FDE（Forward Deployed Engineer）とは何か。求人100件超の実測から描く定義の正本

「FDEの求人票を読んだんですが、これ、うちの会社で言う何の仕事なんでしょうか」。

最近のキャリア面談で、この質問が急に増えました。SIerで上流をやってきた方、SESで常駐を続けてきた方、事業会社のSAの方。皆さま、求人票は読める。でも自分の経験とどう接続するのかが分からない。無理もないと思います。Forward Deployed Engineer——直訳すれば「前方展開エンジニア」。日本語の情報空間には、この職種の定義を体系的に説明した文章がまだほとんど存在しません。実際、当サイトが2026年7月に調べた範囲では、カタカナ表記でのFDE求人検索ヒットはWantedlyで3件、Findyでは0件。求人は英語表記で100件以上あるのに、日本語の解説が追いついていない。そういう歪んだ黎明期です。

皆さまは、「顧客の現場でコードを書く仕事」と聞いて、どんな職種を思い浮かべますか。SES？　プリセールス？　この記事では、その混同を一つずつほどきます。

0. なぜ今、定義から始めるのか

先に理屈を申し上げます。FDEという職種は、2025年以降に日本で急拡大し、2026年春に本格化した「輸入されたばかりの職種」です。Indeedのデータ（Business Insider 2026年5月報道）によれば、グローバルのFDE求人投稿数は前年比約729%増。日本ではSalesforceの日本初FDEチームやSB OAI Japanといった外資が定義を持ち込み、日系AIスタートアップが追随している構図です。

この729%という数字を、僕はこう解釈しています。「コーディングがAIに代替されるから、エンジニアの仕事の範囲を拡張しよう」というシンプルな話ではありません。AIが企画・要件定義・設計・実装まで一気に賄えるようになると、プロダクトが誕生するペースが爆発的に速まり、競争が激化し、システムやサービスのライフサイクルが短命になる。僕はこの「短命になる」ことこそが最も大きな変化だと感じています。ウォーターフォール、アジャイル、スクラム、コードレビュー、ペアプログラミング——平成時代に生まれたエンジニアリング開発の「あり方」や「やり方」は、短命化の速度に耐えられず、完全に変容しなくてはならないフェーズに差し掛かっている。開発体制が変われば、エンジニアの「職域」も変わらざるを得ない。FDEの急増は、その職域変化が最初に名前を得た現象だと僕は読んでいます。

職種が輸入される時、いつも起きることがあります。名前だけが先に広まり、中身が会社ごとにバラバラになる。実際、当サイトが求人媒体を横断して実測したところ、日本のFDE求人は実質70社前後・100求人超（2026年7月17日時点、Findy64件・Green31件・Wantedly16掲載などの重複排除ベース）。その中には、Palantirの原義に忠実な求人もあれば、率直に言うと、SESの案件をFDEと呼び替えただけに見えるものも混ざっています。だからこそ、求人票の名前ではなく構造で見分ける道具が要る。ここが今回の隠れた主役です。

1. 定義——「前方展開」して実装するエンジニア

先に、僕の定義を置きます。FDEとは、顧客（ユーザー）と直接コミュニケーションを取り、既存のシステム（プロダクト）の要望（課題）を文言化し、開発（実装）まで行うエンジニアのことです。本サイトでは、この一文を定義の正本とします。ポイントは、真ん中にあるのが技術ではなく「課題の文言化」だということです。ここは後で詳しく述べます。

1-0. まず「フォワード」をサッカーで考える

Forward Deployedという言葉を、僕はいつもサッカーで説明しています。サッカーの最前線は「フォワード」ですよね。これをビジネスの世界に当てはめると、フォワード＝営業職、ミッドフィルダー＝カスタマーサクセス・マーケティング・プロダクトマネージャー、ディフェンダー＝バックオフィス全般、そしてエンジニアやデザイナー、監督＝社長や事業企画、というイメージです。エンジニアをディフェンダーに置いたのは能力の話ではなく、「顧客の前へ出る」機会が一般的に多くはない、という配置の話です。つまりFDEとは、これまでピッチの後方にいたエンジニアが、最前線——顧客の目の前——に配置（deploy）される職種。フォワード＝「前へ」、デプロイド＝「配置される」。名前がすべてを言い表しています。

