Linktier先日、現DMM AI戦略顧問 / Algomaticの大野さん（@ono_shunsuke）と、FDE（Forward Deployed Engineer）に関してXでやり取りさせていただく機会がありました。
私自身、「過去FDEの方と仕事でご一緒した経験がある」「現在サンフランシスコでAI最新動向に日々触れている」という状況ではあったものの、FDEに関しては既に多くの方々が整理してくださっていたため、自らこれまで発信はしてきませんでした。
ただある程度メディア上での議論も落ち着き、日本でも実際にFDE職の採用が増えてきたことから、私の観点・一次情報が日本企業のFDE型ビジネスにおいて少しでも参考になる部分があるなら、と思いこのタイミングで記事に残すことにしました。
これまでメディア上の議論を追い切れておらず、漏れている・ずれている観点があると思うので、気になる部分などあればぜひコメントいただけますと幸いです。
0. 結論：FDEが必要な理由
役割や詳細は後述しますが、結論としてAIエージェント時代にFDEが重要になる理由は、AIが「回答する存在」から「業務を実行する存在」へ変わりつつあるからだと思っています。
チャットボットやRAGであれば、主な役割は情報検索や回答生成でした。 もちろん、それだけでも精度や権限管理の問題はありますが、多くの場合、最終的に承認・判断し、実行するのは人間でした。
一方でAIエージェントは、社内システムを操作し、チャットを送信し、タスクを管理し、ファイルを更新するなど、業務フローを前に進める存在になります。つまり、AIエージェントは企業内における「新しいユーザ・従業員」になります。
そうなると、必要になる設計は一気に変わります。 どの情報を見てよいのか。 どの操作はAIが自動で実行してよいのか。 どこから人間承認が必要なのか。 例外時には誰にエスカレーションするのか。 実行ログをどう残すのか。 企業ごとの暗黙ルールや過去の慣習をどう扱うのか。 これは、単にモデルを賢くすれば解ける問題ではありません。
だからこそAIエージェント時代には、企業独自の業務、権限、承認プロセス、現場の実態に合わせたカスタマイズの重要性が増します。ここでいうカスタマイズは、単に画面やワークフローを少し調整することではなく、AIが安心・安全に業務を実行できるように、その企業固有のルール、慣習、権限、承認プロセスを実行可能な形に設計することです。
このような背景から、AIエージェント時代には、顧客現場に深く入り込み、業務理解と実装をつなげられるFDEの重要性が高まっているのだと思います。
1. FDEは単なる「導入支援」ではない
FDEとは「顧客や現場に深く入り込み、課題探索から実装、本番定着、評価、プロダクト反映までを担う技術職」です。Palantir、OpenAI、Anthropicなど、会社によって役割名や組織上の置き場は異なりますが、顧客現場に入り、複雑で曖昧な業務課題を実装と運用設計で本番価値に変えるという点は共通しています。
実際、OpenAIは2026年5月にOpenAI Deployment Companyを発表し、FDEが顧客組織に入り、モデルを顧客のデータ・ツール・業務プロセスに接続し、本番システムの設計・構築・テスト・デプロイを担うと説明しています。 またAnthropicのFDE求人でも、Claudeを使った本番アプリケーション構築、エンタープライズ環境での実装支援、再利用可能な実装パターンの体系化、プロダクトチームへの知見還元が責務として書かれています。
2. AIによってFDEが一気通貫で推進可能に
従来これらの一連の仕事は、顧客業務整理はコンサルタント、顧客調整・進行管理はSEやPM、実装はエンジニアという分業制で担うことが多かったものの、AIによって調査、要件定義、プログラミングの生産性が上がったことで、優秀なFDEであれば一気通貫で担うことも不可能ではなくなっています。
実際に私が昔FDEとご一緒した際にも印象的だったのは、顧客CxOへの報告、業務現場のヒアリング・理解、数多くのステークホルダーとの調整、曖昧な課題を構造化し実装方針への落とし込みを、かなりのスピード感をもってアジャイルに進めていた点でした。
チーム内のコミュニケーション負担を減らしつつ、FDE自らがすべてのフェーズの状況を深く理解した上で進められるため、顧客の現実と実装をつなぎ、本番価値に近づけやすくなるのだと感じています。
3. FDEモデルは複利が鍵
FDEを「顧客ごとにカスタマイズする人」とだけ捉えると、ただの受託開発や高単価な個別開発人材になってしまいます。FDEモデルの経済性は、案件ごとの価値創出を、再利用可能なプロダクト・テンプレート・組織知へ転換し、次案件の立ち上げを短縮できるかで決まります。このループが回るかどうかが、FDEと受託開発の分岐点になります。
各社の導入でカスタマイズが必要だった承認ルール、例外処理、権限設計、ログ要件、現場定着の失敗パターンを、毎回バラバラに実装していたら単なる個別開発になります。
一方で、それらをテンプレート、評価基盤、権限設計、承認フロー、導入方法論、プロダクト機能へ変えられれば、FDEが現場で得た知見が自社プロダクトに戻り、次の導入が速くなり、FDE自身の作業効率も上がります。
この「FDE自身が自社プロダクトを使い、その利用経験がさらにプロダクトを改善する」という複利が重要です。FDEが毎回手作業でヒアリングし、要件を整理し、評価設計を作り、権限確認を行い、レポートを作っている限り、FDEモデルは重くなります。逆に、FDE業務そのものを支援するプロダクトや社内OSがあれば、導入活動そのものがプロダクト改善のフィードバックループになります。
4. 複利による堀と人月単価からの脱却
このサイクルが回ると、いくつかの堀（Moat）が積み上がります。
① 業務ノウハウ
顧客現場に入らないと分からない例外処理、承認構造、現場の暗黙知、失敗パターンが蓄積されます。
② 実績と信頼
AIエージェントは、導入を間違えると業務リスクになります。だから顧客は、単に機能がある会社ではなく、「この会社なら自社の業務に入り、本番まで持っていける」と信頼できる会社を選びます。
③ プロダクト
FDEが現場で見つけた課題がプロダクトに反映され、導入のたびに権限設計、評価基盤、ログ設計、承認フロー、テンプレートが洗練されるため、後発企業が表面的に同じUIを作っても、本番運用・機能の質では差が出ます。
④ スイッチングコスト
AIエージェントがその会社固有の業務ルール、権限、承認、例外処理、ログ設計に深く組み込まれると、プロダクトは単なるツールではなく、業務運用そのものに近づきます。置き換えるには、データ移行だけでなく、業務プロセス、教育、権限設計、承認設計、監査設計を再構築する必要が出てきます。
特に重要なのは、これらの堀が積み上がると、顧客から見た比較軸が「実装工数」ではなく「業務成果」「導入リスクの低さ」「本番定着までの速さ」に変わることです。単なる受託開発であれば人月単価や開発費の比較になりやすいですが、FDEモデルがうまく回ると、顧客は“安く作れる業務委託会社”ではなく、“自社の複雑な業務に入り込み、安全に成果まで持っていける会社”を選ぶようになります。
こうなると、人月単価で「誰が安く作れるか」を競う必要が薄れ、結果として価値・成果ベースの価格設計がしやすくなり、利益率も高めやすくなるはずです。
5. FDEはビジネスモデル設計が肝
上述の通り、FDEはAIエージェント時代において重要な役割を果たすはずですが、その効果を最大化するためには以下のようなビジネスモデル設計が重要だと感じています。
① FDEが学んだことをプロダクトへ確実に戻す仕組み
単に社内チャットで共有する、メモとして社内に残すような形ではなく、社内で明確なルールと方法を定義し、FDEが現場で学んだ現場知見を、再活用可能な形で社内ノウハウ蓄積、テンプレート化、プロダクト改善に実際につなげる必要があります。
② そもそもカスタマイズを前提にしたプロダクト
カスタマイズすることを想定していないプロダクトを、無理に顧客業務に合わせようとすると、FDEの負担も大きく、真に価値のあるカスタマイズは難しくなります。
③ FDE業務そのものを支援・強化できるプロダクト
FDEの業務範囲が多岐にわたる中、FDEを疲弊させず競合を上回る成果を上げるためには、FDE業務をより効率化し、より高度化するAIプロダクトである必要があります。
④ 導入件数によらない自社KPI設計
上述の設計が重要になるため、プロダクト導入の案件数だけでなく、「実際に顧客に明確な成果が出ているか」、「FDEの業務効率が日々上がっているか」、「現場知見が次の案件にどれだけ再利用されているか」などを注視し、中長期で粗利とプロダクト競争力を維持できる状態かを測る必要があります。
6. FDEに求められるAgent Ready / Harness設計力
AIエージェント時代のFDEは、従来の導入支援よりさらに難しくなると思っています。なぜなら、相手にするのが「人間が使うプロダクト」だけではなく、「AIが実行する業務プロセス」になるからです。
これまでは、人間が画面を見て、判断し、必要な操作を行う前提で業務システムやSaaSが設計されてきました。しかしAIエージェントが業務実行を担うようになると、プロダクト側も「人間だけでなくAIも利用者になる」前提で設計する必要があります。つまり、AIエージェントがどの情報を参照し、どの操作を実行でき、どこで人間承認を求め、どのログを残し、失敗時にどう戻すのかまで含めて設計する必要があります。
この意味で、FDEにはAgent Ready、Harness Engineeringのような考え方が求められるようになると思っています。
Agent Readyなプロダクト設計とは、AIエージェントが安全に業務を実行できるように、エージェント専用の権限、ID、実行可能な操作範囲、人間承認が必要な操作、実行ログ、失敗時のロールバック、利用可能なコンテキスト、メモリと履歴の管理などを、プロダクトや業務フローの中に組み込むことです。
また、いわゆるHarness Engineeringの考え方も重要になると思います。Harness Engineeringとは、AIエージェントがより安全・正確に動くように、実行前のガイド、実行後の検証、フィードバックループを設計する考え方に近いです。
つまりAIエージェント時代のFDEは、単に「顧客要望を聞いて作る人」ではなく、顧客の業務を理解し、その企業固有のルールや承認プロセスを把握し、それをAIが安全に実行できる形へ落とし込み、さらにプロダクト側の設計にも反映する必要があります。
そしてここまでを踏まえると、企業におけるFDEモデルの最大のボトルネックは人材獲得だと考えます。
FDEには、ビジネスと技術の両方をまたぐ力が必要です。 現場の違和感を拾う力、曖昧な課題を構造化する力、プロトタイプを作る力、本番運用に耐える設計をする力、顧客と会話する力、そして「これは個別要件なのか、プロダクトに戻すべき共通パターンなのか」を見極める力が必要になります。 AIエージェント時代には、ビジネスと技術の両面で深く考えられるFDE人材の価値と採用難易度は、より高くなるはずです。
7. 導入される側の日本企業にとってのFDEモデルの価値
日本企業では、AI導入がPoCで止まりやすい、承認プロセスが複雑、部門横断の調整が難しい、現場業務が暗黙知化している、といった課題が多くあると言われています。ただし、カスタマイズ前提ではないSaaSだけでは入り込みづらかった複雑な現場におけるこの課題も、FDEモデルが主流になれば解決できる余地が出てきたとも捉えられると思っています。
また、コーディングエージェントによって「ソフトウェアを作る」ハードルが下がっていく中、今後重要になるのは、単に何でも内製することではなく、「自社にとって何を作り、何を作らないのが最適なのか」を判断することだと思います。その判断には、自社独自の業務ルール、現場ノウハウ、承認プロセス、判断基準を把握し、再利用可能な形にしていくことが重要です。FDEモデルは、この現場知をデータ化・構造化し、AIエージェントが活用できる形に近づけるうえでも有効だと考えています。
AIエージェントは、単に標準プロダクトを導入すればすぐに本番業務で使えるものではありません。企業ごとの業務、権限、承認プロセス、現場の慣習に深く入り込み、AIが安全に実行できる形へ設計する必要があります。特に日本企業のように、業務プロセスや意思決定が複雑で、現場知が暗黙知化している環境では、この「現場に入り、業務を理解し、実装し、本番化する」役割の重要性は大きいと感じています。
私自身、自ら代表を務めるLinktierでこういった観点を意識して日々事業開発を進めています。 日本内外の皆さんと会話し、少しでも意義のある事業を作っていければと思っているので、気になる点や異なる見方などがあれば、ぜひコメントいただけますと幸いです。