Google Cloudが解説するMCP — Anthropic発のオープン標準が『AIのHTTP』になる理由

Google Cloud Techが Anthropic 発の Model Context Protocol (MCP) を概説する公式動画。冒頭の問題提起は明快だ。AIモデルを自社のツールやデータと連携させようとすると、API挙動がバラバラ、統合ごとにカスタムコード、モデル更新で接続が壊れる。AI 開発者の長年の頭痛の種だった。

根本原因はAPIの設計思想にある。従来APIは『すでに自分が何を欲しいか分かっているプログラム』向けに設計され、正確で決定論的なリクエストを前提とする。一方LLMは確率的に出力し、不確実な入力で推論し、結論を出す前に質問・確認・探索を必要とする。マッチしないインターフェース同士を強引につなぐ役割を、これまでは脆いシステムプロンプトと開発者の苦労が引き受けていた。MCPはここに『AI に合わせたインターフェース層』を入れる試みだ。

MCPアーキテクチャはシンプルなクライアント/サーバー構造を取る。サーバー側はDB、ファイルシステム、社内ツール、ドキュメント検索エンジンといったリソースを公開する。クライアント (Claude などモデル側) が接続すると、サーバーはデータを返すのではなく『自分には何ができ、どんな入力が必要か』というケイパビリティを広告する。

この設計の効果が大きい。モデルは事前に全APIエンドポイントを知っている必要がなく、接続時に動的に発見できる。やり取りはシンプルで定義の明確なスキーマに従う。クライアントは『利用可能なリソース一覧』『このアクション実行』『このデータ取得』といったリクエストを送り、サーバーは構造化JSONで何が可能か・何が起こったかを返す。技術的には4種のリソースが基本要素になる: tools (実行可能なアクション)、resources (データ・状態)、prompts (再利用テンプレート)、context (外部情報)。各要素はメタデータ付きで、何ができ、何を入力に取り、何を返すかが明示される。

実例で見るとMCPの恩恵が際立つ。カレンダー確認・議事録取得・フォローアップメール作成を担うパーソナルアシスタントエージェントを作るとする。旧世界では Google Calendar、Notion、Gmail それぞれのAPIに個別コードを書き、認証・レート制限・各種エッジケースを処理し、さらに長く脆いシステムプロンプトでモデルに使い方を教える必要があった。

MCPでは各システム向けにサーバーをビルドかインストールするだけだ。カレンダーサーバー、ノートサーバー、メールサーバー。各サーバーは『list events』『get meeting summary』『send email』のような利用可能ツールを広告し、モデルは自動でそれらを認識する。どれを、どの順で、どんなデータを渡して使うか、をモデル自身が推論する。グルーコードを毎回書く必要がない。動画は『HTTPがWebを統一した』のと同じ意味でMCPがAIモデルとツールの対話を統一しつつある、と締める。本格的なAI開発者は自社システムを MCP aware に設計する必要が出てくるだろう、というのが Google Cloud からの提言だ。