「私たちは基本的にPalantirですが、X分野に特化しています。」
2025年のスタートアップ資料で最も繰り返されたフレーズの一つです。FDE（Forward-Deployed Engineer）の求人は前年比800〜1,000%急増し、資料にPalantirのロゴを入れる創業者も爆発的に増えましたよね。
でもa16zのMarc Andruskoは、この光景を見てある不都合な質問を投げかけます。「あなたはPalantirなのか、それともPalantirのセールスピッチを持ったアクセンチュアなのか。」
なぜみんなPalantirを目指すのか — 数字が物語ります
Palantirモデルが魅力的なのは当然なんですよ。数字がとにかく圧倒的なので。
そこにAI時代がさらに燃料を注いでいます。大企業はAIを使いたいのに、実際に本番環境まで到達するプロジェクトは思ったよりずっと少ないんです。データサイロ、システム統合の問題、責任者不明確 — これがエンタープライズAI導入の3大障壁なんです。FDEがこの問題を解決する「橋」に見えるのは理解できますよね。
結果として2025年だけでFDE求人が800〜1,000%急増し、初期スタートアップがFDE主導のGTMモデルで7桁の契約を取っています。トレンドは本物です。問題はそのトレンドの裏にある構造なんです。
でも、PalantirはFDEのせいで成功したんじゃないんです
ここで最も多い誤解が生まれます。Palantirの成功を「FDE＋ハイタッチ・デリバリー」と見て、それをコピーしようとするんですが、実際のところFDEはPalantirのコアではなく、実行レイヤーなんです。
Palantirが実際に構築したのは、再利用可能なプリミティブの上に乗ったプラットフォームです。データモデル、アクセス制御レイヤー、ワークフローエンジン、UIプリミティブ — これを先に作りました。FDE（社内呼称では「Deltas」と「Echoes」）は顧客先に赴くとき、スクラッチから作るわけじゃないんですよ。これらのプリミティブを組み立てて検証する役割なんです。
Palantirモデルの実際の構造
共有プラットフォーム（再利用プリミティブ）→ FDEが顧客文脈で組み立て・検証 → 現場パターンが再びプラットフォームに吸収。プラットフォームなしにFDEだけ、またはFDEなしにプラットフォームだけでは、どちらも機能しません。
加えて、Palantirが最初に攻略した市場が特別でした。国防総省、CIA、FBI、NSA — 代替手段がなく、コストは問題ではなく、失敗すれば国家安全保障に関わる顧客たちです。2009年のJPMorganとのパートナーシップでFDE 120人を投入できたのも、そのレベルの顧客がいたからこそ。ほとんどのスタートアップが狙う「中堅企業の販売ワークフローを8%改善」とはまったく別次元ですよね。
「ほとんどのスタートアップは、Palantirの見た目をコピーしながら、ソフトウェアのバリュエーションを持つ高価なサービスビジネスになってしまいます。」
— Marc Andrusko, a16z
このモデルがあなたに合うか — 4つの条件で診断
Palantir GTMが自分のスタートアップに合うかどうかは、4つの構造条件で診断できます。これをチェックすれば、「FDE主導のGTMをすべきか、それともPLGで行くべきか」がわかりますよ。
| 条件 | Palantirモデル適合 | PLG/ボトムアップ適合 |
|---|---|---|
| 問題の重大性 | 国家安全保障・生命・数十億ドル — 失敗は不可 | 効率10〜20%改善レベル |
| 顧客集中度 | 大型アカウント数十個、ACV数千万 | 小規模アカウント数千個 |
| ドメイン同質性 | 顧客ごとにワークフロー構造が似ている | 顧客ごとにニーズがまったく異なる |
| 規制/データ重力 | 国防・医療・金融犯罪など、統合の苦痛が極めて大きい | 統合が比較的シンプル |
4つのうち3つ以上が「Palantirモデル適合」に当てはまって初めて、FDE中心のGTMを検討できます。 そうでなければ、FDEをいくら採用してもスケールしないカスタム開発工場になるだけです。
サービス・トラップに入っているサイン
「来年50社と契約したらどこが壊れますか？」この質問に「よくわからない」や「顧客がみんな違うので…」という答えが出るなら、今プラットフォームではなく人に依存している構造です。それがサービスビジネスです。
では今すぐチームで使えるものは？
Palantirモデルを丸ごとコピーしろということではありません。一部は本当に実用的です。核心は「足場（scaffolding）として使い、基礎（foundation）として使わない」ことです。
- FDEをタイムボックスで運用する
無期限派遣ではなく「90日スプリント→本番」方式で期間を決めてください。終わったら学んだことをプラットフォームに吸収。「後でプロダクト化する」は「永遠にサービスのまま」と同義です。 - プリミティブが先、FDEはその後
FDEが顧客先に行く前に、統合データモデル、権限レイヤー、共通ワークフローエンジンが必要です。なければ顧客ごとに新プロジェクトになり、それはソフトウェアではありません。 - FDEをプロダクトチームの中へ
FDEをプロフェッショナルサービスチームに閉じ込めると、プロダクトフィードバックループが断ち切られます。現場パターンがプラットフォームに上がるには、FDEとプロダクトが同じテーブルに座る必要があります。 - FDE対売上比率を設定する
エンジニア何人がARR $1Mをカバーするか基準を決めてください。この比率が時間が経っても改善しなければ、製品ではなくコンサルティングをしているということです。 - マージンの現実を内部で認める
FDE派遣が必要なディールならグロスマージンは低くなります。投資家にソフトウェアマージンのように表現しないでください。正直なモデリングが正しいプロダクト決定につながります。
