Nullstead

AIエージェント

2026年のエージェント開発は「MCPだけ」でも「A2Aだけ」でも回らない話

MCP・A2A・Responses APIを2026年時点の一次情報で整理。個人開発で動くデモを実運用へ育てるための役割分担、非同期設計、セキュリティ実装を具体例つきで解説します。

約9分

AIエージェントの設計をしていると、最近は必ずと言っていいほど「MCPでいけますか？」「A2Aも必要ですか？」という話になります。結論から言うと、**MCPは“道具箱の規格”で、A2Aは“チーム連携の規格”**です。どちらか片方だけで全部やろうとすると、だいたい後で「想定外の配線工事」が始まります。私も何度か配線工事をして、心の中の工務店を開業しかけました。

この記事では、2025〜2026年に公開された一次情報をもとに、MCP・A2A・Responses API（特に background mode とツール連携）をどう組み合わせると個人開発でも実運用しやすいかを整理します。流行語の暗唱ではなく、実装時に揉めやすいポイントを先回りして解説します。

MCPとA2Aの役割分担を先に固定する

まずは用語の交通整理です。

  • MCP（Model Context Protocol）: モデルが外部ツールやデータにアクセスするための共通プロトコル
  • A2A（Agent2Agent）: エージェント同士が依頼・進捗・結果をやり取りするための共通プロトコル

※ MCP: モデルに「何が使えるか」を渡し、必要に応じてツールを呼ばせる枠組みです。
※ A2A: 複数エージェント間の協調を、HTTP/SSE/JSON-RPCなど既存標準の上で実現する枠組みです。

GoogleのA2A発表では、50以上のパートナーと一緒に「異なるベンダー・異なる基盤のエージェントを連携させる」ことが目的として示されました。逆にMCPは、Anthropicの整理どおり「外部システム接続の標準化」が中核です。つまり、MCPは“エージェントが使う手”を増やし、A2Aは“エージェントの会話”を整える、という関係です。

ここを曖昧にすると、設計レビューで次のような会話が生まれます。

  • 「この調整役エージェント、MCP server_urlを2個足せばいけるのでは？」
  • 「それ、調整役というより“でかい単一エージェント化”してません？」

はい、未来の自分が泣くやつです。

2026時点の現実: プロトコルは成熟中、運用論はこれから

MCPロードマップ（2026-03更新）を見ると、優先領域はかなり実務的です。特に次の4つが重要です。

  1. Transportのスケール運用（stateless化、LB/Proxy配下での正しい動作）
  2. セッション管理（再開・移行）
  3. Tasksのライフサイクル（retry、expiry）
  4. 監査・観測性などのEnterprise Readiness

この並びから読み取れるのは、「もう概念実証の段階ではない」ということです。社内PoCで動くだけでは足りず、落ちたときに復帰できるか、誰が何を呼んだか追えるかが主戦場になっています。

AnthropicがMCPをAAIF（Linux Foundation配下）へ寄贈した発表でも、非同期処理・stateless・server identity・公式拡張など、運用に直結する更新が明示されました。ここから先は「新しい略語を覚えた人」が勝つのではなく、障害時のふるまいを設計できる人が勝ちます。

Responses APIで実装するときの実務ポイント

OpenAI Responses APIの更新は、エージェント実装側の設計自由度をかなり上げました。特に次が効きます。

  • remote MCP servers 対応
  • background mode（長時間処理の非同期化）
  • reasoning summaries
  • 1Mコンテキスト + compaction（モデルによる）

ただし、ドキュメントを読むと便利機能には前提条件があるのが分かります。

  • background mode は store=true 相当の保存前提で、ZDR要件と緊張関係がある
  • background + stream 併用時は再接続戦略（cursor管理）が必要
  • MCP利用時は mcp_list_tools / mcp_call など出力イベントの解釈が必要

つまり、API呼び出しを1回書いて終わりではなく、状態遷移を持つ小さなワークフローとして扱う必要があります。

最小構成のイメージ（Python）

from openai import OpenAI
from time import sleep

client = OpenAI()

resp = client.responses.create(
    model="gpt-5.4",
    input="最新の障害対応手順を要約して、TODOを抽出してください",
    background=True,
    tools=[{
        "type": "mcp",
        "server_label": "docs",
        "server_url": "https://example.com/mcp",
        "require_approval": "never"
    }]
)

while resp.status in {"queued", "in_progress"}:
    sleep(2)
    resp = client.responses.retrieve(resp.id)

print(resp.status)
print(resp.output_text)

※ 上記は説明用サンプルです。実運用では require_approval の扱いを用途別に分け、監査ログを必ず残してください。

「全部1エージェント」で始めると詰まりやすい理由

個人開発だと最初は単一エージェントが最速です。これは正しいです。私もまずは単一で作ります。ただ、次の条件が揃ったら分割を検討したほうが安全です。

  • 外部連携先が3つ以上になった
  • 同期処理だとタイムアウトが増えた
  • 承認フロー（人間確認）を挟みたい
  • 失敗時の再実行単位を細かくしたい

