オープンな企業オントロジー：業務セマンティックレイヤーは誰が所有すべきか

結論から：この記事が 2026 年 6 月に公開されたとき、問いは「業務セマンティックレイヤーを誰が所有するのか」だった。そのレースはもう走り終えた。9 か月で 5 つのプラットフォームがセマンティックレイヤーを投入した。 そして誰も予想しなかったことが起きた——各社はオントロジーへのアクセス経路を MCP で開放し、定義そのものは内部に留めたのだ。これをプロトコルは開放、定義は封鎖と呼ぼう。agent はいま、持ち出せない 5 つのオントロジーを読める。これは所有権の問いを弱めるのではなく、鋭くする。そして答えは変わらない。アプリ、agent、監査、そして複数ベンダーのツールが揃って依存する定義層は、自社リポジトリで保持する中立な層であるべきだ。

まず、ある会社がまさにこの問題で顧客を失った話から始めよう。詳細は匿名化しているが、どのステップも見覚えがあるはずだ。

遠峰と呼ぶこの産業機器メーカーは、年商数十億ドル規模で数千社の顧客を持つ。2024 年、同社はデータ基盤を Microsoft に賭け、Fabric の中に整然としたオントロジーを構築した。「顧客」とは何か、どの「設備」がどの顧客に紐づくか、どの「作業指示」がどの設備に紐づくか。その年、同社はベンダーのカンファレンスで繰り返し紹介されるモデルケースになった。

2026 年、3 つのことがほぼ同時に遠峰を襲った。

データサイエンスチームが更新予測を Gemini で回したがった。その用途では実際に精度が高かったからだ。
コンプライアンス部門に、EU 顧客データは EU 域内に留め、米国クラウドに置けないという通知が届いた。
買収が完了し、Salesforce 上で動く数千社の顧客を抱えた営業組織が丸ごと加わった。

こうして遠峰には3 つの「顧客」ができた。Fabric に 1 つ、Salesforce に 1 つ、コンプライアンス隔離された EU 環境にもう 1 つ。

転機は H グループと呼ぶ主要顧客で訪れた。ある日、営業部長が agent に尋ねた。「H グループの来年の更新リスクはどのくらい高いか」。agent は「低い」と答えた。それは Fabric のオントロジーを読んでおり、そこでは H グループの直近の受注は健全で、数字は綺麗だった。

だが agent が見ていなかったもの——買収で入ってきた Salesforce の記録では、H グループは半年で 2 度、苦情を役員レベルにエスカレーションしていた。EU 隔離環境では、90 日延滞の支払係争が未解決のまま残っていた。3 組のデータは互いを知らない 3 つの「顧客」に属し、それらが同じ H グループだと知っている層は、どこにも存在しなかった。

四半期後、H グループは解約した——年間で数百万ドルの損失。事後検証の結論は、部屋を静まり返らせるほど厳しかった。agent は技術的には誤っていない。見えていたデータの断片は、本当に低リスクを示していた。間違っていたのはモデルではない。その足元にある「顧客」の定義が、3 つに切り刻まれていたことだ。

これは単なる遠峰のミスではない。「自社ビジネスの定義」をプラットフォームに預けたときの、予測可能な帰結である。各プラットフォームは自分の担当分しか守らないし、理解もしないからだ。

この記事が名指ししたレースは、もう走り終えた

この記事が最初に公開された時点では、参加者はまだ予測だった。いまやそれは記録である。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 月
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 日の週

議論を進める前に、この表について 2 つ明言しておきたい。

この記事は、それらをセル単位で比較する場ではない。 能力ごとに、各ベンダー自身のドキュメントを出典として突き合わせたのは別の記事だ：Fabric IQ vs Palantir vs Unity Catalog vs Snowflake。そこでは、どれが業務を記述するだけでなくアクションをモデル化しているのか——最も決定的な行——が決着している。選定中ならあちらを、何を所有すべきかを決めるならこちらを読んでほしい。

論を成しているのは日付であって、機能一覧ではない。 9 か月、5 つのプラットフォーム、「この層は作る価値がある」という 5 つの独立した判断。企業で AI を使うには機械可読で統制された業務定義の層が要る——この半分は、もう誰も説得する必要がない。

