動的計画のテスト

• 動的プランのテスト方法
• サービスプラン概要のドラフトと評価
• ケース概要計画
• メッセージング概要計画
• 概要エラーメッセージのトラブルシューティング
• 動的計画の作業と確認
• ナレッジグラウンディングのトラブルシューティング

動的プランのテスト方法

動的計画は、レコードの変更に応じて適応するリアルタイムの計画で、ケースとメッセージングセッションの両方で使用できます。動的計画をテストするには、レコードで動的計画を生成します。サービスアシスタントは Lightning Web コンポーネントを使用してサービスプランを提供するため、Agentforce Builder または Agentforce テストセンターでテストすることはできません。一般的なテスト設定、テストする使用事例の選択方法、すべての計画種別に適用される Knowledge グラウンディング ガイダンスについては、「Test Service Assistant」を参照してください。

動的計画には、長さや終了時刻が設定されていません。この長さは、ケースまたはメッセージングセッションがどの程度進展するか、および問題に対処するためにグラウンディングソースが保持する情報の量によって異なります。Service Assistant では、レコードの変更や解決の進捗に応じてステップが追加されるため、より豊富なソースと長い会話に基づく計画は、限られたコンテキストのステップよりも多くのステップを実行します。ケースがクローズされたとき、またはメッセージングセッションが終了してチャットが終了したときに、レコードがクローズされると、計画は自動的に終了します。計画履歴はコンポーネントフィードに保存され、レコードがクローズまたは終了した後にアクセスできます。

サービスプラン概要の作成と評価

レコードが対象資格基準を満たすと、Service Assistant はレコードの概要と解決ステップ (サマリーステップ) の概要を含むサービスプラン概要のドラフトを作成します。概要が生成されたら、[Start Plan (計画を開始)] ボタンが表示されます。[計画を開始] をクリックして、リアルタイムの対話型ワークフローを開始します。サマリーがいつ生成されるかは、レコードタイプによって異なります。

概要の一部として、Service Assistant は問題を識別し、一致するサブエージェントを割り当てます。適切なサブエージェントが割り当てられていることを確認します。ケースの場合、Service Assistant は Service AI グラウンディング設定で設定された [件名] 項目と [説明] 項目に基づいてサブエージェントを割り当てます。メッセージングセッションでは、会話トランスクリプトのコンテキストに基づいてサブエージェントが割り当てられます。

サマリープランが表示されるまで最大 1 分かかる場合があります。コンポーネントに読み込み中インジケーターが表示されない。すべてのケース概要は [Service Plan Available] で始まり、サブエージェント名が続きます。

ケース概要計画

テストプロセスを開始するには、既存のケースを開くか、新しいケースを作成します。ケースが対象資格基準を満たしていることを確認します。ケースがオープンまたは作成されると、サービスアシスタントが概要のドラフトを作成します。次に例を示します。

ケースの概要と概要の両方のステップの詳細レベルは、ケースの情報量、Service AI グラウンディング設定で設定した項目とオブジェクト、およびサブエージェント、手順、Knowledge 記事の情報量によって異なります。通常、より詳細なサービスプラン概要 (上記参照) がある場合、ドラフトされたサービスプランはかなり詳細になることが予想されます。

特に、[件名] 項目と [説明] 項目は、Service Assistant がケースを分類してサブエージェントと照合するために使用するため、非常に重要です。Service Assistant は Service AI グラウンディング設定で設定された追加の項目とオブジェクトに基づきますが、正確な計画を生成するには、[件名] と [説明] に明確で具体的な情報が必要です。一般に、項目が詳細であるほど、一致度が高くなります。

メッセージング概要計画

テストプロセスを開始するには、対象資格条件を満たすメッセージングセッションを開きます。ケースとは異なり、メッセージングセッションは開いた直後に概要を生成しません。サービスアシスタントは、サブエージェントや指示に一致する情報を含め、問題を識別するのに十分なコンテキストが会話に含まれている場合にのみ、サービスプラン概要を生成します。

• 初期のメッセージにサブエージェントに一致する情報が含まれていない場合、Service Assistant は会話を監視し続け、後のメッセージで一致が提供されると概要を生成します。概要の生成に必要な会話量は異なる場合があります。
• この動作をテストするには、サブエージェントでの使用事例を反映するメッセージを送信し、Service Assistant で概要が生成され、一致するサブエージェントが識別されることを確認します。

