フォワード・デプロイド・エンジニアリング（FDE）とは
AI時代に世界が注目する「現場配備型」開発の進め方

フォワード・デプロイド・エンジニアリング（Forward Deployed Engineering、FDE）とは、エンジニアが顧客の事業の現場に入り込み、課題の定義から設計・実装・運用・改善までを同じチームが一気通貫で担う開発の進め方です。米Palantir社が確立した職種・体制の概念で、生成AIの普及を機にOpenAIやAnthropicといった主要AI企業が相次いでFDEチームを設けたことで、いま世界的に注目が高まっています。本記事では、FDEの定義と起源、AI時代に求められる理由、従来型SI・常駐SES・ラボ型開発との構造的な違い、そして日本企業が現実的なコストでFDEを活用する方法までを解説します。

フォワード・デプロイド・エンジニアリング（FDE）の定義

「Forward Deployed」は軍事用語の前方展開に由来する表現です。後方の基地（＝開発会社のオフィス）で仕様書が届くのを待つのではなく、エンジニアを前線（＝顧客の事業の現場）に配備し、その場で課題を見つけ、その場で動くソフトウェアを作り、その場で直し続ける。この進め方を体制として制度化したものがフォワード・デプロイド・エンジニアリングであり、それを担う職種がForward Deployed Engineer（FDE）です。

FDEは単なる「常駐エンジニア」ではありません。従来の受託開発やSESとの本質的な違いは、次の4点に集約されます。

• 要件を「聞き取る」のではなく「現場で発見する」——業務を観察し、試作を当てて反応を見ることで、文書化されていない本当の課題を特定します。
• 仕様書より先に動くものを出す——数週間の要件定義工程を挟まず、短いサイクルで動くソフトウェアを現場に見せ、フィードバックで磨きます。
• 作る人と直す人が同じ——設計・実装した本人（同じチーム）が運用と改善まで持つため、引き継ぎロスや伝言ゲームが発生しません。
• 技術と事業の翻訳者を兼ねる——エンジニアリングと顧客の業務理解の両方を持ち、「作れるもの」と「価値が出るもの」のずれを現場で埋めます。

起源はPalantir——「Delta」と呼ばれたエンジニアたち

FDEという職種を生み出し、広めたのは米Palantir Technologies社です。政府機関や大手金融機関向けにデータ分析基盤を提供してきた同社は、創業初期から自社エンジニアを顧客組織の内部に送り込み、現場でソリューションを構築するモデルを採ってきました。このエンジニアたちは社内で「Delta」と呼ばれ、The Pragmatic Engineerの解説によれば、2016年に製品「Foundry」を立ち上げるまで、Palantir社内ではFDEの人数が通常のソフトウェアエンジニアの人数を上回っていたとされます。プロダクト企業でありながら、社員の過半が顧客の現場側にいた——それほどまでに「現場に入り込むこと」を競争力の中核に置いた会社だったのです。

出典: The Pragmatic Engineer「What are Forward Deployed Engineers, and why are they so in demand?」

AI企業への広がり——いま最も需要が伸びる職種のひとつに

長らくPalantir固有の文化と見られていたFDEは、生成AIの実用化を境に業界標準の職種へと変わりつつあります。The New Stackの報道によれば、OpenAIはフォワード・デプロイド・エンジニアリングのチームを設立して急速に拡大しており、Anthropicも顧客対応のエンジニアリング部門を成長させています。同記事は、FDEの求人数が2025年1月から9月の間に800%以上増加したと伝えており、AI企業各社が「モデルを作る人」と同じくらい「モデルを顧客の現場で機能させる人」を求めていることが分かります。

出典: The New Stack「Why OpenAI and Anthropic Are Hiring Forward Deployed Engineer Teams」

なぜAI時代にFDEが注目されるのか

FDEの再評価は流行ではなく、AI導入の構造的な壁への回答です。理由は大きく3つあります。

理由1: AI導入の壁は「モデル」ではなく「現場への統合」にある

前出のThe New Stackの記事は、MIT NANDA Initiativeの調査を引き、公開されたAIプロジェクトの多く（調査対象では95%）が測定可能な成果に結びついていないこと、その主因がAIモデルの性能ではなく、既存システム・業務フロー・社内ルールへの統合の難しさにあることを指摘しています。統合の壁は、オフィスで仕様書を読んでも越えられません。現場に入り、実データと実業務に当てながら作る体制——つまりFDEが、この壁への最短の答えになります。

理由2: AIでは要件を「事前に」固めきれない

生成AIで何がどこまでできるかは、実際に自社のデータと業務で試すまで分かりません。従来型の「要件定義を固めてから見積もり、数か月後に納品」という進め方は、前提が数週間で変わるAI領域と相性が悪いのです。仕様を凍結するのではなく、動くものを起点に要件を発見していくFDEの進め方が、不確実性の高いAI案件では合理的になります。

理由3: モデルの進化速度に、作り直しのサイクルが追いつく必要がある

基盤モデルは数か月単位で世代交代し、昨日のベストプラクティスが今日は過剰設計になることもあります。作った人と運用する人が分かれた体制では、この速度に追随できません。同じチームが運用しながら改善し続けるFDEの体制は、変化の速さそのものへの備えでもあります。この構造変化の背景は、自律型AIエージェント時代のシステム開発でも詳しく解説しています。