このとき、設計は次のように切り分けると事故りにくいです。

  • Execution Agent: MCPでツール実行（I/O担当）
  • Planner Agent: タスク分解と優先度制御（頭脳担当）
  • Coordinator Agent: A2Aで依頼配布・進捗集約（進行管理担当）

要するに、MCPで“手を増やし”、A2Aで“役割分担”するわけです。これをやらずに単一エージェントへ責務を盛ると、最終的に「なんでも屋さん」になって、障害時に原因切り分けが地獄になります。万能感は高いのですが、だいたい翌週に返済が始まります（技術的負債ローン、金利高め）。

セキュリティとガバナンス: 便利機能の副作用を管理する

MCP/Connector連携は強力ですが、OpenAIのガイドでも「信頼できるリモートMCPを使うこと」が明確に警告されています。悪意あるサーバーは、モデル文脈に入った情報を外部へ持ち出すリスクがあります。

最低限、次は実装しておくべきです。

  1. allow-list運用: 接続先MCPを固定し、用途別に分離
  2. allowed_tools制限: 必要なツールだけ公開
  3. 承認ポリシーの分離: 読み取り系は自動、書き込み系は承認必須
  4. 監査ログ: mcp_callの引数・結果・呼出主体を保存
  5. データ保持方針の明示: background mode利用時の保持要件を利用規約に反映

「便利だから全部自動承認」は、最初は気持ちいいです。ですが運用が始まると、気持ちよさの請求書が月末に届きます。支払うのはだいたいSREか未来の自分です。

個人開発向け: まず90日で狙う現実的ロードマップ

最後に、個人開発で無理なく進める順序を提案します。

Phase 1（1〜3週）

  • 単一エージェント + MCP 1〜2系統
  • 失敗時のリトライ方針だけ先に定義
  • 監査ログの形式を固定

Phase 2（4〜8週）

  • background mode導入
  • ポーリング監視 + キャンセル処理
  • ツール承認ポリシーを「読み取り/更新」で分離

Phase 3（9〜12週）

  • Coordinatorを分離し、A2Aで依頼受け渡し
  • 長時間タスクを非同期ジョブ化
  • 指標を追加（成功率、平均完了時間、再試行率）

この順序だと、いきなり壮大なマルチエージェント基盤を作らずに済みます。大事なのは、プロトコルを導入することではなく、運用可能性を一段ずつ上げることです。

よくある落とし穴Q&A（実装前に踏み抜きがちなやつ）

最後に、実装レビューで頻出する質問を短くまとめます。

Q1. MCPがあるならA2Aは不要では？
A. 単一エージェントで完結する範囲なら不要です。ただし、責務分離・再実行単位・担当境界が必要になった時点でA2Aの価値が一気に上がります。MCPはツール接続の標準であり、組織間・エージェント間の契約そのものではありません。

Q2. background modeを入れれば長時間処理は全部解決？
A. 解決しません。キュー滞留、キャンセル、再接続、結果保持期限、通知導線（Webhookやポーリング）を設計しないと、単に「遅い同期処理」が「管理されない非同期処理」に変わるだけです。便利機能は魔法ではなく、運用項目を増やす装置でもあります。

Q3. 承認フローは最初から厳格にすべき？
A. 書き込み・送信・課金が絡む操作は最初から厳格にした方が安全です。読み取り系まで全部手動承認にすると、今度は人間がボトルネックになります。ここはセキュリティと生産性のトレードオフ設計です。

この3つを先に合意しておくと、実装後の「そんな仕様だと思ってなかった」をかなり減らせます。仕様書より先に冷や汗を減らせるので、効果は高いです。

まとめ

2026年のエージェント開発は、MCPとA2Aの二者択一ではありません。

  • MCP: モデルに外部能力を安全に与える
  • A2A: 複数エージェントの責務を整理して連携する
  • Responses API: 非同期実行・ツール連携・長文脈運用を実装に落とす

この3つを役割ベースで組み合わせると、個人開発でも「動くデモ」から「落ちても戻せる運用」へ進化しやすくなります。派手さは少し減りますが、睡眠時間は増えます。私は睡眠時間が増える設計を強く推します。CPUより先に人間の冷却が必要だからです。

参考情報

  1. OpenAI: New tools and features in the Responses API
    https://openai.com/index/new-tools-and-features-in-the-responses-api/
  2. OpenAI API Docs: Background mode
    https://developers.openai.com/api/docs/guides/background
  3. OpenAI API Docs: MCP and Connectors
    https://developers.openai.com/api/docs/guides/tools-connectors-mcp
  4. OpenAI API Changelog
    https://developers.openai.com/api/docs/changelog
  5. Google Developers Blog: Announcing the Agent2Agent Protocol (A2A)
    https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/
  6. Model Context Protocol: Roadmap (updated 2026-03-05)
    https://modelcontextprotocol.io/development/roadmap
  7. Anthropic: Donating MCP and establishing AAIF
    https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation
Tags #AIエージェント #MCP #A2A #Responses API #個人開発 #自動化
← 記事一覧に戻る ページの先頭へ ↑