FDEという肩書の提案を受けた方へ
ベンダーの提案書や顧問の肩書に「FDE」という言葉が出てきて、何者なのか確かめたい方に向けて書いています。
FDEはForward Deployed Engineerの略で、2026年の日本のAI業界で一気に広がった職種名です。結論を先に言うと、本来の定義はエンジニア職です。コンサルタント職ではありません。ここを押さえるだけで、提案の中身をかなり見分けられるようになります。
定義はPalantirにあります
この職種を確立したのは米Palantirです。同社は公式ブログで、Forward Deployed Software Engineerを「顧客のもとに直接入り込み、自社のソフトウェアプラットフォームを顧客の最も困難な問題に合わせて実装するソフトウェアエンジニア」と説明しています。
社内の対比も明快です。通常のエンジニア（Dev）が1つの機能を多くの顧客のために作るのに対し、FDEは1社のために多くの機能を実装します。プロダクトを作る仕事と、プロダクトを顧客の現場で成果に変える仕事の分業です。
どちらもコードを書く仕事として定義されている点が重要です。現場に入って要件を聞き、その場で実装し、動くものを見せて次の要件を引き出す。この往復がFDEの中身です。
日本で広がったのは2025年からです
日本での転機は、OpenAIとソフトバンクの合弁会社SB OAI Japanです。2025年11月に発足した同社は、大企業のAI変革を担う中核職種としてFDEを据えました。募集要項には「単なるPoCではなく、業務に定着し、成果を生み続ける本番システムを構築」とあります。
OpenAI自身も東京拠点のFDEを募集しており、出張は主に国内と明記されています。海外のAI企業が、日本企業の現場に入るエンジニアを東京で雇う。それだけ「現場で実装する人」が足りていないということです。
この2社に続いて、国内のAI企業やSaaS企業も相次いで同名の職種を新設しています。求人サイトの検索では、国内のFDE求人は300件を超えています（2026年8月2日時点、Indeed）。
本場の求人要件を見てください
SB OAI JapanのFDE求人の必須要件は、次のとおりです。
| 必須要件（抜粋） | 意味するもの |
|---|---|
| 5年以上のソフトウェアエンジニアリングまたは技術導入経験 | 実装の実務経験が前提 |
| 本番品質コードの設計・実装経験 | 動けばよいPoCコードでは足りない |
| クラウド環境でのシステム構築経験 | 顧客環境で自分で組める |
| LLM・生成AIアプリケーションの構築または導入経験 | AI実装の経験そのもの |
戦略立案やファシリテーションは必須要件の中心にありません。中心にあるのは、本番までコードを書き切った経験です。想定理論年収812万〜2,034万円という水準は、この要件に対する値付けです。
名前は新しく 仕事は新しくありません
顧客の現場に入り、曖昧な要件を実装で潰していく。この働き方自体は、受託開発の現場が昔からやってきたことです。
新しいのは、プロダクト企業がそれを自社の中核職種に据え、名前を付けたことです。
同じ肩書で中身が違う提案の見分け方
職種名が流行すると、実装を伴わない役割にも同じ名前が付くようになります。現場に入って議論を整理し、資料をまとめ、実装は別のチームへ渡す。それ自体は昔からあるコンサルティングの仕事で、価値がないわけではありません。ただ、FDEという言葉から期待される「その場で実装まで下ろす」役割とは別物です。
見分け方は、本場の求人要件をそのまま質問に変えることです。
FDE的な支援の提案を受けたときの4つの質問
- 本番のコードを書くのは誰ですか: 提案者本人か、別の開発チームか。「体制図の下のほう」に実装者がいる場合、それはFDEではなく従来の元請け構造です
- 過去案件の開発記録をどの粒度で見せられますか: Pull Request、レビュー履歴、受入基準。守秘義務の範囲でも、記録の粒度自体は説明できるはずです
- PoCの後の運用と改善は誰が持ちますか: 「本番定着まで」を掲げるのがFDEの定義です。PoCで契約が終わる設計なら、その言葉を使う理由を確認します
- 成果物は自社に残りますか: コードとドキュメントの帰属。現場に入る働き方は、成果物が顧客側に蓄積されてこそ意味があります
提案書に「FDE」「伴走」という言葉が出てきたとき、中身を確認する質問として商談でそのまま使えます
発注側にとっての意味
FDEの流行は、発注側にとって悪い話ではありません。「作って終わり」ではなく現場への定着まで責任を持つ働き方が、業界の標準として言語化されつつあるからです。実装が速くなった受託開発が何を売るのかという問いへの、1つの答えでもあります。
ただし、肩書は保証になりません。見るべきは記録です。誰がコードを書き、何が残り、誰が本番まで持つのか。この3点を確認してから契約してください。
自社の課題にFDE的な支援が合うのか、伴走型の開発支援とどう違うのかを整理したい段階でしたら、お問い合わせからご相談ください。肩書ではなく、体制と記録の設計から入ります。