このホワイトペーパーについて

エンタープライズ エージェントのアーキテクチャと設計パターンは、マルチエージェント アーキテクチャの可能性を構造化し、AIエージェントにとって新しい機能を組み合わせて、信頼性、反復性、拡張性、管理性に優れたエージェント ソリューションを提供する方法を特定して強調表示します。オブジェクト指向プログラミングの「デザインパターン」からヒントを得て、エージェント技術以前の従来の確定的技術で構築されたビジネスシステムの範囲外にある多くのエキサイティングな課題を解決するために組み合わせたり拡張したりできるパターンがレイアウトされています。

マルチエージェントアーキテクチャの根拠を説明した後、自然言語処理を活用してユーザーのインテントを判断する単純なパターンから、エージェント間の懸念事項を分離するマルチエージェントパターン、システム、情報、コンテンツの表示と操作にエージェントの推論をもたらす UX エージェントパターンまで、多数のエージェントパターンを紹介します。

何よりもまず、エージェントに関する新しい考え方を得ることができます。コンポーネントとしてのエージェント、コンポーザーとしてのエージェント、アクターとしてのエージェント、コラボレーターとしてのエージェント、そして最も重要なのは、より大きなアーキテクチャ内で意図を持って行動し、個々の関心事の範囲内で行動するエージェントです。

ユーザージャーニーにまたがるリッチなエージェントソリューションの概念を把握し、重要なエージェントエクスペリエンス (これまで不可能だったエクスペリエンス) を提供するために必要な指針を得ることができます。

このドキュメントの最初のセクションでは、マルチエージェントアーキテクチャの根拠について説明します。マルチエージェントアーキテクチャが抱える課題と機会について理解を深めるには、次の文書を参照してください。

簡単なパターンから複雑なパターンまで、エージェントパターンの定義と説明を次に示します。ここでは、インタラクションをサポートするパターン、スペシャリストエージェントのパターン、バックグラウンド操作のパターン、実行時間の長いパターンについて説明します。各パターンには、パターンを実現する主要なコンポーネントの図と、使用方法および代表的な使用事例の推奨事項が含まれています。

最後に、この付録には、カスタマーサービスや仲介販売をサポートするなど、より大規模なエージェント型エクスペリエンスを支える総合的なエージェント型ソリューションに、これらのパターンがどのように組み合わされるかの例が記載されています。このセクションでは、豊かなエージェント型エクスペリエンスが、エージェントおよびアクションレベルでの関心の分離を活用し、支援モードと自律モードの両方で内部および外部の関係者を支援する共有エージェントを通じて、インタラクションレベルでの再利用を促進する方法について解説します。

Enterprise アーキテクトは、生成 AI をエコシステムに統合する際、共通の設計上の課題に取り組む必要があります。

• 必要なエージェント数は?
• エージェントはどのように相互運用しますか?
• エージェントと人間との労働分担はどのようになっていますか？
• これらのコンポーネントはどのようにして一貫性のあるシステムに組み上げられているのでしょうか？

このドキュメントでは、エージェントソリューションを設計および構築するためのパターンベースの方法論について説明します。

_モノリシック_エージェントは、ほとんどのエージェント型ソリューションの出発点です。エージェント—特に Agentforce エージェント—は、さまざまな分野で優れたパフォーマンスを発揮します。一般的なユースケースでは、まず単一のエージェントから始めます。

組織が大きくなるにつれて、マルチエージェントアーキテクチャが推奨されるアプローチになります。_マルチエージェントアーキテクチャ_により、モノリス型のシングルエージェントシステムよりも拡張性、制御性、柔軟性が向上します。

マルチエージェントアーキテクチャには、次の主要な利点があります。

• パフォーマンスの向上と複雑さの解消: 複数の特殊なエージェントで構成されるシステムにより、機能が強化され、指示の遵守が簡素化されます。
• モジュール性と拡張性:個々のエージェントをより簡単に追加、交換、変更、テストできるため、俊敏性が向上します。
• 耐障害性およびフォールトトレランス: 1つのコンポーネントに障害が発生しても、システム全体が損なわれることはなく、全体的な耐障害性が向上します。
• 分散ガバナンス: トラブルシューティングと管理を特定のエージェントと対応するアプリケーションに分離できるため、メンテナンスと監視がシンプルになります。

マルチエージェントアーキテクチャを合理化するには、まずエージェントの機能と構造にアーキテクチャのコア原則を投影します。結果として得られるマルチエージェントアーキテクチャは、AI テクノロジー固有の「粒度」に沿ったコアシステム設計とシステムアーキテクチャの原則の現れです。

このアーキテクチャを推進する主要な原則を次に示します。