メッセージングセッションの概要が表示されない場合は、次の要件を満たしていることを確認してください。

• プランをテストするユーザーは、「フローを実行」権限があっても対象資格フローにアクセスできます。「フローを実行」権限だけでは、対象資格フローへのアクセス権は付与されません。「サービスプラン対象資格基準」および「Set Up Service Assistant for Messaging (メッセージングのサービスアシスタントの設定)」を参照してください。
• 会話には、問題を特定するのに十分なコンテキストが含まれています。会話でサービスアシスタントに十分なコンテキストが提供されるまで、概要は生成されません。
• メッセージングセッションレコードは、ボットユーザーではなく人間のエージェントが所有しています。Service Assistant では、ボットユーザーが所有するレコードの計画は生成されません。

概要エラーメッセージのトラブルシューティング

計画概要の生成が開始されないか、リストされたエラーメッセージが表示される場合は、次のトラブルシューティング手順を実行します。

エラーメッセージ

• サービスプラン概要のドラフトを作成できませんでした。引き続き試行しますが、問題が続く場合は、Salesforce システム管理者にお問い合わせください。
• サービスプラン概要のドラフトを作成するのに十分な情報がありません。詳細を追加してから、ここに戻って確認してください。
• 関連するサブエージェントが存在しないため、サービスプランのドラフトを作成できませんでした。Salesforce システム管理者に作成を依頼するか、項目にコンテキストを追加します。

一般的なトラブルシューティング手順

• 適切な権限があることを確認します。システム管理者には、「サービスプランナービルダー」権限セットと「Agentforce デフォルトの管理者」権限セットが必要です。Knowledge グラウンディングを使用する場合は、デフォルトのデータスペースへのアクセス権を持つ「Data Cloud Architect」権限セットがあることを確認してください。サービス担当者には、「サービスプランナーユーザー」権限セットと「Agentforce デフォルトエージェントにアクセス」権限セットが必要です。
• サービスプランナーユーザーに「サービスプランナーエージェントユーザー」、「Agentforce_Service_Assistant 権限」、「Data Cloud ユーザー」権限セットが割り当てられていることを確認します。
• Knowledge記事に正確で包括的、かつ適切に構造化された情報が含まれていることを確認します。Service Assistant では、概要ステップに Knowledge 情報が含まれます。
• 「関連するサブエージェントが存在しないため、サービスプランのドラフトを作成できませんでした。Salesforce システム管理者に作成を依頼するか、項目にコンテキストを追加してください。」というメッセージが表示された場合、Service Assistant はレコードの詳細に一致するサブエージェントを検出できません。上記のトラブルシューティング手順が適用されます。さらに、サブエージェントと手順を確認します。必ず「Grounding Service Assistant with Topics and Topic Best Practices」のガイドラインに従ってください。
  • レコードに関連するサブエージェントと指示が作成されていることを確認します。
  • 各サブエージェントに「Return Request (返品要求)」や「Refund Request (返金要求)」などの個別のタイトルを付けます。
  • 「ケース解決支援」のような汎用的な万能サブエージェントは作成しないでください。サブエージェントは、特定のケース種別を解決するための会社の特定のポリシーと標準を記述します。「Case resolution assistance (ケース解決支援)」というサブエージェントは範囲が広すぎるため、サービスアシスタントはケースを適切なサブエージェントと照合できません。代わりに、「商品不具合レポート」、「請求の紛争」、「取引先アクセスの問題」など、それぞれが 1 つの特定のケースカテゴリに対応する個別のサブエージェントを作成します。
  • ケース種別をサブエージェントカテゴリに分割します。たとえば、返品の処理方法に関する一般的な情報については、「返品要求」のような広範なサブエージェントを使用します。これは、ケースで明示的な項目が言及されていない場合に最適です。範囲とプロセスが異なる返品プロセスの場合、「Shoe Return Request (靴の返品要求)」などの個別の返品要求サブエージェントを作成します。これらは簡単な例ですが、特定のケースに含まれる可能性のあるさまざまなレベルの情報に対処しようとするサブエージェントと指示に十分な情報が含まれていることを確認することを目的としています。
  • 1 つの命令に複数の情報を含めないでください。各命令では、問題の解決に必要な 1 つの ToDo またはプロセスの概要を示す必要があります。

