Forward Deployed Engineer と Forward Deployed Expert の違い｜FDE 2つの中核人材像を5つの軸で整理

FDE=Engineer と FDE=Expert の違いは、『何を作れるか』ではなく、『何を作るかを見極め、社内の意思決定を突破するのは誰か』にある。両者は対立する概念ではなく、AI時代の事業実装の現場に並び立つ、役割の異なる二つの中核人材像である。

Forward Deployed Engineer は、世界の先端AI企業が継承してきた標準語である。一方で、その隣に置かれるべきもう一つの中核人材像として、Forward Deployed Expert という概念が立ち上がっている。両者は何が違い、自社にはどちらが必要なのか。本記事では、2つの違いを5つの軸で整理し、よくある誤解を解き、現場での組み合わせ方を示す。

まず前提：両者は対立しない

Forward Deployed Engineer（FDE）とは、顧客現場に常駐しコードを書きながら課題をプロダクトに変換するエンジニアである。Palantir を起点に、Anthropic・OpenAI をはじめ世界の先端AI企業が継承してきた中核人材像である。Forward Deployed Expert は、その敬意の上に置かれる、もう一つの中核人材像である。

両者は対立しない。むしろ共通点を先に確認することで、違いの輪郭が見えてくる。

第一に、ともに Forward Deployed である。顧客の現場に常駐し、現場の温度のなかで意思決定を行う。離れた本社から仕様書をやり取りするのではない。

第二に、ともに AI を実装の武器にする。生成AIによる完成品構築コストの崩壊（Completion Cost Collapse）以降、両者ともに AI を用いてプロトタイプを動かし、現場で検証する。Expert もまた、AI でコード生成・プロトタイプ実装を駆使する。AI がエンジニアリングの裾野を広げた今、事業開発の専門家がコードを書きながら現場に立つことは、もはや例外ではなく現実である。

第三に、ともに「作って終わり」ではなく、事業を前に進めることを成果とする。

共通点の上に立ったうえで、では何が違うのか。次節で5つの軸に分解する。なお、Forward Deployed Engineer の系譜と定義については Forward Deployed Engineer を参照されたい。

2つの違いはどこにあるのか──5つの軸

両者の違いは、主たる資産・対話相手・成果物・担うフェーズ・AIへの立ち位置、の5つの軸で整理できる。

観点	Forward Deployed Engineer	Forward Deployed Expert
主たる資産	エンジニアリングスキル＋AI実装能力	事業開発の実践知＋AI実装能力
経営と"何を"決めるか	技術・プロダクトの合意	事業・収益の意思決定そのもの
主たる成果物	プロダクト	収益構造の再設計
担う事業開発フェーズ	実装フェーズの完遂	仮説構築〜完成品ローンチ〜社内意思決定突破
AIへの立ち位置	AIを武器にコードを書き、作り切る	AIを武器に何を作るかを見極め、事業を駆動する

主たる資産。 Engineer の核心資産は「作り切る力」である。技術的に難易度の高い要件をプロダクトとして成立させる力。Expert の核心資産は「何を作るかを定義し、社内を動かす力」である。事業開発の実践知が一次資産であり、AI実装能力はその実践知を増幅させる二次的な武器として機能する。

主たる対話相手。 Engineer は技術責任者の隣に座る。要件、アーキテクチャ、データ設計、運用責任の所在。これらの議論を技術側の言語で進める。Expert は事業責任者・経営層の隣に座る。事業ポートフォリオ、KPI 設計、組織の合意形成、予算化のタイミング。これらの議論を経営の言語で進める。

主たる成果物。 Engineer の成果物は、プロダクトという「もの」である。動くソフトウェア、稼働するシステム、顧客が触れる実装。Expert の成果物は、収益構造の再設計 という「事業の質的変容」である。プロダクトはその一要素にすぎず、課金モデル、バリューチェーン、パートナーシップ構造までを含む。

担う事業開発フェーズ。 Engineer は実装フェーズの完遂を担う。要件が固まった後、それを動くものに変換する射程。Expert は仮説構築から完成品ローンチ、その後の社内意思決定突破までの広い射程を担う。「何を作るか」が定まる前から現場に立ち、ローンチ後の市場反応で仮説を更新し続ける。

