アブストラクト

ソフトウェアのパラダイムは、直接操作からゴール指向の委任に移行しつつあります。この変革の最前線にあるのは、AI エージェントです。AI エージェントは、ユーザーに代わって理解、推論、アクションを行うことができる自律的なインテリジェントなエンティティです。このホワイトペーパーでは、AI エージェントの主な種別 (会話型、プロアクティブ、アンビエント、自律、コラボレーション) に関する技術的な探索について説明します。各タイプを定義し、CRM(顧客リレーション管理)の具体的な使用事例を示し、Salesforce Agentforce Platformでこれらのエージェントを構築するためのアーキテクチャのブループリントを提供します。また、フロー、Apex、Data 360、Agent2Agent(A2A)通信、MCP(モデルコンテキストプロトコル)の相互運用性を活用する技術例も紹介します。

AI エージェントは、環境を認識し、特定の目標を達成するためにアクションを実行するシステムです。この概念は新しいものではありませんが、強力な大規模言語モデル (LLM) の登場により、その機能が強化されました。エージェントは、その主な操作モードとインタラクションに基づいて分類できます。

定義: 会話型エージェントは、最も使い慣れた種類のエージェントです。主に自然言語インターフェース (テキストまたは音声) を介して、反応型の要求-応答方式で動作します。コア機能は、質問への回答、情報の取得、簡単なコマンドの実行など、ユーザーのインテントを理解して関連する応答を提供することです。

重要: 会話型のエージェントは、組織にとってデジタルのフロントドアです。明確に定義された反復作業の処理に優れているため、人的リソースを解放できます。有効性は、ユーザーのインテントをすばやく正確に解決し、ユーザーに代わってアクションを実行する能力によって測定されます。

定義: プロンプトを待機する会話型のエージェントとは異なり、プロアクティブなエージェントは用心深い観察者として機能します。これらは、特定のイベント、データの変更、またはシステム内の定義済みの条件によってトリガーされます。トリガーされると、ユーザーによる直接的なインタラクションを必要とせずにタスクを実行するか、ワークフローを開始します。

重要: プロアクティブなエージェントは、システムをデータのパッシブなリポジトリからビジネスプロセスのアクティブな関係者に変換します。プロアクティブエージェントは、機会やリスクが発生した際にそれを特定し、企業が重要なシグナルにリアルタイムで対応できるようにします。

定義: アンビエントエージェントとは、明示的なコマンドを必要とせずにユーザーのワークフローのバックグラウンドで継続的に動作する特定の種類のプロアクティブエージェントです。多くの場合、ユーザーは操作を意識することなくアクションを利用できます。これは、これらのアクションは、ロープロファイルを維持しながら人間の能力を強化するように設計されているためです。

重要: アンビエントエージェントの目標は、日常的な「作業」を自動化してユーザーの認知負荷を軽減することです。従業員が毎日使用するツールにシームレスに統合し、情報を自動的に取得して構造化することで、プロセスを効率化します。

定義: 自律エージェントは、複雑さの大幅な飛躍を表します。高レベルの目標が与えられ、その目標を達成するための一連のステップを独立して計画および実行できます。ユーザーは、経時的なパフォーマンスを改善するために、推論や意思決定を行ったり、アクションから学習したりできます。

**重要:**これは、真のデジタル従業員に最も近いものです。自律エージェントは、『この四半期に製造セクターで50件の新規適格リードを生成』などの複雑かつ多段階の目的を委任され、その目的達成のための計画を自律的に策定・実行することが可能です。

定義: コラボレーションエージェントは、「エージェントスウォーム」と呼ばれることが多く、複雑すぎて 1 人のエージェントでは処理できない問題を協力して解決する、特殊なエージェントの集合体です。多くの場合、「オーケストレーター」または「マスター」エージェントは、大きな ToDo を分解し、サブ ToDo を適切な専門エージェントに委任して、その出力を合成します。堅牢な Agent2Agent (A2A) 通信プロトコルでは、これを実現します。

重要: このアプローチは、人間のチームを反映したものです。複雑な問題を分解することで、各専門エージェントは独自のスキルを持つことができます。1 つはデータ分析、もう 1 つは顧客とのコミュニケーション、もう 1 つはシステムインテグレーションを専門とし、より堅牢で包括的なソリューションを実現します。

AI エージェントの分類を探索しましたが、これらの要素をどのように組み合わせて、実際のビジネスの問題を効率的かつ確実に解決するか? という重要な疑問が残ります。この章では、一般的なエージェント設計パターンのリポジトリを提供することで、この質問に答えます。各パターンは、繰り返し発生する課題に対する実績のあるソリューションであり、単純な単一目的のエージェントから、複雑なエージェントスウォームまで、あらゆるケースの設計図を提供します。

会話型エージェントは、多くの場合、組織のAI機能への玄関口です。これらは、ユーザーが自然言語を使用して ToDo を実行し、情報を取得するための主要なインターフェースとして機能する、ステートフルな複数ターンのダイアログに関与する機能によって定義されます。このセクションでは、会話型エージェントを構築するための 2 つの基本的なレシピを紹介します。1 つはメッセージングクライアントの迅速な対話型交換用、もう 1 つはメールの構造化された非同期用です。

会話型エージェントの知能は、適切なタイミングで適切なデータにアクセスし、それを基に推論する能力に由来します。このパターンは、顧客レコード、ナレッジ記事、そしてビジネスアナリティクスに接続する高度なデータ基盤に支えられています。これらのインテグレーションの完全な再利用可能なレシピは、第 4 章 インテグレーションパターンを参照してください。

問題

お客様は多くのデジタル チャネルでエンゲージし、即時、コンテキストに基づくインテリジェントな応答を期待しています従来のチャットボットはスクリプト形式か**データ ブラインドです。**そのため、パーソナライズが不十分で、早期に人間にエスカレーションされ、サービス コストが高くなる可能性があります。

コンテキスト

• 組織にマルチチャネルデジタルエンゲージメント (WhatsApp、SMS、Slack、Salesforce Experience Cloud) がある。
• 組織の顧客は、複数の言語で組織とやりとりします。
• 組織は、サービスおよび営業ワークフローを強化するために、次のようなエージェントを必要としています:
  • 信頼できるリアルタイムの顧客データから取得
  • ガードレールとコンプライアンス要件の遵守
  • 必要な場合にのみ人間のエージェントにエスカレーションする

主要なコンポーネント

• チャネルの抽象化: Service Cloud の拡張チャット (旧称: アプリ内および Web のメッセージング) を使用すると、エージェントは 1 つの環境を介して複数のチャネルで通信できます。
• Agentforce サービスエージェント: エージェントの動作と目的は、次のコンポーネントで定義されます。
  • トピックと手順: ユーザーと直接やりとりするためのエージェント人格と会話の目的を定義します。これには、そのコアミッション (「あなたはカスタマーサポートの問題を解決するエキスパートです」など)、共感的でプロフェッショナルな口調を保つための手順、処理が許可されている問い合わせの範囲に関する明確なガードレールが含まれます。
  • アクション: エージェントが顧客の問題をリアルタイムに診断および解決するために使用するサービス指向のアクション。これらのツールは、注文の状況の確認、ソリューションのKnowledgeベースの検索、新しいサポートケースの作成などのタスクを対話型インターフェースから直接実行するように設計されています。
  • ガードレール: ガードレールは、エージェントの動作を制約する設定可能なルールとランタイムチェックのセットとして機能します。プロンプトを傍受し、エージェントの提案されたアクションを検証し、最終応答を絞り込んで有害なコンテンツを防止し、ビジネスルールを適用し、エージェントが指定された範囲内で業務を行うことができる安全レイヤーとして機能します。
  • プロンプトテンプレート: 差し込み項目または Data 360 RAG Retrievers のセマンティックデータを介してライブ CRM データが動的に入力される再利用可能なテンプレート。これらのテンプレートにより、エージェントはブランド情報に基づいたコンテキストのコンテンツを生成できます。一方、Einstein Trust Layerでは、指示がLLMに送信される前に機密情報を安全にマスキングできます。
• Data 360
  • Data 360コンポーネント(DLO、DMO、ベクトル ストア、RAG取得など)により、構造化された顧客レコードから非構造化Knowledge記事まで、関連するすべてのエンタープライズ データをエージェントに一元化されたビューで表示し、正確でコンテキストに基づいた応答を実現します。
• Service Cloud
  • CRM データ: エージェントを完全なケース履歴に接続し、取引先の詳細、取引先責任者レコード、エンタイトルメントに関する重要なコンテキストを提供します。
  • Live Agent キュー: 完全な会話コンテキストが差し込まれた人間のサービス担当者へのエスカレーションとルーティングのサポート

接触

1. 組織の顧客がチャネルを介して会話を開始する。
2. メッセージは Agentforce に転送され、Agentforce によって範囲（トピック）が決まり、ガードレールが適用されます。
3. AIはプロンプト テンプレートを使用して応答を作成しますが、フローまたはApexはバックエンド ロジックをトリガーする可能性があります。
4. コンテキストは、Data 360オブジェクト、ベクトルストア、CRMからRAG retrieverを使用して取得されます。
5. AI がコンテキストに応じた回答を返します。
6. AI で解決できない場合、会話は Service Cloud Live Agent にエスカレーションされます

Trade-Offs

関連パターン

グリーターパターン: 自然言語を使用してユーザーのインテントを理解し、ユーザーを適切なサービス担当者に転送するシンプルで実装が容易なパターン

オペレーターパターン: グリーターを基盤として構築され、必要に応じてインテントをネゴシエートしながら、適切なスペシャリストAIエージェントまたは人間のサービス担当者に要求を転送します。

オーケストレーターパターン: AI エージェントスウォームを管理します。ユーザーの要求を受信し、インテントを判断して計画を作成し、必要なデータを 1 人以上のスペシャリストエージェントに渡してから、ユーザーの回答を集計します。オペレーターとは異なり、最初の窓口として機能し続けます。

問題

顧客は主にメールベースの非同期会話を使用しますが、これはアウトリーチに最も適した方法です。組織はこれらの顧客にメールでリーチする必要がありますが、セールスディベロップメント担当はSLA内でインバウンドメールに返信できず、リードを失います。さらに、従業員は不適格なリードに時間を費やします。

コンテキスト

• あなたの組織には、リードエンゲージメントの主なチャネルとしてメールがあります。
• あなたのSDRは、スケールでリードを評価するキャパシティに限りがあります。
• あなたの営業プロセスでは、リードがSDRやビジネス開発担当者（BDR）と会う前に、マルチTouchによるリードナーチャリングが行われます。
• あなたの組織は、セールスとサービスを強化するために、次のようなエージェントを必要とします。
  • リアルタイムのセールスイネーブルメント、セールス商品、マーケティングデータから取得
  • ガードレールとコンプライアンスを遵守します。
  • リード評価条件に基づいてミーティングをスケジュールする

キーコンポーネント

• メールチャネル: 受信メッセージの取得、そのコンテンツと添付ファイルの解析、スレッドの継続性の維持を処理して非同期の会話を可能にします。
• Agentforce SDR Agent: エージェントの動作と目的は、次のコンポーネントで定義されます。
  • トピックと手順: 会話を通じて受信リードを引き付け、評価するためのエージェントの使命を定義します。これには、見込み客のニーズを理解し、主要な評価データ (予算、権限、スケジュールなど) を収集し、取引先責任者とのミーティングのスケジュールなど、明確な次のステップに向けて会話を導く手順が含まれます。
  • アクション: エージェントがリードライフサイクルを管理できるようにする特殊なセールスアクション。これらのツールは、リードデータの強化、テンプレート化されたフォローアップメールの送信、カレンダーシステムとの統合によるディスカバリーコールの予約など、SDR のコアタスクを実行するように設計されています。
  • ガードレール: ガードレールは、エージェントの動作を制約する設定可能なルールとランタイムチェックのセットとして機能します。プロンプトを傍受し、エージェントの提案されたアクションを検証し、最終応答を絞り込んで有害なコンテンツを防止し、ビジネスルールを適用し、エージェントが指定された範囲内で業務を行うことができる安全レイヤーとして機能します。
  • プロンプトテンプレート: 差し込み項目または Data 360 RAG Retrievers のセマンティックデータを介してライブ CRM データが動的に入力される再利用可能なテンプレート。これらのテンプレートにより、エージェントはブランド情報に基づいたコンテキストのコンテンツを生成できます。一方、Einstein Trust Layerでは、指示がLLMに送信される前に機密情報を安全にマスキングできます。
• Data 360
  • Data 360コンポーネント(DLO、DMO、ベクトル ストア、RAG取得など)により、構造化された顧客レコードから非構造化Knowledge記事まで、関連するすべてのエンタープライズ データをエージェントに一元化されたビューで表示し、正確でコンテキストに基づいた応答を実現します。
• Sales Cloud
  • CRM データ: エージェントを完全なケース履歴に接続し、取引先の詳細、取引先責任者レコード、エンタイトルメントに関する重要なコンテキストを提供します。
  • Schedule meeting between customer and SDR (顧客と SDR 間のミーティングのスケジュール): SDR Live Agent ハンドオフは、ToDo とミーティングのスケジュール (次のアクション) を使用してライブミーティングを設定するように設定できます。
  • 活動ログ: 行動、ToDo、Eメール活動を取得し、SDRエージェントのやりとりの結果としてリード、取引先、商談に関連付けます。

接触

1. 顧客はチャネルを通じてメールを送受信し、そのチャネルはAgentforceにルートされます。
2. Agentforce は、トピック、アクション、ガードレールを適用してインテントを解析します。
3. Agentforce は、CRM および Data 360 コンテキストで強化されたプロンプトテンプレートを使用して、コンテキストに応じた応答の下書きを作成します。
4. 複数ターンのメールの会話は、解決またはポリシーガイドラインまで続行されます。
5. 評価済みのリードの場合、Agentforce はミーティングをスケジュールし、CRM を更新します。
6. インテントがAIのスコープを超える場合、Agentforceは人間のサービス担当者による対応を求めてSales Cloud SDRにエスカレーションします。

トレードオフ

関連パターン

アンサー ボット パターン:キーワードだけでなく、生成AIを使用して自然言語を理解し、Knowledgeを取得するセルフ サービスの効果的なパターン

前のセクションの会話型エージェントはユーザーコマンドへの反応に優れていますが、プロアクティブなエージェントは質問されることなく行動するというパラダイムシフトを表しています。このセクションでは、Salesforce の外部と内部の両方で発生するデータとイベントを自律的に監視するエージェントを作成するためのアーキテクチャパターンについて説明します。

問題

