「Palantir Foundry は企業のデジタルツインを作る」「オントロジーで意味レイヤーを持つ」。ここ数年、DX 推進担当のあなたも、Palantir 関連の記事や講演で耳にしたはずです。それでも、Foundry で具体的に何が起きるのか、DWH や BI と何が違うのか、自社に持ち込む価値があるのか、抽象的な説明ばかりで判断できずにいないでしょうか。

Palantir の構造を分解すると、既存のソフトウェア工学の語彙で説明できます。新しいのは概念そのものではなく、実行する順番と、書き込みまで含めた製品化です。この記事では、Foundry の実体を3層に分解し、なぜ「逆順」で組むのか、Operational Ontology の意味、日本の中堅企業が Palantir と付き合うときの3つの構造的な問題、そして代替設計まで整理します。

Data Utilization Support
複雑なビジネスロジックを、武器になるデータへ。
データ基盤の設計〜実装〜運用まで、ビジネス文脈を汲んで伴走します。Empower STK：データ利活用支援 の初回スポット相談は 30分10,500円（税込）から。

Palantir Foundry を3層に分解する

Foundry は、社内に散らばったデータを一箇所に集め、その上で業務を回すアプリケーションまで作れるプラットフォームです。多機能に見えますが、機能を分解すると3層に整理できます。

層主な役割Palantir 側の製品名
データパイプライン層散在システムからデータを吸い上げ、変換・統合するData Connection、Pipeline Builder、Code Repositories
オントロジー層統合したデータを「業務の意味」でモデリングするOntology Manager
アプリケーション層現場が見て操作するための画面を作るWorkshop（ローコード）、OSDK（コード）

「データを集める、意味づけする、使う」という並びに、それ自体で驚きはありません。着目すべきは、この3層を組み立てる順序です。普段のソフトウェア開発と逆になっています。

なぜ「逆順」なのか：リバースドメインモデリング

通常のソフトウェア開発は、次の順序で進みます。要求 → 業務分析とドメインモデリング → 物理データモデルの設計 → アプリケーション。頭の中の業務理解を先に固め、それに合う物理データ構造を設計し、その上にアプリを載せる。この工程で作られるアプリは、多くの場合 1 ドメイン 1 アプリ（受注管理アプリ、在庫管理アプリ）に閉じます。

Foundry の順序は逆です。企業には既にシステムが 10 個も 20 個もあり、データはそこに散らばっています。この現実から出発すると、業務の意味を与える前に、まず物理データを揃えないと始まりません。散在システムからデータを吸い上げ、テーブルを組み上げ、そのうえで「注文」や「顧客」といったドメインオブジェクトを定義していく。工程の順番だけが逆で、モデリングの中身は同じです。

工程通常の業務アプリ開発Foundry
出発点要求と業務理解既存の散在システムのデータ
ドメインモデル先に組む物理データ統合後に組む
物理データモデルに合わせて設計既存を統合して先に用意
スコープ1 ドメイン 1 アプリ全社横断で複数アプリを再利用

業務アプリの開発では、モデルとデータは 0 からスタートします。Foundry では、既に事業が動いていて、システムもデータも 10〜20 年分蓄積されている状態から始まる。ここが本質的な違いです。

Operational Ontology：セマンティック × キネティック の意味

「オントロジー」という言葉は最近、BI ベンダーや DWH ベンダーも使うようになっています。ただ、Foundry のオントロジーは質的に違います。2つの要素で構成されるためです。

要素役割業務での具体例
セマンティック（意味）名詞：オブジェクトとリンク「注文」「顧客」「在庫」、注文と顧客の関連
キネティック（動き）動詞：アクションとファンクション「注文をキャンセルする」「在庫を引き当てる」（業務ルール込み）

BI 系の「セマンティックレイヤー」は名詞だけです。指標定義や項目名を全社で揃える、読み取り専用の意味レイヤー。Foundry のオントロジーは、これに動詞を加え、業務ルールを持った書き込みまで扱います。読み取り専用のセマンティックレイヤーと区別して「Operational Ontology（操作できるオントロジー）」と呼ぶのが、実体に近い呼び方です。

DWH / BI との違い：Read Only か、Read & Write か

「散らばったデータを集めて全社で見る」なら、既に DWH と BI がある——という反論は正当です。実際、読むだけなら DWH + BI で足ります。ディメンショナルモデリング（スタースキーマ）は集計と分析に最適化された成熟技術で、Foundry を持ち込む必要はありません。違いは、書き込みにあります。

観点DWH + BIFoundry
データの流れ一方通行（業務システム → DWH → ダッシュボード）双方向（業務システム ↔ Foundry ↔ アプリ）
気づいた後の行動BI を閉じて、業務システムにログインし直すダッシュボード上のボタンから、業務システムに直接書き戻し
ビジネスルール持たない（読み取り最適化）持つ（アクション経由でルール強制）
モデルの再利用各アプリで個別に設計全社共通、複数アプリで再利用
向く問い何が起きたか？（分析）次に何をするか？（判断と実行）

ダッシュボードで誤発注に気づいても、DWH + BI では「気づく」までしかできません。Foundry では、そのダッシュボード上の「キャンセル」ボタンから、業務ルール込みで基幹システムに書き戻せる。この差が Operational Ontology の実体で、Palantir がここまで評価される根拠でもあります。

FDE モデルの本質：営業装置とオントロジー常駐の二段構造

Palantir の名物 FDE（Forward-Deployed Engineer）と AIP Bootcamp（数日で顧客の実データ上に動くものを見せる実演型営業）は、外形だけ見ると Palantir の主力商品に見えます。実際は違います。

