以前の記事では、AI時代の新しい職種として「FDE（Forward Deployed Engineer）」を取り上げました。
FDEは、顧客の現場に入り込み、業務課題を理解し、技術実装まで踏み込んで価値を出していく役割です。単なる導入支援でも、受託開発でも、カスタマーサクセスでもありません。顧客の現場とプロダクトをつなぎ、そこで得た学びを自社プロダクトの進化に戻していく点に、本質的な強さがあります。
ただ、最近改めて考えているのは、FDEという概念は重要である一方で、日本の多くのSaaS企業にとって、そのままの形では広がりにくいのではないかということです。
Palantirのような巨大プラットフォーマーや、AI領域のトップ企業を前提にすると、顧客ごとに優秀なエンジニアを深く配置するモデルは成立しやすいかもしれません。しかし、一般的なSaaS企業にとって、いきなり専任の人材を顧客現場に張り付けるのはかなり重い選択です。
日本のSaaSにとって、FDEは少し重い
FDEの考え方そのものは、非常に合理的です。
SaaSは「機能を提供して終わり」では価値が出ません。顧客の業務フローに入り、現場の使い方に合わせて設定し、社内の運用に定着して初めて成果につながります。
一方で、現実には次のような制約があります。
- 顧客ごとに専任人材を置くほど単価が高くない
- エンジニアをCS的な現場対応に出し続ける余裕がない
- 顧客側も、外部人材が深く常駐することに慣れていない
- 個別対応が増えるほど、プロダクトの標準化と衝突しやすい
つまり、FDE的な動きは必要なのに、FDEを「人の職種」としてそのまま導入するには重い。このギャップが、日本のSaaS企業にはかなり大きいように感じます。
それでも、顧客ごとの細かい運用課題は確実に存在する
ただし、FDEを置けないからといって、顧客現場の課題が消えるわけではありません。
むしろSaaSの導入後には、細かい相談が大量に発生します。
- この画面で何を設定すればよいのか
- この権限設定はどう変えればよいのか
- このレポートを顧客向けに見せるにはどうすればよいのか
- 自社の運用に合わせて、少しだけUIを変えられないか
- 毎回同じ操作をしているので、自動化できないか
- この要望は機能改善として検討してもらえるのか
こうした依頼は、一つひとつを見ると小さいものです。しかし、顧客の利用体験を左右するのは、まさにこの小さな詰まりです。
多くのSaaSでは、ここをCSが拾い、プロダクトチームに伝え、必要に応じて開発要望に変換します。ただ、この流れはどうしても時間がかかります。情報も途中で薄まりやすく、顧客が本当に困っていた文脈がプロダクト改善に届く前に失われることもあります。
FDEはまず「人」ではなく、Slack上のAIエージェントとして入る
そこで自然に見えてくるのが、FDEをいきなり人として配置するのではなく、まずSlack上のAIエージェントとして顧客接点に置くという形です。
顧客のSlackに、SaaS提供企業のFDE AIエージェントを招待します。ユーザーは、普段の業務の流れの中で、そのエージェントに相談できます。
- 「この設定を変更しておいて」
- 「この条件で一覧を作って」
- 「この顧客向けに簡単な画面を作れますか」
- 「先月と同じレポートを出して」
- 「この操作が毎回面倒なので、改善できますか」
AIエージェントは、単にFAQを返すだけではありません。SaaS本体のAPIや管理画面と接続されていれば、許可された範囲で操作を代行できます。必要に応じて設定を変更し、簡易的なUIを生成し、実行ログを残し、人間のCSやPdMにエスカレーションすることもできます。
これは、よくあるCSチャットボットとは少し違います。
チャットボットが「問い合わせに答える存在」だとすると、FDE AIエージェントは顧客の現場とSaaSプロダクトの間に立ち、実際の運用を前に進める接点です。
FDE AIエージェントが担う6つの役割
具体的には、次のような役割が考えられます。
1. CS的な一次対応
まずは、使い方の質問や設定方法の案内です。ヘルプページを検索して回答するだけでなく、顧客の契約プラン、権限、利用状況、過去の問い合わせを踏まえて返答できれば、体験はかなり変わります。
2. SaaS本体の操作代行
顧客が迷いやすい設定変更や、繰り返し発生する管理作業を代行します。もちろん、承認フローや権限管理は必要です。重要なのは、ユーザーが画面を探し回らなくても、業務上の言葉で依頼できることです。
3. 設定やカスタマイズ
SaaSの価値は、初期設定と運用設定に大きく左右されます。FDE AIエージェントが顧客の業務を聞き取りながら、テンプレート、権限、通知、入力項目、レポート条件などを調整できれば、導入後の立ち上がりは早くなります。
4. 顧客向けの簡易UI構築
AIエージェントが、特定の目的に合わせた簡易画面や入力フォームを作ることも考えられます。すべてを本体機能にする必要はありません。個別顧客の運用に必要な小さなUIを、薄く、速く作れるだけでも価値があります。
5. 依頼や詰まりポイントの蓄積
ユーザーが何に困り、どこで止まり、どの設定変更を求めたのか。これらが自然にログとして残ります。従来はCSのメモや商談記録に散らばっていた情報が、より構造化された形で集まります。
6. 自社プロダクト改善への反映
複数社で同じ依頼が発生しているなら、それは個別対応ではなく標準機能化すべきサインかもしれません。FDE AIエージェントは、顧客対応の窓口であると同時に、プロダクト改善のセンサーにもなります。
面白いのは、依頼そのものが改善データになること
このモデルで特に重要なのは、ユーザーからの依頼が、そのままプロダクト改善のデータになる点です。
たとえば、どの画面で迷ったのか、どの操作をAIに代行させたのか、どの設定変更が何度も発生しているのか、どの個別要望が複数社で共通しているのか、といった情報が蓄積されます。
これは、単なる問い合わせログではありません。顧客の運用実態にかなり近いデータです。
多くのSaaS企業は、機能要望を集めています。しかし、要望は声の大きい顧客に偏りやすく、背景の文脈も失われがちです。一方で、FDE AIエージェントが日常の業務依頼を受け続けていれば、実際にどこで価値提供が詰まっているのかを、より高い解像度で把握できます。
これはCSエージェントなのか、FDEエージェントなのか
この話をすると、「それはCSエージェントではないか」と感じる人もいると思います。実際、入口はかなりCSに近いです。
ただ、CSエージェントとFDE AIエージェントの違いは、回答するだけで終わるか、顧客の運用とプロダクト改善までつなぐかにあります。
CSエージェントは、既存のプロダクトをうまく使ってもらうための存在です。一方で、FDE AIエージェントは、顧客の現場で発生する使い方、設定変更、個別要望、操作代行のログをもとに、プロダクトそのものを変えていく前提を持ちます。
つまり、顧客対応の自動化ではなく、顧客現場からプロダクト進化へのフィードバックループを作る仕組みとして捉えるべきです。
導入するときに注意すべきこと
もちろん、FDE AIエージェントを入れればすべて解決するわけではありません。むしろ、設計を間違えるとリスクもあります。
権限と承認フローを最初に設計する
SaaS本体の操作代行をさせるなら、どこまで自動実行してよいのか、どこから人間の承認を挟むのかを明確にする必要があります。特に、データ削除、権限変更、外部公開、課金に関わる操作は慎重に扱うべきです。
個別対応を増やしすぎない
AIで簡単に個別対応できるようになると、プロダクトが顧客ごとに分岐しすぎる危険があります。重要なのは、個別対応をすること自体ではなく、どの個別対応を標準機能に戻すべきかを判断することです。
人間のCSやPdMが見るべき情報を整理する
AIエージェントがすべてを抱え込むと、逆に組織学習が止まります。どの依頼を週次でレビューするのか、どの傾向をロードマップに反映するのか、人間側の運用設計が欠かせません。
SaaSの競争軸は、機能数から運用への入り込みへ
今後、SaaSの競争軸は、単純な機能数だけではなくなっていくはずです。
もちろん、機能の豊富さは重要です。しかし、顧客が本当に求めているのは、機能一覧ではなく、自社の業務が前に進むことです。
その意味で、顧客のSlackに入り、日々の相談を受け、設定を変え、操作を代行し、簡易UIを作り、詰まりを記録し、プロダクト改善に戻していくFDE AIエージェントは、SaaS企業にとってかなり相性の良い入口になります。
FDEを専任人材としていきなり配置するのは難しい。けれど、FDE的な接点をAIエージェントとして先に置くことはできる。
この順番のほうが、日本のSaaS企業には現実的かもしれません。
まとめ
FDEは、顧客の現場とプロダクトをつなぐ重要な概念です。ただし、多くのSaaS企業にとって、いきなり人を深く配置するモデルは重すぎます。
だからこそ、最初の一歩としては、Slack上のAIエージェントが自然です。
CS的な一次対応から始め、SaaS本体の操作代行、設定変更、簡易UI構築、依頼ログの蓄積、プロダクト改善への反映までを少しずつ担っていく。そうした軽量なFDE接点が、今後のSaaSの運用価値を大きく変えていく可能性があります。
これは単なるチャットボットではありません。
顧客の現場で起きている小さな詰まりを、プロダクト進化の材料に変える仕組みです。
FDEという言葉が日本でそのまま広がるかはわかりません。しかし、その本質である「現場に入り、実装し、学びをプロダクトに戻す」という動きは、AIエージェントによってむしろ広がりやすくなるのではないかと思います。