FDE（Forward Deployed Engineer）は、顧客の現場で解く課題を決め、AIやソフトウェアを本番で動く形まで実装し、使われて業務成果が出るところまで担うエンジニアです。
本記事で扱うFDEは、職種としてのForward Deployed Engineerを指します。
顧客先で働く点だけを見るとSESや客先常駐SEと重なりますが、判定の軸は働く場所ではありません。課題発見・本番実装・成果の測定・知見の還元をどこまで持つかで、FDEと呼べるかどうかが分かれます。
転職先として検討している人が自分の経験を転用できるのか、法人側が自社にFDEを置くべきなのか。求人票やサービスを見たときに見分けられる基準まで扱います。
FDEとは？
FDEは、顧客や利用部門と直接話して解く課題を決め、AIやソフトウェアを本番で動く形まで実装し、現場で使われて業務成果が出るまで担うエンジニアです。顧客先にいるかどうかは判定条件になりません。
担当範囲は、課題発見 → 技術スコープの確定 → 設計・実装 → 本番展開 → 定着・評価 → 知見の還元という流れで並びます。同じFDEという名前でも、この流れのどこまでを持つかは企業ごとに違います。名称ではなく責任範囲のどこを持つかで見分けられるため、まず略称の意味と担当工程を押さえておくと、求人票の読み方が変わってくるでしょう。
FDEはForward Deployed Engineerの略
FDEはForward Deployed Engineerの略で、日本語ではフォワードデプロイドエンジニアと表記します。Forwardは顧客との接点に近い前線、Deployedはその現場へ配置された状態を表す言葉です。
ただし語源から役割が決まるわけではありません。PalantirのForward Deployed Software Engineer求人ではFDSEという表記を使っており、企業によって略称も職種名も違います。
AIソリューションエンジニア、ソリューションアーキテクトなど別の呼び方で、FDEと近い責任範囲を持つ職種もあります。逆にFDEという名前でも担当工程が狭い求人も少なくありません。企業固有の職種名は、その企業の求人と公式説明を正として読んでください。
見るべきは略称の一致ではなく、次に扱う担当工程です。
FDEの担当範囲は課題発見から本番運用・改善まで
FDEは、渡された仕様を実装する役割ではありません。何を解くかを決め、本番で使われる状態を作り、効果と品質を見て直すところまでが担当範囲に入ります。OpenAIのForward Deployed Engineer求人では、Discovery（課題の掘り起こし）から技術スコープの確定、設計、構築、本番展開までを1人の担当範囲に置き、成功を本番採用・測定可能な業務影響・Evalにもとづくフィードバックで測ります。
| 工程 | FDEの行動 | 完了条件 |
|---|---|---|
| 課題発見 | 業務資料とデータを読み、担当者の操作と例外を確認して解く範囲を決める | 対象業務と対象外が文書で合意されている |
| 技術スコープ | 使うモデル、データ接続、権限、想定コストを決める | 実装方式と検証範囲が確定している |
| 設計・実装 | バックエンド、画面、権限、ログまで本番構成を作る | 本番環境で対象者が操作できる |
| 本番展開 | 利用部門への展開、運用手順、エスカレーション先を決める | 対象者が日常業務のなかで使っている |
| 定着・評価 | 利用率と業務指標を見て、Evalで品質を確認して直す | 決めた指標が基準を満たしている |
| 知見の還元 | 共通する課題をプロダクト機能、評価セット、手順書へ戻す | 次の案件で再利用できる形になっている |
Evalは、想定する質問と期待する回答をあらかじめ用意し、出力の品質を続けて確認する仕組みです。この列があるかどうかで、デモ止まりの案件と本番運用まで進んだ案件が分かれます。
6工程のうち一部だけを担うFDEもいるため、これを全社共通の厳密な職務定義として扱う必要はありません。求人票の完了条件の書き方に、どこまでが担当かはほぼ出ています。
FDEが注目される理由は、AI導入がPoCから本番定着の段階へ進んだから
生成AIのモデルやSaaSを契約しただけでは、企業ごとの業務手順、権限、既存システム、品質基準には収まりません。PoCは、本格導入の前に技術的に実現できるかを試す検証を指しますが、ここで回答精度が基準を満たしても、誰がどのデータへアクセスできるのか、誤った回答を誰が確認するのか、公開の承認を誰が出すのかが決まらないまま止まる案件が出てきます。
| PoCで分かること | 本番定着に追加で必要なこと |
|---|---|
| 想定した業務でAIが機能するか | 対象業務の例外処理と、手戻りが出たときの手順 |
| モデルの回答品質 | 参照データの権限とログ、監査で見られる条件 |
| 技術的に実現できるか | 利用部門への展開と、操作を覚えてもらう段取り |
| 一部の担当者による試用結果 | 利用率と業務指標の測り方、改善を続ける担当者 |
右の列は技術の課題ではなく、現場の業務と権限にまたがる課題です。LayerXのFDE募集記事では、顧客業務の資料を読み、ヒアリングした内容をAIワークフローやAIエージェントへ落とす仕事としてこの役割を置いています。技術と現場を往復して本番まで運ぶ担当が空いていると、精度の高いデモが残るだけで終わります。
逆に、標準SaaSの設定だけで要件を満たせる場合は、専任のFDEを置く必要性は高くありません。右の列に空欄が多い企業ならFDE相当の役割が効き、空欄がない企業なら別の投資先を選ぶ判断になるでしょう。
FDEの仕事内容
FDEの1週間には、顧客への業務ヒアリング、データの確認、実装、利用状況のチェックが並行して入ります。工程を順番に消化する開発ではなく、現場で分かったことを実装へ戻し、動いたものをまた現場で試す往復が中心です。
仕事は4つに分かれます。解く課題を決める、AIワークフローを実装して本番へ出す、利用と成果を測って直す、得た知見を再利用できる形へ戻す。このうち工数が読みにくく、担当者の力量差が出やすいのは3つ目の定着と評価です。
現場の業務と制約を把握し、解く課題を決める
要望をそのまま仕様にしないところから仕事が始まります。「問い合わせ対応を自動化したい」という依頼を、対象になる質問の種類、参照するデータ、AIに回答させない条件、例外が出たときの判断者まで分解します。
そのために見るのは資料ではなく、実際の手順です。
- 入力：どの資料、システム、口頭のやり取りから情報が来るか
- 現行手順：誰が何分かけて、どの順番で処理しているか
- 例外：頻度は低いが処理を止めてしまう条件は何か
- 判断者：内容を確認して承認するのは誰か
- 完了条件：どの状態になれば業務として終わるか
顧客の機密情報を扱う場合は、資料を預かる前に権限、保管場所、利用の条件を確定させます。ここを後回しにすると、実装が進んだあとで参照データを差し替える手戻りが起きます。
ヒアリングの前に、この5項目を空欄のまま書き出し、埋まらない欄をそのまま質問へ変えてください。
AIワークフローを設計・実装して本番へ展開する
FDEが作るのは動作デモではなく、業務で使い続けられるシステムです。利用部門が毎日触る前提に立つと、回答を生成する部分以外が品質を決めるためです。
実装対象はAPI連携、RAGの参照範囲、AIエージェントの動作範囲、バックエンド、操作画面、権限、ログ、失敗したときに人へ引き継ぐ導線まで広がります。RAGは、社内文書などを検索してからAIに回答させる仕組みを指します。回答を作れるところまでで止めず、参照権限とエラー時の扱いまで決めるのがFDEの範囲です。AIエージェントそのものの仕組みは、AIエージェントの仕組みと生成AIとの違いで確認できます。
すべてを1人で実装するとは限りません。社内のエンジニア、データ担当、セキュリティ担当と役割を分けて進めます。フルスタックなら何でも作れるという話ではなく、専門チームと技術判断を合わせられる広さが求められます。
そして、動くものができた時点はまだ完了ではありません。
利用率・業務効果・Evalを見て改善する
FDEの完了条件は、システムが動くことではありません。対象者が実際に使い、決めた業務指標と品質基準を満たした状態です。回答精度だけをすべての案件の共通指標にはしません。
| 指標 | 何が分かるか | 次の改善 |
|---|---|---|
| 利用率 | 対象者のうち何人が実際に使っているか | 使われていない業務の手順と操作画面を見直す |
| 1件あたりの処理時間 | 業務時間が短くなったか | 短縮していない工程を特定し、自動化する範囲を変える |
| 有人対応へ戻った件数 | AIが扱えない条件がどこにあるか | 回答範囲を再定義し、参照データを足す |
| Evalの合格率 | 想定質問への回答品質が基準を満たすか | プロンプトと参照範囲を直し、評価セットを追加する |
| 手戻りの発生件数 | 出力をそのまま業務で使えているか | 出力形式と確認手順を変える |
数字は業務の感覚へ置き換えて見ます。1件10分かかっていた確認が3分になれば、月200件の業務では約23時間分の作業が減る計算です。ここまで出せると、AI導入の効果を精度の話ではなく工数の話として社内で説明できるようになります。
KPIは業務ごとに変えます。問い合わせ対応なら正答率に加えて利用率、有人対応へ戻った件数、1件あたりの対応時間を見ますが、資料作成なら見る指標が変わるでしょう。表の5行のうち、AIデモの検証段階で触るのは上から4行目だけです。
現場の知見を再利用可能な機能や型へ戻す
個別の顧客で見つけた共通課題を、プロダクト機能、評価セット、テンプレート、手順書へ戻すことで、FDEモデルは受託開発の積み上げになりにくくなります。Palantirの求人（FDSE表記）でも、顧客の重大な課題を直接理解し、小さなチームで重要度の高いプロジェクトを端から端まで所有する役割として置かれています。
ただし顧客固有の情報をそのまま持ち出すことはできません。匿名化、権利、契約、秘密保持の範囲を守ったうえで、判断の型だけを社内へ残します。たとえば複数の案件で共通する評価手順を、顧客データを含まない検証テンプレートへ変えるやり方です。
この還元先があるかどうかが、次に扱う他職種との比較で最も差の出る部分になります。
FDEと他職種の違い
FDEの能力は、ソフトウェアエンジニア（SWE）、コンサルタント、PdM、ソリューションアーキテクトと重なります。違いが出るのは能力の数ではありません。顧客課題の定義から本番実装、定着、成果までを同じ当事者として追う点です。
比較の軸を完了条件に置くと、肩書きの重なりに引きずられずに読めます。以下の表で職種ごとの重心を並べたうえで、混同されやすい3つの職種との差を個別に見ていきます。
| 職種 | 主な起点 | 主な成果物 | 完了条件 | 顧客接点 | コード実装 |
|---|---|---|---|---|---|
| FDE | 顧客の業務課題 | 本番で使われるシステムと再利用できる型 | 利用と業務指標が基準を満たす | 常時（利用部門と直接） | あり（本番コード） |
| ソフトウェアエンジニア | プロダクト要件・技術課題 | 機能・システム | 仕様と品質基準を満たすリリース | 案件により異なる | あり（本番コード） |
| コンサルタント | 経営・業務課題 | 方針、要件、実行計画 | 合意された計画と意思決定 | 常時 | 案件により異なる |
| PdM | 市場と利用データ | プロダクトの方針と優先順位 | 決めた指標の達成 | 間接（利用データ経由が多い） | 通常は担当外 |
| ソリューションアーキテクト | 技術要件と構成 | 構成方針と技術選定 | 構成の妥当性と実現可能性 | 提案・導入時 | 部分的 |
| SES・客先常駐SE | 依頼元が決めた作業範囲 | 契約で定めた成果物・工数 | 契約範囲の完了 | 常駐先により異なる | あり（範囲内） |
表に置いたのは代表的な重心で、職種全体に画一的な線を引くものではありません。顧客会議に出るSWEも、本番コードを書くコンサルタントもいます。行動1つで判定せず、完了条件がどこに置かれているかで比べてください。
ソフトウェアエンジニアとの違いは、顧客の業務成果まで守備範囲に入ること
一般的なSWEは、プロダクトやシステムの品質と開発の進め方を主軸に置きます。FDEはその前後、つまり解く課題の定義と導入後の成果まで担当範囲に入れます。
機能を仕様どおりリリースして完了になるのか、現場の利用率と業務指標を見て初めて完了になるのか。同じ実装スキルを持っていても、この置き場所が違えば日々の判断は変わってきます。
もちろん顧客接点と導入責任を持つSWEはFDEに近く、SWEを社内開発だけの職種として区切る必要はありません。差が出るのは担当範囲の広さそのものではなく、完了条件の位置です。
コンサルタント・PdMとの違いは、提案だけで終わらず本番コードも書くこと
コンサルタントやPdMとFDEは、業務課題と優先順位を扱う点で近い位置にあります。分かれるのは、FDEが自分で技術スコープを決め、本番品質の実装と展開まで持つところです。
デロイト トーマツはFDE人材の活用を2026年6月から本格化し、構想から実装、定着までをつなぐ方針を打ち出しました。同社はDeployment StrategistとFDEを別の役割として置き、フロントエンド、バックエンド、インフラ、データ連携にまたがるスキルをFDE側に求めています。役割を分けて置いていること自体が、提案と実装が同じ人の担当とは限らない現実を表しています。
AI導入のロードマップを提示して終わる役割と、最初の対象業務を選んでRAG、権限、評価まで実装する役割は別物です。ただし実装まで担う技術コンサルタントやPdMもいるため、職種名だけで線を引けません。AI時代のコンサルタント側の変化については、AI時代に求められるコンサルタントの役割で扱っています。
提案の質で評価される役割を望むならコンサルタント、実装した結果で評価される役割を望むならFDEが近い位置にあります。
SES・客先常駐SEとの違いは、働く場所ではなく責任範囲で見る
FDEとSESは、顧客の環境で働く場合がある点は共通します。ただし判定の軸は契約形態でも勤務場所でもありません。
「顧客先にいるからSESと同じ」という見方で読むと、求人の中身を取り違えます。次の5項目で確認してください。
- 課題を決める権限：解く課題を自分で定義するか、依頼元が決めた要件を受け取るか
- 技術選択：モデル、構成、データ接続の方式を提案・決定できるか
- 実装：本番で動くコードを自分で書くか、指示された範囲を実装するか
- 導入後KPI：利用率や業務指標に責任を持つか、納品で完了か
- 知見の還元先：得た知見をプロダクトや共通の型へ戻すか、案件のなかで終わるか
SESでも高い裁量と成果責任を持つ案件はあります。この5項目は職種名や契約形態で自動的に決まるものではなく、案件ごとに答えが変わります。準委任、派遣、請負といった契約形態の法的な違いには踏み込みませんが、5項目の答えを左右する要因のひとつです。
決められた機能の実装要員として入るのか、現場の課題から作るものを決めて成果まで見るのか。同じ「顧客先で働く」という言葉の中身が、ここで分かれます。
裁量と成果責任を広げたい人はFDE型の求人、担当する技術領域を深めたい人は5項目のうち技術選択と実装に重心がある求人が合います。求人票を見るときは、この5つに答えられる記述があるかを先に探してください。
FDEに必要なスキル
コードが書けるだけではFDEの担当範囲は回りません。逆に、業務理解だけでも足りません。
必要なのは、本番品質のAIシステムを作る技術力、曖昧な要望を実装できる課題へ落とす力、完了条件が違う関係者の意思決定を進める力の3つです。特定の言語や資格の一覧ではなく、この3領域が自分のなかでどう埋まっているかで判断されます。最も比重が大きいのは技術力ですが、残りの2つが欠けると本番導入の直前で案件が止まります。
本番品質のAIシステムを作る技術力
FDEの技術力は、モデルの知識量ではなく、本番環境で動かし続けられるかで測られます。OpenAIのFDE求人が成功の基準に本番採用とEvalを置いているのも、そこが評価の対象になるからです。
| スキル | 使う場面 | 不足したときに起きること |
|---|---|---|
| Python・JavaScriptなどの実装 | 業務ロジック、API連携、操作画面 | 検証環境の試作で止まり、本番へ渡せない |
| API・データ連携 | 既存システムや社内データとの接続 | AIが参照できるデータが揃わず、回答が業務に合わない |
| クラウドとインフラ | 本番環境、権限、コスト管理 | 動作は確認できても、運用と費用の見通しが立たない |
| セキュリティと権限 | 参照範囲、監査ログ、機密情報の扱い | 情報部門の確認が通らず、公開まで進まない |
| LLMの評価（Eval） | 回答品質の基準づくりと継続的な確認 | 改善の判断が体感頼りになり、品質が落ちても気づけない |
RAGで回答を作れる状態と、権限、監査ログ、評価、障害時の切り戻しまで説明できる状態は別物です。すべてを単独で熟達する必要はありませんが、専門チームと技術判断を合わせられる広さは求められます。Pythonを学べばFDEになれるという単純な話ではないでしょう。
この表のうち、AIデモの作成では触らずに済むのは下の3行です。転職時に差が出るのも同じ3行です。
曖昧な業務課題を実装可能な範囲へ落とす力
「AIで効率化したい」という要望のままでは実装に入れません。対象業務が決まらず、完了条件も測り方も置けないからです。
FDEはこれを、対象業務、利用者、参照データ、例外、KPI、期限を持つ技術課題へ変換します。たとえば「営業を効率化したい」なら、商談前の過去事例検索に対象を絞り、検索にかかる時間と提案への採用率で測る形にします。顧客の要望を否定するのではなく、最小の検証範囲と本番の条件を先に合意しておく進め方です。
転職の場面では、要件定義の経験を文書作成の実績として説明しがちです。採用側が見るのは、何を対象から外し、どの順番で解いたかという絞り込みの判断でしょう。
過去の案件を1つ選び、対象外にした範囲とその理由を書き出してください。
顧客・開発・セキュリティを動かす推進力
FDEには、顧客担当者、部門責任者、開発、データ、セキュリティを同じ方向へ動かす推進力が必要です。関係者ごとに完了条件が違うからです。精度を上げたい開発と、監査要件を満たしたい情報部門では、優先する順番が変わります。
その場面でFDEがやるのは、説明を上手にすることではありません。論点、決める人、期限をはっきりさせ、試行してよい範囲と公開の条件を合意します。高圧的なリーダーシップや営業力とは別の能力といえます。
ただし、3領域が揃っていても働き方そのものが合わないケースもあるでしょう。
FDEに向いている人・向いていない人
FDEに向くのは、曖昧な課題と顧客との対話を負担ではなく仕事の一部として引き受けられ、コードと業務成果の両方に責任を持ちたい人です。仕様が確定した実装に集中したい人、顧客折衝を避けたい人には、別の専門職の方が力を発揮しやすいでしょう。
年収や肩書きの新しさで選ぶと、入社後に前提が合いません。ソフトバンクのSB OAI Japan向けFDE求人が課題特定から本番展開、Eval、ガバナンスまでを1つの募集に含めているように、仕事の進め方そのものが判断の対象になります。
| 判断項目 | FDEが向く場合 | 別の職種が向く場合 |
|---|---|---|
| 仕様の状態 | 決まっていない段階から関わりたい | 確定した仕様を高い品質で実装したい |
| 顧客との対話 | 合意形成そのものを仕事として引き受けられる | 技術検討に時間を使いたい |
| 完了の感覚 | 使われて業務が変わるまで見たい | リリースまでで区切りたい |
| 技術の幅 | 広く触りながら判断したい | 1つの領域を深く突き詰めたい |
| 成果の測り方 | 業務指標で評価されることを受け入れられる | 技術的な品質で評価されたい |
内向的か外向的かでは分かれません。顧客との合意形成を仕事として引き受けられるかどうかを見ます。完成した仕様がないと動けない、顧客会議を避けたい、納品後の利用状況に関心が向かない場合はミスマッチになりやすいでしょう。
直近で担当した案件を1つ思い出し、仕様が決まっていない段階の作業を自分がどう感じていたか言葉にしてみてください。表の5項目のうち3つ以上が右側に寄るなら、FDEより先に別の専門職を検討する方が納得感のある選び方になります。
FDEになるには、隣接職種で「課題発見から本番定着」の実績を作る
FDEという肩書きが未経験でも目指せますが、本番開発の経験と、顧客や利用部門と協働した経験は必要です。OpenAIとソフトバンクの現行求人はどちらも関連分野で5年以上の経験を求めており、完全未経験からの入口ではありません。
効くのは資格ではなく、曖昧な課題を動く仕組みに変え、利用と成果まで追った実績です。富士通のFDEインターンシップのように育成側の入口も出てきていますが、中途採用の主流は経験者です。いまの職種から何を足すかを決めるところから始めます。
ソフトウェア・データ・ソリューション職から経験を広げる
近い入口はSWE、データエンジニア、ソリューションアーキテクト、技術導入職です。ただし現職によって、足りない経験が入れ替わります。
| 出発職種 | そのまま活かせる経験 | 補う必要がある経験 |
|---|---|---|
| ソフトウェアエンジニア | 本番実装、品質管理、運用 | 顧客・利用部門との合意、業務課題の絞り込み |
| データエンジニア | データ連携、権限、品質管理 | 業務側のKPI設定、利用部門への展開 |
| ソリューションアーキテクト・技術導入職 | 顧客折衝、構成の判断 | 本番コードの実装、評価の作り込み |
| コンサルタント | 課題定義、関係者の調整 | 自分で実装する経験、技術的な実現可否の判断 |
職種名より、本番実装、顧客協働、プロジェクトを所有した経験の3つを増やす方が採用側に伝わります。社内の利用部門と直接話す小規模な自動化案件を、要件から運用まで1人で担当するのが実績になりやすいやり方でしょう。
実装経験がある人は業務側の合意形成から、業務側の経験がある人は小さな実装から埋める方が、結果的に時間がかかりません。
ポートフォリオはAIデモではなく業務成果まで示す
AIデモを並べたポートフォリオは、FDEの選考では評価が伸びにくい傾向があります。採用側が見るのはモデルの新しさではなく、誰の何を解き、どの制約を処理し、本番の条件と評価をどう決め、何が変わったのかという一連の判断だからです。
| 記載項目 | 書く内容 |
|---|---|
| 課題 | 誰のどの業務が、どう詰まっていたか |
| 利用者 | 実際に使った人数と職種 |
| 制約 | 権限、機密情報、既存システム、期限 |
| 構成 | 使った技術と、それを選んだ理由 |
| Eval | 品質の基準と、確認した方法 |
| 導入結果 | 利用状況と業務指標の変化 |
| 次の改善 | 残った課題と、次に手を入れる箇所 |
社外秘の案件は、数値と固有名詞を伏せて判断の流れと担当範囲だけ書けば足ります。架空の導入効果や利用者の声を足す必要はありません。
既存のリポジトリのREADMEに、この7項目を見出しとして足してください。埋まらない項目が、次の案件で取りにいく経験になります。
求人票は職種名ではなく責任範囲で見極める
FDEという名称の求人でも、担当範囲は同じではありません。ソフトバンクのSB OAI Japan向け求人は、課題特定から本番展開、Eval、セキュリティ、ガバナンス、再利用できるアセット化までを1つの募集に含みます。一方で、決まった要件の実装に近い募集もあります。
面接で確認するなら、次の5つが判定に使えるでしょう。
- プロジェクトの完了条件は納品ですか、利用と業務指標ですか（成果責任の位置）
- 解く課題は誰が決めますか（課題定義の権限）
- 本番コードは自社で書きますか（実装の担当範囲）
- 現場で得た知見はどのチームへ戻しますか（受託開発化していないか）
- 導入後の改善は誰が続けますか（担当が切れる地点）
責任範囲が狭いこと自体が悪いわけではありません。自分が積みたい経験と一致するかどうかで判断してください。求人票の完了条件の書き方に、この5つの答えはほぼ出ています。
企業がFDEを置くべきケース・置かなくてもよいケース
すべての企業にFDEが必要なわけではありません。効くのは、AIの技術選定よりも業務への組み込み、本番実装、定着で止まっている企業です。
ソフトバンクのCrystal intelligenceでも、業務の洗い出しからユースケースの決定、データと既存システムの統合、セキュリティとガバナンス、実装と定着までをFDEが担う進め方を取っています。自社がこの並びのどこで止まっているかを先に見ると、採用・育成・外部への依頼の順番が決まります。
| FDEの必要性が高い状態 | 先に別の課題を解く方が早い状態 |
|---|---|
| PoCは動いたが、既存システムとのデータ連携が終わっていない | 解く業務と、その業務の責任者が決まっていない |
| 参照データの権限と監査の条件が決まっていない | 標準機能の設定だけで業務が完結する |
| 誤った出力を誰が確認するかが決まっていない | 社内のデータ利用条件が未整備で、資料を渡せない |
| 利用部門への展開と評価の担当が決まっていない | 効果を測る業務指標をまだ定義できない |
FDEを置けばAI導入が自動的に進むわけではありません。業務責任者、利用部門、データ・セキュリティ担当が同じ場に入ることが前提になります。
PoCはできたが、現場導入・既存システム連携で止まっている企業にはFDEが合う
PoCの回答精度は基準を満たしたのに、そこから先へ進んでいない。この状態はFDEの優先度が高いサインです。
技術デモと本番運用の間には、データ接続、権限、業務の例外処理、品質評価、利用部門への展開が残っています。現場と実装の両方を見ながらここを詰める担当が空いていると、案件は精度検証の段階で滞留したままになります。次の6項目で自社の空欄を確認してください。
- 業務責任者：対象業務の意思決定者が決まっているか
- データ：参照するデータの範囲と権限が確定しているか
- 連携：既存システムとの接続方式が決まっているか
- 評価：品質の基準と、確認する人が決まっているか
- 運用：誤った出力が出たときの対応手順があるか
- 利用定着：使う部門と、教育の担当が決まっているか
6項目のうち2つ以上が空欄なら、追加のツール検討より先に、この空欄を埋める役割が必要です。ただしPoC自体の目的と測り方が決まっていない場合は、FDEの採用より先に業務課題と責任者を決める段階でしょう。
PoCから本番展開へ進める手順そのものは、AI導入をPoCから本番展開へ進める手順で扱っています。自社の停止地点を特定したうえで、6項目のうち埋まっていない欄を今週中に洗い出してください。
標準SaaSの設定だけで足りる企業は、FDEを置く優先度が低い
既製ツールの標準機能で業務が完結し、複雑なデータ統合や個別実装が要らないなら、専任のFDEを置く優先度は下がります。この場合に効くのは、導入担当の配置、社内教育、利用ルールの整備です。
たとえば議事録の要約だけが目的で、承認済みのツールと既存の運用で足りるケース。ここに高度な役割を置いても、成果は変わりません。
ただし標準ツールでも、複数部門をまたぐ連携、ガバナンス、独自データとの統合が必要になればFDE相当の役割が要ります。企業規模だけで判断できる話ではありません。1部門の定型業務なら運用ルールと教育の整備、複数部門と独自データが絡むならFDE相当の役割が合います。
内製・採用・外部伴走の選択は、導入後も誰が改善を続けるかで決める
内製、採用、外部への伴走依頼のどれを選ぶかは、実装が終わった半年後に誰が改善を続けるかで決まります。短期の実装コストだけで比べると、運用の担当が空いたまま案件が終わります。
| 進め方 | 向く状況 | メリット | 残る責任 |
|---|---|---|---|
| 社内で内製する | 複数の業務へ継続して広げる予定がある | 業務知識と改善の履歴が社内に残る | 人材の確保と育成、他業務との工数調整 |
| FDE人材を採用する | 対象業務が複数あり、継続的な役割として置ける | 課題定義から実装まで社内で完結する | 採用要件の定義、評価と定着、受け入れ体制 |
| 外部へ伴走を依頼する | 最初の対象業務や実装方法が決まっていない | 型ができるまでの期間が短い | 業務責任者を社内に置き、手順とテンプレートを引き継ぐこと |
外部へ丸投げにすると、改善のたびに依頼が必要です。初回は外部と一緒に業務選定、実装、評価まで行い、テンプレートと運用手順を社内チームへ移すやり方が現実的でしょう。
どの進め方でも、先に決めるのは解く業務です。最初の対象業務が絞れないうちは、業界・部門別の生成AI活用事例から自社に近い使い方を探すと候補が出てきます。改善できた業務と削減時間までまとめた資料としては、業務のAI活用事例集もあります。
まず対象業務を1つ決め、半年後に改善を続ける担当者を先に置いてください。その担当が決まってから、内製・採用・外部依頼のどれで初回を回すかを選びます。
日本企業でもFDEの採用・育成が始まっている
LayerXはForward Deployed Engineerの募集を開始し、デロイト トーマツは2026年6月からFDE人材の活用を本格化します。ソフトバンクはSB OAI Japan向けにFDEを募集しており、富士通はFDEをテーマにしたインターンシップを実施しています。
FDEは海外企業だけの呼称ではありません。ただし4社の担当範囲は同一ではないため、公式情報での書き方の差を並べて見た方が実態がつかめます。
| 企業 | 公表・募集の内容 | 公式情報での担当範囲の重心 |
|---|---|---|
| LayerX | Forward Deployed Engineerの募集開始 | 顧客業務の資料を読み、ヒアリングした内容をAIワークフロー・AIエージェントへ落とす |
| デロイト トーマツ | 2026年6月からFDE人材の活用を本格化 | 構想・実装・定着をつなぐ。フロントエンド、バックエンド、インフラ、データ連携にまたがる |
| ソフトバンク（SB OAI Japan） | FDEの求人を掲載 | 課題特定から本番展開、Eval、セキュリティ、ガバナンス、再利用できるアセット化 |
| 富士通 | FDEをテーマにしたインターンシップ | AI・データを使う実装に加えて、顧客価値を高める提案 |
同じFDEでも、AIワークフローの実装に重心があるのか、構想から定着までのつなぎに重心があるのかで中身が変わります。育成の入口として置いている例と、経験者採用として置いている例が混在しており、同じ呼称で一括りにはできません。
なお、企業数の変化を急増や標準職種になったと表現できる定量的な根拠はありません。気になる企業があれば、公式ページの担当範囲と完了条件の書き方を並べて比べてください。
FDEに関するよくある質問
用語の範囲と募集条件については、職種の定義やスキルとは別の疑問が残りやすい部分です。以下の4つは、本文で扱った内容と重ならない範囲で答えます。
- FDEモデルとは何ですか？
-
技術者が顧客の現場に入り、個別の課題を短い期間で実装し、そこで得た知見を再利用できるプロダクト機能や型へ戻す進め方を指す呼び方です。統一された規格ではなく、会社ごとに定義が違います。職種としてのFDEと、事業・開発の進め方としてのFDEモデルは分けて読んでください。個別実装だけが積み上がり、共通の知見が製品へ戻らない状態が続くと、受託開発に近い形になります。
- FDEの年収はいくらですか？
-
公的な統一相場はなく、国・企業・職位で差が大きい職種です。2026年7月23日時点のSB OAI Japan向けソフトバンク求人では、想定理論年収が812.3万円から2,034.62万円です。上限と下限で約2.5倍の開きがあり、担当範囲と職位で金額が動きます。これは1社1求人の例で、国内FDEの平均ではありません。賞与や評価で変動するため、比較するときは職位と賞与条件をそろえてください。
- FDEは未経験からなれますか？
-
職種名としてのFDEが未経験でも応募できる求人はありますが、ソフトウェア開発・技術導入・顧客協働のすべてが未経験の状態から直接就く難度は高めです。OpenAIとソフトバンクの現行求人は関連分野で5年以上の経験を求めています。一方で富士通のようにインターンシップで育てる入口もあるため、中途求人の年数要件をすべての募集へ広げて考える必要はありません。職種名の未経験と実務経験の未経験を分け、隣接職種で本番実装と課題定義の経験を先に作るのが現実的な順番でしょう。
- FDEはAIに代替されますか？
-
実装やドキュメント読解の一部はAIで短縮できますが、現行のFDE求人は曖昧な課題の定義、関係者との合意、本番の責任、セキュリティ判断を人に求めています。これは現時点の求人要件から読み取れる範囲の推論で、将来の予測ではありません。職種が代替されないと断定するより、コード生成や資料読解にAIを使い、担当範囲と進む速さが変わると見た方が実態に近い理解になります。AIに奪われない職種という前提で選ぶ話ではないでしょう。
まとめ｜FDEはAIを「作る」だけでなく「使われて成果が出る」まで担う
FDEかどうかは、肩書きや顧客先にいるかどうかでは決まりません。顧客課題の定義、本番実装、成果の測定、知見の還元をどこまで持つかで判断します。
転職を検討している人は、求人票の完了条件と課題定義の権限を確認し、いま不足している経験を1つ選んで埋めてください。法人側は、PoCの先で止まっている項目を洗い出し、業務責任者とデータの利用条件が決まっているかを先に確かめる段階です。
標準ツールの設定だけで業務が完結するなら、専任のFDEより運用ルールと教育に手を入れた方が早く成果が出ます。自社がどちらの状態かで、次に動かす順番が変わってきます。
