AI導入の現場に立つ新職種「Forward Deployed Engineer」とは
Palantir発の新職種「Forward Deployed Engineer(FDE)」。LayerX・ログラス・ソフトバンクの求人を一次ソースで分析し、現場で得た学びを自社プロダクトに還元するFDEの本質と、自社で採用する際の設計を解説します。
エンジニア採用の現場で「Forward Deployed Engineer」、略してFDEという職種を見かける機会が増えてきました。
FDEは「顧客先に出向くエンジニア」と紹介されることが多く、コンサルタントとエンジニアを1人で兼ねるような職種です。顧客の現場に入って経営や業務の課題を聞き取り、自社のプロダクトを使って、その場で解決まで持っていきます。要件を固める人と手を動かす人が、ここでは1人に重なっています。
FDEがほかの職種と一線を画すのは、課題を解いたその先「何に価値を還元するか」です。現場で見つけた解を、自社のプロダクトそのものに作り込んで残していきます。コンサルティングや受託開発であれば、案件そのものや個人に知見が蓄積されますがFDEはそうではなく、ひとつひとつの課題解決を、プロダクトの機能として積み上げていきます。
そうして積み上げていくことで、眼の前の顧客にとっては共同開発したような自社課題にフィットしたプロダクトになり、また次の顧客には最初から備わっている機能となり大きな事業インパクトがあります。
Forward Deployed Engineerとは何を指す職種なのか
FDEは、顧客の業務に深く入り込んで課題を解き、そこで得た知見を自社プロダクトの開発に持ち帰るソフトウェアエンジニアです。
この職種を最初に作ったのはPalantirです。ソフトウェア業界のニュースレターThe Pragmatic Engineerによれば、Palantirは2010年代初期に、社内で「Delta」と呼ぶ役割としてFDEを生み出しました。
創業初期のPalantirは政府機関向けの導入が中心で、顧客が「何が欲しいか」を言葉で説明するのが難しい場面が多かった。そこでエンジニアを顧客の現場に直接送り込み、観察しながら作る形をとったのが始まりです。
Palantirの説明では、FDEは「one customer, many capabilities(ひとりの顧客に、多くの能力で向き合う)」という考え方の役割だとされています。同誌によれば、FDEは顧客チームに入り込んで働きながら、同時にコアのプロダクト開発チームの一員でもあります。2016年ごろまで、PalantirにはFDEのほうが通常のソフトウェアエンジニアより多く在籍していました。
LayerX公式YouTube『FDEの本質とは?』では、FDEは「顧客と接するビジネスの側と、自社プロダクトの側を結びつけて結果を出すエンジニア」と説明されています。「顧客先に常駐するのか」という問いには、100%の常駐はあまりしない、という応答がされています。プロトタイプの使い心地を確かめたり、現場をヒアリングしたりするために顧客先へ行くものの、成果を出すための時間の使い方として判断する、という話です。
呼称としては2010年代から存在していましたが、長くPalantirの周辺にとどまっていました。FDEがAIファースト企業の求人として広がり始めたのは2025年以降です。
なぜいまFDEが増えているのか
AIが社内で成果につながらない原因が、モデルの性能ではなく現場への実装にあると分かってきたからです。
デロイトが2026年に公表した調査「State of AI in the Enterprise」では、AIのパイロット(試験導入)のうち4割以上を本番運用に移せた企業は25%にとどまっていました。24カ国・3,235名のビジネスとITのリーダーを対象にした調査です。主要な業務プロセスをAIに合わせて作り直した企業も30%でした。多くの会社で、AIは試したけれど仕事の仕方は変わっていません。
モデルはどんどん賢くなっています。足りないのは、それを自社の業務に当てて成果に変える人です。ここに気づいた会社が、現場に入って実装まで担う人を増やし始めました。それがFDEです。
モデルを作る側も、コンサルティング業界も、同じ方向に動いています。AnthropicとOpenAIは2026年5月、それぞれ大手金融と組んで、エンジニアを顧客企業に送り込むAI導入の合弁会社を立ち上げました。どちらもライセンスを売るのではなく、人を送り込むPalantir型のFDEモデルを採っています。デロイト トーマツも2026年4月にFDE人材の活用を本格化すると発表し、6月にFDEマネジメントオフィスを設けると公表しました。完成したソフトを売って終わり、資料を渡して終わり、という形では、AIの導入が追いつかないという判断です。
日本では、この動きがとくに効きます。海外には、標準的なツールに業務を合わせて整えてきた会社が多くあります。一方、日本企業は業務もデータも会社ごとにばらばらです。標準的なAIツールを入れただけでは回らず、現場に入って業務を見ないと当て方が決まりません。
国内でFDEを職種表記そのままで募集している会社はどこか
2026年5月時点で公開求人を一次ソース確認できた国内企業から、LayerX・ログラス・ソフトバンクの3社を取り上げます。いずれも「Forward Deployed Engineer」または「FDE」を職種名そのものとして切り出しています。
企業 | 正式職種名 | 業務スコープ |
|---|---|---|
LayerX | 【Ai Workforce】Forward Deployed Engineer | 顧客業務の理解から、Ai Workforce上でのワークフロー実装、運用改善まで。現場の課題をプロダクト開発へ還元する |
ログラス | Forward Deployed Engineer(FDE)/AIソリューション本部 | 顧客の経営課題のAI実装を、コンサル・エンジニア・PdM混成チームで担当。ユースケースを共通化しLLM基盤の進化に還元する |
ソフトバンク | Forward Deployed Engineer(FDE)/SB OAI Japan合同会社 出向 | 戦略顧客へのLLM活用の技術リード。課題特定から設計、プロト、本番展開までのエンドツーエンド実装 |
LayerX Ai WorkforceのForward Deployed Engineer
LayerXは、生成AIプラットフォーム「Ai Workforce」を提供するAi Workforce事業部でFDEを募集されています。エンジニアブログでは、FDEを「お客さまとの最前線に立ち、業務を深く理解し、AIオンボーディングを実現する」役割だと説明されています。
業務は3つのフェーズに分かれています。導入前は、顧客の業務ドメインを理解して本当に解くべき課題を見極める。実装では、顧客の資料をAi Workforce上のワークフローに落とし込む。運用では「導入後こそが本番」として継続的な改善にコミットする、という流れです。
このFDEで目を引くのは、現場の仕事を自社プロダクトの開発に直接つなげている点です。エンジニアブログでは、ドキュメント読み解きを効率化する内製ツールの開発、業務ワークフローの自動生成に向けたR&D、高品質なプロンプトの自動生成といった成果が紹介されています。
FDEが現場で直面した課題が、そのままAi Workforceの開発テーマになっています。
ログラスのForward Deployed Engineer
ログラスは、経営管理クラウド「Loglass」を提供する会社です。CEO直下のAIソリューション本部でFDEを募集されています。
FDEは、コンサル・エンジニア・PdM(プロダクトマネージャー)・デザイナーからなる4〜5名の混成チームで動きます。顧客の経営企画や管理の部門と直接やりとりしながら、Loglassのデータ基盤やLLM基盤の導入、PoC(概念実証、アイデアが実現できるか試す検証)、運用までを担います。
この求人で目を引くのは、FDEを「単なるAI導入の支援者ではない」と最初に断っている点です。求人本文には、顧客ごとのユースケースを共通化し、Loglass LLM基盤の進化にフィードバックする、と書かれています。顧客の現場で得たものをプロダクトに残すこと。それを職種の定義そのものに書き込んでいます。
ソフトバンク(SB OAI Japan)のForward Deployed Engineer
ソフトバンクは、法人統括のSB OAI事業本部でFDEを募集されています。採用後はSB OAI Japan合同会社へ出向する形です。SB OAI Japanは、ソフトバンクとOpenAIが設立した合弁会社です。
業務は、戦略顧客に対するLLM・生成AI活用の技術リードです。顧客課題の特定、技術スコープの設計、アーキテクチャ設計から、プロトタイプ構築、本番環境への展開まで、エンドツーエンドで実装します。RAG(社内データを参照してLLMの回答精度を高める手法)やエージェント設計、ワークフロー自動化を扱います。
国内のFDE求人は「プロダクトへの還元」をどこまで設計に入れているか
3社の求人を読み比べると、「FDE」という同じ表記でも、現場で得た学びをどこに、どう還すかの設計がそれぞれ違います。
LayerXのFDEは、現場の課題をAi Workforceの開発テーマに直接つなげています。FDE自身が内製ツールやR&Dの成果を出し、プロダクトに作り込んでいく。顧客に入る人とプロダクトを作る人の距離がいちばん近いのが、LayerXの設計です。
ログラスのFDEも、現場の学びをプロダクトに戻すことを職種の中心に置いています。求人本文には、顧客ごとのユースケースを共通化してLLM基盤の進化にフィードバックする、と明記されています。CEO直下の混成チームでFDEがリードする形で、顧客対応とプロダクト改善を地続きにしています。
ソフトバンクのFDEは、戦略顧客へのエンドツーエンドの実装に重心があります。OpenAIのモデルという完成したプロダクトを、顧客の業務に当てていく役割です。求人本文を読む限りでは、自社プロダクトへの還元よりも、顧客ごとの実装の質が職種の中心になっているように見えます。
「FDE」という言葉そのものに、決まった中身があるわけではありません。同じ表記の求人でも、現場の学びを誰がどこに還すのかは会社ごとに違います。ここを決めないままFDEを募集すると、「顧客先に行けるエンジニア」という曖昧な像だけが残り、採用要件がぼやけます。
FDEは受託開発・SESと何が違うのか
FDEは顧客の現場に入って開発します。その姿だけ見ると、受託開発やSES(システムエンジニアリングサービス、エンジニアを客先に常駐させる人材サービス)と似ています。ただ、何を成果とするか、学びがどこに残るかが違います。
観点 | FDE | 受託開発 | SES |
|---|---|---|---|
顧客に提供するもの | 顧客課題の解決と、継続的な改善 | 契約で定めた納品物 | エンジニアの稼働工数 |
顧客との関わり方 | 要望に基づき現場で共同開発する | 要件をもとにベンダー側で開発し納品する | 客先に常駐して指示を受ける |
学び・知見の蓄積先 | 自社プロダクト | 案件ごとにとどまり、横展開しにくい | 個人にとどまり、組織に残りにくい |
次の顧客への効き方 | プロダクトが育つほど速く、質も高くなる | 共通機能や自社パッケージ化している部分以外、基本は毎回ゼロから | 基本は毎回ゼロから |
受託開発は、契約で決めた納品物を作って渡す形です。SESは、エンジニアの稼働そのものを提供します。どちらも、突き詰めれば働いた時間か納品物に対して対価を受け取ります。案件が終わると、そこで得た知見は案件ごとに閉じるか、担当した個人に属したまま、次に引き継がれにくくなります。
FDEが違うのは、顧客の要望に基づいて開発しながら、その過程で得た知見を自社プロダクトに作り込んでいく点です。大治様は同じ動画で、顧客向けに作ったものを汎用性のある形でプロダクトに取り込むこともある、意見を言うだけでなく自分でコードも書く、と話しています。
顧客から見ると、FDEとの関わり方は「できあがった製品を買う」のとは違います。自分たちの要望をもとに、現場で一緒に作っていく相手になります。業務を理解した人がその場で開発するので、要望が直接プロダクトに反映されていく。納品して終わりではなく、運用しながら改善が続きます。受託開発よりも、共同開発に近い関わり方です。
ベンダーから見ると、顧客ごとに作った解をプロダクトに作り込むことで、次の顧客には最初から効く状態になっていきます。大治様は、Palantirに在籍したおよそ3年のあいだにプロダクトの成熟度がはっきり上がった、初期は案件ごとに作っていたものが、後半は既存の機能でこなせるケースが増えた、と振り返っています。現場の解がプロダクトに溜まるほど、FDEの仕事は速く、軽くなります。
AIの導入支援でこの形が効くのは、LLMの「業務への当て方」がまだ十分にプロダクト化されていないからです。だからまず人が現場に入る。そして入った人が得た知見を、プロダクトや社内の仕組みに残していく。これができるかどうかで、AI導入支援が単発で終わるか、会社の資産として積み上がるかが分かれます。
自分たちもエンジニア採用支援の現場に深く入る仕事をしていて、同じことを感じています。現場で得たスカウト設計や母集団形成の知見を、AIで再現できる形に作り込んでいく。現場に入る人と仕組みを作る人が分かれていると、知見が個人の頭の中にとどまり、次の案件に効きません。
自社でFDEのようなポジションを設計するときのポイント
FDEという肩書をそのまま使うかどうかは、本質的な論点ではありません。顧客の現場に入る人を採用するとき、その人の学びをどう活かすのかを設計できているか。判断材料として4つのポイントを挙げます。
還元先のポイント
現場で得た学びを受け止めるプロダクトやチームが、自社にあるでしょうか。
ここが無いままFDE的なポジションを作ると、その人はいい仕事をしても、顧客先での常駐に近い働き方になります。学びが個人に閉じてしまう。FDEを置く前に、還元先を用意できているかを先に確認するのがおすすめです。
評価軸のポイント
顧客の満足度だけで、その人を評価していないでしょうか。
顧客満足はもちろん大事です。ただFDEの価値は、そこで得た知見をプロダクトや社内の仕組みにどれだけ残せたかにもあります。「何件こなしたか」だけでなく「何をプロダクトに還したか」を評価軸に入れると、職種の意味がぶれにくくなります。
体制のポイント
顧客に入る人と、プロダクトを作る人の距離は近いでしょうか。
LayerXのFDEが現場の課題をそのまま開発テーマにできているのは、両者の距離が近いからです。間に何段階も挟まると、現場の手触りが薄まったまま開発に渡ります。
戦略を描く人と実装する人をどう組むかも論点です。Palantirには案件の筋を見るDS(デプロイメントストラテジスト)がFDEの手前にいます。デロイト トーマツも、戦略役のDSと実装役のFDEを組ませる体制を公表しています。1人にすべてを求めるのか、役割を分けて組ませるのか。自社の規模で現実的な形を選ぶのがおすすめです。
採用要件のポイント
コードが書けることだけで、人を測っていないでしょうか。
FDEに求められるのは、顧客の業務を理解して言語化する力、それをコードで形にする力、プロダクトに何を残すかを考える力の3つです。3社の求人を見ても、必須スキルにはエンジニアリング経験と並んで、顧客と直接向き合う経験が挙げられています。技術力だけで採ると、現場で言葉が通じず苦労する場面が出てきます。
おわりに|FDEは「顧客に出向くエンジニア」ではない
Palantirがこの職種を作ったときから、FDEの中心にあるのは、現場で得た学びを自社プロダクトに残していくことでした。顧客にとっては要望に基づく共同開発になり、ベンダーにとってはプロダクトが育っていきます。国内のLayerX・ログラス・ソフトバンクの求人も、現場の学びをどこに、どう還すかでそれぞれ違いが出ています。
自社でFDEのようなポジションを考えるなら、求人票を切り出す前に、整理しておきたいことがあります。どんなサービスモデルで顧客に向き合うのか、組織やプロダクト、ビジネスモデルとどうつなげるのか。そこを一体で検討したうえで、求人の形に落とし込んでいく。この順番で進めると、FDEは自社で機能しやすくなります。
以前このブログでは「AI Builder」という新職種を取り上げました。FDEも、AIによって新しく立ち上がってきた職種のひとつです。AI時代の採用では、こうした新しい職種をひとつずつ理解していくことが、自社の採用設計の助けになります。
エンジニア採用やAI時代の職種設計について壁打ちしたい方は、お気軽にご連絡ください。
出典
The Pragmatic Engineer「What are Forward Deployed Engineers, and why are they so in demand?」 https://newsletter.pragmaticengineer.com/p/forward-deployed-engineers
大治慶晃様(LayerX Ai Workforce事業部 FDE Enabler)インタビュー(LayerX公式YouTube) https://www.youtube.com/watch?v=GM-OyMCnqtc
LayerXエンジニアブログ「Forward Deployed Engineerの募集を開始しました」 https://tech.layerx.co.jp/entry/ai-llm-fde
LayerX「【Ai Workforce】Forward Deployed Engineer」求人 https://open.talentio.com/r/1/c/layerx/pages/110968
ログラス「Forward Deployed Engineer(FDE)」求人 https://hrmos.co/pages/loglass/jobs/1813462408235663396227
ソフトバンク「Forward Deployed Engineer(FDE)/SB OAI Japan合同会社 出向」求人 https://www.softbank.jp/recruit/career/positions/detail/004813/
デロイト「State of AI in the Enterprise」調査プレスリリース https://www.deloitte.com/us/en/about/press-room/state-of-ai-report-2026.html
デロイト トーマツ「企業価値起点のコンサルティングサービス強化に向け、FDE人材の活用を本格化」 https://www.deloitte.com/jp/ja/about/press-room/nr20260430.html
TechCrunch「Anthropic and OpenAI are both launching joint ventures for enterprise AI services」 https://techcrunch.com/2026/05/04/anthropic-and-openai-are-both-launching-joint-ventures-for-enterprise-ai-services/
永井涼平
HRdev代表
レバレジーズ、クラウドワークス等を経て2021年にHRdev創業。18年以上エンジニア採用の最前線に立ち、ログラス・MFS・SALESCORE等の支援実績を持つ。
