「Palantir Foundry は多機能で複雑」という印象は、機能を眺めるだけでは正当な評価に届きません。実際は、既存のデータ基盤の構造と同じ 3 階層に整理できる、素直なアーキテクチャです。DX 推進担当のあなたが Foundry を評価するとき、まず必要なのは各層の役割を分けて見ることです。
この記事では、Foundry を構成する主要コンポーネントを 3 階層（データパイプライン / オントロジー / アプリケーション）に分解し、各層の技術的な位置付けと、既存のオープンスタック製品との対応を整理します。
3階層の全体像
| 層 | Foundry の主要製品 | 既存製品での対応 |
|---|---|---|
| ① データパイプライン層 | Data Connection、Pipeline Builder、Code Repositories | Fivetran / Airbyte / dbt / Airflow |
| ② オントロジー層 | Ontology Manager、Object Storage V2 | dbt Semantic Layer + Cube + カスタム |
| ③ アプリケーション層 | Workshop、OSDK、AIP | Retool / Streamlit + LangChain / Custom GPT |
各層は独立して評価できます。Foundry の価値は、この 3 層を同一プラットフォームで連続して構築でき、モデルの再利用が効くこと。逆に言えば、オープンスタックでも 3 層を意識して組めば、同等の Operational Ontology は再現可能です。
① データパイプライン層の中身
Foundry のデータパイプライン層は、次の 3 つの主要製品で構成されます。
| 製品 | 役割 | 設計思想 |
|---|---|---|
| Data Connection | ソースシステムへの接続、データ取り込み | コネクタライブラリで各種SaaS / DB / ファイル対応 |
| Pipeline Builder | ローコードでの変換パイプライン構築 | SQL や関数のブロックを DAG で組む、非エンジニア向けも意識 |
| Code Repositories | PySpark / SQL / TypeScript でのカスタムロジック | エンジニア向け、Git バージョン管理 |
既存の Fivetran + dbt + Airflow のスタックが担う領域と、機能的には重なります。Foundry の独自性は、この層と後段のオントロジー層が同じプラットフォーム内で連続すること。データ変換の結果が、そのままオントロジーのオブジェクトになる連続性が、Foundry の強みです。
② オントロジー層の中身
Foundry のオントロジー層は、Ontology Manager で組み立てます。主要な部品は 3 つです。
| 部品 | 役割 | 既存製品での近い概念 |
|---|---|---|
| オブジェクト | 業務の名詞（Order、Customer、Inventory） | dbt モデル、ディメンション |
| リンク | オブジェクト間の関係（Order → Customer） | スタースキーマのファクト × ディメンション関係 |
| アクション | 業務の動詞（Cancel Order、Assign）と業務ルール | 既存製品にほぼ対応なし ← ここが Foundry の独自性 |
既存の dbt Semantic Layer や Cube は、オブジェクトとリンクに相当する「セマンティックレイヤー」までは提供しますが、アクション（書き込み可能な業務動詞）は含みません。ここが Operational Ontology と読み取り専用オントロジーの分岐点です。
③ アプリケーション層の中身
Foundry のアプリケーション層は、3 種類の作成手段があります。
| 手段 | 対象ユーザー | 特徴 |
|---|---|---|
| Workshop | 業務側の非エンジニア | ローコードで画面を組む、オブジェクトとアクションをドラッグ&ドロップ |
| OSDK | エンジニア | TypeScript SDK でカスタムアプリを開発、オントロジーへ型付きでアクセス |
| AIP | 業務側 + エンジニア | LLM ベースのエージェント、オントロジーの動詞を安全に呼び出せる仕組み |
既存のオープンスタックでは、Retool や Streamlit がローコード側、React + カスタム API がエンジニア向け、LangChain + Custom GPT がエージェント側を担います。Foundry の統合価値は、これら 3 手段すべてが同じオントロジーを共有し、アクション経由でしか書き込めない一貫性を保つ点にあります。
Foundry の統合価値と代替可能性
3 階層を一つのプラットフォームで組むことの Foundry 側の意味は、次の 4 点です。
| 観点 | Foundry の設計 | 代替スタックでの再現方法 |
|---|---|---|
| 3層の連続性 | 同一プラットフォームで自動連携 | 各層のツールを疎結合で組み、契約層は明示的に定義 |
| モデルの型付き参照 | OSDK でオントロジー変更が型で伝播 | dbt Semantic Layer + GraphQL / TypeScript 型生成 |
| アクション経由の書き込み強制 | オントロジー外から書き込めない設計 | アプリ層で API を通す規約 + サービス層強制 |
| バージョン管理と監査 | 全アクションのログを保持 | アプリ層とデータ層で個別に監査ログ、統合ダッシュボード |
Foundry の 3 階層が持つ「連続性」と「一貫性」は、確かに強力です。ただし、これらは技術的にはオープンスタックでも再現可能で、Palantir 特有の魔法ではありません。導入判断は、3 階層の統合価値と、居座り構造との取引になります。
まとめ
Palantir Foundry は 3 階層（Data Pipeline / Ontology / Application）に分解できます。各層は既存のオープンスタック製品（Fivetran + dbt + Cube + Retool 等）と機能的に対応し、Foundry 独自の価値は「3 層の連続性」と「アクション経由の書き込み強制」に集約されます。技術的な再現は可能で、選択は統合価値と居座り構造のトレードオフです。
オープンスタックでの Operational Ontology 構築、既存 DWH/BI からの Read/Write 統合への移行、あるいは Palantir 導入後の維持不能問題への対処など、貴社の現状を踏まえた設計は、Empower STKの初回相談でご案内できます。
あわせて読みたい
- Palantir Foundry の実体：オントロジーとリバースドメインモデリング、日本企業のDX文脈で読み解く
- FDE モデルの本質：営業装置とオントロジー常駐の二段構造
- Operational Ontology とは：セマンティック × キネティック が生む Read/Write の閉ループ
- オントロジー構築の実務：ドメインモデリングとの共通点と、逆順で組み立てる工程
- Palantir 代替のオープンスタック構成：dbt + セマンティックレイヤー + アプリ層で作る Operational Ontology
よくある質問
Q. Foundry のライセンスコストは、3 階層まとめてでしょうか？
A. 通常、プラットフォーム全体で 1 つの契約になります。3 階層のうち一部だけを使う契約は Palantir では想定されていません。この一体契約が、居座り構造の一因にもなります。
Q. Data Pipeline 層だけ他ツール（例：Fivetran）と組み合わせられますか？
A. 技術的には可能ですが、Foundry の統合価値（型伝播、アクション連続性）は薄れます。Foundry を採用する意義が薄れるため、実務では 3 層一体で使うのが標準です。
Q. オープンスタックで組む場合、どの層から始めるべきですか？
A. データパイプライン層と、その上のセマンティックレイヤー（読み取り専用オントロジー）から始めるのが定石です。アクション層を追加するのは、書き戻したい業務が明確になってから。詳細は「オープンスタック構成」の記事で扱います。