AIへの立ち位置。 Engineer は「AIで作る」。生成AIをコード生産性の武器として使い倒し、Completion Cost Collapse 後の時代に作り切る速度を最大化する。Expert は「AIで“何を作るか”を見極めて駆動する」。生成AIを仮説の検証装置として使い、市場と対話しながら事業の進路そのものを決定する。

Engineer が「作り切る現場」を、Expert が「何を作るかを見極め、社内の意思決定を突破する現場」を担う。両者が同じ現場に並び立つことで、AI時代の事業実装は完結する。Expert の能力の中身については、定義の本体である Forward Deployed Expert にゆずる。

よくある誤解：「ビジネスもやるエンジニア」のことではないのか

FDE=Expert は、『ビジネスもできるエンジニア』の言い換えではない。事業責任者の隣に座り、社内の意思決定を突破し、収益構造を再設計する専門性は、エンジニアリングの「付随スキル」ではなく、独立した実践知だからである。

この誤解は構造的に発生する。AI 時代には「技術とビジネスの断絶を、ビジネスもわかるエンジニアで埋める」という発想が広がっている。それ自体は自然で有効な解である。技術側から越境する人材が、現場の難所を一人で抜けるケースは確かに存在する。

ただし、技術側から越境する人材と、事業開発の実践知を主資産として現場に立つ人材は、必要とされるフェーズも、対話相手も、突破すべき壁も、構造的に異なる。前者を否定しているのではない。後者という「もう一つの極」が、独立した専門性として存在するという整理である。

なぜいま、後者が独立した極として立ち上がるのか。それは、完成品の製造コストが崩れたからである（書籍『AI収益進化論』第3章）。AI コーディングと生成AIの跳躍によって、「作れること」自体の希少性は急速に下がった。Anthropic 内部調査では、社員のClaude支援業務のうち27%が「Claudeがなければ発生しなかった仕事」だと報告されている。「作る」という行為の前提が変わったのである。

「作れること」が希少でなくなった世界では、「何を・誰に・なぜ作るか」を定義し、社内の意思決定を突破して市場に届ける力が、独立した希少資源として立ち上がる。MIT NANDA の調査では、エンタープライズAIツールの本番化変換率は5%にとどまり、組織の95%が測定可能な財務リターンを得られていない。この「GenAI Divide」を超える鍵は、技術側ではなく、事業設計と組織突破の側にある（MIT NANDA Project, 2025）。

だから Expert は「エンジニアの上位互換」でも「下位」でもない。技術側から越境する人材と並んで、事業開発の実践知を主資産とする「もう一つの極」として独立に存在する。役割が違うのである。

どちらが必要なのか──現場での組み合わせ

多くの現場では、どちらか一方ではなく両方が必要になる。ボトルネックがどこにあるかで、どちらが前面に立つかが決まる。

• 実装の完遂が詰まっている（要件は固まっているが作り切れない）→ Engineer が前面。
• 「何を作るか」が定まらない／社内の意思決定・予算化で止まっている／市場反応で仮説を更新し続ける必要がある → Expert が前面。
• 新規事業をゼロから収益化まで連続して走らせる → 両者が同じ現場に並び立つ。

判断の補助線として、もう一つ重要な軸がある。AI 推進が効率化の領域で頭打ちに達した後、そのまま収益進化の領域へ連続して伴走できるかどうかである。McKinsey 調査では、AI 利用企業88%のうち、EBIT 影響を報告する企業は39%にとどまり、その多くが EBIT の5%未満である（McKinsey State of AI, 2025）。効率化AIの山を登り切った先に、収益進化AIの山が別の登り口として現れる。

AlphaDrive の FDE=Expert は、効率化AI の伴走から始めて Plateau Detection 到達後にそのまま収益進化フェーズへ連続して伴走できる。効率化AIの山と収益進化AIの山を、一人の専門家が連続して登る設計である。AX for Revenue Loop の4ステップを通貫して伴走できる人材像、と言い換えてもよい。

Expertの中身は「AXアーキテクト＝BA能力×AI能力」

