By Jay Revels, Ichizoku株式会社 CEO
本記事は、Kevin Bai氏の講演をもとに、ソフトウェアではなく成果を売るFDE（Forward Deployed Engineer）モデルの仕組みと、FDEチームを作るべき条件を解説します。
重要なポイント
- ソフトウェアではなく成果を売る転換：クライアントが買うのはライセンスではなく運用上の成果であり、その価値を現場で具体化するFDEの役割
- デプロイメントマトリクスによる判断：製品の技術的な複雑さが高く、購入者の技術的な習熟度が低い場合に限ってFDEチームを作るという基準
- 受託開発会社化の罠：プラットフォームの抽象化がないまま導入先ごとにカスタムコードを書けば、実態はITコンサルティング会社
- 立ち上げ前の2つのテスト：非対称性テストと複利プリミティブテストで、FDEの必要性と成果を製品に積み上げられるかを事前に検証
FDEプレイブック：エージェント時代に「ソフトウェア」ではなく「成果」を売る方法
2026年のAI Engineer World’s Fairにて、Kevin Bai氏がFDEモデルの仕組みについて18分間にわたって解説しました。聴衆は1,000人を超える技術系の創業者やリードエンジニアでした。
Bai氏はエンタープライズ企業や急成長中の企業で、以下の実績があります。
- Anthropic（Applied AI）：エンタープライズ企業に向けて、最先端のエージェントモデル統合と本番デプロイを推進
- Rippling：同社初のForward Deployed Engineerとして入社し、12カ月でFDE組織を1人から25人に拡大
- Palantir Technologies：元FDE。世界の主要機関の内部で、データ統合とアプリケーション構築を担当
なぜ今この講演が重要なのか
2026年、エージェントAIへの大きな移行により、ソフトウェアプラットフォームは無限にカスタマイズできるようになりました。しかし、カスタマイズの自由度が上がるほど、運用上の摩擦も増加します。そのため、エンタープライズ企業では、モデルAPIやエージェントプラットフォームをそのまま利用するだけでは、ビジネス価値を生み出すことが難しくなっています。エンジニアが直接関与し、きめ細かくサポートする必要があります。
メンタルモデルの転換：ソフトウェアではなく成果を売る
従来型のSaaS（Slack、Jira、Zoomなど）はセルフサーブ型、または導入の負担が少ない設定モデルで成り立っています。顧客側に十分な技術力があるか、製品自体が十分に直感的であるため、顧客自身がワークフローを設定できる仕組みです。
しかし、Palantirや最先端のAIプラットフォームは、これとは根本的に異なるメンタルモデルで動いています。
クライアントが買うのはソフトウェアライセンスではなく、運用上の成果
Palantirは、技術に詳しくないクライアントに極めて複雑な製品を提供しています。その抽象的な技術力を、現場で具体的に役立つ形に落とし込むのがFDEです。
これが、Palantirが他のSaaS競合企業より、高い契約額を得ている理由の一つだと考えられます。従来のエンタープライズSaaS企業のように、UIやインターフェースそのものを製品として売っているのではなく、事前に合意したビジネス成果を売っているのです。ただし、すべてのSaaS製品にFDEチームが必要なわけではありません。
デプロイメントマトリクス：FDEチームを作るべき場合、作るべきでない場合
FDEというアプローチは、あらゆるソフトウェア企業にとって有効な万能策ではありません。Bai氏は、製品の技術的な複雑さと購入者の技術的な習熟度という2つの軸に基づいて、デプロイメントマトリクスを定義しています。
技術的な複雑さが高い × 購入者の技術的な習熟度が低い：FDEゾーン（図右上）
（例：Palantir Foundry、エンタープライズ向けエージェントプラットフォーム）
購入者には十分な予算と事業規模があります。一方で、再利用・カスタマイズ可能なコンポーネントで構成された複雑なプラットフォーム上に構築するための技術力やエンジニアリングのキャパシティがありません。この場合は、FDEチームを作るべきです。
戦略上の警告：受託開発会社化の罠
プラットフォーム側の抽象化が整っていない状態でFDEを投入すれば、致命的な結果を招きます。FDEが導入先ごとにシングルテナントのカスタムコードをゼロから書いているのであれば、それはFDE機能とは呼べません。ソフトウェア企業並みの粗利率を掲げながら、実態としてはITコンサルティング会社を運営していることに他なりません。
創業者・経営陣が問うべき2つの質問
FDE機能を立ち上げる前に、経営陣は自社の製品とGTM戦略について、次の2つの基準で検証する必要があります。
1. 非対称性テスト
技術的な複雑さが高い製品を、技術的な習熟度が低い購入者に販売しているか。
Noの場合：FDEチームが不要なオーバーヘッドを生み、顧客獲得を遅らせます。
2. 複利プリミティブテスト
FDEの成果が製品のコアに積み上がるよう、再利用可能なコンポーネントを備えた基盤プラットフォームアーキテクチャを持っているか。または、現在構築しているか。
Noの場合：プロダクト組織が高コストな受託開発会社と化し、ソフトウェアの粗利率が損なわれ、保守不能な技術的負債が生じます。
3. 「AIは万能」の幻想
AIを万能の解決策として扱い、決定論的なスクリプト、エージェントによる推論、人間による意思決定を適切に切り分けない。
4. 「メンテナンス」の幻想
AIの統合を継続的な評価と改善のループではなく、一度きりのソフトウェア開発として捉える。
戦術面の要点と実行フレームワーク
1. セールスエンジニアではなく、クライアントと向き合うソフトウェアエンジニアを採用する
理想的なFDEは、ビジネス感覚とプロダクトへの直感を備えた、成果を出せるソフトウェアエンジニアです。経営幹部との対話も、本番コードベースのリファクタリングも、その日のうちにこなせる人材です。
2. FDEを終わりのないデザインパートナーシップとして捉える
FDEは一度きりのオンボーディングサービスではありません。クライアントの現場とコアR&Dをつなぐ、継続的なフィードバックループです。
3. 呼び名ではなく、中身を変える
「Solutions Architect」や「Sales Engineer」といった肩書きを「Forward Deployed Engineer」に変えるだけでは意味がありません。インセンティブ、プラットフォームのプリミティブ、エンジニアリングのオーナーシップまで変えなければ、エンタープライズにおけるレバレッジは生まれません。
4. 製品のコアとなる抽象化を先に構築する
再利用可能なコンポーネントを見つけ出し、メインリポジトリに還元することを義務付ける厳格なガイドラインなしに、FDEをクライアントの環境へ投入してはいけません。
最後に
チーム内の有望なFDE候補を見極め、実際に機能するFDEへ育成するための支援をお探しでしたら、ぜひFDE育成プログラムをご覧ください。
【FAQ】よくある質問
1. 従来のSaaSとPalantirのモデルは何が違うのですか？
従来のSaaSは、顧客自身がワークフローを設定できるセルフサーブ型、または導入の負担が少ない設定モデルです。Palantirは、FDEが抽象的な技術力を現場で役立つ形に落とし込み、事前に合意したビジネス成果を売っています。
2. すべてのSaaS製品にFDEチームは必要ですか？
必要なわけではありません。製品の技術的な複雑さが高く、購入者の技術的な習熟度が低い場合に、FDEチームを作るべきです。
3. なぜ今、エンジニアの直接的な関与が必要なのですか？
エージェントAIへの移行でソフトウェアプラットフォームは無限にカスタマイズできるようになり、自由度が上がるほど運用上の摩擦も増えるためです。エンタープライズ企業では、モデルAPIやエージェントプラットフォームをそのまま使うだけでは、ビジネス価値を生み出しにくくなっています。
4. FDEを投入する際、何に注意すべきですか？
プラットフォームの抽象化が整わないまま、導入先ごとにシングルテナントのカスタムコードをゼロから書かせないことです。そうなると、ソフトウェア企業並みの粗利率を掲げながら、実態はITコンサルティング会社を運営することになります。
5. エンジニアをFDEとして機能させるには、何を変える必要があるのですか？
肩書きを変えるだけでは意味がありません。インセンティブ、プラットフォームのプリミティブ、エンジニアリングのオーナーシップまで変えなければ、エンタープライズにおけるレバレッジは生まれません。