Nullstead

AI

2026年、AIエージェント自動化の設計図を描く：MCPとA2Aを“接着剤”として使う現実解

2026年のAIエージェント開発で重要になるMCPとA2Aを、認証・安全性・運用設計の観点から実践的に解説。個人開発でも回せるアーキテクチャと実装の勘所をまとめました。

約10分

2026年、AIエージェント自動化の設計図を描く：MCPとA2Aを“接着剤”として使う現実解

「AIエージェントで業務を自動化したいです」という相談は、2025年後半から本当に増えました。以前は「チャットボットを置いておきたい」が主流でしたが、最近は「実際に仕事を進めるAIがほしい」に変わっています。つまり、答えるだけでなく、調べて、判断して、実行して、報告するところまで期待されているわけです。AIに対する期待値、だいぶ上がりましたね。新人に「まず社内ドキュメント10万ページ読んでから来てください」と言うのと同じくらい上がっています。

ただし、ここで必ずぶつかるのが「接続の問題」です。AIモデル単体は賢くても、Slack、GitHub、Notion、Jira、社内DB、監視基盤…といった現場の道具に安全かつ再利用可能な形でつなぐ仕組みがないと、すぐに“なんちゃって自動化”になります。そこで2025年以降、実務で急速に重要になってきたのが MCP（Model Context Protocol） と A2A（Agent2Agent） です。

この記事では、2026年時点での最新動向を踏まえつつ、個人開発〜小規模チームでも回せる「現実的なエージェント自動化アーキテクチャ」を整理します。結論を先に言うと、**MCPは「道具への接続規格」、A2Aは「エージェント同士の会話規格」**として分けて考えると、設計が一気にシンプルになります。

MCPは“AI用USB-C”になれるのか

MCPは、LLMアプリケーションと外部データ・ツールをつなぐためのオープンなプロトコルです。仕様では、Host / Client / Server の役割が分かれており、JSON-RPC 2.0ベースで機能をやり取りします。MCPサーバーが提供できる機能は、主に Resources / Prompts / Tools の3種です。ここだけ見ると「ふむふむ、また新しい規格ですね」で終わりそうですが、実務上の価値はそこではありません。

価値は、**“モデル依存の個別実装を減らせる”**ことです。これまでのツール連携は、モデルA向けの関数呼び出しと、モデルB向けのプラグイン風実装を、それぞれ持つ必要がありました。MCPでサーバー側を標準化しておけば、ホスト側（エージェント実行基盤）を差し替えても再利用しやすくなります。言ってみれば、毎回専用充電器を探していた時代から、ようやくUSB-Cで統一し始めた感じです。引き出しの中のケーブル本数が減る、あの幸福です。

OpenAIのResponses APIも2025年に remote MCP servers のサポートを打ち出し、Code Interpreterや画像生成などの組み込みツールと並列で扱える方向に進みました。これは「MCPは一部の実験的機能ではなく、商用エージェントの主要接続面になっていく」というシグナルとしてかなり強いです。

※ MCP（Model Context Protocol） LLMアプリとツール接続を標準化するオープン仕様。ざっくり言うと「AIが外部機能を呼ぶための共通言語」です。

2025年後半に増えた“現実の痛み”：認証と安全性

MCPを触って最初に感動し、2日後に現実を知るポイントが認証です。ローカル検証ではサクサク動くのに、チーム運用や本番運用へ持っていくと「このトークン誰が管理するの問題」「このサーバー本当に信用してよいの問題」が同時に噴き出します。

MCPの2025-06-18仕様では、Authorization周りがかなり明確化されました。特に重要なのが、OAuthの Resource Indicators（RFC 8707） をクライアント側で必須化する方向です。これは、アクセストークンの利用先を明示し、悪意あるサーバーへのトークン横流しリスクを減らすための要件です。

ここは地味ですが、実装品質を分ける分水嶺です。なぜなら、プロトコルの利便性が上がるほど、接続先が増え、権限境界が複雑になるからです。「便利だから全部つなぐ」は、セキュリティの文脈では「燃えやすいものをコンロの周りに置く」とほぼ同義です。

Cloudflareが2025年に公開したMCP Server Portals（Open Beta）も、まさにこの痛みに対応しています。要点は、MCP接続を集中管理し、観測し、ポリシーで締めること。つまり、MCPを“便利な野良接続”で終わらせず、企業システムとして管理可能にする方向性です。

A2Aは「複数エージェント時代の交通整理」

MCPが「AIとツールの接続」だとすると、A2Aは「AIとAIの接続」です。Googleが2025年4月に発表し、同年中にLinux Foundation配下で中立的な運営に移ったことで、特定ベンダー依存のプロトコルではなく、エコシステム規格として見る価値が高まりました。