forward deployedは軍事用語の借用で、部隊を前線に展開させることを指します。自社のエンジニアを顧客の現場に「前方展開（forward deploy）」させ、曖昧な課題を要件化し、その場で本番コードを書き、定着まで運ぶ。この言葉を職種名に転用したのがPalantirで、CIA・NSAといった機密環境では顧客データを持ち帰れないため、エンジニアが現地に出向いて開発するしかなかった——という必然から生まれました（起源の詳細はPalantir起源譚の記事に譲ります）。

僕がこの職種を一言で説明する時に使っているのが「顧客折衝×自前実装×生成AI」という三点セットです。当サイトの2026年7月実測で、日本のFDE求人のほぼ全件がこの三要素の掛け算で書かれていました。順に見ます。

1-1. 顧客折衝——技術要件より上に来る

Findyに掲載されたFDE求人64件の必須要件を機械集計すると、最頻出は「顧客折衝・ステークホルダーコミュニケーション」で46件。「Webアプリ/ソフトウェア開発の実務経験」の43件を上回りました。エンジニア職の求人で、対人要件が技術要件より上に来る。これがFDEの最大の特徴です。GreenやWantedlyの求人でも同じ傾向を確認しています。

1-2. 自前実装——提案して終わりではない

二つ目の要素は、提案や設計で止まらず自分の手で実装まで運ぶこと。求人票の言葉を借りれば、メドレーやprimeNumberが明文化する「PoCで終わらせず定着まで」です。開発経験は「3年以上」が最頻の年数指定で、言語不問の求人も多い。特定言語の職人技より、動くものを顧客環境で完成させ切る経験が問われています。

1-3. 生成AI——ただし「必須」は少数派

三つ目が生成AIです。64件中36件がAI・ML関連に言及しています。ただし誤解がないように申し上げると、LLM実装まで必須で求める求人は約3分の1にとどまります。生成AI/LLM/RAG/エージェントの実装経験は、必須（20件）よりも歓迎要件（43件）に置かれるのが現在の相場で、「個人開発可」「業務外可」という緩和も目立ちます。経験より意欲。ここは後で効いてくる事実です。

2. 近接職種との違い——出口がどこにあるか

面談で一番多い混同が「それってSAやプリセールスと何が違うんですか」です。僕の答えはいつも同じで、仕事の出口がどこにあるかを見てください、と申し上げています。

ソリューションアーキテクト（SA）はアドバイザリーが中心で、多くの場合PoCまでが守備範囲です。FDEは顧客環境で本番実装まで踏み込みます。プリセールスは受注が出口。FDEは受注後の本番稼働・定着が出口です。ITコンサルは提言書を納めれば一区切りですが、FDEは長期伴走と実装責任を負う。カスタマーサクセスは既存プロダクトの活用支援であり、FDEは新規の実装から定着までを構築側から担います。

そしてSESとの違い。これが一番深い溝です。SESは労働力の提供であり、評価軸は時間です。FDEは自社プロダクトや自社の解決手法を軸に、成果で評価される。同じ「顧客先で働くエンジニア」でも、時間を売るのか、成果にコミットするのか。ここが分水嶺です。逆に言えば、求人票がFDEを名乗っていても、業務内容が「客先常駐・タスクは顧客が定義」なら、それは名前だけのFDEです。本物のFDE求人は、思っているより見分けやすい——出口を読めばいいのですから。

2-1. 求人票での見分け方（実務）

今日からできる確認手順を置いておきます。所要は1求人あたり5分。（1）業務内容に「定着」「本番」「還流」のいずれかがあるか。（2）必須要件の1行目が対人要件か技術要件か——実測では本物ほど対人が先に来ます。（3）誰のプロダクト・手法を持ち込むのか（自社資産がないならSESに近い）。この3点をメモに書き出すだけで、求人の性格はほぼ判別できます。より細かい3類型の見極めは日本のFDE求人3類型の記事で扱っています。

3. 誰が募集しているのか——支払い能力のある70社

当サイトが企業プロフィールを調査した42社の内訳は、AIプロダクト/AI SaaS企業が20社（エクサウィザーズ、ストックマーク、Algomatic、テイラーなど）、業務SaaS/プラットフォームが12社（Sansan、マネーフォワード、ラクスル、TOKIUM、ログラスなど）、AIコンサル/受託・SIが7社、総合・ITコンサルが2社。上場企業が10社、未上場の中核はLayerX（シリーズB150億円）、キャディ（累計257億円）、ログラス（累計100億円）といった大型調達済みスタートアップです。

