FDEモデルとは、ソフトウェア企業が自社のエンジニアを顧客の現場に送り込み、顧客ごとの課題を解きながら、そこで得た知見や機能を自社の製品に戻していく事業モデルのことだ。発祥はパランティア（Palantir Technologies）で、2025年以降はOpenAIやAnthropicといったAI企業、さらに日本の大手ITベンダーやコンサルティング会社にも広がっている。
FDE（Forward Deployed Engineer）という職種そのものについては「FDEとは？Forward Deployed Engineerの意味と仕事内容」で整理した。ここでは、職種ではなく「事業の作り方」としてのFDEを扱う。
FDEモデルは、SaaSとも受託開発とも違う
ソフトウェアの売り方は、大きく3つに分けられる。
| SaaS（セルフサーブ型） | 受託開発・コンサル | FDEモデル | |
|---|---|---|---|
| 売るもの | 製品の利用権 | 人の時間と成果物 | 製品と、それを現場で使える状態にする仕事 |
| 顧客の現場に入る人 | 基本的にいない | 開発者・コンサルタント | 製品を作る会社のエンジニア |
| 顧客ごとの工夫が残る場所 | 残らない（顧客が自分で設定する） | その顧客の成果物 | 製品（次の顧客でも使える） |
| 収益の中心 | 月額・年額の利用料 | 人月・プロジェクト単価 | 製品の利用料（導入の人件費は先行投資） |
一番下の行と、その一つ上の行が本質だ。受託開発でも顧客の現場には入る。違いは、現場で作ったものがどこに溜まるかにある。受託開発では成果物がその顧客のもとに残り、次の顧客ではまた一から作る。FDEモデルでは、現場で作ったものを汎用化して製品に取り込み、次の顧客では最初から使える状態にする。人の仕事が、製品という資産に変わっていく。
パランティアはなぜFDEを作ったのか
パランティアのエンジニアには、大きく「Dev」と「Delta」の2つの職種がある。同社の公式ブログによれば、Devは「一つの機能を、多くの顧客に」届け、Deltaは「一つの顧客に、多くの機能を」届ける（Palantir Blog）。このDeltaの正式な職名がForward Deployed Software Engineer（FDSE）、つまりFDEだ。
The Pragmatic Engineerの取材によれば、この職種は2010年代前半に生まれ、2016年ごろまでは社内でFDEの人数が通常のソフトウェアエンジニアを上回っていたとされる（The Pragmatic Engineer）。同じ記事は、大企業で物事を進める難しさは技術よりも組織の壁にある、という趣旨の見方も紹介している。巨大な組織の中で、データの持ち主を探し、権限を取り、関係者を動かしながらシステムをつなぐ。それを顧客任せにせず、自社のエンジニアが引き受けたのがFDEの始まりだった。
パランティアにはもう一つ、「Echo」と呼ばれるDeployment Strategistの職種がある（Palantir Blog）。Echoがプロダクトマネジメント寄りの役割を担い、Deltaが技術寄りの役割を担う。事業側と技術側が組になって現場に入る、という形がFDEモデルの原型になっている。
FDEモデルの仕組み：現場の仕事を製品に戻す
FDEモデルの価値は、次の循環にある。
- FDEが顧客の現場に入り、具体的な業務課題を製品で解く
- 製品に足りない機能があれば、FDE自身が作り、製品本体にも手を入れる
- 現場で作ったもののうち、他の顧客にも使えるものを汎用化して製品に取り込む
- 次の顧客では、それが最初から使える。導入が速くなり、FDEはより難しい課題に時間を使える
The Pragmatic Engineerは、パランティアのFDEが製品の制約にぶつかったとき、新しいデータモデルを設定したり、製品の安定性を改善したり、製品本体に修正をコミットしたりすると伝えている。同じ記事では、コンサルタントとの違いを「一回きりの提言ではなく、長く顧客と働き、自社製品にも貢献すること」と説明している。
この循環が回っているかどうかが、FDEモデルと、FDEを名乗る受託開発を分ける。現場での工夫が製品に戻らず、顧客ごとのカスタマイズとして積み上がるだけなら、それは人月ビジネスと変わらない。
なぜ今、FDEモデルが広がっているのか
AIエージェントは「設定して終わり」にならない
生成AIやAIエージェントは、顧客ごとの業務、データ、例外処理に合わせて調整しなければ成果が出ない。しかも同じ入力にも毎回少し違う答えを返すため、導入後も評価と改善が続く。セルフサーブのSaaSのように「契約したら顧客が自分で設定する」では回らない領域が一気に広がった。
米ベンチャーキャピタルのa16zは2025年6月、この状況を「サービス主導の成長（services-led growth）」と呼び、AIスタートアップはFDEを置いて顧客の業務に深く入り込むべきだと論じた（a16z）。AIを買う企業は、スマートフォンを初めて手にした人と同じで、使いたいがセットアップを手伝ってもらう必要がある、というたとえを使っている。
利益率を下げてでも、堀を取りに行く
人手をかければ、当然、粗利は下がる。それでもFDEモデルを選ぶ理由について、a16zは既存の大手SaaSの例を挙げている。ServiceNowの粗利は上場時に63.2%だったが2024年には79%に、Workdayは上場時の54.1%から75%に上がった。顧客の業務とデータの入口を押さえれば、初期の低い利益率は後から回収できる、という主張だ。
AIを作る会社自身が、FDEの会社を作り始めた
OpenAIは2025年初めに2人でFDEチームを立ち上げ、同年8月には東京を含む8都市で10人超の体制になったとされる（The Pragmatic Engineer）。2026年5月にはOpenAI Deployment Companyを設立し、Tomoroの買収で約150人のFDEとDeployment Specialistを抱えた（OpenAI）。Anthropicも同じ5月に企業向けAIサービス会社の設立を発表し、7月に「Ode with Anthropic」として始動している（Anthropic）。
日本でも、富士通が2026年9月にパランティアのGlobal FDE Partnerになり（PR TIMES）、アクセンチュアは2026年3月、Microsoftと組んだFDEの専門組織（プラクティス）を数千人規模で立ち上げると発表した（アクセンチュア）。日経クロステックは富士通のFDEを「IT部門より事業部門、人月より利用料」と見出しで伝えている。人月で稼いできたSIerが、FDEモデルで収益の形そのものを変えようとしている。
FDEモデルの弱点
a16zも、この手法の落とし穴をはっきり書いている。人手に頼る分だけ規模を広げにくいこと、粗利の低さが「製品が差別化できていない」サインである場合もあること、主体的に動ける人材を採用しなければならないこと、そして顧客の選び方、インセンティブの設計、導入作業の自動化が成否を分けることだ。
現場で支援する立場から付け加えると、私は次の3つが特に効くと考えている。
- 質が人に依存する。同じ製品でも、入るFDEによって成果が大きく変わる
- 顧客に深く入るほど、顧客ごとの特殊対応が増え、製品に戻せないものが積み上がる
- 終わり方を決めないと、いつまでも現場から抜けられない。顧客の自走までを最初に設計しておく必要がある
FDEモデルは、現場に人を入れればうまくいく魔法ではない。現場の仕事を型にして戻し続ける規律があって、初めて成り立つ。
日本企業がFDEモデルから学べること
日本では「FDE」が、AI製品を持つ会社の職種としても、SIerやコンサルティング会社の新しい支援形態としても使われ始めている。立場によって、FDEモデルから取り入れるべきものは違う。
| 立場 | 取り入れるべきもの |
|---|---|
| AIプロダクトを持つスタートアップ | 導入をFDEが担い、現場の工夫を製品に戻す循環を作る。LayerXやログラスがFDE職を設けたのはこの形 |
| SIer・コンサルティング会社 | 人月ではなく、成果や利用料で価値を測る。現場の知見を再利用できる型として社内に溜める |
| AIを導入する事業会社 | 外部のFDEに任せきりにせず、社内にも同じ役割を担える人を育てる。いずれ自社で回せる状態をゴールにする |
私たちFDE Consultingは、自社製品を売る立場ではなく、顧客の課題から入る支援会社だ。それでもFDEモデルの核心である「現場で解いて、型にして、手放す」という規律は、支援の進め方そのものに取り入れている。FDEと似た職種との違いは「FDEとSESの違いとは？SIer・コンサル・データサイエンティストと比較」に、FDEが経営にもたらす変化は「FDE 2.0——AI実装者から、企業変革の現場責任者へ」にまとめている。