組織が Salesforce 内外で重要なビジネスイベントを生成しています。それらはアプリケーションや部門に散在しているため、タイムリーかつ文脈に沿ったアクションに変換するのが困難です。

コンテキスト

• ビジネスプロセスは、CRM、支払処理、配送、マーケティングオートメーション、テレメトリ、CDP の複数のシステムにまたがっています。
• 組織のイベントは 24 時間 365 日発生しますが、従業員の対応可能状況は営業時間外に制限されます。システムは常時稼働していますが、人間は常に活動しているわけではありません。
• イベントはコンテキスト認識が欠如しており、Salesforceで提供される顧客のコンテキストがないため、複数のステップで情報を統合する必要があります。現在、実装は個別の複雑な自動化として存在するか、手動で実行されます。
• 人間は、さまざまな形式でデータを収集し、バラバラのイベントに_インテリジェント_に対応するコンパイラとして機能します。
• 対象となるアクションは複数のシステムに適用されます。

主要コンポーネント

• イベントソース
  • 外部データが Data 360 に取り込まれた後にトリガーされるデータアクションイベント
  • Salesforce Pub/Sub API を使用してイベントを Salesforce に送信できるサードパーティまたは Salesforce Heroku MCP サーバー
  • Salesforce Pub/Sub API を介してイベント通知を送信できる外部アプリケーション
• オプションのミドルウェア: MuleSoft または Data 360 (変換用)
• Agentforce Agent: エージェントの動作と目的は、次のコンポーネントによって定義されます。
  • **トピックと手順：**エージェントのコア ミッションとそのトリガーを指定します。これには、主目的の定義も含まれます（たとえば、「すべての優先度の高いケースを監視し、SLA 違反を防止する」など）。エージェントが ToDo を開始するためにリスンする必要がある特定のイベントまたはデータ条件が含まれる
  • アクション: 外部イベントに応答するように設計されたイベントトリガーおよびスケジュール済みアクション。これらのアクションは日常業務では自律的に動作しますが、多くの場合、人の介入を伴うワークフローを調整し、レビュー、承認、または人の判断が必要なシナリオの処理のためにユーザーにエスカレーションする機能が含まれます。
  • ガードレール: ガードレールは、エージェントの動作を制約する設定可能なルールとランタイムチェックのセットとして機能します。プロンプトを傍受し、エージェントの提案されたアクションを検証し、最終応答を絞り込んで有害なコンテンツを防止し、ビジネスルールを適用し、エージェントが指定された範囲内で業務を行うことができる安全レイヤーとして機能します。
  • プロンプトテンプレート: 差し込み項目または Data 360 RAG Retrievers のセマンティックデータを介してライブ CRM データが動的に入力される再利用可能なテンプレート。これらのテンプレートにより、エージェントはブランド情報に基づいたコンテキストのコンテンツを生成できます。一方、Einstein Trust Layerでは、指示がLLMに送信される前に機密情報を安全にマスキングできます。
• Data 360
  • 外部システムで生成され、営業担当に送信されるイベントデータを保存し、ストリーミングまたはリアルタイムのインサイトを変換および構築する DLO や DMO などの Data 360 コンポーネント
  • 計算済みインサイト、ストリーミングインサイト、リアルタイムインサイトは、顧客に関する即時の関連データをエージェントに提供します。これにより、エスカレーションが軽減され、先制的な問題解決が可能になります。データグラフにより、さまざまなデータソースからのリレーションとインサイトがプロアクティブに表示され、顧客のエンゲージメント、活動、プロファイルに関連するパターンや異常を早期に検出できます。
  • Data 360ベクトルストアとRAGリトリーバーによって、関連するすべての企業データと非構造化ナレッジ記事の統合ビューがエージェントに提供され、応答が正確かつ文脈に即していることが保証されます。
• イベント対象
  • 従業員への積極的な通知または顧客への連絡
  • エージェントに拡張可能 (「アンビエントエージェント」および「自律エージェント」パターンを参照)

接触

1. 外部システムで重大な変更が発生します。
2. 外部システムがイベントを生成し、API (プラットフォームイベントを作成) または Pub/Sub API を介して Salesforce イベントバスに公開するか、イベントデータが Data 360 にストリーミングされます。
3. イベントの登録者がトリガーされます。フローがトリガーされます。
4. フローはイベントデータを使用してエージェントアクションを呼び出します。エージェントは適切なアクション方針を決定し、実行します。
5. 結果は通知またはワークフローがトリガーされます。通知はコラボレーションツール (Slack など) でユーザーに配信されます。タスクまたはイベントも生成されます。さらに、アクションで外部システムを呼び出すことができます。そのため、イベントは失われることなく、積極的に実行され、シグナルが発せられ、アクションが起こされることで、検出にかかる人的負担や複雑な自動化が不要になります。

トレードオフ

関連パターン

審査および陪審パターン: このパターンと組み合わせて使用することで、複数の「陪審員」エージェントと「審査」エージェントを活用して合同審査を行い、AIを駆使した意思決定の正確性と信頼性を確保できます。

モデル パターン:このパターンでは、複数のエキスパート エージェントの多様な視点を採用して、より豊富なインサイトを生成します。これにより、プロアクティブなAIのインテリジェントな応答を補完できます。

問題

組織の Salesforce エコシステムではシグナルが常に生成されますが、ビジネスロジック、ガバナンス、人間が優先順位を付けて行動する必要があるため、タイムリーなコンテキストアクションに変換できません。多くの場合、シグナルは処理されずに失われ、機会損失につながります。

コンテキスト

• 組織で 1 つ以上の Salesforce クラウド (セールス、サービス、マーケティング、コマース、健康、製造など) を使用している。
• 単純なルーティングやルールベースのトリアージを超えたインテリジェントなトリアージが必要です。組織では、何百もの複雑なビジネスルールを管理しています。
• イベントへのリアルタイムまたはほぼリアルタイムの応答が必要です。
• 場合によっては、最も特権のあるシステム管理者がシグナルが表示されないためにチェーンの最も弱いリンクになることがあります。

主要コンポーネント

• イベントソースレイヤー
  • 低レベルのプラットフォーム活動からの CRM データ、プラットフォームイベント、変更データキャプチャ (CDC) データ、リアルタイムイベント監視 (RTEM) データ
• Data 360
  • CRM イベントまたはプラットフォームイベントによって生成されたイベントデータを保存する DLO や DMO などの Data 360 コンポーネント。ストリーミングインサイトやリアルタイムインサイトを変換および構築します。
  • 計算済みインサイト、ストリーミングインサイト、リアルタイムインサイト は、顧客、従業員の活動、またはシステムのメタデータの変更に関する即時の関連データをエージェントに提供します。これにより、エスカレーションが軽減され、先制的な問題解決が可能になります。このリアルタイムの状況把握により、エージェントはガバナンスやコンプライアンスにおける運用スループット向上のための適時な介入を実施できるようになります。
  • データグラフにより、さまざまなデータソースからのリレーションとインサイトがプロアクティブに表示され、顧客のエンゲージメント、活動、プロファイルに関連するパターンや異常を早期に検出できます。
  • Data 360ベクトルストアとRAGリトリーバーによって、関連するすべての企業データと非構造化ナレッジ記事の統合ビューがエージェントに提供され、応答が正確かつ文脈に即していることが保証されます。
• Agentforce Agent: エージェントの動作と目的は、次のコンポーネントによって定義されます。
  • トピックと手順: Salesforce 内のデータの変更に基づいてビジネスルールを適用し、プロセスを自動化するエージェントの使命を指定します。エージェントの目的（「交渉フェーズに達する前に主取引先責任者とすべての商談を更新する」など）と、エージェントをトリガーする特定のレコード作成やフィールド更新などが定義されます。
  • アクション: 内部 Salesforce イベントに応答するように設計されたイベントトリガーおよびスケジュール済みアクション。これらのアクションは日常業務では自律的に動作しますが、多くの場合、人の介入を伴うワークフローを調整し、レビュー、承認、または人の判断が必要なシナリオの処理のためにユーザーにエスカレーションする機能が含まれます。
  • ガードレール: ガードレールは、エージェントの動作を制約する設定可能なルールとランタイムチェックのセットとして機能します。プロンプトを傍受し、エージェントの提案されたアクションを検証し、最終応答を絞り込んで有害なコンテンツを防止し、ビジネスルールを適用し、エージェントが指定された範囲内で業務を行うことができる安全レイヤーとして機能します。
  • プロンプトテンプレート: 差し込み項目または Data 360 RAG Retrievers のセマンティックデータを介してライブ CRM データが動的に入力される再利用可能なテンプレート。これらのテンプレートにより、エージェントはブランド情報に基づいたコンテキストのコンテンツを生成できます。一方、Einstein Trust Layerでは、指示がLLMに送信される前に機密情報を安全にマスキングできます。
• イベント対象
  • 従業員に積極的に通知したり、顧客にリーチしたりします。
  • 他のエージェントをコールできる拡張性(環境AIおよび自律AIパターンを参照)

接触

1. CRM レコードの更新、メタデータの変更、Data 360 からトリガーされたデータアクションなど、内部システム内で顕著な変更が発生します。
2. 内部システムがイベントを発行し、API (プラットフォームイベントを作成) または Pub/Sub API を介して Salesforce イベントバスに公開するか、イベントデータが Data 360 にストリーミングされます。
3. イベントの購読者がトリガーされ、フローまたは Apex がアクティブ化されます。
4. 有効化されたフローまたは Apex がエージェントアクションを呼び出します。
5. 結果は通知またはワークフローがトリガーされます。通知はコラボレーションツール (Slack など) でユーザーに配信されます。タスクまたはイベントも生成されます。さらに、アクションが外部システムを呼び出すことができます。
6. そのため、イベントは失われることなく、積極的に実行され、シグナルが発せられ、アクションが起こされることで、検出にかかる人的負担や複雑な自動化が不要になります。

トレードオフ

関連パターン

リスナー/フィードパターン: リスナーパターンと組み合わせて、内部 Salesforce イベントに基づいてプロアクティブなアクションをトリガーできます。

データ スチュワード パターン:プロアクティブなAIがデータ スチュワードを使用して、内部イベントに応答するときにデータの品質と一貫性を確保できる

Zen Data Gardener パターン: 内部イベントまたは定期的なイベントによってトリガーされる、スケジュール済みのプロアクティブなデータグルーミングおよび標準化

会話チャネルで対話形式で応答するエージェントから開始し、特定のイベントに応答するエージェントへと進みました。プロアクティブなエージェントのイベント駆動型モデルを超えて、アンビエントエージェントは直接的なインタラクションからプロアクティブなバックグラウンド支援へのパラダイムシフトを表します。バックグラウンドでデジタル環境を監視するヘッドレスエージェントです。ユーザーの活動やデータストリームからコンテキストを認識し、他のエージェントや人間と連携して ToDo を完了したり、インサイトを表示したり、ガイダンスを提供したりするためのシステムの「目と耳」として機能します。

問題

組織のビジネス活動では、価値のある情報 (通話、ミーティング、チャット、センサーデータなど) が継続的に生成されますが、このデータはキャプチャや分析を行わずにリアルタイムで消去されます。人間がこれらのインタラクションを手動で文書化するまでに、重要なインサイトが失われ、タイムリーな介入の機会も過ぎてしまいます。組織は、リアルタイムで必要なアクション可能なインテリジェンスの大部分を見落とし、一時的なストリームに埋もれてしまい、ギャップ、コーチングの機会の喪失、完全なコンテキストのない意思決定につながります。

コンテキスト

• ビジネス活動では、音声およびビデオ会議、ライブチャット、センサーテレメトリ、画面活動、トランザクションデータなど、さまざまなソースから継続的なストリームが生成されます。
• これらのストリームに効果的に対応し、アクションを実行するには、リアルタイムまたはほぼリアルタイムのインサイト (数時間や数日ではなく数秒や数分以内) が必要です。
• 手動のドキュメント作成プロセスは、コンプライアンスと更新頻度が低く、従業員の認知的負担が高く、重要な情報のキャプチャが不完全であるという特徴があり、うまく機能していません。
• 音声、動画、画面共有、チャット、その他のメタデータからのデータを組み合わせて、インタラクションやイベントの完全かつ正確なコンテキストを作成するマルチモーダル理解が必要です。
• リアルタイムのコーチングとアラートのための即時分析と、インタラクション後の概要と長期的なトレンドの特定のための履歴分析の両方が必要です。
• データストリーム内のさまざまな時間枠の順序、タイミング、遷移、パターンの理解など、分析には一時的なコンテキスト (エピソードメモリ) が不可欠です。

キーコンポーネント

• ストリームソース
  • 音声と動画: ビデオ会議ツール (Slack Huddle、Zoom、Google Meet、Microsoft Teams など) および電話システム
  • コラボレーションツール: Slack、Teams、その他
• ストリームキャプチャコネクタ
  • ネイティブ SDK: リアルタイムのストリームセグメントまたはトランスクリプトをサポートするトランスクリプトまたはメッセージを取得するのに役立つベンダー提供の SDK
• (省略可能) ストリーム処理レイヤー
  • 音声ストリームの場合、リアルタイムでトランスクリプトが利用できない際には、音声をテキストに変換する機能が必要です。Amazon Transcribe などの管理プロバイダーを使用することもできます。
  • その他のデータストリームの場合、必要に応じて Data 360 や Apache Flink などのストリーム処理エンジン
• Data 360
  • イベントデータを保存する DLO や DMO などの Data 360 コンポーネント。ストリーミングまたはリアルタイムインサイトの変換と構築を行います。
  • 計算済みインサイト、ストリーミングインサイト、リアルタイムインサイトは、顧客、その活動、重要なインサイトに関する即時の関連データをエージェントに提供します。これにより、エスカレーションを軽減して、プリエンプティブな問題解決が可能になります。このリアルタイムの状況認識により、エージェントはタイムリーな介入とパーソナル化されたサポートを従業員に提供でき、顧客満足度と業務スループットを最適化できます。
  • 顧客データを保存し、リアルタイムのインサイトを変換および構築する DLO や DMO などの Data 360 コンポーネント
  • Data 360ベクトルストアとRAGリトリーバーによって、関連するすべての企業データと非構造化ナレッジ記事の統合ビューがエージェントに提供され、応答が正確かつ文脈に即していることが保証されます。
