Salesforce公式の最終章「Monitor」は、Agentforceを**“運用で磨く”**ための指針です。
約15ページにわたって、Analytics Data ModelやSession Tracing、Deflection Rate・Quality ScoreなどのKPI測定手法が解説されています。
本記事ではそれを実務レベルに翻訳し、運用指標の読み方・分析設計・改善サイクル構築の3点に焦点を当てました。
単なる導入ではなく、“継続的に成長するエージェント運用”の仕組みをつくるための応用編です。
Deployフェーズ:チャネル設定と担当者準備の詳細
展開フェーズでは、機能の有効化からチャネルのルーティング設計、エスカレーション処理、担当者の環境整備まで多数の手順があります。以下ではタスク単位でまとめます。
1. 前提機能のチェック
まずは組織で以下の機能が有効になっているか確認します。すべてが有効になっていないと接続やフロー作成が行えません。
| 必須機能 | 用途 |
|---|---|
| Enhanced Omni‑Channel Routing | メッセージセッションをエージェントやキューへ自動配分する。 |
| Messaging | Webチャットやアプリ内メッセージングを提供する。 |
| Digital Experiences | Experience Cloudサイトにチャットを埋め込む。 |
2. ルーティングの実装
チャネル側でのルーティング設定は、サービスチャンネル、Routing Configuration、Queue、Omni‑Channel Flowの4つが基本です。
2.1 サービスチャンネルの作成
SetupのService ChannelsからMessaging Sessionオブジェクト用のサービスチャンネルを作成します。名前は「Customer Chat Channel」など分かりやすいものとし、対象オブジェクトをMessaging Sessionに指定します。
2.2 Routing Configurationの設定
チャットを担当者へどのように割り当てるかを定義します。Least Activeモデルを用いると空き時間の長い担当者に割り振られます。同時にキャパシティタイプや利用率を設定し、担当者あたりの負荷を調整します。
2.3 Queueの作成
エージェントが対応できない場合やエスカレーション時の受け皿となるキューを作成します。キューに前述のRouting Configurationを紐付け、サポート対象オブジェクトにMessaging Sessionを設定します。実稼働前には、担当者が所属するパブリックグループまたはロールをこのキューに追加することを忘れないでください。
2.4 Omni‑Channel Flowsの構築
フローはインバウンド用とアウトバウンド(エスカレーション用)の2種類を作成します。
- インバウンドフロー:テンプレートから作成し、入力変数にrecordId、input_record、firstName、lastName、email、MessagingUserを追加します。フロー内ではメールアドレスからContactを検索し、found Contactがある場合はMessagingUserレコードにContactIdを設定します。最後にRoute Workアクションを使い、Service ChannelとAgent Nameを指定し、Fallback Queueには作成したQueueを選びます。
- アウトバウンドフロー:顧客が「人間と話したい」と要求したときに担当者へ転送するフローです。Flow BuilderでrecordId、input_recordを受け取り、Check Availability for RoutingアクションでQueueの担当者が利用可能か確認します。空きがあればRoute WorkアクションでQueueへ送信し、空きがなければエージェントに会話を継続させます。アウトバウンドフローはエージェント設定のMessaging ConnectionでEscalation Flowとして指定します。
3. エスカレーションのカスタマイズ
エスカレーション体験は顧客満足度に直結します。Makana社は以下の工夫で体験を改善しています。
- エスカレーション時のシステムメッセージを「担当者をお探ししますので少々お待ちください」など親しみやすい文言に編集する。
- エージェントが担当者を見つけられなかった場合は、自動的にケースを作成するアクションをEscalation トピックに追加する。EndUserContactIdをフローから検証済みとして渡すことで、再度メールアドレスを尋ねることなくケースを作成できる。
- Escalation トピックのプロンプトに「顧客のメールが未入力なら質問する」「失敗したらケース番号を伝える」といった具体的な手順を記述しておく。
4. サービスチームの整備
エージェントが対応できない場合を想定し、サービス担当者がスムーズに引き継げる環境を整えます。
- Service Resourcesへの登録:担当者をService Resourcesとして追加し、アクティブに設定します。
- Presence Statusesの作成:担当者の在席状況を表すステータス(Available, Busy, Offline等)を作成し、担当者に割り当てます。
- Service Consoleのカスタマイズ:Omni‑Channel Sidebarを有効にし、Messaging Session用のカスタムレコードページを作成します。画面左側にチャットウィジェット、右側に顧客情報やケース情報を配置すると担当者の視認性が高まります。
5. チャットチャネルとサイトの作成
以下の手順で顧客向けサイトにチャットを組み込みます。
- Messagingチャネル:SetupのMessagingから「New Channel」を作成し、Messaging for In‑App and Webを選択します。チャネル名とドメインを指定し、Inbound FlowとOutbound Flow、Fallback Queueをそれぞれマッピングします。プレチャットフォームの項目(氏名・メール)とフローの変数をパラメータマッピングで結び付けます。
- Embedded Service Deployment:Messagingチャネル作成時に自動生成されるデプロイメントでプレチャットフォームを有効にし、必要な項目を必須化します。テスト機能でチャットがフローを通過するか確認します。
- Experience Cloudサイト:Help Centerテンプレートを使ってサイトを作成し、フッターにEmbedded Messagingコンポーネントを配置します。サイト公開後はCORS 設定でドメインを許可しないとチャットが表示されないので注意が必要です。
6. テストとデプロイ
構築後は、ステージング環境で以下の2シナリオを必ずテストします:
- 担当者不在のケース – エージェントがエスカレーションを試みても担当者がいない場合、エージェントがケース作成を案内し、ケースが正しく作成されるか確認します。
- 担当者が在席しているケース – Service ConsoleでOmni‑Channel Sidebarをオンラインにし、エスカレーション要求が担当者へ割り当てられるか確認します。
テスト結果を確認したら、Salesforce CLIを用いてメタデータ(Queue、Flows、チャネル設定など)をパッケージ化し、本番環境にデプロイします。デプロイ後は本番環境でも同じテストを実施し、問題がないことを確認します。
Monitorフェーズ:分析と改善のサイクル
公開したエージェントの品質を継続的に向上させるには、データ収集と分析を定期的に行い、改善策に反映することが欠かせません。ここではAgentforce AnalyticsとOptimizationを活用したモニタリングの詳細を説明します。
1. Audit and Feedbackの設定
Generative AIの出力とユーザーフィードバックを収集するため、Generative AI Audit and Feedbackを有効にします。SetupのEinstein Audit and Monitoring設定から「Generative AI Audit and Feedback」をオンにし、出力とフィードバックを保存するData Cloud Spaceを選択します。これにより、エージェントの応答やユーザー評価が記録され、後から分析可能になります。
2. Agentforce Analyticsの導入
Analyticsはセッション単位の指標を提供するダッシュボード群です。利用するにはSession Tracingをオンにし、STDM (Session Tracing Data Model) を有効化する必要があります。次にAgent Analytics (Beta)ページからダッシュボードライブラリをインストールし、実際のデータを読み込んで指標を確認します。主要な指標としては、品質スコア、エスカレーション率、ディフレクション率、遅延などがあります。
3. Agentforce Optimizationの活用
Optimizationはセッションを「モーメント」に分解し、類似意図の会話をグループ化することで、問題点の深掘りを支援します。利用するにはSession Tracingに加えてOptimizationを有効にし、ユーザーにOptimization用の権限セットを割り当てます。モーメントの生成は約9時間おきに行われ、週末にクラスタリングが自動実施されます。
4. 主要指標の読み方
Analyticsのセマンティックレイヤーには様々な計算フィールドが用意されており、複数の指標を組み合わせることで根本原因分析が可能です。代表的な指標と活用方法は以下の通りです。
| 指標 | 意味 | 改善のヒント |
|---|---|---|
| Quality_Score_clc / Average_Quality_Score_clc | 応答の正確性や指示遵守度を1〜5で評価。低い場合はプロンプトの調整やデータライブラリの追加を検討。 | プロンプトをより具体的に書き直す、またはナレッジソース(Data Library)の範囲を拡充して再学習を促す。 |
| Moment_Duration_clc / Average_Moment_Duration_clc | モーメント単位の所要時間(秒)。長い場合は回答が分かりにくい可能性があるのでFAQや回答テンプレートを見直す。 | 長文回答を分割し、見出し・段階的提示・FAQ形式で可読性を向上させる。 |
| Escalation_Rate_clc | セッション中のエスカレーション発生率。高いときはエスカレーション条件やトピック設計が適切かを再検討。 | エスカレーション条件を見直し、誤判定を防ぐ。FAQ充実や意図認識強化で自動対応率を上げる。 |
| Deflection_Rate_clc | ユーザーが途中でチャットを終了した割合。低ければ自己解決が成功していると判断できるが、極端に高い場合は回答品質の問題も疑われる。 | 会話ログを分析し、「途中離脱が多い質問タイプ」を特定して回答内容を再設計する。 |
これらの指標をCross-filterで組み合わせて分析すると、長時間のわりに品質スコアが低いモーメントや、エスカレーション率が高いトピックを特定できます。
5. 継続的改善サイクル
ガイドでは監視タスクを時間軸で整理し、改善サイクルを構築することを推奨しています。
- Post‑Launch Monitoring(公開直後) – 初期データが正しく収集されているかを確認し、品質スコアや遅延が極端に悪化していないかチェックします。初期のユーザーフィードバックを収集し、重大な問題があればフローやプロンプトを即修正します。
- Moment Monitoring(公開30日後〜) – Optimizationが生成したモーメントを確認し、品質スコアが低いグループやエスカレーションの多いグループを抽出します。該当するトピックやアクションを見直し、データライブラリの追加やプロンプトの改善を計画します。
- Root Cause Analysis(データ蓄積後) – モーメントをクラスタリングし、共通の課題を洗い出します。原因が特定できたら、プロンプトテンプレートやナレッジ記事を更新し、テスト環境で検証してから本番に適用します。
運用チームは日次でKPIを確認し、週次でモーメント分析を行い、月次で根本的改善を計画するというリズムを持つと継続的な品質向上が実現しやすくなります。
よくある課題と対策
展開・モニタリングの現場では、細かな設定漏れや指標解釈の行き違いが原因で期待した成果が出ないことが少なくありません。以下の表に代表的な課題と対策をまとめました。
| 課題 | 対策 |
|---|---|
| チャネル設定が複雑でミスが起こりやすい | 展開前にチェックリストを用意し、Enhanced Omni‑Channel Routing、Messaging、Digital Experiencesが有効か、サービスチャンネル・Routing Configuration・Queue・フローが正しく紐付いているかを確認する。設定変更後は必ずステージング環境でテストする。 |
| エスカレーション時にメールアドレスを再確認されてしまう | Escalation トピックに追加したケース作成アクションでEndUserContactIdを検証済みとして渡し、インバウンドフローでMessagingUserレコードにContactIdをセットする。これにより、エージェントは再度メールアドレスを尋ねることなくケース作成ができる。 |
| Analytics指標の解釈が難しい | Quality ScoreやEscalation Rateなど主要指標の目標値を事前に設定し、初期のベンチマークを取得してから運用する。指標単体ではなく複数指標の組み合わせ(例:長いMoment Duration & 低いQuality Score)で判断することで、改善点が明確になる。 |
| 改善サイクルが続かない | 日次・週次・月次で実施するタスクを決め、担当者と期限を明確にする。Optimizationで抽出したモーメントを週次レポートとして共有し、改善案をタスクに落とし込むことで継続的な改善が回り始める。 |
まとめと次のステップ
本記事は、公式ガイド最終章「Monitor/Optimize」の要点を抽出し、運用改善の仕組みを実務レベルで整理しました。
KPI分析・品質スコア・モーメント生成を通じて、Agentforceを継続的に強化するサイクルを学べたはずです。
これで公式ガイド全体(Ideate→Build→Deploy→Monitor)の全行程を俯瞰できました。
次は再び最初のフェーズ「企画」へ戻り、AI導入の目的と設計を再定義してみましょう。
次に進む
- 第1章:企画フェーズ(初学者向け)へ – 改善データを活かし、AI導入戦略をゼロから再構築。
- 第3章:展開・運用フェーズ(初学者向け)へ – モニタリング設計をさらに磨き上げたい方はこちら。
お問い合わせ
現在Salesforceを効果的に活用できていない企業様や、これからSalesforceの導入を検討している企業様で、設定や運用、保守に関するサポートが必要な場合は、ぜひお気軽にご相談くださいませ!