ひとつ整理が要る。ここで使われる 3 つの語は同義語として扱われがちだが、同義ではない：ontology vs semantic layer vs knowledge graph が、それぞれ何に答えられて何に答えられないかを定めている。以下の所有権の議論は、どの層の話かを決めた読者を前提にする。

転換点：プロトコルは開放、定義は封鎖

ここからが、誰の予想とも違った方向に進んだ部分であり、6 月以降で最も重要な変化だ。

プラットフォームは壁を閉ざさなかった。むしろ開いた——MCP で。Fabric IQ は公開 Ontology MCP エンドポイントを提供する。Palantir は、この記事が最初に公開されたまさにその週に、全 Foundry 環境で Ontology MCP を一般提供にした。Snowflake はマネージド MCP サーバーを提供する。Google は Knowledge Catalog の前段にコンテキスト API を置いた。上記の比較記事にある 4 プラットフォームのうち、3 つが自らのセマンティックレイヤーを MCP で agent に開放している。

一見すると、開かれた答えが自ずとやって来たように見える。そうではない。この区別は精確に述べる価値がある。

MCP が標準化したのは、agent がどうやってオントロジーに届くかである。誰がそれを保持するかについては、何ひとつ標準化していない。

MCP エンドポイントは読み取り経路であって、権利証ではない。あなたの agent は、統制されベンダー中立な綺麗な問い合わせ手段を手に入れる。だがその問い合わせ先の定義は、依然として他社のプラットフォームに住み、他社のリリース列車でバージョンが決まり、あなたが去るときには相手とともに残る。プロトコルは開いている。定義は閉じている。プロトコルは開放、定義は封鎖。

これが重要なのは、この 2 つが、最も金のかかる方向で混同されやすいからだ。「どの agent でも読める」は可搬性のように聞こえる。それは可搬性の逆である。持ち出せないという状態を、居心地よくしてしまうものだ。

それが断片化を軽くせず、むしろ悪化させる理由

単一ベンダーのロックインなら、少なくともあなたの業務定義は完全な 1 部として残る。動かせないだけだ。痛いが、まとまってはいる。

5 つのプラットフォームがそれぞれ自前のオントロジーを持つと、別のものが生まれる。断片化だ。遠峰の「顧客」は単にロックされたのではない。3 つに切られ、互いを知らない 3 つのプラットフォームに保管された。それが自然治癒しない仕組みが 2 層あり、MCP がいま 3 層目を加えた。

第 1 層はインセンティブ。 Microsoft のオントロジーに Salesforce の「顧客」を理解させればいい、と思うかもしれない。そう単純ではない。各ベンダーのオントロジーは自社の堀の一部だからだ。もし Microsoft が一方的に「顧客」の意味論を競合と統一すれば、競合のデータ移動を滑らかにし、自社の差別化を減らすことになる。レースの参加者全員にとって、統一は戦略的に旨みがない。 これは技術的な見落としではなく、合理的なプラットフォーム行動である。

第 2 層は技術。 インセンティブを脇に置いても、オントロジー間の意味整合は難しい。A システムの「顧客」は B システムの「Account」と等しいのか。項目定義、ライフサイクル、重複排除ルール、「同一実体」の判定基準は、システムごとに違う。AI もこれを確実に自動推論できない。agent が誤るのは、まさにこの確定した定義の層が欠けているからだ。H グループに戻ろう。「この 3 件は同じ会社か」を agent に推測させたとき、外した代償があの損失だった。

第 3 層は新しく、そして最も居心地が悪い：MCP は断片化を我慢するコストを下げた。 以前は、互いに繋がっていない 5 つのセマンティックレイヤーに agent を配線するのは十分に苦しく、いずれ誰かが問題を上申し、名寄せプロジェクトに予算がついた。いまやそれは、午後いっぱいで 5 つのエンドポイントを登録するだけの作業だ。agent は「この顧客は誰か」に別々の答えを返す 5 つのツールを平然と抱え、最初に届いた方から自信満々に答える。かつて名寄せを強制していた統合の痛みは取り除かれた。それが警告していた断片化は、そのまま残っている。

