


生成AIを業務に入れようとした会社の多くが、同じところでつまずいています。試しに使ってみる段階(PoC)まではうまくいくのに、毎日の業務で使われる「本番」までたどり着かないのです。この壁を越えるための職種として、米国で急速に広がっているのがフォワードデプロイドエンジニア(FDE:Forward Deployed Engineer)です。
FDEは、AIやソフトウェアを提供する会社に所属しながら、顧客の現場に入り込み、顧客の業務に合わせたシステムを自分の手でつくって、本番で動くところまで責任を持つエンジニアです。もとはデータ分析企業のPalantir(パランティア)が使っていた職種名ですが、2025年以降はOpenAIやAnthropicといったAI企業が採用を本格化させ、求人が1年で8倍を超える規模に伸びました。
この記事では、FDEの定義と生まれた経緯、急増した理由、ソリューションアーキテクトやカスタマーサクセスなど似た職種との違い、具体的な仕事の中身、そして日本企業がこの役割をどう置けばよいかまでを解説します。
フォワードデプロイド(forward deployed)は「前線に配置された」という意味です。FDEは、自社の開発拠点ではなく顧客の現場という「前線」に身を置き、そこで実際に動くシステムをつくるエンジニアを指します。
FDEの仕事は、顧客の課題を聞いて提案書を書くことでも、製品の使い方を説明することでもありません。顧客のデータや既存システム、業務の流れを理解したうえで、自社のプロダクトを組み合わせ、必要なコードを自分で書き、顧客の業務の中で本当に使われる状態にすることです。
FDEという働き方を職種として確立したのは、政府機関や大企業向けにデータ分析基盤を提供するPalantirです。Palantirは公式ブログ「Dev versus Delta」で、社内のエンジニアを2種類に分けて説明しています。
「Delta」という呼び名は、創業初期に事業開発のチームをNATOのフォネティックコード(Alpha、Bravo…)で呼んでいた名残だと同社は説明しています。Palantirにはもう1つ、プロダクトマネージャーとエンジニアと戦略担当を兼ねたような「Echo(デプロイメント・ストラテジスト)」という役割もあり、DeltaとEchoが組んで顧客の現場に入るのが基本の形です。
この「Dev」と「Delta」の分け方は、FDEを理解するうえでいちばん大事なポイントです。FDEは、製品を汎用的に磨く人とは別に、個別の顧客で成果を出し切る人を置くという考え方から生まれた職種なのです。
技術と現場をつなぐ人材をお探しですか?
talentalのBizDev人材が伴走した事例をご覧いただけます。
米国の求人サイトIndeedのデータをBusiness Insiderが報じたところによると、FDEの求人は2025年4月の643件から、2026年4月には5,330件に増えました。1年で約8.3倍(前年比729%増)です。1つの求人サイトでの件数であり、実際に採用された人数ではない点には注意が必要ですが、職種としての立ち上がりの速さははっきり表れています。
急増を引っ張っているのは、生成AIのモデルを開発する企業です。
国内でも、転職サイトでFDEの求人が年収800万〜1,500万円の水準で掲載されるようになっています(2026年5月時点)。
AI企業がここまでFDEに力を入れるのは、AIの価値が「モデルの性能」だけでは決まらないことがはっきりしてきたからです。
マサチューセッツ工科大学(MIT)の研究プロジェクトNANDAが2025年にまとめた予備調査報告書『The GenAI Divide』では、企業の生成AIの試験導入のうち、売上に目に見える効果が出たのは約5%にとどまるとされました。報告書は、原因をモデルの性能や規制ではなく、AIが現場の業務の流れに合っていないことに求めています。調査の規模は大きくなく、すべての企業に当てはまる失敗率として読むべきではありませんが、「導入の現場」に課題があるという見立ては多くの企業の実感と重なります。
汎用的なAIは、個人が使うぶんには柔軟で便利です。しかし会社の業務で使うには、その会社のデータ、権限、承認の流れ、例外処理に合わせて組み込む必要があります。その「組み込み」を、製品を知り尽くした側のエンジニアが現場でやり切るのがFDEです。
AIが現場で期待どおりに動くための前提づくりについては、こちらの記事でも解説しています。
FDEは、顧客と技術の間に立つという点で、いくつかの職種と重なります。違いは「いつ関わるか」「何を渡すか」「誰の成果に責任を持つか」で整理するとわかりやすくなります。
ソリューションアーキテクトは、顧客の課題に対して技術的な全体設計を描く職種です。設計図を描くところまでが中心で、実装は顧客側や別のチームが担うことが多くなります。FDEは設計だけでなく、自分でコードを書いて本番で動かすところまでを担います。
セールスエンジニアは、契約の前に技術面から営業を支える職種です。デモや技術的な質問への回答を通じて、受注につなげるのが役割です。FDEが本格的に動くのは契約の後で、受注したプロダクトが顧客の業務で成果を出すまでを担います。
カスタマーサクセスは、導入した製品を顧客が使いこなし、継続して利用してもらえるように支援する職種です。使い方の定着や活用の提案が中心で、基本的にコードは書きません。FDEは、製品をそのまま使うだけでは解けない課題を、実装によって解くところに違いがあります。
日本の読者にとって最も紛らわしいのが、SIer(システムインテグレーター)のシステムエンジニアとの違いでしょう。顧客の業務に合わせてシステムをつくるという点では似ています。違いは2つあります。
同じく「エンジニア」と名のつく新しい職種に、GTMエンジニアがあります。GTMエンジニアは、自社の営業・マーケティングの仕組みをデータとAIで組み立てる職種です。FDEは顧客の業務の中にプロダクトを組み込みます。前者は売上が生まれるまでの流れを、後者は売れたあとに成果が出るまでの流れを、それぞれエンジニアリングで支えていると捉えると整理しやすくなります。
FDEの仕事は、顧客の現場に入ってから、成果が出て手を離すまでの流れで整理できます。
最初の仕事は、顧客が本当に解きたい課題を特定することです。担当者へのヒアリングだけでなく、実際の業務の流れ、使われているデータの形、例外的な処理がどこで起きているかまで、現場で確かめます。「何を自動化したいか」より先に「業務のどこで時間とミスが生まれているか」を押さえるのが、PoC止まりを避ける最初の一歩です。
AIやプロダクトが役に立つかどうかは、顧客のデータにきちんとアクセスできるかで決まります。社内のデータベースや業務システムとの連携、権限の設定、データの整形など、地味ですが欠かせない作業をFDEが担います。
プロダクトの標準機能だけでは足りない部分を、FDEが実装します。AIの領域では、業務に合わせたエージェントの設計、社内文書を参照させる仕組み、出力をチェックする仕組みなどが典型です。試作で終わらせず、実際の業務で毎日使われる状態にして、運用できる形で引き渡すところまでが仕事です。
複数の顧客で同じ要望が出てきたら、それは個別対応ではなく製品の機能にすべきものかもしれません。FDEは現場で得た気づきを開発チームに伝え、個別の工夫を、多くの顧客が使える機能に変えていくきっかけをつくります。この役割があるかどうかが、FDEと単なる受託開発を分ける線になります。
FDEは自分でコードを書く職種です。Pythonなどでの開発経験に加え、AIの領域では、大規模言語モデル(LLM)を使ったアプリケーションの実装、社内データを参照させる仕組み(RAG)、エージェントの設計、外部のツールやデータとの連携といった知識が求められます。試作をつくれるだけでなく、本番の業務で止まらない品質まで持っていけるかが問われます。
顧客の業界や業務の流れを理解し、「何が本当の課題か」を顧客と一緒に言葉にする力が欠かせません。技術に詳しくない担当者や経営層に、できることとできないことを平易に説明する場面も多くあります。
顧客の現場にいると、要望は次々に出てきます。すべてに応えていると、いつまでも終わらない個別開発になってしまいます。成果につながる範囲を見極め、やらないことを顧客と合意する判断力は、FDEにとって技術力と同じくらい重要です。
FDEは米国のAI企業で生まれた職種ですが、考え方そのものは日本企業にも当てはまります。立場ごとに置き方を整理します。
自社でAIプロダクトや業務SaaSを提供している会社では、大口顧客や導入の難しい業界向けにFDEを置くことが考えられます。その際は、次の2点を最初に決めておくと失敗しにくくなります。
後者がないと、FDEは「無償のカスタマイズ部隊」になり、プロダクトの会社が受託開発の会社に近づいていきます。
AIを導入する側の事業会社にとって、FDEは「ベンダーから来る人」です。しかし、ベンダーのFDEがどれほど優秀でも、受け入れる社内に業務とAIの両方がわかる担当者がいなければ、現場の課題を正しく伝えることも、引き渡されたシステムを運用し続けることもできません。
導入を成功させたい事業会社は、ベンダーのFDEと組む「社内側のFDE役」を置くことを考える価値があります。業務の流れを知る事業部門の人材と、AIの実装を理解する人材がペアになる形が現実的です。
AIを事業開発のプロセスに組み込む進め方については、こちらの記事で解説しています。
FDEに求められる「実装力」と「業務を理解する力」を兼ね備えた人材は、国内ではまだ多くありません。正社員で採用しようとすると、時間もコストもかかります。
そこで、立ち上げの数カ月だけ外部の人材に入ってもらい、業務委託や副業の形で役割を試してみるのも1つの方法です。最初の数件の導入で「どこまで個別対応し、何を製品に戻すか」の型をつくってから、社内で採用・育成する人材の要件を決めると、採用の失敗も減らせます。外部人材の探し方については、こちらの記事が参考になります。
正社員採用・業務委託・顧問など、外部人材に任せる方法ごとの違いは、こちらのガイドで比較しています。
急速に広がる職種には、慎重な見方もあります。導入を考えるなら、次の点は押さえておくべきです。
FDEは、顧客ごとに人が入り込んで成果を出す仕組みです。売上に対して人件費がかかるため、ソフトウェアだけを売る場合より利益率は下がります。顧客が増えるほどFDEも増やさなければならないなら、それはソフトウェア企業ではなくコンサルティング企業に近い形です。FDEへの投資は、現場の学びを製品に戻して、次の顧客では人手を減らせる見込みがあってこそ成り立ちます。
顧客ごとに個別の実装が増えると、それぞれを保守し続けるコストが膨らみます。プロダクトのバージョンが上がるたびに、各顧客の個別実装を直す必要が出てくることもあります。引き渡しの際に、顧客側で運用できる形にしておくことが欠かせません。
職種名が流行すると、中身の伴わない使われ方も増えます。米国でも「FDEは肩書きを変えたコンサルタントではないか」という議論があります。ベンダーから「FDEが伴走します」と提案されたときは、実際にコードを書いて本番まで持っていくのか、提案と助言にとどまるのかを確認するとよいでしょう。「AIエージェント」を名乗る製品の見極め方と同じく、名前ではなく中身を見ることが大切です。
フォワードデプロイドエンジニア(FDE)は、顧客の現場に入り込み、プロダクトを顧客の業務に組み込んで、本番で成果が出るところまで責任を持つエンジニアです。Palantirが「Dev」と「Delta」を分けたことに始まり、生成AIの導入が「PoC止まり」になりやすいことを背景に、2025年以降はOpenAIやAnthropicが採用を本格化させ、求人は1年で約8.3倍に伸びました。
FDEの本質は、汎用的な製品をつくる人とは別に、個別の顧客で成果を出し切る人を置き、その学びを製品に戻すという分業にあります。日本企業でも、AIプロダクトを売る側は「成果の定義」と「製品に戻すルール」を決めたうえで置き、AIを導入する側は社内にFDE役を置くことで、AI導入の成功率を高められるはずです。人材が少ない今は、立ち上げ期を外部の人材で始め、型をつくってから社内に広げるのも現実的な進め方です。
技術と現場をつなぐ人材をお探しですか?
ご覧いただいている『月刊タレンタル』を運営するtalental(タレンタル)株式会社では、BizDev領域の即戦力人材レンタルサービス「talental」を提供しています。
領域特化型の人材事業の立ち上げ、自治体向けサービスの事業推進、オウンドメディアを活用したマーケティング手法の確立、法人向け研修のサービス設計など、さまざまなプロジェクトを手掛けるtalental。当社所属のBizDev人材が実際にどう伴走したのかを、導入事例としてご紹介しています。