私たちのデプロイメント作業の 3 分の 2 は、現在、自社製品（Duet）によって自律的に行われています。
この投稿では、なぜそうなったのか、プロダクト + デプロイメントの進め方に関する私たちの哲学、そしてそれが時間とともにどう進化してきたのかについて書きます。
かつて軽視していたことが、今やデフォルトの答えになっている
「フォワードデプロイドエンジニア（FDE）」は、AI のゴートゥーマーケットにおけるほぼすべての難しい問いへの答えとなっている。デプロイがつらい？FDE を雇おう。顧客がセルフサービスできない？FDE だ。プロダクトがまだ完成していない？FDE だ。Anthropic と OpenAI はどちらも、Palantir を明確にモデルにしたエンタープライズ向けデプロイ部門を立ち上げている。そして、私が話すすべてのシード期のスタートアップに、今では FDE の求人がある。この職種の求人は、昨年で数百パーセント増加したと報じられている。
奇妙なのは、つい最近まで、これが批判されることだったという点だ。エンジニアを顧客先に派遣することは、本当のプロダクトを持っていない証拠と見なされていた。収益の質が低く、マージンは構造的に頭打ちになる、と。根底にある経済性は何も変わっていない。
FDE の鍵となるのは、彼らが成果（アウトカム）を届けることだ。これは AI の時代において素晴らしいことだ。なぜなら、企業は成果に至る道筋が分からないかもしれないが、AI が説得力のある成果を生み出すことは明らかだからだ。
同時に、この役割は使われすぎており、構造的な問題を隠すための松葉杖になるべきではない。
「FDE は苦痛を食ってプロダクトを排出する」
Palantir（私の共同創業者 @AshwinSreenivas が出身の会社だ）は、2000 年代半ばに Gotham を CIA、NSA、陸軍情報部隊に売り込みながら、この役割を広めた。そして彼らは長い間批判を受け続けた。共同創業者の一人である Joe Lonsdale は、20 年の大半において、Palantir に対する主流の見方は「本当のテクノロジー企業というより、着飾ったコンサルティング会社」というものであり、その見方は、彼らのエンジニアの多くが顧客と長時間一緒に過ごしているという事実に基づいていた、と書いている。
しかし、Palantir の CTO である Shyam Sankar には、彼が繰り返し口にしていた言葉があった。「FDE は苦痛を食ってプロダクトを排出する」。
Palantir の初期の Gotham デプロイは、非常に特注的で、ある部隊の 1 つのインテリジェンス上の問いに答えるために作られた。Palantir は、そこで見た問題をプラットフォームのプリミティブとしてコード化した。オントロジー、オブジェクトモデル、権限管理、ワークフローエンジン、来歴追跡などだ。それらのプリミティブは Foundry になった。Foundry は商業的に販売できるものになった。Apollo と AIP も同じ道をたどった。
そのどれも、まず現場でエンジニアが苦痛を食っていなければ存在しなかっただろう。その苦痛はプロダクトへのインプットであって、販売コストではなかった。
Foundry が成熟するにつれ、標準化されたデプロイによってカスタム作業の必要性は劇的に減り、粗利益は 80% 台にまで上昇し、Palantir は FDE 主導の動きからアカウントベースドセリングへとシフトした。そうした FDE の多くはコアエンジニアリングに移行した。また、顧客が単に「より良いソフトウェアを備えた Accenture」を求めている契約を断ったことでも有名だ。
FDE チームはビジネスモデルではなかった。正しいプロダクトを構築するための方法だったのだ。
なぜ一部の AI スタートアップは今まさに FDE を本当に必要としているのか
もし 2015 年に SaaS CRM を構築していたなら、ワークフローを発見する必要はなかっただろう。過去 20 年間にわたって、パイプラインとは何か、ステージとは何か、リードの引き継ぎがどのようなものかは、すでに多くの人々が考え抜いてきたからだ。
もし 2026 年に会計向けの AI エージェントを構築しているなら、確立されたワークフローは存在しない。なぜなら、文字通り誰もそんなものを使ったことがないからだ。ユーザージャーニーがどのようなものか、誰も知らない。あなたも、そして重要なことに、あなたの顧客もだ。彼らは自分が何を望むのかを伝えられない。なぜなら、彼らが望むであろうものは、まだ形になっていないからだ。
それは Palantir が始めたときと同じ状況だ。Lonsdale の捉え方では、彼らは必要性からフォワードデプロイドを採用した。強いテクノロジーを持っていたが、初期の防衛・インテリジェンス顧客が実際にどう働いているのかまったく分からなかったのだ。
だから、そう、エンジニアを送り込もう。その場に座ろう。テストが想像もしなかった形で自分のプロダクトが壊れるのを見よう。真に新しいカテゴリーにおいて、ラストマイルはデリバリーの問題ではなく、ディスカバリーの問題だ。そして、そこにいることに代わるものはない。
落とし穴は「始めること」ではない。「やめられないこと」だ。
実際のユーザージャーニーが何かを理解したら、FDE を現場から引き上げ始めるべきだ。
あなたはそうしたくないだろう。誰かが悪い決断をするからではなく、彼らを現場に置いておくほうが、どのスプリントでも楽だからだ。
FDE がいれば、プロダクトに関する厳しいトレードオフをすべて回避できる。プロダクトが何をするのか、2 つの顧客リクエストのどちらを優先するのか、設定画面の範囲をどこで区切るのかを決める必要がなくなる。自由に感じられる。誰も誰かにノーと言わなくて済む。苦しいアーキテクチャ上の決断も不要だ。顧客は喜ぶ。
そして今や、このモデルの欠点をすべて抱えつつ、ディスカバリーの恩恵はまったくない。サービス提供コストは下がらない。マージンは頭打ちのままだ。成長は採用に制約される。現場での特注の修正はすべて、あなたが下さなかったプロダクト上の決断だ。それぞれのデプロイが、次のデプロイをより簡単にすべきなのだ。
その上、Palantir が最初から獲得していたような 8 桁（数千万ドル）の取引を成立させられるスタートアップはほとんどなく、経済性を維持するのはさらに難しくなる。
もう 1 つ、混同してはいけないこと
FDE は実装（インプリメンテーション）と同じでもない。「この統合を彼らのチケットシステムに組み込んでくれ」というのは、現実に必要な仕事だ。しかしそれは、既知の仕様に対する実行であって、未知の仕様の発見ではない。この 2 つを 1 つの職種にまとめることで、企業は成長するサービス組織がプロダクト投資であると自分自身に納得させているのだ。
現在、モデルはコードを十分にうまく書けるため、2023 年に実装チームが行っていた仕事の多くは、プロダクト自身が行うことになりつつある。最終的には、ラストマイルの作業をすべてエンドツーエンドで実行できるエージェントを構築できるようになるだろう。 そのエージェントはワークフローを観察し、顧客にインタビューすることさえできる。
私たちが代わりにやったこと
@DecagonAI における私たちの具体的なケースでは、サービス主導や FDE 主導ではなく、プロダクト主導のアプローチが答えだと根本的に信じている。カスタマーサービスは大量発生し、反復可能で、分解可能だ。エンタープライズと話すとき、次の 2 つの点は常に一貫している。
- 反復スピードが鍵だ。 AI エージェントをリリースするのは一度きりのことではない。時間の経過とともに絶えず調整し、更新していく必要がある。それぞれの微調整にエンジニアリングが必要なら、スケールするには遅すぎ、コストもかかりすぎる。
- ベンダーロックインと自主性（ソブリンティ）。 SaaS に対する組織の経験を考えると、誰もベンダーにロックインされて、そのリソースに依存したいとは思わない。
初期の頃、Ashwin と私は、顧客が求めるものをただ個人的に作っていた。プロダクトが軌道に乗るにつれ、私たちは中核的なバリュープロポジションは「最高のプロダクトを持つこと」だと明確に決断した。
明確にしておくと、私たちは今でも顧客とパートナーシップを組み、エンドツーエンドで成果を届けている。 しかし、そのプロセスを通しても、私たちはビルドを所有しつつ、顧客のチームが私たちのプロダクトを使えるようにし、鍵を渡している。プロダクトが成熟するにつれ、私たちのエンジニアリングチームが行う顧客固有の作業は劇的に減った。
その決断にはトレードオフがあった。現場でその場しのぎのハックをすればもっと速い場合でも、それをしないということだ。エスカレーションを受けて、パッチではなく要件に変換するということであり、短期的には時間がかかる。
その見返り：
- デプロイメント作業の 3 分の 2 は今や Duet を通じて自律的に行われている。設定、反復、そしてこれまで人間の介入を必要としていたチューニングのロングテールもだ。
- 大きな銀行、航空会社、通信事業者などでも、最初の AOP の立ち上げには平均してわずか数日しかかからない。
やるべきことはまだたくさんあるが、私たちはその旅の途上にいる。
では、FDE をやるべきか、やらないべきか？
早い段階でフォワードデプロイドをやろう。シグナルを得よう。エンジニアを常に顧客の前に立たせよう。
そして、本当の問いを投げかけよう。その特注性は顧客の環境にあるのか、それとも自社のプロダクトの欠陥にあるのか？ラストマイルは削減できないものなのか、それともまだ作られていないだけなのか？あなたの FDE たちは何かを発見しているのか、それとも何かを吸収しているのか？そして、彼らの誰かが現場から戻ってきた前回、何がプロダクトに組み込まれたのか？
FDE を使って、プロダクトに何が必要かを明らかにしよう。FDE は苦痛を食ってプロダクトを排出する。もしあなたの FDE たちが苦痛を食って、さらに苦痛を排出しているなら、それは FDE チームではない。それはサービスビジネスだ。
