オープンな企業オントロジー：業務意味層は誰が所有すべきか
企業 AI には機械可読な業務定義層が必要だ。だが「顧客、注文、設備」の定義が各プラットフォームに閉じると、agent は同じ会社を見られない。意味層は企業自身が持つべきだ。
結論から言うと： アプリも、agent も、監査人も――そして今や複数のベンダーまでもが依存するビジネス定義の層は、特定のプラットフォームに属するべきものではない。それは、自社のリポジトリの中に自分で握っておく中立的な層であるべきだ。
まず、ある会社がこの一件でどうやって顧客を一社失ったかを話そう。細部は伏せてあるが、各ステップはおそらくあなたも見覚えがあるはずだ。
ユアンフォン（远峰）は工業設備のメーカーで、年商は数十億、顧客は数千社を抱える。2024 年、同社はデータ基盤の命運をマイクロソフトに賭け、Fabric の中にきれいなオントロジーを構築した。「顧客」とは何か、ある顧客にはどの「設備」が紐づくのか、その「設備」にはどの「作業指示」がぶら下がっているのか――それらをすべて明確に定義した。その年、同社はベンダーの大規模カンファレンスで何度も名前を挙げられる模範事例だった。
2026 年、三つの出来事がほぼ同時にユアンフォンに降りかかった。
- データサイエンスチームが、ある具体的なシナリオでは Gemini のほうが確かに精度が高かったため、それを使って解約予測を一括で回したいと考えた。
- コンプライアンス部門に、EU の顧客データは EU 域内に留めなければならず、米国のクラウドにはもう入れられない、という通知が届いた。
- ある買収が完了し、Salesforce 上で稼働する数千社の顧客を抱える営業組織が丸ごと加わった。
こうしてユアンフォンには 三つの「顧客」 ができた。Fabric の中に一つ、Salesforce の中に一つ、そしてコンプライアンスのために隔離された EU 環境の中にもう一つ。
物語の転機は「H グループ」という重要な大口顧客の上で起きた。ある日、営業統括が agent に尋ねた。「H グループの来年の解約リスクはどれくらい高い?」agent は答えた。「低いです」――それは Fabric のオントロジーに接続していて、そこでは H グループの直近の受注は健全で、数字は美しかった。
だが agent が見ていなかったものがある。Salesforce のレコード(買収によってもたらされたもの)では、H グループは半年のうちに二度、苦情を経営層レベルにエスカレーションしていた。EU 隔離環境には、90 日も滞留している回収トラブルがぶら下がっていた。三つのデータはそれぞれ互いを認識しない三つの「顧客」に属していて、それらが実は同じ H グループであることを、どの層も知らなかった。
四半期が一つ過ぎたころ、H グループは離反し、年間で数百万の損失となった。事後検証の結論は、痛烈すぎて誰もが沈黙するものだった――agent は技術的には間違っていない。それが見たデータは、確かに低リスクを示していた。間違っていたのはモデルではなく、その足元にある「顧客」の定義が三つに切り分けられていたことだ。
これはユアンフォンの失策ではない。これは「業務の定義」をプラットフォームに預けて保管させたことの必然的な帰結だ――そして各プラットフォームは、自分の持ち分だけを保管する。
個別事例ではない:誰もがこの層へ向かっている
ユアンフォンの状況がこれほど普遍的なのは、業界全体が一斉に同じ層へと殺到しているからだ。
以前は「ビジネス意味層 / Ontology」といえば、ほぼ Palantir の語彙だった。いまは Microsoft、Google、Salesforce なども、AI が読める業務定義層へ向かっている。名前は違っても方向は同じだ。agent が業務システムを横断して動くには、「顧客」「注文」「設備」が何を意味するかを機械が読める形にしなければならない。
なぜほかでもなく今なのか。agent がこの穴を突き破ったからだ。過去十年のデータパイプラインは「データがどこに流れるか」だけを気にして、「このデータが何を意味するか」はあまり気にしなかった――最後に帳尻を合わせるのは人間だったからだ。agent にはその帳尻を合わせる人間がいない。何十枚ものテーブル、定義のばらばらな「顧客」フィールドを前にして、間違って答える(H グループに対してそうしたように)か、怖くて答えられないかのどちらかになる。多くの agent 試験導入が本番に到達できない理由の一部も、この層の欠落にある。
だから各ベンダーの判断は正しく、しかも高度に一致している。AI が信頼できる形で企業に入っていくには、まず機械可読でガバナンスされた業務定義の層がなければならない。 この点はもはや争う必要がない。本当に争うべきは、次の問いだ――この層は誰のものか。
三つの正しい方向、三つの異なる錠
三社の方策を並べてみると、ばつの悪い共通点に出くわす。
| オントロジーはどこに置かれるか | 誰が読み解けるか | あなたは持ち出せるか | |
|---|---|---|---|
| Palantir Foundry | Palantir プラットフォーム内 | 常駐エンジニア + プラットフォームツール | プラットフォームに拘束、移行=作り直し |
| Microsoft Fabric IQ | OneLake / Fabric 内 | 365 と Fabric エコシステム | マイクロソフトのスタックに拘束 |
| Google 企業ナレッジグラフ | Google Cloud 内 | Vertex と GCP エコシステム | グーグルのスタックに拘束 |
公平に言えば、各社とも自分の縄張りの中では非常によくやっている。Palantir のオントロジーモデリングの品質は本当に高い。マイクロソフトは意味層を OneLake と 365 に溶接しており、全社員がマイクロソフトを使う会社にとっては、ほとんど摩擦のないほど滑らかだ。グーグルもデータ規模とグラフ推論において確かな実力を持つ。各社とも、あなたの業務をきれいに整理する手助けをしてくれる――そしてその整理されたものを、自社のプラットフォームの中に閉じ込める。
ベテランの IT 人がここを見れば、反射的に一言こう言うだろう。また例のベンダーロックインか、古い問題だな、と。
だが今回いちばん心配すべきはロックインではない。今回はもっと厄介な、新しい問題がある。それを解体する前に、まず閉じたプラットフォームが 勝つ ためのシナリオを真剣に語っておかなければならない――それは決して弱くないからだ。
まず、閉じたプラットフォームが勝つシナリオを語ろう
「オープンがいい」とただ叫ぶだけなら、それは布教であって分析ではない。閉じたプラットフォームの手には、四枚の本物の切り札がある。
第一に、モデリングの品質。 大企業が二十年かけて溜め込んだ腐ったシステムをかじり砕いて、きれいで自己無矛盾なオントロジーにするのは、極めて重い工程だ。Palantir は常駐エンジニアが概念を一つひとつ突き合わせていく方式で、その品質に短期的にはオープンソースコミュニティは太刀打ちできない。オントロジーというものは、下手に作るくらいなら作らないほうがましだ。
第二に、責任を負える主体がいること。 何かあれば電話に出る相手がいて、SLA があり、契約による裏付けがある。CIO にとって、「一社のベンダーが層全体の責任を肩代わりしてくれる」こと自体に価値がある――これを one throat to choke(締め上げる喉が一つ)と呼ぶ。
第三に、多くの会社は実際に「ほぼ一社に集中している」。 もしあなたの業務の 80% が一つのエコシステムの中にあるなら、「エコシステム内で最適」は文字どおりの意味であなたにとっての最適であり、オープンがもたらす利点をそもそも使う場面がない。
第四に、統合の深さ。 同じエコシステム内では、データ・ID・権限がすべて出来合いで、省ける汚れ仕事は人月単位で効いてくる。
この四枚の切り札はどれも本物だ。だから結論は「閉じたプラットフォームはすべて落とし穴だ」ではない――その前提の中にいる会社にとって、それらはしばしば正しい答えだ。問題はユアンフォンのような会社で起きる。その前提が、いま失効しつつある からだ。
今回、シナリオには新しい穴がある:分断
単一ベンダーへのロックインなら、少なくともあなたの業務定義は 完全な一つ のままで、ただ持ち出せないだけだ。痛いが、完全ではある。
三社の巨人が同時に閉じたオントロジーを作ると、生まれるのは別物だ――分断 である。ユアンフォンの「顧客」はロックされたのではなく、三つに切り分けられて、互いを認識しない三つのプラットフォームにそれぞれ横たわっている。これはロックインよりもずっと辛く、しかもその辛さには理由がある――それが自然には治らないことを保証する二層のメカニズムがあるのだ。
第一層は利害。 あなたはこう考えるかもしれない。ではマイクロソフトのオントロジーに Salesforce の「顧客」を理解させればいいのでは? それはできない。どの一社にも、それをやる動機がないからだ。各社のオントロジーは、それぞれの堀(モート)そのものだ。もしマイクロソフトが自ら進んで Salesforce との「顧客」の意味を統一すれば、それは競合のためにデータをよりスムーズに移せるよう手助けし、自らをコモディティ化することに等しい。統一という行為は、すべての参加選手にとって自傷行為だ。 これは技術的な不注意ではなく、合理的な選択だ――だから彼らのうちのどの一社かが分断を片づけてくれることを期待するのは、当てにならない。
第二層は技術。 利害を脇に置いたとしても、オントロジー間の意味のすり合わせそのものが、未解決の難問だ。A システムの「顧客」は B システムの「Account」と等しいのか? 両者のフィールドの定義、ライフサイクル、重複排除のルール、何をもって「同一エンティティ」とするか――すべてが異なる。これは AI にも信頼できる形で自動でやらせることはできない――むしろ逆で、agent はまさにこの確定した定義の層が欠けているからこそ間違うのだ。H グループに戻ろう。agent 自身に「この三つのレコードが同じ会社かどうか」を推測させれば、その推測の間違いの代償が、あの数百万になる。
ひとことにまとめると――三つのツールを買ったつもりが、実は互いを認識しない三つの「事実の源泉」を買っていた。 システムが増え、買収が増え、コンプライアンスのための隔離が増えるほど、この分断は深刻になる。そして agent の時代は、よりによってその代償を増幅した――人間の脳ならまだなんとか三つのシステムの間を手作業ですり合わせられるが、agent にはできない。agent が推論するには、確定した、システムをまたいで一貫した定義の層が必要なのだ。
分断を起こさないためには、論理的には出口は一つしかない。業務の定義は、競争に参加するどのプラットフォームにも属してはならず、中立的なものでなければならない――あなた自身が保有し、三社のツールがいずれも読みにいける一つの定義だ。閉じたプラットフォームは構造上これを提供できない。彼らは競争の選手であって、同時に審判を務めることはできないのだ。
自分が分断されつつあるかを見分ける方法
これは抽象的な話ではなく、ごく具体的な早期症状がある。以下の数項目と照らし合わせて、三つ以上当たれば、分断はもうあなたの会社で起きている。
- 同じ「顧客 / 注文 / 設備」が、システムごとに定義が異なり、突き合わせができず、レポートを作るたびに人手で寄せ集めねばならない。
- agent にシステムをまたぐ質問をさせると、曖昧にごまかすか、半分しか正しく答えない(一つのシステムは見たが、もう一つを見ていない)。
- 新しいシステムを一つ接続するたびに、AI に「これは何か、フィールドはどういう意味か」を一から教え直さなければならない。
- ある買収から一年以上が経つのに、両側のマスターデータがまだ本当には一本化されておらず、それぞれ別々に報告している。
- コンプライアンス上、ある種のデータを隔離する必要があり、その結果、同一のエンティティが複数の場所に保存され、互いを認識しなくなっている。
ユアンフォンは H グループを失う前、この五項目のうち四つに当たっていた。当時それらはすべて「データガバナンスのやるべきこと」として扱われ、それが実は agent が遅かれ早かれ踏み抜く地雷だと気づいた者はいなかった。
まず冷や水を:オープンは銀の弾丸ではない
ここで正直に立ち止まらなければならない。さもないと、これは膏薬売りになってしまう。
第一に、定義をオープンプロトコルに置き換えたところで、ユアンフォンのあの三つの「顧客」が自動的に一つに統合されるわけではない。 やるべき意味モデリング、重複排除、定義の整合は、変わらずやらなければならない――この部分に銀の弾丸はなく、それを吹聴する者は誰であれ信じてはいけない。オープンが本当に変えるのは、この骨の折れる作業の 帰属 だ。今日あなたが力を尽くして整合させた定義は、あなた自身のリポジトリの中に書かれていて、どこかのプラットフォームの裏側に沈殿しているのではない。来年あなたがモデルを替え、クラウドを替え、買収されたとしても、作り直すのは接続であって、定義そのものではない。
第二に、「オープン」であること自体が勝利を保証するわけでもない。 歴史上、オープンな標準が本当に勝ち抜くには、しばしば十分に優れた参照実装と、活発なエコシステムがさらに必要だった――プロトコルを公開しただけで、誰もそれを使いやすく作り上げなければ、やはり廃れる。だからオープンを選ぶことは「誰かがそれを堅実に作り上げてくれる」ほうに賭けることであり、これは実行リスクのある判断であって、確実な勝ちではない。
だがこの二杯の冷や水の重みに注意してほしい。これらが言っているのは「オープンも労力がかかるし、リスクもある」であって、「閉じたほうがいい」ではない。これと比べれば、業務定義を一社のプラットフォームに閉じ込めることのダウンサイドのリスク――つまりユアンフォンのような分断――のほうがはるかに大きく、しかも逆転がはるかに難しい。どちらも無料ではない。ただし片方は、最も核心的な資産を、あなた自身の手の中に握っている。
皆に依存される層は、最後には中立になる
この法則そのものは新しくないが、新しい例で語る価値がある。それが繰り返し起きているからだ。
エコシステム全体に共通して依存される「定義層」は、最終的にはすべて中立へと向かう。最も古い例は SQL だ。データベースベンダーは血みどろの市場で殺し合ったが、クエリ言語そのものは公共のものだ。より新しく、より問題を物語るのはこの二つだ。OpenTelemetry――可観測性領域のデータ定義で、各社の監視ベンダーが接続しに来て、中立の CNCF がホストし、誰も独占できない。そして LSP(Language Server Protocol)――マイクロソフト自身が立ち上げたものなのに、まさにオープンであったからこそ、すべてのエディタに採用され、事実上の標準になった。
LSP のこの例はとりわけ味わい深い。マイクロソフトが 自らの手で 証明したことだからだ――定義層をオープンにして、自分は最良の実装で稼ぐほうが、それを錠で閉ざすよりも勝てる。ビジネス意味層は同じ類いのものだ――それは将来、あなたのアプリ、あなたの agent、あなたの監査システム、加えて三社のツールに 同時に 依存されることになる。これほど多くの当事者に依存される層が、論理的に、長期にわたってそのうちの一方の私有物であり続けられるはずがない。中立になるか、さもなければユアンフォンのような分断を生み続けるかのどちらかだ。
中立なその層は、どんな見た目をしているか
ここまで長く語ってきたが、実物を一目見てみよう。重要なのは構文ではなく、それが どこにあるか、持ち出せるか、分断を取り戻せるか だ。
仮にユアンフォンが最初から「顧客」を一つの中立的な定義として作っていたなら、三つのシステムをそれぞれデータソースとして接続し、各々をオブジェクトとしてモデル化したうえで、共通のキー(法人番号)によって、権限と監査を備えた一つの「顧客」へと揃えられる。
export const Customer = ObjectSchema.create({
name: 'crm_customer',
label: '顧客',
fields: {
name: Field.text({ label: '顧客名', required: true }),
tax_id: Field.text({ label: '法人番号' }), // システムをまたいで「同一の顧客」を揃えるための共通キー
},
});この定義はあなたの Git リポジトリの中にあり、diff が取れ、レビューでき、移行できる。それが次にできること――それこそが肝心だ。「持ち出せる」を、約束ではなく、実演できる動作に変える。
git add crm/*.ts # 定義があなたのバージョン管理に入り、監査でき、ロールバックできる
os start # 同じ定義を、あなた自身のインフラ上で動かす
# あとは任意のモデルをそこに向ければいい――Claude、GPT、Gemini、どれでも、ランタイムは変わらないさて、あの致命的な問いをもう一度。「H グループの来年の解約リスクはどれくらい高い?」agent が向き合うのは、一つの 統一された、権限と監査を備えた「顧客」だ。受注は健全だが、二度の経営層レベルの苦情と、90 日の回収トラブルが重なっている――agent は答える。「高リスク、早めの介入を推奨します」。同じモデル、同じ問いなのに、足元の定義がもはや分断していないというだけで、結論は「数百万を失った」から「一四半期前倒しの警告」へと変わった。
これが ObjectStack と ObjectOS の役割分担であり、この競争に対するその答えでもある。
- ObjectStack――業務を記述するオープンプロトコル(Apache 2.0)。あなたのリポジトリの中にあり、三社の agent がいずれも読める。
- ObjectOS――この定義のランタイム。あなた自身のインフラ上で動き、権限を強制し、監査を記録する。
定義層は中立、実行層は商売。SQL とデータベースベンダー、LSP とエディタベンダーの関係と、同じ種類のものだ。
結び
これは「オープンがいいか閉じたほうがいいか」というイデオロギーの問題ではない。もっと冷静な算術の問題だ。あなたのベンダーの組み合わせは遅かれ早かれ変わる――マルチモデル、マルチクラウド、買収、コンプライアンスのための隔離、必ず変わる――その瞬間、あなたの業務の定義を、誰が手の中に握っているのか?
三巨頭は真金白銀をもって、この層が作る価値のあるものだと業界に証明した。だが彼らは同時に、この算術の問題をすべての企業の目の前に突きつけた。ユアンフォンのあの三つの「顧客」は技術事故ではなく、定義を手放したことの必然的な代償だ。そして「低リスク」と誤判定された H グループは、最初の一枚の請求書にすぎない。
皆に依存される層が、歴史上一度も長く一社のものであったことはない。今回も、違う理由はない。
npm i -g @objectstack/cli && os start最初のビジネスオブジェクトを定義し、そのデータをあなたの既存の二つのシステムから来させて、それを自分のリポジトリに git commit する――その瞬間、業務の定義はあなたの手に戻る。どこかの一社の裏側にではなく。