Palantir Ontology 実導入の現実 — 「操作まで契約化」の代償（泥・ロックイン・常駐依存）¶

作成日: 2026-07-24 出典 / きっかけ: Palantir Foundry Ontology の批判・レビュー各種（badalaiworld/Towards AI「How It Works … Where It Falls Short」、Lokad レビュー総合4.7/10、TrustRadius/PeerSpot 価格）。概念の完成形（palantir_foundry_ontology_ビジネスのai化基盤_整理）に対し「実装の泥」を裏取り関連: palantir_foundry_ontology_ビジネスのai化基盤_整理 palantir_fdse_forward_deployed_engineer_整理 aiエージェント時代のデータ基盤論争_意味層は要るか_整理 sansan_corporate_databridge_情シス内製データ連携基盤_整理

0. 要点（3行）¶

Ontology の強さ（意味＋操作＋ガバナンスを1つに契約化）は、そのまま重さでもある。組織全体のデータ・プロセス・モデルを表すオントロジーの構築と継続保守は極めて複雑で、事業が変わるたびに更新が要る → 常駐専門家（FDSE）への恒久依存が Palantir のビジネスモデルの実体
ベンダーロックインが構造的: Foundry は W3C 標準を使わず独自表現。オントロジーを OWL としてエクスポートできず、他基盤への移行は極めて高コスト（高いネットリテンションはこの構造的依存の裏返し）
技術的限界も明確: OWL 的な論理推論をしない（関係は明示モデル必須・自動推論なし）。価格は Compute/Storage/Ontology の3軸従量で不透明。一方で「エンジニア・支援・他ツールを退役させる前提の Activity-Based Costing なら割安」という擁護もあり、TCO は立場で割れる

1. 「操作まで契約化」の代償＝オントロジー保守コスト¶

概要ノートで見た通り Ontology は意味層（Object/Property/Link）＋キネティック層（Action/Function）を1つにする。この完成度が価値だが、その形を作り・保つ工数が本体コスト
オントロジーは「組織全体のデータ・プロセス・モデルを正確に表す」もの → 事業の変化に合わせて継続更新が必要。静的な設定でなく生き物
だから Palantir のモデルはコンサルティング集約的（palantir_fdse_forward_deployed_engineer_整理の FDSE が顧客常駐でこれを担う）。「製品を買えば終わり」ではなく、オントロジーを耕し続ける人への恒久投資が要る
Lokad の評価: 「実装方法の透明性 5/10」「成功に必要な真の顧客依存度が不透明」— カスタマイズ依存が高く、どれだけ人手が要るか事前に見えにくい

2. ベンダーロックイン（構造的）¶

Foundry は独自表現でオントロジーを持ち、W3C/OWL 標準を使わない → OWL ファイルとしてエクスポートして他基盤で推論、ができない
一度、業務ロジック・意味モデル・運用ワークフローを Foundry に載せると、移行は極めて高コスト。「プラットフォームが非常に強い重力中心になる」（Lokad）
高いネットリテンション（134% と紹介される）は「満足」だけでなく構造的に抜けにくいことの表れでもある、という読み

3. 技術的限界¶

OWL 的論理推論をしない: 関係は明示的にモデル化しないと使えず、プラットフォームが自動で関係を推論してくれるわけではない。「知識グラフ」と呼ぶが、記述論理の reasoner ではない
クロスエージェントの意味検証層が未成熟: 外部 AI エージェントとの統合で「cross-agent coordination の semantic validation layer はまだ存在しない」
供給チェーン等ドメイン特化の定量差別化は弱い（Lokad: 「決定を取り巻く環境であって、最適化の透明なエンジンではない」総合4.7/10）

4. コスト（TCO は立場で割れる）¶

価格は Compute / Storage / Ontology の3軸従量＋不透明さの指摘。プレミアム価格・ロールアウトの複雑さへの反発は実在
反対の擁護（Dorian Smiley 等）: Activity-Based Costing で、退役できるエンジニア工数・サポート・他ツールを織り込むと Foundry はしばしば割安。単純な compute/storage 比較では高く見えるだけ
市場: データ統合カテゴリの mindshare は 2026 時点で 2.1%（前年 3.2% から低下）。買い手はモジュラー・短い time-to-value・可搬性・説明可能性を重視する方向 → Palantir の「重い一枚岩」と逆風の面

5. 考察（自分の解釈）¶

一言でいうと「完成度と重さは同じコインの裏表」。Ontology が enforced（意味も操作も権限も強制）だからこそ強く、その強制を成立させるオントロジー構築・保守が重く・抜けにくく・人依存になる。概念の美しさと実装の泥は分離できない
これが今週の他社が内製で Palantir 型に行かなかった理由を説明する: Sansan は読み取り契約だけ（書き込み＝操作は正本に残す）、カンム/メルカリは意味層すら enforced にしない。「完成形の重さ」を避けて、買えるランウェイ（作り直せる軽さ・自社所有）を選んでいる（coding-style.md の「複雑さは事業価値で裁く」と同じ判断）
「OWL でなく独自表現」「自動推論しない」は、研究の知識グラフ視点だと重要: Palantir の Ontology は記述論理の KG ではなくプロパティグラフ＋アプリ統合。学術的な reasoning を期待すると外す。逆に言えば、実務では「推論」より「明示モデル＋権限＋操作」の方が効くという割り切り
留保: 批判記事（badalaiworld/Lokad）はベンダー中立とは限らず（Lokad は競合）、擁護（Dorian Smiley）は実践者ポジション。134% リテンション・mindshare 2.1% 等の数値は二次情報で、測定条件は未確認。TCO は「何を退役させられるか」の前提で結論が反転する点に注意

6. まとめ — 「完成形」を選ぶ/選ばない判断¶

状況	判断
意味＋操作＋権限を一枚岩で・監査が最優先・予算と常駐人材がある	Palantir 型（買う）。完成度を取る
作り直せる軽さ・自社所有・可搬性が要る	内製の読み取り契約（Sansan 型）や意味層（dbt SL/LookML）から積む
KG で論理推論をしたい	Palantir Ontology は不適（reasoner でない）。研究用途は別基盤
TCO を判断したい	compute/storage 単純比較でなく、退役できる工数・ツールまで含めた Activity-Based Costing で

参考リンク¶

「Palantir Foundry Ontology: How It Works … Where It Falls Short」（badalaiworld / Towards AI, Pankaj Kumar）: https://badalaiworld.substack.com/p/palantir-foundry-ontology-how-it
Lokad「Review of Palantir」（総合4.7/10）: https://www.lokad.com/review-of-palantir-com/
Dorian Smiley「The CodeStrap Operating Model for Palantir Foundry」（擁護・ABC の TCO 論）: https://medium.com/codestrap/the-codestrap-operating-model-for-palantir-foundry-c2e230b7f64a
Palantir Foundry 価格（TrustRadius, 2025）: https://www.trustradius.com/products/palantir-foundry/pricing
概念側: palantir_foundry_ontology_ビジネスのai化基盤_整理 / 職種側: palantir_fdse_forward_deployed_engineer_整理

作成: 2026-07-24 ／最終更新: 2026-07-24