• 分解による複雑さの管理
• 分離による復元性の向上と脆性の低減
• コードの再利用による信頼性と効率の向上
• 任意のエージェントの懸念範囲を制限することで、エージェントの信頼性が向上します。
• モジュール性と拡張性によるシステムのメンテナンスと進化の向上
• 特化によるエージェント管理と説明責任の簡素化

よりプリミティブなエージェント アーキテクチャ(たとえば、コア アーキテクチャ構造として LLM に焦点を絞ったアーキテクチャ)とは異なり、_Agentforce は最初_からマルチエージェント オーケストレーション用に設計されています。マルチエージェントオーケストレーションは、Atlas Reasoning エンジンとエージェントによる推論の基盤となるもので、エージェント応答内に動的で効果的なプログラミングパスを作成し、ユーザーエクスペリエンス (UX) に広範で深いエージェント増強を提供する機能を劇的に拡張します。

Agentforce 内では、次の主要なオープンで相互運用可能なプロトコルと Salesforce 製品によって、このような連携が可能になります。

• Agentforce は、エージェントのすべての重要な要素 (トピック、命令、アクション、ガードレール、コンテキスト、呼び出し、出力、実行の詳細、ログなど) をカプセル化するエージェントサブシステムを提供します。
• アクション: データへのアクセス、フローのコール、外部システムの呼び出し、および他のエージェントのコールを行うためのフックを提供します。
• Data 360: エージェントに特定の個人化されたコンテキストを提供するデータ仮想化レイヤーを提供します(Data 360の統合プロファイルとキーチェーンを活用して、企業全体から特定の情報を取得)。

また、企業全体のエージェントやリソース、またはエージェントにアクセスするために、次の機能がサポートされます。

• MCP(モデル コンテキスト プロトコル):エージェントをエンタープライズ ツール、データ、Knowledgeに接続してコンテキストの正確性を確保する安全な通信レイヤーです。
• エージェント間 (A2A) プロトコル: システム、組織、ベンダー間の安全で管理された調整を可能にするエージェント間委任の標準ハンドシェイク。

これらの原則は、オーケストレーションされたインテリジェンスのスケーラブルかつガバナンス可能なシステムを構築するための基盤となります。

堅牢なエージェント型ソリューションには、効果的なテクノロジーの提供を支える非機能要件に対する明確なアプローチが必要です。

• セキュリティとガバナンス (ID およびアクセス管理、データプライバシー、データセキュリティ、脅威モデリング)。
• オブザーバビリティと監視 (分散トレーシング、集中管理ログ、評価指標、ダッシュボード)。
• 運用化とライフサイクル管理 (仕様、テストケースの生成、テスト、フィードバック、継続的な学習、廃止)。

エンタープライズエージェントソリューションを構築するための主要なアーキテクチャ上の考慮事項は、このホワイトペーパーでは説明していませんが、今後の公開資料で取り上げます。

企業全体のエージェントの状況を管理するには、アーキテクトは、技術的な機能とビジネスへの影響という 2 つの補完的な観点からエージェントを分類する必要があります。

この分類では、エージェントがアーキテクチャ内で引き受ける可能性のある機能ロールが分類されます。

• チャネル/UX ロール: インタラクションのモダリティ (ヘッドレス、プロンプト、チャットとメッセージ、AI で管理されるワークスペースなど) を定義します。
• スペシャリスト役割: 深いドメインの知識 (Domain Expert、Knowledge Minion、Assistant、Planner など) をカプセル化します。
• ユーティリティサービスロール: 個別のトランザクションタスク (生成、集計、変換、設定など) を実行します。
• メンテナンスおよびプロアクティブサービスロール: データの健全性と品質 (選定、適合性、データ品質、データ強化など) を重視します。
• 長期ロール: コンシェルジュ、プロジェクトマネージャー、ナーチャラー、ウォッチャー/アラートなど、長期間にわたってプロセスを管理します。

明確な設計とコミュニケーションを容易にするために、エージェントマップはエージェントソリューションを説明する標準テンプレートです。特定のデザインパターン内の主要なエンティティ、システム、インタラクションを定義します。

エージェント型マップテンプレートコンポーネントを次に示します。

• ユーザーレイヤーでは、システム内のユーザーアクターを定義します (顧客、認証済み従業員 (SF ユーザー)、認証されていない従業員など)。
• エージェントレイヤーは、必要なエージェント、表示されるパターン、相互の関係、および特定のパターンを実現するために使用される指示を記述します。
• コンテキスト/アクションは、エージェントが管理またはアクセスするリソース、機能、またはアクションです。
• ソースは、基盤となるデータ、アプリケーション、知識ベース、およびエージェントが接続するその他のシステムです。

付録Aおよび付録Bは、エージェント型マップテンプレートのスイムレーン内での構成を示すことで、システムレベルのエージェント型パターンを例示しています。

Salesforce では、エージェントパターンのライブラリを使用して、信頼性の高い予測可能なエージェントソリューションを整理して提供します。これらのパターンは、一般的なアーキテクチャの問題を解決するためのブループリントです。