つまり「上場企業か、調達数十億円級か」が雇い手の中心。年収レンジの中央値は約1,100万円、最高は2,500万円（Third Intelligence、JDSCなど）に達します（詳細は年収相場の記事で分解しています）。勤務地は東京にほぼ一極集中で、フルリモート明示は約15%。顧客の現場に入る職種である以上、ここは構造的な制約だと感じています。

4. 越境できるのか——「LLM必須は3分の1」の意味

最後に、この記事で一番お伝えしたいことを書きます。僕の周囲の実感で言うと、FDE求人を眺めて「自分にはAIの実務経験がないから無理だ」と閉じてしまう方が非常に多い。ですが実測データはその逆を示しています。LLM実装を必須とする求人は約3分の1。過半の企業は、生成AIについて経験より学習意欲を許容しています。

むしろ落ちる理由は別のところにあります。必須1位の顧客折衝、9位の要件定義・上流工程（16件）、そして求める人物像でほぼ全社が挙げる「オーナーシップ・自走」。これらはSIerの上流経験者、常駐で顧客と揉まれてきたSESの方、ITコンサルの方が既に持っているものです。足りないのは生成AIの実装経験だけで、そこは求人側が「歓迎・個人開発可」まで緩めて待っている。越境の壁は、皆さまが思っているより低い場所にあります。数字がそう言っています。

もう一つ、越境について申し上げたいことがあります。FDEは「エンジニアが前へ出る」だけの現象ではありません。ビジネスサイドの弱みは長らく「技術的知見」でしたが、AIの力によって、機能レベルの要件定義・設計・実装はビジネスサイドでも叶えられる時代になりました。つまり、ビジネスサイドがAIを使ってエンジニアリングの職域に侵食する「逆流」も、同時に起きています。僕自身がビジネスサイドの人間としてAIでコードを書いている実感から言っても、この逆流は本物のFDE現象の一部です（PM・ビジネスサイドからの越境はPM経験者はFDEになれるかの記事で扱っています）。

5. 課題の文言化——技術より上に来る、最重要の職域

最後に、定義の正本として一番強調しておきたい職域の話をします。実測で必須要件1位が顧客折衝だったことは述べましたが、その顧客折衝の中身を一段分解すると、核にあるのは「課題の文言化・課題提起」です。顧客の曖昧な要望を、解ける形の課題として言葉にする。僕は、これが2026年7月時点のFDEにおいて技術より上に来る最重要の職域だと考えています。

ただし、「課題の文言化なら私もできますよ」と言う前に、一つ考えてほしいことがあります。例えばダイエット。「痩せたい」という課題に対して、食事量を減らす、ランニングをする、糖質制限をする——課題の文言化も解決策の明示も「できた」ことになりますよね。では皆さま、ダイエットに成功されたことはありますか。解決策を見出して実行したのに解決できなかった、という方がほとんどではないでしょうか。つまり、顧客が感じている課題の解決策をシステムに実装しても、本当にその課題が解決できたかは分からない。表層的な課題の裏にある「本質的な課題」にたどり着くスキルは、解決策を並べるスキルとは別物なのです。

そしてもう一つ。仕事でも私生活でも、「あなたの課題は〇〇だから、これを改善したほうが良いですよ」と唐突に言われて、イラッとした経験はありませんか。人間は、自分の至らない点を指摘されたら心中穏やかではありません。エンジニアは「事実」に目を向けて課題を解決するスキルに長けていますが、顧客やユーザーは人間であり、そこには感情が伴います。論理的に正しい課題でも、顧客がそれに合意するとは限らない。顧客が「解決したい」と思える課題を、コミュニケーションによって創発させながら伝える——ただ課題を突き止めるだけでは足りない、この感情を伴う課題合意こそが、フォワードデプロイドをするために必要な要素です。面接でdecomp（課題分解）と並んで対人局面が重く見られるのは、この構造があるからです。

6. 結び——定義が固まる前に、現在地を測る

FDEはまだ定義が揺れている職種です。だからこそ、名前ではなく構造（出口・要件の順序・自社資産の有無）で求人を読める人が、良い案件と名前だけの案件を選り分けられます。そして定義が固まり、日系大手SIerがこの名称を採用し始めれば（当サイトは2026年後半〜2027年と推測しています）、求人は増える一方で競争も始まる。動くなら定義の揺れている今のほうが、経験の読み替えが効きます。まずはご自身の経験がFDEの三点セットのどこに接地するのか、現在地から測ってみてください。