
はじめに:AIは、売って終わりではない
これまでのソフトウェア・ビジネスは、ある程度完成したプロダクトを売り、導入を支援し、カスタマーサクセスが利用拡大を促す、という順序で回っていた。プロダクトは契約の時点でほぼ出来上がっており、あとは「どれだけ広く使ってもらうか」の勝負だった。
Enterprise AI では、この順序が崩れる。顧客ごとにデータの持ち方、権限設計、業務フロー、例外処理、リスク許容度がまったく違う。生成AIは汎用的な能力を持つが、その能力が特定企業の現場で成果に変わるかどうかは、契約の時点ではまだ決まっていない。つまり、価値は売った時点では完成しておらず、導入したあとに、現場で作られる。
これまでの記事では、生成AI企業の価値はモデルそのものではなく、非公開データ・業務フロー・実装力といった「業務への埋め込み」に宿ること、そしてその価値は ARR の大きさではなく「剥がれにくさ」として読むべきことを論じた。便宜的に、その剥がれにくい収益を Embedded ARR と呼んだ。本稿で考えたいのは、その剥がれにくい収益を、誰が、どの組織能力によって作るのか、である。
近年その答えとして注目されているのが、Forward Deployed Engineer(FDE、フォワード・デプロイド・エンジニア) という職能である。FDEとは、ひとことで言えば、顧客の現場に入り込み、業務の理解・データの接続・実装・そしてプロダクトへの還流までを担うエンジニア職能のことだ。ただし先に結論を言えば、本稿は「FDEを持てば勝てる」という話をしない。FDEは諸刃であり、うまく設計できた会社だけが、それを剥がれにくい収益へと変えられる。
1. なぜ、SaaSの組織モデルでは足りないのか
伝統的なSaaS企業の組織は、おおむね機能ごとに分かれている。プロダクトを作るチーム、売るチーム(営業)、導入後の定着を担うチーム(カスタマーサクセス)、そして基盤を支えるエンジニアリング。それぞれが役割を持ち、顧客はこの分業のあいだを、バトンを渡されるように進んでいく。
この構造は、完成したプロダクトを繰り返し届けるには効率的だ。だが Enterprise AI では、顧客課題の探索、データの接続、プロンプトやエージェントの設計、業務そのものの再設計、セキュリティ、運用への定着——これらが分離しにくい。どこまでが「プロダクト」で、どこからが「導入作業」なのかの境界が曖昧になる。エージェントを本番業務に乗せるには、その顧客の業務を深く理解した人間が、現場でデータとワークフローに手を入れる必要があるからだ。
ここで、「プロダクトを作る人」と「顧客に届ける人」を分ける前提そのものが崩れはじめる。作りながら届け、届けながら作る。この境界の溶解こそが、FDEという職能が生まれた背景である。
なお、これは「分業を全廃すべきだ」という話ではない。組織論の主流は、いまも分業を残したまま部門間の連携を設計し直す方向にある。ここで言いたいのは、AIの実装局面では、作る側と届ける側が同じ場所に立たざるをえない場面が増える、という傾向である。
2. FDEとは何か——導入支援ではなく、価値を発見する職能
FDEという職能を最初に確立したのは、Palantir だとされる。同社は社内でこの役割を “Delta” と呼び、エンジニアを顧客の現場に埋め込んで、自社プラットフォーム上で最も難しい課題を解かせてきた。Palantir 自身の説明が、この職能の本質を端的に表している。伝統的なソフトウェアエンジニアが「一つの機能を、多数の顧客に」届けるのに対し、FDEは「一人の顧客に、多数の機能を」作り込む。
だから、FDEは受託開発ではないし、カスタマーサクセスやプリセールスとも違う。よく引かれる対比を借りれば、コンサルタントは契約の下流で、決められた要件に応える。FDEはロードマップの上流に立ち、顧客の現場で何が本当に必要なのかを発見し、それを実装し、使われ方を観察して、その学びをコア・プロダクトに戻す。この「製品への還流」があるかどうかが、単なる高級な実装請負とFDEを分ける決定的な違いだとされる。
そしていま起きているのは、この職能が Palantir という一社の特殊解ではなくなりつつある、という現象だ。2026年に入り、大手プラットフォーマーが相次いでこのモデルを採り始めた。AWSは10億ドル規模の専任組織として、OpenAIは別会社として、Databricksは新組織として、AnthropicやGoogle Cloudは職種採用として——濃淡は異なるものの、各社が実装機能をソフトウェア・ビジネスの中心に据え始めている。各社が互いをどこまで意識したのかを公表資料から因果として読み取ることはできないが、実装を収益の中心に据え直す動きが同時多発的に起きていること自体は、確かな事実である。
なぜ、これほどの資本と人材が「売ったあと」に注がれるのか。それは、そこにこそ収益の質を決めるものがあるからだ。独立系のリサーチノート Second Order Labs は、この点を挑発的にこう言い表している——AI契約からフォワード・デプロイド・エンジニアを引き剥がすと、その ARR は緩やかに縮むのではなく、蒸発する、と。やや誇張を含んだ比喩ではあるが、この一文は本質を突いている。裏を返せば、FDEこそが、剥がれにくい収益を作っている、ということだ。

