オントロジー

実務では

オントロジーがソフトウェアである。ObjectStack において、オントロジーはホスト型プラットフォーム内部の一層ではない。それはアプリケーション自身の定義——オブジェクトとフィールド、リレーション、アクション、権限、フロー、エージェントとツールの定義——であり、ランタイムがそれを実行する。データベース、REST API、画面、MCP ツールはすべてそこから導出され、権限と監査はあらゆる呼び出しで強制される。この言葉には四つの境界が伴う。第一に、これは実行可能なものであって、知識表現としてのオントロジーではない。継承も公理も推論器もなく、定義は検証され、そして実行される。第二に、既存システムの上にかぶせるセマンティックレイヤーではない。それ自体がシステムであり、外部データソースのフェデレーションはデフォルトで読み取り専用、しかもまだ初期段階にある。第三に、ビュー、ダッシュボード、アプリ、翻訳はオントロジーの投影であって、その一部ではない。そして第四に、コードは消えない。フック、アクション本体、CEL、制約付き JSX としてランタイムの中へ移るのである。

この言葉は哲学に由来し、知識工学を経てエンタープライズソフトウェアに入ってきた。知識工学では、ソフトウェアが推論できるようにドメインを形式的にモデル化したもの——クラス、プロパティ、関係——を指す。実務上の意味は狭く、かつ有用だ。オントロジーは型（顧客、作業指示、デバイス）と、各型が持つプロパティと、型同士のつながりを、組織全体に対して一度だけ命名する。これがデータベーススキーマとの違いである。スキーマは一つのアプリケーションが自分の行をどう保存するかを記述する。オントロジーは、このビジネスが「顧客」と言うとき何を意味するのかを、十数個のシステムやレポーティングツール、そしてモデルがすべて同じように解決できる形で記述する。2026 年に多くの人が思い浮かべるのは Palantir Foundry であり、そのモデリングの質は本当に高い。Microsoft Fabric IQ や Google のエンタープライズナレッジグラフも同じレイヤーに進出しつつある。

ほとんどのオントロジーの取り組みは、リスクが始まる場所の一歩手前で止まっている。検索用途のオントロジーは読み取りモデルだ。エージェントがビジネスについて的確に語れるようにはなるが、エージェントが何かを変更しなければならないときに何が起きるかについては何も語らない。それを完成させる能力は、宣言され、権限チェックを受ける書き込み操作——アクション——と、同じ定義に付随する権限と監査のルールである。書き込みを統制されたアクションに集約してきた Palantir の長年の取り組みは評価されるべきだ。問われてきたのは、その設計が正しいかどうかでは決してない。

問われているのは、そのファイルを誰が持っているかだ。ObjectStack では、定義そのものがあなたのビジネスオントロジーである。オープンで、バージョン管理され、あなたのものとしてあなた自身のリポジトリにある。フレームワークのあちこちに散らばったコードでも、ベンダーのシステム内に保持されたグラフでもない。読めて、diff が取れて、別のホストへ移せる定義は、同じくらい優れていてもベンダーのエンジンの中に住み、移行には作り直しが必要な定義とは、別の資産である。オントロジーが AI エージェントを正しくしてくれるわけではない。ビジネスをうまくモデル化することは、今も時間がかかり、意見の割れる人間の仕事であり、どんなフォーマットも近道にはならない。フォーマットが決められることはもっと狭い。その結果が、エージェントが丸ごと保持できるほど小さいか、エージェントの誤りを記述時点で拒否できるほど厳密か、そして最初に書かれたプラットフォームより長く生き残れるほどポータブルか、である。