FDEはなぜPalantirで生まれたのか。軍事用語からOpenAI・Anthropicへ続く起源譚

「なんで軍隊みたいな名前なんですか、この職種」。

FDEの説明をすると、面談でだいたいこの反応が返ってきます。当然です。Forward Deployed——前方展開。IT職種の名前としては明らかに異物ですから。でも僕は、この名前こそがFDEという仕事の本質を一番正確に説明していると思っています。名前の由来を遡ると、この職種が「なぜ存在しなければならなかったのか」という必然に突き当たるからです。

皆さまは、納品したシステムが顧客の現場で使われずに死んでいくのを見たことはありませんか。FDEの起源譚は、その問題を20年前に極限状況で解いた会社の話です。

0. 前提——なぜ起源を知る必要があるのか

先に申し上げておくと、これは教養のための歴史記事ではありません。日本のFDE求人は2026年7月時点で100件超（当サイト実測）ありますが、その中身は玉石混交です。原義に忠実な求人と、名前を借りただけの求人を見分けるには、原義そのものを知っているのが一番強い。Palantirがこの職種に込めた設計思想——それが今回の隠れた主役です。

1. 発端——データを持ち帰れない顧客

Palantirは2003年設立、初期の主要顧客はCIAやNSAといった米国の諜報機関でした。ここで普通のソフトウェアビジネスの前提が崩れます。機密環境の顧客データは、外部に持ち出せない。本社にデータを送ってもらって開発する、という当たり前の手順が最初から成立しないのです。

ならば、エンジニアがデータのある場所へ行くしかない。Palantirは2000年代半ば、自社エンジニアを顧客施設に送り込み、現地で本番コードを書かせる職種を作りました。社内呼称は「Delta」、正式にはFDSW（Forward Deployed Software Engineer）。「forward deployed」は部隊を前線に展開させる軍事用語の借用で、顧客が軍・諜報機関だった会社らしい命名です（この経緯はPragmatic Engineer「What are Forward Deployed Engineers」2025年8月12日、およびPalantir自身の採用情報に依っています）。

ここで押さえていただきたいのは、FDEが「営業戦略として」ではなく「物理的な制約から」生まれたことです。誰かが気の利いた職種を発明したのではない。現場に行かなければ仕事が成立しなかったから、現場に行く職種ができた。この順序が、後の全てを決めています。

2. 設計——「責務はスタートアップのCTOに近い」

面白いのはここからです。制約から生まれた働き方を、Palantirは明確な職務設計に昇華させました。Palantirの採用ページにあるFDEの定義は、僕が知る限りあらゆる職種定義の中でも際立って野心的です。いわく、FDEの責務はスタートアップのCTOに近い。小さなチームで、高リスク案件のエンドツーエンドの実行を、オーナーシップを持って担う——。

CTOという比喩の意味を分解すると、三つになります。第一に、技術判断を自分で下す（本社にお伺いを立てない）。第二に、課題の定義から本番稼働までの全工程に責任を持つ（工程の一部だけを担当しない）。第三に、リソースが足りなければ自分で作る。日本のSI業界の感覚で言えば、要件定義・設計・実装・運用の分業を、一人ないし数名で全部引き受けるイメージです。率直に言うと、これは万人向けの働き方ではありません。だからこそ高い報酬が付きます（Palantir FDSEの米国年収中央値は$215K、Perspective AI 2026 Comp Report。詳細は年収相場の記事で）。

2-1. 製品への還流——出張エンジニアとの決定的な違い

もう一つ、Palantirの設計で見落とされがちな要素があります。FDEは現場で顧客固有の問題を解くだけでなく、そこで得た知見を本社の製品開発に還流させる役割を負っていました。現場で10社に同じ改修をしたら、それは製品の機能になるべきだ、という発想です。このループがあるから、FDEは「高級な出張エンジニア」ではなく製品戦略の一部になる。僕はここがFDEモデルの心臓部だと考えています。現場と製品をつなぐ配管。これが無いFDE組織は、時間が経つとただの受託部隊に退化します。

2-2. Echoとのペア——一人で行かせない

さらにPalantirは、FDE（Delta）を単独で顧客に送りませんでした。ペアを組むのがDeployment Strategist、社内呼称「Echo」です。Deltaが実装を担い、Echoが顧客の業務・政治・意思決定構造を読み解いて「何を作るべきか」を定める。軍隊のコールサイン（Delta/Echo）で呼び合う二人組が、機密施設の中で顧客の課題を解いていく——物語としてよくできていますが、実務的にも合理的です。技術と業務理解の両方を一人に求めると採用が成立しない。二人に分ければ成立する。日本の求人で言えば、FDEとカスタマーサクセス/コンサルタントの協働体制がこの構造の子孫にあたります。

3. 継承——なぜAI企業がFDEを復活させたのか

Palantirの社内職種だったFDEは、2020年代半ば、生成AIの波で一気に業界標準の名前になりました。OpenAIとAnthropicがFDE職を設置し、Pragmatic Engineerの2025年8月の記事によれば、OpenAIは世界8都市に10名超のFDEを展開。決済スタートアップのRampは約15名のポッド制で運用しています。a16zは「The Palantirization of everything」という論考まで出しました。求人数で見ると、Indeedのデータ（Business Insider 2026年5月18日）でグローバルのFDE求人は前年比約729%増。Bloomberryの集計では2024年から2025年にかけて+1,165%です。

なぜ復活したのか。構造がPalantirの初期と同じだからです。生成AIは強力ですが、そのままでは顧客の現場で動きません。顧客のデータ・業務・セキュリティ要件に合わせて誰かが「現地で」組み込む必要がある。20年前は機密データが理由で、今はAIの現場適応が理由。「製品が現場でそのまま動かない」市場には、必ずFDEが要る。これがPalantirが証明し、AI企業が借用した法則です。誤解がないように申し上げると、OpenAIやAnthropicの求人要件は顧客対峙の技術職経験3年以上、LLMの本番運用経験、出張25〜50%といった水準で、Palantir原義にかなり忠実です（各社採用ページ、2026年7月当サイト確認）。

4. 実務——起源を面接でどう使うか

ここまでの話を、転職の実務に落とします。今夜30分でできる準備です。まず、応募先の求人票をPalantirの三要素——（1）CTO型のオーナーシップ、（2）製品への還流ループ、（3）伴走役との分業——に照らして採点してみてください。三つとも読み取れれば原義型、還流だけ無ければ受託型です（日本の求人の類型分けは3類型の記事に詳述しています）。次に、面接の逆質問を一つ用意します。僕のおすすめは「現場で得た知見はどういう経路で製品に反映されますか」。この一問で、その会社のFDEが心臓部を持っているかどうかが分かりますし、起源を理解した候補者として記憶されます。実際、僕の周囲の実感で言うと、FDE面接で職種の歴史文脈まで語れる候補者はまだ1割もいません。差別化としては安すぎるくらいです。

5. 結び——名前は借り物でも、必然は本物

軍事用語を借りた奇妙な職種名の裏には、「現場に行かなければ解けない問題」という20年変わらない必然がありました。そして生成AIの時代、この必然は機密機関から普通の企業へと一気に拡がっています。日本の求人100件超は、その拡散の最前線です。起源を知った上で求人票を読むと、同じFDEの三文字がまるで違って見えるはずです。次はご自身がこの系譜のどこに立てるのか、適性から確かめてみてください。