フォワード・デプロイド・エンジニア:AIスタートアップはいつ採用すべきか、そしてコンサル会社にならない方法(2026年)

Surya Pratap
By Surya Pratap

2026年7月25日

9 min read

Startup Strategy
顧客の環境に常駐し、プロダクトのリポジトリにコードを持ち帰るフォワード・デプロイド・エンジニア

今月、創業者たちのXを眺めていると、ある職種名が何度も目に入ります。フォワード・デプロイド・エンジニア(FDE)です。この職種の採用は前年比で10倍以上に増え、AWSは10億ドル規模の投資に支えられているとされる専門のフォワード・デプロイド・エンジニアリング組織を立ち上げました。2026年半ばには、6桁ドルの契約を持つシリーズAのAIスタートアップのほぼすべてが、少なくとも1人は採用しようとしています。Redditでも同じ話題が、より強い不安とともに語られています。これはエンタープライズAIをようやく本番に乗せる職種なのか、それともコンサルティング事業を作り直してプロダクト企業と呼ぶための、体のいい方便なのか、と。

どちらの見方にも一理あり、その緊張関係こそが、この職種が創業者にとって重要な理由です。FDEはAIにおけるラストワンマイル問題への答えです。モデルは簡単な部分で、実際の顧客の実際のシステムの中でそれに本当の仕事をさせる泥臭い作業こそが、商談の成否を分けます。この体制をうまく回せば、プロダクト・マーケット・フィットへの最短経路になります。間違えれば、スタートアップは知らないうちに、想像以上に利益率の低いサービス会社に変わってしまいます。この記事は、この職種の実態、最初の1人を採用するタイミング、そしてプロダクトを作り続ける体制にしておく方法についての、創業者向けガイドです。

フォワード・デプロイド・エンジニアとは実際に何か

フォワード・デプロイド・エンジニアとは、顧客を見る目を持ったエンジニアで、およそ60〜180日間顧客の環境に入り込み、実際の連携を出荷し、曖昧な企業の課題を動くソフトウェアに変える人です。成果物はスライド資料や要件ヒアリングの文書ではなく、本番のコードです。この機能は2008年ごろにPalantirが生み出し、2023年にはOpenAIとAnthropicが大規模言語モデルの時代に合わせて作り直しました。2026年には、フロンティアラボからSierra、Decagon、Databricksといった企業、さらに資金力のある多数のスタートアップへと広がっています。

重要なのは、FDEと従来のソリューションエンジニアとの違いです。ソリューションエンジニアは販売を支援し、既存の機能を設定します。FDEは顧客のスタックに入るコードを書き、体制が健全であれば、そのコードは自社のメインのプロダクトリポジトリにも戻ってきます。プリセールスよりもフィールドエンジニアに近く、優れたFDEは、顧客のレガシーなデータベースにも自社のコードベースと同じくらい慣れています。

なぜ2026年にこの職種が急増したのか

FDEブームは、今年広く語られてきた変化の当然の帰結です。AIはデモを抜け出し、実際に仕事をし始めています。プロダクトが提案をするだけのコパイロットだった頃は、顧客はログインするだけで導入できました。プロダクトが、請求書の照合、チケットの解決、申告書の作成といった範囲の決まった仕事をやり遂げるシステムになると、権限、承認、レガシーなソフトウェア、そして顧客ごとにまったく異なる人間の回避策とつながらなければなりません。その連携作業こそがラストワンマイルであり、より良いプロンプトでは片付きません。

FDEが「行動のシステム(systems of action)」という考え方と自然に噛み合うのも、そのためです。長く生き残るAI企業が、特権的なアクセスを伴う範囲の決まったワークフローを握る企業だとすれば、誰かが顧客ごとの現実にプロダクトを物理的に組み込み、そこで学んだことをコアのプロダクトに還元しなければなりません。FDEは、苦労して勝ち取った1件のエンタープライズ導入を、プロダクトライン全体が受け継ぐ再現可能な能力に変える、人間の仕組みなのです。

ラストワンマイル問題

エンタープライズAIでは、モデルが難しい部分であることはめったにありません。難しいのはラストワンマイル、つまり顧客のデータの形、権限、承認の連鎖、レガシーなシステムです。FDEが存在するのは、その1マイルが営業でも、ドキュメントでも、プロンプトでも片付かないからです。現場でエンジニアリングするしかありません。

罠:うっかりコンサル会社を作ってはいけない

議論のRedditの側で目立つのは、次の失敗です。創業者がFDEを、名前を変えただけのソリューションエンジニアとしてGo-to-Market組織に組み込み、成約した商談や処理したチケットで評価してしまう。この構造は、カスタム作業をプロダクトに変えることを何も評価しないため、知らないうちに一回限りのカスタム作業に最適化されていきます。これを長く続ければ、ソフトウェアのロゴを掲げたコンサル会社ができあがります。売上は大きいが利益率は薄く、ロードマップは前の四半期にいちばん声の大きかった顧客に決められてしまうのです。