• **Agentforce エージェント。**このパターンは、ライブ通話トランスクリプトやビデオフィードなど、連続的なデータストリームを監視するアンビエントエージェントに焦点を絞ります。リアルタイムリスナーとして機能し、発生した非構造化データを解釈します。たとえば、ライブ通話を聞いているエージェントがデータ検出エージェントを呼び出して、会話で共有された新しいコンテキストに基づいてリードのレコードを強化できます。このようなヘッドレスエージェントの例を次に示します。
  • **フィードバック エージェント。**エージェントの動作と目的は、次のコンポーネントで定義されます。
    • トピックと手順: 会話ストリームを分析し、構造化されたフィードバックとパフォーマンス評価指標を抽出するエージェントの主な任務を定義します。これには、顧客のセンチメントを監視し、主要な商品や競合他社へのメンションを特定し、人間のエージェントが会社のベストプラクティスやセールスプレイブックに従っているかどうかを評価する手順が含まれます。
    • アクション: 非構造化会話データをアクション可能なビジネスインテリジェンスに変換するアクション。これらのアクションにより、エージェントは「フィードバック概要」レコードの作成、商品機能要求の記録、マネージャーによるレビューに否定的なセンチメントを示す電話のフラグ設定、主要な評価指標に対するエージェントの全体的なパフォーマンスを追跡するダッシュボードの更新を行うことができます。
    • ガードレール: ガードレールは、エージェントの動作を制約する設定可能なルールとランタイムチェックのセットとして機能します。プロンプトを傍受し、エージェントの提案されたアクションを検証し、最終応答を絞り込んで有害なコンテンツを防止し、ビジネスルールを適用し、エージェントが指定された範囲内で業務を行うことができる安全レイヤーとして機能します。
    • プロンプトテンプレート: 入力を受信し、LLM で生成された出力を提供できる構造化されたテンプレート化された LLM 命令
• Ambience targets (雰囲気目標)
  • ビデオ通話やデスクトップアプリケーションなど、エージェントとユーザーがいる場所でユーザーに通知

接触

1. ストリームが有効化されると (ユーザーがビデオ通話に参加した場合など)、エージェントは自分自身をオブザーバーとして添付します。
2. エージェントはストリームデータの受信を開始し、インクリメンタルにインテントを検出し、意思決定を行いアクションを呼び出します。
3. エージェントはインテントに基づいてコンテキスト化し、追加データ (構造化または非構造化) を取得します。
4. エージェントは、ユーザーを促すことなくジャストインタイムのリアルタイム応答を提供します。営業電話の異議申し立てを検出し、異議申し立てを処理するための重要な情報を提供できます。
5. エージェントは、統合された概要とアクションをまとめ、他のエージェントやユーザーと共有できます。

トレードオフ

関連パターン

リスナー/フィードパターン: リスナーパターンと組み合わせることで、会話およびユーザー操作データのリアルタイムストリームを処理し、関連するコンテキストとインサイトを表示できます。

Interrogator パターン: このパターンと組み合わせて使用することで、ストリーム内の複数のソースからコンテキストを収集し、質問に回答できます。

問題

従業員は、メール、カレンダー、通話、およびアプリケーション全体で毎日何百ものビジネスクリティカルな活動を実行しますが、これらの活動は手動で記録されるまで組織システムには認識されません。このようなことはめったにありません。この活動ブラインドは、CRM データが不完全であり、AI モデルにインテリジェントなおすすめに必要なシグナルがなく、マネージャーが顧客エンゲージメントをリアルタイムで把握できないことを意味します。手動の活動記録は、生産性に対する負担となる一方で、実際の業務の大部分を捉えられていません。

コンテキスト

ストリームオブザーバーと同様に、アクション可能な ToDo を提供したり、ユーザーの代わりにアクションを実行したりするデータおよびコンテンツオブザーバーです。

主要なコンポーネント

• データレイヤー
  • CRM データ: エージェントにコンテキストを提供する CRM で使用できる顧客データ (たとえば、ユーザーが商談ページを表示しているときに、エージェントは商談および関連付けられた取引先に関する情報を CRM から取得できます)。
  • さまざまなソースから取り込まれた関連する顧客データを保存する DLO や DMO などの Data 360 コンポーネント
  • 計算済みインサイト、ストリーミングインサイト、リアルタイムインサイトは、顧客、その活動、重要なインサイトに関する即時の関連データをエージェントに提供します。これにより、エスカレーションが抑制されるとともに、先手を打った問題解決が可能となります。
  • Data 360ベクトルストアとRAGの取得機能により、関連するすべての企業データと非構造化ナレッジがエージェントに統合ビューとして提供されます。
• Agentforce Agent: このパターンは、UI 内でユーザーのアクションを直接監視するアンビエントエージェントに焦点を当てています。リアルタイムアシスタントとして機能し、ユーザーのワークフローのコンテキストを理解してガイダンスを提供します。たとえば、エージェントはサービス担当者がケースレコードに記入している様子を監視し、関連するナレッジ記事を積極的に提示することができます。このようなヘッドレスエージェントの例を次に示します。
  • **フィードバックエージェント。**エージェントの動作と目的は、次のコンポーネントで定義されます。
    • トピックと手順: UI 内のユーザーのアクションを監視し、状況に応じた支援を提供するエージェントの任務を定義します。これには、その目的 (「ケース解決プロセスでサービス担当者をガイドする」など) と、サポートを積極的に提供するために監視する必要がある特定の UI イベントまたはデータ入力パターンが含まれます。
    • アクション: Apex またはフローを使用して作成されたアクション。関連情報と Next Best Action をユーザのワークフロー内で直接表示します。これらのアクションにより、エージェントは関連する Knowledge 記事を取得して表示したり、プロセスで有効な次のステップを提案したり、ビジネスルールに違反する可能性のあるデータ入力項目にフラグを設定したりできます。これらはすべて、ユーザーのリアルタイムの活動に応答します。
    • ガードレール: ガードレールは、エージェントの動作を制約する設定可能なルールとランタイムチェックのセットとして機能します。プロンプトを傍受し、エージェントの提案されたアクションを検証し、最終応答を絞り込んで有害なコンテンツを防止し、ビジネスルールを適用し、エージェントが指定された範囲内で業務を行うことができる安全レイヤーとして機能します。
    • プロンプトテンプレート: 差し込み項目または Data 360 RAG Retrievers のセマンティックデータを介してライブ CRM データが動的に入力される再利用可能なテンプレート。これらのテンプレートにより、エージェントはブランド情報に基づいたコンテキストのコンテンツを生成できます。一方、Einstein Trust Layerでは、指示がLLMに送信される前に機密情報を安全にマスキングできます。
• Ambience targets (雰囲気目標)
  • Web ページや管理者ページなど、エージェントとユーザーがいる場所でユーザーに通知

接触

1. ユーザーがページまたはアプリケーションにアクセスすると、エージェントは自分自身をオブザーバーとして添付します。
2. エージェントはデータとアクションを調査し、インクリメンタルな方法でインテントを検出し、意思決定を行い、アクションを呼び出します。
3. エージェントはインテントに基づいてコンテキスト化し、追加データ (構造化または非構造化) を取得します。
4. エージェントはユーザー入力画面なしでジャストインタイムのリアルタイム応答を提供し、Next Best Action を提案したり、ユーザーの代わりに実行を提案したりできます。
5. エージェントは、これを他のエージェントやユーザーとシームレスに共有できます。

トレードオフ

関連パターン

リスナー/フィードパターン: リスナーパターンと組み合わせて、観測された活動に基づいてプロアクティブなアクションをトリガーできます。

データ スチュワード パターン:アクティビティ代行受信AIは、データ スチュワードを使用して、代行受信されたアクティビティを記録するときのデータ品質と一貫性を確保できます。

ジェネレータパターン: 代行受信された活動に基づいて活動概要またはフォローアップ ToDo を自動的に生成するために使用できます。

このセクションでは、1 人以上のエージェントが人間のユーザーと協力して共通の目標を達成するコラボレーションエージェントのパターンについて詳しく説明します。これらのレシピでは、シームレスなパートナーシップの構築に焦点が当てられています。エージェントは複雑なデータ収集と ToDo の実行を処理しながら、意思決定、承認、戦略ガイダンスをユーザーに提供します。

このモデルでは、エージェントがワークフローの自動化可能な部分を処理します。このプロセスは動的なフィードバックループになります。

• 人間が会話型エージェントを介して ToDo を開始すると、プロアクティブエージェントがトリガーされてバックエンドステップが管理されます。
• 同時に、アンビエントエージェントがアクションを監視してリアルタイムのガイダンスを提供する場合があります。

このプロセスにより、人とデジタルの作業のシームレスな融合が実現します。このパターンでは、Agentforce がマルチエージェントの Human-in-The-Loop (ループ内の人間) システムを容易にして、1 人のエージェント (または人間) だけでは管理できない複雑なジョブに対処する方法を示しています。

問題

ビジネスプロセスでは、内部組織と外部組織の両方から、異なるスキルと優先度で異なる作業を実行する異なる組織の作業者間のコラボレーションが必要です。プロセスのボトルネックは、リソースの業務量、スキルの制約、またはやりとりされる情報の量によって、いつでもどこでも発生する可能性があります。

コンテキスト

• プロセスはチーム全体にまたがり、成果を得るためには複数のチームメンバーがコラボレーションする必要があります。
• エージェントアシスタントは、会話型、プロアクティブ、アンビエントのエージェントとして、1 対 1 のシナリオですでに従業員をサポートしています。
• プロセスでは、ビジネスプロセスの適切な区分でエージェントを使用します。ただし、プロセスには人とエージェントのコラボレーションも必要です。このコラボレーションには、エージェントの支援を伴う人間間連携や、人間とエージェントが交互に関与する連携が含まれる場合があります。
• スキルのギャップはエージェントが埋めます。
• エージェントは、フォローアップや意思決定に役立つ重要な情報の交換などの作業で人的労力を削減することで、コラボレーションを改善します。
• エージェントは、ポリシーとガイドラインに基づいてコラボレーションや委任を行うこともできます。

主要コンポーネント

• コラボレーションサーフェス
  エージェントによるコラボレーションでは、すべての参加者 (人間とエージェントの両方) がやりとりできる共有スペースが必要です。これらのコラボレーションサーフェスは、もはや静的な人間のみの環境ではありません。代わりに、エージェントを招待して参加させたり、寄稿したり、会話を開始したりできるチャネルであるため、チームワークの性質が根本的に変わります。たとえば、エージェントが Slack でケーススウォームを作成して開始し、人間の専門分野のエキスパートや他のエージェントをケースに関するコラボレーションに招待できます。

• Agentforce エージェント
  このパターンは、個々のエージェントパターンの枠を超え、コラボレーションエージェントモデルにおいてこれらが融合し、複雑なプロセスを統括することで人間の能力を効果的に拡張する様子を示しています。上記のパターン（会話型（2.1）、プロアクティブ（2.2）、およびアンビエント（2.3））は、Agentforce エージェントコンポーネントの方向性を定義します。会話型エージェントは、人間の側で動作する主インターフェイスとして機能し、人間とコラボレーションに関与するすべてのエージェントとの間のインターフェイスとして機能します。タスクが多面的すぎる場合、カンバセーションエージェントがコラボレーションセッションを開始し、人間のユーザーと必要なヘッドレスエージェントが同時に問題に取り組みます。 このプロセスは動的なフィードバック ループになり、人間がタスクを開始してプロアクティブ エージェントがバックエンド ステップを管理し、アンビエント エージェントがリアルタイムのガイダンスを提供するために監視することで、人とデジタル環境の作業がシームレスに融合されます。

• データレイヤー
  コラボレーティブエージェントモデルでは、データレイヤーは単に情報を提供するよりも動的な役割を果たします。つまり、人とエージェントチーム全体の永続的なメモリおよび共有ワークスペースになります。関連する各エージェントには、それぞれのパターンで定義されているように固有のデータニーズがありますが、複雑なタスクに関するコラボレーションは、ジョブ全体の状態を追跡する共有データ基盤に依存します。

  この共有状態は極めて重要です。ToDo が会話型エージェントからプロアクティブなエージェントに渡され、その後人間に承認が渡されるため、データレイヤーは各ステップでの進行状況、コンテキスト、決定を追跡する必要があります。これにより、すべての参加者が一貫して最新の状況を把握できるようになります。

接触

1. 人間が他の人間やエージェントとコラボレーションセッションを開始します。
2. コンテキスト、目標、ジョブ、結果が定義されます。
3. エージェントは追加情報を取り込んでコンテキストを強化し、人間またはエージェントである所有者と共に作業を完了するために必要なステップを積極的に計画します。
4. 進行状況が観察され、コンテキストが更新され、アクションが実行されます。
5. エージェントがジョブを実行する場合、エージェントは人間の関係者が推論を理解し、フィードバックを提供し、介入を可能にするために役立つ詳細情報を提供します。
6. エージェントは完全な透明性とコンプライアンスで仕事を完了します。

トレードオフ

関連パターン

オペレーター パターン:コラボレーション エージェントは多くの場合、オペレーターとして機能し、適切なスペシャリストAIエージェントまたは人間のサービス担当者に要求を転送し、インテントを交渉します。

オーケストレーター パターン:コラボレーションが関連するシナリオでは、オーケストレーター エージェントがAIエージェントのスウォームを管理し、シームレスなユーザー エクスペリエンスのためにその応答を集計します。

