--- schema_version: "1" id: 8a8bc705e2a516d3cbb7ae1903be5fc3bb9bea5bfa701a7b0094e4e6eaec5aaf title: Agentic パターンと Agentforce を使用した実装 collection: architect version: next locale: ja-jp portal_url: https://docs.salesforce.com/architect/next/ja-jp/fundamentals/guides/agentic-patterns.md canonical_url: https://staging.architect.salesforce.com/docs/architect/ja-jp/fundamentals/guide/agentic-patterns.html source_site: staging.architect.salesforce.com content_type: documentation content_hash: 74a627b515513ef9d708d00d84fa2ac0fbac235bd18e85001b1345fdba4d07f8 products: - 基礎 - Architect Site Content Repo updated_at: 2025-10-01T00:00:00Z --- ## アブストラクトソフトウェアのパラダイムは、直接操作からゴール指向の委任に移行しつつあります。この変革の最前線にあるのは、AI エージェントです。AI エージェントは、ユーザーに代わって理解、推論、アクションを行うことができる自律的なインテリジェントなエンティティです。このホワイトペーパーでは、主要な種別の AI エージェントの技術的な探索について説明します。対話型、プロアクティブ、アンビエント、自律、コラボレーション。各タイプを定義し、CRM(顧客リレーション管理)の具体的な使用事例を示し、Salesforce _Agentforce_ Platform でこれらのエージェントを構築するためのアーキテクチャのブループリントを提供します。また、フロー、Apex、Data 360、Agent2Agent(A2A)通信、MCP(モデルコンテキストプロトコル)の相互運用性を活用する技術例も紹介します。 ## Chapter 1:AI エージェントの分類 AI エージェントは、環境を認識し、特定の目標を達成するためにアクションを実行するシステムです。この概念は新しいものではありませんが、強力な大規模言語モデル (LLM) の登場により、その機能が強化されました。エージェントは、その主な操作モードとインタラクションに基づいて分類できます。 ### 1.1 会話型エージェント **定義:**会話型のエージェントは、最も馴染みのあるエージェントです。主に自然言語インターフェース (テキストまたは音声) を介して、反応型の要求-応答方式で動作します。コア機能は、質問への回答、情報の取得、簡単なコマンドの実行など、ユーザーのインテントを理解して関連する応答を提供することです。 **重要度:**会話型エージェントは、組織のデジタルフロントドアです。明確に定義された反復作業の処理に優れているため、人的リソースを解放できます。有効性は、ユーザーのインテントをすばやく正確に解決し、ユーザーに代わってアクションを実行する能力によって測定されます。会話型エージェントの図

### 1.2 プロアクティブエージェント **定義:**プロンプトを待機する会話型エージェントとは異なり、プロアクティブなエージェントは用心深いオブザーバーとして機能します。これらは、特定のイベント、データの変更、またはシステム内の定義済みの条件によってトリガーされます。トリガーされると、ユーザーは直接操作することなく ToDo を実行するか、ワークフローを開始します。 **重要度:**プロアクティブなエージェントは、システムをデータのパッシブなリポジトリからビジネスプロセスのアクティブな関係者に変換します。商談やリスクが発生したときに特定できるため、企業は重要なシグナルにリアルタイムで対応できます。プロアクティブエージェントの図

### 1.3 アンビエントエージェント **定義:**アンビエントエージェントは、明示的なコマンドを必要とせずにユーザーのワークフローのバックグラウンドで継続的に動作する特定のタイプのプロアクティブエージェントです。多くの場合、ユーザーは操作を意識することなくアクションを利用できます。これは、これらのアクションは、ロープロファイルを維持しながら人間の能力を強化するように設計されているためです。 **重要度:**アンビエントエージェントの目標は、ありふれた「仕事に関する作業」を自動化することでユーザーの認知負荷を軽減することです。従業員が毎日使用するツールにシームレスに統合し、情報を自動的に取得して構造化することで、プロセスを効率化します。アンビエントエージェントの図

### 1.4 自律エージェント **定義:**自律エージェントは、複雑さを大幅に飛躍させます。高レベルの目標が与えられ、その目標を達成するための一連のステップを独立して計画および実行できます。ユーザーは、経時的なパフォーマンスを改善するために、推論や意思決定を行ったり、アクションから学習したりできます。 **重要度:**これは、真のデジタル従業員に最も近いものです。自律エージェントは、「この四半期に製造セクターで 50 件の新規適格リードを生成」などの複雑な複数ステップの目的を委任され、その達成に向けた計画を策定して実行できます。自律エージェントの図

### 1.5 コラボレーションエージェント (エージェントスウォーム) **定義:**コラボレーションエージェントは「エージェントスウォーム」と呼ばれることが多く、1 人のエージェントでは処理できない複雑な問題を協力して解決するための特殊なエージェントのコレクションです。多くの場合、「オーケストレーター」または「マスター」エージェントは、大きな ToDo を分解し、サブ ToDo を適切な専門エージェントに委任して、その出力を合成します。堅牢な Agent2Agent (A2A) 通信プロトコルでは、これを実現します。 **重要度:**このアプローチは、人間のチームを反映しています。複雑な問題を分解することで、各専門エージェントは独自のスキルを持つことができます。1 つはデータ分析、もう 1 つは顧客とのコミュニケーション、もう 1 つはシステムインテグレーションを専門とし、より堅牢で包括的なソリューションを実現します。コラボレーションエージェントの図

## Chapter 2:Agentforce アーキテクチャパターン AI エージェントの分類を探索しましたが、これらの要素をどのように組み合わせて、実際のビジネスの問題を効率的かつ確実に解決するか? という重要な疑問が残ります。この章では、一般的なエージェント設計パターンのリポジトリを提供することで、この質問に答えます。各パターンは繰り返し発生する課題に対する実証済みのソリューションであり、単純な単一目的のエージェントから複雑なコラボレーションエージェントスウォームまで、あらゆるもののブループリントを提供します。 ### 2.1 会話型エージェントパターン会話型エージェントは、多くの場合、組織の AI 機能のフロントドアです。これらは、ユーザーが自然言語を使用して ToDo を実行し、情報を取得するための主要なインターフェースとして機能する、ステートフルな複数ターンのダイアログに関与する機能によって定義されます。このセクションでは、会話型エージェントを構築するための 2 つの基本的なレシピを紹介します。1 つはメッセージングクライアントの迅速な対話型交換用、もう 1 つはメールの構造化された非同期用です。会話型エージェントのインテリジェンスは、適切なデータに適切なタイミングでアクセスし、推論できることから生まれます。このパターンは、顧客レコード、Knowledge Article、ビジネス分析に接続する高度なデータ基盤に依存します。これらのインテグレーションの完全な再利用可能なレシピは、[第 4 章を参照してください。Integration Patterns (インテグレーションパターン](#chapter-4エージェントのインテグレーションパターン))。 #### 2.1.a 会話型エージェント:インタラクティブメッセージングクライアントパターン **問題** お客様は多くのデジタルチャネルでエンゲージし、**即時、コンテキスト**に基づくインテリジェントな応答を期待しています従来のチャットボットは**スクリプト**形式か**データブラインドです。**そのため、パーソナライズが不十分で、早期に人間にエスカレーションされ、サービスコストが高くなる可能性があります。 **コンテキスト** - 組織にマルチチャネルデジタルエンゲージメント (WhatsApp、SMS、Slack、Salesforce Experience Cloud) がある。 - 組織の顧客は、[複数の言語](https://help.salesforce.com/s/articleView?id=ai.service_agent_considerations.htm&type=5)で組織とやりとりします。 - 組織では、次のようなエージェントを使用してサービスおよびセールスワークフローを強化する必要があります。 - 信頼できるリアルタイムの顧客データから取得 - ガードレールとコンプライアンス要件の遵守 - 必要な場合にのみ人間のエージェントにエスカレーションするインタラクティブメッセージングクライアントのパターン図

**主要コンポーネント** - **チャネルの抽象化：**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**

アスペクト	ゲイン	Cost (コスト)
応答速度	常時接続のインスタント返信	複雑なクエリでは 2 秒以上の遅延
精度	RAG を使用して実際のデータにグラウンディング	選定された最新のベクトルストアが必要
拡張性	ほぼ無限の同時会話	キャッシュ、対象、絞り込みによってコストを最適化する必要がある
柔軟性	自由形式のクエリを処理する	高度なプロンプトエンジニアリングが必要
ヒューマンタッチ	人間のサービス担当者は複雑なケースのみを処理する	エスカレーションしきい値が間違っていると、顧客のストレスを感じる
会話の多様性	異なるKnowledge、スキル、ツールを必要とする多数のインテント	精度と遅延を最適化するためにトピックと命令を継続的に調整する必要がある