ケースのトラブルシューティング手順

• サブエージェントに関連する明確でわかりやすい件名がケースに含まれていることを確認します。
• ケースの問題または要求に関する説明に十分な詳細が含まれていることを確認します。1 ～ 2 文をお勧めします。
• Service AI グラウンディング設定を確認します。グラウンディングするすべての項目と関連ケースオブジェクトが選択されていることを確認します。次に、ケースの次の項目のデータを確認します。グラウンディング項目またはケースフィード、コメント、メールに明確で競合しない情報があることを確認します。情報が競合すると、ケースの概要や手順の詳細が不明確になる可能性があります。

メッセージングのトラブルシューティング手順

• Service Assistant は、[件名] 項目と [説明] 項目ではなく会話トランスクリプトでグラウンディングします。Service Assistant がサブエージェントを照合して焦点を絞ったサマリーステップを生成できるように、会話に顧客の問題に関する明確で具体的な詳細が含まれていることを確認します。
• 概要要件を満たしていること、会話に問題を識別するのに十分なコンテキストが含まれていること、1 つ以上のメッセージがサブエージェントに一致すること、レコードがボットユーザーではなく人間のエージェントによって所有されていること、計画をテストするユーザーに対象資格フローへのアクセス権があることを確認します。「メッセージング概要計画」を参照してください。

動的計画の作業と確認

成功した計画の概要を確認したら、[Start Plan (計画を開始)] をクリックしてワークフローを開始します。ガイダンス計画とは異なり、動的計画では完全なチェックリストのドラフトが一度に作成されることはありません。Service Assistant は一度に 1 つのステップを提示し、レコードの変更に応じて各ステップを調整し、エージェントアクションを表示してステップを自動化できます。計画に取り組むときに、正確性と関連性を評価します。

各ステップでのガイダンスの確認

• 各ステップのガイダンスを確認し、正確で関連性が高く、サブエージェント、手順、Knowledge記事の解決ガイダンスと一貫していることを確認します。
• 各ステップの表現を確認し、エージェントアクションが期待どおりに表示され実行されることを確認します。ステップを完了するためにアクションを使用できる場合、Service Assistant によってステップに表示され、確認して実行できます。アクションは設定に基づいて自動的に実行されます。

サブエージェントベースのステップ

• サブエージェントの指示から作成されたステップは、各指示で指定したガイダンスから直接作成されます。サンプルサービスプランでは、サブエージェントベースのステップは「ID 検証を実行してユーザーのドキュメント処理の対象資格を確保します。」です。
• ステップが (Knowledge グラウンディングなしで) サブエージェントのみに依存している場合、ステップには引用リンクは含まれません。
• ケースに一致するサブエージェントが計画の生成に使用されます。サブエージェント名はサービスプランの最上部に表示されます。

Knowledgeベースのステップ

Knowledgeデータ型を使用してデータライブラリを設定し、[ソースを表示] を有効にすると、サービスプランはKnowledge記事でグラウンディングされます。「Set Up Knowledge Grounding」を参照してください。

表示とナビゲーション

• Knowledge Article から作成された各ステップは、ステップの最後に番号を付けて引用されます [1]。引用には、Knowledge 記事の名前をリストする [ソース] セクションの対応するエントリへのハイパーリンクが含まれます。引用を表示するには、データライブラリ設定で [ソースを表示] を有効にします。
• 動的計画では各ステップがリアルタイムで作成されるため、各ステップには計画全体の 1 つのソースセクションではなく、独自のソースセクションがあります。各ステップの引用が、そのステップで使用される記事にリンクしていることを確認します。
• 同じ記事がステップごとに異なる引用番号で表示されることがあります。動的計画では、各ステップが独自に作成および引用されるため、ステップ間で引用番号は一致しません。この動作は予期されるものであり、複数のステップで使用される記事で同じ引用番号が保持されるガイダンス計画とは異なります。
• ステップは、サブエージェントと Knowledge 記事の両方から作成できます。
• ステップは複数の Knowledge Article から作成できます。これは、ステップの最後に引用が 2 つ以上ある場合に示されます [1][2]。