FDE=Expert の能力の中身は、AlphaDrive が体系化した「AXアーキテクト＝BA能力×AI能力」である。

BA能力とは、ビジネスアーキテクト能力。経営戦略を事業構造に落とす力、ステークホルダーを動かす力、組織横断で合意形成する力。AI能力とは、AI Sprint・AI Orchestration・Full-Product Launch という、AI 時代に固有の事業実装能力。両者の掛け算が、Expert の能力の輪郭である。

詳細な能力定義は Forward Deployed Expert と AXアーキテクト にゆずる。本記事では、Expert の中身が「AI もわかるビジネスパーソン」でも「ビジネスもわかるエンジニア」でもなく、独立した方法論として体系化された人材像である点を確認するに留める。

世界が「FDE=Engineer」を標準語として確立する一方、AlphaDrive は「AXアーキテクトを Forward Deployed に常駐させる」というもう一つの解を、日本で AI 事業開発の文脈において提示している。

まとめ：Engineer の隣に、Expert を

FDE=Engineer と FDE=Expert の違いは、優劣ではない。「何を作れるか」と「何を作るかを見極め、社内の意思決定を突破するか」という、役割の違いである。

Engineer が「作り切る現場」を担い、Expert が「何を作るかを見極め、社内を動かす現場」を担う。両者が同じ現場に並び立つことで、AI 時代の事業実装は完結する。AIは効率化から、収益の創造へ。その移行を現場で起こすには、Engineer の隣に、Expert がいる。

Expert の定義の本体は Forward Deployed Expert へ、能力体系の詳細は AXアーキテクト へ進まれたい。

よくある質問

Q1. Forward Deployed Engineer と Forward Deployed Expert は、どちらが新しい概念ですか。

Forward Deployed Engineer の方が先に確立された語である。Palantir を起点に、Anthropic・OpenAI をはじめとする先端AI企業が継承してきた標準語として、世界的に広く認知されている。Forward Deployed Expert は、その敬意の上に置かれる、もう一つの中核人材像として、AlphaDrive が AI 事業開発の文脈で日本において提示した整理である。両者は時系列の前後関係にあるのではなく、役割の異なる二つの極として並列に存在する。

Q2. Expert はコードを書かないのですか。

書く。Expert もまた、AI を活用してコード生成・プロトタイプ実装を駆使する。Completion Cost Collapse 以降、事業開発の専門家がコードを書きながら現場に立つことは現実になった。違いは「コードを書くかどうか」ではなく、主たる資産が事業開発の実践知に置かれているか、エンジニアリングスキルに置かれているか、という重心の置き方にある。

Q3. なぜ「ビジネスもできるエンジニア」では不十分なのですか。

不十分という整理ではない。技術側から越境する人材は、現場の難所を抜ける有効な解の一つである。ただし、事業責任者の隣に座り、社内の意思決定を突破し、収益構造を再設計する専門性は、エンジニアリングの「付随スキル」として身につくものではなく、独立した実践知である。両者は対立せず、必要とされるフェーズと対話相手が異なる、別軸の専門性として並列に存在する。

Q4. 自社にはどちらが必要か、どう判断すればよいですか。

ボトルネックの所在で判断する。実装の完遂が詰まっているなら Engineer が前面に立つべきであり、「何を作るか」が定まらない、社内の意思決定や予算化で止まっている、市場反応で仮説を更新し続ける必要があるなら Expert が前面に立つべきである。新規事業をゼロから収益化まで連続して走らせる場合は、両者が同じ現場に並び立つ構成が現実的である。

Q5. なぜ AI 時代に「Expert」という独立した極が立ち上がるのですか。

完成品の製造コストが崩れたからである。「作れること」自体の希少性が急速に下がった世界では、「何を・誰に・なぜ作るか」を定義し、社内の意思決定を突破して市場に届ける力が、独立した希少資源として立ち上がる。MIT NANDA の調査が示すように、エンタープライズAIツールの本番化変換率は5%にとどまる。この差を埋めるのは技術側だけではなく、事業設計と組織突破の側にある専門性である。

---

発行: 株式会社アルファドライブ 編集: AX for Revenue Institute 編集部 最終更新: 2026年5月4日