A2Aの設計思想で実務的に重要なのは次の3点です。

  1. 既存標準の上に乗ること（HTTP / SSE / JSON-RPC）
    既存インフラと組み合わせやすい。
  2. 長時間タスクを前提にしていること
    「5秒で返すQA」ではなく、調査・実行・承認待ちを含むワークフローへ適用しやすい。
  3. 認証・認可を最初から考慮していること
    社内導入時の“後付けセキュリティ地獄”を減らせる。

これを現場の言葉に置き換えると、MCPで道具を持たせ、A2Aで役割分担させるです。たとえば、

  • 監視エージェント：アラート要約
  • 修復エージェント：再起動・ロールバック提案
  • 検証エージェント：影響範囲チェック
  • 報告エージェント：チケット更新

のように分業させる設計がしやすくなります。人間のチーム編成をそのまま機械に写せるのは、運用上かなり大きいです。

実装パターン：個人開発でも回る“1親方+専門職3人”構成

ここからは、私が2026年におすすめする最小構成です。規模を問わず拡張しやすく、失敗しても巻き戻しやすいのが利点です。

全体像

  • Orchestrator（親方）
    • ユーザー要求を受ける
    • どの専門エージェントへ渡すか判断
    • 最終結果を統合して返す
  • Research Agent（調査担当）
    • Web検索・ドキュメント収集
  • Action Agent（実行担当）
    • MCP経由で外部ツール操作
  • Guard Agent（監査担当）
    • 権限、危険操作、個人情報漏えいチェック

このとき、MCPサーバーは機能単位で分けます。たとえば mcp-github、mcp-slack、mcp-database-readonly のように分離し、「便利だから全部入り」サーバーを作らないのがコツです。全部入りにすると、後で権限設計が爆発します。経験者はだいたい一度燃えています。

実践コード：OpenAI Responses API + remote MCP の最小例

以下は「1回の問い合わせでMCPツールを呼ぶ」最小イメージです。環境差分があるため、実運用前に必ず検証してください（※動作未検証のサンプルです）。

# 例: Node.js + OpenAI SDK
npm i openai

import OpenAI from "openai";

const client = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });

const response = await client.responses.create({
  model: "gpt-4.1",
  input: "直近24時間の障害チケットを要約して、優先度順に3件ください。",
  tools: [
    {
      type: "mcp",
      server_label: "incident-hub",
      server_url: process.env.MCP_SERVER_URL,
      require_approval: "never"
    }
  ]
});

console.log(response.output_text);

実運用でのポイントは3つです。

  1. require_approvalを環境で切り替える
    開発中は always、本番は操作種別ごとに条件分岐が安全です。
  2. ツール呼び出しを監査ログへ必ず残す
    「何を、誰の権限で、いつ実行したか」を後追いできる形にします。
  3. 読み取り専用ツールを先に作る
    いきなり書き込み権限を渡さない。まずは“見える化”から。

失敗しないための設計ルール5つ

1. プロトコルと業務ロジックを分離する

MCP/A2Aは接続のための層です。業務判断（承認条件や例外処理）は別レイヤーに置きます。ここを混ぜると、仕様更新時に全体が巻き込まれます。

2. 「最小権限 + 有効期限」を徹底する

OAuthトークンは短命化し、スコープを狭めます。MCP接続先が増えるほど、横展開リスクは指数的に上がります。

3. 人間の承認ポイントをUIで明示する

危険操作（送金、削除、外部送信）は必ず承認を挟みます。エージェントの自律性は便利ですが、責任は人間側に残るからです。

4. 観測可能性（Observability）を最初に入れる

トレース、構造化ログ、ツール呼び出し履歴を後付けにしない。問題が起きてから観測を足すのは、火事の最中に火災報知器を注文するようなものです。

5. “単一巨大エージェント”を避ける

万能エージェント1体に全部任せるより、責務を分割した複数エージェントの方がデバッグしやすく、安全設計もしやすいです。

2026年の見取り図：MCPとA2Aは競合ではなく補完

「MCPとA2A、どっちに賭けるべきですか？」という質問をよく受けます。私の答えはシンプルで、賭ける対象ではなく、重ねて使う対象です。

  • MCP：ツール・データ接続の共通化
  • A2A：エージェント間協調の共通化

この2つが揃うと、エージェント基盤は「単機能デモ」から「運用可能なシステム」へ進化します。さらに、GitHubのMCP Registryのようにサーバー発見性を上げる動きも進んでおり、2026年は“接続できること”より“安全に運用し続けられること”が差別化要因になっていくはずです。

派手なデモはSNS映えしますが、現場で価値を出すのは地味な設計です。権限、監査、分業、失敗時の戻し方。ここを丁寧に作るチームが、最終的に速くなります。AI時代なのに地味な話で締めるのは若干ロマン不足ですが、実装はだいたい地味が勝ちます。悲しいですが、だいたい本当です。

参考リンク

Tags #AI #MCP #A2A #自動化 #個人開発
← 記事一覧に戻る ページの先頭へ ↑