Agentforce サービスエージェントは、拡張メッセージングチャネルとアプリケーション内および Web 向けのメッセージングで、顧客が一般的な問題を解決できるようサポートします。エージェントは顧客に代わって自律的に行動できるため、ケース解決のための強力なツールとなります。会社のセキュリティ基準と使用事例を念頭に置きながら、エージェントのアクションに ID やその他のガードレールをどのように組み込むか、また、組み込むかどうかを決定します。
|
サービスエージェントは、Lightning Experience で利用できます。 |
|
利用可能: Enterprise、Performance、Unlimited、Developer Editions with the Einstein for Service、Einstein Platform、または Agentforce サービスエージェントアドオン |
エージェントが実行できるアクションを完全に管理できるため、ニーズに合わせてカスタマーエクスペリエンスをカスタマイズできます。セキュリティを強化し、エージェントが定義された範囲内で確実に業務を行うために、次の対応を推奨します。
Agentforce サービスエージェントに、業務遂行に必要な最低限のユーザー権限を割り当てる
非公開アクションのフローに認証とアクセスコントロールを直接組み込む
各企業のリスク許容度やセキュリティ基準はそれぞれ異なり、Agentforce サービスエージェントの実装に ID を組み込む方法も一つではありません。しかし、Agentforce サービスエージェントが意図された範囲外のデータを共有しないように、認証と承認を念頭に置いてエージェントを設定してください。
Agentforce サービスエージェントは、さまざまなアクションを柔軟に実行できます。これらのアクションは、概念上、公開と非公開の 2 つのグループに分類できます。Salesforce には、アクションを公開または非公開として指定する特定の設定はありませんが、このフレームワークは、会社のセキュリティ基準を実装するときに役立ちます。
公開アクションとは、認証なしで、ID に関係なく、誰にでも代わって会社が実行することに抵抗のないアクションです。たとえば、返品ポリシーなどの公開情報に基づいている場合、ナレッジを使用して質問に回答アクションは公開アクションと見なされる可能性があります。注文履歴の参照についても、リクエストした人の身元確認を行わずに実行できるのであれば、公開アクションです。
非公開アクションでは、認証やメッセージセッションでの識別情報の共有など、会社のコンフォートレベルに応じて、リクエストした人の身元確認を要求します。個人の予約情報の更新、購入、サポート契約に基づいたサービス要求などは、すべて非公開アクションの例です。Agentforce サービスエージェントが非公開アクションを完了するには、アクションをトリガーするユーザーにアクションへのアクセス権があり、ユーザーの ID を確実に確認する必要があります。
Agentforce サービスエージェントには、一般的なサービスケースを解決するエージェントを構築するために使用できるトピックとアクションのオプションが用意されています。[Case Management] (ケース管理)、[Customer Account Management] (顧客アカウント管理)、[Reservation Management] (予約管理)、[Delivery Issues] (配送の問題)、[Order Inquiries] (注文の照会) トピックには、すべて非公開アクションが含まれています。非公開アクションを動作させるには、会社の認証基準に従って設定する必要があります。
セキュアでない可能性のある Agentforce サービスエージェントが有効化されるのを防ぐため、イネーブルメント目的で提供される非公開アクションは、それらのアクションの実行に必要なシステムに接続するように設定されていません。その場合でも、Agentforce サービスエージェントは、非公開アクションを本当に実行したかのように会話で回答します。たとえば、実際には完了していなくても、エージェントはメールアドレスの更新が完了したとユーザーに回答します。
Agentforce サービスエージェントのセキュリティを強化するために、ユーザーに代わって非公開アクションを行う前に、エージェントがやり取りするユーザーの ID を確認することを義務付けることを検討してください。
会話の範囲外で認証プロセスを処理する二要素認証などの技術を使用してユーザーの ID を確認することを推奨します。チャット内で ID 情報を共有することは安全な確認方法ではありませんが、選択するアプローチは、リスク許容度とセキュリティ基準によって異なります。
ユーザーの ID が確認されたら、その確認を関連付けられた MessagingSession レコードに保存できます。非公開アクションを完了する前に、Agentforce サービスエージェントはユーザーの ID と権限を確認するために MessagingSession レコードを参照することができます。このプロセスは非公開アクションのフローに直接組み込むことができます。
非公開アクションを実行できる Agentforce サービスエージェントを作成する場合、リスクを軽減する方法を検討することが重要です。使用事例は多様ですが、次の主要なガイドラインに留意してください。
|
ガイドライン |
詳細 |
|
最小限の権限の原則に従う |
|
|
堅牢なアクセスコントロールを実装する |
|
|
セキュアなアクションを設計する |
|
次のフローチャートは、Agentforce サービスエージェントと非公開アクションのコンテキストで認証を管理する方法の概要です。このフローチャートのコンテキストでは、「コミュニティ」は認証されていない公開メッセージングチャネルを表し、「ポータル」はコミュニティの会話から派生した認証されたセッションを表します。
Agentforce サービスエージェントを非公開アクションを完了するように設定するには、会社の基準に従って、やり取りするユーザーの ID を確認するようにします。
|
サービスエージェントは、Lightning Experience で利用できます。 |
|
利用可能: Enterprise、Performance、Unlimited、Developer Editions with the Einstein for Service、Einstein Platform、または Agentforce サービスエージェントアドオン |
Agentforce のサービスエージェントは、複数のメッセージング構成でリリースできます。
エクスペリエンスサイトにリリースされた、認証ユーザーに限定されたアプリケーション内および Web チャネル用のメッセージング
Salesforce 以外の独自の認証メカニズムを持つカスタムサイトまたはアプリケーションにリリースされた、アプリケーション内および Web チャネル向けのメッセージング
Apple Messages for Business のような、拡張されたサードパーティのメッセージングチャネル
いずれの構成においても、エージェントが実行するアクションを完全に制御することができます。定義したパラメーター内で Agentforce サービスエージェントが動作するように、エージェントのアクションを管理および制限する方法を慎重に検討してください。会社のポリシーによっては、Agentforce サービスエージェントがすべてのアクション、あるいは非公開アクションを実行するときに、真の認証を必要としないことを決定する場合もあります。
認証済みユーザーに制限されたエクスペリエンスサイトに Agentforce サービスエージェントがリリースされると、各 Agentforce メッセージングセッションに自動的に有効で認証済みの AuthSession が追加されます。ユーザーの取引先 ID と取引先責任者 ID は分かっているため、これらの値を MessagingSession レコードのそれぞれの項目に割り当てることは比較的簡単です。
完了する前に、これらの値が割り当てられていて、識別された AuthSession が有効であることを確認するように、各非公開アクションを設定する必要があります。
Salesforce の外部で独自の認証メカニズムを持つカスタムサイトまたはアプリケーションに Agentforce サービスエージェントがリリースされる場合、Agentforce メッセージングセッションを MessagingSession レコードに対応付ける必要があります。
[ユーザー検証] 機能は、カスタムサイトまたはアプリケーションでユーザー識別子をセキュアに渡すことを可能にし、そのユーザー識別子が MessagingEndUser レコードに保存するために役立ちます。たとえば、メールアドレスを識別子として使用する場合、MessagingEndUser レコードのメールアドレスを解析してユーザーの ID を確認するように非公開アクションを設定できます。
この認証管理方法は認証された AuthSession を自動的に追跡しないため、認証後に認証を直接的に無効にする方法はありません。認証はトークンに埋め込まれている有効期限に達するまで有効です。会社の基準に従って有効期限を定義してください。
Agentforce サービスエージェントが Apple Messages for Business などの拡張サードパーティメッセージングチャネルにリリースされる場合、Agentforce サービスエージェントが非公開アクションを実行するには、認証を対話のフローに組み込む必要があります。
|
認証方法 | 手順 |
チャネル識別子を使用したユーザーの認証 |
会社のポリシーによっては、チャネル固有の識別子を認証に使用することができます。この方法にはリスクが伴います。チャネル固有の識別子を認証に使用するということは、認証をチャネルプロバイダーに委任することを意味します。そのため、この方法を採用する前に、認証要件を慎重に検討する必要があります。 認証をチャネルプロバイダーに委任する決断をした場合は、チャネルオブジェクトリンクを実装して取引先責任者を関連付けられたメッセージングセッションに自動的に関連付けるようにします。非公開アクションが完了前にこの情報を参照するように設定できます。 |
|
サイドチャネルを介したユーザーの認証 |
認証にチャネル固有の識別子を使用できない場合は、サイドチャネルを介してユーザーを認証するように Agentforce サービスエージェントを設定する必要があります。チャネルプロバイダーの識別子に依存しなくなっても、会話はそのプロバイダーによって保護されます。そのチャネルで悪意のあるユーザーがなりすましや他のユーザーの ID を偽装することが可能な場合、サイドチャネルでセッションが認証された後にも同じことをする可能性があります。 サイドチャネルを介したユーザーの認証は、既存の Web 認証メカニズムに認証を委任する、エクスペリエンスサイトユーザーの認証のバリエーションです。これを実装するには、必要な認証を実装するサイトにクエリパラメーターを介して MessagingSessionId を渡します。次に、そのサイトのサーバーがその MessagingSessionId に対する認証要求を受信したときに、Salesforce API を使用して MessagingSession レコードを認証メカニズムから取得された識別子で更新するように設定する必要があります。 |
|
メッセージコンポーネントを使用した認証 |
Apple Messages for Business などの拡張されたサードパーティのメッセージチャネルでは、Agentforce サービスエージェントはメッセージングエンドユーザー (MEU) に認証メッセージングコンポーネントを送信できます。このプロセスでは、MEU はデバイス上で認証プロンプトを受け取り、Facebook または Google などの標準的な認証プロバイダーを使用して認証を完了できます。また、カスタム認証プロバイダーを設定することもできます。 |
ユーザーが認証されたら、非公開アクションはセッション ID を使用して、関連付けられた取引先 ID と取引先責任者 ID に基づいて非公開アクションの範囲を適用できます。これにより、アクションが意図したとおりに制限されます。
たとえば、注文情報を参照する前に MessagingSession レコードから取引先責任者 ID を取り込むように Get Order By Order Number (注文番号で注文を取得) アクションを設定できます。
//Get Contact from Session (セッションから取引先責任者を取得)
SELECT Id, contactId__c FROM MessagingSession
WHERE sessionId =: SessionId
//Get orders based on Contact from Session (セッションから取引先責任者に基づいた注文の取得)
SELECT Id, Status FROM Order
WHERE ContactId =: ms.contactId__c AND orderNumber =: orderNumber
他の非公開アクションも同様に設定して、Agentforce サービスエージェントが認証されたユーザーに自分のデータのみを提供できるようにすることができます。
セキュアな Agentforce サービスエージェントの実装の詳細は、エージェントがリリースされる場所やユーザー認証ポリシーによって異なります。基礎となるパターンを理解するために、例を見てみましょう。
|
サービスエージェントは、Lightning Experience で利用できます。 |
|
利用可能: Enterprise、Performance、Unlimited、Developer Editions with the Einstein for Service、Einstein Platform、または Agentforce サービスエージェントアドオン |
Agentforce サービスエージェントがエクスペリエンスサイトにリリースされる場合、エージェントと対話しているユーザーを再認証することが必要になる場合があります。そのような場合、セッション内の認証を呼び出すことができます。
会話内でパラメーター化された URL を提供してユーザーを認証できます。パラメーター化された URL は、Experience Cloud ポータルのセキュアなメソッドを参照する必要があります。パラメーター化された URL を送信する前に外部認証の準備を行うには、次のカスタム項目を使用して MessagingSession オブジェクトを設定します。
|
項目 |
初期値 |
定義 |
|
AuthSessionId |
NULL |
この MessagingSession に現在リンクされているAuthSession があるか識別します。メッセージングセッションが認証されているかどうかを示します。 |
|
AuthRequestTime |
DateTime.Now() |
認証が要求されたときに保存され、指示された期間外で MessagingSession に ID が割り当てられないように制限し、外部認証が許可される期間を制御できます。 |
|
AccountId |
NULL |
Experience Cloud ポータルで認証された取引先責任者に対する認証済みセッションに、認証済みセッションにリンクされた取引先が割り当てられるようにします。 |
|
ContactId |
NULL |
認証されたセッションにリンクされた取引先責任者が、Experience Cloud ポータルで認証された取引先責任者に相対的に割り当てられるようにします。 |
パラメーター化された URL を処理する Apex メソッドでは、MessagingSession.SessionKey 項目を使用できます。このグローバル一意識別子 (GUID) は、Status = “Active” である MessagingSession レコードにおいて一意です。このメソッドは、次のクエリを使用して関連する MessagingSession レコードを検索します。
SELECT Id, Conversation.ConversationIdentifier, Status, FROM MessagingSession
WHERE SessionKey = '1db8a0ab-aae4-4ed9-b6d5-3e7fe85b9574' AND Status = 'Active'
AND AuthSessionId__c = NULL
AND AuthRequestTime__c < DateTime.Now.AddMinutes(-10)
AND AuthRequestTime__c > DateTime.Now();
このクエリがレコードを返した場合、そのレコードはユーザーが過去 10 分間に認証された場所でのAgentforce サービスエージェントとの会話を表します。返されたレコードを更新して、Experience Cloud ポータルの現在の AuthSession との関係を表すことができます。たとえば、MessagingSession が ms : として定義されている場合、
ms.AuthSessionId__c = SessionManagment.GetCurrentSession().get('SessionId');
User authUser = [SELECT Id, ContactId, AccountId from User WHERE Id = :UserInfo.getUserId()];
ms.AccountId__c = authUser.AccountId;
ms.ContactId__c = authUser.ContactId;
ms.commit();
Agentforce サービスエージェントが、非公開アクションを実行するときにユーザーの ID を確認するために必要な情報を取得しました。AuthSession の ID も含まれており、対応するポータルセッションでの会話が終了した直後に解除できます。
Maintain Trust with Agentforce Actions (英語)
003876435

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.