**関連パターン** [Greeter パターン](/docs/architect/ja-jp/fundamentals/guide/enterprise-agentic-architecture#グリーターパターン):自然言語を使用してユーザーのインテントを理解し、ユーザーを適切なサービス担当者に転送するシンプルで実装しやすいパターン [Operator pattern](/docs/architect/ja-jp/fundamentals/guide/enterprise-agentic-architecture#演算子パターン):必要に応じてインテントをネゴシエートし、適切なスペシャリスト AI エージェントまたは人間のサービス担当者に要求を転送するためのグリーターを基盤とする [Orchestrator パターン](/docs/architect/ja-jp/fundamentals/guide/enterprise-agentic-architecture#orchestrator-パターン):AI エージェントスウォームを管理します。ユーザーの要求を受信し、インテントを判断して計画を作成し、必要なデータを 1 人以上のスペシャリストエージェントに渡してから、ユーザーの回答を集計します。Operator とは異なり、最初の連絡先のままです。 #### 2.1.b 会話型エージェント:対話型メールの会話パターン **問題** 顧客は主にメールベースの非同期会話を使用しますが、これはアウトリーチに最も適した方法です。組織ではこれらの顧客にメールで連絡する必要がありますが、営業担当は SLA 内の受信メールに返信できないため、リードを失う可能性があります。さらに、従業員は評価されていないリードに時間を費やします。 **コンテキスト** - 組織にリードエンゲージメントのプライマリチャネルとしてメールがある。 - SDR では、大規模にリードを評価するための業務量が制限されています。 - 営業プロセスでは、リードが SDR やビジネス開発担当者 (BDR) と会う前にマルチタッチでリードを育成します。 - 組織では、次のようなエージェントを使用してサービスとセールスを強化する必要があります。 - リアルタイムの販売イネーブルメントおよび販売商品およびマーケティングデータから取得 - ガードレールとコンプライアンスの遵守 - リード評価条件に基づいてミーティングをスケジュールするインタラクティブメールの会話パターン図

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

アスペクト	ゲイン	Cost (コスト)
応答速度	5 分未満の最初の応答 (8 ～ 24 時間)	電話に比べて初期アウトリーチのパーソナライズが低い
SDR 容量	リードカバー率が2~5倍に向上	早期のリレーション構築タッチポイントの喪失
適格性の一貫性	予算、権限、ニーズ、タイムライン (BANT) の対象範囲を非同期で取得	微妙なシグナルを見逃す可能性がある
コンテンツの精度	RAG で最新情報を保証	選定されたセールス商品とイネーブルメントライブラリが必要です。複数ターンは厳しい場合があります
ミーティングの変換	取引開始率が大幅に向上	BANT ギャップがある場合、品質の低いリードとのミーティングがある
コスト効率	人間の SDR よりもコスト効率が高い	開発コストとメンテナンスコスト

**関連パターン** [Answer Bot パターン](/docs/architect/ja-jp/fundamentals/guide/enterprise-agentic-architecture#アンサーボットパターン):キーワードだけでなく、生成 AI を使用して自然言語を理解し、Knowledge を取得するセルフサービスの効果的なパターン ### 2.2 プロアクティブなエージェントパターン前のセクションの会話型エージェントはユーザーコマンドへの反応に優れていますが、プロアクティブなエージェントは質問されることなく行動するというパラダイムシフトを表しています。このセクションでは、Salesforce の外部と内部の両方で発生するデータとイベントを自律的に監視するエージェントを作成するためのアーキテクチャパターンについて説明します。 #### 2.2.a プロアクティブエージェント:外部イベント応答パターン **問題** 組織が 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** - [外部システムで生成](https://developer.salesforce.com/docs/data/data-cloud-int/guide/c360-a-create-eventbusconnector-data-stream.html)され、営業担当に送信されるイベントデータを保存し、ストリーミングまたはリアルタイムのインサイトを変換および構築する **DLO や DMO** などの Data 360 コンポーネント - **計算済みインサイト、ストリーミングインサイト**、リアルタイムインサイトは、顧客に関する即時の関連データをエージェントに提供します。これにより、エスカレーションを軽減して、プリエンプティブな問題解決が可能になります。**データグラフ**により、さまざまなデータソースからのリレーションとインサイトがプロアクティブに表示され、顧客のエンゲージメント、活動、プロファイルに関連するパターンや異常を早期に検出できます。 - **Data 360 ベクトルストアと RAG**取得機能によって、関連するすべてのエンタープライズデータと非構造化 Knowledge 記事の統合ビューがエージェントに提供され、応答が正確でコンテキストに基づいてグラウンディングされます。 - **イベント対象** - 従業員への積極的な通知または顧客への連絡 - エージェントに拡張可能 (「[アンビエントエージェント](#23-アンビエントエージェントパターン)」および「[自律エージェント](#25-自律エージェントパターン)」パターンを参照) **接触** 1. 外部システムで重大な変更が発生します。 2. 外部システムがイベントを生成し、API (プラットフォームイベントを作成) または Pub/Sub API を介して Salesforce イベントバスに公開するか、イベントデータが Data 360 にストリーミングされます。 3. イベントの登録者がトリガーされます。フローがトリガーされた。 4. フローはイベントデータを使用して[エージェントアクションを](https://help.salesforce.com/s/articleView?id=platform.automate_flow_ref_elements_actions_generate_ai_agent_response.htm&type=5)コールします。エージェントは適切なアクション方針を決定し、実行します。 5. 結果は通知またはワークフローがトリガーされます。通知はコラボレーションツール (Slack など) でユーザーに配信されます。ToDo または行動も生成されます。さらに、アクションで外部システムをコールできます。そのため、イベントは失われるのではなく、プロアクティブに実行、シグナル、アクションが実行されるため、検出するための人的オーバーヘッドや複雑な自動化が排除されます。 **Trade-Offs**

アスペクト	ゲイン	Cost (コスト)
リアルタイムインテグレーション	イベントは数秒でアクションをトリガーします。	API 入力の複雑さ (パートナー SLA の変動)
インテリジェントな応答	CRM と外部コンテキストを使用した AI を駆使した意思決定	強化により、遅延や古いデータ (順序どおりでないイベントなど) が追加されます。
疎結合	Salesforce ロジックに依存しない外部システム	非同期処理によって最終的な一貫性が確保されます。
拡張性	バーストイベントを処理します。	API 制限、イベントストレージコスト
双方向	Salesforce は外部システムに対応できます。	外部 API 連動関係、障害シナリオ
セキュリティ	署名済み検証済みイベント、外部システムによる最小 (またはゼロ) 権限アクセス	リプレイ保護、鍵の循環、操作オーバーヘッド

**関連パターン** [Judge & Jury パターン](/docs/architect/ja-jp/fundamentals/guide/enterprise-agentic-architecture#審査員と審査員のパターン):このパターンと組み合わせて使用することで、複数の「陪審員」エージェントと「裁判官」エージェントを合同評価に活用して、AI を駆使した判断の正確性と信頼性を確保できます。 [Model of Models パターン](/docs/architect/ja-jp/fundamentals/guide/enterprise-agentic-architecture#model-of-models-モデルパターンのモデル):このパターンでは、複数のエキスパートエージェントの多様な視点を採用して、より豊富なインサイトを生成することで、プロアクティブな AI のインテリジェントな応答を補完できます。 #### 2.2.b プロアクティブエージェント:内部 Salesforce Platform イベント応答パターン **問題** 組織の Salesforce エコシステムではシグナルが常に生成されますが、ビジネスロジック、ガバナンス、人間が優先順位を付けて行動する必要があるため、タイムリーなコンテキストアクションに変換できません。多くの場合、シグナルはアクションなしで失われ、商談は失われます。 **コンテキスト** - 組織で 1 つ以上の Salesforce クラウドを使用している:セールス、サービス、マーケティング、コマース、健康、製造など。 - 単純なルーティングやルールベースのトリアージを超えたインテリジェントなトリアージが必要です。組織では、何百もの複雑なビジネスルールを管理しています。 - イベントへのリアルタイムまたはほぼリアルタイムの応答が必要です。 - 場合によっては、最も特権のあるシステム管理者がシグナルが表示されないためにチェーンの最も弱いリンクになることがあります。内部 Salesforce プラットフォームイベント応答パターン図

**主要コンポーネント** - **イベントソースレイヤー** - 低レベルのプラットフォーム活動からの CRM データ、プラットフォームイベント、変更データキャプチャ (CDC) データ、リアルタイムイベント監視 (RTEM) データ - **Data 360** - [CRM イベントまた](https://developer.salesforce.com/docs/data/data-cloud-int/guide/c360-a-create-eventbusconnector-data-stream.html)はプラットフォームイベントによって生成されたイベントデータを保存する **DLO や DMO** などの Data 360 コンポーネント。ストリーミングインサイトやリアルタイムインサイトを変換および構築します。 - **計算済みインサイト、ストリーミングインサイト、リアルタイムインサイト** は、顧客、従業員の活動、またはシステムのメタデータの変更に関する即時の関連データをエージェントに提供します。これにより、エスカレーションを軽減して、プリエンプティブな問題解決が可能になります。このリアルタイムの状況把握により、エージェントはガバナンスとコンプライアンスの運用スループットのためにタイムリーな介入を提供できます。 - **データグラフ**により、さまざまなデータソースからのリレーションとインサイトがプロアクティブに表示され、顧客のエンゲージメント、活動、プロファイルに関連するパターンや異常を早期に検出できます。 - **Data 360 ベクトルストアと RAG**取得機能によって、関連するすべてのエンタープライズデータと非構造化 Knowledge 記事の統合ビューがエージェントに提供され、応答が正確でコンテキストに基づいてグラウンディングされます。 - **Agentforce Agent:**エージェントの動作と目的は、次のコンポーネントで定義されます。 - **トピックと手順:**Salesforce 内のデータの変更に基づいてビジネスルールを適用し、プロセスを自動化するエージェントのミッションを指定します。エージェントの目的 (「交渉フェーズに達する前に主取引先責任者とすべての商談を更新する」など) と、エージェントをトリガーする特定のレコード作成、項目自動更新などが定義されます。 - **アクション:**内部 Salesforce イベントに応答するように設計されたイベントトリガーおよびスケジュール済みアクション。これらのアクションは日常業務では自律的に動作しますが、多くの場合、人の介入を伴うワークフローを調整し、レビュー、承認、または人の判断が必要なシナリオの処理のためにユーザーにエスカレーションする機能が含まれます。 - **ガードレール:**ガードレールは、エージェントの動作を制約する設定可能なルールとランタイムチェックのセットとして機能します。プロンプトを傍受し、エージェントの提案されたアクションを検証し、最終応答を絞り込んで有害なコンテンツを防止し、ビジネスルールを適用し、エージェントが指定された範囲内で業務を行うことができる安全レイヤーとして機能します。 - **プロンプトテンプレート:**差し込み項目または Data 360 RAG Retrievers のセマンティックデータを介してライブ CRM データが動的に入力される再利用可能なテンプレート。これらのテンプレートにより、エージェントはブランド情報に基づいたコンテキストのコンテンツを生成できます。一方、Einstein Trust Layer では、指示が LLM に送信される前に機密情報を安全にマスキングできます。 - **イベント対象** - 従業員に積極的に通知したり、顧客に問い合わせたりします。 - 他のエージェントをコールできる拡張性([環境 AI](#23-アンビエントエージェントパターン)および[自律 AI](#25-自律エージェントパターン)パターンを参照) **接触** 1. CRM レコードの更新、メタデータの変更、Data 360 からトリガーされたデータアクションなど、内部システム内で顕著な変更が発生します。 2. 内部システムがイベントを発行し、API (プラットフォームイベントを作成) または Pub/Sub API を介して Salesforce イベントバスに公開するか、イベントデータが Data 360 にストリーミングされます。 3. イベントのサブスクライバがトリガーされ、フローまたは Apex がアクティブ化されます。 4. 有効化されたフローまたは Apex が[エージェントアクションを](https://help.salesforce.com/s/articleView?id=platform.automate_flow_ref_elements_actions_generate_ai_agent_response.htm&type=5)コールします。 5. 結果は通知またはワークフローがトリガーされます。通知はコラボレーションツール (Slack など) でユーザーに配信されます。ToDo または行動も生成されます。さらに、アクションで外部システムをコールできます。 6. そのため、イベントは失われるのではなく、プロアクティブに実行、シグナル、アクションが実行されるため、検出するための人的オーバーヘッドや複雑な自動化が排除されます。 **Trade-Offs**

アスペクト	ゲイン	Cost (コスト)
リアルタイムインテグレーション	イベントは数秒でアクションをトリガーします。	レイヤーが増えると、単純なイベント処理で遅延が発生する可能性があります。
インテリジェントな応答	CRM と外部コンテキストを使用した AI を駆使した意思決定	強化により、遅延や古いデータ (順序どおりでないイベントなど) が追加されます。
疎結合	ファンアウト (登録者の増加) および拡張可能	非同期処理により、登録者間で最終的な一貫性が確保されます。
拡張性	バーストイベントの処理	API の制限
セキュリティ	プラットフォーム提供のTrustレイヤー	交渉不可能な業務オーバーヘッド

**関連パターン** [リスナー/フィードパターン](/docs/architect/ja-jp/fundamentals/guide/enterprise-agentic-architecture#リスナーフィードパターン):リスナーパターンと組み合わせて、Salesforce の内部イベントに基づいてプロアクティブなアクションをトリガーできます。 [Data Steward パターン](/docs/architect/ja-jp/fundamentals/guide/enterprise-agentic-architecture#データスチュワードパターン):プロアクティブな AI は、データスチュワードを使用して、内部イベントに対応するときのデータ品質と一貫性を確保できます。 [Zen Data Gardener パターン](/docs/architect/ja-jp/fundamentals/guide/enterprise-agentic-architecture#zen-data-gardener-パターン):内部イベントまたは定期的なトリガーによるスケジュール済みのプロアクティブなデータグルーミングと標準化 ### 2.3 アンビエントエージェントパターン会話チャネルで対話形式で応答するエージェントから開始し、特定のイベントに応答するエージェントへと進みました。プロアクティブなエージェントのイベント駆動型モデルを超えて、アンビエントエージェントは直接的なインタラクションからプロアクティブなバックグラウンド支援へのパラダイムシフトを表します。バックグラウンドでデジタル環境を監視するヘッドレスエージェントです。ユーザーの活動やデータストリームからコンテキストを認識し、他のエージェントや人間と連携して ToDo を完了したり、インサイトを表示したり、ガイダンスを提供したりするためのシステムの「目と耳」として機能します。 #### 2.3.アンビエントエージェント:バックグラウンドストリームオブザーバーパターン **問題** 組織のビジネス活動では、価値のある情報 (通話、ミーティング、チャット、センサーデータなど) が継続的に生成されますが、このデータはキャプチャや分析を行わずにリアルタイムで消去されます。人間がこれらのインタラクションを手動で文書化するまでに、重要なインサイトが失われ、タイムリーな介入が必要なタイミングが過ぎています。組織は、**リアルタイムで必要**なアクション可能なインテリジェンスの大部分を見落とし、一時的なストリームに埋もれてしまい、ギャップ、コーチングの機会の喪失、完全なコンテキストのない意思決定につながります。 **コンテキスト** - ビジネス活動では、音声およびビデオ会議、ライブチャット、センサーテレメトリ、画面活動、トランザクションデータなど、さまざまなソースから継続的なストリームが生成されます。 - これらのストリームに効果的に対応し、アクションを実行するには、リアルタイムまたはほぼリアルタイムのインサイト (数時間や数日ではなく数秒や数分以内) が必要です。 - コンプライアンスと更新頻度が低い、従業員の認知的負担が高い、重要な情報のキャプチャが不完全という特徴を持つ手動のドキュメント作成プロセスが失敗する。 - 音声、動画、画面共有、チャット、その他のメタデータからのデータを組み合わせて、インタラクションやイベントの完全かつ正確なコンテキストを作成するマルチモーダル理解が必要です。 - リアルタイムのコーチングとアラートのための即時分析と、インタラクション後の概要と長期的なトレンドの特定のための履歴分析の両方が必要です。 - データストリーム内のさまざまな時間枠の順序、タイミング、遷移、パターンの理解など、分析には一時的なコンテキスト (エピソードメモリ) が不可欠です。 **主要コンポーネント** - **ストリームソース** - 音声と動画:ビデオ会議ツール (Slack Huddle、Zoom、Google Meet、Microsoft Teams など) および電話システム - コラボレーションツール:Slack、Teams、その他 - **ストリームキャプチャコネクタ** - ネイティブ SDK:リアルタイムのストリームセグメントまたはトランスクリプトをサポートするトランスクリプトまたはメッセージの取得に役立つベンダー提供の SDK - **(省略可能) ストリーム処理レイヤー** - 音声ストリームの場合、トランスクリプトをリアルタイムで使用できない場合、音声をテキストに変換する音声-to-テキスト機能。Amazon Transcribe などの管理プロバイダーを使用することもできます。 - その他のデータストリームの場合、必要に応じて Data 360 や Apache Flink などのストリーム処理エンジン - **Data 360** - イベントデータを保存する **DLO や DMO** などの Data 360 コンポーネント。ストリーミングまたは[リアルタイムインサイト](https://developer.salesforce.com/docs/data/data-cloud-int/guide/c360-a-create-eventbusconnector-data-stream.html)の変換と構築を行います。 - **計算済みインサイト、ストリーミングインサイト**、リアルタイムインサイトは、顧客、その活動、重要なインサイトに関する即時の関連データをエージェントに提供します。これにより、エスカレーションを軽減して、プリエンプティブな問題解決が可能になります。このリアルタイムの状況認識により、エージェントはタイムリーな介入とパーソナライズされたサポートを従業員に提供でき、顧客満足度と業務スループットを最適化できます。 - 顧客データを保存し、リアルタイムのインサイトを変換および構築する **DLO や DMO** などの Data 360 コンポーネント - **Data 360 ベクトルストアと RAG**取得機能によって、関連するすべてのエンタープライズデータと非構造化 Knowledge 記事の統合ビューがエージェントに提供され、応答が正確でコンテキストに基づいてグラウンディングされます。 - **Agentforce Agents。**このパターンは、ライブ通話トランスクリプトやビデオフィードなど、連続的なデータストリームを監視するアンビエントエージェントに焦点を絞ります。リアルタイムリスナーとして機能し、発生した非構造化データを解釈します。たとえば、ライブ通話を聞いているエージェントがデータ検出エージェントを呼び出して、会話で共有された新しいコンテキストに基づいてリードのレコードを強化できます。このようなヘッドレスエージェントの例を次に示します。 - **フィードバックエージェント。**エージェントの動作と目的は、次のコンポーネントで定義されます。 - **トピックと手順:**会話ストリームを分析し、構造化されたフィードバックとパフォーマンス評価指標を抽出するためのエージェントの主任務を定義します。これには、顧客のセンチメントを監視し、主要な商品や競合他社へのメンションを特定し、人間のエージェントが会社のベストプラクティスやセールスプレイブックに従っているかどうかを評価する手順が含まれます。 - **アクション:**非構造化会話データをアクション可能なビジネスインテリジェンスに変換するアクション。これらのアクションにより、エージェントは「フィードバック概要」レコードの作成、商品機能要求の記録、マネージャーによるレビューに否定的なセンチメントを示す電話のフラグ設定、主要な評価指標に対するエージェントの全体的なパフォーマンスを追跡するダッシュボードの更新を行うことができます。 - **ガードレール:**ガードレールは、エージェントの動作を制約する設定可能なルールとランタイムチェックのセットとして機能します。プロンプトを傍受し、エージェントの提案されたアクションを検証し、最終応答を絞り込んで有害なコンテンツを防止し、ビジネスルールを適用し、エージェントが指定された範囲内で業務を行うことができる安全レイヤーとして機能します。 - **プロンプトテンプレート:**入力を受信し、LLM で生成された出力を提供できる構造化されたテンプレート化された LLM 命令 - **Ambience targets** (雰囲気目標) - ビデオ通話やデスクトップアプリケーションなど、エージェントとユーザーがいる場所でユーザーに通知 **接触** 1. ストリームが有効化されると (ユーザーがビデオ通話に参加した場合など)、エージェントは自分自身をオブザーバーとして添付します。 2. エージェントはストリームデータの受信を開始し、インテントを増分検出して意思決定を行い、アクションをコールします。 3. エージェントはインテントに基づいてコンテキスト化し、追加データ (構造化または非構造化) を取得します。 4. エージェントは、ユーザーを促すことなくジャストインタイムのリアルタイム応答を提供します。営業電話の異議申し立てを検出し、異議申し立てを処理するための重要な情報を提供できます。 5. エージェントは、統合された概要とアクションをまとめ、他のエージェントやユーザーと共有できます。 **Trade-Offs**

アスペクト	ゲイン	Cost (コスト)
ウィンドウサイズ	小ウィンドウ — 低レイテンシ、迅速なコーチング	また、コンテキストや精度も低い
処理モード	[リアルタイム] では、アシスタントの商談がすぐに表示されます。	リソースを大量に消費する
ストリーム解像度	高品質の音声と動画は精度は高くなりますが、遅延は増加します。	ストレージとコンピューティングの増加
保持期間	大量のデータをトレーニングやコンプライアンスに使用できます。	ストレージコストの増加、ノイズの発生
マルチモーダル	より豊富なコンテキストと総合的な理解	同期の複雑さ
アンビエンス	人間のユーザーに一貫したサポートを提供できる	プライバシー/ポリシーの適用

**関連パターン** [リスナー/フィードパターン](/docs/architect/ja-jp/fundamentals/guide/enterprise-agentic-architecture#リスナーフィードパターン):Listener パターンと組み合わせて、会話およびユーザーインタラクションデータのリアルタイムストリームを処理し、関連するコンテキストとインサイトを明らかにすることができる [Interrogator パターン](/docs/architect/ja-jp/fundamentals/guide/enterprise-agentic-architecture#取調官パターン):このパターンと組み合わせて使用することで、ストリーム内の複数のソースからコンテキストを収集し、質問に回答できます。 #### 2.3.b アンビエントエージェント:ユーザー活動の傍受パターン **問題** 従業員は、メール、カレンダー、通話、およびアプリケーション全体で毎日何百ものビジネスクリティカルな活動を実行しますが、これらの活動は手動で記録されるまで組織システムには認識されません。このようなことはめったにありません。この活動ブラインドは、CRM データが不完全であり、AI モデルにインテリジェントなおすすめに必要なシグナルがなく、マネージャーが顧客エンゲージメントをリアルタイムで把握できないことを意味します。手動活動ログでは、生産性税が発生しますが、実際の作業はほとんど欠落しています。 **コンテキスト** ストリームオブザーバーと同様に、アクション可能な ToDo を提供したり、ユーザーの代わりにアクションを実行したりするデータおよびコンテンツオブザーバーです。 **主要コンポーネント** - **データレイヤー** - **CRM データ**:エージェントにコンテキストを提供する CRM で使用可能な顧客データ (たとえば、ユーザーが商談ページを表示しているときに、エージェントは CRM から商談および関連付けられた取引先に関する情報を取得できます)。 - さまざまなソースから取り込まれた関連する顧客データを保存する **DLO や DMO** などの Data 360 コンポーネント - **計算済みインサイト、ストリーミングインサイト**、リアルタイムインサイトは、顧客、その活動、重要なインサイトに関する即時の関連データをエージェントに提供します。これにより、エスカレーションを軽減して、プリエンプティブな問題解決が可能になります。 - **Data 360 ベクトルストアと RAG**取得機能によって、関連するすべてのエンタープライズデータと非構造化 Knowledge の統合ビューがエージェントに提供されます。 - **Agentforce Agent:**このパターンは、UI 内でユーザーのアクションを直接監視するアンビエントエージェントに焦点を当てています。リアルタイムアシスタントとして機能し、ユーザーのワークフローのコンテキストを理解してガイダンスを提供します。たとえば、エージェントはサービス担当者がケースレコードに入力することを監視し、関連する Knowledge 記事を積極的に表示できます。このようなヘッドレスエージェントの例を次に示します。 - **フィードバックエージェント。**エージェントの動作と目的は、次のコンポーネントで定義されます。 - **トピックと手順:**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. エージェントは、これを他のエージェントやユーザーとシームレスに共有できます。 **Trade-Offs**

アスペクト	ゲイン	Cost (コスト)
範囲	幅広い活動範囲、エージェントがさまざまなモーダル (メール、カレンダー、アプリケーションページ) でコンテキストを共有可能	計算コスト
インテリジェントな自動化	モジュールにして完全に自律的な AI に拡張でき、ポリシーが明確であるループから人を排除できる	エージェント評価の増加。偽陽性やエラーのリスクは、妥当な期間で検出されなくなる可能性がある
代行受信の複雑さ	リアルタイム分析の恩恵を受けることができます。たとえば、詐欺や脅威を検出して取引を停止できます。	エージェントと人間のワークフローの同期が必要
コンテキスト深度	より深いコンテキストがインテリジェントな意思決定につながる	コンテキスト完全である必要がある
エージェントの自律性	ヘッドレスエージェントはユーザー入力を求めずにバックグラウンドで作業するため、摩擦を軽減	エージェントの意思決定の透明性が低下し、監査履歴が増える
マルチエージェント	ヘッドレスエージェントは連携して特殊なエージェントを形成できます。	ヘッドレスオーケストレーションとさらなる複雑さ

**関連パターン** [リスナー/フィードパターン](/docs/architect/ja-jp/fundamentals/guide/enterprise-agentic-architecture#リスナーフィードパターン):リスナーパターンと組み合わせて、観測された活動に基づいてプロアクティブなアクションをトリガーできます。 [Data Steward パターン](/docs/architect/ja-jp/fundamentals/guide/enterprise-agentic-architecture#データスチュワードパターン):活動傍受 AI はデータスチュワードを使用して、傍受された活動を記録するときのデータ品質と一貫性を確保できます。 [Generator パターン](/docs/architect/ja-jp/fundamentals/guide/enterprise-agentic-architecture#ジェネレーターパターン):代行受信された活動に基づいて活動概要やフォローアップ ToDo を自動的に生成するために使用できます。 ### 2.4 コラボレーションエージェントパターンこのセクションでは、1 人以上のエージェントが人間のユーザーと協力して共通の目標を達成するコラボレーションエージェントのパターンについて詳しく説明します。これらのレシピでは、シームレスなパートナーシップの構築に焦点が当てられています。エージェントは複雑なデータ収集と ToDo の実行を処理しながら、意思決定、承認、戦略ガイダンスをユーザーに提供します。このモデルでは、エージェントがワークフローの自動化可能な部分を処理します。このプロセスは動的なフィードバックループになります。 - 人間が会話型エージェントを介して ToDo を開始すると、プロアクティブエージェントがトリガーされてバックエンドステップが管理されます。 - 同時に、アンビエントエージェントがアクションを監視してリアルタイムのガイダンスを提供する場合があります。このプロセスにより、人とデジタルの作業のシームレスな融合が実現します。このパターンでは、Agentforce がマルチエージェントの Human-in-The-Loop (ループ内の人間) システムを容易にして、1 人のエージェント (または人間) だけでは管理できない複雑なジョブに対処する方法を示しています。 **問題** ビジネスプロセスでは、内部組織と外部組織の両方から、異なるスキルと優先度で異なる作業を実行する異なる組織の作業者間のコラボレーションが必要です。プロセスのボトルネックは、リソースの業務量、スキルの制約、またはやりとりされる情報の量によって、いつでもどこでも発生する可能性があります。 **コンテキスト** - プロセスはチーム全体にまたがり、成果を得るためには複数のチームメンバーがコラボレーションする必要があります。 - エージェントアシスタントは、会話型、プロアクティブ、アンビエントのエージェントとして、1 対 1 のシナリオですでに従業員をサポートしています。 - プロセスでは、ビジネスプロセスの適切な区分でエージェントを使用します。ただし、プロセスには人とエージェントのコラボレーションも必要です。このコラボレーションには、エージェントによる支援を伴う人間間コラボレーションと、エージェントによる人間間コラボレーションがあります。 - スキルのギャップはエージェントが埋めます。 - エージェントは、フォローアップや意思決定に役立つ重要な情報の交換などの作業で人的労力を削減することで、コラボレーションを改善します。 - エージェントは、ポリシーとガイドラインに基づいてコラボレーションや委任を行うこともできます。 **主要コンポーネント** - **コラボレーション表面** エージェントによるコラボレーションでは、すべての参加者 (人間とエージェントの両方) がやりとりできる共有スペースが必要です。これらのコラボレーション表面は、もはや静的な人間のみの環境ではありません。代わりに、エージェントを招待して参加させたり、寄稿したり、会話を開始したりできるチャネルであるため、チームワークの性質が根本的に変わります。たとえば、エージェントが Slack でケーススウォームを作成して開始し、人間の専門分野のエキスパートや他のエージェントをケースに関するコラボレーションに招待できます。 - **Agentforce エージェント** このパターンは、個々のエージェントパターンを超えて、コラボレーションエージェントモデルでどのように収束するかを示し、人間の能力をインテリジェントに増強する複雑なプロセスをオーケストレーションします。上記のパターン（会話型（2.1）、プロアクティブ（2.2）、および環境型（2.3））では、Agentforce Agent コンポーネントの方向を定義します。**会話型エージェント**は、人間の側で動作する主インターフェイスとして機能し、人間とコラボレーションに関与するすべてのエージェントとの間のインターフェイスとして機能します。ToDo が多面的すぎる場合、会話型エージェントがコラボレーションセッションを開始し、人間のユーザーと必要なヘッドレスエージェントが同時に問題に取り組みます。このプロセスは動的なフィードバックループになり、人間がタスクを開始して**プロアクティブエージェント**がバックエンドステップを管理し、**アンビエントエージェント**がリアルタイムのガイダンスを提供するために監視することで、人とデジタル環境の作業がシームレスに融合されます。 - **データレイヤー** コラボレーションエージェントモデルでは、データレイヤーは単に情報を提供するよりも動的な役割を果たします。つまり、人とエージェントチーム全体の永続的なメモリおよび共有ワークスペースになります。関連する各エージェントには、それぞれのパターンで定義されているように固有のデータニーズがありますが、複雑なタスクに関するコラボレーションは、ジョブ全体の状態を追跡する共有データ基盤に依存します。この共有状態は極めて重要です。ToDo が会話型エージェントからプロアクティブなエージェントに渡され、その後人間に承認が渡されるため、データレイヤーは各ステップでの進行状況、コンテキスト、決定を追跡する必要があります。これにより、すべての参加者が一貫した最新のエピソードを表示できます。 **接触** 1. 人間が他の人間やエージェントとコラボレーションセッションを開始します。 2. コンテキスト、目標、ジョブ、結果が定義されます。 3. エージェントは追加情報を取り込んでコンテキストを強化し、人間またはエージェントである所有者と共に作業を完了するために必要なステップを積極的に計画します。 4. 進行状況が観察され、コンテキストが更新され、アクションが実行されます。 5. エージェントが作業を実行する場合、エージェントは人間の関係者が推論を理解し、フィードバックを提供し、傍受を許可するのに役立つ詳細情報を提供します。 6. エージェントは完全な透明性とコンプライアンスで作業を完了します。 **Trade-Offs**

アスペクト	ゲイン	Cost (コスト)
ネイティブコラボレーションサーフェス	エージェントは作業の人的フローにすぐに参加して貢献できる	ユーザーの採用には追加のトレーニングと有効化が必要
双方向コンテキスト共有	エージェントはコンテキストを表示してすべての関係者と共有できるため、すべてのユーザーが情報を利用できるようになります。	意図的な非対称の機密情報には、追加の保護が必要です。
コラボレーション	エージェントはリアルタイムのコラボレーションを可能にし、フィードバックをすぐに提供し、解決時間を短縮します。	解決時間が短いほど、疲労につながる可能性のある人間の順番待ち作業が多くなります。
専門分野	ドメイン固有のエージェントは、価値の高い支援を提供します。	境界が設定されたコンテキストのニーズとドメイン固有性の増加。変化に適応する複雑さ
可観測性	理由の提供、監査証跡、エージェント評価によるTrustの構築	テレメトリコストの増加

**関連パターン** [Operator pattern](/docs/architect/ja-jp/fundamentals/guide/enterprise-agentic-architecture#演算子パターン):多くの場合、コラボレーションエージェントはオペレーターとして機能し、適切なスペシャリスト AI エージェントまたは人間のサービス担当者に要求を転送し、インテントを交渉します。 [Orchestrator パターン](/docs/architect/ja-jp/fundamentals/guide/enterprise-agentic-architecture#orchestrator-パターン):コラボレーションが関連するシナリオでは、オーケストレーターエージェントが AI エージェントのスウォームを管理し、応答を集計してシームレスなユーザーエクスペリエンスを実現します。 [ワークスペース (Radar O'Reilly) パターン](/docs/architect/ja-jp/fundamentals/guide/enterprise-agentic-architecture#ワークスペース-radar-oreilly-パターン):コラボレーションエージェントは、このパターンを使用して応答性の高い 1 か所の UX を管理し、会話フロー内で関連するコンテンツをリアルタイムに更新します。 ### 2.5 自律エージェントパターンユーザーを支援するコラボレーションパターンとは異なり、自律エージェントは完全な委任を目的として設計されています。このセクションでは、複雑な複数ステップの ToDo を独立して計画および実行し、人の介入なしで概要レベルの目標を達成できるエージェントのアーキテクチャ設計図について説明します。ここでは、最初から最後まで実行できる目標と Trust で ToDo できるシステムの作成に焦点を絞ります。 **問題** 組織は、ポリシーに基づく個別のジョブ、プレイブック、実行に必要な特定のスキルを備えた非常に複雑なプロセスセットで価値を実現します。これらは多くの場合、時間とリソースを大量に投資する必要があるプログラムです。新しいプログラムを設定するとオーバーヘッドが大きくなり、価値を実感するまでに数か月かかることがあります。フィードバックと改善を実装するには、追加の時間と労力が必要になることがよくあります。複雑さの主な原因は組織の構造にあり、分散アプリケーションとプロセスが連動して人間がプログラムを管理しなければならない場合があります。 **コンテキスト** - エージェントは最初から最後まで独立して操作できます。エージェントは、目標、計画、戦略が事前に設定されるように設計および設定されます。 - エージェントは、人間の承認を求めずにすべての意思決定を行うことができます。エージェントにはポリシーとコンプライアンスのガイドラインが提供されます。 - エージェントは必要なコンテキストとデータにアクセスでき、人間なしで必要なアクションを実行できます。 - 人間は通知されますが、「輪の中」ではありません。 **主要コンポーネント** - **目標と戦略定義レイヤー** - **プロセスプレイブック:**エージェントが従う必要がある確定的ルールを含む自律実行の詳細な説明 - **自律的な決定条件:**エージェントが人の承認なしで意思決定できるようにするルール - **代替ルール:**エージェントの主プロセスが失敗したときにデフォルトまたは例外シナリオを処理するための定義済みアクション - **範囲:**範囲外の状況の処理方法を含め、エージェントができることとできないことを明確に定義した境界 - **成功条件と done の定義:**エージェントの ToDo が正常に完了するタイミングを決定する評価指標と条件 - **Agentforce エージェント** - **エージェントオーケストレーターまたは振付家:**目標、理由、実行計画を所有する主エージェント - **トピックと手順**:ゴールが定義されると、オーケストレーターまたは振付師エージェントが中心になって、その全体的な目的を小さな管理可能なジョブまたはサブタスクに分割します。ジョブの順序の概要を示した包括的な計画を作成し、各ステップに必要な特定のエージェントまたはツールを特定します。最後に、オーケストレーターエージェントは、効率的かつ効果的に目標を達成するために、計画のシームレスな実行、進行状況の監視、連動関係の管理、必要に応じての調整を行います。振付家エージェントの場合、コンテキストと状態を下流のエージェントに渡して、ジョブを完了まで引き継ぎます。 - **アクション:**アクションは、機能の実行、データの取得、または他のヘッドレスエージェントへの委任を行うためのツールをコールし、幅広い機能とより複雑なワークフローを可能にします。 - **ガードレール:**ガードレールは、エージェントの動作を制約する設定可能なルールとランタイムチェックのセットとして機能します。プロンプトを傍受し、エージェントの提案されたアクションを検証し、最終応答を絞り込んで有害なコンテンツを防止し、ビジネスルールを適用し、エージェントが指定された範囲内で業務を行うことができる安全レイヤーとして機能します。 - **データレイヤー** - **CRM データ:**1 人以上のエージェントにコンテキストを提供する CRM で使用可能な顧客データ - さまざまなソースから取り込まれた関連する顧客データを保存する **DLO や DMO** などの Data 360 コンポーネント - **計算済みインサイト、ストリーミングインサイト**、リアルタイムインサイトは、顧客、その活動、重要なインサイトに関する即時の関連データをエージェントに提供します。これにより、メールバウンスの処理などのプリエンプティブな問題解決が可能になり、エスカレーションが軽減されます。 - **Data 360 ベクトルストアと RAG**取得機能により、関連するすべてのエンタープライズデータと非構造化 Knowledge の統合ビューをエージェントに提供 - 会話コンテキストを提供するケース履歴や会話エージェント履歴などの **Slack チャネルメッセージ**または会話データ - **監視と監視** - **エージェントの目標の進行状況の監視:**自律エージェントセッションの進行状況を追跡して、結果を測定し、目的と一致していることを確認する - **エージェント業務の監視:**介入とトラブルシューティングのために自律エージェントの状況をリアルタイムで追跡し、円滑な運用を確保 - **エージェントガバナンスの監視:**追跡ログと監査ログを追跡して、自律エージェントが定義済みの目標、目的、倫理ガイドラインに準拠していることを確認する **接触** 1. ジョブは明確な結果で定義されます。 2. ジョブは次のいずれかの方法で開始されます。 - エージェントに ToDo が割り当てられている。 - エージェントは、資格に基づいて積極的にジョブを選択します。 - エージェントはバックグラウンドでジョブを実行します。 3. エージェントは期待を明確に設定し、目標、計画、戦略の詳細を人間に通知します。この計画では、ステップごとのプロセス、使用されたエージェント、使用されたデータ、範囲、エージェント評価計画、および進行状況、運用、ガバナンスを監視するためのチェックポイントが詳細に示されます。 4. エージェントが実行を開始します。マイルストーンごとに、状態と進行状況が更新されます。人間には、必要に応じてフィードバックを提供したり、エージェントを代行受信したりする機能があります。 5. エージェントがジョブを完了します。結果と結果は監視ダッシュボードで使用できます。 **Trade-Offs**

アスペクト	ゲイン	Cost (コスト)
速度	エージェントが ToDo を数週間から数か月ではなく数時間から数日で完了	自律的なエージェント操作の有効化が必要
自治	エージェントが人の介入なしで完全な実行を達成	実行中は介入が制限され、コストがかかる
拡張性	エージェントの拡張が容易	リソースのロックを防止するには、レート制限を設定する必要があります。
一貫性	エージェントはガードレールを使用してポリシーに準拠する	新しいシナリオの処理では、正しい結果を確認するための検査が必要です。
Cost (コスト)	エージェントがループ内の人間を避ける	このプロセスの構築にはコストがかかる
人事	エージェントが重要なリソースと専門リソースを解放	エキスパートが実行を通じて経験的に把握できず、プロセスの改善点を特定する能力が低下する
品質管理	監視と確認が可能	エージェントエラーがすぐに検出されない場合、修復コストが高い
精度	エージェントはコンテキストとポリシーを使用して適切な意思決定を行うことができます。	あいまいさや古さを排除するために、コンテキストとデータを選定して管理する必要があります。

**関連パターン** [プロジェクトマネージャーパターン](/docs/architect/ja-jp/fundamentals/guide/enterprise-agentic-architecture#プロジェクトマネージャーパターン):多くの場合、自律エージェントはこのパターンを具体化し、最小限の人の介入で開始から完了までの長い複数ステップのプロセスを監督します。 [Configurer pattern](/docs/architect/ja-jp/fundamentals/guide/enterprise-agentic-architecture#コンフィグレーターパターン):自律エージェントはこのパターンを使用して、自然言語要件または定義済みポリシーに基づいて設定を自動的に生成および検証できるため、手動で監視することなくコンプライアンスと正確性を確保できます。 [Zen Data Gardener パターン](/docs/architect/ja-jp/fundamentals/guide/enterprise-agentic-architecture#zen-data-gardener-パターン):このパターンは、自律エージェントがスケジュールされたバックグラウンドデータのグルーミングと標準化に使用でき、経時的なデータ品質と一貫性を確保して、エージェントの正確な意思決定をサポートします。 ## Chapter 3:一般的なエージェント型 AI の使用事例では、エージェント分類とエージェントパターンを Salesforce Platform でどのように実装するかを見てみましょう。Agentforce のコアコンポーネントに精通していない場合は、この章以降で参照される主要なテクノロジーについて、[付録](#付録)を参照しておくと役立ちます。このセクションでは、エージェントの分類を取り上げ、一般的な使用事例を使用して各エージェントを説明し、実際のアプリケーションでエージェントがどのように使用されるかを示します。 ### 3.1 会話型エージェントの使用事例:インスタント注文状況顧客の Jane が会社の Web サイトにアクセスし、最近の注文状況を確認します。 - **インタラクション:**Jane がチャットウィンドウ (Agentforce チャットクライアント) を開きます。 - **エージェントアクション:**会話型エージェントが挨拶して、どのように役立つかを尋ねます。Jane は「最新の注文はどこですか?」と尋ねます。 - **プロセス:** 1. エージェントは、Salesforce からの Jane の顧客情報に基づいて、最新の注文を識別します。 2. 配送システムに (MuleSoft コネクタを介して) 最新の追跡情報を照会し、Jane にリアルタイムの更新と追跡リンクを提供します。 3. 次に、保険契約を検索し、自動的に迅速な配送にアップグレードします。 4. Jane がエージェントが処理できない複雑な質問をすると、チャットが人間のサービスエージェントにシームレスにエスカレーションされ、状況に応じた完全なトランスクリプトが提供されます。 **レシピ** 使用されるパターン:[対話型 AI パターン](#21-会話型エージェントパターン)、[トランザクションデータのエージェント](#42-データインテグレーションパターン)への統合 **設計時間**

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

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

Jane が Web ページで Agentforce ウィンドウを開くことができるように、拡張チャットを Jane のチャットエントリポイントとして設定します。
Agentforce を有効にし、Agentforce Builder で会話を処理してカスタムアクションをトリガーするサービスエージェントを作成します。
エージェントが「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. 両方のアクションをビルダーでサービスエージェントに追加し、「注文と追跡」トピックにリンクして公開します。
サービス担当者にエスカレーションする説明を含むエスカレーショントピックを定義します。
- 送信オムニチャネルフローを作成して有効化します。
- ビルダーの [接続] タブに追加して、エスカレーションメッセージと共にエスカレーションします。

オムニチャネルを設定します。

オムニチャネルの設定

→

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

→

優先度と業務量の設定

→

テストと検証

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

データインテグレーションを設定します。

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

→

MuleSoft API ログイン情報の作成

→

MuleSoft 外部サービスを登録

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

**エージェントランタイムプロセスフロー** エージェントを設定してリリースすると、実行時に次の一連の手順が実行されます。 1. **チャットの起動:**Jane が Agentforce チャット (組み込みサービス) を開きます。Jane がログインした後のセッションおよび取引先責任者コンテキストの読み込み。 2. **挨拶と意図:**エージェントが Jane に挨拶します。Jane が注文の状況を尋ねると、インテント検出によって「最新の注文」が \[注文と追跡] トピックに対応付けられます。 3. **CRM 参照：**エージェントは \[Get Latest Order (最新注文を取得)] アクションをトリガーし、Jane の最新レコードを Salesforce (注文概要/注文) に照会します。 4. **配送クエリ:**エージェントが指定ログイン情報を使用して MuleSoft API をコールすると、/shipping/status/{orderId}はリアルタイムの状況と追跡 URL を返します。 5. **応答構成:**Agentforce は結果をマージし、応答を構成します。注文 \[OrderID] は \[Carrier (運送業者)] 経由で出荷され、明日 \[Track Here (追跡)] で到着します。 6. **フォールバック:**一致または API エラーがない場合、エージェントは謝罪し、データの問題を修正するために再試行することを申し出ます。 7. **エスカレーション:**複雑なクエリや感情的なクエリは、オムニチャネルを介して自動的に人間に転送され、完全なチャットとコンテキストが渡されます。 8. **ログ:**すべてのインテント、アクション、結果はインタラクションログに保存されます。API 遅延は Anypoint Monitoring で監視されます。 9. **継続的な改善：**エスカレーションは Agentforce の再トレーニングにフィードされます。一般的なフローは後続のリリースで調整されます。 ### 3.2 プロアクティブなエージェントの使用事例:高価値カートの放棄価値の高い顧客 John が \$1,000 を超える商品をオンラインカートに追加したが、60 分以内に購入を完了しなかった。 - **トリガー:**John の取引先責任者 ID とカートの値を含む Salesforce Platform イベント Cart_Abandoned\_\_e が E コマースシステムから起動されます。 - **エージェントアクション:**このイベントに登録しているプロアクティブなエージェントは、すぐにアクションを実行します。 - **プロセス:** 1. エージェントが Salesforce で John のレコードを確認し、John が VIP 顧客であることを確認します。 2. John のアカウントマネージャーである Sarah の優先度の高い ToDo が作成され、放棄されたカートのすべての詳細が含まれます。 3. Sarah にフォローアップを促す通知が Slack 経由で送信されます。 4. 同時に、John を対象を絞った Marketing Cloud ジャーニーに登録し、期間限定の 10% 割引コードを含むリマインダーメールを送信して購入の完了を促します。 **レシピ** このレシピでは、Salesforce Platform でプロアクティブな AI エージェントを実装して、VIP 顧客による価値の高いカートの放棄に対処します。このソリューションは、Salesforce Platform Events、Knowledge 検索用の Data 360、Agentforce を活用して、タイムリーでインテリジェントなフォローアップアクションを調整し、パッシブデータをアクティブなビジネスエンゲージメントに変換します。 **設計時間**

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

カスタム取引先責任者項目の作成 → 新しいプラットフォームイベントの定義
1. Contact Id (取引先責任者 ID)、Cart Value (カート金額)、Cart Last Updated DateTime (カート最終更新日時)、および Cart Details (カートの詳細) フィールドを使用して Cart_Abandoned__e プラットフォームイベントを作成します。
2. 放棄イベントを設定します。Commerce Cloud を使用して、Checkout イベント通知のプラットフォームイベントを作成します。カート Checkout セッションの状態が中間状態であり、しきい値に達した後にセッションがタイムアウトした場合に、破棄が検出されます。または、E コマースが外部システムの場合は、次のいずれかの方法でイベントを Salesforce に公開します。フロー、Apex、Salesforce API、または Pub/Sub API。
3. Contact オブジェクトで、選択リスト値 Standard、Premium、および VIP を使用して新しいフィールド Customer_Tier__c を作成します。

Data 360 で非構造化データの取り込みを設定します。ドキュメントリポジトリをソースとする割引ポリシードキュメントを Data 360 に Amazon S3 で追加します。

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

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

VIP Cart Recovery エージェントを設定します。

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

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

エージェントをコールするようにプラットフォームイベントを配線します。

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

→

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

→

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

→

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

新しいプラットフォームイベントトリガーフロー「VIP Cart Abandonment Recovery」を作成します。
フローで登録する [カート破棄済み] イベントを選択します。
Flow Builder で呼び出し可能なカスタムエージェントを設定し、VIP Cart Recovery エージェントを選択します。顧客の VIP 放棄カートリカバリーを開始する要求を送信し、プラットフォームイベントペイロードを送信します。

**エージェントランタイムプロセスフロー** エージェントを設定してリリースすると、実行時に次の一連の手順が実行されます。

顧客がカートを破棄	→	Commerce Cloud でイベントを公開	→	プラットフォームイベントトリガーフロー	→	フローによる従業員エージェントの呼び出し
						↓
割引オファーの分析	←	マネージャーの ToDo を作成する	←	Slack のアラートマネージャー	←	エージェントが [回復] トピックを実行する
↓
顧客をジャーニーに登録	→	顧客がオファーを利用する	→	エージェントがフィードバックのために結果を分析

1. **カート放棄の検出:**John はカートに \$1,200 を追加し、60 分経過しても Checkout またはフェーズが進まなかった場合、破棄をトリガーします。 2. **プラットフォームイベントの公開:**Commerce Cloud は、John の取引先責任者 ID、カート金額 \$1,200、カート変更日、その他の詳細を使用して Cart_Abandoned\_\_e イベントを公開します。 3. **フローの初期化:**プラットフォームイベントによって、VIP カート放棄回復フローがトリガーされます。 4. **従業員エージェントの有効化:**フローが実行されると、VIP Cart Recovery エージェントが呼び出されます。 5. **トピックの実行：**エージェントは \[VIP カートをリカバリ] トピックを解決し、指示を実行します。 6. **通知の作成:**エージェントが Slack で John のアカウントマネージャー Sarah にアラートを表示します。 7. **ToDo の作成:**エージェントは Sarah の ToDo を作成し、実行するフォローアップについてアドバイスします。 8. **割引分析:**エージェントは、Data 360 取得関数をコールして、カート金額、顧客ランク、購入履歴に基づいて「最大許容割引」を要求することで、割引分析を実行します。この場合、この関数は 10% の割引提案を推奨します。 9. **メールの準備とジャーニーの登録:**エージェントは割引オファーメールを準備し、John を Marketing Cloud ジャーニーの VIP Customer Cart Recovery に新しいカート価格で登録します。 10. **ログと属性:**John が提案を利用すると、ログ属性とコンバージョン総計値が作成されます。 11. **フィードバック分析:**結果が分析され、提案、復旧までの時間、その他の最適化要素がさらに決定されます。 ### 3.3 アンビエントエージェントの使用事例:リアルタイムの営業電話アシスタンス営業担当の 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 サンプル](https://github.com/zoom/rtms-samples/tree/main/audio/send_audio_to_aws_transcribe_service_sdk))を設定します。その後、トランスクリプトはプラットフォームイベントとして Salesforce に公開されます。 **設計時間**

Sales Call Realtime Response エージェントを設定します。

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

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

Product Knowledge データライブラリを設定します。

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

→

Knowledge 記事の追加

→

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

→

グラウンドライブラリの動作

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

Pub/Sub API を使用してリアルタイムのトランスクリプトを Salesforce に公開します。

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

公開された Transcript_Segment__e イベントに登録するためのフローの配線。

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

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

**エージェントランタイムプロセスフロー** エージェントを設定してリリースすると、実行時に次の一連の手順が実行されます。

ユーザーが Zoom 通話を開始する	→	サーバーでの文字起こしと公開	→	フローが応答エージェントを呼び出す	→	Agent Querys Knowledge Base (エージェントが知識ベースを照会)
						↓
Analytics でエージェントのパフォーマンスを絞り込む	←	エージェントが通話の概要をまとめる	←	エージェントが引き続き聞く	←	エージェントが 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 retrieve：**エージェントは、\[Get Product Spec (商品仕様を取得)] アクションをトリガーし、Knowledge データに一致する回答を照会します。 6. **非公開 Slack DM の送信:**エージェントは \[Slack インサイトを送信] を実行し、David の Slack DM に投稿します。「Product _Toaster 2XP_ は Apple および Android デバイスと統合でき、Bluetooth で接続できます。アプリをインストールしたら、Bluetooth で接続してトースターを操作するだけです。マニュアルへのリンクはこちらです。」 7. **リアルタイムの継続：**エージェントは引き続きトランスクリプトテキストを受信します。複数のインサイトが見つかった場合、エージェントは通話フローを中断することなくコンテキストに応じた Slack 返信をスレッド化します。 8. **通話後の概要:**セッションの終了時に、エージェントは主要な質問、実行されたアクション、参照された商品の概要を自動的にまとめます。 9. **継続的な改善：**Agentforce Analytics は、トランスクリプトと応答の遅延、商品の一致精度、および販売結果を評価し、経時的なトピックの指示を調整します。 ### 3.4 自律エージェントの使用事例:地域のリードジェネレーション営業マネージャーの Bob は、自律エージェントに次のような目標を設定します。「カリフォルニアの製造部門の売上パイプラインを今後 60 日間で 500 万ドル増加させます。」 - **トリガー:**マネージャーが Slack のコマンドを使用して目標を割り当てます。 - **エージェントアクション:**自律エージェントは計画と実行のループを開始します。 - **プロセス:** 1. **調査:**エージェントは Salesforce Data 360 と外部データソースを (MuleSoft を介して) 照会し、現在の顧客ではないカリフォルニアの製造部門の企業を特定します。 2. **対象:**これらの企業を分析し、最近の資金調達ラウンド、新規役員の採用、関連する求人などの購入シグナルを探します。上位 20 件の見込み客にスコアを付けて優先度を付けます。 3. **取引先責任者の特定:**これらの会社の主要な取引先責任者 (業務統括責任者や工場長など) を検索します。 4. **アウトリーチ:**特定の会社のニュースや問題点を参照して、取引先責任者ごとにパーソナライズされたアウトリーチメールのドラフトが作成されます。次の週に送信されるようにスケジュールされます。 5. **フォローアップ:**メールの開封と返信を追跡します。見込み客からの肯定的な返信によってカレンダーの分析がトリガーされ、ミーティング時間が提案されます。確認後、Salesforce の行動と新しい商談が自動的に生成されます。 6. **レポート:**Slack で営業マネージャーに毎週の進行状況レポートが提供されます。 **レシピ** これは、各エージェントが特定のタスクを実行し、コンテキスト、データ、制御を次のエージェントに渡すマルチエージェントシナリオです。調査と評価にはいくつかのカスタムヘッドレスエージェントを使用し、見込み客へのアウトリーチと監視には標準のセールス開発担当 (SDR) エージェントを使用します。また、Bob の会社が市場調査に ZoomInfo を使用していることも想定します。また、データベースに保持され、パートナー企業に関する有益な情報が含まれるサプライヤーネットワークデータも受け取ります。 **設計時間**

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

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

→

適格性エージェントがリードをスコアリング

→

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

リサーチエージェント:MuleSoft を使用して Data 360 と外部ソースを照会する
適格性エージェント:リードの優先度付け、スコアリング、強化
SDR エージェント:リードの割り当て、アウトリーチの実行、フォローアップ、ミーティングのスケジュールを行います。Agentforce Analytics for SDR Agent を使用して、SDR エージェントの活動と進行状況を監視します。

新しい会社データを検出して取り込みます。

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

→

Salesforce CRM データの取り込み

→

ZoomInfo データの取り込み

→

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

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

ヘッドレス調査および適格性エージェントを開始するプラットフォームイベントを設定します。

新しいプラットフォームイベントの作成
1. 人間のユーザーの概要目標を取得する項目目標を使用して、新しい AgentGoal__e プラットフォームイベントを作成します。

ゴールオーケストレーターエージェントを設定します。これは、ユーザーのゴールを受信して他のエージェントに調整する会話型の AI エージェントです。

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

Agentforce 従業員エージェントテンプレートからエージェントを作成します。
このエージェントがゴールインテントを理解し、必要に応じて追加のエージェントをコールできることを示す新しいトピック [Parse Goal (ゴールを解析)] を追加します。
- 他のエージェントにゴールを解析してイベントをトリガーするトピック命令を追加します。
目標イベント AgentGoal__e を作成します。

オーケストレーションエージェントによってトリガーされるリードリサーチおよび評価エージェントを設定します。

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

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

アウトリーチ、リードナーチャリング、ミーティングスケジュールを実行するようにAgentforce SDRエージェントを設定します。

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

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

公開済み AgentGoal__e イベントを登録するための新しいフローを設定します。

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

→

[エージェント目標に登録] イベント

→

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

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

**エージェントランタイムプロセスフロー** エージェントを設定してリリースすると、実行時に次の一連の手順が実行されます。

ユーザーが概要目標を割り当てる	→	Orchestrator エージェントがイベントを作成する	→	フローが目標をエージェントに転送する	→	リサーチエージェントがリードを評価する
						↓
		Analytics を使用したエージェントの監視	←	SDR エージェントによるミーティングのスケジュール	←	SDR エージェントがアウトリーチを開始

- **目標の割り当て:**Bob は自律エージェントに「カリフォルニアの製造業のパイプラインを 60 日間で 500 万ドル増やす」ように依頼します。 - **目標オーケストレーション:**自律目標オーケストレーターエージェントが目標を受信し、インテントを解析して、プラットフォームイベント AgentGoal\_\_e を作成します。ゴールオーケストレーターエージェントは、複数のゴールを処理するように機能を継続的に拡張するように設計されています。拡張してオーケストレーション機能を追加したり、ユーザーに説明を求めたりして、インテントをより深く理解し、ゴールを開始したりできます。 - **ルーティング:**\[Flow Route Goals to Agents (エージェントへのフロールート目標)] がトリガーされ、Lead Research and Qualification エージェントがコールされます。 - **調査:**Lead Research and Qualification (リードリサーチおよび評価) エージェントは、Data 360 に新しいリード情報を照会し、既存の顧客に対して重複排除を行い、Data 360 から追加の市場調査データを取得してリードを強化します。リードをさらにスコアリングし、主要な取引先責任者を特定して、リードを評価します。 - **アウトリーチ:**リードが評価されると、リードの割り当てルールによってリードが SDR エージェントの対象になります。SDR エージェントは最初のアウトリーチを行い、商品に関連する質問に答えることで取引先責任者との会話を維持します。 - **フォローアップ:**ケイデンス終了時またはリードの要求時に、エージェントはリードがサービス担当者のエンゲージメントに適しているかどうかミーティングスケジュールの入力を求めます。その後、ミーティングをスケジュールしてフローを終了します。 - **Agent Analytics:**[SDR Agent Analytics](https://help.salesforce.com/s/articleView?id=sales.sales_agent_sdr_analytics.htm&type=5)ダッシュボードでは、エージェントのパフォーマンスの効率性に関するインサイトが提供されます。 ### 3.5 コラボレーションエージェントの使用事例:複雑なサービスのエスカレーション長年の顧客で、請求超過、受け取った交換部品の誤り、サービス切断という多面的な問題が発生している。 - **トリガー:**顧客がチャットを開始すると、最初の会話型エージェントは複雑さをすばやく認識し、エージェントのスウォームにエスカレーションします。 - **エージェントアクション:**オーケストレーターエージェントが担当します。 - **プロセス:** 1. **オーケストレーター:**顧客との会話を維持し、最新情報を提供する 2. **オーケストレーターの委任:**A2A プロトコル実装を使用して、オーケストレーターは必要な機能を備えた「関連エージェント」(請求、物流、プロビジョニング) を検出し、ToDo を派遣します。 - **請求エージェント宛て:**顧客 X の請求書 #INV-7890 を調査します。不一致はありますか? - To **Logistics Agent:**顧客 X の追跡番号 #TN-12345 を確認します。出荷された部品番号と正しい部品の現在の在庫を確認します。 - **プロビジョニングエージェント:**「アカウント #ACC-5678 のサービス状況を確認します。切断された場合、理由コードは?」 3. **専門エージェントが実行する内容:**各エージェントは A2A 要求を受信し、それぞれのシステムに照会して応答を作成します。 4. **合成:**エージェントは、A2A 応答を介して調査結果をオーケストレーターに報告します。オーケストレーターは次の情報を合成します。「顧客は実際に \$50 請求超過しました。倉庫のエラーにより、誤ったパーツが配送されました。請求の問題によりサービスが自動的に切断されました。」 5. **確認:**オーケストレーターは顧客に問題を通知し、次のステップを明確に示すことで、人間のサービス担当者に問題をエスカレーションすることを提案します。 6. **解決方法**次に、サービス担当者に完全なソリューションを提案して承認を求めます。サービス担当者が会話に参加します。サービス担当者は、エージェントの推奨ソリューションを含め、問題に関連するすべてのデータをすばやく確認します。「迅速な配送で右側の部品の新しい配送注文を作成します。誤った部品の返品を開始します。新規注文で 10% の割引を承認し、最新の改良バージョンで部品をアップセルします。支払情報を更新して、定期的な請求アレンジを設定する提案をします。」 **レシピ** このレシピでは、複数の側面が含まれる複雑なカスタマーサービスの問題に対処するために設計されたコラボレーションエージェントシステムの実装の概要を説明します。オーケストレーターエージェントを使用して、A2A プロトコルを介して ToDo を専門のエージェント (請求、物流、プロビジョニング) に委任し、その結果を合成することで、包括的なソリューションを提供し、最終承認と顧客とのやりとりのためにサービス担当者をシームレスに統合します。 **設計時間**

顧客が Web ページで Agentforce ウィンドウを開くことができるように、拡張チャットを顧客のチャットエントリポイントとして設定します。

Agentforce Billing エージェントを設定します。これは、注文または請求書を受け取り、請求照会を実行できるヘッドレスの専門エージェントです。

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

→

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

→

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

→

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

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

Agentforce Logistics Agent を設定します。これは、出荷の確認、出荷の追跡、在庫の確認ができるヘッドレスの専門エージェントです。

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

→

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

→

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

→

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

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

Agentforce Provisioning Agentを設定します。これは、プロビジョニングとサービス状況を検証できるヘッドレスの専門エージェントです。

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

→

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

→

[カスタムフローを作成] アクション

→

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

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

請求、物流、プロビジョニングエージェントを A2A サーバーとして公開し、エージェントレジストリに登録します。

MuleSoft を使用してエージェントを公開 → レジストリへのエージェントの登録
1. Agentforce Agent で直接 A2A がサポートされていない場合、MuleSoft コネクタを使用してエージェント API を A2A サーバとして公開できます。
2. これらの A2A サーバーをエージェントレジストリに登録します。
3. エージェントのオーケストレーションには Anypoint Agent Fabric を使用します。
  1. MuleSoft Agent Brokerは、エージェントカードに記載されているエージェント機能に基づいて、プラットフォーム間でエージェントをオーケストレーションするのに役立ちます。

Agentforceヘルプエージェントを設定します。これは、顧客とやりとりし、複雑さを評価し、複数の専門エージェントと連携して問題を解決する対話型のAIエージェントです。

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

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

**エージェントオーケストレーションプロセスフロー** Anypoint Code Builder でエージェントブローカーの作成がサポートされるようになりました。エージェントブローカーは、ドメイン間でエージェントを接続し、最適なエージェントとツールをエンゲージするインテリジェントなルーティングおよびオーケストレーションレイヤーです。MuleSoft 開発者エージェントは、ブローカーの基盤を設定するコードを生成します。以前にエージェントレジストリに登録されたエージェントカード (A2A サーバー) に記載されているエージェント機能に基づいて、追加の設定は Anypoint Code Builder によって自動的に行われます。最後に、このエージェントブローカーをクラウドにリリースできます。エージェントブローカーが使用できると、これらの要求は適切なエージェントに転送されます。ブローカーはプロンプトを受信し、LLM を使用して ToDo に分解し、最初にコールするエージェントを決定します。各反復ループで、元のプロンプトに正常に対応したかどうか、またはジョブを完了するために追加のエージェントと連携する必要があるかどうかを判断します。

Agentforce ヘルプエージェント	→	MuleSoft エージェントブローカー	→	A2A サーバーとしての請求エージェント	→	A2A サーバとしてのロジスティクスエージェント
						↓
		エージェントが応答を取得するためのサポート	←	Broker 集計応答	←	A2A サーバーとしての調達エージェント

**エージェントランタイムプロセスフロー** エージェントを設定してリリースすると、実行時に次の一連の手順が実行されます。

顧客がチャットを開始する	→	顧客が複数の問題を示している	→	エージェントが注文の詳細を調査する	→	オーケストレーターがスペシャリストエージェントをコールする
						↓
Orchestrator が解決プランを合成	←	プロビジョニングエージェントが問題を検出	←	物流エージェントがエラーを確認	←	請求エージェントが不一致を検出
↓
エージェントがサービス担当者にエスカレーション	→	サービス担当者が解決策を提示	→	システムエージェントが ToDo を実行する	→	エージェントがケースを更新してクローズする

1. **チャットの起動:**顧客が Agentforce チャット(組み込みサービス)を開きます。顧客がログインした後のセッションおよび取引先責任者コンテキストの読み込み。 2. **挨拶と意図:**エージェントが顧客に挨拶します。顧客が明らかにストレスを感じ、過剰請求、誤った部品、切断されたサービスについて通知する。 3. **CRM 参照：**エージェントは \[Get Latest Order (最新注文を取得)] アクションをトリガーし、Salesforce (注文概要/注文) に顧客の最新のレコードを照会します。その後、エージェントはコンテキストで注文を確認し、調査することを顧客に通知します。さらに、請求書 ID、請求書に関連付けられた追跡番号、サービスに関連する納入商品 ID が検索されます。 4. **オーケストレーターの有効化:**オーケストレーターエージェントがエスカレーションと注文 ID を受信し、ケースを作成します。コンテキストデータを 3 つのエージェント (請求エージェント、物流エージェント、プロビジョニングエージェント) に渡して通信します。 5. **Billing Agent 応答:**請求エージェントが、部品、単価、合計コストの詳細と共に返します。また、注文の部品と請求書の部品の不一致も記録されます。請求エージェントは、注文内の部品の価格と超過請求の理由を検索します。 6. **物流エージェント応答:**物流エージェントは、出荷済み部品の詳細と、タグの問題で誤った部品が送信された可能性があることを示す、物流システムによって作成された例外メモと共に返品します。また、ロジスティクスエージェントは、問題が修正され、元のバージョンと新しいバージョンで正しい部品が使用可能になったことを確認します。 7. **プロビジョニングエージェントの応答:**プロビジョニングエージェントがサービス切断の詳細と期限切れの支払情報に関する問題を返します。また、支払情報を更新するように顧客にアドバイスするために送信される通知も提供されます。 8. **オーケストレーター合成:**Orchestrator エージェントは、これらすべてのエージェントからの回答を合成し、各問題の Knowledge 記事を参照してソリューションを構成します。まず、誤った部品の情報を検索し、返品を開始します。次に、解決ポリシードキュメントに基づいて問題の割引を提供し、顧客が購入できる新しいバージョンへのアップグレードも推奨します (ただし、価格差があります)。3 つ目は、顧客からの新しい支払情報が必要であるため、解決を伝えるためにサービスリポジトリにエスカレーションすることです。 9. **エスカレーション:**オーケストレーターエージェントはサービス担当者にエスカレーションし、必要なすべてのコンテキスト、調査メモ、解決策の推奨事項を必要な承認と共に提供し、サービス担当者を通話に取り込みます。 10. **ループ内のユーザー:**サービス担当は、顧客の忍耐に感謝し、問題を謝罪して説明します。その後、サービス担当は補償として部品の 10% 割引を提供し、新しいアップグレード部品とその利点を顧客に通知します。最後に、切断について説明し、新しい支払情報を取得してシステムを更新します。 11. **プロアクティブなリストア：**AI エージェントは会話を監視し、サービスの復元、アップグレードされた部品の注文、割引と調整後の価格を含む新しい請求書の作成に積極的に対応します。 12. **ケースクローズ:**最後に、概要をまとめ、ケースを更新して、ケースをクローズします。 ## Chapter 4:エージェントのインテグレーションパターンエージェントを効果的に機能させるには、広範なエンタープライズデータおよびツールと統合できる必要があります。これにより、エージェントが設定された目標を達成するために必要な重要なコンテキストが提供されます。Agentforce フレームワークは、Salesforce の**内部**と**外部**の両方のデータを統合する高度な統合アーキテクチャを提供します。このセクションでは、エージェントをこれらのリソースに接続するパターンについて説明します。これらのパターンは、インテグレーションの 2 つの基本的なアプローチに基づいて構築されています。 - **内部統合 (データアクセスとツールアクセス):**Salesforce エコシステム内のリソースの場合、エージェントの操作には 2 つの方法があります。 - **データ・アクセス：**Agentforce コアランタイムは Data 360 と緊密に統合されており、内部のデータサービスを*直接*照会できます。**データグラフ**に対するクエリをネイティブに作成および実行して、顧客の全体像を把握したり、**RAG**を使用してセマンティック検索を実行して非構造化 Knowledge を把握したり、**Data 360 クエリ API**を使用して一括情報にアクセスしたりできますこのダイレクトパスは、データ取得の速度と柔軟性を高めるために最適化されています。 - **ツールアクセス:**ToDo に複雑なビジネスロジックや複数ステップのプロセスが含まれる場合、または厳格なガバナンスが必要な場合、その機能は**アクション**にカプセル化されます。Apex またはフローで構築されたこれらのアクションにより、エージェントは安全で再利用可能なインターフェースを使用して、データを参照するだけでなく、レコードの更新、プラットフォーム・イベントのトリガー、確立されたビジネス・プロセスの実行も実行できます。 - **外部インテグレーション (MCP/A2A):**エージェントが Salesforce の外部 (外部アプリケーション、マイクロサービス、別のエージェントなど) から情報を必要とする場合、**モデルコンテキストプロトコル (MCP)** を使用しますこのオープンスタンダードは、相互運用性のための共通言語を提供します。MCP サーバは[、AgentExchange](https://agentexchange.salesforce.com/) から追加することも、管理者がエージェントレジストリまたは Apex コールアウトで MCP サーバに追加することもできます。次に、このアクションは外部 MCP サーバーへの要求を開始し、内部と外部を構造化して橋渡しします。同様に、エージェントが別のエージェントと通信する必要がある場合、**Agent2Agent(A2A)**プロトコルによってこのやりとりが容易になります。これにより、専門のエージェントが協力して複雑な問題を解決し、モジュール性と再利用性を促進する複雑なマルチエージェントシステムを構築できます。次のパターンは、エージェントが必要とする特定のデータインテグレーションテーマについて整理されています。MCP を使用した**外部アプリケーションへの接続**から、Data 360 内の直接アクセスと正式なアクションの強力な組み合わせを使用した Data 360 の**大量一括データ**、リアルタイムの**トランザクションレコード**、**非構造化コンテンツ**へのアクセスに至るまで、これらのパターンがどのように個別のデータの課題を解決するかを説明します。 ### 4.1 ツールインテグレーションパターン **問題** エージェントの有効性は、外部ツールの操作能力によって異なります。ただし、従来の ERP から最新の SaaS アプリケーションまで、これらのツールには共通言語がありません。それぞれに固有の API、認証モデル、データ形式があります。これにより、開発者は、エージェントが使用する必要があるすべての新しいツールについて、カスタムのポイントツーポイントインテグレーションを構築および管理するという脆弱で拡張性のないサイクルを強いられます。 **コンテキスト** 破損した出荷ケースの解決を担当するエージェントについて考えてみます。成功するためには、3 つの異なる外部システムとやりとりする必要があります。つまり、**サプライヤーの API**を照会して代替在庫を確認したり、**物流パートナーのサービス**をコールして新しい配送を手配したり、**財務システム**にアクセスしてクレジットを処理したりする必要があります。共通のプロトコルがない場合、エージェントは 3 つの個別のカスタムインテグレーションを必要とし、それぞれに潜在的な障害点があります。[MCP は](#2エージェントの相互運用性a2a-および-mcp)、これらのインタラクションをシームレスで信頼性の高いものにするための標準化された通信レイヤーを提供します。 MCP を介して公開された外部サービスをエージェントに統合する方法を次に示します。 MCPツールを統合するレシピ

**レシピ 1:\*\***MCP を使用した外部ツールの有効化\*\* **問題** 組織は従来の ERP と最新の SaaS を組み合わせて運用していますが、共通のプロトコルがないためエージェントとの統合は困難です。各ツールには独自の API、認証、データモデルがあります。開発者は、ツールごとにカスタムのポイントツーポイントコネクタを作成して管理することになるため、脆弱で拡張性がなく、コストのかかるインテグレーションが生成されます。 **パターン** エージェントは構造化されたアクションを介して (MCP を介して) 外部ツールを呼び出すため、Salesforce Platform 以外の特殊なツールを使用できます。 **コンテキスト** - エージェントは、Salesforce Platform の外部に存在するツールセットのプロキシとして機能します。 - これらの外部ツールには、さまざまな API、認証メカニズム、データ形式がある場合があります。 - エージェントとこれらの外部ツールとのシームレスなやりとりを可能にするには、標準化された通信プロトコルが必要です。 - 同じ外部ツールを複数のエージェントがさまざまな目的で使用する可能性があるため、再利用性は重要な懸念事項です。 **接触** 1. **トリガー:**Agentforce 内のユーザ要求または内部イベントでは、外部ツールを使用する必要があります。 2. **行動の意図:**Agentforce Agent はインテントを識別し、外部 MCP ベースのツールが必要であると判断します。 3. **プランナー (内部):**Agentforce Agent のプランナーは、設定された手順と使用可能なツールに基づいて適切な MCP ツールまたはアクションを選択します。 4. **実行:**Agentforce エージェントが MCP 準拠要求を外部 MCP サーバに送信します(たとえば、MuleSoft エンドポイントへの Apex コールアウトを介して、MuleSoft エンドポイントが外部 MCP サーバに転送します)。 5. **外部処理:**外部 MCP サーバーは要求を処理し、基盤となる外部アプリケーションを操作し、MCP 準拠の応答を準備します。 6. **結果**:外部 MCP サーバは応答を Agentforce Agent に返します。 7. **フォローアップ:**Agentforce エージェントは応答を処理し、内部状態を更新して、タスクを続行するか、ユーザにフィードバックします。 **Trade-Offs**

アスペクト	ゲイン	Cost (コスト)
柔軟性	多様な外部機能へのアクセス	MCP サーバー/インテグレーションレイヤーの初期開発
モジュール性	エージェント機能は外部ツールから分離	慎重な API 設計とバージョン管理が必要
拡張性	外部システムの拡張性を使用	外部システムのパフォーマンスが連動関係になる
標準化	標準化プロトコル (MCP)	Adoption および/または wrapper
セキュリティ	外部アクセスのための一元化されたセキュリティ	外部システムのログイン情報とアクセスポリシーの管理
メンテナンス性	外部ツールの更新では、エージェントを変更する必要はありません。MCP で変更を知らせることができる	頻繁な変更のコスト

### 4.2 データインテグレーションパターンエージェントの意思決定ロジックは、基礎となるデータによってのみ機能します。エージェントがインテリジェントに行動するには、周囲の状況をリアルタイムに把握している必要があります。データ取り込みアーキテクチャが定義されていないと、エージェントは機能するために不可欠な大量のリアルタイム情報にアクセスしたり、処理したりできません。 **エージェントとのトランザクションデータの統合** **問題** エージェントは、記録システムに存在する個々のレコードに対して低レイテンシの参照・更新操作 (ケースの更新や注文状況の取得など) を実行する必要があることがよくあります。これらのアクションでは、基盤となるデータモデルの一貫性を確保するためにデータの整合性と信頼性が必要です。アーキテクチャのコアとなる課題は、脆弱なポイントツーポイントインテグレーションを作成することなく、このトランザクションデータアクセスに安全でリアルタイム、かつスケーラブルなパターンを提供することです。 **コンテキスト** エージェントをこれらのレコードに正常に接続するには、複数の**コアコンポーネント**で構成される堅牢なアーキテクチャが必要です - **トランザクション・システム：**これらは、**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 server：**トランザクションデータと関数を公開する MCP サーバ (入力データを含む tool=billing.update_record など) - **記録の外部システム：**ステートフルな変更が行われるシステム **接触** 1. **トリガー:**レコードのトランザクションを必要とするコマンドまたはイベントが発生した。 2. **行動の意図:**Agentforce Agent は状態変更インテントを識別します。 3. **プランナー (内部):**プランナーが MCP ツールを選択します。 4. **実行:**このツールは、ポリシーレベル、レコードレベル、および項目レベルのアクセスチェックに合格した後に実行されます。 5. **結果:**MCP サーバーが応答を返す 6. **フォローアップ:**Agentforce エージェントが応答を処理します。 **Trade-Offs**

アスペクト	ゲイン	Cost (コスト)
速度	ワンツールコール	ガバナンスオーバーヘッドの増加
即時性と安全性	安全な再試行	重複排除と緊急性をサポートする実装
拡張性	簡単に拡張可能	接続オーバーヘッド
一貫性	明確かつ明示的	アトミック
安全性	ガードレールとポリシーを実装できます。	ポリシーの変更をカスケードするための操作オーバーヘッド
可観測性	操作には相関関係と監査を使用できます。	テレメトリコストの増加

**レシピ 2:MuleSoft API**を使用した複雑なオーケストレーション **パターン** エージェントは MuleSoft API を使用して、複雑で複数ステップのクロスシステムアトミックトランザクションを実行します。これにより、単一の管理エンドポイントが提供され、信頼性の高いエンドツーエンドの処理が保証され、個々のシステムへの直接コールに関連する一貫性、信頼性、レイテンシ、データの問題が回避されます。 **コンテキスト** - 対話型エージェントと自律型エージェントは、多くの場合、複数の操作を確実に実行する必要があります。 - 1 つのトランザクションに複数のトランザクションシステムと操作がある。 - ワークフローには、トランザクション/ロールバック、再試行、ポリシー適用が必要です。 - トランザクションのニーズは、リアルタイム、緊急、観察可能、コンプライアンスです。 **接触** 1. **トリガー:**コマンドまたはイベントが発生し、複雑なトランザクションを完了する必要があります。 2. **行動の意図:**Agentforce Agent がインテントを識別します。 3. **プランナー (内部):**プランナーは、[API アクションまた](https://help.salesforce.com/s/articleView?id=platform.api_catalog_activate_agent_topics_and_agent_actions.htm&type=5)は API アクションの呼び出し可能なアクションを選択します。 4. **実行:**API が実行され、応答が返されます。 5. **フォローアップ:**Agentforce エージェントが応答を処理します。 **Trade-Offs**

アスペクト	ゲイン	Cost (コスト)
速度	複数の分散操作に対する 1 つのコール	開発と運用のオーバーヘッド
即時性と安全性	安全な再試行/SAGA サポート	複雑さ
拡張性	簡単に拡張でき、非同期が可能	非同期の最終的な一貫性
安全性	API レイヤーのポリシー	ポリシーの変更をカスケードするための操作オーバーヘッド
可観測性	追跡に使用可能な相関関係と監査	テレメトリコストの増加

**分析データとエージェントの統合** **問題** 組織は分析インフラストラクチャ (データウェアハウスやレーク、リアルタイム分析システム、ビジネスインテリジェンスプラットフォーム) に多額の投資をしてきましたが、AI エージェントはこれらのシステムから切断されたままです。これにより、エージェントがコンテキストを強化して (たとえば、前四半期に顧客が 3 回部品を返品したなど)、より適切な意思決定 (この場合はエスカレーション) ができるようにするためのギャップが生じます。 **コンテキスト** エージェントの業務インテリジェンスは、根本的に異なるデータ形式とソースから情報を統合できることから生まれます。したがって、このアーキテクチャパターンは 1 つの使用事例ではなく、基本的なデータ取り込みフレームワークとして設計されています。効果的なエージェントは、構造化されたソースを処理して論理的なデータ主導の分析を実行するために装備する必要があります。エージェントには、大量の構造化フィードへのアクセス権が必要です。これには、エンタープライズ **データレイク**との統合(Data 360 とのゼロコピー統合を使用)、**ミドルウェア変換**されたデータストリームの処理、**CSV**などのバッチファイルの取り込みが含まれます。 **レシピ 1:Data 360 Zero-Copy**を使用して統合されたデータレイク **問題** 従来のデータパイプラインを使用してデータレイクに保存されている分析データをコピー、管理、変換する場合、組織はコスト高に直面します (Snowflake など)。これまで、分析はほとんどオフラインであったため、タイムリーなアクションを実行する機会を逃していました。 **パターン** エージェントは、重要なインサイトを外部データウェアハウスに照会するのではなく、Data 360 で使用できるゼロコピーデータ (および計算済みインサイト) を照会します。これにより、エージェントはトランザクションデータと分析データの両方をグラウンディングして、より適切な意思決定を行うことができます。 **コンテキスト** - 組織では、顧客データと業務データをデータウェアハウスとレイクに保存しています。 - エージェントには、集計された総計値、履歴トレンド、分析インサイトへのアクセス権が必要です。 - エージェントのコンテキストにはトランザクションデータと分析データの両方が必要です (リサーチエージェントの履歴トレンドデータの必要性を考慮します)。 **接触** 1. **トリガー:**分析データまたは計算済みインサイトへのアクセスが必要なインサイトに関するクエリをエージェントが受信する。 2. **実行:**エージェントはクエリ API を使用して Data 360 計算済みインサイトをコールするアクションを実行し、計算済みインサイトが返されます。 3. **フォローアップ:**Agentforce エージェントが応答を処理します。 **Trade-Offs**

アスペクト	ゲイン	Cost (コスト)
データ移動	なし、ゼロコピー	コストの計算
遅延	数日または数週間からほぼリアルタイム	SLA
拡張性	データ量無制限	コストの計算

**レシピ 2:データストリーム**からのアクションのトリガー **問題** 組織は、Web サイトの訪問、通話、ミーティング、チャット、センサーデータなどのビジネス活動から価値のある情報を継続的に生成します。ただし、これらのやりとりが使用可能になったり、データウェアハウスから取得されたりするようになると、重要なインサイトが失われ、タイムリーな介入の機会は失われます。結果として、組織はリアルタイムで必要なアクション可能なインテリジェンスの大部分を見逃し、多くの場合、これらの一時的なストリームに埋もれてしまいます。これにより、ギャップが生じたり、コーチングの機会を逃したり、状況を完全に把握せずに意思決定を行ったりします。 **パターン** エージェントは、データアクションを使用して[ストリーミングインサイト](https://help.salesforce.com/s/articleView?id=data.c360_a_create_streaming_insight.htm&language=en_US&type=5)または Data 360 の[リアルタイムインサイト](https://help.salesforce.com/s/articleView?id=data.c360_a_create_real_time_insight.htm&language=en_US&type=5)からリアルタイムまたはほぼリアルタイムのインサイトを受信します。または、エージェントは、Apache Flink などのリアルタイム処理エンジンとインターフェイスする MCP サーバに照会して、ストリーミングインサイトにリアルタイムでアクセスします。 **コンテキスト** - プラットフォームイベント、Pub/Sub API、RTEM などのストリーミングシステムは、大量のストリームデータを生成します。 - Data 360 や Apache Flink などのストリーム処理システムは、これらの個々のイベントを到着時に処理します。 - Agentforce はストリームシステム (たとえば、追加コンテキストを含む Live Meeting の最新の 30 秒のトランスクリプト) を照会する必要があるか、データアクション (不正行為の検出など) によってトリガーされます。 - ほぼリアルタイムの低レイテンシアクションが必要です。 **接触** 1. **ストリーム排出量:**ソースシステムは、データの連続ストリームを生成します。 2. **ストリーム処理:**Data 360 や Apache Flink などのストリーム処理エンジンで情報が処理されます。 3. **変換:**インサイトは、ミドルウェア (複雑な変換用) または Data 360 でエージェント対応データに集約、変換、合成されます。 4. **ストリームインサイトイベント:**Data 360 データアクションは、合成データ (30 秒のオーディオストリームのトランスクリプトなど) に対してトリガーされます。 5. **強化:**エージェントがコンテキストを追加してインテントを検出します。 6. **実行:**エージェントがアクションを実行します。 7. **フォローアップ:**エージェントは次のストリーミングインサイトを待機します。 **Trade-Offs**

アスペクト	ゲイン	Cost (コスト)
遅延	数秒で使用可能	コンピューティングコストと実装コスト
カップリング	生産者は消費者から独立しています。	デバッグと追跡が困難
拡張性	拡張可能	制限
注文	増分コンテキスト構築	注文外到着
値	ほぼリアルタイムのインサイト	ガバナンスとコンプライアンスのオーバーヘッド

**セマンティックデータとエージェントの統合** 企業には、さまざまな形式や形状のビジネス・アーティファクト（カタログ、マニュアル、ポリシー、Knowledge グラフ、リレーションシップ・マップ）があります。単純なタスクの実行を超えて高度な推論を行うには、エージェントはほとんどの Human Knowledge が保存されているこのデータを理解する必要があります。 **レシピ 1:ドラッグ:エージェント**向けの非構造化データのパワーの解放 **問題** 組織は、エージェントが自信を持ってアクセスする妨げとなる検索不能な情報を所有していることがよくあります。この欠陥により、エージェントからの応答が不完全になることが多く、Trust を確立するために必要なコンテキストの深さや検証可能な引用が不足しています。そのため、エージェントが一貫してセマンティックに関連する正確なコンテンツを取得できるように標準化された方法が必要であることは明らかです。 **パターン** このパターンは、エージェントが内部ドキュメントから公開 Web コンテンツまで、さまざまな非構造化情報を取り込んで解釈できるようにするアーキテクチャを提供します。エージェントにこのデータへのアクセス権を付与することは、市場センチメント分析、ドキュメントの概要、競合他社の調査などの高度な機能を活用する鍵となります。 **コンテキスト** - Knowledge は、さまざまな形式や形式のファイルに格納されます。 - 冗長コンテンツは、これらのドキュメントで一般的です。 - エージェントには、引用できる正確な情報が必要です。 - Knowledge は頻繁に変更されるため、ファイルの更新とインデックスの再作成が必要です。 **接触** コンテンツをそのままエージェントが取り込んだり、使用したりすることはできません。エージェントがコンテンツを取得して使用するには、コンテンツがチャンク化され、埋め込まれ、ベクトルデータベースに保存され、インデックス付けされる必要があります。 **取り込みと準備** 1. **ソースをクロールして取り込みます。**ソースは、手動で識別する方法 (PDF ファイルをアップロードする方法など) と、その場所で識別する方法 (AWS S3 など) があります。 2. **チャンク:**取り込まれたコンテンツは、効率的に処理および取得できるように、小さく管理しやすいチャンクに分割されます。ドキュメント全体ではなく、最も関連性の高い情報のみが取得されるため、これは RAG にとって重要なステップです。 3. **埋め込み:**各チャンクは、特殊な言語モデルを使用して、*埋め込み*と呼ばれる数値表現に変換されます。これらの埋め込みではテキストの意味が取得されるため、類似性ベースの検索が可能になります。 4. **ベクトルストレージ:**埋め込みは、Data 360 ベクトルストアに保存されます。Data 360 ベクトルストアは、ハイパフォーマンスの類似性検索用に最適化された特殊なデータベースです。これにより、エージェントは関連コンテンツをすばやく見つけることができます。 5. **インデックス付け:**コンテンツとその埋め込みはベクトルストア内でインデックス付けされるため、すぐに検索できます。 **Data 360 取得関数** - **コンテンツの取得：**この関数は、クエリを入力として受け取り、Data 360 ベクトルストアに対してセマンティック検索を実行して、最も関連性の高いコンテンツチャンクを見つけます。 - **コンテンツの絞り込み：**この関数を使用すると、取得したコンテンツをドキュメント種別、著者、日付などのメタデータに基づいて絞り込み、結果をさらに絞り込むことができます。 - **Rank content:**この関数は、取得されたコンテンツチャンクを類似性スコア (ベクトル検索)、キーワードスコア、またはその両方の組み合わせ (ハイブリッド検索) に基づいてランク付けします。 **取得および生成** - **クエリ:**エージェントが情報を必要とする場合、ベクトルにも埋め込まれたクエリを作成します。 - **セマンティック検索：**エージェントは Data 360 ベクトルストアに対してセマンティック検索を実行し、クエリの埋め込みと保存されているコンテンツチャンクの埋め込みを比較します。これにより、ベクトルスコアまたはハイブリッドスコア (ベクトルとキーワードの組み合わせ) に基づいて、意味的に最も関連性の高いチャンクが取得されます。 - **取得増強生成 (RAG):**取得されたコンテンツチャンクは、元のクエリと共に Agentforce Agent のコンテキストとして提供されます。LLM はこのコンテキストを使用して、正確で正確な回答を生成します。 - **応答と引用：**エージェントは生成された回答を元のソースドキュメントまたは Web リンクへの引用と共に提示し、Trust を構築して検証できるようにします。 **Trade-Offs**

アスペクト	ゲイン	Cost (コスト)
精度	Higher Trust (引用を含むグラウンディングされた回答)	ドキュメントの選定と衛生
取得	自然言語とキーワードを処理する	ストレージの追加、調整作業
セキュリティ	特権アクセスを適用できる	実行時オーバーヘッド、キャッシュの複雑さ
チャンキング	関連性の向上	前処理と調整の強化
バージョン設定	古いKnowledgeの絞り込み	メンテナンスとガバナンスのコスト

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

アスペクト	ゲイン	Cost (コスト)
精度	Higher Trust (検証可能なリレーションがあるグラウンディング済み回答)	データハーハーモナイゼーションとグラフモデリング作業
取得	複雑なリレーショナルクエリの処理	グラフのトラバースは、非常に大きなグラフでは計算コストが高くなる可能性があります。
セキュリティ	リレーションに基づいて特権アクセスを適用できる	実行時オーバーヘッド、複雑なアクセス制御
コンテキスト深度	エンティティとその接続に関する豊富で総合的な理解	グラフ最適化のための前処理と調整の強化
メンテナンス性	リレーションの一元化されたデータモデル	進化するビジネスニーズに合わせた DMO の継続的な調整

## 結論企業は、AI エージェントが主導する自動化とインテリジェンスの新時代の最先端に位置しています。単純な顧客からの問い合わせの処理から複雑なビジネス戦略の自律的な実行まで、エージェントは生産性と顧客エンゲージメントの再定義を約束します。Salesforce Agentforce Platform は、この変革に不可欠な信頼性の高い基盤を提供します。Agentforce は、宣言型ツールとプロコードツールの堅牢なスイート、統合されたデータプラットフォーム、A2A と MCP を通じたオープン標準への取り組みにより、あらゆるタイプのエージェントを構築するための包括的で信頼できる基盤を提供します。このアーキテクチャにより、組織は単独でなく、接続されたパートナーとして機能するインテリジェントな目標指向のエージェントをリリースして、測定可能なビジネスの成功を促進できます。 ## 付録 ### Agentforce を使用した高度なエージェントの作成:必要な知識 Salesforce では、高度なエージェントを構築するための基盤として機能する、Agentforce プラットフォームで統合された強力なツールセットが提供されています。このドキュメントのレシピと例は、Agentforce プラットフォームの機能とエージェントの相互運用方法に精通していることを前提としています。このセクションでは、このドキュメントのレシピとパターンを最大限に活用するために理解する必要がある主要なコンポーネントについて再説明します。 ### 1\.Agentforce Platform の機能このセクションでは、Agentforce でエージェントを作成するアーキテクトと開発者にとって不可欠なプラットフォームの基本機能について説明します。 - **Salesforce フロー:**エージェントロジックを定義する主要なツール。宣言型のビジュアルインターフェースは、エージェントが実行するステップを調整するのに最適です。 - **Apex:**複雑なカスタムロジック、自律エージェントの状態管理、複雑なインテグレーションに対応 - **プラットフォームイベント:**A2A プロトコルのトランスポート層として機能する、プロアクティブなエージェントとコラボレーションエージェントの神経系。 - **Data 360:**エージェントの統合長期記憶。インテリジェントなアクションに必要なコンテキストを提供し、取得拡張生成 (RAG) の基盤となります。 - **MuleSoft:**エージェントが外部につなぐブリッジ。システムインテグレーションと MCP を介したクロスプラットフォームエージェントコミュニケーションの両方を可能にします。 - **Slack:**ToDo、通知、承認など、人間とエージェントのインタラクションの主要な表面 - **Agentforce チャットクライアント:**顧客対応の会話型エージェント向けのカスタマイズおよび組み込み可能なフロントエンド ### 2\.エージェントの相互運用性:A2A および MCP エージェントが真に効果的に機能するためには、エージェントをサイロ化することはできません。Agentforce は、2 つのコア相互運用性パターンを採用しています。 - **Agent2Agent (A2A) 通信:**このプロトコルは、Salesforce エコシステム内のエージェントが相互に通信する方法を制御します。Agentforce プラットフォームは **A2A クライアント**とサーバの両方として機能し、それぞれ要求の実行とリスンを行います。これは、コラボレーションエージェントのスウォームに不可欠です。エージェントは、特定のスキルを持つ他のエージェントを検出して呼び出すように**関連エージェント**を使用して設定できるため、動的で拡張可能なシステムを作成できます。プラットフォームイベントは、これらの A2A メッセージの耐久性のある非同期転送メカニズムとして機能します。 - **モデルコンテキストプロトコル (MCP):**この[標準に](https://modelcontextprotocol.io/docs/getting-started/intro)より、エージェントが 1 つのプラットフォームに固定されることがありません。MCP では、異なるフレームワークで構築されたエージェントがコミュニケーションできる共通のメッセージ形式が定義されています。このモデルでは、**Agentforce は MCP クライアントとして動作します。**たとえば、Salesforce エージェントは MCP 準拠の要求を送信することで、複雑な物流計算を専門とする外部エージェントに照会できます。MuleSoft はゲートウェイとして機能し、内部 A2A 要求を外部 MCP 形式の API コールに変換して、企業全体でシームレスな相互運用性を確保します。