FDE(Forward Deployed Engineer)とは?AI導入をPoC止まりにしない新職種を導入企業の視点で解説

FDE(Forward Deployed Engineer)とは、自社のAIプロダクトを持つ企業に所属しながら、顧客の業務現場という「最前線」に入り込み、課題の定義からAIの実装・定着までを一気通貫で担うエンジニア職です。 米Palantirが確立した役割が、生成AIの企業導入が本格化した2025年以降にOpenAIなどAI企業各社へ広がり、日本でもLayerXやソフトバンク系企業が相次いで採用を始めています。この記事では、FDEが生まれた背景と仕事の中身を整理したうえで、「AIを導入する側の企業」がこの職種の登場をどう活かすべきかまで解説します。

FDEとは?定義と起源

FDEとは、ベンダー側のエンジニアでありながら顧客の現場に深く入り込み、「自社プロダクトが顧客の業務で実際に成果を出している状態」まで責任を持つ職種です。Forward Deployedは軍事用語の「前方展開」に由来し、本社のオフィスではなく顧客という前線に配備されることを意味します。

起源は米国のデータ分析企業Palantir Technologiesです。同社は2010年代から、政府機関や大企業の現場にエンジニアを常駐に近い形で送り込み、顧客のデータと業務に合わせてプロダクトを作り込むモデルを採ってきました。Palantirではエンジニアリングを担うFDEと、業務側の合意形成を担うDeployment Strategist(導入戦略担当)が組んで顧客に向き合う体制が知られています。

長らく「Palantir独特の職種」だったFDEが一気に一般化したのは2025年です。OpenAIがエンタープライズ導入部隊としてFDEチームの採用を本格化し、AnthropicやGoogleも同種の顧客常駐型エンジニア職を拡大。ベンチャーキャピタルのa16zがFDEを「いまテック業界で最もホットな職種」と評したことで、職種名として広く認知されました。米国では2025年から2026年にかけてFDEの求人掲載数が数倍規模で急増しています。

なぜ今FDEなのか:AI導入が「PoC止まり」になる構造

FDEという職種が急拡大した理由は、生成AIの企業導入が構造的につまずきやすいからです。MITの調査レポート「The GenAI Divide」(2025年8月)は、企業の生成AIパイロットの約95%が測定可能な事業成果を出せていないと報告しました。デモは動くのに本番で使われない——いわゆるPoC止まりです。

つまずきの原因は、モデルの性能ではなく「モデルと現場のあいだ」にあります。

従来のソフトウェア導入なら、この隙間はSIerの要件定義とFIT&GAP分析で埋められました。しかし生成AIは「作る前に仕様を確定できない」という性質があるため、現場で実データを使って試し、出力を見ながら業務側とAI側を同時に調整する人間が必要になります。この隙間を専門に埋めるのがFDEです。汎用モデルの性能競争が一段落し、AI企業の勝負どころが「モデルの賢さ」から「顧客の業務で成果を出せるか」へ移ったことも、各社がFDE採用を急ぐ背景にあります。

FDEは何をするのか:仕事の中身

FDEの仕事は、コードを書くことよりも「成果が出る状態を作ること」に重心があります。典型的な流れは次の4段階です。

1. 業務理解: 顧客の現場に入り、実際の業務フロー・データ・例外処理を観察してAIが効く箇所を特定する。ここでの課題定義がプロジェクトの成否を決める
2. 設計・実装: 自社プロダクトを土台に、顧客のデータ接続・RAG構成・プロンプト・ワークフローを顧客固有の業務に合わせて構築する
3. 現場定着: 実データで精度を検証し、人間がどこで確認・修正に入るか(ヒューマンインザループの設計)を決め、現場の手順に組み込んで使われる状態にする
4. プロダクト還元: 現場で見つかった課題や作り込みを自社に持ち帰り、プロダクト本体の機能として一般化する

4点目がFDEを単なる常駐エンジニアと分ける本質です。個社対応で終わらせず、現場の学びをプロダクトに還元して「次の顧客には標準機能で提供する」ループを回すことが、FDEモデルの事業的な狙いです。実際、日本でFDE組織を先行させたLayerXも、FDEの役割を顧客課題の解決と同時に「現場でのフィードバックをプロダクト進化に直結させること」と位置づけています。

SE・カスタマーサクセスと何が違う?

FDEは既存の職種と重なって見えますが、「何をもって仕事が完了か」が異なります。

SIerのSEとの違いは契約構造に表れます。受託開発は「合意した要件を作り切る」ことが責任範囲で、要件が最初に決められない生成AI案件とは相性が悪い。一方FDEは自社プロダクトという土台の上で、要件の発見から成果までを丸ごと引き受けます。カスタマーサクセスとの違いは実装力です。CSは活用の伴走をしますが、顧客のデータに接続してワークフローを組む開発までは踏み込みません。FDEはその両方をやる、いわば「実装できるCS」かつ「現場に出る開発者」です。

