アーキテクト向けAgentforce相互運用性ガイド

執筆：AgentforceAgentforce製品チーム（Pragya Anand 、Moe Basi 、Shiv Ramanna 、Kyle Bransky ）

以下では、相互運用性へのアプローチを定める方法についてご確認いただけます。
読了後、第2部をダウンロードし、構築時のリファレンスガイドとしてご活用ください。

マルチエージェントシステムを設計する前に、まず単一のAIエージェントがどのように動作するかを理解することが重要です。AgentforceのAIエージェントは、特定のドメインを対象とするモジュール式の構成要素であるサブAIエージェント （旧称トピック）で構成され、それぞれにアクション（Flow、Apex、プロンプトなど）が定義されています。

各Agentforce AIエージェントは独自のLLM推論ループを実行し、目標を達成するまで、サブAIエージェント間でのタスクの委任方法や応答の生成方法をオーケストレーションします。Agentforce推論エンジンは、このループにエージェントスクリプトにもとづく決定論的な制御を加え、サブAIエージェント間の遷移や順序を明示的に指定することで、LLMの判断だけに依存するのではなく、予測可能で制御可能な動作を実現します。LLMによる推論と決定論的なスクリプティングを組み合わせることで、業務ワークフローを実現できます。単一のAIエージェントで多くの処理に対応できますが、複雑さが増すにつれて、次のような限界に直面します。

• データ境界の制約：異なるSalesforce組織やシステムに存在するデータ、ワークフロー、権限にはアクセスできません。これは、単一のAIエージェント設計では越えられないアーキテクチャ上の壁です。
• コンテキスト過多：LLM推論エンジンのコンテキストは、指示、アクションの出力、会話履歴で埋め尽くされ、やがて中核となるルールを無視したり、トピックを混同したりするようになります。
• ドメイン特化の破綻：あらゆる分野のエキスパートになろうとするAIエージェントは、特定のサブAIエージェントを呼び出す際に誤ったロジックを適用します。指示ブロックが大きくなるほど、精度は低下します。

意思決定フレームワーク：ビジネスプロセスが比較的単純で、単一のドメイン内で動作し、各サブAIエージェントで共通のデータアクセス範囲を使用できる場合は、単一のAIエージェントを使用します。

SOMA（Single-Org, Multi-Agent）オーケストレーションでは、複数の専門のAgentforce AIエージェントが1つのSalesforce組織内でシームレスに連携できます。ユーザーが異なるAIエージェントとの会話を個別に管理する必要はなく、SOMAでは、会話の窓口となる1つの統合されたAIエージェントが提供されます。その背後では、「スーパーエージェント」または「オーケストレータAIエージェント」がインテリジェントにタスクを調整して専門エージェントに委任し、それぞれのタスクが、その処理に最適なAIエージェントによって確実に処理されるようにします。

意思決定フレームワーク：単一のSalesforce組織環境内で動作する専門エージェントに対して、顧客が統一された「窓口」エクスペリエンスを求めている場合は、SOMAを使用します。

• メリット：複数の専門エージェントに対して会話の入口を1つにすることで、ユーザーエクスペリエンス（UX）をシンプルにします。
• デメリット：1つのSalesforce組織内で利用できるデータとワークフローに限定されます。

MOMA（Multi-Org Multi-Agent）オーケストレーションは、単一組織（SOMA）モデルを論理的に発展させたもので、複雑なデータ統合を行うことなく、複数のSalesforce組織で統一されたAIエージェントエクスペリエンスを提供できます。このアーキテクチャは、オープンネットワークではなく意図的な委任という考え方にもとづいて構築されており、予測不能な連鎖を防ぐため、委任を意図的に1階層に限定する制約（AIエージェントA→AIエージェントB。AIエージェントA→B→Cではない）を適用します。セキュリティは、ユーザーアイデンティティを認識した実行と、Data 360 One（DC1）のトラスト境界内での動作によって維持されます。

意思決定フレームワーク：ネイティブのAgentforceネットワークで、データモデルを統合することなく、異なるSalesforce組織間でタスクを安全に委任する必要がある場合は、MOMAを使用します。

