8月29日、Ciscoが「From Isolated Agents to Collective Intelligence: Why A2A Is the Protocol the Agentic SOC Has Been Waiting For」と題した記事を公開した。この記事では、セキュリティオペレーションセンター（SOC）における複数AIエージェントの連携を実現するプロトコル「A2A（Agent2Agent）」のアーキテクチャと、セキュリティチームが今から準備すべき事項について詳しく紹介されている。
問題の核心：エージェントが賢くなっても、ワークフローは止まる
午前2時にアラートが上がる。Splunk内のトリアージエージェントが数秒で情報を補完する。そこでワークフローが止まる。レスポンスをトリガーするために別ツールを開く人間が必要で、チケット作成にはさらに別のツールが必要になる。
エージェント単体の性能ではなく、エージェント間のハンドオフが詰まっている——これが今の全ベンダーに共通する課題だ。Splunkが提供するTriage、Detection Builder、SOP、Guided Response、Automation Builder、Malware Threat Reversingといった各エージェントは、それぞれ1つの仕事をうまくこなす。しかし異なるプラットフォーム上に構築されたエージェント同士が直接作業を受け渡せなければ、人間がその橋渡し役を担い続けることになる。
A2Aはその橋渡しを自動化するためのプロトコルだ。A2AはGoogle DeepMindが2025年初頭に提唱したマルチエージェント通信仕様であり、現在はLinux Foundation傘下のAGNTCYを中心にオープン標準化が進んでいる。ただし記事は率直にも述べている——A2Aを介したエージェント間ハンドオフは現時点でどこにも本番出荷されていない。以下はその概念的アーキテクチャの解説であり、今から基盤を整えておく価値がある理由の説明である。
MCP（垂直）とA2A（水平）：2層で使い分ける
ここが記事の最も重要なポイントだ。A2AはMCP（Model Context Protocol）と並列して機能し、それぞれ異なる問題を解く。MCPはAnthropicが提唱したオープン仕様であり、エージェントが外部ツールやデータソースと連携するための「垂直方向」のインターフェースを担う。A2Aはその上位レイヤーとして、エージェント同士を「水平方向」につなぐ役割を果たす。
MCP：エージェントとデータをつなぐ（垂直方向）
SplunkのMCP Serverは2026年2月に一般提供が開始されており、MCP対応エージェントがカスタム統合なしにSplunkの検索実行・アセットコンテキスト取得・エンリッチメントデータ参照を行える仕組みだ。A2A：エージェントとエージェントをつなぐ（水平方向）
ベンダーやプラットフォームの境界を越えて、エージェント同士が直接作業を委譲し合う。トリアージは一つのコンテキストで、封じ込めは別のコンテキストで、チケット作成はさらに別で実行される。A2Aはその全ワークフローを人間の介在なしに動かすためのプロトコルだ。
記事はSOARとの違いについても明確にしている。SOARはベンダーごとに1本ずつ構築した統合を通じて固定プレイブックをオーケストレーションし、ロジックはSOARプラットフォームに集中する。A2AはP2P型であり、各エージェントが「Agent Card」と呼ばれるJSONマニフェストを自己公開することで、カスタムコネクタなしに相互発見・呼び出しが可能になる。受信側エージェントは静的スクリプトではなく自身の推論を適用する。
「SOARとA2Aは競合しない。A2Aで自律エージェントが意思決定と作業委譲を行い、SOARはその結果として生じるアクションを実行する場所として残る」
A2Aの技術的な仕組み
A2AはHTTP・Server-Sent Events・JSON-RPC 2.0という既存のWebスタンダードの上で動作する。インフラチームがネットワーク制御を再設計せずに導入できるよう意図的に選ばれた設計だ。前述したエージェント間ハンドオフの未解決問題に対して、A2Aは以下の4つの仕組みで対応する。
Agent Cardの公開：A2A準拠エージェントは
/.well-known/agent-card.jsonにJSONマニフェストを公開し、できることと認証要件を宣言する。A2A v1.0で追加された署名付きAgent Cardにより、受信エージェントがカードの発行元ドメインを暗号的に検証できる。悪意あるエージェントがワークフローに割り込むのを防ぐ仕組みだ。Taskの委譲：高速な処理は即座に結果を返す。長時間処理（数週間分のテレメトリにまたがる相関調査など）はSSEを通じてステータスをストリームし、
submitted → working → input-required → completed / failed / cancelledというライフサイクルで管理される。Artifactの返却：テキスト・データ・ファイルの形で構造化された出力が、呼び出し元エージェントに渡される。
認証：OAuth 2.0、APIキー、mTLSなど、既存のAPI管理レイヤーが既に施行しているスキームをそのまま使う。A2A専用の信頼システムは不要だ。
これらはいずれも「新しいインフラを構築する」のではなく「既存のWebスタンダードを組み合わせる」という設計思想に基づいており、エージェント間の自律的なハンドオフを、従来の人手による橋渡しと置き換えることを目指している。
セキュリティチームが今から準備すべき事項
本番稼働前に整備すべき事項として、記事は3つを挙げている。
① エージェントのアイデンティティ管理はPAMの問題として扱う
どのエージェントがどのエージェントをどの条件下で呼び出せるかは、新カテゴリではなく既存のIAMガバナンスの延長として扱うべきだ。サービスアカウントに適用しているのと同じ統制をエージェントIDに拡張する形が推奨される。
② エージェント間トラフィックは監査ログに記録する
タスク委譲ごとに送信元・送信先・コンテンツ・Artifact・タイムスタンプを耐久性のあるログとして残す必要がある。Splunkプラットフォームは特別な統合なしにこのデータを今日から取り込める。ただしEnterprise Security内での相関検索・ノータブルイベント・リスクスコアリングに活用するには、CIMデータモデルへのマッピングか独自モデルの構築という、通常の新規データソースオンボーディングと同等の作業が別途必要になる。
③ プロンプトインジェクション対策はアプリケーション層の責任
A2Aはタスクコンテンツをサニタイズしない。攻撃者が制御するデータ（細工されたログエントリや悪意あるファイル名など）をエージェントが処理してタスクを委譲した場合、ペイロードはそのまま伝播する。入力バリデーションはA2A経由の委譲を設計する段階で組み込む必要があり、後から追加できるものではない。
詳細はFrom Isolated Agents to Collective Intelligence: Why A2A Is the Protocol the Agentic SOC Has Been Waiting Forを参照していただきたい。
