Palantir GothamとFoundryの違い｜用途・顧客・FDE実務
- 主な顧客：防衛・インテリジェンス・警察などの政府機関
- 主な用途：調査分析、人物や組織の関係分析、地理空間分析、作戦の意思決定支援
- データ：機密情報を含む多様な情報源を統合
- 導入環境：厳格なセキュリティ要件と分離ネットワークが前提
- 主な顧客：製造・金融・医療・エネルギーなどの企業と公共機関
- 主な用途：データ統合、分析、業務アプリケーションの構築と運用
- 中核概念：業務の実体をデータで表すOntology
- 導入環境：クラウドやオンプレミスなど企業のIT環境に合わせて構成
Palantir GothamとFoundryの違いは？
Gothamは政府・防衛・インテリジェンス向けの分析基盤で、Foundryは民間企業の業務データを統合して運用するための基盤です。
Palantir Technologiesは2003年に創業し、最初の主力製品として政府機関向けのGothamを開発しました。その後、民間企業向けにFoundryを提供しています。どちらもデータを統合して意思決定に使うという点は同じです。違いは「誰が、どんな判断に使うか」にあります。Palantir自身も公式サイトや年次報告書（Form 10-K）で、主力プラットフォームをGotham・Foundry・Apollo・AIPの4つと説明しています。
対象顧客と目的はどう違う？
Gothamは「脅威や対象を見つけて判断する」ため、Foundryは「業務を最適化して実行する」ためのプラットフォームです。
| 観点 | Palantir Gotham | Palantir Foundry |
|---|---|---|
| 主な顧客 | 防衛・インテリジェンス・法執行など政府機関 | 製造・エネルギー・金融・ヘルスケアなどの民間企業、一部の公共機関 |
| 主な目的 | 人物・組織・事象の関係分析、状況把握、作戦支援 | サプライチェーン、生産、保守、需給計画などの業務最適化 |
| 中心となる概念 | エンティティ（人・場所・物・事象）とその関係 | Ontology（業務オブジェクトとアクションのモデル） |
| 典型的な画面 | 地図、タイムライン、関係グラフ | ダッシュボード、業務アプリ、ワークフロー |
| 求められる要件 | 機密区分の管理、厳格なアクセス制御、分断された環境での運用 | 既存の基幹システム（ERP・MESなど）との連携、現場での使いやすさ |
技術的な基盤は共通している？
技術基盤の多くは共通化が進んでいます。それでも、データモデルの考え方と運用環境の要件は製品ごとに異なります。
GothamとFoundryはまったく別の製品というより、同じ設計思想を政府向けと民間向けに展開した製品と考えるほうが実態に近いです。どちらも「生データを意味のあるオブジェクトに変換し、権限に応じて見せ、判断を記録する」という流れでできています。Foundryではこの流れをOntologyとして明確に製品化しており、後発のAIPもOntologyを土台にしています。
現場目線でいうと、どちらの案件でも求められる力は「データの意味を決める力」です。データパイプラインを作る技術そのものより、顧客の業務を正しくモデル化できるかどうかで成果が決まる場面が多いと感じます。
Palantir Gothamはどんな組織で何に使われている？
Gothamは主に米国や同盟国の防衛・インテリジェンス・法執行機関で使われ、情報分析と作戦判断を支えています。
Gothamの「Gotham」は、バットマンの舞台になる架空都市から取られたと広く言われています。創業初期の資金の一部を米CIA系のベンチャーキャピタルであるIn-Q-Telから調達した経緯もあり、Palantirが政府向けからスタートした事実をよく表しています。
主な利用分野はどこ？
主な利用分野は、インテリジェンス分析、防衛の作戦計画、法執行機関の捜査支援、災害対応の4つです。
- インテリジェンス分析：通信記録、報告書、公開情報などをつなぎ合わせ、人物や組織の関係を可視化する
- 防衛・作戦支援：部隊、装備、地理情報を統合し、指揮官の状況把握と意思決定を支える
- 法執行・捜査：事件記録や捜査資料を横断して検索し、関連性を見つける
- 災害対応・公衆衛生：物資や拠点の状況を把握し、配分を判断する
具体的な契約名や金額は、各国政府の調達情報やPalantirの決算資料で確認できる範囲が限られます。案件の多くは非公開です。記事やSNSで流れてくる「Gothamが○○作戦に使われた」という情報は、一次情報で確認できるものかを見極める必要があります。
Gothamならではの要件は何？
Gothamでは、機密区分ごとのアクセス制御、ネットワークから隔離された環境での運用、監査可能性が最優先されます。
民間システムとの大きな違いは、「誰がどの情報を見たか、どう判断したか」を後から検証できることが必須になる点です。また、インターネットにつながらない環境（エアギャップ環境）や、通信帯域が限られた前線環境に配備されるケースもあります。Gothamの開発や導入に携わるエンジニアは、機能を追加するより先に、セキュリティと運用の制約を前提に設計を考えることになります。
Palantir Foundryは企業でどう使われている？
Foundryは、企業内に散らばるデータをOntologyで業務オブジェクトとしてつなぎ、現場の意思決定アプリまで作るために使われます。
Foundryの特徴は、データ基盤とアプリ開発環境が一体になっていることです。データウェアハウスとBIツールを別々に導入する場合と違い、データの取り込み、変換、モデル化、業務アプリ化、書き戻しまでを同じ権限管理のもとで扱えます。
公開されている代表的な導入例は？
公開事例として有名なのは、Airbusの航空データ基盤「Skywise」、英国NHSの連合データ基盤、日本のSOMPOとの合弁事業です。
| 組織 | 領域 | 概要（公開情報に基づく） |
|---|---|---|
| Airbus | 航空機製造・運航 | 航空会社と共有するデータ基盤「Skywise」をPalantirと共同で構築 |
| 英国NHS England | 公的医療 | Federated Data Platform（連合データ基盤）の調達でPalantir主体のコンソーシアムが2023年に選定された |
| SOMPOホールディングス | 保険・介護 | 2019年にPalantir Technologies Japanを合弁で設立し、国内展開の足場とした |
NHSの案件は公的機関ですが、使われているのはFoundry系の基盤です。「Gotham＝政府、Foundry＝民間」と単純に分けられない例として覚えておくと便利です。
企業でよく使われる業務領域はどこ？
よく使われるのは、サプライチェーン、生産・品質管理、設備保全、需給計画など、複数のシステムをまたぐ業務です。
これらの業務に共通するのは、ERP、MES、表計算ファイル、現場の紙記録などにデータが分かれていて、一つの判断に複数のデータが必要になるという点です。Foundryの価値はダッシュボードを作ること自体ではありません。「この部品の納期遅れが、どの受注に影響し、誰が何を決めるべきか」を一つのOntology上で扱えることにあります。
実務者の感覚では、Foundry導入が成功するかどうかは技術よりも「最初に選ぶユースケース」で決まりやすいです。経営層が見たい全社KPIから始めるより、現場担当者が毎日使う判断業務を一つ選んで作り込むほうが、定着しやすい傾向があると感じます。
GothamとFoundryに対するAIP・Apolloとの関係はどうなっている？
AIPはGothamとFoundryの上で生成AIを動かすための層で、Apolloは両製品を各環境に配信・更新し続けるための基盤です。
4つの製品は横に並ぶものではなく、層として重なる関係にあります。
| 層 | 製品 | 役割 |
|---|---|---|
| AI活用層 | AIP（Artificial Intelligence Platform） | LLMをOntologyや業務アクションにつなげ、エージェントや業務アプリに組み込む |
| アプリ・データ層 | Gotham / Foundry | データ統合、モデル化、分析、業務アプリ |
| 配信・運用層 | Apollo | クラウド、オンプレミス、エアギャップ環境などへのソフトウェアの継続的な配信と更新 |
AIPはGotham・Foundryと何が違う？
AIPは単独の分析ツールではありません。既存のOntologyと権限管理の上でLLMを安全に業務へ組み込むための製品です。
AIPは2023年4月に発表されました。その後、顧客が数日間でユースケースを試作する「AIP Bootcamp」という導入方式が、Palantirの営業・導入の中心的な手法になりました。ポイントは、LLMが直接データベースを触るのではなく、Ontologyで定義されたオブジェクトとアクションを通じて動くことです。そのため、「誰が何をしてよいか」というGotham・Foundryの権限モデルがそのままAIにも適用されます。
Apolloはなぜ重要なの？
Apolloがあるおかげで、Palantirは同じソフトウェアを政府の隔離環境から民間のクラウドまで一貫して更新できます。
Gothamの顧客には、ネットワークから隔離された環境や、機密レベルの異なる複数の環境が存在します。Apolloは、そのような環境の違いを吸収しながらソフトウェアの配信を自動化する仕組みです。Palantirは2021年ごろからApolloを外部向けにも製品として打ち出しています。FDEにとっては、「顧客ごとにフォークしたコードを手作業で保守する」状態を避けるための土台になっています。
FDEの働き方はGotham案件とFoundry案件でどう違う？
Gotham案件はセキュリティ制約と機密性が働き方を決め、Foundry案件は業務理解と成果のスピードが働き方を決めます。
PalantirでFDE（Forward Deployed Engineer）に当たる職種は、社内では「Forward Deployed Software Engineer」と呼ばれ、顧客の現場に入り込んで課題の発見から実装までを担います。どちらの案件でも「顧客の隣で作る」という本質は同じです。ただし、日々の制約条件は大きく異なります。
働く環境と求められる条件はどう違う？
Gotham案件ではセキュリティクリアランスや勤務場所の制約が大きく、Foundry案件では顧客企業の現場に入り込む柔軟さが求められます。
| 観点 | Gotham案件 | Foundry案件 |
|---|---|---|
| 勤務場所 | 顧客施設内の制限区域や専用環境が中心になりやすい | 顧客オフィス・工場とリモートの組み合わせが多い |
| 参加条件 | 国籍やセキュリティクリアランスが求められることがある | 一般的な守秘義務契約の範囲で参加できることが多い |
| 開発環境 | 持ち込みできるツールや外部サービスの利用に厳しい制限がある | クラウド環境と比較的自由な開発ツールを使える |
| 対話する相手 | 分析官、指揮官、捜査担当者 | 現場責任者、業務部門、経営企画、情報システム部門 |
| 成果の測り方 | 任務遂行への貢献、分析時間の短縮 | コスト削減、リードタイム短縮などの業務KPI |
| 外部への発信 | 実績を公表できないことがほとんど | 顧客の許可があれば事例として公表できる場合がある |
日本でFDEを目指すエンジニアにとって、現実的に関わる機会が多いのはFoundry・AIP系の民間案件です。Gotham系の防衛案件は、国籍やクリアランスの要件から参加できる人が限られます。
キャリアとして見るとどちらが有利？
どちらが有利かは目指す方向によって変わります。業界を問わず通用する汎用的なFDEスキルを磨きやすいのは、Foundry案件です。
Foundry案件では、異なる業界の業務をOntologyに落とし込む経験を何度も積めます。この「業務をモデル化する力」は、Palantir以外のFDE職種やデータ基盤の導入支援、社内DX推進の役割にも転用しやすいスキルです。一方、Gotham案件では、高セキュリティ環境での設計、運用、監査対応という希少な経験が得られます。防衛・公共分野で長期的にキャリアを築きたい人には強みになるでしょう。
現場実務者の視点から補足すると、どちらの案件でも評価されるのは「顧客の言葉で課題を言い直せること」です。Palantir製品の操作に詳しいことは入口にすぎません。FDEとして価値を出せるかどうかは、顧客と一緒に「何を判断するためのデータか」を決めきれるかにかかっていると考えます。GothamとFoundryの違いを理解することは、その判断の文脈を読むための最初の一歩です。
出典・参考：Palantir Technologies 公式サイト（製品ページ：Gotham／Foundry／AIP／Apollo）、Palantir Technologies Inc. Form 10-K、Airbus Skywise 公開資料、NHS England Federated Data Platform 公表資料、SOMPOホールディングス プレスリリース（2019年）
