Agentforceマルチエージェントオーケストレーションの公式仕様と「責務分解」のベストプラクティス

Agentforceの適用範囲が広がり、エンタープライズ規模の複雑な業務をAIエージェントに任せるようになると、1つの巨大なAgentにすべての機能を詰め込むアプローチは限界を迎えます。エージェント指示（Instructions）やアクションの肥大化は、プロンプト解釈のコンフリクトや予期せぬハルシネーションの温床となるためです。

この課題を解決するため、Salesforceは単なる会話システムから「エージェント型推論（Agentic Reasoning）」へとパラダイムを移し、「マルチエージェントシステム（MAS）」の構築を推進しています。本記事では、Summer ’26の「マルチエージェントオーケストレーション（ベータ）」の公式仕様に基づき、設計の要となる「責務分解」と、Atlas推論エンジンによる動的ルーティングのアーキテクチャを解説します。

マルチエージェント・コラボレーションの概念

1つの巨大なAIにすべてを任せるのではなく、異なる役割や権限を持つ複数のエージェントがチームとして連携する仕組みを「マルチエージェント・コラボレーション」と呼びます。

Salesforceの公式見解において、この概念は以下の価値をもたらすとされています。

• 専門化による精度の向上: 「注文管理」や「技術サポート」など、エージェントを特定の領域に特化（スペシャリスト化）させることで、回答精度が向上します。
• 権限とセキュリティの分離: 各エージェントに必要最小限のアクションとデータアクセス権限のみを付与することで、セキュアなシステム構築が可能になります。

A2Aプロトコルによる通信の標準化

上記のコラボレーションを、異なるシステムやエージェント間で実現するためのオープンな標準規格が「A2A（Agent2Agent）プロトコル」です。

A2Aプロトコルでは、エージェント同士がAPIの同期通信のように直接的に叩き合うのではなく、非同期かつ疎結合な以下の構造化コンポーネントを用いて連携します。

• Agent Card: エージェントの能力や入出力スキーマを定義したメタデータ。
• Task: 委譲される作業の単位。
• Message: タスク内でやり取りされる指示や状態。
• Artifact: リモートエージェントが返す、構造化された実行結果。

Salesforceプラットフォーム内において、Agentforce（Service Agentなど）同士を連携させる場合も、この「構造化された依頼（Task）を渡し、構造化された結果（Artifact）を受け取る」という非同期的な疎結合の思想がベースとなります。

マルチエージェントオーケストレーションの基本構成

マルチエージェントシステムでは、すべての意思決定を1箇所に集中させるのではなく、役割を細分化した複数のエージェントがA2A（Agent-to-Agent）プロトコルを用いて情報を交換し、集団的な意思決定を行います。

Summer ’26の「Orchestrate Other Agents（ベータ）」機能により、Salesforceプラットフォーム上でエージェントを以下の2つの明確な役割に分離して直接接続することが可能になりました。

• プライマリエージェント（オーケストレーター）
  すべてのユーザーインタラクションの単一の入口です。ユーザーの初期クエリを分析して意図（インテント）を理解し、最適なセカンダリエージェントへとシームレスにルーティングします。
• セカンダリエージェント（サブエージェント／スペシャリスト）
  プライマリエージェントからタスクを委任され、背後で処理を行います。特定のデータにグラウンディングされ、自らの狭い責任範囲（専門業務）にのみ集中して回答や処理を生成します。

追加されたスペシャリストエージェントのAgent Scriptコード例：

start_agent agent_router:
    reasoning:
        instructions: ->
            | Select the best tool to call based on conversation history and user's intent.
        actions:
            (省略)
            go_to_Order_Management_Spesialist_Service_Agent: @utils.transition to @connected_subagent.Order_Management_Spesialist_Service_Agent

connected_subagent Order_Management_Spesialist_Service_Agent:
    label: "Order Management Spesialist Service Agent"
    target: "agent://Order_Management_Spesialist_Service_Agent"
    loading_text: "注文業務を担当するエージェントを呼び出し中..."
    description: "注文に関する登録やキャンセルの依頼はこのサブエージェントが担当します。"

オーケストレーターとスペシャリストの責務分解に関する見解

マルチエージェント設計において最も重要なのが、「どの処理をプライマリ（オーケストレーター）が担い、どこからセカンダリ（スペシャリスト）に委譲するか」という責務の境界線です。Webアプリケーションにおけるフロントコントローラーパターンのように設計するのがベストプラクティスです。