これらは 4 つの主要なカテゴリに分類されます。

• インタラクションパターン: エージェントのエンゲージメントとユーザーエクスペリエンス (UX) を重視します。
• スペシャリスト/ワーカーパターン: 特定のドメイン内の深い知識または特定のスキルをカプセル化します。
• ユーティリティおよびデータ管理パターン: 他のエージェントまたはプロセスをサポートする特定の反復可能なタスクを実行します。
• 長期実行パターン: 複数のステップを含む、長期間にわたって発生するプロセスとワークフローを管理します。

次のセクションでは、各カテゴリの主要なパターンについて詳しく説明します。各パターンの説明には、概要、出力種別、パターン使用ガイダンス、代表的な使用事例、ソリューション図のほか、Salesforce エージェントの成熟度ルーブリックへの対応付けが記載されています。

_インタラクションパターン_は、エージェントエンゲージメントとユーザーエクスペリエンスに重点を置いた基本的な設計です。

• 概要: _Greeter パターン_は、自然言語を使用してユーザーのインテントを判断するシンプルで実装が容易なパターンです。次に、ユーザーを適切な人間のエージェントにルートします。

• 出力種別: 次のリソースへの引き継ぎ/エスカレーション。

• ビジネス価値: 顧客にとってシームレスで効率的な最初の連絡を促進し、サービスプロバイダのインテント解決とコンテキストのコレクトを最大化します。

• パターン使用ガイダンス: エージェントをブランドチャネルの主エンゲージメントリソースとして設定します。ユーザーのインテントに基づいて、ルーティング手順と組み合わされたブランド、商品、サービスに関する手順を提供します。エージェントは、ウォームハンドオフを提供するためにインテントをコレクトし、要約します。

• 代表的な使用事例:チャット ボットを使用してオプションのメニューを表示するWebページを想像してください。ユーザーは、人間に転送する前にすべてのオプションをクリックする必要があります。バックオフィスの生産性と効率を向上させるために、チャットボットは複雑な作業パスとインタラクションをよく使用します。これにより、顧客が「入力、選択、クリック」の疲労シナリオに陥り、コンテキストが使用可能なメニューオプションの範囲外である場合に不満を感じることがよくあります。従来のチャットボットを自然言語インタラクションを使用する_エージェント型フロントドア_に置き換えることで、負担を軽減し、人間のようなインタラクションを実現します。

• Agentforce レシピ:

  • Agentforce サービスエージェント: Agentforce Builder を使用したサービスエージェントの組み立て
    • パッケージサービスエージェントには、転送をサポートする設定可能な転送機能があります。
      • 人間のエージェントへ
      • AI エージェントへ
      • 外部エージェントへ
  • コード例が含まれる業界固有のパターン

• 図:

• Salesforce エージェントの成熟度: レベル 1 (転送とエスカレーションが組み込まれた標準サービスエージェントを使用している場合はレベル 0)

• 概要: _オペレータパターン_は、適切なスペシャリストエージェントまたは人間に要求を転送し、(必要に応じて)インテントをネゴシエートすることで、_グリーターパターン_に基づいて構築されます。

• 出力種別: 次のリソースへの引き継ぎ/転送。

• パターン使用ガイダンス: ブランドおよびサービス固有の手順と、インテントに基づいてユーザーをどこに派遣するかを示す手順を組み合わせます。エスカレーションリソース（人間のエージェントまたは他のエージェント）を定義します。

• 代表的な使用事例:_エージェント フロント ドア_は、人間またはAI担当者の専門分野が非常に高いシナリオに使用します。

• 図:

• Salesforce エージェント型成熟度: レベル 2

• 概要: _オーケストレータパターン_で AI エージェント「スウォーム」を管理します。ユーザー要求を受信すると、1 人以上のスペシャリストエージェントに発言を渡し、ユーザーの回答を集計します。_演算子パターン_とは異なり、最初の連絡先 (POC) であり続けます。

• 出力種別: ワーカーエージェントからの応答を照合して準備します。

• パターン使用ガイダンス: 主エンゲージ担当者として設定されます。オーケストレーターが発言をエージェントにリレーできるサポートワーカーエージェント (優先度設定担当者やドメイン SME など) ごとに手順を説明します。

• 代表的な使用事例: _オーケストレータパターン_をエージェント型フロントドアとして使用し、マルチエージェントソリューションと一貫したインタラクションを必要とする会話ごとに複数のトピックについて話し合う必要がある顧客をサポートします。マルチシステムアーキテクチャでは、複数のシステム間および外部エージェントのコラボレーションで応答を調整する_オーケストレーターパターン_を検討します。

• 図:

• Salesforce エージェント型成熟度: レベル 3