グラウンディングされていないステップ

サービスアシスタントは、グラウンディングソースに基づいていない独自のステップを提案できます。提案されたステップは、サブエージェント、手順、または Knowledge 記事に十分な情報がない場合に表示されます。動的計画では、Service Assistant は提案ステップに「会社のドキュメントに情報がありません。こう提案しても 正しくないかもしれないテスト中にこれらのフラグを使用してグラウンディング ソースのギャップを見つけ、不足しているガイダンスをサブエージェント、手順、または Knowledge 記事に追加します。

動的計画の更新

動的計画では、新しい情報が到着すると、そのステップがリアルタイムで更新されます。ガイダンスプランとは異なり、動的プランを再ドラフトすることはできません。代わりに、計画中にグラウンディングソースを更新すると、Service Assistant は更新が行われたときに更新を取得します。この動作のテスト方法は、レコードタイプによって異なります。

ケースの場合、Service AI グラウンディング設定で設定された項目とオブジェクトを更新し、Service Assistant でその変更が取り込まれていることを確認します。

• Service Assistant は、Service AI グラウンディング設定で設定された項目とオブジェクトを使用してケースを監視します。
• 現在、営業担当が現在実行中のステップがリアルタイムで更新されるのは新規ケースメールのみです。ケースコメント、ケースフィード、その他のグラウンディング項目など、その他のすべての情報は追跡され、現在のステップではなく次のステップに組み込まれます。

メッセージングセッションの場合、Service Assistant は会話トランスクリプトで計画をグラウンディングするため、更新はリアルタイム性が高いです。セッションで新しいメッセージを送信し、チャットフィードの進捗に応じてサービスアシスタントが計画を更新することを確認します。

• Service Assistant はトランスクリプト全体を監視し、新しいメッセージを受信するたびに新しい計画ステップを生成するため、各ステップには会話の現在の状況が反映されます。
• 新しいケースメールのみが現在のステップを更新するケースとは異なり、メッセージングセッションは会話の進行に合わせて段階的に更新されます。

テストエージェントアクション

動的計画では、エージェントアクションが計画ステップと一致すると、Service Assistant によってエージェントアクションが自動的に表示されます。計画に取り組むときは、表示されるアクションと見逃されるアクションに注意してください。期待するアクションがステップに表示されない場合は、次の方法を試してください。

• サブエージェント命令でアクションへの直接参照を追加します。API 参照名ではなく表示ラベルでアクションを参照し、いつ使用するかを Service Assistant に指示します。たとえば、「最初のステップとして、[Get Travel Records (移動レコードを取得)] アクションを使用します。直接参照では、Service Assistant にアクションを含める必要があるため、必ず実行する必要がある必須ステップで使用します。「Service Assistant のアクション」を参照してください。
• アクションの説明を絞り込みます。条件が一致した場合にのみ実行される状況ステップの場合、Service Assistant はコンテキストの一致を使用するため、サブエージェントの手順と Knowledge 記事で用語を反映する説明を記述します。「アクション作成のガイドライン」を参照してください。
• サービスプランナーユーザーのアクションの権限を確認します。アクションはサービスプランナーユーザーの権限で実行され、権限がない場合、アクションが失敗したり、空白のデータが返されたりする可能性があります。「アクション権限」を参照してください。

アクションの実行後、Service Assistant で「レコードが更新されました」などの自由記述の言語が表示されることがあります。手順を教えてください」というメッセージが表示され、次のステップに進むことができません。計画を続行するには、サブエージェントの指示に「アクションが完了したら、すぐにエントリ要件の確認に進みます」など、次のアクションを記述します。アクションの設定と照合についての詳細は、「エージェントアクションを使用した サービスアシスタントのグラウンディング」を参照してください。

計画での特定の情報の要求

特定の情報が計画に常に表示されるようにするには、サブエージェントの指示にその情報を含めます。この方法は、情報がKnowledge記事から取り込まれない場合に使用します。「最初のステップとして、顧客の取引先状況を確認します」など、必要な内容とタイミングを正確に示す指示を記述します。この方法で指示された情報は、常に計画に含まれます。

計画の推進

