「FDE を何人入れるか」「FDE 型の支援でお願いしたい」。2026年に入って、AI 導入の商談でこの3文字を聞く機会が急に増えました。OpenAI と Anthropic が大規模に採用し、AWS は6月に10億ドル（約1,500億円規模）を投じる専門組織を作りました。ところが、日本語で「FDE とは何か」を発注側の目線で説明した文章は、まだ多くありません。
この記事は、AI 導入を検討している経営者・管理部門・情シスの方に向けて書いています。FDE（Forward Deployed Engineer、フォワード・デプロイド・エンジニア）とは何者で、なぜ今こんなに注目され、SIer やコンサルと何が違い、自社が「FDE 型の支援」を受けるなら何を確認すべきか。この4点が分かるようにまとめました。
FDE を一言でいえば、「AI 会社から自社に出向してきて、自社の業務の中で AI を動くところまで作り、動かし方を残して帰るエンジニア」。買い手にとっての本質は、成果物が『提案書』ではなく『本番で動いている仕組み』であることだ。
この記事の要約
FDE をひとことで
FDE は直訳すると「前線に配置されたエンジニア」です。ソフトウェア会社に所属しながら、顧客企業の現場に入り込み、そこで実際に動くシステムを作る技術者を指します。営業に同行して説明するだけでもなく、外から提案書を書くだけでもなく、顧客の環境の中でコードを書き、本番で動かし、定着するまで見届ける。それが仕事です。
身近な例えでいえば、「メーカーから出向してきて、自社の工場のラインにその会社の機械を組み込み、動かし方を現場に教えてから帰るエンジニア」に近い。違うのは、扱うのが機械ではなく AI であり、組み込む先が経理・営業・カスタマーサポートといった事務の業務フローだという点です。
英語圏の技術メディア The Pragmatic Engineer は、FDE を「顧客チームに入り込む期間と、本社の製品開発チームに戻る期間を行き来するソフトウェアエンジニア」と定義しています。この「行き来する」が大事で、現場で見つけた課題を製品側に持ち帰るのも仕事のうちです。
生まれたのは Palantir。「エンジニアの半分以上が顧客先にいた」会社
この職種を作ったのは、米国のデータ分析企業 Palantir です。2010年代前半、同社の主な顧客は情報機関でした。顧客は仕事の中身を明かせないため、通常の「要望を聞いて製品を作る」進め方ができません。そこで、エンジニアを顧客の中に送り込み、内側から必要なものを作る体制をとりました。
Palantir はこの役割を社内で「Delta（デルタ）」と呼び、技術者ではない相方として、顧客の目的や関係者、定着を担当する「Echo（エコー）」という職種を組み合わせました。2016年ごろまで、同社には通常のソフトウェアエンジニアより FDE のほうが多かったとされています。製品 Foundry を出した後は、現場を知る FDE が製品開発側に戻り、その経験が製品に反映されました。
つまり FDE は、「売る前に製品が完成している」ことを前提にした従来のソフトウェア商売では成り立たない場面から生まれた職種です。顧客ごとに環境も課題も違い、入ってみないと何を作ればよいか分からない。生成 AI の企業導入は、まさにこの状態にあります。
SIer・コンサル・セールスエンジニアと何が違うのか
日本の発注側が最初に迷うのはここです。「うちには SIer もコンサルもいる。FDE と何が違うのか」。違いは、所属・成果物・関わる期間の3点で整理できます。
| 役割 | 所属 | 主な成果物 | 関わり方 | FDE との違い |
|---|---|---|---|---|
| FDE | AI・ソフトウェア会社 | 顧客環境で本番稼働する仕組み | 数週〜数か月、顧客先に常駐に近い形で | — |
| SIer・SES | 受託開発会社・派遣元 | 要件どおりのシステム | 契約期間中、指示に基づき開発 | FDE は自社製品の担当者として入り、要件そのものを一緒に決める |
| IT コンサル | コンサルティング会社 | 提案書・構想・ロードマップ | 短期の調査・提言が中心 | FDE は提言で終わらず、自分でコードを書いて動かす |
| セールスエンジニア | ソフトウェア会社 | デモ・検証環境・提案支援 | 商談中心。受注後は別チームへ | FDE は受注後の本番構築と定着まで責任を持つ |
| ソリューションアーキテクト | クラウド・ソフトウェア会社 | 設計図・試作 | 設計助言が中心。顧客の実データは触らないことが多い | FDE は顧客の実データ・実システムの中で作る |
The Pragmatic Engineer の整理を借りれば、ソリューションアーキテクトが「匿名化データで試作を作る」のに対し、FDE は「顧客のインフラの上で実コードを書く」。コンサルタントが「一度きりの提言」をするのに対し、FDE は「長期に伴走する」。セールスエンジニアが「受注」に軸足を置くのに対し、FDE は「製品への還元」まで含む。この3点が違いです。
発注側の実務でいえば、SIer には「仕様書を渡す」、コンサルには「課題を渡す」のに対し、FDE には「業務そのものを見せる」ことになります。渡すものが違うので、社内の準備も違ってきます。これは後の章で扱います。
なぜ2026年に急に増えたのか——「試作はできたが本番に乗らない」問題
FDE が注目される理由は一つです。生成 AI は「試しに使う」のは簡単でも、「業務に組み込んで毎日動かす」のが難しい。この「試作と本番の隙間」を埋める人が足りない。エンタープライズAI導入を『試す』から『業務にする』へで書いたスケール4段階の、まさに2段目から3段目で詰まる会社が多いのです。
そこで2026年、AI 会社自身が「導入をやり切る部隊」を持つ動きが相次ぎました。
| 時期 | 動き | 規模・特徴 |
|---|---|---|
| 2026年5月 | OpenAI が「OpenAI Deployment Company」を設立 | TPG など19社が40億ドル超を出資。FDE を中核に、投資先企業への AI 導入を請け負う |
| 2026年5月（7月に社名公表） | Anthropic が Blackstone・Hellman & Friedman・Goldman Sachs と企業向け AI サービス会社を設立（社名「Ode with Anthropic」） | 15億ドル規模。中堅企業に エンジニアを送り込み、業務をエージェント前提に組み直す |
| 2026年6月30日 | AWS が FDE 専門組織を新設 | 10億ドルを投資。数千人規模の専門家を顧客先に配置。NFL では「数週間で本番稼働」 |
| 通年 | OpenAI・Anthropic が FDE を各都市で採用 | OpenAI は東京を含む世界各都市で募集。Anthropic は「3年以上の顧客対応型の技術職経験」を要件に |
注目したいのは、3社とも「AI 会社が直接やる」のではなく、投資会社やコンサル会社と組んで「導入専門の別会社」を作っている点です。モデルを売る商売と、導入をやり切る商売は、必要な人も収益の型も違う。それを分けて、後者に本気で資本を入れた、ということです。海外で広がる『Claude 業務導入コンサル』市場で書いた流れが、この半年で大手の正式事業になりました。
裏を返せば、AI 会社側が「モデルを渡すだけでは導入が進まない」と認めたということでもあります。買い手にとっては、「導入が難しいのはうちの現場のせいではない」と分かる材料になります。
FDE は現場で何をするのか——3つの段階
FDE の仕事は、おおむね3段階で進みます。The Pragmatic Engineer が OpenAI の進め方として紹介している型を、発注側の言葉に置き換えます。
- 見立て（スコーピング）。 現場に入り、業務の流れとデータを実際に見て、「どの業務に、どこまで AI を入れるか」を決める。ここで対象を絞り込めるかが成否を分ける。
- 検証（バリデーション）。 小さく作って、「正しく動いたか」を測る物差し（評価基準。英語で eval と呼ぶ）を先に用意し、数字で確かめる。感想ではなく合格率で判断する。
- 本番化（デリバリー）。 顧客の実システムに組み込み、本番で動かし、現場が自分たちで回せるように手順と担当者を残す。
この「物差しを先に作る」が、FDE の仕事を SIer や社内の試行錯誤と分ける一番の特徴です。生成 AI は同じ入力でも毎回少しずつ違う答えを返すため、「動いた／動かない」の二択では評価できません。「100件のうち何件が合格か」で見る必要があり、その合格基準を業務側と一緒に決めるのが FDE の腕の見せどころです。
もう一つ、FDE は本社に戻る前提で動きます。OpenAI の求人には「出張は最大50%」とあり、The Pragmatic Engineer の取材では「顧客先で過ごす時間は25〜50%」とされています。残りの時間は製品側にいます。現場で見つけた「ここで詰まる」を製品に持ち帰るためで、これが顧客にとっては「次の版で直る」という形で返ってきます。
発注側が知っておくべき4つのこと
ここからが本題です。自社が FDE、あるいは「FDE 型」の導入支援を受けるとき、契約前に押さえておきたいことを4つに絞ります。
1. 成果物は「動いている仕組み」と「動かし方」の両方
FDE 型支援の価値は、本番で動く仕組みが残ることです。ただし、それだけでは FDE が帰った翌月に止まります。AWS の発表では、顧客に残すものとして「稼働するエージェント」に加え、「手順書（ランブック）」「構成の説明資料」「社内で運用を引き継ぐ担当者の育成」を挙げています。契約時に「何が残るか」を、この粒度で確認してください。
2. 渡すのは仕様書ではなく「業務そのもの」
FDE には、業務の流れ・実データ・例外処理のクセを見せる必要があります。「まだ整理できていないから見せられない」では、FDE は仕事になりません。逆にいえば、業務が整理されていなくても始められるのが FDE 型の強みです。ただし、見せる以上、データの取り扱い（どこに置くか、持ち出しの禁止、終了時の削除）を先に決めておくこと。AIエージェントが企業データを漏らす5つの経路で挙げた論点は、FDE を受け入れるときの確認項目にそのまま使えます。
3. 社内に「Echo 役」を置く
Palantir が FDE（Delta）と必ず組ませた Echo は、技術者ではなく「業務の目的と関係者と定着」を見る人でした。受け入れ側にも、この役が要ります。FDE の相手をする窓口ではなく、「この業務の責任者として、AI に何を任せ、何を任せないかを決められる人」です。技術は FDE が持ってきます。足りないのは、現場の判断を引き受ける人のほうです。AI時代はIQよりEQで書いた「部門間の温度差を埋められる人」が、ここでも決め手になります。
4. 「特定の AI 会社の FDE」は、その会社の製品を前提にする
当然ですが、OpenAI の FDE は OpenAI のモデルで、Anthropic の FDE は Claude で、AWS の FDE は AWS の上で作ります。それ自体は悪いことではなく、製品を一番知っている人に作ってもらえる利点です。ただ、「他社モデルに切り替える」「複数のモデルを使い分ける」という設計は、彼らの守備範囲の外になりがちです。中立的な設計が必要な部分と、製品の専門家に任せる部分を、発注側が分けておく必要があります。
日本の中堅企業はどう向き合うか
正直に書くと、OpenAI や Anthropic の FDE が直接入るのは、当面は大企業と、投資会社の傘下にある企業が中心です。AWS も「数千人規模」と言いつつ、最初の事例は NFL や航空会社です。日本の中堅企業が明日から本家の FDE を呼べるわけではありません。
それでも、この職種が示した「型」は、規模を問わず使えます。要点は3つです。提案書ではなく本番で動くものを成果物にする。感想ではなく合格率で評価する。帰った後に回る手順と担当者を残す。この3つを満たす支援者であれば、肩書きが FDE でなくても、やっていることは同じです。
筆者の実感では、日本の AI 導入で止まるのは「技術が足りない」場面より、「誰がこの業務の AI 化に責任を持つか」が決まらない場面のほうが多い。FDE 型の支援を受けるにせよ、社内で進めるにせよ、先に決めるべきは Echo 役です。「AI導入」の本当の難しさで書いた「フロー管理の壁」は、FDE を呼んでも消えません。壁を越える人を社内に置いて、初めて FDE の技術が生きます。
まとめ
FDE は、Palantir が「入ってみないと分からない顧客」のために作った職種で、2026年に OpenAI・Anthropic・AWS が導入専門の部隊と会社をつくったことで、AI 導入の標準的な形になりつつあります。成果物は本番で動く仕組み、評価は合格率、関わり方は伴走。SIer やコンサルとは、渡すものと残るものが違います。
発注側として押さえるのは4つ。何が残るかを粒度まで確認する。業務とデータを見せる準備と取り扱いルールを決める。社内に判断を引き受ける Echo 役を置く。製品前提の設計と中立な設計を分ける。本家の FDE を呼べる規模でなくても、この型で支援を選び、社内の体制を組めば、同じ結果に近づけます。
「本番で動くところまで」を成果物にする AI 導入支援
はてなベースでは、AI エージェントを既存の業務フローに組み込む設計から、その前提となるデータ基盤の整備、セキュリティが気になる企業向けのオンプレミス環境での生成AI導入までを一貫して支援しています。提案書で終わらず、現場で動き、担当者が回せる状態までを一緒に作ります。「FDE 型の支援を中堅企業の規模で受けたい」「どの業務から始めるべきか見立ててほしい」といった段階から、30分の無料相談でご相談ください。