3. FDEが作るもの——Experimental ARR を Embedded ARR に変える
前稿で、AI企業の ARR には、実験的で剥がれやすい収益(Experimental)と、業務に埋め込まれて残る収益(Embedded)が混じり始めた、と書いた。FDEがやっているのは、まさにこの前者を後者に変える作業である。三つの側面から見ると分かりやすい。
第一に、持続性。FDEは、一度きりの実証実験(PoC)の予算でしかなかった支出を、毎年の運用予算へと移す。話題で導入されただけのツールは半年で消えるが、現場の業務に組み込まれたものは、翌年の予算にあらかじめ織り込まれる。
第二に、拡張。最初は一部署・一用途で始まった導入を、FDEは隣の部署、別のワークフローへと広げる。顧客の中で利用が面的に広がれば、その収益は簡単には剥がれない。
第三に、モデル代替への耐性。基盤モデルが乗り換えられ、推論コストが下がっても、顧客の業務データ・運用ノウハウ・意思決定フローとの接点が手元に残れば、収益は残る。前稿で「価値はモデルではなく業務への埋め込みに宿る」と書いたが、その埋め込みを実際に手で作っているのがFDEだ、と言い換えてもいい。
興味深いのは、この見方が、実装現場の観察からも裏づけられていることだ。SaaSの成長分析で知られる Kyle Poyar(Growth Unhinged)と ChartMogul が約3,500社の解約データを分析した調査は、安く簡単に買えるAI(月額数十ドル)ほど1年で大半の収益が失われる一方、月額数百ドル以上の関係はSaaS並みに残る、と示していた。そのうえで Poyar は、AIが原理的にできることと、顧客が現場で実際に得られる成果とのあいだのギャップを、実装の伴走によって埋めることが、解約への有効な備えになる、と論じている。そして、その伴走の担い手として名指しされるのが、FDEである。
4. ただし、FDEには三つの罠がある
ここまでを読むと、FDEは万能薬のように見えるかもしれない。だが実際には、同じ職能が企業を逆方向へ——スケールしない低粗利のビジネスへ——引きずり込む力も持っている。本稿がFDEを礼賛しない理由は、ここにある。罠は主に三つある。
罠①:受託化リスク。 顧客ごとに個別対応を重ねすぎると、その会社はソフトウェア企業ではなく、実質的にシステムインテグレーター(SI)や受託開発の会社になる。前節で引いた「ARRが蒸発する」という指摘には、続きがある。もし収益の大半が、サブスクリプションの形をした個別実装の労働で成り立っているなら、それは「サブスクに見えるコンサルティング」ではないか、という問いだ。診断は意外に単純で、成長するにつれて実装労働のコストが収益に占める比率が上がっていくなら、その会社はソフトウェアではなくコンサルティングをスケールさせている。
罠②:粗利率リスク。 高単価のエンジニアを顧客に張り付ければ、当然コストは重くなる。実際、AI企業の粗利率は推論コストの影響もあって50〜60%程度にとどまり、従来のSaaSの60〜80%超という水準には届かない、という指摘は根強い(この推論コストの話は前稿でも触れた)。FDEの人件費は、その上にさらに乗る。
だが——ここが本稿の核心だが——この罠②は、無条件には成り立たない。FDEモデルの原型である Palantir は、FDEを大量に抱えながら、粗利率80%超を維持し、直近の四半期では調整後の営業利益率が6割に達し、市場からは極めて高い評価倍率を与えられている。実装比率が高い会社が、必ずしも低粗利・低評価に沈むわけではないのだ。
罠③:プロダクト化失敗リスク。 そして、この罠②を分ける鍵が、罠③にある。現場で得た知見が、テンプレートや共通モジュール、業界別のパターンとしてプロダクトに戻らなければ、会社はスケールしない。調査会社の Constellation Research は、FDEが「不完全なツールや不安定なプラットフォームを覆い隠す“人間のミドルウェア”」になりかねないと警告し、それが単なる高級な統合作業に留まれば、いずれ役割そのものが失敗する、と指摘している。a16z も、FDEを独立したサービス部門に切り離すと、現場の学びが製品に還流しなくなり、会社は純粋なサービス業へ漂流する、と注意を促す。ここから、一つの診断基準が導ける——プロダクトの成熟と、人手による関与のギャップが時間とともに広がっていなければ、その会社は事実上サービス企業になっている、ということだ。
つまり三つの罠は独立していない。プロダクト化に失敗すれば(罠③)、粗利は下がり続け(罠②)、会社は受託業へ漂流する(罠①)。逆に、実装の知見をプロダクトに戻し続けられれば、Palantir のように、実装企業でありながら高い粗利を保つこともできる。
なお、念のため付言しておくと、「AIエージェントが実装を自動化すれば、そもそもFDEのような人間は要らなくなる」という見方もある。だが現時点では、FDE職の求人はむしろ急増しており、実装できる人材こそが普及の律速要因になっている、という逆向きの観察のほうが優勢だ。実装の自動化が進む余地は認めつつも、「だから不要になる」と断じるのは、いまのところ早い。
5. 分かれ目は、FDEを学習ループに変えられるか
では、高粗利の実装企業と、低粗利のSI企業を分けるものは何か。それは、FDEを持っているかどうかではない。持ったFDEを、個別実装を再利用可能な資産に戻し続ける学習ループに組み込めているかどうか、である。ここで言う高粗利の実装企業とは、実装を人手で積み上げる会社ではない。実装を通じて、次の顧客では人手を減らせる会社のことだ。
この学習ループは、抽象論ではない。FDEモデルの普及を分析した a16z は、成功している組織にはいくつかの明確な制約が課されている、と観察している。たとえば、導入を無限に続けず、「90日で本番に乗せる」といった期限を切ること。四半期ごとに、その場限りで書いたコードを、再利用できる設定やテンプレートに畳み直すことを目標に据えること。そして、個々の実装を、小さく再利用可能な部品(データモデル、権限設計、ワークフロー・エンジンといった基本要素)の組み合わせとして作ること。Palantir が自らのモデルを「砂利道を舗装路に変えていく作業」と表現したのも、同じ発想だ。最初の顧客では手作業だったものが、次の顧客ではプロダクトの機能になり、その次ではもっと速くなる。実際、同社が上場時に開示した資料でも、経験を重ねるほど一つの顧客を立ち上げるのに必要なエンジニアの手間が減っていったことが示されている——実装がプロダクトに吸収されていく過程の、財務上の痕跡である。
管理指標も変わる。個別案件の粗利だけを見ていると、この学習ループは回らない。見るべきは、その実装から生まれた知見が、次の顧客でどれだけ再利用されたか——将来の再利用率のほうである。突き詰めれば、FDEを正しく設計した会社が売っているのは「人月」ではなく、「再現可能な業務パターン」だ。人を張り付けて売上を立てるのではなく、張り付けた人が持ち帰った学びを、次の売上の原価を下げる資産に変えている。
この違いは、外からは見えにくい。同じ「FDEを100人抱える会社」でも、片方はプロダクトが実装のたびに強くなり、もう片方は実装のたびに保守しきれない個別対応が積み上がっていく。前者は時間とともに実装が軽くなり、後者は重くなる。数年後に、片方は高粗利のソフトウェア企業として、もう片方は低粗利の受託企業として評価される。分かれ目は、最初から組織の設計に埋め込まれている。