• メリット：は、厳格なデータレジデンシーを維持しながら、複雑なエンタープライズ環境全体で統一されたAIエージェント体験を提供します。
• デメリット：複数の組織間でユーザーアイデンティティをマッピングし、コンテキストを共有することは困難な場合があります。

モデルコンテキストプロトコル（MCP）クライアントを使用すると、Agentforce管理者は外部MCPサーバーを登録でき、ビルダーはリモートのツール、リソース、アクションを標準化された方法でAgentforceに統合できます。これにより、個別のポイントツーポイントインテグレーションを使用するのではなく、ツールコントラクトを介してAgentforceから外部機能を利用できます。

意思決定フレームワーク：Agentforceを主要なオーケストレータとして維持し、外部機能にツールとしてアクセスするだけでよい場合は、MCPクライアントを使用します。たとえば、外部システムからデータを取得する、ワークフローを呼び出す、ナレッジソースを検索する、サードパーティプラットフォームを介してアクションを実行するといった場合です。

Agentforceから外部機能をツールとして利用する場合は、MCPクライアントを使用します。

• メリット：カスタムコードを使用することなく、外部サービスをAgentforce向けのセキュアでガバナンス可能なツールとして利用できます。また、ツールポイズニングを防止するため、セマンティック整合性チェック（アンチラグプル）やリスクスコアリングなどの安全機能も備えています。Agentforceを推論ループの中核に据えたまま、Agentforceでできることを拡張できます。
• デメリット：この抽象化は、意図的にツール中心となっています。リモート機能を、推論やワークフローの一部を担う特化型AIエージェントとしてモデル化するほうが適切な場合、それをMCPに無理に当てはめると不自然になる可能性があります。また、スキーマは外部サーバーによって定義されるため、コントラクトが変更されると、更新または再登録するまで連携が機能しなくなる可能性があります。

Agentforce A2Aアウトバウンドは、Agentforce AIエージェントがサードパーティのAIエージェントと直接連携するためのネイティブな方法です。これを実現するには、管理者がまず、外部AIエージェントの具体的なスキル、機能、トランスポートプロトコルの詳細を指定して、そのAIエージェントを登録する必要があります。登録してAgentforce AIエージェントに接続すると、実行時に利用できるようになり、プラットフォームを横断して安全にタスクを委任できます。

意思決定フレームワーク：ネイティブのAgentforceネットワークからGoogleやBoxなどの外部ベンダーのAIエージェントと安全にやり取りする必要がある場合は、Agentforce A2Aを使用します。注：ここでは、あるAIエージェントから、推論、計画、実行の一部を担う別のAIエージェントに作業を委任する必要があります。

• メリット：Agentforceに直接組み込まれているため、こうしたマルチエージェントワークフローを管理するために外部のオーケストレーションツールを購入する必要がありません。ユーザーに「統一されたブランド」のAIエコシステムを提供でき、外部プラットフォームが備えている既存の専門性を活用できます。
• デメリット：サードパーティのAIエージェントを信頼し、システム間でデータプライバシーを確保することが課題となる場合があります。サードパーティAIエージェントの機能を手動で登録し、認証標準を整合させる必要があります。

次のシンプルなルールを基準に判断します。重要なのは、両側にAIが存在するかどうかではありません。重要なのは、リモート機能をどのようにモデル化するかです。

• ツールとしてモデル化する場合は、MCPを使用する
• 連携するAIエージェントとしてモデル化する場合は、A2Aを使用する

A2Aインバウンドを使用すると、外部のサードパーティAIエージェントから、Agentforce AIエージェントの特化したスキルやデータをネイティブに呼び出すことができます。この構成では、Agentforceを価値の高い「エキスパート」として扱い、外部システムから呼び出してSalesforce固有のアクションを実行できます。セキュアなAPIエンドポイントを介してAgentforceの機能を公開することで、ユーザーがサードパーティアプリケーションから離れることなく、外部プラットフォームからSalesforceにタスクを委任できます。

意思決定フレームワーク：主要なAIインターフェースがサードパーティシステム（カスタムポータルや外部ボットなど）にあり、Salesforce内で複雑なワークフローを実行する必要がある場合は、インバウンドA2Aを使用します。

