FDE（フォワードデプロイドエンジニア）とは？SESとの違いや比較を解説！
FDEという職種名は、2025年の終わりごろから急に見かけるようになりました。OpenAIもAnthropicも募集しており、日本でもLayerXやソフトバンクとOpenAIの合弁であるSB OAI Japanなどが枠を設けています。年収の話も派手で、日本でも1,000万円台から、米国のシニア帯だと日本円で1億円に届く数字が並びます。
ただこのFDE、顧客のオフィスに数か月常駐して、要望を聞きながら開発して、現場に定着するまで面倒を見る。これはつまり、日本で長年やってきた客先常駐・SESと、何が違うのでしょうか？
FDEとSESはどちらも準委任契約
先に結論から言ってしまうと、契約形態でFDEとSESを区別することはできません。
「FDEは顧客の課題を自ら定義する、SESは顧客の指示に従って作業する」、「FDEは成果でコミットするプロフェッショナル」「SESは指示通りに動く労働力」など、もっともらしい話が並びますが、これは職業意識の話であって、構造の説明にはなっていません。同じ意識の高さで働いているSESエンジニアはいるでしょうし、指示待ちのFDEもいるはずです。
では何で異なるのか？この記事では3本の軸で考えます。
- 出し手が製品を持っているか
- 稼働時間で評価されるか、顧客の成果で評価されるか
- 現場での学びが、次の顧客に展開可能か
これらを順に見ていく前に、そもそもFDEが何のために発明されたのかを押さえておくと、この3本が後付けの理屈ではないことが分かります。
Palantirの定義は、普通のエンジニアと真逆を向いている
FDEという役割を作ったのは、米国のデータ分析企業Palantirです。同社はこの役割を、こう定義しています。
普通のソフトウェアエンジニアは、多数の顧客に対して1つの機能を作る。FDEは、1人の顧客に対して多数の機能を作る。
この一文がFDEの本質をほぼ全部言い切っています。プロダクト企業の常識では、目の前の1社のためだけに何かを作るのは負けです。汎用化できないものは資産にならないし、保守コストだけが残る。にもかかわらず、Palantirは意図的にその逆をやる部隊を作りました。
なぜそんなことをしたのかは、当時の顧客が誰だったかを知ると腑に落ちます。
顧客が要件を語れず、データも見せてくれない現場で発明された
2000年代初頭のPalantirの主要顧客は、米国の情報機関でした。ここには、普通のソフトウェア開発が成立しない条件が揃っていました。
顧客は自分たちが何を必要としているのかを言語化できない。仮にできたとしても、機密なので詳細を外部に説明できない。扱っているデータそのものも見せてもらえない。ユーザーインタビューもできないし、現場の業務フローは状況に応じて常に変わり続ける。
つまり、要件を聞いて、設計して、作って納めるという進め方が、入口の時点で成立しなかったわけです。
そこでPalantirが取ったのが、エンジニアを顧客の環境の中に置いてしまうという手でした。要件が聞けないなら、隣に座って観察して、試しに作って反応を見て学ぶ。これがフォワードデプロイド、つまり前線配備という軍事用語をそのまま持ってきた名前の由来です。この部隊は当初、社内でDeltaと呼ばれていました。
課題を見つけるEchoと、作りきるDelta
Palantirはこれを、二種類の人材の組み合わせとして設計しました。
Echoは、顧客の業界出身の領域専門家です。その業界の言葉と痛みを知っていて、どこに価値が眠っているかを見つける役割を担います。Deltaは実行側で、情報が不完全なまま、とにかく形にして動かすエンジニアです。
課題を見つける人と、作りきる人。この二枚看板を現場に置いたことが、単なる出向や常駐との最初の違いでした。
砂利道を作るのがFDE、舗装するのは本社
そしてもう一つ、FDEモデルの心臓部にあたる仕組みがあります。Palantirはこれを、砂利道と舗装道路のたとえで語ります。
FDEは目の前の1社のために、粗くて泥臭い解決策を作ります。これが砂利道です。同じような砂利道が複数の顧客の現場に何本もできてくると、本社の製品エンジニアがそこから共通のパターンを抜き出して、誰でも使える標準機能として作り直します。これが舗装です。
顧客ごとの個別対応が、製品そのものを太らせる燃料になる。 この還流ループがあるからこそ、Palantirは個別対応をやりながらプロダクト企業でいられました。ちなみに2016年ごろには、同社のエンジニアはFDEの人数のほうが通常のエンジニアより多くなっていたと言われています。
いま再燃したのは、要件を事前に書けない仕事がAIで一気に増えたから
なぜ20年近く前の仕組みが、2025年から2026年にかけて急に注目されているのか。
理由は単純で、Palantirが直面していた制約が、AI導入という形で多くの企業に広がったからです。
生成AIを業務に入れようとすると、要件定義がうまく書けません。何ができるのかが事前に確定していないし、実際にデータを入れてみないと精度も分からない。顧客が「こういう業務をこう自動化したい」と説明してくれても、いざ現場のデータを見にいくと、説明と実態がまるで違う。ここが最大の難所です。
OpenAIでFDE組織を率いるColin Jarvis氏は、検証フェーズについて、大量の曖昧さの中で働くことになり、顧客の説明と現場のデータやシステムの実態は往々にして一致しないという趣旨の説明をしています。これは要件を聞いて作る方式では処理できない種類の曖昧さです。
ここで、よく引用される数字に触れておきます。MITのProject NANDAが2025年に出したレポートで、企業の生成AI実証実験の95%が損益に測定可能な影響を与えていない、というものです。FDEの必要性を語る記事のほぼ全部がこれを引きます。
ただし、この数字は割り引いて読んだほうがいいです。調査の規模は経営者52名へのインタビューと153名へのアンケート、公開されている300件の導入事例の分析で、統計的な悉皆調査ではありません。NANDAはMITから生まれたプロジェクトではあるものの、MITが管理運営しているわけではなく、レポート自体が特定のソリューションへの誘導になっているという利益相反の指摘も出ています。同じレポートの中には、外部パートナーと組んだ案件は約67%が本番稼働に到達し、内製だけの場合は約33%にとどまったという数字もあり、こちらのほうがFDEの文脈では実は重要です。
95%が失敗している、という煽り文句ではなく、外から人が入ったほうが本番に届く確率が倍近いというほうが、実感に近いのではないかと思います。
SESとの違いは、意識ではなく製品・損益・還流の3本で決まる
ここで最初の問いに戻ります。
まず、日本の契約類型を整理しておく
日本でエンジニアが客先で働くときの契約は、だいたい3つに分かれます。
準委任契約は、業務の遂行そのものを約束する契約です。成果物の完成責任は負わず、報酬は基本的に稼働時間に対して支払われます。いわゆるSES契約はこの準委任の一種です。重要なのは、発注側にはエンジニアへの指揮命令権がないという点で、指示はベンダー側の責任者を通す必要があります。
請負契約は、仕事の完成を約束します。納品して初めて報酬を請求でき、瑕疵があれば直す責任も負います。
労働者派遣契約は、派遣先の企業に指揮命令権があります。自社の社員と同じように、日々の作業内容や勤務時間を管理できます。
そして偽装請負というのは、形式上は準委任や請負なのに、実態として発注側が直接細かい指示を出していて、中身が労働者派遣になっているものを指します。ベンダーが派遣事業の許可を持っていなければ、労働者派遣法違反として罰則の対象になります。
さて、ここで問題です。FDEはこのどれでしょうか。
答えは、どれにもなりうる、です。ベンダーの正社員として顧客先に入るなら準委任に近い形が多いですし、成果指標を握るなら成果完成型の準委任や請負に寄せることもできます。契約類型を見ても、FDEかSESかは判別できません。 これが最初に書いた結論です。
線1 出し手が製品を持っているか
Palantirの原義でのFDEは、製品を持っている側の社員です。自社のプラットフォームを顧客の業務に食い込ませるために現場へ行く。だから顧客先での作業は、それ自体が売上であると同時に、自社製品の販路と改善機会でもあります。
対して、人月で人を出す会社は製品を持っていません。売っているのは人の時間そのものです。この差は意識の差ではなく、ビジネスモデルの差です。
線2 稼働時間で評価されるか、顧客の成果で評価されるか
何をもって仕事がうまくいったとするか。ここが決定的に違います。
稼働時間が埋まっていることが評価になる構造だと、極端な話、課題が解決してしまうと売上が減ります。現場を良くすることと、自分の収入が逆を向くわけです。一方、顧客のビジネス成果に紐づいているなら、早く効かせて次の課題に移るほうが得になります。
同じ人が同じ席に座っていても、この向きが逆なら、出てくる行動は当然変わります。
線3 現場での学びが、次の顧客に効く形で残るか
そして3本目。Palantirの砂利道と舗装道路の話です。
顧客ごとに作った泥臭い解決策から共通のパターンが抜き出され、製品なりナレッジなりの形で残っていくのか。それとも案件が終わるたびに全部リセットされ、次の現場でまたゼロから同じことをやるのか。
この還流ループが無いなら、名乗りがFDEであっても、実態は受託開発か常駐です。 逆にこのループがあるなら、契約形態が準委任であっても、SESとは別の生き物です。
3本のうち、外から一番見えにくくて、一番ごまかしが効かないのがこの3本目だと思います。
仕事時間の多くは、顧客の説明とデータの実態のずれを埋めるのに消える
具体的に何をやっているのかを、案件の流れで見てみます。
最初の数日から数週間は、現場に入って業務を地図にする作業です。誰がどんな判断をしていて、その判断にどんな情報を使っていて、どこで詰まっているか。この段階では、コードはほとんど書きません。
次が検証フェーズで、ここが一番きついとされています。顧客が説明してくれた業務フローと、実際のデータベースの中身が食い違う。あるはずの項目が空欄だらけだったり、運用でカバーされていて誰もシステムに入力していなかったり、部署ごとに同じ項目の意味が違ったり。ここを突き合わせて現実に合わせる作業が、時間の大半を持っていきます。
そのあとに実装が来ます。週の何日かを顧客先で過ごしながら、実際に動くものを顧客の環境の中に作っていきます。スライドや設計書ではなく、動くコードを置いてくるのが特徴です。
そして定着。作って終わりではなく、現場の人が実際に使う状態まで持っていって、使われ方を見ながら直します。
最後に還流。ここで得た型を、自社の製品なりナレッジなりに戻します。
Palantirの現役FDEの証言として引かれているのは、週の何日かを顧客先で過ごしてステークホルダーとの打ち合わせや監視、デバッグ、デプロイをやっている、というものや、月によって全然違って、普通のエンジニアのようにコードを書いている週もあれば、顧客と案件のスコープを切っている週もある、というものです。要するに、役割の境界がはっきりしない仕事です。
製品を持たない第三者がFDEを名乗れるのか
ここで、日本の実情に踏み込みます。
Palantirの原義でのFDEは、繰り返しになりますが製品を持つ会社の社員です。ところが、日本でFDEと呼ばれているものの多くは、他社のSaaSやAPIを顧客に導入する第三者です。SIerやコンサルティング会社、あるいは個人の業務委託が、ベンダーではない立場で現場に入る。
この場合、線1が割れます。製品の所有者ではないからです。ではもうFDEではないのかというと、そう単純でもありません。
還流の行き先が、製品からナレッジに移るだけだと考えると整理がつきます。
APIを含むSaaSを顧客に入れるとき、SaaSそのものは触りようがありません。作るのは、そのSaaSと顧客の業務の間を埋める部分です。認証をどう通すか、社内のどのデータを渡すか、出力を誰がどう確認するか、既存の業務システムのどこに戻すか。ここは毎回ゼロから作ることになります。
その埋めた部分が案件終了とともに消えていくなら、それは受託開発です。業界や業務のパターンとして自社に型が残り、次の顧客のときに立ち上がりが速くなっているなら、線3は成立しています。 製品を持っていなくても、還流先をナレッジに置き換えれば、FDE的な働き方は成立します。
逆に言うと、他社製品を入れているだけで、毎回同じところで同じように苦労しているなら、名前を変えても中身は変わっていません。
FDEと間違われやすい6つ
3本の線を当てると、紛らわしいものが整理できます。
客先常駐のSESは、線1が割れます。出し手が製品を持っていません。多くの場合、線2も割れて稼働時間が評価軸になります。ここが最も混同されやすいのですが、判別は難しくありません。
SIerの受託開発は、線2は成立しうるものの、線3が割れがちです。案件ごとに一から作って納めて終わる構造だと、学びが次に効きません。
コンサルティング会社のPoC支援は、線3が割れます。実証実験の報告書までが納品物で、本番稼働まで持っていく責任を持たない契約になっていると、砂利道すら残りません。元OpenAIのBob McGrew氏はFDEをプロダクト化されたコンサルティングと表現していますが、逆に言えば、プロダクトが無いコンサルティングはFDEではないということでもあります。
プリセールスやソリューションアーキテクトは、線が割れるというより深さが違います。OpenAIの内部での説明でも、ソリューションアーキテクトは実証用のMVPを作るところまでで、FDEはもっと手を動かして顧客のインフラの中にコードを書き、より曖昧な状態で働く、と区別されています。
カスタマーサクセスは、既に売れた製品の利用を伸ばす役割で、線2の向きは近いのですが、コードを書いて現場を作り変える権限を持たないことが多いです。
フリーランスの業務委託は、契約だけでは判別できません。線1は基本的に割れるので、線3が立っているかどうかが唯一の分かれ目になります。
将来性は、職種名ではなく働き方が残るかで考える
増えているのは事実です。ただし、この職種を批判している人たちの言い分のほうが、実は読む価値があります。
求人数の伸びは本物だが、母数は小さい
海外の求人分析では、FDE関連の求人が2025年4月の643件から2026年4月には5,330件へと、前年比で7倍以上に増えたという集計が出ています。日本国内は2026年春の時点で、日系が26件前後、外資が9件前後で、合わせて35件ほどという集計もあります。
伸び率は派手ですが、日本での実数はまだ数十件です。 職種としてはこれから、という段階だと見ておくのが妥当です。
会計上、FDEの工数は研究開発ではなく売上原価になる
最も鋭い批判は、SaaS業界の論客であるThomas Otter氏のものです。氏の指摘はこうです。
FDEの工数を顧客に請求すればコンサルティングであり、請求しなければカスタマーサクセスである。いずれにせよ研究開発ではなく、売上原価に分類されるべきものだ。 それを継続収益として計上するのは、投資家と自分自身を騙している。
これは会計の話に見えて、事業モデルの本質を突いています。FDEを大量に抱えるほど、粗利率はソフトウェア企業のものから、人月商売のものに近づいていきます。
a16zのMarc Andrusko氏も同じ方向の警告を出していて、Palantirの表層的なやり方だけを真似た会社の大半は、SaaSの服を着たコンサルティング会社に終わるだろう、と述べています。Palantirが成立しているのは、統合されたプラットフォームと、失敗が許されない領域という条件が揃っていたからであって、エンジニアを顧客先に送り込むこと自体が勝ち筋なのではない、という指摘です。
標準化を始めたとき、最大の抵抗勢力は自社のFDEになる
Otter氏はもう一つ、時間差で効いてくる問題を挙げています。
技術リソースが個別案件に張り付き続けると、数年後には数十の案件はあるのに標準製品は乏しいという状態になる。そこで標準化に着手しようとすると、最大の反対勢力になるのは、顧客の事情を一番よく知っている自社の技術者自身になる。さらに、個別対応に慣れた顧客も標準化に抵抗するので、社内外で綱引きが起きる。
これは砂利道を舗装しようとしたときに必ず起きる摩擦で、線3の還流ループは、放っておいて回るものではないということでもあります。
というわけで、FDEという職種名が5年後に残っているかは正直分かりません。ただ、要件が事前に書けない仕事を、現場に入って一緒に確定させながら作るという働き方のほうは、AIが業務に食い込む限り必要であり続けるはずです。名前より、この形が自社に必要かどうかで考えるほうが実用的です。
スキルセットは、技術スタックが入場券で、核は要件を作る力
求人票を分析した集計では、技術面の基礎セットとしてPython、TypeScript、SQL、クラウド、コンテナ周りが並びます。AI企業の求人ではLLMの経験を明記しているものが31%、RAGの経験を求めるものが12%という数字も出ています。経験年数はOpenAIで5年以上、シニア職で7年以上、Anthropicで4年以上あたりが目安とされています。
ただ、この辺りはあくまで入場券です。求人票の記述でよく出てくるのはT字型という言い方で、技術の縦軸に加えて、業界理解、関係構築、不確実な状況での意思決定、役員クラスと話せること、といった横軸が求められます。
もっと絞って言うと、要件が存在しない状態から要件そのものを作る力が核だと思います。顧客が語る業務と、データベースの実態と、現場の人が本当に困っていることの3つがずれているとき、どこを正として設計するかを決める仕事です。ここは技術力とも対人スキルとも少し違う、別の筋肉です。
見極めの質問としては、顧客が言ってきた要件そのものを作り直した経験を具体的に語れるかどうかが効きます。言われた通りに作った話しか出てこないなら、線2の向きが違います。
報酬水準も触れておくと、Palantirのフォワードデプロイドソフトウェアエンジニアの総報酬の中央値が21万ドル前後、OpenAIのミドルからシニア帯はサンフランシスコで基本給16万から28万ドル、日本国内の正社員求人は1,000万円から2,500万円のレンジで出ています。ただしこれらは2026年前半時点の集計で、変動が激しい領域です。
企業がFDEを採用・外注する理由は、PoCが本番に届かないから
ここからは、雇う側・発注する側の話です。
FDEを検討する会社は、だいたい同じ詰まり方をしています。
実証実験は成功したのに、本番導入が進まない。 精度は出たし現場も好感触だったのに、既存システムとの接続、権限、運用ルール、例外処理の話になった途端に止まる。
社内に要件を書ける人がいない。 現場は困りごとを言えるが要件にできず、情シスは要件を書けるが現場の判断を知らない。この間を埋める人がいないと、発注書が書けないので外注もできません。
入れたツールが使われていない。 導入は終わったことになっているのに、現場は元のやり方に戻っている。
いずれも、製品と業務の間にある隙間が原因です。ここは製品を売る側も、業務を回す側も、自分の担当だと思っていない領域です。FDEという役割は、この誰の担当でもない隙間を担当だと宣言した人、という言い方もできます。
他社が同じ隙間をどう埋めたかを先に見ておくと、自社で必要な体制の見当がつきやすくなります。
外注するなら、契約設計と受け入れ準備の両方が要る
実際に外に頼むときの実務です。
契約は、指揮命令をどう扱うかを最初に決める
成果を握るなら、成果完成型の準委任か請負に寄せます。 稼働時間精算だと、線2の向きが自動的に工数側を向いてしまいます。ただし、AI導入は成果物を事前に確定できないことが多いので、期間を区切って、期ごとに何をもって完了とするかを合意し直す形が現実的です。
そして日本で必ず注意すべきなのが、指揮命令の扱いです。準委任で入っている人に対して、発注側が直接、日々の作業指示や勤務管理をすると、実態が労働者派遣とみなされて偽装請負のリスクが出ます。ベンダーが派遣事業の許可を持っていなければ、派遣法違反として罰則の対象になります。
ここは皮肉なところで、FDEに期待している働き方ほど、現場との距離が近くなり、指揮命令の線が曖昧になりやすいです。誰が誰に指示を出すのか、窓口を誰にするのかを、契約と運用の両方で最初に設計しておく必要があります。
費用の目安としては、月あたり130万円から300万円程度という水準がいくつかの媒体で示されています。調達経路によって幅が大きいので、参考程度に。
受け入れ側が用意しないと、何も始まらないものが3つある
外注しても機能しないケースは、だいたい発注側の準備で決まります。
データへのアクセス権限。 これが下りないと、検証フェーズが1ミリも進みません。契約書にサインした後で、実データを見るのに3か月かかる、というのは珍しくない話です。
現場の人の時間。 業務を地図にする作業は、現場の人に聞かないとできません。通常業務のかたわらで、週に何時間出せるかを先に決めておく必要があります。
決められる人の同席。 顧客の説明とデータの実態がずれていたとき、どちらを正とするかを決めるのは業務側の意思決定です。ここに決裁権のある人がいないと、判断待ちで止まります。
失敗パターンは、隙間を埋める人を置かないまま製品だけ入れること
よくある失敗を挙げておきます。
製品の選定だけを外部に頼み、導入は社内でやると決めて止まる。実証実験だけを切り出して発注し、本番の話が誰の担当でもなくなる。個別対応を頼み続けた結果、そこでしか動かないものが積み上がって、誰も触れなくなる。
最後の一つは、Palantirが砂利道を舗装し続けることで回避してきた問題そのものです。発注する側も、作ってもらったものが自社の型として残るか、その案件限りで消えるかを見ておいたほうがいいと思います。
まとめ
FDEは、顧客が要件を語れない現場でソフトウェアを届けるために、Palantirが2000年代初頭に発明した役割です。1人の顧客のために多数の機能を作り、そこで生まれた砂利道を本社が舗装して製品にする、という還流ループが本体でした。
生成AIの導入で、要件を事前に書けない仕事が一気に増えたことで、この20年前の形がいま再発見されています。
そしてSESや受託開発との違いは、契約形態では区別できません。見るべきは3本です。出し手が製品を持っているか。稼働時間で評価されるか、顧客の成果で評価されるか。現場での学びが次の顧客に効く形で残るか。 特に3本目が無いなら、名前が何であれ中身は変わりません。
製品を持たない第三者であっても、還流先を製品からナレッジに置き換えれば、この働き方は成立します。日本で現実的に増えていくのは、おそらくこちらの形です。
お問い合わせ
下記フォームよりお気軽にお問い合わせください。
担当者より折り返しご連絡いたします。