From 4d7c87f3ab0a5251b73d2ff67c8df0e458504023 Mon Sep 17 00:00:00 2001 From: Claude Date: Thu, 3 Sep 2026 02:44:34 +0000 Subject: [PATCH 1/2] =?UTF-8?q?content(ja):=20name=20the=20category=20?= =?UTF-8?q?=E3=82=BB=E3=83=9E=E3=83=B3=E3=83=86=E3=82=A3=E3=83=83=E3=82=AF?= =?UTF-8?q?=E3=83=AC=E3=82=A4=E3=83=A4=E3=83=BC,=20not=20the=20calque=20?= =?UTF-8?q?=E6=84=8F=E5=91=B3=E5=B1=A4?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Japanese data-engineering writing names this category セマンティックレイヤー. 意味層 appears in that same writing as an inline gloss explaining the term, not as the term itself — and a word used to explain the term is not the term. That matters for retrieval, which is what the tier-2 tag vocabulary is for: セマンティックレイヤー is the string a Japanese reader would actually type. Swept content/blog/**/index.ja.mdx (38 files): 18 occurrences of 意味層, all of them the category used as a NAME — every one corresponds to a literal "semantic layer" in the English source. Zero glosses, so the "leave the glosses" half of the ruling had no instances to apply to. frontmatter 3 -> 0 body 15 -> 0 セマンティックレイヤー: 0 -> 18 (frontmatter 3, body 15) Frontmatter title and description are included because the ruling rests on retrieval and tags are not routes on this site — and the meta description are where a Japanese query lands. The post slug is locale-independent, so no URL changes. 16 of the 17 changed lines are a pure 意味層 -> セマンティックレイヤー substitution. The one non-mechanical line renders "semantic-layer tool" as セマンティックレイヤーのツール rather than the 13-kana run セマンティックレイヤーツール. Left untouched: セマンティック層 in give-your-agent-rules-for-governable-apps (the issue itself records it as acceptable field usage, not the calque under this card), フォワードデプロイドエンジニア (per the ruling), and ビジネス意味層 in src/components/ArticleList.astro (site chrome, outside the declared surface — reported instead). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FeA1nwBz1ohH65dvffUGKr --- .../ai-ontology-open-protocol/index.ja.mdx | 10 +++++----- .../index.ja.mdx | 18 +++++++++--------- .../index.ja.mdx | 6 +++--- 3 files changed, 17 insertions(+), 17 deletions(-) diff --git a/content/blog/ai-ontology-open-protocol/index.ja.mdx b/content/blog/ai-ontology-open-protocol/index.ja.mdx index 1535926..e178a0c 100644 --- a/content/blog/ai-ontology-open-protocol/index.ja.mdx +++ b/content/blog/ai-ontology-open-protocol/index.ja.mdx @@ -32,7 +32,7 @@ tags: 9 か月目、パイロットは静かに終わります。モデルは能力で負けたのではありません。誰もサインしてくれなかったから負けたのです。 -業界には、ここで欠けていたものの名前があります。**Ontology（ビジネスオントロジー）**——どんなビジネスオブジェクトが存在し、互いにどう関係し、誰が何をしてよく、実行されたことがどこに記録されるのかを、構造化された機械可読な形で明示的に定義する意味層です。 +業界には、ここで欠けていたものの名前があります。**Ontology（ビジネスオントロジー）**——どんなビジネスオブジェクトが存在し、互いにどう関係し、誰が何をしてよく、実行されたことがどこに記録されるのかを、構造化された機械可読な形で明示的に定義するセマンティックレイヤーです。 ## Palantir が正しかったこと @@ -42,7 +42,7 @@ Palantir Foundry の核心は 2 つの動作です。第一に、企業中に散 なぜ高価なのか？解決している問題が本当に高価だからです。大企業が 20 年かけて溜め込んだレガシーシステムを 1 つのきれいなオントロジーに整理するには、Palantir の常駐エンジニア（Forward Deployed Engineer）がシステムを 1 つずつ紐解き、概念を 1 つずつ突き合わせる必要があります——文字通りの労働集約型エンジニアリングです。顧客は政府、防衛、金融、エネルギー。「AI のすべてのステップが権限の範囲内で、すべて記録される」ことが絶対要件であり、予算もそれに見合う顧客です。契約は数百万ドルからですが、更新され続けます。CISO が最も気にする 3 つの質問——冒頭のあの 3 つ——に本当に答えているからです。 -つまり Palantir がはっきり示したのは営業力だけではなく、1 つのアーキテクチャ上の判断です。**AI が企業に入るには、ガバナンスの効いたビジネス意味層が先に存在しなければならない。**この判断にもう論証は要りません。 +つまり Palantir がはっきり示したのは営業力だけではなく、1 つのアーキテクチャ上の判断です。**AI が企業に入るには、ガバナンスの効いたビジネスセマンティックレイヤーが先に存在しなければならない。**この判断にもう論証は要りません。 考え直すべきは次の問いです。この層は、どんな*形態*で存在すべきか？いくつかのことが変わりつつあるからです。 @@ -78,7 +78,7 @@ AWS がどうやって稼いでいるかを見てください。ホストして パターンは驚くほど一貫しています。**エコシステム全体が依存する可搬な基盤は、定義だけでなく、それを解釈する基礎ランタイムまでオープンになっていきます。** ベンダーはそれでも、ホスティング、アップグレード、セキュリティ、性能、サポート、運用責任という本番運用体験から継続収益を得られます。AWS 自身が最大の証拠です。Linux、Kubernetes、Postgres はオープンなまま、AWS はそれらを確実に運用することに対価を得ています。 -ビジネス意味層はまさにこの基盤です。オブジェクトモデル、権限ルール、承認フロー、そしてそれらを強制するランタイムの意味論は、アプリケーション、agent、監査システムから共同で依存されます。依存が増えるほど、どちらも一社のプラットフォームに閉じるべきではありません。定義は自社リポジトリの読める・バージョン管理できるファイルにし、互換ランタイムはセルフホスト可能で交換可能にする。単一の有償エンジンでしか動かないオープンファイルは、本当には可搬ではありません。 +ビジネスセマンティックレイヤーはまさにこの基盤です。オブジェクトモデル、権限ルール、承認フロー、そしてそれらを強制するランタイムの意味論は、アプリケーション、agent、監査システムから共同で依存されます。依存が増えるほど、どちらも一社のプラットフォームに閉じるべきではありません。定義は自社リポジトリの読める・バージョン管理できるファイルにし、互換ランタイムはセルフホスト可能で交換可能にする。単一の有償エンジンでしか動かないオープンファイルは、本当には可搬ではありません。 企業は 20 年かけて**データ**を閉じたシステムから解放してきました。AI の時代に、データよりさらに根源的な資産——**ビジネスの定義そのもの**——を、もう一度閉じ込めるべきではありません。 @@ -108,7 +108,7 @@ AWS がどうやって稼いでいるかを見てください。ホストして **最も強い反論を、正直に置きます。** チームが可搬性から本当に得たいものの大半は、すでに手に入っています。自分のモデルを読み、diff としてレビューし、どの agent にも向けられる。分析用のセマンティクスなら、2026 年に Apache Incubator へ入った中立仕様で交換もできます。ontology が問いに答えるだけでよいなら、それはもう十分に近い。そこを本記事がごまかすべきではありません。 -答えは、そもそも「意味層」と ontology を分ける線と同じです。それは、何かが実際に**起こらねばならない**瞬間まで成り立ちます。公開されたアクションが実際にレコードを書き換えた瞬間、あなたが本当に気にするもの——権限チェック、トランザクション、閾値を超えたときの承認、監査の 1 行——はすべてエンジンの性質であって、ファイルの性質でも、プロトコルの性質でもありません。文はエクスポートできます。強制はエクスポートできません。 +答えは、そもそも「セマンティックレイヤー」と ontology を分ける線と同じです。それは、何かが実際に**起こらねばならない**瞬間まで成り立ちます。公開されたアクションが実際にレコードを書き換えた瞬間、あなたが本当に気にするもの——権限チェック、トランザクション、閾値を超えたときの承認、監査の 1 行——はすべてエンジンの性質であって、ファイルの性質でも、プロトコルの性質でもありません。文はエクスポートできます。強制はエクスポートできません。 この隙間を**最後まで閉じている層**と呼びましょう。非難ではなく、この分野がどこで止まったかの記述です。9 か月で 3 層のうち 2 層が、しかも多くは自らの勢いで開かれました。3 層目はまったく動かなかった——それは、プラットフォーム事業が「自分が売っているもの」を変えずには開けない、唯一の層だからです。 @@ -167,7 +167,7 @@ Ontology という判断は正しい——Palantir が業界全体のために ## おわりに -9 か月目に死んだあの AI パイロットは、モデルの能力に負けたのではありません。セキュリティチームがサインできる意味層が存在しなかったことに負けたのです。業界で最も高価な会社が、この層の価値を 10 年かけて証明しました。そして 2026 年は、9 か月でもっと狭く、もっと役に立つことを証明しました。**この層のうち、開くのが安く済む部分は、もう開かれた。**インターフェースは公開プロトコルであり、定義はあなたが読めるファイルです。残っているのは、後者を前者に変え、その過程で規則を強制するエンジン——そしてその層では、何も開かれませんでした。 +9 か月目に死んだあの AI パイロットは、モデルの能力に負けたのではありません。セキュリティチームがサインできるセマンティックレイヤーが存在しなかったことに負けたのです。業界で最も高価な会社が、この層の価値を 10 年かけて証明しました。そして 2026 年は、9 か月でもっと狭く、もっと役に立つことを証明しました。**この層のうち、開くのが安く済む部分は、もう開かれた。**インターフェースは公開プロトコルであり、定義はあなたが読めるファイルです。残っているのは、後者を前者に変え、その過程で規則を強制するエンジン——そしてその層では、何も開かれませんでした。 だから 6 月に本記事が投げた問いは、いま、より鋭い形を持っています。「オントロジーは開かれるべきか」ではありません——それはもう決着し、しかもベンダー自身が決着させました。問いはこうです：**最後まで閉じている層が、よりによってあなたの業務規則を実行する層だとして、そのエンジンは誰のものであってほしいですか。** diff --git a/content/blog/enterprise-ontology-race-open-vs-closed/index.ja.mdx b/content/blog/enterprise-ontology-race-open-vs-closed/index.ja.mdx index a5abd2f..bac6e53 100644 --- a/content/blog/enterprise-ontology-race-open-vs-closed/index.ja.mdx +++ b/content/blog/enterprise-ontology-race-open-vs-closed/index.ja.mdx @@ -1,6 +1,6 @@ --- -title: "オープンな企業オントロジー：業務意味層は誰が所有すべきか" -description: "2025年11月から2026年8月にかけて5つのプラットフォームが業務意味層を投入し、その多くが MCP の読み取り経路を開放した。だが定義そのものは内部に残る。プロトコルは開放、定義は封鎖——所有権の問いはより鋭くなった。" +title: "オープンな企業オントロジー：業務セマンティックレイヤーは誰が所有すべきか" +description: "2025年11月から2026年8月にかけて5つのプラットフォームが業務セマンティックレイヤーを投入し、その多くが MCP の読み取り経路を開放した。だが定義そのものは内部に残る。プロトコルは開放、定義は封鎖——所有権の問いはより鋭くなった。" author: ObjectStack Team date: 2026-06-16T17:00:00+08:00 updated: 2026-09-02T18:00:00+08:00 @@ -12,7 +12,7 @@ industries: [] cover: ./cover-en.svg tags: - オントロジー - - 意味層 + - セマンティックレイヤー - MCP - Fabric IQ - Unity Catalog @@ -21,7 +21,7 @@ tags: - Looker --- -**結論から**：この記事が 2026 年 6 月に公開されたとき、問いは「業務意味層を誰が所有するのか」だった。そのレースはもう走り終えた。**9 か月で 5 つのプラットフォームが意味層を投入した。** そして誰も予想しなかったことが起きた——各社はオントロジーへの**アクセス経路**を MCP で開放し、**定義そのもの**は内部に留めたのだ。これを**プロトコルは開放、定義は封鎖**と呼ぼう。agent はいま、持ち出せない 5 つのオントロジーを読める。これは所有権の問いを弱めるのではなく、鋭くする。そして答えは変わらない。アプリ、agent、監査、そして複数ベンダーのツールが揃って依存する定義層は、自社リポジトリで保持する中立な層であるべきだ。 +**結論から**：この記事が 2026 年 6 月に公開されたとき、問いは「業務セマンティックレイヤーを誰が所有するのか」だった。そのレースはもう走り終えた。**9 か月で 5 つのプラットフォームがセマンティックレイヤーを投入した。** そして誰も予想しなかったことが起きた——各社はオントロジーへの**アクセス経路**を MCP で開放し、**定義そのもの**は内部に留めたのだ。これを**プロトコルは開放、定義は封鎖**と呼ぼう。agent はいま、持ち出せない 5 つのオントロジーを読める。これは所有権の問いを弱めるのではなく、鋭くする。そして答えは変わらない。アプリ、agent、監査、そして複数ベンダーのツールが揃って依存する定義層は、自社リポジトリで保持する中立な層であるべきだ。 まず、ある会社がまさにこの問題で顧客を失った話から始めよう。詳細は匿名化しているが、どのステップも見覚えがあるはずだ。 @@ -45,13 +45,13 @@ tags: ## この記事が名指ししたレースは、もう走り終えた -この記事が最初に公開された時点では、参加者はまだ予測だった。いまやそれは記録である。2025 年 11 月から 2026 年 8 月にかけて、5 つのプラットフォームが業務意味層を投入した。 +この記事が最初に公開された時点では、参加者はまだ予測だった。いまやそれは記録である。2025 年 11 月から 2026 年 8 月にかけて、5 つのプラットフォームが業務セマンティックレイヤーを投入した。 | プラットフォーム | 何を投入したか | 時期 | | --- | --- | --- | | **Microsoft Fabric IQ** | Ontology アイテムに加え、Graph・Data Agent・Operations Agent からなる agent ワークロード一式。パブリックプレビュー。公開 Ontology MCP エンドポイント経由で任意の agent から到達可能 | Ignite、2025 年 11 月。2026 年 3 月 FabCon アトランタでルールと自動化を追加 | | **Snowflake** | Semantic View Autopilot が GA。委員会に「売上」をゼロから定義させるのではなく、既存のクエリ履歴と BI 資産から意味ビューを起草する | 2026 年 2 月 3 日 | -| **Google** | Looker BI Agents が Looker の意味層に接地。Dataplex は Knowledge Catalog に改称され、カタログのメタデータを意味グラフに変換し、agent 向けのコンテキスト API を提供 | Cloud Next '26、2026 年 4 月 | +| **Google** | Looker BI Agents が Looker のセマンティックレイヤーに接地。Dataplex は Knowledge Catalog に改称され、カタログのメタデータを意味グラフに変換し、agent 向けのコンテキスト API を提供 | Cloud Next '26、2026 年 4 月 | | **Databricks Unity Catalog** | Business Semantics が GA。統制されたメトリックビューと agent メタデータをデータ層で一度定義する。中核実装は Apache Spark へオープンソース化が進行中 | 2026 年に GA。Business Glossary と Domains は 2026 年 6 月の Data + AI Summit で | | **Palantir Foundry** | Ontology MCP が全 Foundry 環境で GA。オブジェクト型・アクション型・関数が、任意の MCP クライアントから呼べるツールとして公開される | 2026 年 6 月 16 日の週 | @@ -67,7 +67,7 @@ tags: ここからが、誰の予想とも違った方向に進んだ部分であり、6 月以降で最も重要な変化だ。 -プラットフォームは壁を閉ざさなかった。むしろ開いた——MCP で。Fabric IQ は公開 Ontology MCP エンドポイントを提供する。Palantir は、この記事が最初に公開されたまさにその週に、全 Foundry 環境で Ontology MCP を一般提供にした。Snowflake はマネージド MCP サーバーを提供する。Google は Knowledge Catalog の前段にコンテキスト API を置いた。上記の比較記事にある 4 プラットフォームのうち、**3 つが自らの意味層を MCP で agent に開放している**。 +プラットフォームは壁を閉ざさなかった。むしろ開いた——MCP で。Fabric IQ は公開 Ontology MCP エンドポイントを提供する。Palantir は、この記事が最初に公開されたまさにその週に、全 Foundry 環境で Ontology MCP を一般提供にした。Snowflake はマネージド MCP サーバーを提供する。Google は Knowledge Catalog の前段にコンテキスト API を置いた。上記の比較記事にある 4 プラットフォームのうち、**3 つが自らのセマンティックレイヤーを MCP で agent に開放している**。 一見すると、開かれた答えが自ずとやって来たように見える。そうではない。この区別は精確に述べる価値がある。 @@ -87,7 +87,7 @@ MCP エンドポイントは読み取り経路であって、権利証ではな **第 2 層は技術。** インセンティブを脇に置いても、オントロジー間の意味整合は難しい。A システムの「顧客」は B システムの「Account」と等しいのか。項目定義、ライフサイクル、重複排除ルール、「同一実体」の判定基準は、システムごとに違う。AI もこれを確実に自動推論できない。agent が誤るのは、まさにこの確定した定義の層が欠けているからだ。H グループに戻ろう。「この 3 件は同じ会社か」を agent に推測させたとき、外した代償があの損失だった。 -**第 3 層は新しく、そして最も居心地が悪い：MCP は断片化を我慢するコストを下げた。** 以前は、互いに繋がっていない 5 つの意味層に agent を配線するのは十分に苦しく、いずれ誰かが問題を上申し、名寄せプロジェクトに予算がついた。いまやそれは、午後いっぱいで 5 つのエンドポイントを登録するだけの作業だ。agent は「この顧客は誰か」に別々の答えを返す 5 つのツールを平然と抱え、最初に届いた方から自信満々に答える。**かつて名寄せを強制していた統合の痛みは取り除かれた。それが警告していた断片化は、そのまま残っている。** +**第 3 層は新しく、そして最も居心地が悪い：MCP は断片化を我慢するコストを下げた。** 以前は、互いに繋がっていない 5 つのセマンティックレイヤーに agent を配線するのは十分に苦しく、いずれ誰かが問題を上申し、名寄せプロジェクトに予算がついた。いまやそれは、午後いっぱいで 5 つのエンドポイントを登録するだけの作業だ。agent は「この顧客は誰か」に別々の答えを返す 5 つのツールを平然と抱え、最初に届いた方から自信満々に答える。**かつて名寄せを強制していた統合の痛みは取り除かれた。それが警告していた断片化は、そのまま残っている。** 一行でまとめる。**あなたは 5 つのツールを買ったつもりで、実際には互いを知らない 5 つの真実の源を買った。しかも今度は、便利に呼び出せる。** システムが増え、買収が増え、コンプライアンス隔離が増えるほど、この断片化は深刻になる。agent 時代はその代償を増幅する。人間なら苦しみながらも複数システムを手作業で突き合わせられるが、agent にはできない。推論する前に、確定した、システム横断で一貫した定義の層が要るのだ。 @@ -116,7 +116,7 @@ MCP エンドポイントは読み取り経路であって、権利証ではな 3. 新しいシステムを繋ぐたび、「これは何か」「項目は何を意味するか」を AI に教え直している。 4. 買収から 1 年以上経つのに、双方のマスターデータがまだ本当には統合されておらず、各々が自分の版を報告している。 5. コンプライアンス上ある種のデータを隔離する必要があり、同じ実体が複数部に分かれ、互いを認識していない。 -6. あなたの agent に意味層ツールが 2 つ以上与えられていて、食い違ったときどちらが優先かを誰も書き留めていない。 +6. あなたの agent にセマンティックレイヤーのツールが 2 つ以上与えられていて、食い違ったときどちらが優先かを誰も書き留めていない。 遠峰が H グループを失う前、最初の 5 つのうち 4 つが当てはまっていた。当時それらは「データガバナンスの宿題」として整理され、agent がいずれ暴くリスクだとは誰も思っていなかった。6 番目は 2026 年に加わった項目で、最も静かに訪れる。エンドポイントをもう 1 つ足すことは、前進のように感じられるからだ。 diff --git a/content/blog/why-ai-agent-pilots-fail-four-layers/index.ja.mdx b/content/blog/why-ai-agent-pilots-fail-four-layers/index.ja.mdx index 250b1aa..cdfe098 100644 --- a/content/blog/why-ai-agent-pilots-fail-four-layers/index.ja.mdx +++ b/content/blog/why-ai-agent-pilots-fail-four-layers/index.ja.mdx @@ -51,7 +51,7 @@ PoC そのものは間違っていない。間違っているのは **検証す | それが答えられなければならないこと | 欠けているのはどの層か | 欠けるとどうなるか | | --- | --- | --- | -| 「顧客」とは結局何を指すのか? 定義はどこにあるのか? | ① 意味層 | 見当違いの答え、定義の衝突、業務が認めない | +| 「顧客」とは結局何を指すのか? 定義はどこにあるのか? | ① セマンティックレイヤー | 見当違いの答え、定義の衝突、業務が認めない | | A 顧客の情報が B 顧客に使われないか? | ② 権限層 | 越権漏洩、法務が一票で否決 | | このステップは先に人の承認を待つべきか? | ③ フローと承認の層 | 止めるべきが止まらず、誰も動かせない | | この操作は誰が、いつ、何に基づいて行ったのか? | ④ 監査層 | 証拠を出せず、コンプライアンスが直接阻止 | @@ -60,7 +60,7 @@ PoC そのものは間違っていない。間違っているのは **検証す ## なぜこの四層はいつも欠席するのか -ではなぜ最初から作っておかないのか? 従来のやり方では、どの層も大きな塊の **横断的な** 硬い工事だからだ。意味層は十数のシステムのデータを統一されたオブジェクトモデルに整合させねばならず、権限層は各アプリのコードに散らばったルールを一貫したポリシーにまとめねばならず、承認は既存の体系に接続せねばならず、監査は人と AI の動作を同じ一冊の帳簿に集約せねばならない。それらはある機能の一部ではなく、すべての機能の下に敷かれた土台だ――汚くて遅く、しかもすべてデモには見えない部分だ。 +ではなぜ最初から作っておかないのか? 従来のやり方では、どの層も大きな塊の **横断的な** 硬い工事だからだ。セマンティックレイヤーは十数のシステムのデータを統一されたオブジェクトモデルに整合させねばならず、権限層は各アプリのコードに散らばったルールを一貫したポリシーにまとめねばならず、承認は既存の体系に接続せねばならず、監査は人と AI の動作を同じ一冊の帳簿に集約せねばならない。それらはある機能の一部ではなく、すべての機能の下に敷かれた土台だ――汚くて遅く、しかもすべてデモには見えない部分だ。 さらに悪いことに、多くのチームは **試験導入ごとにこの四層を個別に作り直す**。今回が終わり、シナリオを替えれば、四層を一から作り直す。予算と忍耐が、すべて土台を繰り返し作ることに費やされる。 @@ -108,7 +108,7 @@ export const RepairTicket = ObjectSchema.create({ }); ``` -残りの四層はオープンな ObjectStack ランタイムが揃える。**意味層**――この宣言そのものが、agent が業務を理解する拠り所だ。**権限層**――誰が修理依頼書を読み書きできるかを、ランタイムが呼び出しのたびに強制検証する。**フローと承認の層**――「修理費用が上限超過なら承認を経る」は、オブジェクトにぶら下がった宣言的フローで、自動で一時停止してサインを待つ。**監査層**――人と agent の動作のたびに、同じ一冊の帳簿に落ちる。次のシナリオに替えても、この四層は作り直さず、オブジェクトをいくつか宣言し直すだけでいい。 +残りの四層はオープンな ObjectStack ランタイムが揃える。**セマンティックレイヤー**――この宣言そのものが、agent が業務を理解する拠り所だ。**権限層**――誰が修理依頼書を読み書きできるかを、ランタイムが呼び出しのたびに強制検証する。**フローと承認の層**――「修理費用が上限超過なら承認を経る」は、オブジェクトにぶら下がった宣言的フローで、自動で一時停止してサインを待つ。**監査層**――人と agent の動作のたびに、同じ一冊の帳簿に落ちる。次のシナリオに替えても、この四層は作り直さず、オブジェクトをいくつか宣言し直すだけでいい。 陳さんのあのプロジェクトがこう作られていたら、法務のあの問いは死刑にはならなかった。彼はその場で権限セットを取り出し、agent は質問者の身分でしか、質問者が見る権限のあるデータしか見られないことを証明できた――②の層がもともと足元にあったからだ。 From 901948bfddcc128be3899a6c1fcd3f93f1a61721 Mon Sep 17 00:00:00 2001 From: Claude <noreply@anthropic.com> Date: Thu, 3 Sep 2026 02:57:37 +0000 Subject: [PATCH 2/2] =?UTF-8?q?content(ja):=20name=20the=20category=20?= =?UTF-8?q?=E3=82=BB=E3=83=9E=E3=83=B3=E3=83=86=E3=82=A3=E3=83=83=E3=82=AF?= =?UTF-8?q?=E3=83=AC=E3=82=A4=E3=83=A4=E3=83=BC=20in=20the=20blog-index=20?= =?UTF-8?q?lead=20too?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Patch round on #159. The seat's ruling scoped the sweep to content/blog/**/index.ja.mdx plus the #78 vocabulary table, so this string was reported rather than edited in the first pass. The seat has since ruled it in scope, on two pieces of evidence I re-verified here: - Its English sibling (ArticleList.astro:49) reads "why the business semantic layer should be open" — the category used as a NAME, the same test that governed the other 18 occurrences. - Its Korean sibling (line 91) already reads 비즈니스 시맨틱 레이어, the transliteration. Across the eight locale entries, Japanese was the only calque: zh-Hans 业务语义层, zh-Hant 業務語意層, de Business-Semantikschicht, es capa semántica de negocio, fr couche sémantique métier, ko 시맨틱 레이어. This is the recommended-reading lead on /ja/blog/ — the first Japanese prose a visitor to the site reads — and it was the last 意味層 in the repository. grep -rn '意味層' src content scripts -> 1 hit before, 0 after widened to the whole repo (minus node_modules/dist/.git) -> same 1, now 0 ビジネスセマンティックレイヤー matches what this branch already uses in ai-ontology-open-protocol/index.ja.mdx for the same English phrase. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FeA1nwBz1ohH65dvffUGKr --- src/components/ArticleList.astro | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/components/ArticleList.astro b/src/components/ArticleList.astro index 3584da7..0547257 100644 --- a/src/components/ArticleList.astro +++ b/src/components/ArticleList.astro @@ -64,7 +64,7 @@ const homeCopy: Record<Locale, { }, ja: { recommendedTitle: 'おすすめ記事', - recommendedLead: 'まずはここから：ビジネス意味層がなぜオープンであるべきか、AI-native の核心がなぜコードではなくメタデータなのか、そして一文がどうガバナンス可能なアプリになるのか。', + recommendedLead: 'まずはここから：ビジネスセマンティックレイヤーがなぜオープンであるべきか、AI-native の核心がなぜコードではなくメタデータなのか、そして一文がどうガバナンス可能なアプリになるのか。', latestTitle: '最新記事', latestLead: 'ObjectOS ブログの新着記事です。', },