一行でまとめる。あなたは 5 つのツールを買ったつもりで、実際には互いを知らない 5 つの真実の源を買った。しかも今度は、便利に呼び出せる。 システムが増え、買収が増え、コンプライアンス隔離が増えるほど、この断片化は深刻になる。agent 時代はその代償を増幅する。人間なら苦しみながらも複数システムを手作業で突き合わせられるが、agent にはできない。推論する前に、確定した、システム横断で一貫した定義の層が要るのだ。

断片化を避けるには、業務の定義がレースの当事者であるプラットフォームに全面的に属していてはならない。それは中立な層——自分で保持し、異なるベンダーのツールが読める定義——である必要がある。閉じたプラットフォームは構造的にこれを提供しづらい。彼らはレースの選手であり、同時に中立な審判にはなれないからだ。

まず、閉じたプラットフォームが勝つ筋書き

「オープンは善だ」と繰り返すだけなら、それは分析ではなく説教である。閉じたプラットフォームは 4 枚の本物のカードを持ち、この 9 か月でうち 2 枚は強くなった。

第 1 に、モデリング品質。 20 年積み上がった企業の複雑さを、綺麗で自己整合したオントロジーに落とすのは重い工学だ。Palantir は常駐エンジニアと 1 概念ずつ突き合わせる。その品質にオープンソースコミュニティが短期で並ぶのは難しい。オントロジーは、下手に作るくらいなら作らない方がましなこともある。常駐モデルには固有の経済性があり、それは職名ほど簡単には移植できない——常駐モデルの模倣がなぜコンサル会社を作ってしまうのかが、その下に何が存在していなければならないかを解いている。

第 2 に、責任を負う単一の主体。 壊れたとき、電話に出る人がいて、SLA があり、背後に契約がある。CIO にとって「1 社がこの層全体の責任を担う」ことには本当の価値がある。

第 3 に、実際「ほぼ 1 スタック」の会社は多い。 業務の 8 割がすでに 1 つのエコシステムにあるなら、「そのエコシステム内で最良」が文字通り最良の選択肢でありうる。事業がシステム横断でないなら、オープンの利点は使いにくい。

第 4 に——これが強くなった——コールドスタート問題。 Snowflake の Autopilot は既存のクエリ履歴から意味モデルを起草する。Fabric IQ は業務の専門家がノーコードのビジュアルツールでオントロジーを書けるようにし、データエンジニア待ちを不要にした。どちらも本当の障害を突いている。障害は技術ではなく、6 か月かかるモデリング委員会だった。オープンなフォーマットが渡すのは、ファイルと白紙のページである。

4 枚とも本物だ。だから結論は「閉じたプラットフォームは全部罠」ではない。1 つのエコシステムに収まっている会社にとっては、しばしば正解である。問題が現れるのは遠峰のような会社だ。前提が失効する。

断片化されつつあるかの見分け方

これは抽象論ではなく、具体的な初期症状がある。以下を照合してほしい。3 つ以上当てはまるなら、断片化はすでに社内で起きている。

同じ「顧客 / 受注 / 設備」がシステムごとに違う定義で、突合できない。レポートのたびに人手で継ぎ合わせている。
agent にシステム横断の質問をすると、曖昧に濁すか、半分だけ正しい（片方は見えて、もう片方が見えていない）。
新しいシステムを繋ぐたび、「これは何か」「項目は何を意味するか」を AI に教え直している。
買収から 1 年以上経つのに、双方のマスターデータがまだ本当には統合されておらず、各々が自分の版を報告している。
コンプライアンス上ある種のデータを隔離する必要があり、同じ実体が複数部に分かれ、互いを認識していない。
あなたの agent にセマンティックレイヤーのツールが 2 つ以上与えられていて、食い違ったときどちらが優先かを誰も書き留めていない。

遠峰が H グループを失う前、最初の 5 つのうち 4 つが当てはまっていた。当時それらは「データガバナンスの宿題」として整理され、agent がいずれ暴くリスクだとは誰も思っていなかった。6 番目は 2026 年に加わった項目で、最も静かに訪れる。エンドポイントをもう 1 つ足すことは、前進のように感じられるからだ。