ワークスペース(Radar O'Reilly)パターン: コラボレーションエージェントはこのパターンを使用して、応答性の高い一元化されたUXを管理し、会話フロー内で関連するコンテンツをリアルタイムで更新します。

ユーザーを支援するコラボレーションパターンとは異なり、自律エージェントは完全な委任を目的として設計されています。このセクションでは、複雑な複数ステップの ToDo を独立して計画および実行し、人の介入なしで概要レベルの目標を達成できるエージェントのアーキテクチャ設計図について説明します。ここでは、最初から最後まで実行できる目標と Trust で ToDo できるシステムの作成に焦点を絞ります。

問題

組織は、ポリシーに基づく個別のジョブ、プレイブック、実行に必要な特定のスキルを備えた非常に複雑な一連のプロセスで価値を実現します。これらは多くの場合、時間とリソースを大量に投資する必要があるプログラムです。

新しいプログラムを設定するとオーバーヘッドが大きくなり、価値を実感するまでに数か月かかることがあります。フィードバックと改善を実装するには、追加の時間と労力が必要になることがよくあります。複雑さの主な原因は組織の構造にあり、分散アプリケーションとプロセスが連動して人間がプログラムを管理しなければならない場合があります。

コンテキスト

• エージェントは最初から最後まで独立して操作できます。エージェントは、目標、計画、戦略が事前に設定されるように設計および設定されます。
• エージェントは、人間の承認を求めずにすべての意思決定を行うことができます。エージェントにはポリシーとコンプライアンスのガイドラインが提供されます。
• エージェントは必要なコンテキストとデータにアクセスでき、人間なしで必要なアクションを実行できます。
• 人間には通知されますが、全体の情報共有に常に参加するわけではありません。

主要コンポーネント

• 目標と戦略定義レイヤー
  • プロセスプレイブック: エージェントが従う必要がある確定的ルールを含む自律的な実行の詳細な説明
  • 自律決定条件: エージェントが人間の承認を必要とせずに意思決定を行えるようにするルール
  • 代替ルール: エージェントの主プロセスが失敗したときにデフォルトまたは例外シナリオを処理するための定義済みアクション
  • 範囲: 範囲外の状況の処理方法など、エージェントができることとできないことを明確に定義した境界
  • Success criteria and definition of done (完了の成功基準と定義): エージェントの ToDo が正常に完了するタイミングを決定する指標と条件
• Agentforce エージェント
  • エージェントオーケストレーターまたは振付家: 目標、理由、実行計画を所有するメインエージェント
    • トピックと手順: 目標が定義されると、オーケストレーターまたは振付師エージェントが主導して、その全体的な目標をより小さく管理可能なジョブまたはサブタスクに分割します。ジョブの順序の概要を示した包括的な計画を作成し、各ステップに必要な特定のエージェントまたはツールを特定します。最後に、オーケストレーターエージェントは、効率的かつ効果的に目標を達成するために、計画のシームレスな実行、進行状況の監視、連動関係の管理、必要に応じての調整を行います。コレオグラファーエージェントの場合、コンテキストと状態を下流のエージェントに渡して、ジョブを完了まで引き継ぎます。
    • アクション: アクションは、機能を実行するツールを呼び出したり、データを取得したり、他のヘッドレスエージェントに委任したりして、より幅広い機能と複雑なワークフローを実現します。
    • ガードレール: ガードレールは、エージェントの動作を制約する設定可能なルールとランタイムチェックのセットとして機能します。プロンプトを傍受し、エージェントの提案されたアクションを検証し、最終応答を絞り込んで有害なコンテンツを防止し、ビジネスルールを適用し、エージェントが指定された範囲内で業務を行うことができる安全レイヤーとして機能します。
• データレイヤー
  • CRM データ: 1 人以上のエージェントにコンテキストを提供する CRM で使用可能な顧客データ
  • さまざまなソースから取り込まれた関連する顧客データを保存する DLO や DMO などの Data 360 コンポーネント
  • 計算済みインサイト、ストリーミングインサイト、リアルタイムインサイトは、顧客、その活動、重要なインサイトに関する即時の関連データをエージェントに提供します。これにより、メールバウンスの処理などのプリエンプティブな問題解決が可能になり、エスカレーションが軽減されます。
  • Data 360ベクトルストアとRAGの取得機能により、関連するすべての企業データと非構造化Knowledgeの統合ビューをエージェントに提供します。
  • 会話コンテキストを提供するケース履歴や会話エージェント履歴などの Slack チャネルメッセージまたは会話データ
• 監視と監督
  • エージェント目標進行状況監視: 自律エージェントセッションの進行状況を追跡して、結果を測定して目標に一致していることを確認します。
  • エージェント業務監視: 介入とトラブルシューティングのために自律エージェントのリアルタイム状況を追跡し、円滑な業務を実現します。
  • エージェントガバナンス監視: 追跡ログと監査ログを追跡して、自律エージェントが定義済みの目標、目的、および倫理ガイドラインに準拠していることを確認します。

接触

1. ジョブは明確な結果で定義されます。
2. ジョブは次のいずれかのメソッドで開始されます。
   • エージェントにタスクが割り当てられます。
   • エージェントは、条件に基づいて自発的にジョブを選択します。
   • エージェントはバックグラウンドでジョブを実行します。
3. エージェントは期待を明確に設定し、目標、計画、戦略の詳細を人間に通知します。この計画では、ステップごとのプロセス、使用されたエージェント、使用されたデータ、範囲、エージェント評価計画、および進行状況、運用、ガバナンスを監視するためのチェックポイントが詳細に示されます。
4. エージェントが実行を開始します。マイルストーンごとに、状態と進行状況が更新されます。人間には、必要に応じてフィードバックを提供したり、エージェントを代行受信したりする機能があります。
5. エージェントがジョブを完了します。成果と結果は監視ダッシュボードで入手可能です。

トレードオフ

関連パターン

プロジェクトマネージャーパターン: 多くの場合、自律型エージェントがこのパターンを体現し、最小限の人の介入で開始から完了までの長時間の複数ステッププロセスを監督します。

コンフィグレーターパターン: 自律エージェントはこのパターンを使用して、自然言語要件または定義済みポリシーに基づいて設定を自動的に生成および検証できるため、手動で監視することなくコンプライアンスと正確性を確保できます。

Zen Data Gardener パターン: このパターンは、自律エージェントがスケジュールされたバックグラウンドデータのグルーミングと標準化に使用でき、経時的なデータ品質と一貫性を確保して、エージェントの正確な意思決定をサポートします。

では、エージェント分類とエージェントパターンを Salesforce Platform でどのように実装するかを見てみましょう。Agentforce のコア コンポーネントに精通していない場合は、この章以降で参照される主要なテクノロジーについて、付録を参照しておくと役立ちます。

このセクションでは、エージェントの分類を取り上げ、一般的な使用事例を使用して各エージェントを説明し、実際のアプリケーションでエージェントがどのように使用されるかを示します。

顧客の Jane が会社の Web サイトにアクセスし、最近の注文状況を確認します。

• インタラクション: Jane がチャット ウィンドウ(Agentforce チャット クライアント)を開きます。
• エージェントアクション: 会話型のエージェントが挨拶し、どのように役立つか質問します。Jane は「最新の注文はどこですか？」と尋ねます。
• プロセス:
  1. エージェントは、Salesforce からの Jane の顧客情報に基づいて、最新の注文を識別します。
  2. 配送システムに (MuleSoft コネクタを介して) 最新の追跡情報を照会し、Jane にリアルタイムの更新と追跡リンクを提供します。
  3. 次に、保険契約を検索し、自動的に迅速な配送にアップグレードします。
  4. Jane がエージェントが処理できない複雑な質問をすると、チャットが人間のサービスエージェントにシームレスにエスカレーションされ、状況に応じた完全なトランスクリプトが提供されます。

レシピ

使用されるパターン: 会話型 AI パターン、トランザクションデータとエージェントの統合

設計時間

1. 会話エージェントを設定します。

   拡張チャットの設定	→	サービスエージェントの作成	→	「サポート注文の定義」トピック	→	[注文を取得] アクションを作成
   						↓
   送信エスカレーションオムニチャネルフローの追加	←	エスカレーショントピックの作成	←	トピックへのアクションの追加	←	[状況を取得] アクションを作成
   ↓
   エージェントを公開

2. Jane が Web ページで Agentforce ウィンドウを開くことができるように、拡張チャットを Jane のチャット エントリ ポイントとして設定します。
3. Agentforce を有効にし、Agentforce Builder で会話を処理してカスタムアクションをトリガーするサービスエージェントを作成します。
4. エージェントが「Where is my latest order? (最新の注文はどこですか?)」を自然に認識できるように、説明と手順を使用してサポート注文トピックを定義します。
   1. カスタムエージェントアクションの作成：
      1. Jane の最新の注文を取得する [Get Latest Order for Contact (取引先責任者の最新の注文を取得)] アクション
      2. MuleSoft を使用して追跡情報を取得する [Get Shipping Status by Order ID (注文 ID 別に配送状況を取得)] アクション
      3. 必要に応じて、外部サービスアクションを使用して、フローの両方のアクション (最新の注文の取得と MuleSoft の呼び出し) を調整します。
      4. 両方のアクションをビルダーでサービスエージェントに追加し、「注文と追跡」トピックにリンクして公開します。
5. サービス担当者にエスカレーションする説明を含むエスカレーショントピックを定義します。
   • アウトバウンドのオムニチャネルフローを作成して有効化します。
   • ビルダーの Connections タブに追加し、エスカレーションメッセージとともにエスカレーション用に設定します。
6. オムニチャネルをセットアップします。

   オムニチャネルの設定

   →

   エスカレーションルールを命令で定義

   →

   優先度と業務量の設定

   →

   テストと検証

7. AI エージェントがクエリを解決できない場合、人間のサービスエージェントへのシームレスなエスカレーションを有効にします。オムニチャネルルーティングを設定して、チャットをサービス担当者に割り当て、コンテキスト用に完全なトランスクリプトを転送します。
8. エスカレーションロジックをAgentforce命令とエスカレーションアクションに統合し、エージェントが複雑なケースをいつ転送すべきかを把握できるようにします。オムニスーパーバイザーを通じてルーティングの優先度と業務量を管理します。
9. 完全な環境をテストします。Jane がチャットを開くと、エージェントは Jane に挨拶し、注文を識別し、配送データを取得して、人の介入が必要な場合にシームレスにエスカレーションします(「拡張イベントログの有効化」も参照してください)。
10. データインテグレーションをセットアップします。

    コンテキストデータをマッピング

    →

    MuleSoft API ログイン情報の作成

    →

    MuleSoft 外部サービスを登録

11. Jane の取引先責任者レコードと注文レコードを認証済みチャットフォームまたは事前チャットフォームでマッピングして、エージェントを Jane の Salesforce コンテキストでグラウンディングします。
12. 認証用の外部ログイン情報および指定ログイン情報を使用して、Salesforce を MuleSoft shipping API に安全に接続します。
13. MuleSoft が OpenAPI 仕様を公開する場合は、フローおよびエージェントが宣言的にコールできるように外部サービスとして登録します。
14. 非構造化データ統合を設定します。
    1. [設定] から新しいデータライブラリを作成します。「Order and Shipping Policy」 (注文および配送ポリシー) という名前を付けます。
    2. 配送ポリシーの例外を含むポリシードキュメントの PDF を追加します。
    3. バックグラウンドで、ドキュメントが自動的にチャンクされ、インデックス付けされて、すぐに使用できるようになります。

エージェントランタイムプロセスフロー

エージェントを設定してリリースすると、実行時に次の一連の手順が実行されます。

1. チャット起動: Jane が Agentforce チャット (組み込みサービス) を開きます。Jane がログインした後、セッションおよび連絡先コンテキストが読み込まれます。

2. 挨拶とインテント: エージェントが Jane に挨拶します。Jane が注文の状況を尋ねると、インテント検出によって「最新の注文」が [注文と追跡] トピックに対応付けられます。

3. CRM ルックアップ: エージェントは [Get Latest Order (最新注文を取得)] アクションをトリガーし、Jane の最新レコードを Salesforce (注文概要/注文) に照会します。

4. **Shipping query：**エージェントが指定ログイン情報を介してMuleSoft APIをコールすると、/shipping/status/{orderId}がリアルタイムの状況と追跡URLを返します。

5. 応答構成: Agentforce が結果をマージし、「Your order [OrderID] shipped via [Carrier], arrival tomorrow — [Track Here].」([Carrier] 経由で出荷された注文 [OrderID] が明日到着しました — [Track Here]) という応答を構成します。

6. フォールバック: 一致がないか API が失敗した場合、エージェントは謝罪し、データの問題を修正するために再試行することを提案します。

7. エスカレーション: 複雑なクエリや感情的なクエリは、オムニチャネルを介して自動的に人間に転送され、完全なチャットとコンテキストが渡されます。

8. ログ記録: すべてのインテント、アクション、結果がインタラクションログに保存されます。API 遅延は Anypoint Monitoring で監視されます。

9. 継続的な改善: エスカレーションは Agentforce の再トレーニングにフィードされ、一般的なフローは後続のリリースで調整されます。

価値の高い本顧客であるJohnは、1,000ドルを超える商品をオンラインカートに追加しましたが、60分以内に購入を完了しませんでした。

• トリガー： John の取引先責任者 ID とカート値を含む Salesforce Platform イベント Cart＿Abandoned＿＿e が E コマース システムから起動されました。
• エージェントアクション: このイベントに登録されたプロアクティブなエージェントがすぐにアクションを実行します。
• プロセス:
  1. エージェントが Salesforce で John のレコードを確認し、John が VIP 顧客であることを確認します。
  2. John の Account Manager である Sarah のために、放棄されたカートのすべての詳細を含む優先度の高いタスクが作成されます。
  3. Sarah にフォローアップを促す通知が Slack 経由で送信されます。
  4. 同時に、John を対象を絞った Marketing Cloud ジャーニーに登録し、期間限定の 10% 割引コードを含むリマインダーメールを送信して購入の完了を促します。

レシピ

このレシピでは、Salesforce Platform でプロアクティブな AI エージェントを実装して、VIP 顧客による価値の高いカートの放棄に対処します。このソリューションは、Salesforce Platform Events、Knowledge検索用のData 360、Agentforceを活用して、タイムリーでインテリジェントなフォローアップ アクションを調整し、パッシブ データをアクティブなビジネス エンゲージメントに変換します。

設計時間

1. VIP 顧客である John がカートを放棄したときにトリガーする放棄カートイベントを設定します。

   カスタム取引先責任者項目を作成

   →

   新しいプラットフォームイベントの定義

   1. Contact Id (取引先責任者 ID)、Cart Value (カート金額)、Cart Last Updated DateTime (カート最終更新日時)、および Cart Details (カートの詳細) フィールドを使用して Cart_Abandoned__e プラットフォームイベントを作成します。
   2. 破棄イベントを設定します。Commerce Cloud を使用して、Checkout イベント通知のプラットフォーム イベントを作成します。カート注文手続きセッションの状態が中間状態になり、セッションがしきい値に達してタイムアウトした場合に、放棄が検出されます。または、e コマースが外部システムの場合は、フロー、Apex、Salesforce API、Pub/Sub API のいずれかの方法を使用してイベントを Salesforce に公開します。
   3. Contact オブジェクトで、選択リスト値 Standard、Premium、および VIP を使用して新しいフィールド Customer_Tier__c を作成します。
2. Data 360 での非構造化データの取り込みの設定: ドキュメントリポジトリをソースとする割引ポリシードキュメントを Data 360 の Amazon S3 に追加します。

   AWS S3 認証情報の作成	→	新しい S3 データストリームの作成	→	ストリームの設定とリリース	→	検索インデックスの作成
   						↓
   				取得機能のテスト	←	インデックスの設定とリリース

   1. S3 にアクセスするための外部認証情報を作成します: IAM ユーザー用の新しいアクセスキーとシークレットのセット、または IdP 用の IAM Amazon リソース名 (ARN) を作成します。
   2. 新しい S3 データストリームを作成します。[データストリーム] タブで、データストリーム Policy Documents Stream を作成し、S3 ソースを選択して、PDF ファイルの種類を選択し、更新頻度を設定して、メタデータ項目 (ファイル名とサイズ) を対応付けてからリリースします。
   3. データ ストリームが完了したら、検索インデックスを作成します。チャンク、E5-large-v2 埋め込みモデル、ハイブリッド検索タイプに通路抽出を使用して、インデックスをリリースします。
   4. 作成した取得関数をテストします。
3. VIP カートリカバリー エージェントを設定します。

   テンプレートからエージェントを作成	→	[VIP カートをリカバリ] トピックの追加	→	トピックの手順の追加	→	Slackアラートアクションを作成
   						↓
   トピックへのアクションの追加	←	ジャーニー登録アクションの作成	←	[割引オファーを作成] アクション	←	カートリカバリータスクの作成

   1. Agentforce 従業員エージェントテンプレートからエージェントを作成します。
   2. このエージェントが VIP 顧客にとって価値の高いカートの破棄を処理するという説明と共に、新しいトピック「Recover VIP Cart (VIP カートの復旧)」を追加します。
   3. トピックの手順を追加して、VIP 状況を検証し、カートが条件を満たすか確認し、Slack で Account Manager に通知し、割引オファーを推奨し、顧客をカートリカバリーメールジャーニーに登録します。
   4. アクションとタスクを作成します。
      • [取引先マネージャーにアラートを送信] アクション: プロアクティブな Slack 通知を送信します。
      • カートの詳細とともに Account Manager に割り当てられた放棄されたカートリカバリー タスク
      • Get Discount Offer (割引オファーを取得) アクション: 保険契約と以前の購入履歴を分析します。グラウンディングを含むプロンプトテンプレートを作成し、プロンプトテンプレートで取得関数を参照し、データを使用します。
      • [復旧ジャーニーに登録] アクション: API を使用して Marketing Cloud 復旧ジャーニーに登録し、エージェントから生成されたすべての登録者データと割引オファーメールメッセージを取得します。
   5. アクションをトピックに追加します。
   6. Marketing Cloud のテンプレートを使用して VIP カスタマー カート リカバリ ジャーニーを作成するか、新しいジャーニーを作成します。
4. エージェントをコールするようにプラットフォームイベントを配線します。

   イベントトリガーフローの作成

   →

   プラットフォームイベントに登録

   →

   エージェントが呼び出し可能なアクションの追加

   →

   イベントデータをエージェントに渡す

   1. 新しいプラットフォームイベントトリガー型フロー「VIP カート放棄リカバリー」を作成します。
   2. フローがサブスクライブするカート放棄イベントを選択します。
   3. Flow Builder で カスタムエージェントの呼び出し可能なアクションのセットアップを行い、VIP カートリカバリーエージェントを選択します。顧客のためのVIPカート放棄リカバリーを開始するリクエストを送信し、プラットフォームイベントのペイロードを送信します。

エージェントランタイムプロセスフロー

エージェントを設定してリリースすると、実行時に次の一連の手順が実行されます。

1. カート放棄検出: Johnはカートに1,200ドルを追加し、60分後にCheckoutやステージの進行がない場合に放棄がトリガーされます。
2. **プラットフォーム イベント パブリケーション:**Commerce Cloud は、John の取引先責任者 ID、カート金額 $1,200、カート変更日、その他の詳細を含む Cart_Abandoned__e イベントを公開します。
3. フロー初期化: プラットフォームイベントによって VIP カート放棄リカバリーフローがトリガーされます。
4. 従業員エージェントの有効化: フローが実行されると、VIP Cart Recovery エージェントが呼び出されます。
5. トピック実行: エージェントは [Recover VIP Cart (VIP カートをリカバリ)] トピックを解決し、指示を実行します。
6. 通知作成: エージェントが John のアカウントマネージャー Sarah に Slack で警告します。
7. ToDo 作成: エージェントは Sarah の ToDo を作成し、実行するフォローアップについてアドバイスします。
8. 割引分析: エージェントは、Data 360 取得関数をコールして、カート金額、顧客層、購入履歴に基づいて「最大許容割引」を要求して、割引分析を実行します。この場合、この関数は 10% の割引提案を推奨します。
9. Eメール準備およびジャーニー登録:エージェントは割引オファーメールを準備し、JohnをMarketing CloudジャーニーのVIPカスタマー カート リカバリーに新しいカート価格で登録します。
10. Logging and attribution: John は提案を利用し、ログの属性とコンバージョンの評価指標を作成します。
11. フィードバック分析: 提案、復旧までの時間、その他の最適化要素をさらに判断するために結果が分析されます。

営業担当の David が、新しい見込み顧客とのディスカバリーコールに従事しています。インテリジェントなエージェントが通話をリアルタイムで積極的に監視し、見込み客の質問に答えることで David を迅速にサポートします。

例: 見込み客が特定の製品仕様について問い合わせた場合、エージェントは関連する詳細を自動的に取得し、Slack または非公開メッセージで David に配信します。

• トリガー: 見込み客が、営業担当 (David) との検出コール中に特定の製品情報を必要とする質問をします。
• エージェントアクション: アンビエントエージェントは通話ログとメッセージを継続的に分析し、必要な情報をインテリジェントに特定して取得します。
• プロセス:
  1. エージェントが通話の文字起こしをリアルタイムで解析します。
  2. 主要なアクション項目が自動的に識別され、関連情報が取得されます。
  3. この場合、エージェントは Salesforce から直接商品情報を取得します。
  4. 次に、取得した情報を Slack または非公開メッセージで David に自動的に表示します。

レシピ

このレシピには、リアルタイムの音声テキスト変換機能を必要とする前提条件があり、それらは通信プロバイダーから入手できることを前提としています。たとえば、Zoom 通話を統合するレシピを次に示します。

**前提条件:**Zoom 通話のリアルタイムの文字起こしの例:

• Zoom 開発者プラットフォームで、記録の参照、Web フックの送信、ミーティングストリームに必要な範囲を使用して Zoom アプリケーションを作成します。Realtime Media Streams (RTMS) などの必要な製品機能を有効にします。
• オーディオ ストリームを受信して Amazon Transcribe サービスに転送し、文字起こしされたテキストを取得する中間シグナリング サーバ(Zoom RTMS サンプル)を設定します。その後、トランスクリプトはプラットフォームイベントとして Salesforce に公開されます。

設計時間

1. Sales Call リアルタイムレスポンスエージェントをセットアップします。

   テンプレートからエージェントを作成	→	[支援コール] トピックの追加	→	トピックの手順の追加	→	トランスクリプト分析アクションの作成
   						↓
   		トピックへのアクションの追加	←	[Slack インサイトを作成] アクション	←	[商品仕様を作成] アクション

   1. Agentforce 従業員エージェントテンプレートからエージェントを作成します。
   2. このエージェントがライブトランスクリプトを聞き取り、インテントを理解して、商品データを支援するという説明を含む新しいトピック [Assist Call (通話の支援)] を追加します。
   3. トランスクリプトの解析、商品仕様の取得、Slack メッセージの送信を行うためのトピック命令を追加します。
   4. アクションを作成します。
      • [通話の文字起こしを分析] アクション: リアルタイムで受信した通話の文字起こしデータを分析し、主要な質問またはアクションを抽出します。
      • [商品仕様を取得] アクション: 商品Knowledge記事を照会する
      • 「内部」ユーザーへの Slack インサイトの送信
   5. アクションをトピックに追加します。
2. Product Knowledge データライブラリをセットアップします。

   新しいデータライブラリの作成

   →

   Knowledge 記事の追加

   →

   システムチャンクとインデックス

   →

   グラウンディングライブラリのアクション

   1. [設定] から新しいデータライブラリを作成します。「Product Knowledge」という名前を付けます。
   2. 製品情報を含むKnowledge記事を追加します。
   3. バックグラウンドで、ドキュメントが自動的にチャンクされ、インデックス付けされて、すぐに使用できるようになります。
   4. 「商品仕様を取得」アクションでグラウンディングを使用します。
3. Pub/Sub API を使用してリアルタイムのトランスクリプトを Salesforce に公開します。

   サーバーが音声トランスクリプトを受信する

   →

   サーバーがプラットフォームイベントを公開する

   1. プラットフォームイベント Transcript_Segment__e を、通話 ID、シーケンス、話者、セグメント開始時刻、セグメント終了時刻、所要時間、およびトランスクリプトデータ項目を使用して作成します。
   2. シグナリングサーバ (「前提条件」セクションを参照) で、音声から文字起こしされたテキストを受信したら、Transcript_Segment__e イベントを使用してデータをすぐに公開します。フロー、Apex、Salesforce API、または Pub/Sub API のいずれかを使用して、イベントを Salesforce に公開できます。
4. 公開された Transcript_Segment__e イベントに登録するためのフローの配線。

   イベントトリガーフローの作成	→	Transcript イベントを購読する	→	エージェントが呼び出し可能なアクションの追加	→	エージェントにペイロードを送信
   						↓
   						エージェントが Slack DM を送信

   1. 新しいプラットフォームイベントトリガーフロー「Discovery Call Insights」を作成します。
   2. フローに登録する Transcript＿Segment＿＿e イベントを選択します。
   3. Flow Builder で呼び出し可能なカスタムエージェントアクションを設定し、Sales Call Realtime Response エージェントを選択します。イベントペイロードを送信して [支援コール] トピックに転送します。トピックから質問が派生すると、質問は [商品仕様を取得] アクションに送信され、回答を得ることができます。
   4. 最終的な回答がまとめられ、Slack DM を介してすぐにユーザーに送信されます。

エージェントランタイムプロセスフロー

エージェントを設定してリリースすると、実行時に次の一連の手順が実行されます。

1. 通話開始: David は、Zoom 通話で見込み顧客とディスカバリーコールを開始します。Zoom RTMS は、ライブ音声をシグナリングサーバーのトランスクリプトエンドポイントにストリーミングします。
2. リアルタイム文字起こし: シグナリングサーバーは音声を受信し、音声をテキストに変換して、Salesforce Platform でトランスクリプトセグメントプラットフォームイベントを公開します。
3. エージェントリスニングおよびコンテキスト分類: Salesforce がプラットフォームイベントを受信し、Discovery Call Insights フローをトリガーします。
4. フローは、セグメントを受信する Sales Call Realtime Response エージェントを開始し、質問 (「Toaster 2XP はモバイルデバイスと統合されていますか?」など) を識別して [Assist Call (支援通話)] トピックに分類します。
5. **Knowledge 取得:**エージェントは [Get Product Spec (商品仕様を取得)] アクションをトリガーし、Knowledge データに一致する回答を照会します。
6. Send private Slack DM: エージェントは Send Slack Insight を実行し、David の Slack DM に投稿します。「Product Toaster 2XP は Apple および Android デバイスと統合でき、Bluetooth 経由で接続できます。アプリをインストールしたら、Bluetooth で接続してトースターを操作するだけです。マニュアルへのリンクはこちらです 。 」
7. リアルタイム継続: エージェントはトランスクリプトテキストを引き続き受信します。複数のインサイトが見つかった場合、通話フローを中断することなくコンテキストに応じた Slack 応答をスレッド化します。
8. 通話後の概要: セッションの終了時に、エージェントは主要な質問、実行されたアクション、参照された製品の概要を自動的にまとめます。
9. 継続的な改善: Agentforce Analyticsは、トランスクリプトと応答のレイテンシ、商品の一致精度、および営業担当の成果を評価し、時間の経過とともにトピックの指示を調整します。

営業マネージャーの Bob は、「カリフォルニアの製造セクターでの販売パイプラインを今後 60 日間で 500 万ドル増やす」という目標を持つ自律エージェントにタスクを課します。

• トリガー: マネージャーが Slack のコマンドを使用して目標を割り当てます。
• **エージェントアクション:**自律エージェントは計画と実行のループを開始します。
• プロセス:
  1. 調査: このエージェントは(MuleSoftを介して)Salesforce Data 360と外部データソースを照会し、現在の顧客ではないカリフォルニアの製造部門の企業を特定します。
  2. 対象: これらの企業を分析し、最近の資金調達、新規役員の採用、関連する求人などの購入シグナルを探します。上位 20 件の見込み客にスコアを付けて優先度を付けます。
  3. **Identify Contacts (**取引先責任者の特定): これらの会社の主要な取引先責任者 (業務統括責任者や工場長など) を検索します。
  4. アウトリーチ: 特定の会社のニュースや課題を参照して、取引先責任者ごとにパーソナライズされたアウトリーチメールのドラフトを作成します。次の週に送信されるようにスケジュールされます。
  5. フォローアップ: Eメールの開封と返信を追跡します。見込み客からの肯定的な返信によってカレンダーの分析がトリガーされ、ミーティング時間が提案されます。確認後、Salesforce の行動と新しい商談が自動的に生成されます。
  6. **レポート:**Slack の営業マネージャーに毎週の進行状況レポートを提供します。

レシピ

これは、各エージェントが特定のタスクを実行し、コンテキスト、データ、制御を次のエージェントに渡すマルチエージェントシナリオです。調査と評価にはいくつかのカスタムヘッドレスエージェントを使用し、見込み顧客へのアウトリーチとモニタリングには標準のセールスデベロップメントエージェント（SDR）を使用します。また、Bob の会社が市場調査に ZoomInfo を使用していることも想定します。また、データベースに保持され、パートナー企業に関する有益な情報が含まれるサプライヤーネットワークデータも受け取ります。

設計時間

1. マルチエージェントアーキテクチャを設定します。

   調査エージェントがインテリジェンスを収集する

   →

   評価エージェントがリードをスコアリング

   →

   SDR エージェントがアウトリーチを開始

   1. 調査エージェント: MuleSoft を使用して Data 360 と外部ソースを照会する
   2. 評価エージェント: リードの優先度付け、スコアリング、強化
   3. SDR エージェント: リードの割り当て、アウトリーチの実行、フォローアップ、ミーティングのスケジュールを行います。Agentforce Analytics for SDR Agent を使用して、SDR エージェントの活動と進行状況を監視します。
2. 新しい会社データを検出して取り込みます。

   新しいデータスペースの作成

   →

   Salesforce CRM データの取り込み

   →

   ZoomInfo データの取り込み

   →

   サプライヤーデータベースデータの取り込み

   1. 「Sales and Marketing」 (セールスおよびマーケティング) という新しいデータスペースを設定します。この新しいデータスペースには、自律エージェントに必要なすべてのデータが保持されます。
   2. Salesforce コネクタを使用して、リード、取引先、取引先責任者、商談の CRM データをデータスペースに取り込みます。
   3. ZoomInfo の Data 360 コネクタを設定します。Data 360 の営業およびマーケティングデータスペースにデータを挿入します。
   4. Anypoint Salesforce Data 360 コネクタを設定して、サプライヤーデータベースに接続し、データを Data 360 に取り込みます。
3. ヘッドレス調査および評価エージェントを開始するプラットフォームイベントをセットアップします。

   新しいプラットフォームイベントの作成

   1. 人間のユーザーの概要目標を取得する項目目標を使用して、新しい AgentGoal__e プラットフォームイベントを作成します。
4. ゴールオーケストレータエージェントをセットアップします。これは、ユーザーのゴールを受信し、他のエージェントにオーケストレートするカンバセーションAIエージェントです。

   テンプレートからエージェントを作成	→	「解析目標を追加」トピック	→	トピックの手順の追加	→	[目標イベントを作成] アクション
   						↓
   						トピックへのアクションの追加

   1. Agentforce 従業員エージェントテンプレートからエージェントを作成します。
   2. このエージェントがゴールインテントを理解し、必要に応じて追加のエージェントをコールできることを示す新しいトピック [Parse Goal (ゴールを解析)] を追加します。
      • 他のエージェントにゴールを解析してイベントをトリガーするトピック命令を追加します。
   3. 目標イベント AgentGoal__e を作成します。
5. オーケストレーションエージェントによってトリガーされるリード調査および評価エージェントをセットアップします。

   調査トピックの作成	→	重複排除アクションの作成	→	リード強化アクションの作成	→	リードスコアリングアクションの作成
   						↓
   				トピックへのアクションの追加	←	[リード評価を作成] アクション

   1. 「Research new leads in a region or state」(地域または州の新規リードの調査)という説明でプロスペクト調査トピックを作成します。
   2. アクションを作成します。
      • Lead Apexアクションの重複排除: 既存の顧客に対する新規リードの確認と検証
      • プロンプトテンプレートを使用するリードApexアクション: 非構造化マーケティングインサイトやサプライヤーデータベースのデータを調査し、リードデータを強化します。
      • [リードをスコアリング] アクション: 更新されたリードデータでリードを積極的にスコアリングする
      • Qualify Lead for Agent (エージェントのリードを評価) アクション: スコアリングに基づいて、SDR エージェントのリードを評価するパラメーターを割り当てます。
6. アウトリーチ、リードナーチャリング、ミーティングスケジュールを実行するようにAgentforce SDRエージェントを設定します。

   テンプレートから SDR エージェントを作成	→	エージェントの知識ベースの設定	→	エージェントのメール設定の定義	→	リードの割り当てルールの設定
   						↓
   						対象リード条件の定義

   1. 事前設定済みの Lead Nurture Agent テンプレートを使用して、[設定] ページから新しい SDR エージェントを作成します。メール設定とリード割り当てルールを設定し、リードオブジェクトまたは取引先責任者オブジェクトを選択し、割り当てルールの対象条件 (しきい値リードスコアと新規リード) を定義します。
   2. エージェントの設定、権限の割り当て、ケイデンスおよび割り当てルールの設定を行って、Agentforce Lead Nurturingを設定します。
   3. 必要な知識を設定し、SDRエージェントが質問に回答できるようにします。
7. 公開済み AgentGoal__e イベントを登録するための新しいフローを設定します。

   イベントトリガーフローの作成

   →

   エージェント目標イベントを購読

   →

   エージェントが呼び出し可能なアクションの追加

   1. 「Route Goals to Agents (目標をエージェントに転送)」という新しいプラットフォームイベントトリガーフローを作成します。
   2. フローで登録するエージェント目標イベントを選択します。
   3. Flow Builder で呼び出し可能なカスタムエージェントアクションを設定し、Lead Research and Qualification エージェントを選択します。

エージェントランタイムプロセスフロー

エージェントを設定してリリースすると、実行時に次の一連の手順が実行されます。

• 目標の割り当て: Bob は自律エージェントに「60 日間でカリフォルニアの製造業のパイプラインを 500 万ドル増やす」ように依頼します。
• ゴールオーケストレーション: 自律的な Goal Orchestrator エージェントがゴールを受信し、インテントを解析して、プラットフォームイベント AgentGoal__e を作成します。オーケストレータ エージェントは、複数の目標を処理するために機能を継続的に拡張するように設計されています。拡張してオーケストレーション機能を追加したり、本ユーザに説明を求めてインテントをより深く理解し、目標を開始したりできます。
• ルーティング: [Flow Route Goals to Agents (エージェントへのフロールート目標)] がトリガーされ、Lead Research and Qualification エージェントをコールします。
• 調査: リードリサーチおよび評価エージェントは、Data 360で新しいリード情報を照会し、既存の顧客に対する重複排除を行い、Data 360から追加の市場調査データを取得して、リードを強化します。リードをさらにスコアリングし、キー値となる連絡先を特定して、リードを評価します。
• アウトリーチ: リードが評価されると、リードの割り当てルールに従って、リードがSDRエージェントの対象になります。SDR エージェントは最初のアウトリーチを実施し、商品に関連する質問に答えることで連絡先との会話を維持します。
• フォローアップ: ケイデンスの終了時またはリードからの要求時に、リードがサービス担当者とのエンゲージメント対象であれば、エージェントはミーティングのスケジュール設定を促します。その後、ミーティングをスケジュールしてフローを終了します。
• Agent Analytics: SDR Agent Analytics ダッシュボードでは、エージェントのパフォーマンスの効率性に関するインサイトが提供されます。

長年の顧客で、請求超過、受け取った交換部品の誤り、サービス切断という多面的な問題が発生している。

• トリガー: 顧客がチャットを開始すると、最初の会話型エージェントがその複雑さをすばやく認識し、エージェントのスウォームにエスカレーションします。
• エージェントアクション: オーケストレーターエージェントが担当します。
• プロセス:
  1. オーケストレータ: 顧客との会話を維持し、最新情報を提供します。
  2. オーケストレーター代理: A2A プロトコル実装を使用して、オーケストレーターは必要な機能を備えた「関連エージェント」(請求、物流、プロビジョニング) を検出し、ToDo を派遣します。
     • 請求エージェント宛て: 「Investigate invoice #INV-7890 for customer X. Are there are discrencies? (顧客 X の請求書 #INV-7890 を調査してください。不一致はありますか)」
     • 物流エージェント宛て: 「顧客 X の追跡番号 #TN-12345 を確認してください。出荷された部品番号と正しい部品の現在の在庫を確認してください。」
     • プロビジョニングエージェント宛て: 「Check service status for account #ACC-5678. If disconnected, what is the reason code? (アカウント #ACC-5678 のサービスステータスを確認してください。切断された場合、理由コードは何ですか?)」
  3. 専門エージェントの実行: 各エージェントは A2A 要求を受信し、それぞれのシステムに照会して応答を策定します。
  4. 合成: エージェントは、A2A 応答を介して調査結果をオーケストレーターに報告します。オーケストレーターは「顧客は実際に $50 の過剰請求をしました。倉庫のエラーにより誤ったパーツが配送されました。請求の問題によりサービスが自動的に切断されました。」
  5. 受領確認: オーケストレーターがお客様に問題を通知し、次のステップに関する明確な指針を示して人間のサービス担当者に問題をエスカレーションすることを提案します。
  6. 解決策: 次に、サービス担当者に完全なソリューションを提案して承認を求めます。サービス担当が会話に参加します。サービス担当は、エージェントの推奨ソリューションである「迅速な配送で右側の部品の新しい配送注文を作成します。誤った部品の返品を開始します。新しい注文で10%の割引を承認し、最新の改良バージョンの部品をアップセルします。支払情報を更新し、定期的な請求のセットアップを提案します。

レシピ

このレシピでは、複数の側面が含まれる複雑なカスタマーサービスの問題に対処するために設計されたコラボレーションエージェントシステムの実装の概要を説明します。オーケストレーターエージェントを使用して、A2A プロトコルを介して ToDo を専門のエージェント (請求、物流、プロビジョニング) に委任し、その結果を合成することで、包括的なソリューションを提供し、最終承認と顧客とのやりとりのためにサービス担当者をシームレスに統合します。

設計時間

1. 顧客が Web ページで Agentforce ウィンドウを開くことができるように、拡張チャットを顧客のチャット エントリ ポイントとして設定します。
2. Agentforce 請求エージェントをセットアップします。これは、注文または請求書を受け取り、請求照会を実行できるヘッドレスの専門エージェントです。

   テンプレートからエージェントを作成

   →

   Billing の問い合わせトピックの定義

   →

   カスタムフローアクションの作成

   →

   トピックへのアクションの追加

   1. Agentforce を有効にして、Agentforce 従業員エージェントテンプレートから従業員エージェントを作成します。
   2. 「請求書の不一致、支払の問題、および請求エラーの調査」という説明を使用して、トピック「請求照会」を定義します。
      1. [Check Invoice Discrepancy (請求書の不一致を確認)] カスタムフローアクションを追加します。このアクションには、[請求書番号]、[顧客 ID]、[日付範囲] の入力と、[不一致金額]、[根本原因]、[影響を受けるトランザクション] の出力が含まれます。
3. Agentforce Logistics Agent を設定します。これは、出荷の確認、出荷の追跡、在庫の確認ができるヘッドレスの専門エージェントです。

   テンプレートからエージェントを作成

   →

   「配送確認の定義」トピック

   →

   カスタムフローアクションの作成

   →

   トピックへのアクションの追加

   1. Agentforce を有効にして、Agentforce 従業員エージェントテンプレートから従業員エージェントを作成します。
   2. トピック「Shipping Verification (納入先検証)」を定義し、請求書の納入先を検証するための説明を入力します。
      1. [Verify Shipping Details (納入先の詳細を確認)] カスタムフローアクションを追加します。このアクションには、請求書番号、顧客 ID、日付範囲の入力と、出荷済み部品、日付、在庫状況の出力が含まれます。
4. Agentforce Provisioning Agentを設定します。これは、プロビジョニングとサービス状況を検証できるヘッドレスの専門エージェントです。

   テンプレートからエージェントを作成

   →

   「サービスチェックの定義」トピック

   →

   カスタムフローアクションの作成

   →

   トピックへのアクションの追加

   1. Agentforce を有効にして、Agentforce 従業員エージェントテンプレートから従業員エージェントを作成します。
   2. トピック「Service Check (サービスチェック)」を定義して、サービスの接続とアカウントの状況を確認する説明を入力します。
      1. カスタムフローアクション [Verify Service (サービスを検証)] を追加します。このアクションには、[Customer Id (顧客 ID)] と [Asset Id (納入商品 ID)] の入力と、[Service Status (サービス状況)] と [Service Exception Reason (サービス例外理由)] の出力が含まれます。
5. 請求、物流、プロビジョニングエージェントを A2A サーバーとして公開し、エージェントレジストリに登録します。

   MuleSoft を使用してエージェントを公開

   →

   レジストリへのエージェントの登録

   1. Agentforce Agent で直接 A2A がサポートされていない場合、MuleSoft コネクタを使用してエージェント API を A2A サーバとして公開できます。
   2. これらの A2A サーバーをエージェントレジストリに登録します。
   3. エージェントのオーケストレーションには Anypoint Agent Fabric を使用します。
      1. MuleSoft Agent Brokerは、エージェントカードに記載されているエージェント機能に基づいて、プラットフォーム間でエージェントをオーケストレーションするのに役立ちます。
6. Agentforceヘルプ エージェントを設定します。これは、顧客とやりとりし、複雑さを評価し、複数の専門エージェントと連携して問題を解決する対話型のAIエージェントです。

   サービスエージェントの作成	→	調査トピックの定義	→	通知アクションの作成	→	オーケストレーショントピックの定義
   						↓
   エスカレーショントピックの定義	←	[ケースを作成] アクション	←	[通話エージェントを作成] アクション	←	エージェントオーケストレーションフローの作成
   ↓
   オムニチャネルフローの作成	→	エスカレーション用のフローの接続

   1. Agentforce を有効にし、Agentforce Builder で会話を処理してカスタムアクションをトリガーするサービスエージェントを作成します。
   2. トピック Service Investigation を説明と手順を使用して定義し、通常は複数の問題が同時に発生した複雑なトピックをエージェントが自然に認識できるようにします。
      1. カスタムエージェントアクションを作成。
         • 問題を認識し、進捗状況を更新するステータス通知アクション
   3. アクションを使用して他のエージェントをコールできるオーケストレーショントピックを定義します。
      1. フローアクションをコールする通話エージェントアクションを作成します。フローアクションには複数のエージェントアクションがあり、ヘッドレス請求エージェント、物流エージェント、プロビジョニングエージェントをそれぞれ開始できます。
      2. ケースの作成、詳細の追加、状況の設定を行う [ケースを作成] アクションを作成します。
   4. サービス担当者にエスカレーションする説明を含むエスカレーショントピックを定義します。
   5. アウトバウンドオムニチャネルフローを作成して有効化します。
      • エージェントの Connections タブに追加し、エスカレーションメッセージとともにエスカレーションします。

エージェントオーケストレーションプロセスフロー

Anypoint Code Builder でエージェントブローカーの作成がサポートされるようになりました。エージェントブローカーは、ドメイン間でエージェントを接続し、最適なエージェントとツールをエンゲージするインテリジェントなルーティングおよびオーケストレーションレイヤーです。MuleSoft 開発者エージェントは、ブローカーの基盤を設定するコードを生成します。

以前にエージェントレジストリに登録されたエージェントカード (A2A サーバー) に記載されているエージェント機能に基づいて、追加の設定は Anypoint Code Builder によって自動的に行われます。最後に、このエージェントブローカーをクラウドにリリースできます。

エージェントブローカーが使用できると、これらの要求は適切なエージェントに転送されます。ブローカーはプロンプトを受信し、LLM を使用してタスクに分解し、最初に呼び出すエージェントを決定します。各反復ループで、元のプロンプトに正常に対応したかどうか、またはジョブを完了するために追加のエージェントと連携する必要があるかどうかを判断します。

エージェントランタイムプロセスフロー

エージェントを設定してリリースすると、実行時に次の一連の手順が実行されます。

1. チャット起動: 顧客が Agentforce チャット (組み込みサービス) を開きます。顧客がログインした後、セッションおよび取引先責任者コンテキストが読み込まれます。
2. 挨拶とインテント: エージェントが顧客に挨拶します。顧客は明らかに不満を感じており、過剰請求、誤った部品、切断されたサービスについて通知します。
3. CRM lookup: エージェントは [Get Latest Order (最新注文を取得)] アクションをトリガーし、Salesforce (注文概要/注文) に顧客の最新のレコードを照会します。その後、エージェントはコンテキストで注文を確認し、調査することを顧客に通知します。さらに、請求書 ID、請求書に関連付けられた追跡番号、サービスに関連する納入商品 ID が検索されます。
4. **オーケストレーターの有効化:**オーケストレーター エージェントがエスカレーションと注文IDを受信し、ケースを作成します。コンテキストデータを3つのエージェント（請求エージェント、物流エージェント、プロビジョニングエージェント）に渡して通信します。
5. 請求エージェント応答: 請求エージェントは、部品、単価、合計の詳細と共に返します。また、注文の部品と請求書の部品の不一致も記録されます。請求エージェントは、注文内の部品の価格と超過請求の理由を検索します。
6. ロジスティクスエージェント応答: ロジスティクスエージェントが、出荷された部品の詳細と、タグ付けの問題により誤った部品が送信された可能性があることを示す、ロジスティクスシステムによって作成された例外メモと共に返します。また、ロジスティクスエージェントは、問題が修正され、元のバージョンおよび新しいバージョンで正しい部品が入手可能になったことを確認します。
7. プロビジョニングエージェント応答: プロビジョニングエージェントは、サービス切断の詳細と期限切れの支払情報に関する問題を返します。また、支払情報を更新するように顧客にアドバイスするために送信される通知も提供されます。
8. **オーケストレーター統合:**オーケストレーター エージェントは、これらすべてのエージェントからの回答を統合し、各問題のKnowledge記事を参照してソリューションを構成します。まず、誤った部品の情報を検索し、返品を開始します。次に、解決ポリシードキュメントに基づいて問題の割引を提供し、顧客が購入できる新しいバージョンへのアップグレードも推奨します (ただし、価格差があります)。さらに、顧客からの新しい支払情報が必要であるため、解決を伝えるためにサービス担当者にエスカレーションします。
9. **エスカレーション:**オーケストレーターエージェントがサービス担当者にエスカレーションし、必要なすべてのコンテキスト、調査メモ、解決策の推奨事項を必要な承認と共に提供し、サービス担当者に電話連絡します。
10. Human in the loop: サービス担当は、お客様の忍耐に感謝し、問題をお詫びして、問題を説明します。その後、サービス担当は補償として部品の 10% 割引を提供し、新しいアップグレード部品とその利点を顧客に通知します。最後に、切断について説明し、新しい支払情報を取得してシステムを更新します。
11. **プロアクティブ リストア:**AIエージェントは会話を監視し、サービスのリストア、アップグレードされた部品の注文、割引と調整後の価格を使用した新しい請求書の作成に対してプロアクティブに対応します。
12. ケースクローズ: 最後に、概要をまとめ、ケースを更新してクローズします。

エージェントを効果的に機能させるには、広範なエンタープライズデータおよびツールと統合できる必要があります。これにより、エージェントが設定された目標を達成するために必要な重要なコンテキストが提供されます。Agentforceフレームワークは、Salesforceの内部と外部の両方のデータを統合する高度な統合アーキテクチャを提供します。

このセクションでは、エージェントをこれらのリソースに接続するパターンについて説明します。これらのパターンは、インテグレーションの 2 つの基礎的なアプローチに基づいて構築されています。

• 内部インテグレーション (データアクセスとツールアクセス): Salesforce エコシステム内のリソースの場合、エージェントの操作には 2 つの方法があります。
  • データアクセス: AgentforceコアランタイムはData 360と緊密に統合されており、内部のデータサービスを_直接_照会できます。データグラフに対するクエリをネイティブに作成および実行して、顧客の全体像を把握したり、RAGを使用してセマンティック検索を実行して非構造化Knowledgeを把握したり、Data 360クエリAPIを使用して一括情報にアクセスしたりできますこのダイレクトパスは、データ取得の速度と柔軟性を高めるために最適化されています。
  • ツールアクセス: タスクに複雑なビジネスロジックや複数ステップのプロセスが含まれる場合、または厳格なガバナンスが必要な場合、その機能はアクションにカプセル化されます。Apexまたはフローで構築されたこれらのアクションにより、エージェントは安全で再利用可能なインターフェースを使用して、データを参照するだけでなく、レコードの更新、プラットフォーム・イベントのトリガー、確立されたビジネス・プロセスの実行も実行できます。
• 外部インテグレーション (MCP/A2A): エージェントが Salesforce の外部 (たとえば、外部アプリケーション、マイクロサービス、または別のエージェントから) で情報を必要とする場合、**モデルコンテキストプロトコル (MCP) を使用します。**このオープンスタンダードは、相互運用性のための共通言語を提供します。MCP サーバは、AgentExchange から追加することも、管理者がエージェント レジストリまたは Apex コールアウトで MCP サーバに追加することもできます。次に、このアクションは外部 MCP サーバーへの要求を開始し、内部と外部を構造化して橋渡しします。同様に、エージェントが別のエージェントと通信する必要がある場合、**Agent2Agent(A2A)**プロトコルによってこのやりとりが容易になります。これにより、専門のエージェントが協力して複雑な問題を解決し、モジュール性と再利用性を促進する複雑なマルチエージェントシステムを構築できます。

次のパターンは、エージェントが必要とする特定のデータインテグレーションのテーマについて整理されています。MCPを使用した外部アプリケーションへの接続から、Data 360内の直接アクセスと正式なアクションの強力な組み合わせを使用したData 360の大量一括データ、リアルタイムのトランザクションレコード、非構造化コンテンツへのアクセスに至るまで、これらのパターンがどのように個別のデータの課題を解決するかを説明します。

問題

エージェントの有効性は、外部ツールの操作能力によって異なります。ただし、従来のERPから最新のSaaSアプリケーションまで、これらのツールには共通言語がありません。それぞれに固有の API、認証モデル、データ形式があります。これにより、開発者は、エージェントが使用する必要があるすべての新しいツールについて、カスタムのポイントツーポイントインテグレーションを構築および管理するという脆弱で拡張性のないサイクルに陥ります。

コンテキスト

破損した出荷ケースの解決を担当するエージェントについて考えてみます。成功するためには、3つの異なる外部システムとやりとりする必要があります。つまり、サプライヤーのAPIを照会して代替在庫を確認したり、物流パートナーのサービスをコールして新しい配送を手配したり、財務システムにアクセスしてクレジットを処理したりする必要があります。共通のプロトコルがない場合、エージェントは 3 つの個別のカスタム統合を必要とし、それぞれが潜在的な障害ポイントとなります。MCP は、これらのインタラクションをシームレスで信頼性の高いものにするための標準化された通信レイヤーを提供します。

MCP を介して公開された外部サービスをエージェントに統合する方法を次に示します。

レシピ 1: MCP を使用した外部ツールの有効化

問題

組織は従来のERPと最新のSaaSを組み合わせて運用していますが、共通のプロトコルがないためエージェントとの統合は困難です。各ツールには独自のAPI、認証、データモデルがあります。開発者は、ツールごとにカスタムのポイントツーポイントコネクタを作成・管理する必要があるため、脆弱で拡張性に乏しく、コストのかかる統合が生み出されます。

パターン

エージェントは構造化されたアクションを介して (MCP を介して) 外部ツールを呼び出すため、Salesforce Platform 以外の特殊なツールを使用できます。

コンテキスト

• エージェントは、Salesforce Platform の外部に存在するツールセットのプロキシとして機能します。
• これらの外部ツールには、さまざまな API、認証メカニズム、データ形式がある場合があります。
• エージェントとこれらの外部ツールとのシームレスなやりとりを可能にするには、標準化された通信プロトコルが必要です。
• 同じ外部ツールを複数のエージェントがさまざまな目的で使用する可能性があるため、再利用性は重要な懸念事項です。

接触

1. トリガー： Agentforce 内のユーザ要求または内部イベントでは、外部ツールを使用する必要があります。
2. 行動の意図: Agentforce エージェントがその意図を識別し、外部 MCP ベースのツールが必要であると判断します。
3. プランナー (内部): Agentforce エージェントのプランナーは、設定された手順と使用可能なツールに基づいて適切な MCP ツールまたはアクションを選択します。
4. **実行:**Agentforce Agent が MCP 準拠要求を外部 MCP サーバに送信します(たとえば、MuleSoft エンドポイントへの Apex コールアウトを介して、外部 MCP サーバに転送します)。
5. 外部処理: 外部 MCP サーバは要求を処理し、基盤となる外部アプリケーションとやりとりして、MCP 準拠の応答を準備します。
6. 結果:外部 MCP サーバが応答を Agentforce Agent に返します。
7. フォローアップ: Agentforce エージェントが応答を処理し、内部状態を更新して、タスクを続行するか、ユーザにフィードバックします。

トレードオフ

エージェントの意思決定ロジックは、基礎となるデータによってのみ機能します。エージェントがインテリジェントに行動するためには、周囲の状況をリアルタイムにかつ十分に把握している必要があります。データ取り込みアーキテクチャが定義されていないと、エージェントは機能するために不可欠な大量のリアルタイム情報にアクセスしたり、処理したりできません。

エージェントとのトランザクションデータの統合

問題

エージェントは、記録システムに存在する個々のレコードに対して低レイテンシの参照・更新操作 (ケースの更新や注文状況の取得など) を実行する必要があることがよくあります。これらのアクションでは、基盤となるデータモデルの一貫性を確保するためにデータの整合性と信頼性が必要です。アーキテクチャのコアとなる課題は、脆弱なポイントツーポイント統合を作成することなく、このトランザクションデータアクセスに安全でリアルタイム、かつスケーラブルなパターンを提供することです。

コンテキスト

エージェントをこれらのレコードに正常に接続するには、複数のコアコンポーネントで構成される堅牢なアーキテクチャが必要です

• **トランザクション システム:**これらは、Salesforce、Workday、SAPなどの記録システム、AWSなどのプラットフォームでホストされるサービスなどの信頼できるデータ ソースです
• 統合レイヤー: 通常**、MuleSoft** によって処理される強力な統合レイヤーは、これらの異種システムに安全に接続し、データを変換して Agentforce プラットフォームに公開するために不可欠です。
• MCP サーバ: 相互運用性を確保するために、エージェントは MCP 標準を使用してこれらの外部システムと通信します。インテグレーションレイヤーは、外部サービスまたはエージェントをホストするさまざまな MuleSoft、Heroku、またはサードパーティ MCP サーバーに接続できます。
• Agent Exchange: このコンポーネントはディレクトリまたはスイッチボードとして機能し、Salesforce エージェントが正しい外部サービスまたはエージェントを検出して安全に接続し、タスクを実行できるようにします。

レシピ 1: MCP を使用した直接レコード操作

パターン

エージェントは MCP を使用してトランザクションデータシステムに接続し、特定された特定のレコードに対して、即時整合性要件を備えたステートフル CRUD 操作を実行します。

コンテキスト

• 対話型のコラボレーションエージェントは、ワークフロー内でシステム・オブ・レコードのデータをトランザクション処理する必要があります。
• システム・オブ・レコードは外部システムです。
• トランザクションは冪等である必要があります。

キーコンポーネント

• Agentforce Agent: トランザクションの更新に関するトピックと手順。アクションは、外部 MCP サーバまたは Agentforce Exchange が登録した MCP サーバをコールします。
• MCP サーバ: トランザクションデータと関数を公開する MCP サーバ (入力データを含む tool=billing.update_record など)
• 外部記録システム: ステートフルな変更が行われるシステム

接触

1. トリガー： レコードのトランザクションを必要とするコマンドまたはイベントが発生しました。
2. インテント: Agentforce エージェントが状態変更インテントを識別します。
3. プランナー (内部): プランナーが MCP ツールを選択します。
4. Execute: このツールは、ポリシーレベル、レコードレベル、および項目レベルのアクセスチェックに合格した後に実行されます。
5. 結果: MCP サーバが応答を返す
6. フォローアップ: Agentforce エージェントが応答を処理します。

トレードオフ

レシピ 2: MuleSoft API を使用した複雑なオーケストレーション

パターン

エージェントは MuleSoft API を使用して、複雑で複数ステップのクロスシステムアトミックトランザクションを実行します。これにより、単一の管理エンドポイントが提供され、信頼性の高いエンドツーエンドの処理が保証され、個々のシステムへの直接コールに関連する一貫性、信頼性、レイテンシ、データの問題が回避されます。

コンテキスト

• 対話型エージェントと自律型エージェントは、多くの場合、複数の操作を確実に実行する必要があります。
• 1つのトランザクションには、複数のトランザクションシステムと操作が存在します。
• ワークフローには、トランザクション/ロールバック、再試行、ポリシー適用が必要です。
• トランザクションの要件は、リアルタイム性、冪等性、可観測性、そしてコンプライアンス（準拠）です。

接触

1. **トリガー：**コマンドまたはイベントが発生したため、複雑なトランザクションを完了する必要があります。
2. インテント： Agentforce エージェントがインテントを識別します。
3. プランナー (内部): プランナーは、API アクションまたは API アクションの呼び出し可能なアクションを選択します。
4. **Execution:**API が実行され、応答が返されます。
5. フォローアップ: Agentforce エージェントが応答を処理します。

トレードオフ

分析データとエージェントの統合

問題

組織は分析インフラストラクチャ (データウェアハウスやレーク、リアルタイム分析システム、ビジネスインテリジェンスプラットフォーム) に多額の投資をしてきましたが、AI エージェントはこれらのシステムから切断されたままです。これにより、エージェントがより豊富なコンテキストを得て（たとえば、前四半期に顧客が3回部品を返品したなど）、より適切な意思決定（この場合はエスカレーション）ができるようにするためのギャップが生じます。

コンテキスト

エージェントの業務インテリジェンスは、根本的に異なるデータ形式とソースから情報を統合できることから生まれます。したがって、このアーキテクチャパターンは1つのユースケースのためではなく、基礎的なデータ取り込みフレームワークとして設計されています。効果的なエージェントは、構造化されたソースを処理して論理的なデータ主導の分析を実行するために装備する必要があります。エージェントには、大量の構造化フィードへのアクセス権が必要です。これには、エンタープライズ データ レイクとの統合(Data 360とのゼロ コピー統合を使用)、ミドルウェア変換されたデータ ストリームの処理、CSVなどのバッチ ファイルの取り込みが含まれます。

レシピ 1: Data 360 Zero-Copy を使用して統合されたデータレイク

問題

従来のデータパイプラインを使用してデータレイクに保存されている分析データをコピー、管理、変換する場合、組織はコスト高に直面します (Snowflake など)。これまで、分析はほとんどオフラインであったため、タイムリーなアクションを実行する機会を逃していました。

パターン

エージェントは、重要なインサイトを外部データウェアハウスに照会するのではなく、Data 360 で使用できるゼロコピーデータ (および計算済みインサイト) を照会します。これにより、エージェントは、より良い意思決定のために、Transactional と分析の両方のデータを活用できます。

コンテキスト

• 組織では、顧客データと業務データをデータウェアハウスとレイクに保存しています。
• エージェントには、集計された総計値、履歴トレンド、分析インサイトへのアクセス権が必要です。
• エージェントのコンテキストにはトランザクションデータと分析データの両方が必要です (リサーチエージェントの履歴トレンドデータの必要性を考慮します)。

接触

1. トリガー: エージェントが、分析データまたは計算済みインサイトへのアクセスを必要とするインサイトに関するクエリを受信しました。
2. **実行:**エージェントはクエリ API を介して Data 360 Calculated Insights をコールするアクションを実行し、計算済みインサイトが返されます。
3. フォローアップ: Agentforce エージェントが応答を処理します。

トレードオフ

レシピ 2: データストリームからのアクションのトリガー

問題

組織は、Web サイトの訪問、通話、ミーティング、チャット、センサーデータなどのビジネス活動から価値のある情報を継続的に生成します。ただし、これらのやりとりが使用可能になったり、データウェアハウスから取得されたりするようになると、重要なインサイトが失われ、タイムリーな介入の機会は失われます。結果として、組織はリアルタイムで必要なアクション可能なインテリジェンスの大部分を見逃し、多くの場合、これらの一時的なストリームに埋もれてしまいます。これにより、ギャップが生じたり、コーチングの機会を逃したり、状況を完全に把握せずに意思決定を行ったりします。

パターン

エージェントは、データアクションを使用してストリーミングインサイトまたは Data 360 のリアルタイムインサイトからリアルタイムまたはほぼリアルタイムのインサイトを受信します。または、エージェントは、Apache Flink などのリアルタイム処理エンジンとインターフェイスする MCP サーバに照会して、ストリーミングインサイトにリアルタイムでアクセスします。

コンテキスト

• プラットフォームイベント、Pub/Sub API、RTEM などのストリーミングシステムは、大量のストリームデータを生成します。
• Data 360 や Apache Flink などのストリーム処理システムは、これらの個々のイベントを到着時に処理します。
• Agentforce はストリームシステム（たとえば、追加コンテキストを含むライブミーティングの最新の 30 秒のトランスクリプト）をクエリする必要があるか、データアクション（不正行為の検出など）によってトリガーされます。
• ほぼリアルタイムの、低レイテンシのアクションが必要です。

接触

1. ストリーム排出: ソース システムはデータの連続ストリームを排出します。
2. ストリーム処理: Data 360 や Apache Flink などのストリーム処理エンジンで情報が処理されます。
3. 変換: インサイトは、ミドルウェア (複雑な変換用) または Data 360 でエージェント対応データに集約、変換、合成されます。
4. ストリームインサイトイベント: Data 360 データアクションは、合成データ (30 秒のオーディオストリームのトランスクリプトなど) に対してトリガーされます。
5. 強化: エージェントがコンテキストを追加してインテントを検出します。
6. 実行: エージェントがアクションを実行します。
7. フォローアップ: エージェントは次のストリーミングインサイトを待機します。

トレードオフ

セマンティックデータとエージェントの統合

企業には、さまざまな形式や形状のビジネス・アーティファクト（カタログ、マニュアル、ポリシー、Knowledgeグラフ、リレーションシップ・マップ）があります。単純なタスクの実行を超えて高度な推論を行うためには、エージェントはほとんどの人間の知識が保存されているこのデータを理解できなければなりません。

レシピ1: RAG: エージェントの非構造化データの能力を引き出す

問題

組織は、エージェントが自信を持ってアクセスする妨げとなる検索不能な情報を所有していることがよくあります。この欠陥により、エージェントからの応答が不完全になることが多く、信頼を確立するために必要なコンテキストの深さや検証可能な引用が不足しています。そのため、エージェントが一貫してセマンティックに関連する正確なコンテンツを取得できるように標準化された方法が必要であることは明らかです。

パターン

このパターンは、エージェントが内部ドキュメントから公開 Web コンテンツまで、さまざまな非構造化情報を取り込んで解釈できるようにするアーキテクチャを提供します。エージェントにこのデータへのアクセス権を付与することは、市場センチメント分析、ドキュメントの概要、競合他社の調査などの高度な機能を活用する鍵となります。

コンテキスト

• 知識は、さまざまな形式や形態のファイルに格納されています。
• 冗長なコンテンツは、これらのドキュメントで一般的です。
• エージェントには、引用できる正確な情報が必要です。
• Knowledgeは頻繁に変更されるため、ファイルの更新とインデックスの再作成が必要です。

接触

コンテンツをそのままエージェントが取り込んだり、使用したりすることはできません。エージェントがコンテンツを取得して使用するには、コンテンツがチャンク化され、埋め込まれ、ベクトルデータベースに保存され、インデックス付けされる必要があります。

取り込みと準備

1. ソースをクロールして取り込む: ソースは、手動で識別する方法 (PDF ファイルをアップロードする方法など) と、その場所で識別する方法 (AWS S3 など) があります。
2. チャンク: 取り込まれたコンテンツは、効率的な処理と取得を促進するために、管理しやすい小さなチャンクに分割されます。ドキュメント全体ではなく、最も関連性の高い情報のみが取得されるため、これは RAG にとって重要なステップです。
3. 埋め込み: 各チャンクは、特殊な言語モデルを使用し_て埋め込み_と呼ばれる数値表現に変換されます。これらの埋め込みはテキストの意味を捉え、類似性に基づく検索を可能にします。
4. ベクトルストレージ: 埋め込みは、Data 360 ベクトルストアに保存されます。Data 360 ベクトルストアは、ハイパフォーマンスの類似性検索用に最適化された特殊なデータベースです。これにより、エージェントは関連コンテンツをすばやく見つけることができます。
5. インデックス付け: コンテンツとその埋め込みはベクトルストア内でインデックス付けされるため、すぐに検索できます。

Data 360 取得関数

• コンテンツを取得: この関数は、クエリを入力として受け取り、Data 360 ベクトルストアに対してセマンティック検索を実行して、最も関連性の高いコンテンツチャンクを見つけます。
• コンテンツの絞り込み: この機能により、取得したコンテンツをドキュメントの種類、著者、日付などのメタデータに基づいて絞り込み、結果をさらに絞り込むことができます。
• コンテンツのランク付け: この関数は、類似性スコア (ベクトル検索)、キーワードスコア、またはその両方の組み合わせ (ハイブリッド検索) に基づいて、取得されたコンテンツチャンクをランク付けします。

取得および生成

• クエリ: エージェントが情報を必要とする場合、ベクトルに埋め込まれたクエリも作成します。
• セマンティック検索: エージェントは Data 360 ベクトルストアに対してセマンティック検索を実行し、クエリの埋め込みと保存されたコンテンツチャンクの埋め込みを比較します。これにより、ベクトルスコアまたはハイブリッドスコア (ベクトルとキーワードの組み合わせ) に基づいて、意味的に最も関連性の高いチャンクが取得されます。
• RAG (Retrieval-augmented Generation: 取得されたコンテンツチャンクは、元のクエリと共に Agentforce Agent にコンテキストとして提供されます。LLM はこのコンテキストを使用して、精緻で検証可能な引用ができる回答を生成します。
• 応答および引用: エージェントは生成された回答 (多くの場合、元のソースドキュメントまたは Web リンクへの引用を含む) を提示して、信頼を築き、検証できるようにします。

トレードオフ

レシピ2： データグラフ： エージェントの事前選定された構造化グラフデータ

問題

組織はサイロ化されたリレーションデータを所有していることが多く、エージェントがそれを取得するのを妨げています。この問題は、さまざまなエンティティの接続方法に関する Trust を構築するための十分なコンテキストの詳細がない応答をエージェントが不完全にしてしまうことがよくあります。また、エージェントが複数のデータベースから情報を取得する必要がある場合に遅延が発生する原因にもなります。

パターン

このパターンは、エージェントが内部 CRM データから外部 Knowledge グラフに至るまで、さまざまな構造化および半構造化されたリレーション情報を取り込んで解釈するためのアーキテクチャを提供します。エージェントにこのデータへのアクセス権を付与することは、Customer 360ビュー、複雑な依存関係の分析、動的なコンテキスト構築などの高度な機能を実現するための鍵となります。

コンテキスト

1. リレーションデータはさまざまなシステムや形式に分散しています。
2. エージェントはエンティティ (顧客、ケース、注文、関連商品など) 間の接続を理解する必要があります。
3. Knowledgeグラフと接続されたデータ モデルは、複雑なリレーションを理解するために不可欠です。
4. エージェントには、引用可能なエンティティリレーションに関する正確な情報が必要です。

接触

エージェントが効果的に照会して使用するには、リレーショナルデータをハーモナイズしてグラフ構造で表す必要があります。

取り込みと準備

1. クロールおよび取り込みソース: データソース (CRM システム、ERP、外部 API、CSV など) が識別され、Data 360 に取り込まれます。
2. データハーモナイゼーション: 未加工データは、Data 360内のDMO(データモデルオブジェクト)にマッピングされ、その構造を標準化して統合ビューを作成します。
3. ID解決: 重複する顧客プロファイルが統合され、関連レコードがリンクされて、各顧客の1つの正確なビューが作成されます。
4. データグラフ作成: DMO を接続して、さまざまなエンティティ間のリレーションを表すデータグラフを作成します (たとえば、顧客 DMO はケース DMO に接続され、ケース DMO は商品 DMO に接続されます)。このグラフにより、リレーションを効率的にトラバースできます。
5. 計算済みインサイト: 集計指標と派生属性 (顧客の合計購入履歴など) が計算され、より豊富なコンテキストのためにデータグラフに追加されます。

取得および生成

1. クエリ: エージェントがエンティティ間のリレーションに関する情報を必要とする場合、データグラフに対してクエリを作成します (「What are all open cases for this customer and what products associated with this customer? (この顧客のすべてのオープンケースと、それらに関連付けられている製品は何か?)」など)。
2. グラフトラバースおよびクエリ API: エージェントは Data 360 Query API を使用してデータグラフをトラバースし、クエリに基づいて接続済みレコード、計算済みインサイト、および関連属性を取得します。
3. コンテキスト生成: 取得されたリレーション認識データは、元のクエリと共に Agentforce Agent にコンテキストとして提供されます。LLM は、この強化されたコンテキストを使用して、データの相互接続性を反映する正確で正確、かつ引用可能な回答を生成します。
4. **応答および引用:**エージェントは、生成された回答 (多くの場合、応答を通知したデータグラフ内の特定のレコードまたはリレーションを参照) を提示して、Trust を構築し、検証できるようにします。

トレードオフ

企業は、AI エージェントが主導する自動化とインテリジェンスの新時代の最先端に位置しています。単純な顧客問い合わせへの対応から、複雑なビジネス戦略の自律的実行まで、エージェントは生産性と顧客エンゲージメントを再定義することを約束します。Salesforce Agentforce Platformは、この変革に不可欠な信頼性の高い基盤を提供します。Agentforceは、宣言型ツールとプロコード ツールの堅牢なスイート、統合されたデータ プラットフォーム、A2AとMCPを通じたオープン標準への取り組みにより、あらゆるタイプのエージェントを構築するための包括的で信頼できる基盤を提供します。このアーキテクチャにより、組織は単独でなく、接続されたパートナーとして機能するインテリジェントな目標指向のエージェントをリリースして、測定可能なビジネスの成功を促進できます。

Salesforce では、高度なエージェントを構築するための基盤として機能する、Agentforce プラットフォームで統合された強力なツールセットが提供されています。このドキュメントのレシピと例は、Agentforce プラットフォームの機能とエージェントの相互運用方法に精通していることを前提としています。このセクションでは、このドキュメントのレシピとパターンを最大限に活用するために理解する必要がある主要なコンポーネントについて再説明します。

このセクションでは、Agentforce でエージェントを作成するアーキテクトと開発者にとって不可欠なプラットフォームの基本機能について説明します。

• Salesforce フロー: エージェントロジックを定義するための主要なツールです。宣言型のビジュアルインターフェースは、エージェントが実行するステップを調整するのに最適です。
• Apex: 複雑なカスタムロジック、自律エージェントの状態管理、複雑なインテグレーションに対応
• プラットフォームイベント: A2A プロトコルのトランスポート層として機能する、プロアクティブおよびコラボレーションエージェントの神経系。
• Data 360: エージェントの統合長期記憶。インテリジェントなアクションに必要なコンテキストを提供し、検索拡張生成 (RAG) の基盤となります。
• MuleSoft: MCP を介したシステムインテグレーションとクロスプラットフォームのエージェントコミュニケーションの両方を可能にする、エージェントと外部との橋渡し役。
• Slack: ToDo、通知、承認など、人間とエージェントのやりとりを行う主画面
• Agentforce チャットクライアント: 顧客対応の会話型エージェント向けのカスタマイズおよび組み込み可能なフロントエンド

エージェントが真に効果的に機能するためには、エージェントをサイロ化することはできません。Agentforce は、2 つのコア相互運用性パターンを採用しています。

• Agent2Agent (A2A) 通信: このプロトコルは、Salesforce エコシステム内のエージェントが相互に通信する方法を制御します。Agentforce プラットフォームは A2A クライアントとサーバの両方として機能し、それぞれ要求の実行とリスンを行います。これは、コラボレーションエージェントのスウォームに不可欠です。エージェントは、特定のスキルを持つ他のエージェントを検出して呼び出すように関連エージェントを使用して設定できるため、動的で拡張可能なシステムを作成できます。プラットフォームイベントは、これらの A2A メッセージの耐久性のある非同期転送メカニズムとして機能します。

• モデルコンテキストプロトコル (MCP): この標準により、エージェントが 1 つのプラットフォームにロックされることがありません。MCP では、異なるフレームワークで構築されたエージェントがコミュニケーションできる共通のメッセージ形式が定義されています。このモデルでは、**Agentforce は MCP クライアントとして動作します。**たとえば、Salesforce エージェントは MCP 準拠の要求を送信することで、複雑な物流計算を専門とする外部エージェントに照会できます。MuleSoft はゲートウェイとして機能し、内部 A2A 要求を外部 MCP 形式の API コールに変換して、企業全体でシームレスな相互運用性を確保します。