• メリット：ロジックを複製することなく、リアルタイムのSalesforceデータと自動化機能を外部アプリケーションで利用できるようにします。
• デメリット：スムーズなユーザーエクスペリエンス（UX）を実現するには、外部システムでオーケストレーションと「引き継ぎ」のロジックを処理する必要があります。

SalesforceのホステッドMCPサーバーを使用すると、標準化されたMCPインターフェースを介して、サードパーティAIエージェント、Copilot、LLMプラットフォームなどの外部ホストにAgentforceの機能を公開できます。これにより、外部プラットフォームからAgentforceをツールプロバイダーとして呼び出すことができます。一方、Agentforceは、複雑で専門性の高いタスクに対応するためのエンタープライズアクション、ビジネスロジック、オーケストレーションを引き続き内部にカプセル化します。

意思決定フレームワーク：外部プラットフォームからAgentforceをツールプロバイダーとして利用する場合は、Agentforce AIエージェントをMCPサーバーとして使用します。これは特に、次の2つのシナリオで有用です。

• エンタープライズAIエージェントの相互運用性：Microsoft CopilotなどのサードパーティのエンタープライズAIエージェントがタスクを完了するうえで、Agentforceに含まれるエンタープライズアクションを必要とし、Agentforce AIエージェントを呼び出す場合。
• 外部LLM/チャネルへの展開：ブランド化されたAgentforceの機能を、ChatGPT、Geminiなどの外部の会話型インターフェースや同様のホスト内で利用できるようにする場合。

このモデルでは、外部プラットフォームが引き続き主要なホストエクスペリエンスとなり、AgentforceはMCPを介して意図的にツールエンドポイントとして公開されます。Agentforceの内部がエージェント型であっても、外部との関係は対等なAIエージェント間での委任ではなくツールの呼び出しであるため、相互運用性のパターンはMCPのままです。

• メリット：Salesforceデータにもとづいて自社向けに構築した、請求やサポートなどの強力な専門のAgentforce AIエージェントを、標準化されたプロトコルを介してSalesforceの外部でも簡単に再利用できます。また、外部アシスタントやエンタープライズAIエージェントから、Agentforceのオーケストレーションやビジネスアクションを再構築せずに利用できます。エンタープライズの相互運用性と外部チャネルへの展開の両方に対応します。
• デメリット：外部ホストが主要なユーザーエクスペリエンス（UX）と推論ループを担うため、Agentforceがいつ、どのように呼び出されるかについて、Agentforce側で制御できる範囲は小さくなります。また、エンタープライズシナリオでは、認証、認可、アイデンティティの伝播、コンテキストの受け渡しを確実に処理する必要があります。

上記の概要は出発点にすぎません。ユースケースに適したオーケストレーションパターンを特定するのに役立ちます。続いて、その設計方法とリリース方法をご確認ください。

第2部『アーキテクト向けマルチエージェントオーケストレーションリファレンスガイド』をダウンロードすると、以下の内容をご確認いただけます。

• 複雑なプロセスを、責任範囲が明確なAIエージェントに分解します。ドメインの専門性、ワークフローのステージ、機能という3つの戦略により、肥大化した1つのAIエージェントを、それぞれが1つの役割を適切に遂行する複数の特化型AIエージェントに分割できます。
• アーキテクチャを5つのオーケストレーションパターンのいずれかに対応させます。監督モードと引き継ぎモードは現在一般提供されています。並列実行、イベント駆動型バックグラウンドAIエージェント、計画と提示はロードマップに含まれています。
• LLM主導のルーティングと決定論的ルーティングを使い分けます。Agentforce推論エンジンは、自由度の高いリクエストに柔軟に対応します。ワークフローで確実な順序が必要な場合は、エージェントスクリプトによって決定論的に制御できます。ほとんどのマルチエージェント設計では、両方を使用します。
• 最も一般的な7つのアンチパターンを回避します。メッシュオーケストレーション、重複するサブAIエージェント、過剰な委任階層は、大規模環境でガバナンスと可観測性を損なう主な原因となります。
• 現在サポートされている機能を前提に設計します。エージェントスクリプトの現在の制約（固定ハンドオフ、ネストされた委任、接続できるサブAIエージェントが7つまでという制限）によって、現在リリースできるパターンと、次の四半期に向けて計画すべきパターンが決まります。