FDE（Forward Deployed Engineer）という職種名を、求人票や技術系の記事で見かける機会が増えました。一方で、PMやITコンサルタントとの違いを聞かれてすぐに答えられる人は多くありません。言葉が先に広まり、何をする役割なのかが曖昧なまま使われています。
本記事は、開発を外部に委託している事業会社の担当者と、SIerで顧客折衝と技術の両方に関わっているエンジニアの方に向けて書いています。前半ではFDEの定義と仕事内容、PM・SWE・ITコンサルタント・アーキテクトとの違い、Palantir・OpenAIにおけるFDEの役割を整理します。後半では、FDEという言葉を既存のIT産業構造からどう捉えるべきかについて、Incubation Baseの考察を示します。
この記事の結論
FDE（Forward Deployed Engineer）とは、顧客と直接協働し、課題の発見・技術設計・試作・実装・本番導入までを一気通貫で前進させるエンジニアを指します。ただし業界共通の厳密な職務定義はなく、企業によって役割は異なります。
FDE型の働き方自体は生成AI以前から存在します。Palantirは自社がこの職種を確立したと説明しており、OpenAIも東京を含む複数拠点でFDEを組織機能として拡大しています。
本記事では、さらに「なぜ今FDEが注目されているのか」を考察します。Incubation Baseでは、その重要な背景の一つが生成AIによる分業の再統合にあると考えています。これは一般的な定義ではなく、本記事の見立てです。
この記事でわかること
- FDE（Forward Deployed Engineer）とは何か、仕事内容と役割
- FDEとPM・ソフトウェアエンジニア・ITコンサルタント・アーキテクトの違い
- Palantir・OpenAIにおけるFDEの役割
- なぜ生成AIの普及でFDEが改めて注目されているのか
- FDEに必要なスキル・経験と、若手でもFDEになれるのか
- FDEが必要な組織・不要な組織
- 日本企業やSIerがFDE型組織を作る際の論点
FDE（Forward Deployed Engineer）とは
近年、ソフトウェア開発やシステム導入に携わる企業やエンジニアの間で、FDEという職種が注目されています。一般的には、顧客の近くで業務課題を把握し、技術的な解決策の設計、試作、実装、本番導入までを進めるエンジニアを指します。
FDEは何の略？
FDEは「Forward Deployed Engineer」の略称です。直訳すると「前方に配置されたエンジニア」であり、自社オフィスではなく顧客の現場（前線）に入って働くことに由来します。
表記は企業によって異なります。Palantirは「Forward Deployed Software Engineer（FDSE）」と呼び、OpenAIは「Forward Deployed Engineer（FDE）」という職種名で募集しています。呼称は違いますが、顧客と直接協働して課題解決から実装・導入まで担うという点は共通しています。本記事では総称としてFDEを使います。
Palantir・OpenAIではFDEをどう定義しているか
FDEという職種を最も早くから制度化したのはPalantirです。同社の求人情報では、FDSEを「The Original Forward Deployed Software Engineer」と位置付け、自社がこの職種を確立した（pioneered）と説明しています。顧客と並走しながら、課題理解、アーキテクチャ設計、顧客固有のアプリケーション開発、経営層を含む関係者との折衝、構想から本番導入までを担う役割です。
OpenAIの東京拠点のFDE求人では、発見（discovery）、技術的スコーピング、システム設計、構築、本番展開までを自ら担い、本番での採用率や業務への定量的なインパクト、そして製品・研究へのフィードバックを成果指標としています。「進捗や明確さがそれに依存する場合は、自らコードに直接貢献する」ことも明記されています。
| Palantir FDSE | OpenAI FDE | |
|---|---|---|
| 顧客との直接協働 | ◎ | ◎ |
| 課題発見 | ◎ | ◎ |
| システム設計 | ◎ | ◎ |
| 自ら実装 | ◎ | ◎ |
| 本番導入 | ◎ | ◎ |
| プロダクトへのフィードバック | ◎ | ◎ |
| 主な技術文脈 | データ・AI・業務アプリケーション | Frontier AI / LLM |
| 特徴 | 顧客固有の課題をデータとソフトウェアで解く | 研究成果を顧客の本番システムへ展開する |
※2026年8月時点の各社求人情報をもとに整理。詳細は記事末尾の参考情報を参照。
両社に共通しているのは、「顧客課題を理解する人」と「実装する人」を強く分離しない点です。整理すると、FDEの共通項は次のようになります。
| 共通項 | 内容 |
|---|---|
| 顧客に近い | 顧客のエンジニア・業務部門と直接協働する |
| 課題から入る | 固定された仕様ではなく、曖昧な問題から開始する |
| 技術設計を担う | システムやアーキテクチャを自ら設計する |
| 自ら作る | プロトタイプや本番品質のコードにも関与する |
| 本番まで責任を持つ | PoCで終わらず、導入と定着（adoption）を重視する |
| フィードバックを戻す | 現場で得た知見を製品・研究・ロードマップへ反映する |
FDEの主な仕事内容
一般的なFDEの業務には、次のようなものがあります。
- 顧客の経営課題や業務課題を把握する
- 顧客の要求を技術的な要件へ整理する
- 自社のプロダクトやAIを使って解決策を設計する
- プロトタイプやPoCを開発する
- 顧客のデータや既存システムと接続する
- 本番導入に必要な設計、実装、運用を前進させる
- 顧客案件で得た知見をプロダクト開発へ戻す
すべてのFDEが、これらを一人で担当するわけではありません。小規模な案件では、一人のFDEが課題整理から実装まで広く担うことがあります。一方、大規模プロジェクトでは、PM、業務コンサルタント、アーキテクト、データエンジニア、開発チームなどと分業しながら、顧客課題と技術実装をつなぐ役割を担います。
また、企業によってFDEの実態は大きく異なります。技術提案が中心であれば、セールスエンジニアやソリューションアーキテクトに近くなります。導入や個別開発が中心であれば、導入コンサルタントやプロフェッショナルサービスに近くなります。自ら設計・実装し、プロダクト改善まで担うのであれば、プロダクトエンジニアやテックリードに近い役割になります。
FDEとPM・SWE・ITコンサルタント・アーキテクトの違い
FDEは、PM、ソフトウェアエンジニア（SWE）、ITコンサルタント、アーキテクト、セールスエンジニアなどの既存職種と大きく重なります。一般的な傾向を整理すると、次のようになります。
| 職種 | 顧客課題の把握 | 解決策・要件の設計 | 自ら実装 | プロジェクト管理 | 本番成果への関与 |
|---|---|---|---|---|---|
| FDE | ◎ | ◎ | ○〜◎ | ○ | ◎ |
| SWE（ソフトウェアエンジニア） | △ | ○ | ◎ | △ | ○ |
| PM | ◎ | ○ | △ | ◎ | ○〜◎ |
| ITコンサルタント | ◎ | ◎ | △ | ○ | ○ |
| アーキテクト | ○ | ◎ | ○〜◎ | △ | ○ |
| ソリューションアーキテクト | ○〜◎ | ◎ | △〜○ | △ | ○ |
| セールスエンジニア | ○ | ○ | △ | △ | △ |
※実際の職務範囲は、企業やプロジェクトによって異なります。
最大の違いは、FDEが顧客課題の理解と技術実装の距離を短くすることです。どれか一つの業務を専門的に担うのではなく、顧客課題を理解するだけでなく、技術的な成立性を自ら検証し、必要であれば実装し、本番利用まで前進させる点に特徴があります。
そのため、FDEを「PMが実装もする職種」「顧客と直接話すSWE」と説明することもできます。ただし、PMが日常的にすべてのコードを書くという意味でも、SWEが営業を兼ねるという意味でもありません。顧客理解と実装の間にある受け渡しを減らすことが本質です。
FDEは本当に新しい職種なのか
FDEの説明を見ると、次世代の新しいエンジニア職のように見えます。しかし、SIer、ITコンサルティング、受託開発、フリーランスなどの現場を知る人ほど、次のような疑問を持つのではないでしょうか。
顧客の課題を理解し、要件を整理し、設計し、実装して、導入まで進める仕事は、以前から存在していたのではないか。実際、小規模な受託開発会社の経営者やフリーランスエンジニアは、営業、ヒアリング、提案、要件定義、設計、実装、運用改善までを、一人または少人数で担ってきました。
優秀なPMやITコンサルタント、アーキテクトの中にも、顧客課題を深く理解し、自ら技術的な検証を行いながら、プロジェクト全体を前進させてきた人はいます。Palantirに至っては、生成AIが普及する以前からFDSEを制度化し、組織の中核に据えてきました。したがって、FDEの仕事そのものが新しく生まれたわけではありません。
FDE型の働き方自体は生成AI以前から存在します。一方、生成AIによって、課題整理・調査・設計・試作・実装の一部を一人で高速に進められるようになり、FDE型の働き方をより広い企業・案件で成立させやすくなったと考えられます。新しいのは仕事内容ではなく、それを組織的に採用できる企業の範囲です。
なぜ今、FDEが注目されているのか
生成AIで一人が担える業務範囲が広がった
大きく変化したのは、生成AIによって、一人が実行できる業務範囲です。従来、PMやコンサルタントが顧客課題を理解していても、それを具体的な形にするためには、複数の担当者が必要でした。例えば、次のような作業です。
- 顧客インタビューの整理
- 業務フローや課題構造の可視化
- 市場、競合、技術の調査
- 要件定義書や提案資料の作成
- UI案や画面イメージの作成
- SQLや簡易スクリプトの作成
- プロトタイプ開発
- テストケースや技術文書の作成
以前は、これらをコンサルタント、ビジネスアナリスト、デザイナー、エンジニアなどへ分担していました。現在は、十分な知識と判断力を持つ人であれば、生成AIを使って、その相当部分を自ら進められます。
この見方は、外部の議論とも方向が近いものです。EY Japanが2026年6月に公開した「TMT Industry Futures Vol.3」の座談会では、FDEを「ビジネス上の課題特定から解決策の策定、そして実際の実装までを一気通貫で担う人材」とし、AIの進化によって「課題解決ができる人が、AIを道具として使いこなし、そのまま実装まで担うという形も、十分に現実的になってきている」と述べられています。
顧客理解と実装の分断を減らせる
FDEが求められるようになった背景は、企業が突然「顧客対応のできるエンジニア」を必要とし始めたからではありません。従来は複数人で分業していた課題整理、調査、設計、試作、実装の一部を、能力の高い一人がAIを使って圧縮できるようになった。この変化によって、課題を理解する人と、実際に形にする人を分ける必要性が低下しました。
ここで圧縮されるのは、必ずしも職種そのものではありません。職種と職種の間にあった調査、文書化、初期設計、試作、受け渡し、中間調整といった工程です。FDEは新しい役職を一つ追加するモデルではなく、従来の中間レイヤーや受け渡しを減らすためのモデルと捉えると理解しやすくなります。
大規模プロジェクトでFDEは何をするのか
大規模なシステム開発では、FDEが一人ですべてを担当することはできません。セキュリティ、インフラ、データ基盤、品質保証、既存システム連携、法務などには、それぞれ専門性が必要です。そのため、大規模プロジェクトにおけるFDEは、すべてのコードを書く人ではなく、次のような役割を担います。
- 顧客の曖昧な相談から、解決すべき課題を特定する
- 業務要件を技術的な仮説へ変換する
- AIを使って初期調査、設計、試作を行う
- プロトタイプで技術的な成立性を検証する
- 専門性や規模が必要な部分を開発チームへ渡す
- 顧客と開発チームの間で意思決定を前進させる
- 本番利用の結果を、次の改善へ反映する
重要なのは、FDEが何でも一人で行うことではありません。FDEが自ら課題理解と初期検証を行い、本当に専門家や大人数が必要な部分だけをチーム化することに意味があります。「一人で何でもできる万能職種」という理解は誤りです。
FDEはいらない？PM・開発チームで代替できるケース
PMが顧客の課題を正確に把握し、開発チームにも十分な業務理解と課題解決力がある場合、FDEという独立した役割は必ずしも必要ありません。次のような状態であれば、PMと開発チームがFDEの機能を担えます。
- PMが顧客の発言だけでなく、背景にある業務課題を理解している
- PMが技術的な実現可能性を一定程度判断できる
- 開発者が顧客や利用者と直接会話できる
- 開発チームが仕様書ではなく、解決すべき課題を理解している
- PMとテックリードが共同で意思決定できる
- 仮説検証と実装を短い周期で回せる
この状態でFDEを追加すると、顧客 → FDE → PM → 開発チームという新しい伝達経路が生まれる可能性があります。FDE、PM、コンサルタント、アーキテクトの責任分界が曖昧であれば、会議参加者と調整工数が増えるだけです。したがって、FDEはすべてのプロジェクトに必要な職種ではありません。
FDEが必要になるのは、顧客理解と技術実装の間に、既存体制では埋められない空白がある場合です。そしてFDEを置くのであれば、既存の役割に加えるのではなく、従来の受け渡しや中間工程の一部を減らす必要があります。
FDEに必要なスキル・経験
AIが使えるだけではFDEになれない
FDEが注目される一方で、「AIを使ってアプリを作れる人なら、少し経験を積めばFDEになれる」という認識もあります。しかし、AIを使って成果物を作れることと、顧客の成果に責任を持つことは別です。生成AIは、コード、資料、画面案、調査結果を短時間で生成できます。一方で、次のような判断は、AIを使えるだけでは担えません。
- 顧客が話している問題は、本当に解くべき課題なのか
- どの業務を変え、どの業務を残すべきか
- 何を作らないと判断すべきか
- AIが生成した設計やコードに問題がないか
- PoCでは動いても、本番で何が問題になるか
- 個別対応と標準化をどのように切り分けるか
- いつ専門家を参加させるべきか
- 顧客の投資に見合う成果が得られるか
これらを判断するためには、業務、開発、プロジェクト管理、顧客対応、本番運用などの経験が必要です。AIは、経験の代わりになるものではありません。AIは、経験者の調査、設計、試作、文書化を高速化し、それまで他人へ依頼していた作業を自ら進められるようにするものです。
若手でもFDEになれるのか
FDEには新卒・若手を採用して育成する企業もあります。Palantirは現在も新卒向けのFDSE求人を出しており、入社初日から顧客との最初の会話から本番導入まで責任を持たせる設計です。したがって「若手はFDEになれない」とは言えません。
一方、OpenAIの東京拠点のFDE求人は、顧客対応を含む5年以上のエンジニアリングまたは技術導入の経験を求めています。顧客の曖昧な課題を一人称で捉え、業務・技術・本番運用を横断して自律的に判断する即戦力型のFDEには、相応の経験が必要です。特に生成AIによって個人の実行範囲が広がるほど、「何を作るべきか」「何を作らないか」を判断する経験の価値は高まります。
つまり、若手をFDE候補として採用し育てる道と、経験者を即戦力型FDEとして迎える道は別のものです。企業は、自社がどちらを求めているのかを区別する必要があります。
重要なのは「判断と結果の往復」
FDEになるために、営業、コンサルティング、PM、設計、開発を、それぞれ一定年数ずつ形式的に経験する必要があるわけではありません。重要なのは、自分の判断がどのような結果につながったかを、複数の工程で経験することです。例えば、次のような経験です。
- 曖昧な要件が、後工程でどのような手戻りを生んだか
- 技術的に正しい設計が、現場ではなぜ使われなかったか
- プロトタイプと本番システムでは、何が異なるのか
- 顧客社内の予算や意思決定が、プロジェクトへどう影響するか
- 導入後の利用状況を見て、何を改善すべきか
- 顧客固有の要求を、どこまで共通化できるか
こうした知識は、研修や資格だけでは身に付きにくいものです。重要なのは在籍年数ではなく、課題設定、設計、実装、導入、運用の判断と結果を、複数の案件で何度往復したかです。
小規模案件、フリーランス、新規事業、スタートアップでは、一人が複数工程を同時に担当するため、比較的短期間で横断的な経験を積める場合があります。一方、工程分業が進んだ大規模組織では、一つの領域へ長期間固定されることが多く、経験年数が長くても全体を理解しているとは限りません。
ここからはIncubation Baseの考察｜FDEが組織構造をどう変えるか
ここまでは、FDEの一般的な定義と、Palantir・OpenAIなど実在企業の職務内容をもとに整理してきました。ここからは、FDEという言葉を日本のIT産業構造、とくに分業型の組織や受託開発のモデルからどう捉えるべきかについて、Incubation Baseの考察を述べます。一般的な定義ではなく、当社の実務観察に基づく見立てとしてお読みください。
従来の分業モデルとFDE型モデルの違い
従来のプロジェクトでは、顧客の相談が複数の担当者を経由して、開発チームへ届くことがあります。この構造は、大規模案件を安定的に運営するうえでは合理的です。一方で、受け渡しが増えるほど、顧客が最初に抱えていた課題の背景や、細かな判断理由が失われる可能性があります。
FDE型のプロジェクトでは、FDEまたは顧客担当のテックリードが、顧客との対話、課題整理、初期設計、技術検証を自ら行います。そのうえで、セキュリティ、インフラ、大規模開発など、専門性や人員が必要な部分だけを、PM、アーキテクト、開発・運用チームなどへ接続します。FDEがすべてを一人で担当するのではなく、意思決定と実装の距離を短くすることが目的です。
なぜ分業型組織ではFDE型人材が育ちにくいのか
日本の大手SIerなど、工程・機能分業が進んだ組織は、大規模で複雑なシステムを一定の品質で安定的に開発するために分業を進めてきました。分業には合理性があります。
- 専門性を高めやすい
- 大人数を管理しやすい
- 品質基準を統一しやすい
- 契約と責任範囲を整理しやすい
- 大規模案件を再現性高く運営しやすい
しかし、そのトレードオフとして、顧客、業務、技術、プロジェクト全体を横断して理解する人材が育ちにくくなります。典型的には、経験が次のように分断されます。
- 営業は顧客や契約を理解しているが、実装から離れている
- コンサルタントは構想を作るが、本番運用まで担当しない
- PMは進捗、品質、採算の管理が中心になる
- アーキテクトは技術設計を行うが、顧客業務から距離がある
- エンジニアは担当機能を開発するが、投資判断や案件全体を知らない
また、開発者がPMへ昇格する従来型のキャリアでは、上流へ進むほどコードを書かなくなる傾向があります。過去に開発経験があっても、現在のAI、クラウド、データ基盤を使って、自ら短時間で検証できるとは限りません。反対に、最新技術に詳しい若手エンジニアは、顧客の予算、業務設計、組織内調整、本番導入を経験していないことがあります。FDEには、この両方が必要です。
もっとも、こうした組織にFDEになり得る人がまったくいないわけではありません。小規模案件を少人数で担当した、新規事業や先端技術部門に所属した、プリセールスから導入まで一貫して担当した、顧客企業へ出向した、炎上案件で職種を越えて対応した、スタートアップや起業・フリーランスを経験した。こうした、組織が設計した分業の外へ出た経験を持つ人ほど、FDEに近い能力を持っている可能性があります。
一方で、こうした能力は既存の評価制度では見えにくいことがあります。案件規模、売上、管理人数、稼働率が評価される一方で、少人数で仮説検証を進めたことや、自ら実装して不要な開発を減らしたことは評価されにくいからです。その結果、FDEとして活躍できる素養を持つ人がいても、従来型のPM、アーキテクト、プリセールスとして配置され、横断的な能力を十分に発揮できない場合があります。
FDEという肩書を付けるだけでは機能しない
企業がFDEを必要だと考え、既存のPMやエンジニアの肩書を変更しても、それだけでは機能しません。既存の分業構造を残したままFDEを追加すると、FDEが次のような調整役になる可能性があります。
- 営業の承認を取る
- PMとスケジュールを調整する
- アーキテクトへ技術判断を依頼する
- 開発部門へ実装を依頼する
- プロダクト部門へ改善要望を伝える
- 各部門の回答を顧客へ持ち帰る
これでは、受け渡しが一つ増えただけです。FDEモデルを成立させるには、役割だけでなく、権限と組織構造を変える必要があります。例えば、次のような設計です。
- 顧客と直接会話できる
- 初期スコープを自ら決められる
- AIを使った調査や試作を自ら行える
- 小規模な実装を速やかに進められる
- 必要な専門家を直接アサインできる
- PoCだけでなく本番導入まで継続して関与できる
- 顧客の利用状況や現場の反応を確認できる
- 現場で得た知見をプロダクト開発へ戻せる
FDEは、既存組織に人を追加する施策ではありません。AIを前提に、従来の役割、会議、成果物、承認プロセスを減らす組織再設計とセットで考える必要があります。
受託開発とFDEは本当に異なるのか
FDEの特徴として、顧客案件で得た知見をプロダクト改善へ戻すことが挙げられる場合があります。しかし、受託開発でも、顧客が予算を確保し、継続契約を結んでいれば改善を行うのは当然です。受託開発が「作って終わり」になりやすいのは、受託という業態そのものが原因とは限りません。
- 顧客が初期開発の予算しか確保していない
- 保守契約が障害対応に限定されている
- 改善が追加発注になる
- 開発会社が利用状況を確認できない
- 顧客側に継続的なプロダクト責任者がいない
- 年度予算の終了とともに体制が解散する
こうした契約、予算、ガバナンスの問題が背景にあります。受託開発とプロダクト型FDEの違いがあるとすれば、改善するかどうかではなく、改善投資をどのように回収するかです。受託開発では、原則として顧客ごとに改善費用を負担します。プロダクト企業は、一社の顧客から得た知見を複数の顧客へ展開できるため、自社のプロダクト開発費として投資できます。
ただし、FDEが顧客ごとの個別開発に追われ、成果が共通プロダクトへ還元されないのであれば、実態は高度な受託開発や準委任と大きく変わりません。FDEと受託開発の本質的な違いは、誰が改善費用を負担し、その成果をどの顧客へ再利用できるかという経済構造にあります。
生成AIが変えたのはFDEの仕事内容ではなく「経済性」
顧客の課題を理解して技術で解く仕事は以前から存在しました。生成AIによって変わったのは、一人が調査・設計・試作・実装まで進められる範囲と速度です。その結果、従来なら複数職種へ分業していた仕事を、小さなチームへ再統合する選択肢が現実的になっています。
従来、一人が広い工程を担えるのは、能力の高いフリーランスエンジニア、起業家、一部のPMやアーキテクトに限られていました。AIは、こうした人材の代わりになるものではありません。すでに全体像を理解している人の生産性を高め、以前は複数人へ依頼していた作業を短時間で実行できるようにするものです。
この変化は、多人数を長期間配置することで売上を立てる人月型の収益モデルと衝突する可能性があります。これはすべてのFDEモデルに当てはまる必然ではなく、当社の仮説です。しかし、少人数で案件を進められるほど、契約、価格、評価の前提を見直す必要が出てくると考えています。
FDEという新しい職種が生まれたというよりも、生成AIによって、以前から存在していた越境型人材の働き方の経済性が変わり、企業が組織的に採用しやすくなった。これが、本記事でFDEをめぐる変化を捉える見方です。
代表・内山の視点：AIが代替するのは職種ではなく「中間作業」
内山 明夫FDEの本質は「万能なエンジニアを作ること」ではなく、経験のある人がAIを使うことで、従来は複数人へ受け渡していた調査・整理・設計・試作の工程を自ら進められるようになることだと考えています。
その結果、AIが代替するのは必ずしも職種そのものではなく、職種間に存在していた中間作業や受け渡しです。FDEは、その圧縮されたプロジェクト構造の中心に置かれる役割として捉えると理解しやすいと思います。
日本企業がFDE導入前に確認すべき5つのこと
FDEという名称が注目されているからといって、すべての企業がFDE部門を作る必要はありません。導入前には、少なくとも次の点を確認する必要があります。
1．現在のPMと開発チームで担えない機能は何か
顧客理解、技術判断、試作、実装、定着支援のうち、どこに空白があるのかを明確にします。既存メンバーの役割や会議体を見直せば解決するなら、新しい職種は不要です。
2．FDEを置くことで何を減らすのか
会議、資料、承認、引き継ぎ、人員のどれを減らすのかを決めます。既存体制を残したままFDEだけを追加すると、組織は複雑になります。
3．FDEへどこまで裁量を与えるのか
FDEが自ら試作も意思決定もできず、すべてを他部署へ依頼するなら、単なる窓口になります。
4．若手の育成採用と即戦力の採用を分けているか
若手をFDE候補として採用し、育てることは可能です。ただし、顧客成果まで責任を持てる即戦力型のFDEとは区別し、複数工程と複数案件を経験できる育成環境を用意する必要があります。
5．人月型の収益モデルと両立できるか
AIを使って少人数で案件を進めるFDEモデルは、多人数を長期間配置することで売上を立てるモデルと衝突する可能性があります。FDE導入は、人材施策だけでなく、契約、価格、評価、収益モデルの見直しを伴う場合があります。
FDEに関するよくある質問
FDEとは何の略ですか？
Forward Deployed Engineer（フォワード・デプロイド・エンジニア）の略です。顧客の現場に入り、課題の発見から設計・実装・本番導入までを担うエンジニアを指します。PalantirではForward Deployed Software Engineer（FDSE）と表記します。
FDEとPMの違いは何ですか？
PMは、予算、スケジュール、品質、体制など、プロジェクト全体の管理に責任を持ちます。FDEは、顧客課題を技術的な解決策へ変換し、自ら試作や実装を行いながら、本番成果まで前進させることに重点を置きます。ただし、企業によって両者の役割は大きく重なります。
FDEとSWE（ソフトウェアエンジニア）の違いは何ですか？
SWEは与えられた要件や仕様をもとに、設計・実装・テストを担うことが中心です。FDEは顧客と直接協働して課題そのものを特定するところから関わり、何を作るべきかの判断と実装の両方を担います。実装力は共通ですが、顧客課題との距離が異なります。
FDEとITコンサルタントの違いは何ですか？
ITコンサルタントは、課題整理、構想策定、要件定義などを中心に担います。FDEはそれに加えて、自ら技術的な検証や実装を行い、実際に動くシステムとして導入することが期待されます。
FDEに必要なスキルは何ですか？
技術力だけでなく、顧客理解、業務理解、課題設定、要件整理、設計、プロジェクト推進、本番運用への理解が必要です。すべての領域の専門家である必要はありませんが、各領域の論点を理解し、必要な専門家を適切に動かせることが求められます。
若手でもFDEになれますか？
なれます。Palantirのように新卒をFDSEとして採用し、初日から顧客案件の責任を持たせる企業もあります。一方、OpenAIの東京拠点のように5年以上の経験を求める企業もあります。若手がFDE候補として経験を積む道と、経験者が即戦力型FDEとして迎えられる道は別であり、AIツールの操作経験だけで短期間に即戦力型FDEになれるわけではありません。
優秀なPMと開発チームがいればFDEは不要ですか？
PMと開発チームが顧客課題を共有し、技術的な仮説検証を短い周期で進められるなら、独立したFDEは必須ではありません。FDEを置く目的は人を増やすことではなく、顧客理解と技術実装の間にある分断を減らすことです。
まとめ｜FDEは顧客理解と技術実装の距離を縮める役割
FDE（Forward Deployed Engineer）とは、顧客と直接協働し、課題の発見から設計・実装・本番導入までを一気通貫で前進させるエンジニアです。Palantirが確立し、OpenAIをはじめとするAI企業が組織機能として拡大している役割であり、その仕事自体は生成AI以前から存在していました。
本記事の見立てとして、生成AIが変えたのはFDEの仕事内容ではなく、その経済性です。業務と技術の両方を理解する経験者がAIを使えば、従来は複数人が担当していた調査、整理、設計、試作、文書化の相当部分を一人で進められます。FDEが改めて注目されている背景には、分業されていた仕事を再び少人数へ統合できるようになったことがあると考えています。
企業がFDEを導入する際に必要なのは、注目されている肩書を付けることではありません。顧客、業務、技術、プロジェクトを横断して理解できる人材を見つけ、その人がAIを活用して自ら前に進められる権限と環境を整えることです。FDEは人を増やすための職種ではなく、顧客理解と技術実装の距離を縮めるための役割です。
参考情報
以下のリンクは、2026年8月22日時点で確認した情報です。求人ページは募集終了などにより、将来URLが変更または非公開になる可能性があります。
- OpenAI「Forward Deployed Engineer – Tokyo」
- OpenAI Careers「Forward Deployed Engineer」求人検索
- Palantir Blog「A Day in the Life of a Palantir Forward Deployed Software Engineer」
- Palantir「Forward Deployed Software Engineer」求人情報
- Palantir「Forward Deployed Software Engineer, New Grad – Commercial」求人情報
- EY Japan「TMT Industry Futures Vol.3」（2026年6月・PDF）