Palantirの「オントロジー」は、標準技術で再現できるか
連載「AIエージェント時代のオントロジー」第1回
Palantirの決算や株価の話題とセットで、必ず出てくる言葉があります。「強さの秘密はオントロジーにある」。同社のFoundryというプラットフォームの中核機能で、顧客企業のデータを業務の言葉のまま意味づけする層のことです。
ところで、この「オントロジー」、聞き慣れない独自技術のように語られがちですが——思想そのものは30年前から存在する、枯れた標準技術です。W3C標準の組み合わせで、その中核は今日でも再現できます。
この記事では、Palantirのオントロジーの正体を分解し、「どこまでが既存の標準で組めて、彼らは何を売っているのか」をエンジニア目線で見取り図にします。でも、いきなりオントロジーについてお話しても哲学とエンジニアリングの大きな壁を一朝一夕で理解することはなかなか難しい。そこで、現実にある情報の感覚を延長させならが、オントロジーについて身近にしてきましょう。
Palantirのオントロジーとは何か
Foundryのオントロジーは、ざっくり3つの部品でできています。
Object Type:「顧客」「機体」「契約」のような、業務に登場するモノの型
Link Type:「顧客が機体を所有する」のような、モノとモノの関係
Action Type:「担当者をアサインする」のような、モノに対する操作の定義
そして近年はAIP(AIプラットフォーム)経由で、この層をLLMエージェントの「接地面」として使っています。エージェントが幻覚で架空の顧客を語らないのは、オントロジーが「この会社に実在するモノと関係」を供給しているからです。
前半2つは、30年モノの標準技術
Object TypeとLink Type。これは知識工学の世界で1993年に定義が与えられた「オントロジー」——共有された概念化の、明示的な仕様——そのものです。
しかも記述のための標準規格が揃っています。モノをグローバルなIDで指すRDF、クラスと関係の意味を定義するOWL、問い合わせるSPARQL。すべてW3C標準で、無償のツールチェーン(Fuseki、Protégéなど)で今日から使えます。医療のSNOMED CT、金融のFIBO、そしてGoogleの検索を支えるKnowledge Graph。世界はとっくにこの技術で回っています。
つまりPalantirの独自性は、ここにはありません。
本丸は3つ目 ――「操作」までオントロジーに含めたこと
面白いのはAction Typeです。従来のオントロジーが世界を「読む」ための記述に徹していたのに対し、Palantirは「書く」——業務操作とその履歴——までオントロジーの一部にしました。彼らはこれをkinetic(動的)な層と呼びます。
操作が意味論を持つと、何が起きるか。AIエージェントが「何ができて、どんな条件が要り、実行すると何が起きるか」を、データと同じ方法で理解できます。そして実行の一つひとつが「誰が・いつ・何を根拠に」という監査可能な履歴として蓄積される。エージェントに業務を任せる時代の要件が、ここに揃っています。
では、この操作レイヤは独自技術でしか作れないのか。
標準技術でのレシピ ――宣言・検証・実行・記録
結論:組めます
。設計はこうです(図)。
いまの時点ではこれから説明する用語はまだ分からくて大丈夫です。最終的にはこのレシピを実現できるようにする。それが今回の連載の最終目標ですから。
定義 = RDF/OWL:操作の型(AssignTechnician等)を、対象・パラメータ・効果ごとオントロジー内にトリプルで宣言する。schema.orgのAction語彙という前例もあります
検証 = SHACL:「アサインは有効な保守契約下の機体のみ」という事前条件を、コードのif文ではなく宣言的なシェイプとして書く。実行したい操作をまず「提案」として小さなグラフに書き、この門番を通す
実行 = MCP + SPARQL UPDATE:検証を通った提案だけが、AIエージェントの標準プロトコルであるMCPツール経由で実行され、効果がグラフに書き込まれる。ツール自体をAction定義から動的生成できるのが美しいところで、新しい操作の追加は「コードを書く」ではなく「Turtleを1ブロック足す」になります
記録 = PROV-O:来歴のW3C標準語彙。「このアサインは、AIエージェントが山田さんの承認のもと、6月20日に実行した」がトリプルとして残り、監査はただのSPARQLクエリになります
この設計の隠れたメリットを一つだけあげておきます。
事前条件が宣言的だと、拒否までもが説明可能になります。契約が失効していれば、SHACLのエラーメッセージ(「対象機体に有効な保守契約がありません」)がエージェントに返り、エージェントはそれを人間の言葉でユーザーに説明できる。ガードレールがブラックボックスにならないのです。
このレシピをざっくりと見て、いまは、まあ、そんなものか程度に思ってください。
では、Palantirは何を売っているのか
公平に言います。標準技術で賄えないものが3つあります。トランザクション(検証と書き込みの競合制御)、認可(誰がどの操作を呼べるか)、外部システムへの副作用。これらは自前のサーバー実装が引き受ける責務です。
そしてPalantirが売っているのは、まさにそこです。UI、権限管理、データパイプライン、運用。それが一体化した強固なシステムとして実現している——思想は標準で再現できる。買っているのは、統合と運用の完成度。それが分かった上でなら、「高いが速い」を買うのも「安いが自分で組む」を選ぶのも、どちらも健全な判断です。つまり、オントロジーを理解することで選択の自由が得られるというわけです。
なぜ今、この話をするのか
で、この第一回目で一番言いたいこと。それは、LLMがどれだけ賢くなっても、変わらない事実が一つあります。LLMは世界を知っていても、あなたの組織を知らない。「当社の『顧客』の定義」「この契約の今の状態」は、誰かが明示化しない限り、この世のどこにも存在しません。
この組織しか存在しないものを概念・存在論=オントロジーとして扱うこと。それは計り知れない価値です。つまり、Palantirの驚異的な時価総額は、この「組織固有の概念化」という資産の市場価値を示す、一つの証拠だと私は見ています。そしてその資産は、標準技術と設計の作法さえ知っていれば、自分たちの手で作れる。 というわけです。
この連載では、その作法を基礎から解説していきます。次回は「RAGはどこで力尽きるか——GraphRAGが解いた3つの弱点」。LLM開発者が今まさに踏んでいる壁の話から始めます。
感想・リクエストは #AI時代のオントロジー でぜひ。マガジンをフォローすると毎週火曜の更新が届きます。
#オントロジー #ナレッジグラフ #LLM #AI #AI時代のオントロジー