FDE と Bootcamp は「入口の営業装置」で、Palantir の本体は「オントロジーを作り、動かし、手離さないこと」にあります。実演は撒き餌、オントロジーが檻。収益の重心は Bootcamp の売上ではなく、その後の「居座り」にあります。コピー機とインクの構造に似ています。本体（Foundry）を見せる段階では安く見え、消耗品（オントロジー維持・更新）で回収する。

導入後、オントロジーは事業の変化——組織再編、M&A、業務プロセス変更——に合わせて手入れが必要になります。その持ち主は結局 Palantir 側に残り続けます。Palantir から見ればこれは製品戦略として合理的で、顧客から見れば「便利で強力だが、離れられない」の状態が続きます。

日本企業が直面する 3 つの構造的問題

Palantir を導入した企業（グローバルでは実績多、日本ではまだ薄い）が抱える構造的な問題は、次の 3 つです。技術ではなく、Palantir モデルそのものが内包する問題です。

問題内容顕在化のタイミング
ハンドオーバー断崖FDE 撤収の瞬間、生きたソフトが凍結ワークフローになる契約終了直後
オントロジーの経年劣化組織再編・M&A ごとに手入れが必要だが、持ち主が社内にいない1〜3年後
更新交渉の人質構造業務が全部 Foundry に載った後の値上げ交渉で、CFO が抗えない3〜5年後

加えて、日本市場では Palantir の下限ロット（金額とスコープの最小単位）と中堅企業（30〜70 人規模）のペインが噛み合わず、そもそも導入が進みにくい構造もあります。SIer 多重下請けと FDE の埋め込みモデルは相性が悪く、SOMPO 合弁以降も日本での事例は薄いまま推移しています。

代替設計：Palantir の結果を、Palantir の構造なしで

Palantir が証明した価値は、確実にあります。データ → 判断 → 実行の閉ループを、業務システムに書き戻すところまで一気通貫で持つ。これが Operational Ontology の意味で、DWH + BI では届かない領域です。

問題は、そのループを Palantir 経由で作ろうとすると、居座り構造が付いてくることです。日本の中堅企業には、この構造は経済的に噛み合わず、経営的にも心地よくありません。ここに代替設計の余地があります。

原則内容
オープンスタックで組むSnowflake / BigQuery + dbt + セマンティックレイヤー + アプリ層で、Foundry と同等の Operational Ontology を再現。ライセンスの単一ベンダー依存を避ける
1 年で作って引き渡すExternal build, internal maintain。外部が作り、内部が維持する二段構造を、最初から契約に書く
検収・監査の第三者化引き渡し後は薄い検収レイヤーだけで並走。依存を再生産せず、内部持ち主の判断を第三者が支える

要点は「Palantir が居座って稼ぐループを、外部が引き渡して去ることで作れるか」です。SIer とも Palantir とも構造的に違う立ち位置になります。SIer は居座ることで稼ぎ、Palantir は製品に還流させて稼ぐ。第三の道として、引き渡して去ることで稼ぐ設計が成立するか、というのが検証中の仮説です。

まとめ

Palantir Foundry の実体は、リバースドメインモデリングと Operational Ontology という 2 つの概念に集約できます。技術的には既存のソフトウェア工学の延長で、新しいのは工程の順番と、書き込みまで含めた製品化。日本の中堅企業では、Palantir 直接の導入は経済的に噛み合わないことが多い一方、Operational Ontology という設計思想自体は、オープンスタックで再現できます。持ち主を外部業者ではなく貴社の中に残す設計にすることが、居座り構造からの離脱経路になります。

オープンスタックでの Operational Ontology 構築、既存 DWH/BI からの Read/Write 統合への移行、あるいは Palantir 導入後の維持不能問題への対処など、貴社の現状を踏まえた設計は、Empower STKの初回相談でご案内できます。

よくある質問

Q. DWH + BI があれば、Foundry は不要ですか？

A. 「読むだけ」で足りるなら不要です。ダッシュボードで気づいたあと、業務システムへの書き戻しまで一気通貫で欲しいなら、DWH + BI では届きません。Operational Ontology の設計が必要です。ただし Palantir 以外にも、オープンスタックで組む選択肢はあります。「読む先に、書き戻したい業務がどれだけあるか」の棚卸しが判断の起点になります。

Q. Palantir と SIer 常駐の違いは何ですか？

A. 稼ぎ方の構造が違います。SIer は居座ることで稼ぐ（オントロジーなしの人月）。Palantir は製品に還流させて稼ぐ（オントロジーは作るが手離さない）。両者とも顧客側は「離れられない」状態が続く点で共通しますが、Palantir はループの再利用可能性が高い（複数アプリで同じオントロジーを使える）ぶん、SIer より投資対効果は上に来ることが多いです。

Q. 中堅企業（30〜70人規模）で、Operational Ontology は組めますか？

A. Palantir Foundry の直接導入は、金額とスコープの下限を下回るため経済的に噛み合いにくいです。ただし、オープンスタック（Snowflake / BigQuery + dbt + セマンティックレイヤー + アプリ層）で同等の Operational Ontology を組むことは可能です。1 年程度の外部支援期間と、内部で維持できる 1〜2 名の担当者がいれば、現実的なスコープに収まります。

Q. Palantir を既に導入した企業が、独立を目指すことは可能ですか？

A. 技術的には可能ですが、政治的・経済的な難所があります。オントロジーの「業務ロジック」部分は Foundry の中に残っているため、外に出す作業は再モデリングに近い。次の契約更新のタイミングを目安に、6〜12 ヶ月の再構築プロジェクトを計画するのが現実的な進め方です。