企業 AI Ontology：業務定義とランタイムをともにオープンにすべき理由

結論から言うと： Palantir は、AI が企業に入るにはガバナンスの効いたビジネス意味層が必要だと証明した——だが必要なのは、単一ベンダーのエンジンに依存する「オープンなファイル」ではなく、自社が所有するオープンな型付きアプリ定義と可搬なオープンソースランタイムです。定義と実行基盤を開き、その周囲の本番運用体験で対価を得るべきです。

まず、あなたもおそらく目撃したことのあるプロセスから始めましょう。

ある企業が「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 自身が最大の証拠です。Linux、Kubernetes、Postgres はオープンなまま、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 },
  },
};

重要なのは構文ではありません。この数十行がシステムそのものであることです。オープンソースの ObjectStack ランタイムがこの定義を読み、データベーステーブル、REST API、管理画面、MCP ツールを導出し、権限と監査を強制します。30% を超える値引きには財務承認が必要？それはこのオブジェクトに紐づくフロー定義であり、同じく宣言的で、同じくバージョン管理されています。ObjectOS は同じアプリの周囲に、ブラウザ内 Build／Ask、チームレビューと承認、マネージドクラウドまたはプライベート展開、SSO、運用、サポートという商用の本番体験を加えますが、定義や実行エンジンを専有依存には戻しません。

1 つのメタデータ定義が、API・画面・AI ツール・権限と監査として同時に効力を持つ

ここから 3 つの帰結が直接導かれます。

**冒頭の 3 つのセキュリティの質問に、構造的な答えができる。**AI は何を見られるか——権限セットに書いてある。どの権限で動くか——ログインユーザーとして行動し、ObjectStack ランタイムが強制する。プロンプトでお願いするのではない。監査記録はどこか——人間と agent はすべての読み書きを同じ台帳に記録する。誰が、何を、いつ、なぜ。コンプライアンスが見る台帳は 1 冊だけです。
**業務変更がコードレビューになる。**AI がシステムに「更新リマインダー」を追加したい？提出されるのはメタデータの diff です。どのフィールドが変わり、どの権限が動いたか、一目で分かります。定義はバージョン管理されているので、間違いはロールバックできます。
**システム全体が 1 つの agent のコンテキストウィンドウに収まる。**典型的なエンタープライズモジュールは、数万行の CRUD とグルーコードから数百行の宣言に収斂します——AI がすべての依存関係を端から端まで読み切り、データ・API・画面・権限を横断する安全なリファクタリングを一度の変更でやり切れる大きさです。これが「共同メンテナーとしての AI」と「補完ツールとしての AI」の分水嶺です。

定義と可搬なランタイムはコミュニティへ、本番運用はビジネスへ

ここで議論全体が閉じます。

Ontology という判断は正しい——Palantir が業界全体のために証明済みです。しかし AI 時代の健全な形は「定義だけ開き、専有エンジンで課金する」ことではありません。型付きの業務定義と可搬なガバナンスランタイムをオープンエコシステムに置き、その周囲の本番運用体験を有償にすることです。

これがまさに ObjectStack と ObjectOS の分業です。

ObjectStack はオープンな型付きアプリ定義とオープンソースランタイム（Apache 2.0）です。オブジェクト、関係、権限、フロー、API、UI、AI ツールをリポジトリで一度だけ定義し、ランタイムがデータベース、REST API、画面、MCP サーバーを導出して、すべての呼び出しで権限と監査を強制します。定義もエンジンも diff、セルフホスト、移行が可能です。
ObjectOS は同じ ObjectStack アプリを囲む商用プロダクションプラットフォームです。ブラウザ内 Build／Ask、チームレビューと承認、マネージドクラウドまたはプライベート展開の運用、SSO、企業向け制御、サポートを提供します。Ontology を再び囲い込む閉じた実行エンジンではありません。

片側には、どんなチームや agent でも理解し、セルフホストし、持ち出せるアプリ定義と可搬なランタイム。もう片側には、企業が本当に対価を払う本番体験——共同編集、承認、ホスティング、プライベート展開、SSO、サポート、アップグレード、運用責任があります。アプリと基礎ランタイムはあなたのもの。チームのために確実に運用することがビジネスです。

おわりに

9 か月目に死んだあの AI パイロットは、モデルの能力に負けたのではありません。セキュリティチームがサインできる意味層が存在しなかったことに負けたのです。業界で最も高価な会社が、この層の価値を 10 年かけて証明しました。次の仕事は、それが大企業だけの贅沢品でなくなるようにすることです。

本当かどうか確かめたければ：

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

5 分後、最初のビジネスオブジェクトを定義してください。オープンな ObjectStack ランタイムがそれをデータベーステーブル、API、管理画面、AI が安全に呼び出せるツールへ変えます。すべての呼び出しが権限を伴い、台帳に記録されます。チームがブラウザ内 Build／Ask、共有レビューと承認、マネージドクラウドまたはプライベート展開、SSO、サポートを必要とするなら、ObjectOS が運用するのは同じ ObjectStack アプリです。専有形式や独占エンジンに置き換えることはありません。