冷や水を一杯：オープンは銀の弾丸ではないし、この領域は標準化しつつある

ここで正直に立ち止まろう。さもないと売り込みになる。真っ当な反論が 3 つあり、3 つ目は新しい。

第 1 に、定義をオープンなプロトコルに置き換えても、遠峰の 3 つの「顧客」が自動的に 1 つになるわけではない。 意味モデリング、重複排除、定義の突合はやはり必要だ。ここに銀の弾丸はないし、あると言う者を信じてはいけない。オープンが本当に変えるのは、この重労働の帰属である。今日あなたが揃えた定義は、プラットフォームの裏側ではなく、自社リポジトリに書かれる。来年モデルを替え、クラウドを替え、買収されたとき、作り直すのは接続であって定義そのものではない。

第 2 に、「オープン」自体が勝ちを保証しない。 歴史的に、オープン標準が勝つには通常、良い参照実装と活発なエコシステムも要る。誰も快適に使えるようにしないプロトコルを公開するだけでは足りない。オープンを選ぶことは、「誰かがちゃんと作るだろう」に賭けることだ。これは実行リスクであって、確定した勝ちではない。

第 3 に——そしてこれが本稿の立場に対する最強の反論だが——ベンダー自身が定義層を標準化しつつある。 Snowflake は Salesforce、dbt Labs、BlackRock、RelationalAI とともに Open Semantic Interchange を共同設立した。この取り組みは 2026 年 7 月に Apache Ossie として Apache Incubator に入り、Databricks、Oracle、Collibra を含む 50 以上の組織が参加している。Databricks は別途、メトリックビューの実装を Apache Spark へオープンソース化している。これは本物であり、多くの中立層の取り組みより速い。「閉じたプラットフォームは決して収斂しない」と今日主張するのは、証拠に逆らうことだ。

だが、その収斂がどこで止まるかをよく見てほしい。Ossie が扱うのは分析系の意味論——メトリック、ディメンション、リレーションシップだ。アクションと権限は対象外である。つまり、業務を記述する側の半分は可搬になりつつあり、業務を変更する側の半分——操作そのもの、誰が実行してよいか、監査ログに何が書かれるか——は専有のまま残る。これは小さな残りではない。agent が何かを実行できるかを決める半分であり、断片化の代償が最も高い半分である。

この 3 つはどれも「閉じている方が良い」とは言っていない。オープンにも手間があり、リスクがあり、半分は歩み寄られつつある、と言っている。それを、業務定義を 1 つのプラットフォームに固定し、その後 5 つに分断されることの下振れと比べてほしい。どちらも無料ではない。ただ一方は、中核資産を自分の手に残す。

皆が依存する層は、中立に落ち着く

このパターン自体は新しくないが、新しい例で語る価値がある。繰り返し起きているからだ。

エコシステム全体が共同で依存する「定義層」は、中立になっていく傾向がある。最も古い例は SQL だ。データベースベンダーは激しく競ったが、クエリ言語そのものは公共のままだった。より新しい例が 2 つある。中立な CNCF がホストする可観測性データ標準の OpenTelemetry、そして Microsoft が公開し、オープンだったからこそ多くのエディタに採用された LSP（Language Server Protocol）である。

LSP の例が特に有用なのは、Microsoft 自身がパターンを証明したからだ。定義層を開放し、最良の実装で競う方が、層を閉じるより多くの価値を生みうる。ただし LSP が実際に何を開いたかに注目してほしい——プロトコルと、言語サーバーが提供すべきものの定義だ。オントロジーについては、MCP が前半を済ませた。Apache Ossie が分析部分の後半に挑んでいる。そして「動く」部分については、まだ誰もやっていない。

あなたのアプリケーション、agent、監査システム、そして 5 社のツールが同時に依存する層は、遠峰が被ったような断片化を出し続けない限り、そのうちの 1 社の私物のままではいられない。

中立な層は、どんな形をしているか

ここまで来たら実物を見よう。要点は構文ではない。定義がどこにあるか、持ち出せるか、断片化を引き戻せるかである。