これを避けるパターンは、もともとPalantirで、そして現在はAnthropicで採られているもので、FDEを営業ではなくエンジニアリング組織に置くことです。フルタイムのエンジニアが顧客の現場とコアのコードベースを行き来し、現場で行った仕事はプロダクトになることが期待されます。エンジニアリングの指揮系統に入れることで、作ったものをプロダクト化する方向への恒久的なバイアスが生まれます。カスタム連携を出荷する人自身がそれを保守しなければならないので、プラットフォームとして汎用化する動機が生まれるのです。

プロダクト化テスト

導入が終わるたびに、1つだけ問いかけてください。FDEがこの顧客のために作ったもののうち、次の顧客には無料で届くようになったものは何か。正直な答えが「何もない、すべてカスタムだった」なら、あなたが運営しているのはサービス事業です。コアのプロダクトに新しいコネクター、テンプレート、機能が加わったのなら、運営しているのはフィールドチームを持つプロダクト企業です。

創業者が最初の1人を採用すべきタイミング

タイミングは採用そのものより重要です。最初のFDEを迎えるべきシグナルは、「エンタープライズに売りたい」ではありません。意味のある契約規模を超える再現可能なエンタープライズのパイロットをすでに3件ほど成約していて、創業者であるあなた自身が顧客との連携作業のボトルネックになっていることです。言い換えれば、需要が証明され、自分の時間が制約になってから採用すべきで、その前ではありません。

早すぎる採用は、まだ存在しない需要を作り出すためにシニアエンジニアに給料を払うことになり、コストを正当化するためにどんなカスタム案件でも引き受けたくなります。遅すぎる採用は、創業者が真夜中に自ら顧客の環境をデバッグしている間に、すべての商談が導入段階で止まってしまいます。窓が開くのは、パイロット間に共通するパターンがFDEが汎用化できるほど明確になったときで、遅い連携作業が成長の天井になり始めると閉じていきます。

報酬の現実

これはジュニアの採用ではないので、創業者はコストについて冷静に向き合う必要があります。この職種の報酬総額は、シード段階の約20万ドルから、シリーズCでは45万〜55万ドル以上に及びます。フロンティアラボの求人は、一般的なプロダクトエンジニアの水準より上に集中しています。トップラボのシニアFDEは中央値で48万5,000ドル近くと報告されており、スタッフレベルの職種はさらに高くなります。あなたが払っているのは、出荷する力と顧客を見る目という珍しい組み合わせに対してであり、その人材市場は本当に逼迫しています。

この価格が意味を持つのは、実際の契約規模と比べたときだけです。1人のFDEが、放っておけば止まってしまう6桁ドルの商談を動かし、拡大させるなら、計算は簡単です。5万ドル未満の契約を大量のカスタム作業で支えているなら、モデルは逆転しています。それは、プロダクトがまだエンタープライズ向けの体制に耐えられる段階にないというサインです。

採用できるようになる前は、あなた自身がFDEだ

これを読んでいる創業者の多くは、シリーズA前で、最初の一握りの本物の顧客を追いかけている段階でしょう。その場合の実務的な結論は、求人を出すことではありません。自分がすでにフォワード・デプロイド・エンジニアであると認め、この体制を意識的に回すことです。最初の顧客の環境に入り込み、連携を自分で出荷し、すべてのカスタム修正を、プロダクトがネイティブにやるべきことについての研究メモとして扱ってください。この段階で引き出したパターンこそが、将来のFDE採用を高くつくものではなく生産的なものにしてくれます。

  • 調査するのではなく、入り込む。 要件ヒアリングの電話ではなく、顧客のシステムの中で実際のタスクに取り組みます。必要なエッジケースは、実際の環境でしか現れません。
  • カスタム作業を記録する。 特定の顧客のために何かを作るたびに、どのネイティブなプロダクト機能があればそれが不要になったかを書き留めます。
  • 繰り返す前に汎用化する。 同じ連携を2回目に手作業で作ることになったら、手を止めてプロダクト化します。それが、積み上がっていく会社とコンサルとの違いです。
  • 痛みではなく、パターンで採用する。 3件以上のパイロットが同じ形をしていて、自分の時間がボトルネックになったときに最初のFDEを採用します。そうすれば、その職種は手順書を一から発明するのではなく、既知の手順書をプロダクト化することになります。

フォワード・デプロイド・エンジニアは一過性の肩書きではありません。AIを現実の世界に届けることが、営業ではなくエンジニアリングの問題だと業界が認めた証です。それを理解し、早い段階で現場に入り込み、徹底的にプロダクト化し、パターンが証明されてから初めてこの職種を採用する創業者は、商談を潰していたラストワンマイルを、自社を守る堀に変えていきます。

IdeaToMVP Academy

Want to build with AI — not just read about it?

4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.

Explore the Academy →
Share this post :