AIエージェント運用に「配備側」の人と手順を置く設計
SalesforceのFDE（フォワード・デプロイド・エンジニア）の話題を起点に、マーケティング部門がAIエージェントを配備・運用するための役割分担、立ち上げ手順、回答品質の統制基準を整理します。
公開 2026年9月29日
結論：AIエージェントは「作る人」より「配備して直す人」で決まる
AIエージェントの品質は、モデルやツールの選定より、配備後に誰がどの頻度で直すかで決まります。2026年9月27日のSalesforce Japan Blogでは、顧客先に入って導入と改善を行うFDE（フォワード・デプロイド・エンジニア）という職種が紹介されました。記事では、データの不備やナレッジ記事の更新がデータベースに反映されていないといった、運用側の問題が扱われています。
マーケティング部門が自社サイトにAIを置く場合も、同じ論点が発生します。つまり「回答の根拠になる資料が最新か」「誤答をどこで検知し、誰が何日で直すか」です。本記事は、この配備と改善の体制を社内で設計するための手順と判断基準を整理します。
※本記事は2026年9月時点の情報をもとに作成しています。
FDE（フォワード・デプロイド・エンジニア）とは
FDEとは、製品を顧客の現場に持ち込み、その場で導入・調整・改善まで行う役割を指す呼び方です。Salesforce Japan Blogの記事では、AIエージェントの試験運用でデータやナレッジ反映の問題が生じた企業に対し、FDEチームが派遣されたと説明されています。開発と導入支援の間にある領域を担う職種、という位置づけです。
マーケティング部門にとって重要なのは、職種名そのものではありません。「製品を作る側」と「現場で動かす側」の間に、誰も座っていない状態を作らないという考え方です。
社内でAIを扱うとき、この席は多くの場合空席になります。ツールはマーケが導入し、コンテンツは各部門が持ち、不具合はベンダーに聞く。結果として、誰も回答品質に責任を持たない構造が生まれます。
配備側の役割を社内でどう分けるか
最初に決めるのは、AIの回答に関する3つの責任です。「根拠資料の鮮度」「誤答の検知」「修正の反映」を、それぞれ名前のついた担当に割り当てます。
| 責任範囲 | 担当の置き方 | 判断の基準 |
|---|---|---|
| 根拠資料の鮮度 | 資料オーナー（製品・マーケ） | 価格・仕様・対応範囲が変わった日に更新されているか |
| 誤答の検知 | 週次レビュー担当（マーケ運用） | 会話ログを定期的に見る担当が1人以上いるか |
| 修正の反映 | 配備担当（マーケ＋情シス） | 検知から反映までの日数が決まっているか |
兼任でも構いません。重要なのは、3つとも「誰か」ではなく「この人」になっていることです。
営業への引き継ぎ基準まで含めて設計する場合は、MQLの引き継ぎとSLAの決め方の考え方と揃えると、部門間の責任の切れ目が減ります。
立ち上げから定常運用までの手順
手順は、範囲を絞って開始し、ログを見て広げる順序が扱いやすいです。
- 対象を1つに絞る：製品ページ1本、または特定のユースケース1つに限定します。
- 根拠資料を棚卸しする：AIが参照してよい資料を明示的に列挙します。参照させない資料も明示します。
- 答えない範囲を決める：価格の個別見積、契約条件、他社比較など、人に渡す領域を先に定義します。
- ログの見方を決める：週次で何件、どの観点で見るかを決めます。
- 修正の経路を1本にする：資料を直すのか、回答方針を直すのかを分けて記録します。
- 範囲を広げる：ログ上の未解決質問が落ち着いてから、次のページや用途へ広げます。
各フェーズの判断基準は次の通りです。
| フェーズ | 見るもの | 次へ進む条件 |
|---|---|---|
| 試験運用 | 未解決質問の中身 | 質問の種類が把握できている |
| 限定公開 | 誤答の原因分類 | 原因が資料側か方針側か切り分けられる |
| 定常運用 | 更新の遅延 | 資料更新が定例業務に入っている |
回答品質の統制基準：不具合を種類で分ける
不具合は原因別に分けると、直す担当が自動的に決まります。ひとまとめに「精度が低い」と扱うと、改善が止まります。
| 不具合の型 | 典型的な症状 | 直す場所 |
|---|---|---|
| 根拠の欠落 | 資料にない事項を答えようとする | 資料の追加、または答えない設定 |
| 根拠の陳腐化 | 旧価格・旧仕様を答える | 資料の更新と反映確認 |
| 範囲の逸脱 | 契約条件など人が答えるべき話に踏み込む | 回答方針の境界定義 |
| 引き継ぎの断絶 | 担当に渡る際に文脈が消える | 引き継ぎ項目の定義 |
特に多いのは、資料は更新したのにAI側の参照データに反映されていない型です。Salesforce Japan Blogの記事でも、ナレッジ記事の更新がデータベースに反映されていなかった点が挙げられています。更新作業と反映確認は、別の工程として手順に書き分けます。
回答の境界設計はAIの回答をどこまで許すかの統制でも整理しています。
よくある失敗のパターン
PoCの担当者が異動して止まる。 立ち上げた個人に知識が属人化し、引き継ぎ時に運用が空白になります。手順書と参照資料の一覧を、初日から共有ドライブに置きます。
ログを誰も見ていない。 導入直後だけ確認し、その後は放置される型です。週次30分を定例に入れ、見る人と見る件数を決めます。
資料の更新が製品側の作業に閉じている。 仕様変更が製品ドキュメントだけに反映され、AIが参照する資料が置き去りになります。変更管理のチェックリストに「AI参照資料の更新」を1行足します。
評価指標が「精度」だけ。 何%正しいかは議論が収束しません。未解決質問の件数、修正までの日数、人への引き継ぎ件数など、動きのある数字で見ます。
答えない範囲を決めていない。 何でも答えさせると、確認しなければならない範囲が際限なく広がります。先に人へ渡す領域を定義します。
この進め方が向いていないケース
次の条件では、配備体制を作る前提が成り立ちません。
- 参照できる資料が整備されていない場合。 根拠となる文書が存在しない、または口頭知識に依存している状態では、まず文書化が先です。
- 製品仕様や価格が週単位で変わる場合。 更新が反映に追いつかず、陳腐化した回答が残り続けます。変更が落ち着くまでは範囲を絞ります。
- 問い合わせ件数が少なく、ログが溜まらない場合。 改善の材料が得られないため、有人対応での記録を先に蓄積します。
- 規制上、回答内容の事前承認が必須の領域。 個別の承認フローと自動回答は相性が悪く、人が答える設計のほうが整合します。
また、リード数そのものが足りない段階では、AIの配備より流入と導線の見直しが先になります。BtoB LPのCVRが頭打ちになるときも併せて検討してください。
よくある質問
専任のFDEのような人材を置く余裕がありません。
専任である必要はありません。役割を3つに分け、既存メンバーの業務に週次の枠として組み込む形から始められます。重要なのは人数ではなく、修正の経路が1本に定まっていることです。
ベンダーに任せる場合と自社で見る場合の切り分けは。
製品の挙動や設定はベンダー、根拠資料の内容と鮮度は自社、という分け方が扱いやすいです。資料の中身は自社しか判断できないためです。
誤答が出たとき、まず何を確認すべきですか。
資料に正しい記述があるかを先に見ます。記述があるのに誤答なら反映か方針の問題、記述がなければ資料側の問題です。この切り分けを最初に行うと、担当がすぐ決まります。
会話ログはどこまで営業と共有すべきですか。
引き継ぎ対象になった会話は全文、それ以外は月次の傾向として共有する形が現実的です。共有の範囲は、[営業側の使い方](/for-sales)を踏まえて決めます。
まとめ
AIエージェントの導入は、設置した時点ではなく、直し続ける体制ができた時点で完了します。FDEという職種の話題は、その配備側の仕事に名前が付き始めたことを示しています。
マーケティング部門が明日から着手できるのは、次の3点です。根拠資料のオーナーを決めること。週次でログを見る担当を決めること。誤答を型で分類し、直す場所を対応付けること。この3つが揃えば、ツールが何であっても運用は回り始めます。
UniAgentは、Webサイト上で登録資料を根拠に説明とヒアリングを行い、その内容を文脈付きで担当者へ引き継ぐAIです。関連する整理はナレッジ一覧にまとめています。