Palantir Foundry は多機能に見えますが、機能を分解すると3階層（データパイプライン / オントロジー / アプリケーション）に整理できます。それぞれ既存の Fivetran + dbt + Snowflake + Cube + Retool のスタックと機能的に対応しています。

Foundry の独自性は「3階層の連続性」と「アクション経由の書き込み強制」に集約されます。技術は既存のソフトウェア工学の延長で、新しいのは実行する順番と、書き込みまで含めた製品化です。

Palantir の名物 FDE（Forward-Deployed Engineer）と AIP Bootcamp は、Palantir の商品ではなく「入口の営業装置」。本体は「オントロジー常駐」にあります。実演は撒き餌、オントロジーが檻という二段構造です。

顧客側は、FDE 撤収後のハンドオーバー断崖、1〜3年でのオントロジーの経年劣化、3〜5年後の更新交渉での人質構造という、3つの構造的リスクを負います。

Palantir のオントロジーは、セマンティック（名詞：オブジェクトとリンク）× キネティック（動詞：アクションとファンクション）の2要素で構成されます。動詞を持つことで、書き込みまで扱える「操作できるオントロジー」になります。

BI 系の「セマンティックレイヤー」は名詞だけの世界（Read Only）。Palantir の Operational Ontology は、これに動詞を加え、業務ルール込みで書き戻せる（Read/Write）点で質的に違います。

通常のソフトウェア開発は、要求 → ドメインモデリング → 物理データ → アプリの順で進みます。Palantir では、既存の物理データから出発して、ドメインモデル（オントロジー）→ アプリの逆順で組みます。これがリバースドメインモデリングです。

実装は6フェーズで6〜12ヶ月。最難関はキネティック層の業務ルールコード化と、境界づけられたコンテキスト問題（部門ごとに「注文」の定義が違う）への政治的対処です。

既存 DWH + BI は Read Only の世界です。ダッシュボードで気づいた後、業務システムに戻ってログインし直す、Excel マクロで補完する、といった手作業が積み上がる。この症状が2つ以上出ていたら、Operational Ontology 化を検討する価値があります。

段階的移行は5ステップ。全業務を一気に Operational 化する必要はなく、1〜3業務プロセスに絞ってPoC → 拡大の順で進めます。既存 BI 資産は残しつつ、キネティック層だけ追加する併存戦略が実務的です。

Palantir Foundry と同等の Operational Ontology は、Fivetran + dbt + Snowflake + Cube + Retool のオープンスタックで再現可能です。初期投資は Foundry の 1/10 以下、5年トータルでも大幅に安く、ベンダーロックインも回避できます。

中堅企業（30〜70人規模）は、Palantir の下限を超えるホワイトスペース。「引き渡して去る」設計（外部が作り、内部が維持する）で、居座り構造も SIer 常駐も回避する第三の道が成立します。