日本での広がり

日本では2025年後半からFDE職の設置が始まり、2026年に入って加速しています。

• LayerX: 2025年7月に国内で先行してFDE募集を開始。AIプラットフォーム「Ai Workforce」の導入最前線にFDEを配置し、顧客の文書業務に合わせたAIワークフロー構築とプロダクトへのフィードバックを担う。募集開始から半年でチーム規模を倍以上に拡大している
• ログラス: 経営管理クラウドの導入にFDE組織を設置。共同創業者が自らFDE組織の立ち上げを主導していることを公表している
• SB OAI Japan: ソフトバンクとOpenAIの合弁会社。OpenAIの企業向けAI「Cristal intelligence」を日本企業へ展開する体制でFDE型の職種を採用している

ほぼゼロだった国内のFDE求人は2026年春時点で数十件規模まで増えており、「自社プロダクト×導入伴走」を掲げるAI企業の標準的な組織形態になりつつあります。なお、海外ではAnthropicのように同じ役割をApplied AI Engineerなど別の名前で呼ぶ企業もあり、職種名は揺れていますが、「ベンダー側のエンジニアが顧客の現場で成果まで伴走する」という中身は共通です。

導入する側の企業はFDEをどう活かすか

ここまではベンダー側の話ですが、FDEの登場は「AIを導入する側」にとっても実務的な意味があります。ポイントは3つです。

1. ベンダー選定の評価軸に「FDE型支援の有無」を入れる

生成AIの導入でPoC止まりを避けたいなら、提案書のデモの出来ではなく「誰がうちの現場に入って、どこまでやってくれるのか」を確認すべきです。RFPや商談で確認したい項目を挙げます。

最後の行は見落とされがちですが重要です。個社カスタマイズが増えるほど、担当者しか触れない属人化したシステムになり、後の保守で苦しみます。FDEモデルのベンダーは作り込みをプロダクト標準機能へ吸収していくため、この心配が構造的に小さくなります。

2. PoCの設計自体を「FDE的」にする

FDEがいてもいなくても、PoCの計画を「実データ・実業務・数値つき成功基準」で組めば、PoC止まりのリスクは大きく減らせます。検証テーマの選び方や成功基準の立て方はPoCの基礎解説にまとめています。また、そもそも自社がAI導入を進められる状態かはAI導入準備度チェックで先に確認しておくと、ベンダーとの会話が具体的になります。

3. 「社内FDE」という選択肢を持つ

複数部署にAI活用を広げる段階では、業務とAIの両方が分かる人材を社内に置く方が速くなる局面があります。外部のFDEは自社プロダクトの範囲で成果を出す役割なので、部署横断の優先順位づけや、ツール選定そのものは社内の人間にしかできないからです。専任者を採用するか、既存社員を育てるか、当面は外部支援とAIツールで賄うかは、AIか採用かの費用比較で月額ベースの試算をしてから判断すると、感覚論になりません。

よくある誤解

• FDE=常駐SESではない: 客先常駐という形は似ていますが、SESは労働力の提供が商品です。FDEは自社プロダクトで成果を出すことが商品で、現場の学びをプロダクトに還元する点が逆方向です
• FDEがいれば丸投げできるわけではない: FDEが埋めるのは技術と現場のギャップです。どの業務から着手するか、何をもって成功とするかの判断材料を出せるのは発注側だけで、ここを丸投げするとFDEがいてもPoCは迷走します
• PoCを繰り返すことが前進ではない: FDE型の伴走があっても、成功基準のないPoCを重ねるだけでは意味がありません。検証は毎回「導入判断につながる数値基準」とセットで設計します(基準の立て方はPoC計画書作成ツールが警告つきで補助します)
• 流行語だから乗るべき、ではない: FDEはあくまでベンダーの組織形態です。導入側にとっての本質は職種名ではなく、「成果が出るまで誰が責任を持つ体制か」を契約前に見極めることです

まとめ

FDEは、生成AIの導入が「モデルの性能」ではなく「現場との統合」で失敗するという現実から生まれた職種です。ベンダー側のエンジニアが顧客の前線に立ち、課題定義から実装・定着・プロダクト還元までを引き受けることで、PoC止まりの構造を壊しに来ています。導入する側の企業にとっての実践的な示唆はシンプルで、ベンダーを「デモの出来」ではなく「成果までの伴走体制」で選ぶこと、そしてPoCの設計自体をFDE的に——実データ・実業務・数値基準で——組むことです。