• 概要: _リスンする/フィードパターン_は、会話のフロー中にコンテキストとインサイトを表示します。_リスンする_は、会話のターンごとにトリガーされ、従業員の関連情報を検索して表示します。

• 出力種別: 会話に基づいて関連するコンテキストを提供します。このコンテキストは、効果を得るために書式設定できます (たとえば、比較を行ったり、重要なポイントを強調したりできます)。

• パターン使用ガイダンス: リスナーをターンベースのチャネル (チャット、音声、SMS など) に接続します。各主題領域ごとにトピックを定義します。エージェントはトランスクリプトを消費し、トピックを識別し、関連するコンテンツを検索して従業員の実行中のフィードに投稿するアクションを呼び出します。

• 代表的な使用事例: _ユニバーサルアシスタント_を使用して、カスタマーサービスまたは営業担当をサポートします。

• 図:

• Salesforce エージェント型成熟度: レベル 3

• 概要: _ワークスペース (Radar O'Reilly) パターン_では、会話の流れでレスポンシブな単一画面のUXを管理します。各発言が処理され、関連するコンテンツで UX の一部が更新されます。

• 出力種別: より大きな単一画面内のポートレットにある関連するコンテキストを提供します。

• パターン使用ガイダンス: _オーケストレータ_エージェントが発言を一連の_トピック_エージェントに渡します。各トピックエージェントはステートメントを評価し、UX の更新が必要かどうかを判断します。その場合、動的更新が対応する LWC に転送されます。

• 代表的な使用事例: 高度なエージェント型フロントドアのように機能します。

• 図:

• Salesforce エージェント型成熟度: レベル 3

_スペシャリスト パターン_は、特定のドメインの深いKnowledgeまたはスキルをカプセル化したもので、通常は_インタラクション パターン_によってオーケストレーションされます。

• 概要:_アンサーボット パターン_は、GenAIを使用してキーワードだけでなくKnowledge検索用の自然言語を判断するセルフ サービスの効果的なパターンです。

• 出力タイプ: Summaryd Knowledge and references/citations to support materials (ナレッジの概要とサポート資料への参照/引用)。

• パターン使用ガイダンス: 信頼できるソース資料(Knowledge StoreやFAQなど)を整理して取り込み、エージェントを設定します。企業 Web サイトまたは内部ポータル内にエージェントを配置します。質問を監視して、ナレッジギャップを特定して解決します。

• 代表的な使用事例: 企業の Web サイトでの自然言語検索の促進、HR 福利厚生ボットの操作、すべての対象者へのセルフサービスコンポーネントの提供。

• 図:

• Salesforce エージェント成熟度: レベル 1

• 概要: _ドメイン SME パターン_は、ビジネスドメイン (注文や請求など) の自然言語フロントエンドを提供する基本的なパターンです。

• 出力種別: ドメインに関連するコンテンツ、トピック、データ、および書式設定された情報を提供します。

• パターン使用ガイダンス: このパターンを使用して、件名またはビジネスドメインをカプセル化します。適切な CRUD 操作を実行できるようにエージェントを設定します。これらのエージェントをインタラクション パターン(- Orchestrator や Listener など)で使用できるようにします。

• 代表的な使用事例: ビジネスデータドメインのゲートキーピング、「注文エージェント」または「在庫エージェント」の提供、ビジネスドメインのエージェントインターフェースの提供。

• 図:

• Salesforce エージェント型成熟度: レベル 2

• 概要: _Interrogator パターン_は、複数のソースからコンテキストを収集して質問に回答するためにトピックについて尋問できる SME エージェントです。活用される主要なエージェント機能は、コンテンツを読んで内部化した後で人間が行うように、コンテンツ全体にわたってコンテキストを取得して概念を結び付ける機能です。このパターンにより、「回転椅子インテグレーション」の必要性が軽減されます。

• 出力種別: 質問への回答を提供します。

• パターン使用ガイダンス: 多くの場合、ユーザーが直接質問できるようにユーザーの現在のコンテキストに接続されたコンソールウィジェットとして設定されます。また、FAQ、ポリシー、製品カタログなどのKnowledgeリソースと組み合わせて使用されます。_Interrogator パターン_を標準プロンプトと組み合わせて、よくある質問に対する一般的な回答を拡張します。

• 代表的な使用事例: 契約アシスタントエージェント、給付問い合わせアシスタント、またはマルチエージェントパターン (リスナーやワークスペースなど) のスペシャリストワーカーエージェントとして使用します。

• 図:

• Salesforce エージェントの成熟度: レベル 2

• 概要: _Prioritizer パターン_は、定義された目的に基づいて一連のタスクまたは作業オブジェクトを並び替えるために使用されます。GenAI を活用して、定性的な分析、非構造化データ分析、または複数のデータドメインの統合分析を行います。

• 出力種別: 生成インサイトを提供します。

• パターン使用ガイダンス: 自然言語を使用して、優先順位付けに必要な資質を説明します。選択可能な一連のオプションを使用してエージェントをグラウンディングします。Listenerパターンと組み合わせて、作業フローで応答性の高い「Next Best Action」を作成します。

• 代表的な使用事例: Next Best Action ジェネレーターとして、または実行時間が長いパターンやマルチエージェントパターンの専門作業員エージェントとして使用します。

• 図:

• Salesforce エージェントの成熟度: レベル 2

_ユーティリティパターン_は、他のエージェントまたはプロセスをサポートする特定の反復可能なタスクを実行します。

• 概要: _ジェネレーターパターン_は、既存の入力および標準から新しいコンテンツ (ケースの概要やメールドラフトなど) を作成するための基本パターンです。多くの場合、プロンプトとして実装され、他のエージェント内に埋め込まれる可能性があります。

• 出力タイプ: 要求された形式とインテントに準拠する生成されたコンテンツを提供します。

• パターン使用ガイダンス: _ジェネレータパターン_は他のほとんどのパターン内で、またはスタンドアロンとして使用できます。コンテキストは、要求、実行中のハイドレーション、または追加の強化ステップで提供できます。

• 代表的な使用事例: ケースの概要、メールの下書き、ナレッジ記事、またはQBRへの提案/回答を提供します。

• 図:

• Salesforce エージェント成熟度: レベル 1

• 概要:_データ スチュワード パターン_は、一貫したデータ品質、準拠、強化を確保するためにデータ操作にエージェント ステップを導入する自律的なバックグラウンド パターンです。

• 出力タイプ: 保存前に更新されたレコードおよびデータフィールドを指定します。

• パターン使用ガイダンス: データの保存前にフローを記録するデータスチュワードを追加することで、データ作成時にデータ品質を組み込みます。分類データ、概要データ、状態データの一貫した適用に役立ちます。

• 代表的な使用事例:一貫した「ピザトラッカー」スタイルの更新、アカウント データの強化、郵便番号と住所の不一致の排除を実現します。

• 図:

• Salesforce エージェント型成熟度: レベル 2

• 概要: _Zen Data Gardenerパターン_は、データのグルーミングと標準化に使用されるスケジュール済みのバックグラウンドパターンで、低コストの理由を活用して、接続されていないデータドメイン全体でデータを検証、強化、および準拠します。

• 出力種別: 更新されたレコードやデータ管理タスクを提供します。

• パターン使用ガイダンス: パターンを使用して、定期的なデータの確認と検証を有効にします。変化の遅いデータの場合、エージェントを遅いケイデンス（例：毎月）でスケジュールします。データスチュワードパターンと組み合わせて、見込みおよび遡及的なデータ品質オペレーションを提供します。

• 代表的な使用事例: 販売した給付と請求システムの整合性を確保し、国内レジストリに対するブローカーライセンスの定期的な検証を行います。

• 図:

• Salesforce エージェント型成熟度: レベル 4

• 概要: _コンフィグレーターパターン_では、自然言語要件から設定アーティファクト (SQL/SOQL、JSON、CSV など) を生成します。また、要件に対して既存の設定を検証するために逆方向に実行することもできます。

• 出力種別: 更新されたレコード、データ管理タスク、修正用のビルドの問題/エラーを提供します。

• パターン使用ガイダンス: 特定の標準、ガイドライン、または例を使用してエージェントをグラウンディングします。契約や商品仕様などのソースを使用してビルド要件を設定します。_コンフィグレーターパターン_をターゲットシステムに接続して、生成された構成をプッシュします。

• 代表的な使用事例: 医療保険商品の商品設定レコードの生成と、医療提供者の契約/支払条件の検証。

• 図:

• Salesforce エージェント型成熟度: レベル 4

• 概要: _Judge & Jury パターン_は、「陪審員」エージェントのアンサンブルと「Judge 担当者」を用いて、応答の整合性を評価し、実質的に一貫した回答とグラウンディングを確保することで、幻覚を最小限に抑えるよう設計されています。

  • _アンサンブルアプローチ_は、応答の正確性と関連性に対処するために Agentforce と Atlas Reasoning エンジンに組み込まれています。[_Judge and Jury (_審査員)] パターンは、高レベルの精度が不可欠な場合にこの機能を基盤にします。
  • データグラウンディング (「これらのレコード/ドキュメントで回答を見つけてください」など) と_プロンプトエンジニアリング_ (「これらのレコードで回答が見つかった場合にのみ回答を返します」や「この外部ソースに対して回答を検証してください」など) の組み合わせも、幻覚を最小限に抑える効果的な方法です。

• 出力種別: 生成インサイトを提供します。

• パターン使用ガイダンス: 一貫性のあるグラウンディングされた生成出力が強く必要とされる場合に使用します。_Judge 担当者_がグラウンディングプロンプトを作成して、2人以上の_陪審員担当者_に渡し、その後、Judge 担当者が応答を評価します。最良の結果を得るには、陪審員エージェントごとに異なるモデル (OpenAI のモデルと Anthropic のモデルなど) を使用します。

• 代表的な使用事例: 幻覚を最小限に抑えるために、忠実度の高い、事実に基づいた応答を提供します。

• 図:

• Salesforce エージェント型成熟度: レベル 2

• 概要: _モデルパターン_では、複数のエキスパートエージェントを活用して幅広い視野を生成し、コンセンサスを抽出します。[審査 & 審査員] パターンとは異なり、このパターンでは複数の視点を採用して豊かさを高めます。

  • 異なる視点（POV）を持つエキスパートモデルを活用できる場合、このパターンは「パネル・オブ・エキスパート」パターンと呼ばれることもあります。
  • エージェントの応答が一般にアクセス可能な「真実」に収束することを意図するJudge & Jury パターンとは異なり、_モデル・オブ・モデルズ パターン_はエージェント型環境の多様性を活用して応答のスコープを拡張します。
  • このパターンは、個別の POV を持つエージェントが他にもいることを前提としています。たとえば、マルチ組織、マルチエージェント環境、またはベンダーが提供する複数のエージェントが技術スタックにまたがっている環境では、_モデルパターン_によって複数の見解を統合する構造が提供されます。
  • このパターンを考慮する場合、他のより軽量なアプローチも考慮します。
    • 複数のエキスパートエージェントを定義する代わりに、複数のプロンプトを指定して、システムがプロンプトのアンサンブルとして機能するようにします。
    • コンテキストに応じて適切なデータにアクセスするアクションで「グラウンディング」を活用します。

• 出力種別: 生成インサイトを提供します。

• パターン使用ガイダンス: _アグリゲータ_エージェントの役割は、モデルエージェントが返した主要な概念に基づいて、豊富な見解を形成して返すことです。モデルエージェントは、独自の視点に基づいて回答を決定します。

• 代表的な使用事例: 異なる視点をまとめることで回答の品質が向上する可能性がある状況で使用します。 たとえば、特権エージェント (_ERP エージェント_など) が貴重でアクセスできない POV を持つ可能性があるマルチシステムエージェント環境などです。

• 図:

• Salesforce エージェント型成熟度: レベル 2

_Long-Running Processパターン_は、長期間にわたって発生するプロセスを管理します。これには、複数のステップとアクターが含まれます。

• 概要: _プロジェクトマネージャーパターン_は、長期にわたるプロジェクトを監視する複雑なパターンです。活動の調整、完了の追跡、ユーザーへの通知、関係者へのプロジェクト状況の表示を行います。

• 出力種別: 複数の出力 (ケース、ToDo、状況の更新、通知など) があります。

• パターン使用ガイダンス: 定期的な繰り返しの複数ステップの活動をサポートする傘のパターンとして使用します。_プロジェクトマネージャーパターン_では、ToDo、ロール、連動関係を含むプロジェクトの入力テンプレート/アウトラインを取得し、ケースと活動をインスタンス化してユーザーに割り当てます。

• 代表的な使用事例: アカウントインストール管理および企業セールスエンゲージメントに使用します。

• 図:

• Salesforce エージェント型成熟度: レベル 4

パターンがエージェントの役割を説明するのに対し、_オーケストレーションの原型_では、エージェント集団がどのようにコラボレーションするかに関するシステムレベルのブループリントを定義します。これらのアーキタイプは、オーケストレーションの頭脳としての_Agentforce_とユニバーサルコネクタおよびアダプターとしての_MuleSoft_の役割を明確にします。

アーキタイプ 1: SOMA (単一組織、複数のエージェント)

• 定義: 共有ガバナンスとデータを使用する 1 つの Salesforce 組織内で複数のエージェントがコラボレーションします。
• アーキテクチャ フロー:Agentforce では、_スーパーバイザ エージェント_は 1 つのフロント ドアとして機能し、組織内の_スペシャリスト エージェント_に要求を転送します。外部機能の場合、エージェントは MuleSoft が MCP 対応以外の API の MCP ラッパーとして機能する Agentforce MCP Client を使用します。
• 主な考慮事項: このパターンでは、統合ガバナンス、ID、権限、およびオブザーバビリティを維持するために、オーケストレーションロジックがSalesforce(CRMコンテキストやData 360に類似)で一元化されます。

アーキタイプ 2: MOMA (Multi Org, Multiple Agents)

• 定義: エージェントが複数の Salesforce 組織でコラボレーションする場合、データと権限の境界を越えて安全に連携する必要があります。
• アーキテクチャフロー: ある組織の_スーパーバイザーエージェント_が、標準化された_エージェント間 (A2A)_ プロトコルを使用して別の組織のエージェントに ToDo を委任します。このハンドシェイクにより、組織レベルの Trust、ユーザー ID フロー、および共有されたカンバセーションコンテキストが確保されます。
• 主な考慮事項: このパターンでは、組織の自律性を維持しながら、企業全体のワークフローを有効にします。これにより、複雑な複数組織の資産で一貫したエージェント業務を行うための基盤が提供されます。

アーキタイプ 3: マルチベンダー A2A (Salesforce 主導のオーケストレーション)

• 定義: Salesforce の_スーパーバイザーエージェント_が、A2A プロトコルを使用して、Salesforce ネイティブエージェントと他のベンダー (Google/Vertex や LangGraph など) のエージェントの組み合わせの作業を調整します。
• アーキテクチャフロー: _スーパーバイザエージェント_が要求を処理して計画をまとめ、A2A プロトコルを介して内部および外部のベンダーエージェントを呼び出します。A2A対応ではない外部システムの場合、_MuleSoft_は既存のツールをラップしてA2Aと通信する「軽量のエージェントの外観」を公開できます。
• 主な考慮事項: このアーキタイプでは、A2Aを使用して、個別のオーケストレーション階層を持たないクリーンで管理可能な構成を生成することで、オーケストレーションの頭脳をCRMとData 360に近づけます。

原型 4: マルチベンダー A2A (MuleSoft 主導のオーケストレーション)

• 定義: オーケストレーションは Salesforce 以外のエントリポイントから開始されます。このエントリポイントでは、推論とルーティングを実行するために中立的な外部オーケストレーターが必要です。
• アーキテクチャフロー: 外部システムの _UI エージェント_が要求をオーケストレーションサービス (MuleSoft Conductor の概念) に転送します。オーケストレーションサービスでは、インテントが解釈され、ToDo が計画されます。次に、A2A を使用して、CRM またはサービスアクション用の Agentforce エージェントを含むベンダーエージェントに通話を転送します。
• 主な考慮事項: このパターンは、中立的なオーケストレータがアーキテクチャ上望ましい、Salesforce以外のエントリポイント用です。ドメインシステムの UX を維持しながら、推論、ガバナンス、ポリシー、オブザーバビリティを MuleSoft で一元化します。

これらの個々のパターンとオーケストレーションのアーキタイプは、エンドツーエンドのソリューションで構成されるように設計されたアーキテクチャのビルディングブロックです。エージェント型ソリューションマップは、これらのコンポーネントがどのように接続されているかを視覚化するために使用されます。

• ヘルスケア プロバイダー向けの_メンバー サービス ソリューション_は、SOMアーキタイプの標準実装です。匿名ユーザー用の Answerbot、認証済みメンバー用の Orchestrator、および複数の_ドメイン SME エージェント_ (ケース、請求、給付など) を使用して、特定の要求を処理します。
• B2C ブローカー ポータル_は、ポータル オーケストレーター エージェントを使用して RFP プロセスの実行時間が長い_プロジェクト マネージャー エージェント_を呼び出す複雑な構成です。次に、RFP プロセスはバックオフィス データ操作に_ヘッドレス、データ スチュワード、_取調官エージェント_を使用します。

エージェント設計パターン手法は、堅牢で拡張性と保守性に優れたエンタープライズ AI システムを構築するために必要なアーキテクチャの規律を提供します。これらのパターンにより、複雑さを解消し、モジュール性を促進することで、アーキテクトは信頼性と予測性の高いエージェント型ソリューションを提供できます。

オーケストレーションのアーキタイプの選択は、ユーザーが作業する場所、コンテキストが存在する場所、および企業が人間、エージェント、システム間のやりとりをどのように管理しているかに基づいて戦略的な決定を行います。エージェントの作成とオーケストレーションの違いを理解し、_MCP_や_A2A_などのオープン プロトコルを活用することで、アーキテクトは孤立したボットの作成から、一貫性のある管理された分散型のエンタープライズ推論システムのエンジニアリングに移行できます。このアプローチは、持続可能なエージェント型アーキテクチャを構築するための共有言語と再利用可能なブループリント一式を提供します。

この付録では、エージェントパターンをシステムレベルのソリューションに構成する具体的な例について説明します。

次の図は、5 つの基本パターンを結合して共通のカスタマーサービスワークフローを作成する方法を示しています。

1. アンサーボット: 匿名ユーザーが質問し、Knowledge ベースのエージェントが処理します。
2. オペレータ: オペレータが従業員の質問に優先順位を付けます。オペレータは会話に項目を設定し、より専門的なエージェントに渡します。
3. オーケストレーター: 認証済みユーザー (SF ユーザー) は、多面的な問い合わせを処理するために複数のエージェントを調整するオーケストレーターとエンゲージします。
4. ドメイン SME: スペシャリストエージェント (HR エージェントや福利厚生エージェントなど) は、オーケストレーターによって呼び出され、専門分野の更新を実行して特定のデータを取得します。
5. ジェネレーター: ユーティリティエージェントは、アカウントの詳細を要約したり、インタラクション完了後にケースをまとめたりするために使用されます。

このソリューションマップでは、メンバーサービスの使用事例のエージェントアーキテクチャの詳細を説明し、複数のパターンの構成を示します。

• ユーザープロファイル: このソリューションでは、匿名ユーザー、認証済みメンバー、SF ユーザー (人間の CSR など) という 3 つの異なるユーザー種別が提供されます。
• インタラクションパターン: _アンサーボット_は匿名の「文書検索」クエリを処理し、オーケストレーター (エージェントのフロントドア) は認証済みユーザーの問い合わせを管理します。_リスンする/フィードパターン_は、SF ユーザーを支援します。
• ドメインエージェントの再利用: 特殊な_ドメイン SME エージェント_ (ケースエージェント、請求エージェント、給付エージェントなど) は、さまざまなインタラクションフローで再利用されます。
• Autonomous & Assistive (自律および支援): このシステムは、自律エージェント (ユーザー操作を直接行うため) と_支援エージェント_ (人間の CSR を増強するため) を組み合わせます。
• データソース: このアーキテクチャでは、公開データソースとエンタープライズデータソースが混在しており、接続には_Data 360_と_MuleSoft_が幅広く使用されています。

次の図は、機能レイヤーに整理されたコンタクトセンターの支援AIソリューションの論理アーキテクチャを示しています。

• オーケストレーターエージェント: さまざまな人格(匿名、外部メンバー、CSRなど)のユーザーエクスペリエンスを管理し、全体的なインタラクションフローを調整します。
• 従業員エージェント: _複数の SME エージェント_が、Knowledge、ケース/請求/給付、提供者ディレクトリなどのコアビジネスドメインに焦点を絞っています。Next Best Action エージェントも含まれます。
• ユーティリティエージェント: 翻訳、ケースラップアップ、通話の概要など、特定の再利用可能なタスクを実行します。 インテグレーションおよびコアシステム: エージェントシステム全体がクロスプラットフォームインテグレーションレイヤーを介して非構造化データリソース、構造化データリソース、コアエンタープライズシステムに接続されます。
• ガバナンス: ガバナンスレイヤーは、エージェントが使用する LLM/SLM の監視性、評価、管理を提供します。

このソリューションマップでは、B2B 健康保険ブローカーポータルの複雑で実行時間の長いエージェント操作の詳細が示されます。このモデルには、複数のステップ(RFPの送信や提案の受信など)でブローカーのジャーニーを促進する_ポータル エージェント_(オーケストレーター)が含まれます。このオーケストレーターは、プロジェクト マネージャー エージェントを呼び出します。次に、プロジェクト マネージャーは、RFP Extractor、国勢調査変換、データ スチュワードなど、バック オフィス データの品質と変換に関する複数のヘッドレス エージェントを調整します。

この図は、コンタクトセンターと同様に階層化されたアプローチを採用したB2Cブローカーソリューションの論理アーキテクチャを示しています。これには、さまざまなユーザー・人格用の_オーケストレーター・エージェント_、主要なドメイン（Knowledge、Member Services、Commissionsなど）用の再利用可能な_ワーカー・エージェント_、翻訳や集計などの特定の機能用の_ユーティリティ・エージェント_が含まれます。

次の図は、提供者契約ソリューションの論理アーキテクチャを示しています。_オーケストレーター_エージェントは完全なインタラクションを管理し、_ワーカーエージェント_はドメイン内の特定のインテント (契約 SME エージェントなど) を管理し、_ユーティリティ_エージェントは契約の比較やインサイトの生成などの個別のタスクを実行します。

次の表に、いくつかの主要なインタラクションパターン、一般的なユーザーエクスペリエンス、および主要なアーキテクチャの目的をまとめます。

David Harshbarger は、成功した起業家でありテクノロジーリーダーで、多くの主要なソフトウェア企業で働いた経験があります。彼は、アーキテクチャの方向性とビジネスの方向性を一致させるソリューションを設計し、技術者が自分たちのテクノロジーを活用して協力できるようにしてきました。現在、David は Salesforce のプリンシパルエンタープライズアーキテクトとして健康とライフサイエンスをサポートしています。

Chacha Choudhury は、数十年の経験を持ち、高度なスキルとビジョンを持つ IT CTO/チーフアーキテクトです。現在は、Salesforce アーキテクチャプログラムとグローバルアーキテクトコミュニティを率いるプリンシパルエンタープライズアーキテクトです。エンタープライズ全体のテクノロジー戦略の設定、アーキテクチャのモダナイゼーションの推進、生成 AI やエージェント型 AI アプリケーションなどの革新的なソリューションの開拓に関する専門知識が認められています。