AIエージェント時代、なぜFDEが重要になるのか
Forward Deployed Engineerは「顧客の中でプロダクトを発見する人」

1 なぜ今 FDE が再評価されているのか

ここ数年、シリコンバレーでは FDE 採用が一気に増えている。Bob McGrew によれば、YC の求人ボードでは 100 社を超えるスタートアップが FDE を募集していた時期があり、数年前にはほぼゼロだったという。これは単なる流行ではない。AI エージェントという製品カテゴリが、まだ完成済みの市場や標準ワークフローを持っていないことの裏返しである。

従来の SaaS であれば、ある程度は「このカテゴリにはこういう incumbent product がある」「この UI ならユーザーは理解できる」「導入後の使い方はだいたい想像がつく」という前提があった。ところが AI エージェントには、それがまだない。契約レビュー、調達、営業、法務、サポート、現場オペレーション——どの領域でも、エージェントがどう組み込まれると価値になるのかは、実際に顧客の現場に入ってみないと見えない。

AIエージェント時代に必要なのは、売ることより先に「何が本当に価値になるか」を現場で見つけることだ。

だから FDE が必要になる。FDE は、営業資料のうえで「売れそうなもの」を語る人ではない。顧客の内部に入り、既存のツール・データ・ワークフロー・組織制約を見ながら、「この会社で最初に解くべき 1 つの問題は何か」を見つける人である。AI エージェント市場では、その discovery が製品開発とほぼ同義になっている。

2 FDE とは何者なのか

Bob McGrew の説明を要約すると、FDE とは 既存プロダクトの機能と、顧客が本当に必要としている結果のあいだを埋める技術者 である。顧客の現場で使われている業務、データ、ボトルネックを理解し、現在の製品がまだ届いていない部分を埋める。そこには coding もあれば prototype もあるし、要件整理もあればデモ設計もある。つまり、FDE は「導入後の保守要員」ではなく、顧客の中で product discovery を実行する front-line engineer なのだ。

重要なのは、FDE は「顧客の言ったことをそのまま作る人」ではないという点である。むしろ逆だ。顧客はしばしば、小さく安全で、だが本質的には価値の薄い改善を求めがちだ。FDE の仕事は、そこに従順に応えることではなく、CEO や事業責任者の上位課題に食い込む 3 倍・10 倍の変化を見つけることにある。だから domain knowledge だけでなく、ある種の「異端性」や「現状を疑う視点」が必要になる。

3 Palantir 型 FDE モデルの核心

Bob McGrew が語る Palantir の話で面白いのは、FDE 戦略が最初から「美しい理論」として存在していたわけではないことだ。情報機関向けソフトウェアを作ろうとしたが、ユーザーは特殊で、業務は外から見えず、一般的な SaaS のように「同じものを大量に売る」だけでは成立しなかった。そこで、顧客現場で小さく作り、学び、次に広げるというやり方が定着していった。

その中核にあったのが、Echo team と Delta team という分担である。Echo は顧客現場に入り、どの問題が本当に重要か、どのデモが刺さるか、誰と関係を作るべきかを見極める。Delta は高速でコードを書き、prototype を組み、短期間で動くものを届ける。この 2 つを束ねることで、「売る」「作る」「学ぶ」が分断されず、同じループの中に置かれる。

ここで印象的なのが、FDE は「プロダクトの外」にいるのではなく、むしろプロダクトチームの外縁を顧客現場まで伸ばした存在だという点である。FDE が現場で作った砂利道を見ながら、プロダクトチームは「この問題を、次の 5 社・10 社にも効く形でどう一般化するか」を考える。だから FDE と product が分断すると、このモデルはすぐ壊れる。

4 なぜ FDE は単なるコンサルではないのか

FDE モデルには、しばしば「それって結局コンサルでは？」という批判がつく。Bob McGrew の答えは興味深い。彼は、その批判を雑に否定しない。むしろ 本当に consulting business に堕ちるリスクはある と認めたうえで、どこで分岐するかを説明している。

分岐点は明確だ。顧客ごとに毎回ゼロから作り続け、学びが製品へ戻らず、利益率も改善しないなら、それは consulting である。だが、FDE の現場 work を通じて product discovery が進み、導入コストが下がり、次の顧客で同じ成果をより短く出せるようになるなら、それは product business としてスケールし始めている。