従来型SI・常駐SES・ラボ型開発との違い

「エンジニアが客先で働く」形態は日本にも以前からあります。しかし、契約の単位・責任の持ち方・改善のループが根本的に異なります。違いを整理します。

観点	従来型SI（請負）	常駐SES	ラボ型開発	FDE
提供するもの	仕様書どおりの成果物	技術者の労働時間	専属チームの稼働枠	現場の課題解決そのもの
要件定義	着手前に凍結する	顧客側が指示する	顧客側が主導する	現場で観察・試作しながら発見する
最初の動くもの	数か月後の納品時	指示された範囲で随時	スプリント単位	数日単位で提示し反応を見る
作る人と運用する人	別（保守は別契約・別チームも多い）	契約次第で交代あり	継続はするが指示待ちになりがち	同じチームが運用・改善まで持つ
仕様変更への強さ	変更のたびに追加見積もり	指示があれば対応	柔軟だが方針は顧客依存	変更を前提に設計・体制を組む
向く案件	要件が固まった定型開発	労働力の補強	継続的な開発量の確保	要件が固まらないAI・新規領域

常駐SESとFDEは一見似ていますが、SESが提供するのは「労働時間」であり、何を作るかの判断は顧客側に残ります。FDEは課題の定義から成果までを自分ごととして持つ点で、責任の構造が逆です。また請負型SIとの違いは、仕様の凍結を前提にするかどうかに尽きます。人月と仕様凍結を前提にした従来モデルの限界については、人月商売の崩壊で詳しく論じています。

JumpStackにおけるFDEの実装——現場に配備するのは「AIチーム」

ここからは一次情報として、JumpStackがFDEをどう実装しているかをお話しします。私たちは「社員は、全員AI。監督は、人間1名。」という体制で、設計・実装・レビュー・QAをAIエージェント群が担うAI駆動開発企業です。そしてFDEを事業の中核概念に置き、お客さまの現場にAIチームを配置するという形で実践しています。進め方は3つの原則に整理できます。

1. 現場にAIチームを配置する——お客さまの事業・業務・データの文脈をチームが継続的に保持し、汎用の受け答えではなく「その会社の課題」に最適化された開発を行います。
2. 仕様書を待たず、数日で動くものを出す——完璧な要件定義書の完成を待つより、たたき台となる動くソフトウェアを数日で提示し、現場の反応を見て直すほうが、結果的に速く正確です。AIチームは24時間稼働するため、このサイクルを人間のチームより速く回せます。
3. 同じチームが運用・改善まで持つ——納品して終わりではなく、構築したチームがそのまま運用と改善を続けます。実際に、要件が固まりきらない段階から参画したSVOD（動画配信）システムの構築でも、この進め方を採っています。

本来、FDEは贅沢な体制です。優秀なエンジニアを特定の顧客に長期間張り付けるため、人件費の高い欧米AI企業では大型契約でしか成立しにくいモデルでした。私たちはここに構造的な答えを持っています。社員が全員AIであるため、優秀な「チームまるごと」を一社の現場に張り付けても、人月コストの積み上げに依存しない。FDEを現実的なコストで提供できることこそ、AI駆動開発企業がFDEを掲げる意味だと考えています。

よくある質問

Q1. FDEはプリセールスエンジニアやカスタマーサクセスと何が違いますか？

プリセールスは受注まで、カスタマーサクセスは製品の活用支援までが主な守備範囲で、どちらも自らはコードを書いて課題を解決しません。FDEは顧客の現場で実際にソフトウェアを設計・実装し、運用まで持つエンジニアリング職です。「説明する人」ではなく「作って解決する人」である点が本質的な違いです。

Q2. どのような案件がFDEに向いていますか？

要件が固まりきらない案件、特にAI活用のように「試してみないと正解が分からない」領域に向いています。逆に、仕様が完全に確定している定型的な開発であれば、従来型の請負でも成立します。判断の分かれ目は「発注時点で正解を仕様書に書き切れるか」です。書き切れないなら、FDE型の進め方を検討する価値があります。

Q3. 「現場に入る」とは物理的な常駐が必須ということですか？

いいえ。FDEの本質は物理的な席の位置ではなく、顧客の業務・データ・意思決定の文脈に深く入り込むことです。リモートでも、日次の同期・実データへのアクセス・現場担当者との直接対話があれば成立します。JumpStackの場合はAIチームがオンラインでお客さまの文脈を保持し続けるため、場所の制約なくFDEの密度を実現できます。

まとめ——FDEは「贅沢な体制」から「合理的な標準」へ

フォワード・デプロイド・エンジニアリングとは、エンジニアを顧客の現場に配備し、課題発見から実装・運用までを同じチームが担う進め方です。Palantirが確立し、AI時代の統合の壁を前にOpenAIやAnthropicが採用したことで、いや応なく世界標準になりつつあります。日本企業にとっての論点は「FDEが良いかどうか」ではなく、「贅沢な体制だったFDEを、誰が現実的なコストで提供できるか」です。社員が全員AIのJumpStackは、その答えのひとつとしてFDEを提供しています。要件が固まらない構想段階からでも、まずは現場の課題をお聞かせください。サービスとしての進め方・料金の考え方はFDEのご依頼ページにまとめています。