企業 AI Ontology：業務意味層をオープンプロトコルにすべき理由
AI が企業に入るには、ガバナンスされた業務意味層が必要だ。重要なのは、その定義をオープンでレビュー可能、移行可能にし、実行責任はランタイムが担うことだ。
結論から言うと： Palantir は、AI が企業に入るにはガバナンスの効いたビジネス意味層が必要だと証明した——だがその層は、閉じたプラットフォームに囲い込むのではなく、Linux のように自社が所有するオープンプロトコルであるべきだ。定義の層はオープンにし、ランタイムで対価を取る。
まず、あなたもおそらく目撃したことのあるプロセスから始めましょう。
ある企業が「AI アシスタント」プロジェクトを立ち上げます。1 週目、デモは衝撃的でした。顧客データをエクスポートしてモデルに渡すと、「東日本エリアで更新リスクの高い顧客はどこか」に本当に答えられるのです。経営陣はその場でパイロット拡大を決定します。
3 か月目、本番データへの接続が必要になり、セキュリティチームが入ってきて、3 つの質問をします。
- AI はどのデータを見られるのか？営業 A が「全社の業績ランキング」を聞いたら、他人のインセンティブまで答えてしまわないか？
- AI がアクションを実行する——値引きの変更、契約書の送付——のなら、誰の権限で動くのか？問題が起きたら誰の責任か？
- 監査が「この値引きは誰が承認したのか」を調べるとき、AI が関与した部分の記録はどこにあるのか？
プロジェクトチームは答えられません。怠慢ではなく、アーキテクチャの中に、これらの質問に答えられる層がそもそも存在しないのです。データは十数個のシステムに散らばり、権限は各アプリのコードの中に書かれ、「値引き承認」のルールはベテラン社員の頭の中にしかない。AI が向き合っているのは生のテーブルと生の API であり、どれほど賢くても、どこにも書かれていない企業のルールを読み取ることはできません。
9 か月目、パイロットは静かに終わります。モデルは能力で負けたのではありません。誰もサインしてくれなかったから負けたのです。
業界には、ここで欠けていたものの名前があります。Ontology（ビジネスオントロジー）——どんなビジネスオブジェクトが存在し、互いにどう関係し、誰が何をしてよく、実行されたことがどこに記録されるのかを、構造化された機械可読な形で明示的に定義する意味層です。
Palantir が正しかったこと
Ontology を研究上の概念から商業的事実に変えたのは Palantir です。なぜ成功したのかを公平に見ておく価値があります——公平に見るほど、次の問いが鮮明になるからです。
Palantir Foundry の核心は 2 つの動作です。第一に、企業中に散らばったデータを統一されたオントロジー層に統合すること。顧客・設備・注文は何十ものテーブルではなく、型と関係と属性を持つビジネスオブジェクトになります。第二に、すべての書き込み操作をガバナンスの効いた Actions に収斂させること。各アクションは検証され、権限が確認され、完全に監査されます。2023 年以降の AIP は、このアーキテクチャを大規模言語モデルに直接向けました。**LLM はデータベースに触れない。オントロジー層が公開するガバナンス済みツールしか呼べない。**モデルは交換可能で、境界は動きません。
なぜ高価なのか？解決している問題が本当に高価だからです。大企業が 20 年かけて溜め込んだレガシーシステムを 1 つのきれいなオントロジーに整理するには、Palantir の常駐エンジニア（Forward Deployed Engineer）がシステムを 1 つずつ紐解き、概念を 1 つずつ突き合わせる必要があります——文字通りの労働集約型エンジニアリングです。顧客は政府、防衛、金融、エネルギー。「AI のすべてのステップが権限の範囲内で、すべて記録される」ことが絶対要件であり、予算もそれに見合う顧客です。契約は数百万ドルからですが、更新され続けます。CISO が最も気にする 3 つの質問——冒頭のあの 3 つ——に本当に答えているからです。
つまり Palantir がはっきり示したのは営業力だけではなく、1 つのアーキテクチャ上の判断です。**AI が企業に入るには、ガバナンスの効いたビジネス意味層が先に存在しなければならない。**この判断にもう論証は要りません。
考え直すべきは次の問いです。この層は、どんな形態で存在すべきか？いくつかのことが変わりつつあるからです。
ソフトウェアは AI が書くものになりつつある
1 つ目の変化は最も目に見えるものです。アプリケーション自体が、ますます AI によって書かれるようになっています。
「50 人のチームのために経費承認システムをカスタム開発する」は、かつて経済的に成立しませんでした——開発費が痛みを上回るからです。今は AI agent が午後のうちに納品します。カスタム業務ソフトウェアは希少品から日用品になりつつあり、総需要は爆発的に増えます。
その爆発がどこで起きるかに注目してください。ロングテールです。どのエンタープライズベンダーの見込み客リストにも決して載らないチーム——調達プロセスも、導入予算も、POC 審査会議もないチーム——で起きます。彼らはただ agent に「動くものを作って」と言い、その日のうちに使い始めます。
常駐エンジニアと数百万ドルの契約で回るモデルは、構造的にこの市場に届きません。批判ではなく、単に 2 つの異なる市場だという話です。しかしこの新しい市場のすべてのシステムが、冒頭のあの 3 つのセキュリティの質問に同じように衝突します——ただし衝突したとき、隣に常駐エンジニアはいません。
次に技術選定をするのは agent だ
2 つ目の変化はより静かで、より深いものです。技術を選ぶという行為そのものが、人間から AI へ移りつつあります。
今日、agent に「顧客管理システムを作って」と頼めば、高い確率で Next.js と Postgres を選びます。なぜか？誰かが agent の頭の中に広告を出したからではありません。これらの技術がオープンで、ドキュメントが揃っていて、訓練データの中に大量に存在するからです。agent は何十万もの使用例を見ており、どこに落とし穴があるかを知っています。
これは以前には存在しなかった事態を生みます。開発者向け技術にとって、公開されたプロトコルのテキストとオープンソースコードが、流通チャネルそのものになったのです。プロトコルがオープンであるほど、議論が増え、学べるコードが増え、次世代モデルの理解が深まり、agent はそれをデフォルトで選ぶようになる——自己強化するループです。
閉じたプラットフォームはこのループに入れません。そのオントロジーの記法も、アクションの意味論も、権限モデルも、ドキュメントの壁と契約の向こう側にあります。モデルは学習できず、agent はセルフサービスで使い始めることもできません。調達プロセスには選ばれても、agent には選ばれない。ソフトウェアの多くが agent によって書かれるようになるとき、これはもうマーケティングの問題ではありません。チャネルからの不在です。
待って——閉じたプラットフォームが勝った例もあるのでは？
ここまで来ると、賢い反論が出てくるはずです。オープンが常に勝つわけではない。クラウド時代に勝ったのは AWS で、モバイルで勝ったのは iPhone。どちらも閉じている。
この反論は真剣に受け止める価値があります。受け止めきると、本当のパターンが見えてくるからです。
AWS がどうやって稼いでいるかを見てください。ホストしているのは Linux、Kubernetes、Postgres——どこまでもオープンスタンダードです。iPhone は閉じていますが、流れるパケットはすべて TCP/IP と HTTP の上を走ります。さらに遡れば、データベースベンダーは血みどろの競争をしながら、SQL という言語自体は公共のものであり続けました。コンテナオーケストレーション戦争は、全員が同じオープンな OCI イメージフォーマットの上で走る形で終わりました。
パターンは驚くほど一貫しています。**エコシステム全体が依存する「定義層」は最終的にオープンになる——誰も自分の資産を単一ベンダーの文法の上に築こうとはしないからです。一方「実行層」は閉じたまま対価を取れる——実行には継続的な運用、性能、責任が伴い、それは実在する継続コストだからです。**AWS 自身が最大の証拠です。定義はコミュニティのもの、実行がビジネス。
ビジネス意味層は典型的な定義層です。あなたのオブジェクトモデル、権限ルール、承認フローは、これからあなたのアプリケーションに、agent に、監査システムに依存されていきます。依存するものが増えるほど、それは一社のプラットフォームのデータベースの中ではなく、あなた自身のリポジトリの中の、読める・バージョン管理できる・持ち運べるファイルであるべきです。
企業は 20 年かけてデータを閉じたシステムから解放してきました。AI の時代に、データよりさらに根源的な資産——ビジネスの定義そのもの——を、もう一度閉じ込めるべきではありません。
この「定義」は実際どんな姿か
抽象論はここまで。ObjectStack プロトコルにおける商談オブジェクトの定義を見てください（実際のサンプルからの抜粋です）。
export const Opportunity = ObjectSchema.create({
name: 'crm_opportunity',
label: '商談',
fields: {
name: Field.text({ label: '商談名', required: true }),
account: Field.lookup('crm_account', { label: '取引先', required: true }),
amount: Field.currency({ label: '金額', min: 0 }),
probability: Field.percent({ label: '受注確度', defaultValue: 50 }),
expected_revenue: Field.formula({
label: '期待収益',
expression: cel`amount * probability / 100`,
}),
discount_percent: Field.percent({ label: '値引き率', max: 100 }),
},
});
// 権限も同じく宣言的：営業は読み書きできるが、削除はできない
export const SalesUser: Security.PermissionSet = {
name: 'crm_sales_user',
objects: {
crm_opportunity: { allowRead: true, allowCreate: true, allowEdit: true, allowDelete: false },
},
};重要なのは構文ではありません。この数十行がシステムそのものであることです。ランタイム（ObjectOS）がこの定義を読み込み、データベーステーブル、REST API、管理画面、そして——AI agent が直接呼び出せるガバナンス済みツールを自動生成します。30% を超える値引きには財務承認が必要？それはこのオブジェクトに紐づくフロー定義であり、同じく宣言的で、同じくバージョン管理されています。
ここから 3 つの帰結が直接導かれます。
- **冒頭の 3 つのセキュリティの質問に、構造的な答えができる。**AI は何を見られるか——権限セットに書いてある。どの権限で動くか——ログインユーザーとして行動し、ランタイムが強制する。プロンプトでお願いするのではない。監査記録はどこか——人間と agent はすべての読み書きを同じ台帳に記録する。誰が、何を、いつ、なぜ。コンプライアンスが見る台帳は 1 冊だけです。
- **業務変更がコードレビューになる。**AI がシステムに「更新リマインダー」を追加したい？提出されるのはメタデータの diff です。どのフィールドが変わり、どの権限が動いたか、一目で分かります。定義はバージョン管理されているので、間違いはロールバックできます。
- **システム全体が 1 つの agent のコンテキストウィンドウに収まる。**典型的なエンタープライズモジュールは、数万行の CRUD とグルーコードから数百行の宣言に収斂します——AI がすべての依存関係を端から端まで読み切り、データ・API・画面・権限を横断する安全なリファクタリングを一度の変更でやり切れる大きさです。これが「共同メンテナーとしての AI」と「補完ツールとしての AI」の分水嶺です。
プロトコルはコミュニティへ、ランタイムはビジネスへ
ここで議論全体が閉じます。
Ontology という判断は正しい——Palantir が業界全体のために証明済みです。しかし「定義はオープン、実行は有償」のパターンに従えば、AI 時代におけるこの層の健全な形態はこうなります。ビジネス意味プロトコルは Linux のようにオープンエコシステムに属し、ガバナンスを効かせたランタイムがそれをあなた自身の環境で実行する。
これがまさに ObjectStack と ObjectOS の分業です。
- ObjectStack は業務アプリケーションを記述するオープンプロトコル（Apache 2.0）です。オブジェクト、関係、権限、フロー、API、UI、AI ツールを一度だけ定義します。それはあなたのリポジトリの中にあり、diff でき、移行でき、どんな agent でも読める——だからこそ公開インターネット上に存在し、将来のあらゆるモデルの訓練データの中に存在します。
- ObjectOS はそれらの定義のランタイムです。あなたのサーバー上で、あなたのデータベースに対してすべてを実行し、実行時に権限を強制し、監査ログを書き込みます。ガバナンスはプロンプトにではなく、実行エンジンに書かれています。
片側には、どんなチームでも、どんな agent でも、今日から使えて、読めて、持ち出せるプロトコル。もう片側には、企業が本当に対価を払うもの——ホスティング、コンプライアンス、マルチ環境のリリース、運用に責任を持つ誰か。定義はあなたのもの。それを動かす面倒は、私たちのビジネスです。
おわりに
9 か月目に死んだあの AI パイロットは、モデルの能力に負けたのではありません。セキュリティチームがサインできる意味層が存在しなかったことに負けたのです。業界で最も高価な会社が、この層の価値を 10 年かけて証明しました。次の仕事は、それが大企業だけの贅沢品でなくなるようにすることです。
本当かどうか確かめたければ：
npm i -g @objectstack/cli && os start5 分後、最初のビジネスオブジェクトを定義してください。それがデータベーステーブルになり、API になり、管理画面になり、AI が安全に呼び出せるツールになるのを見られます——すべての呼び出しが権限を伴い、台帳に記録されながら。