エージェントアクションでステップが完了すると、動的で高度なステップが自動的に計画されます。アクションで自動化されていないステップの場合、サービスアシスタントはステップを完了するためにサービス担当者が手動で行う操作を記述し、担当者が確認するのを待ちます。この動作は予期されるものであり、エージェントのチャットで情報に関する質問をするときに Service Assistant は特に待機します。

• 自動化されていないステップの場合、Service Assistant は完了する ToDo について説明し、担当者に「このステップが完了したら知らせてください」などの言葉で指示します。計画は勝手には進まない。
• 計画を進めるには、「完了」、「ステップ完了」、「次のステップに進む」など、ステップが完了したことを明確に示す言葉で応答します。次に、サービスアシスタントによって次のステップが生成されます。

通常は、解決ガイダンスに沿って作業し、各ステップの表現がサービス スペシャリストやKnowledgeおよびサブエージェントの指示と正確で一貫しているかどうかを評価します。

サブエージェント スイッチング

サービスアシスタントは、ケースの進行状況に応じて顧客のインテントを検出し、関連するサブエージェントに切り替えて、そのサブエージェントとその関連Knowledge情報からガイダンスを提供できます。2 つ目の問題を導入して、サービスアシスタントがサブエージェントを切り替えることを確認することで、この動作をテストします。

• 解決が 1 つのサブエージェントの問題から開始され、2 番目の問題に移行した場合、Service Assistant は 2 番目のサブエージェントに切り替えて、必要な情報を収集し、計画のその部分を解決します。
• 2 番目の問題が解決されると、Service Assistant は自動的に元のサブエージェントに切り替えることができます。場合によっては、自動的に切り替わらないことがあります。チャットを使用して、「元の問題に戻りましょう」などのリダイレクトを行います。

詳細は、「サービスプランレコード処理」を参照してください。

エージェント チャットの使用

エージェントのチャットをテストして、Service Assistant がオンデマンドで Knowledge を検索し、アクションを実行できることを確認します。エージェントチャットを使用するには、一般的な CRM および FAQ サブエージェントをエージェントに追加します。「Agent Chat for Service Assistant」を参照してください。

• Knowledgeに関する質問をするか、Knowledge情報を求め、サービスアシスタントがKnowledge記事から関連情報を返すことを確認します。
• メールのドラフト作成などの一般的なアクションと追加したカスタムアクションを起動するように Service Assistant に依頼します。アクションが機能しない場合は、サービスプランナーユーザーのアクション権限を確認します。「アクション権限」を参照してください。

レコードが完了したときのエージェントのチャットの動作は、チャネルによって異なります。ケースがクローズされると、エージェントのチャットは終了し、チャットボックスは無効になります。メッセージングセッションが終了すると、サービス計画は終了しますが、サービスアシスタントとチャットボックスは約 24 時間使用できるため、まとめ作業 (概要の確認、フォローアップメールのドラフト作成、Knowledge の質問、アクションの実行、チャットを使用した一般的なサポートの取得など) を完了できます。いずれの場合も、フィード履歴は保持され、表示されたままになるため、記録後に計画ステップ、アクション、チャットインタラクションの完全なレコードを確認できます。

ナレッジグラウンディングのトラブルシューティング

Knowledge記事が引用されていない場合、引用された記事が関連していない場合、または一般的なエラー メッセージが表示される場合は、次のトラブルシューティング手順を実行してください。Knowledge Groundingはプラン タイプ間で同じように機能するため、このガイダンスはケースとメッセージング セッションの両方に適用されます。動的計画では、各ステップが独自に作成および引用されるため、あるステップでは引用の問題が発生しても、別のステップでは発生しないことに注意してください。

一般的なエラーメッセージ

• 計画の作成中に問題が発生しました。データライブラリ設定を確認するように Salesforce システム管理者に依頼してください。
• 引用するソースが見つかりませんでした。データライブラリ設定を確認するように Salesforce システム管理者に依頼してください。
• 情報源は示せなかったSalesforce システム管理者にお問い合わせください。

ユーザー権限とデータアクセスの確認