遠峰が当初「顧客」を 1 つの中立な定義として作っていたとしよう。3 システムすべてをデータソースとして接続し、それぞれをオブジェクトとしてモデル化し、共有キー（納税者番号）で 1 つの統制された「顧客」に揃える。自社リポジトリの中の、唯一の真実の源となる宣言だ。

export const Customer = ObjectSchema.create({
  name: 'crm_customer',
  label: 'Customer',
  fields: {
    name: Field.text({ label: 'Customer name', required: true }),
    tax_id: Field.text({ label: 'Tax ID' }), // システム横断で「同じ顧客」を揃える共有キー
  },
});

この定義は Git リポジトリに置かれる。diff でき、レビューでき、移行できる。次に何ができるかが核心だ——「可搬」を約束ではなく、実演できる動作に変える。

git add crm/*.ts          # 定義がバージョン管理に入る：監査可能、巻き戻し可能
os start   # 同じ定義が、自社のインフラ上で動く
# あとは任意のモデルを向ければいい——Claude、GPT、Gemini——ランタイムは変わらない

ここでもう一度あの決定的な問いを投げよう。「H グループの来年の更新リスクはどのくらい高いか」。agent が見るのは、権限と監査が付いた1 つの統合された「顧客」だ。健全な受注に、役員レベルの苦情 2 件と 90 日の支払係争が重なっている。agent は「高リスク、早期介入を推奨」と答える。同じモデル、同じ問い。足元の定義が断片化していないというだけで、結論は「数百万ドルを失った」から「四半期まるごと早く警告した」に変わる。

MCP の論点はここでも効く。しかも効く向きが正しい。同じ定義こそ、ランタイムが統制されたツールとして agent に差し出すものだ——読み取り経路は開かれ、かつ定義はあなたのものである。それが定義とランタイムの双方がなぜオープンであるべきかの全論証である。

これが ObjectStack と ObjectOS の分業であり、このレースへの答えでもある。

ObjectStack — open business ontology（オープンな業務オントロジー）：オープンな定義プロトコルと、オープンソースの自己ホスト型ランタイム（Apache 2.0）。定義はあなたのリポジトリに置かれ、どのベンダーの agent でも読め、ランタイムが検証と実行を担い、権限と監査を強制する。
ObjectOS — 同じ ObjectStack アプリケーションのための、任意選択の商用プロダクション基盤と運用体験。クラウドでも自社管理でも、ブラウザベースの AI 構築・デプロイ・運用を足す。下層のオープンな定義とランタイムを置き換えることはない。

定義と自己ホスト型ランタイムはオープンかつ中立に保ち、商用のプロダクション体験で製品が競う。SQL とデータベースベンダー、LSP とエディタベンダーの関係と同じである。

トレードオフも正直に書く。モデリングの深さ、コールドスタート、そしてウェアハウス規模の分析系意味論——この 3 つでは上記のプラットフォームが先行しており、比較記事がどこで先行しているかを詳述している。ここで違うのは「より良い」より狭い。定義はオープンライセンスの下にある、自社リポジトリの普通のファイルであり、それを執行するランタイムは自分でホストできる、ということだ。

むすび

これは「オープンが善か、クローズドが善か」というイデオロギーの問いではない。もっと冷めたアーキテクチャの問いだ。マルチモデル採用、マルチクラウド戦略、買収、コンプライアンス隔離によってベンダー構成が変わるとき、あなたのビジネスの定義を握っているのは誰か。

9 か月前、その問いは仮定だった。この領域がまだ何も出していなかったからだ。いまや出した。5 つのプラットフォームがこの層に作る価値があることを証明し、そしてその多くが、あなたの所有物ではない家に正面玄関を開けた。他社のオントロジー上の MCP エンドポイントは本当に有用だ——ただ、その定義を所有することとは同じではない。そしてその 2 つの隙間こそ、遠峰の H グループが落ちた場所である。

皆が依存する層が 1 社に留まり続けることは稀だ。この層だけが例外である理由はない。

npm i -g @objectstack/cli && os start

最初の業務オブジェクトを定義し、そのデータを既存の 2 システムから取り、自分のリポジトリに git commit してみてほしい。その瞬間、ビジネスの定義は誰かのバックエンドではなく、あなたの手に戻っている。