プライマリエージェントの役割（共通処理とガバナンスの集約）

• 本人認証・ログイン処理: 全社共通のセキュリティチェックやユーザー識別。
• 初期意図解析とルーティング: ユーザーの要望を分析し、最適なセカンダリエージェントへ遷移する判断。
• エスカレーション判定: 怒りの感情検知や、自動化を一時停止して人間のオペレーターによる介入を要求する制御。

セカンダリエージェントを切り出す3つの基準

以下の要件が含まれる場合、プライマリの機能を拡張するのではなく、新たなセカンダリエージェントを作成して接続すべきです。

1. データ更新（トランザクション）を伴う処理: 注文のキャンセルやケースの起票など、Salesforceのレコードを更新する処理には厳密なバリデーションが伴うため、分離します。
2. 業務固有のスロットフィリング（情報の聞き返し）が必要な処理: 「OSのバージョンは？」や「注文番号は？」といった特定の業務でのみ必要なヒアリングロジックをプライマリに持たせると、他の無関係な会話でも誤って情報を聞き出そうとする原因になります。
3. 独立した外部APIやフローを利用する処理: 使用可能なアクション（ツール）が増えるほど、LLMの推論精度は低下します。特定の業務でのみ使うAPIやフローはセカンダリエージェント内に閉じ込めます。

Atlas推論エンジンによる動的タスクルーティング

マルチエージェントオーケストレーションにおいて、タスクを各エージェントへ適切に割り当てる頭脳となるのがAtlas推論エンジンです。実際のAgentforceプレビューログを確認すると、以下のようなハイブリッド推論が行われていることがわかります。

1. 動的ルーティングの決定: Atlasは各セカンダリエージェントの「説明（Description）」や「指示（Instructions）」を評価し、確率論的なLLMベースの推論（LLM_DETERMINED）を用いて、フローを介さずに直接セカンダリへタスクをルーティングします。
2. コンテキストの完全なハンドオフ: セカンダリは独立した内部セッション（relatedAgentSessionId）として立ち上がりますが、これまでの対話コンテキストは維持されます。
3. 推論指示の解決（Resolve）: セカンダリへ遷移すると、Atlasは変数やアクションの参照を実際のコンテキスト値に置き換え、自然言語プロンプト（会話スキル）とプログラム的ロジック（ビジネスルール）を統合して実行します。

これにより、プライマリ側で不要なヒアリングを頑張る必要はなく、セカンダリに完全に会話の主導権を委譲（ハンドオフ）することが可能になります。

処理フローの全体像（構成例）

オーケストレーションのガバナンスとテスト手法

エンタープライズ環境でマルチエージェントシステムを安全に動作させるためには、開発・運用段階での強固なガバナンスとテストが求められます。

• Agent Scriptによる予測可能性の担保: エージェントの大局的なワークフローと自然言語処理を分離することで、LLMの自律性に過度に依存しない、予測可能なロジック制御を実現します。
• 優先管理と競合の解決: 複数のエージェントが同時に応答した場合の処理順序などを管理するシステム的な調停を行います。
• Agentforce テストスイートによる検証: サブエージェントやアクションのメタデータを読み込み、システムが自動的にテスト発話を生成します。エンジニアはこれを利用し、「プライマリが正しくセカンダリへルーティングできるか」「コンテキストが途切れずに会話が継続するか」を定量的に評価できます。

おわりに

SalesforceにおけるA2Aの実装は、「Orchestrate Other Agents」機能の登場により、真のマルチエージェントシステムの理想に到達しつつあります。

対話の窓口と共通処理を担う「プライマリエージェント」と、業務固有のスロットフィリングからデータ更新までを自己完結する「セカンダリエージェント」の責務を厳格に分離する。このアーキテクチャこそが、複雑化するエンタープライズの業務を破綻なくスケールさせるための絶対的なベストプラクティスです。

参考URL

Multi-Agent Collaboration: How Distributed AI Systems Scale Problem Solving

Agent2Agent (A2A) Protocol: Guide to AI Agent Interoperability

AIエージェントオーケストレーションとは？

Multi-Agent Orchestration

Multi-Agent Systems Explained: A Complete Guide

Orchestrate Other Agents (Beta)

Multi-Agent Orchestration (Beta)

What is A2A?