• エージェントが有効になっていることを確認します。
• すべてのユーザーに正しいKnowledgeグラウンディング権限があることを確認します。「Best Practices for Grounding Service Assistant in Knowledge」を参照してください。サービスプランナーユーザーの権限に十分注意してください。「Data Cloudユーザー」権限セットがあり、ユーザーにカスタム レコード タイプとKnowledge記事に割り当てられたデータ カテゴリへのアクセス権があることを確認します。
• 管理者、サービス担当者、サービスプランナーユーザーが権限セットのデフォルトデータスペースにアクセスできることを確認します。通常、「Data Cloud アーキテクト」権限セットで有効になっているデフォルトのデータスペースにアクセスできるのは、Service Assistant 管理者のみです。ただし、Knowledge記事が計画に含まれていない場合は、デフォルトのデータ スペースへのアクセス権をサービス担当者に付与することをお勧めします。デフォルトのデータスペースアクセス権は、Knowledge カスタム権限セットまたは標準の Service Assistant 権限セットを使用して付与できます。「デフォルトのデータスペースアクセス」を参照してください。

Knowledgeグラウンディングの設定の確認

• 記事が公開され、公開されていることを確認します。一般公開されているKnowledge記事では、IsVisibleInPkbがTrueに設定されています。
• データライブラリ設定で [ソースを表示] が有効になっていることを確認します。[ソースを表示] を使用しない場合、動的計画ステップのステップごとの [ソース] セクションまたは引用は表示されません。
• 検索インデックスを再構築して、データライブラリに最新のKnowledgeベース情報があることを確認します。データライブラリ検索インデックスは毎日更新されますが、データライブラリを最新のKnowledgeベースの更新と同期させるには手動で再構築します。Knowledge 記事を追加、変更、または削除するときは、検索インデックスを再構築することをお勧めします。「検索インデックス設定の再構築」を参照してください。
• データカテゴリの設定とアクセス権を再確認します。データ カテゴリが表示され、Knowledge記事に設定されたデータ カテゴリがデータ ライブラリの[Knowledge]タブで設定されたデータ カテゴリの絞り込みに一致することを確認します。
• 記事を確認して、構造と形式がデータライブラリで設定した識別項目とコンテンツ項目に一致することを確認します。識別項目はKnowledgeベースを検索して、レコードの詳細に一致する関連記事を検索します。コンテンツ フィールドは、Knowledge記事から重要な情報を抽出して計画ステップを作成します。
  • 項目を識別するには、[タイトル]、[概要]、[質問] など、記事の簡潔な概要を提供する項目を選択します。
  • コンテンツ項目の場合、[回答] や [詳細] など、コンテンツが最も多い項目を選択します。
  • カスタムKnowledgeフィールドを識別およびコンテンツフィールド設定に適用します。
• Knowledge記事の概要を確認または追加して、記事とその範囲を簡単に説明します。概要により、検索結果が改善されます。レコードの詳細でよく使用される語句を含めて、問題または要求を説明します。
• 記事のコンテンツにレコードに関連するキーワードと情報が含まれていることを確認します。

レコードコンテンツ

• ケースの場合、サービスAIグラウンディング設定でケースの件名、説明、項目セットを確認し、各項目に十分な情報があること、その情報が表示する予定のKnowledge記事に関連していることを確認します。ケースコメントとケースフィードをグラウンディングソースとして選択している場合は、それらを確認します。情報の関連性が高く、表示する予定のKnowledge記事と競合しないことを確認します。
• メッセージング セッションの場合、会話トランスクリプトを確認し、表示する予定のKnowledge記事に関連する特定の詳細とキーワードがメッセージに含まれていることを確認します。計画はトランスクリプトに基づいているため、Service Assistant が関連記事を取得して引用するように、問題を反映するメッセージを送信します。

対象を絞ったエラーメッセージのトラブルシューティング

• 引用するソースが見つかりませんでした。動的計画は再ドラフトできないため、会話を続行するか、レコードを更新して新しいステップを促してから、引用の表示を確認します。問題が続く場合は、Salesforce システム管理者に、データライブラリの取得に関するサポートを Salesforce カスタマーサポートに依頼してください。
• 情報源は示せなかったSalesforce システム管理者に依頼して、データライブラリの取得について Salesforce カスタマーサポートにお問い合わせください。

設定とテストの詳細については、「Set Up Knowledge Grounding and Troubleshooting Knowledge」を参照してください。