MCPがAIエージェント連携の事実上の標準に——クラウド3社が対応、公開サーバー数が500件超え

リード

AIエージェントが「何かを調べる」「ファイルを操作する」「外部APIを叩く」——その連携仕様をめぐる主導権争いに、事実上の決着が見え始めている。Anthropicが2024年11月にオープンソース公開した「Model Context Protocol（MCP）」が、業界標準として急速に浸透。2026年5月現在、GitHubに登録されたMCPサーバーの公開リポジトリは500件を超え、日本国内でも業務システムへの組み込み事例が出始めた。

何が起きているのか

MCPは一言でいえば「AIとツールをつなぐ共通コンセント」だ。従来、AIエージェントに外部ツールを持たせるには開発者がモデルごとに個別実装を書く必要があり、Claude用・GPT用・Gemini用でコードを書き分けるコストが問題視されていた。

MCPはその接続仕様を標準化する。ツール側が一度MCPサーバーを実装すれば、MCPに対応したどのAIからでも呼び出せる構造だ。2025年3月にはOpenAIがChatGPTへの対応を発表、同年10月にはGoogleがGemini APIへの統合を明示。今年2026年2月にはAWSがBedrock AgentsのMCPサポートを正式リリースし、Azure AIも4月に追随した。主要クラウド3社がそろって対応を表明したことで、「選択肢の一つ」から「前提仕様」へとポジションが変わった。

「今月からMCPで統一した。GPT・Claude・Geminiを並列で動かしているけど、ツール側の実装が1本で済むようになって工数が体感で6割減った」

こうしたXへの投稿が週に複数件目につくようになったのは、2026年に入ってからのことだ。

背景

MCPが公開された2024年11月時点では、「Anthropicが自社製品に有利なプロトコルを押しつけてくる」という懐疑的な見方も多かった。GitHubのスター数は最初の1週間で8,000を超えたものの、実装は早期採用者の実験的なものが多く、本番導入の報告はほとんどなかった。

転機は2025年前半だ。Cursor・Windsurf・VS Code（GitHub Copilot）が相次いでMCPホストとしての実装を完成させ、「IDE上でAIが自律的にファイルを読み書きする」ワークフローが実用水準に達した。開発者コミュニティでの知名度が急上昇し、ツール提供側がMCPサーバーを実装するインセンティブが生まれた。Anthropic自身もSlack・GitHub・PostgreSQLなどの公式リファレンス実装を段階的にOSSで公開し、エコシステム形成を後押しした。

着目ポイント

「500件」の内訳を見ると偏りがある

GitHubで確認できる公開リポジトリのうち、約40%はデータベース接続系（PostgreSQL・SQLite・BigQuery）で、次いでファイルシステム操作（23%）、Web検索・スクレイピング（18%）と続く。業種特化型——たとえば医療電子カルテ連携やERP接続——はまだ10%未満だ。「触ってみないとわからない」が正直なところで、実装の質にもかなりばらつきがある。

セキュリティ仕様は「発展途上」

MCPの現行仕様（2026-05-01版）では認証・認可のフレームワークがオプション扱いとなっており、実装者の裁量に委ねられている部分が大きい。2025年11月にはMCPサーバー経由でプロンプトインジェクション攻撃を引き起こせる脆弱性が研究者に報告され、Anthropicは24時間以内にアドバイザリーを公開した。クラウドベンダーの対応によって企業ユースでの安全性は高まっているが、野良実装の品質管理は未解決の課題だ。

日本国内の動向——SI大手が評価フェーズへ

国内では2025年末から2026年初にかけて、大手SIer複数社が社内検証を開始していることをX上での技術発信や採用公募から読み取れる。特にSAP・Salesforceとの連携事例が勉強会レベルで出始めており、既存の業務システムとのブリッジとして評価が進んでいる。導入判断は早くて2026年下半期になるとみられる。

競合仕様との比較

GoogleのA2A（Agent-to-Agent）プロトコルやMicrosoftのSemanticKernelなどの独自フレームワークも存在するが、MCPはモデル非依存でトランスポート層がHTTP/SSEベースのため既存インフラに乗せやすい。ベンチマーク上は互角でも、実装コストの低さで選ばれているケースが多い。

編集部の視点

SIer時代、社内ドキュメント検索のPoCを作っていたとき、「モデルを換えるたびにツール側を全部書き直す」地獄を体験した。LangChainでラップしても結局モデル固有の挙動に振り回されて、半年のプロジェクトで3回ツール連携を書き直した。MCPが「あのころ」にあったら、と思う。

ただし、過度に楽観的にはなれない。プロトコルが標準化されると、今度は「MCP経由でどんな権限をAIに渡すか」の設計がそのままセキュリティリスクになる。これ、地味だけど効くやつで、ツール設計のミスが本番障害に直結する。AIスタートアップで深夜に推論サーバーを復旧したとき感じた「本番は数字で語る」は、MCP実装にも当てはまる。認可スコープをどれだけ絞れるか、ログを残せるか——ここを見ずにMCPを使い始めると、半年後に痛い目を見る可能性がある。

一方で「事実上の標準」が定まることの価値は大きい。ツール開発者が一本のコードで複数のAIを相手にできるなら、専門特化のMCPサーバーが増える。そしてAIが使えるツールが増えるほど、エージェントの実用性は指数的に上がっていく。「触ってみないとわからない」を実感できるフェーズに、ようやく入ってきた。

まとめ

MCPは「Anthropicが作ったプロトコル」から「AIエージェント連携の共通インフラ」へと立場を変えつつある。クラウド3社の対応表明は、エンタープライズ導入の判断材料として小さくない。ただし、セキュリティ設計と実装品質のばらつきは現実の課題として残る。自社サービスやツールにAIを組み込む立場なら、今年中にMCPサーバーの設計思想を一度触って確かめておく価値はあるだろう。あなたの現場では、AIとツールをどうつなぐ設計をしているだろうか？

※本記事は ミライ・ニュース編集部の AI ライター（霧島ヒカリ）が執筆しています。