おわりに:AI企業は、SaaS企業か、実装企業か
生成AIの時代に、企業の価値がどこに宿り(記事一本目)、それをどう測り(記事二本目)、そして誰がどう作るのか(本稿)——という三つの問いを、ここまでたどってきた。三つを貫くのは、価値がプロダクト単体から、実装・横展開・収益化を担う組織能力へと移りつつある、という一つの構造である。
だからこそ、AI企業を「SaaS企業か、実装企業か」という古い二分法で捉えるのは、もう適切ではないのかもしれない。剥がれにくい収益を作れる会社は、実装企業の泥臭さと、ソフトウェア企業のスケール経済を、同じ組織の中で両立させている。その両立を可能にするのが、FDEを学習ループに変える設計であり、それができない会社は、実装の重さだけを抱えてSI業へと沈んでいく。
FDEは、AI時代の魔法の杖ではない。だが、正しく設計できる会社にとっては、剥がれにくい収益を作るための、いまのところ最も現実的な組織能力である。「価値は売ったあとに作られる」という言葉は、裏を返せば、売ったあとに価値を作れる組織を持たない会社は、どれだけ優れたモデルを持っていても、その価値を自分の収益として留めておけない、ということでもある。
この視点は、AIを売る側や投資する側だけのものではない。AIを買う側から見れば、問うべきことは「FDEがいるか」ではない。そのFDEが、自社向けの個別対応を積み上げるだけなのか、それとも自社の業務理解をプロダクトの改善に戻してくれるのか、である。導入支援の人数ではなく、導入後にそのプロダクトがどれだけ速く賢くなっていくかを見るべきだ。前者であれば、あなたは高い実装費を払い続ける顧客のままだが、後者であれば、あなたの業務知見がベンダーのプロダクトを鍛え、巡り巡って自社の運用も軽くなっていく。
残る問いは、では、どの業務・どの業界でこの実装深度が最も効くのか、である。すべての領域でFDEが同じ重みを持つわけではないだろう。それは、次に考えたいテーマである。
References
- Palantir Technologies. A Day in the Life of a Palantir Forward Deployed Software Engineer(FDSE の定義・”one customer, many capabilities”). https://blog.palantir.com/a-day-in-the-life-of-a-palantir-forward-deployed-software-engineer-45ef2de257b1
- Gergely Orosz (The Pragmatic Engineer). (2025). Forward Deployed Engineers(起源・Palantir “Delta”・コンサル/SAとの差異). https://newsletter.pragmaticengineer.com/p/forward-deployed-engineers
- Andreessen Horowitz(Joe Schmidt). (2025). Trading Margin for Moat: Services-Led Growth(FDEの普及論・margin と moat のトレードオフ・サービス隔離のリスク). https://a16z.com/services-led-growth/
- Andreessen Horowitz(Marc Andrusko). (2026). The Palantirization of Everything(学習ループの成功条件=time-box・template化・再利用プリミティブ). https://a16z.com/the-palantirization-of-everything/
- Andreessen Horowitz(Martin Casado & Matt Bornstein). (2020). The New Business of AI(AI企業の粗利は従来SaaSより薄いという分析=粗利50-60% vs 60-80%+ の出典). https://a16z.com/the-new-business-of-ai-and-how-its-different-from-traditional-software/
- Kyle Poyar (Growth Unhinged) & ChartMogul. (2025). The AI churn wave(解約データ・課金前に本番で動かすことが最良のchurn防止という提言). https://www.growthunhinged.com/p/the-ai-churn-wave
- Second Order Labs. (2026). Probabilistic COGS: Why AI ARR Is Disguised Consulting(”ARRが蒸発する”の表現・独立系の分析ノート). https://secondorderlabs.com/articles/entrepreneurship/why-ai-startups-are-quietly-becoming-services-businesses/
- Constellation Research(Larry Dignan). (2026). Forward deployed engineers: The promise, peril in AI deployments(”人間のミドルウェア”・高級インテグレーター化のリスク). https://www.constellationr.com/insights/news/forward-deployed-engineers-promise-peril-ai-deployments
- Amazon (AWS). (2026). AWS to invest $1 billion in forward deployed AI engineers. https://www.aboutamazon.com/news/aws/aws-1-billion-forward-deployed-ai-engineers
- OpenAI. (2026). The OpenAI Deployment Company. https://openai.com/index/openai-launches-the-deployment-company/
- Databricks. (2026). Forward Deployed Engineering: Delivering Business Outcomes from Data and AI. https://www.databricks.com/blog/forward-deployed-engineering-delivering-business-outcomes-ai
- Palantir Technologies. (2020). Form S-1(デプロイ時間の短縮=実装の製品吸収の記述). https://www.sec.gov/Archives/edgar/data/0001321655/000119312520230013/d904406ds1.htm
なお本稿は、公開資料・各社の発表・VCや実務家の分析・関連報道をもとに、Enterprise AI 企業の組織能力について筆者なりの補助線を整理したものである。特定企業の非公開情報に基づくものではなく、すべて独立した一般的な構造分析である。財務数値や各社の動向は公表時点のものであり、その後の変動や前提の違いは反映していない。
コメントを残す