つまり KPI も変わる。単に稼働率や請求工数を見るのではなく、契約規模、解決した outcome の大きさ、次回導入の容易さ、product leverage の増加 を見る必要がある。AI エージェント企業が FDE を採用しても、それが「PoC 工場」になるのか「学習する product 組織」になるのかは、ここで決まる。

5 AIスタートアップが学ぶべきこと

AI エージェント企業にとって、FDE モデルの魅力は obvious である。エージェントは能力の伸びが速い一方で、採用・定着・運用はそれほど速く進まない。つまり市場には、「モデルができること」と「顧客が業務として受け入れられること」のあいだに大きなギャップがある。Bob McGrew は、今のスタートアップが埋めているのはまさにそのギャップだと言う。

ただし、ここで誤ると危ない。FDE を採用しただけで勝てるわけではない。重要なのは、何を outcome として売るのか、どの問題に入り込むのか、どこでプロダクト化へ戻すのかである。スタートアップが学ぶべきポイントは、少なくとも次の 4 つある。

• ソフトウェアの売上ではなく outcome を売る — ただの seats や usage ではなく、顧客が得る結果で語る。
• CEO の上位課題に刺さる問題を選ぶ — IT の雑務改善ではなく、経営が本当に気にする課題へ行く。
• デモを product discovery の道具として使う — 機能紹介ではなく、顧客が欲しくなる未来像を見せる。
• FDE と product を切り離さない — 現場の砂利道を、次の顧客向けの高速道路へ変える組織が必要。

ここは Managed Agents の話ともつながる。AI エージェント時代の価値は、単にモデルが賢いことではなく、どれだけ現実の業務に埋め込めるかで決まる。その埋め込みのために必要なのが、runtime だけでなく FDE 的な front-line discovery なのである。

6 FDE 人材像と demo-driven development

この話でもうひとつ重要なのが、「誰を FDE にするのか」という論点である。Bob McGrew の語りでは、Echo 側にはその業界を深く知る人が必要だが、同時にその現状に満足していない heretic でなければならないとされる。現場をよく知っていても、「今のやり方で十分だ」と思っている人は、3 倍・10 倍の変化を構想できないからだ。これは日本企業にもそのまま当てはまる。業務に詳しいだけでは足りず、業務を組み替える視点が必要になる。

Delta 側に求められるのも、いわゆる長期保守向けの完璧主義とは少し違う。重要なのは、短期間で prototype を立ち上げ、荒くても動くものを出し、顧客の反応を見ながら次へ進める力である。第一版が将来捨てられる可能性を受け入れつつ、それでも価値のある速度で前に進める人材が必要になる。FDE が「創業者育成装置」に近いと言われるのは、この感覚がそのまま startup building に通じるからだ。

そして、この役割を機能させるうえで demo-driven development は極めて重要になる。Palantir 初期の話でも、単なる機能一覧ではなく「この流れで本当に顧客の仕事が変わる」と感じられるデモが重視されていた。良いデモは、単なる営業資料ではない。顧客にとっての desired outcome を視覚化し、何が足りていないかを早い段階で炙り出す product discovery の装置である。AI エージェント企業にとって、デモは飾りではなく、現場学習のインターフェースだと言っていい。

7 日本企業にとっての示唆

日本では、FDE という言葉自体はまだ一般化していない。しかし役割の必要性はむしろ高い。日本企業の AI 導入では、単純な SaaS 置き換えよりも、部門ごとに微妙に違う業務フロー、長い承認経路、既存システムとの接続、慎重な現場運用が障害になることが多い。つまり「機能を売る」だけでは前に進まない。

ここで必要なのは、顧客の内側に入り、最初の勝ち筋を作り、その勝ち筋を次の顧客へ一般化する人材である。名前が FDE でなくてもいい。だが実態としては、営業と開発のあいだで要件を受け渡す人ではなく、顧客の問題を技術的に解きながら製品へ還流させる人が必要になる。

この観点は、Claude Code Best Practice 深掘り記事 や ハーネスエンジニアリング完全ガイド ともつながる。AI を本番導入するには、モデル選定よりも先に、どの仕事をどう任せ、どこで監視し、どう再現可能にするかを設計しなければならない。FDE は、その設計を顧客の中で現実に接続する役割なのである。