9月23日、O'Reillyが「MCP Is Not Just Another API Standard」と題した記事を公開した。MCPが単なるAPIラッパーではなく、AIエージェントのアーキテクチャそのものを変える統合プロトコルである理由について詳しく論じている。記事の核心は、「ツールの説明文がコードよりも重要になる」という逆説的な主張だ。エンジニアがJSONスキーマを完璧に書いても、説明文が不十分ならエージェントは別のツールを選ぶ——この現実が、MCPを従来のAPI標準と根本的に異質なものにしている。
MCPとは何を標準化しているのか
MCP（Model Context Protocol）は、Anthropicが2024年11月に公開したJSON-RPCベースのプロトコルだ。クライアント（LLMを動かす側）とサーバー（ツールや情報を提供する側）が会話するための、固定された5つのプリミティブを定義している。
- Tools：呼び出し可能な関数。名前・説明・JSONスキーマで定義する
- Resources：URIで参照できる読み取り専用のコンテキスト（ファイル、ドキュメント等）
- Prompts：サーバーが提供する再利用可能なテンプレート
- Sampling：サーバーがクライアント側のモデルにテキスト生成を依頼する仕組み。通常の「クライアントがサーバーを呼ぶ」方向とは逆の、サーバー起点の推論リクエストを可能にする
- Elicitation：タスク実行中にサーバーが人間へ追加入力を求める仕組み（2025年6月の改訂で追加）。エージェントが自律実行中に判断を人間へ差し戻すためのチャネルとして機能する
5つのプリミティブは個々に見れば目新しくない。重要なのは、モデル・フレームワーク・ベンダーを問わず、常にこの同じ5つであることだ。記事の著者はこれを「バリュープロポジション全体を一文で表すとそれだけだ」と言い切っている。
「AIエージェントの配管」という比喩が間違っている理由
MCP以前のLLMシステムとの統合は、フレームワークごとに独自のツール呼び出し規約を実装する作業だった。LangChainを使えばLangChain用のアダプタを、別のフレームワークを追加すれば互換性のない別のコピーを書く必要があった。維持コストはフレームワーク数に比例して増えた。
MCPはこれを一つの契約に集約する。一度書けば、どんな準拠クライアントからでも呼び出せる。著者はこれを「メンテナンスコストがフレームワーク数に比例していたものが、システム数だけに比例するようになった」と表現している。
ただし、より本質的な変化は別の場所にある。従来のAPI統合は「あらかじめ二者間で合意した契約」だ。エンドポイント・ペイロード・認証・バージョニングを事前に設計し、コードはその計画に従う。
MCPサーバーにはその余裕がない。どのエージェントが呼ぶか、どの順番で呼ぶか、他のどのサーバーと組み合わせられるか、何を目的に呼ばれるか——これらはすべて、人間がチャットボックスに入力した30秒後にエージェントがランタイムで決める。構成を担う主体が自分のコードではなく、モデルになった。これはスタイルの違いではなく、統合問題のカテゴリが変わったことを意味する。
「ツールの説明文」が実はインターフェースである
ここが記事で最も実践的に刺さるポイントだ。
JSONスキーマはパラメータの型を保証する。しかし「このツールをいつ使うべきか」はスキーマでは決まらない。それを決めるのはツールの名前と説明文であり、エージェントはこの数百トークンで正しいツールを選ぶかどうかを判断する。
記事が挙げる具体例を見ると差は歴然だ。
技術的には正しいが不十分な説明：
{
"name": "get_status",
"description": "Returns the current status of a record given its ID."
}
実際にエージェントが使える説明：
{
"name": "get_status",
"description": "Returns the current fulfillment status for an order record.
IDs are numeric order numbers (e.g. 48213), not SKUs or customer IDs. Status
values are one of: pending, processing, shipped, delivered, cancelled. Use this
instead of get_shipment_status, which returns carrier tracking events rather
than the order's internal state."
}
後者は「書いた人間には当たり前すぎる情報」を明示している。だがエージェントは初めてそのツールに出会い、隣に聞ける同僚もいない。著者は「ツール説明の執筆はバックエンドエンジニアリングというよりテクニカルライティングとプロダクトデザインに近い」と指摘する。そして、説明が不十分なMCPサーバーを技術的に正しく実装したにもかかわらず、エージェントが別の（より説明が丁寧な）ツールを選ぶ現場を実際に見てきたと述べている。
組み合わせはコントロールできない
MCPの魅力は、事前に合意していないサーバー同士のツールをエージェントが自由に組み合わせられることだ。それはリスクでもある。
従来の統合では「AをコールしてからBかCを選ぶ」というシーケンスはスクリプトに書かれ、レビューされ、ユニットテストできた。MCPエージェントでは、同じシーケンスがモデルのランタイム推論で生成される。決まっていない決定をユニットテストすることはできない。
単体で正しく動くツールでも、エージェントが想定外の順番で呼んだとき、あるいは別のサーバーの出力をそのまま入力として渡したとき、誤った結果を出すことがある。このバグはコードレビューで見えず、テストスイートがその組み合わせをたまたま再現しない限り検出されない。本番環境で、特定の条件が揃ったとき初めて表面化する。
仕様の進化が示すもの
記事公開時点における最新の仕様改訂（2026年7月28日付）の変更内容は、どこで実際に痛みがあったかを示している。著者は元記事内でこの改訂を「これまでで最大の変更」と位置づけており、MCP公式サイトのChangelogで内容を直接確認できる。
- プロトコルコアのステートレス化：セッションIDによるセッション管理を廃止。水平スケールする通常のロードバランサーで動く構成に対応
- Tasks：長時間実行処理（ドキュメント処理、多段階承認等）のファーストクラスサポート
- MCP Apps：ツールがインタラクティブなUIを返せるように
- 認証の強化：OAuth 2.1とOpenID Connectへの準拠
- レガシーHTTP+SSEトランスポートの非推奨化：12ヶ月の移行期間付き
公式レジストリには約1万のサーバーが登録され、TypeScript・Python両SDKのダウンロード数はそれぞれ累計10億回を超えていると著者は述べている。プロトコルの原著者の競合他社も数ヶ月以内に採用した。
ガバナンスは追いついていない
2026年を通じた独立系セキュリティ研究によれば、公開登録されているサーバーの大多数にパストラバーサルを誘発しうるファイル操作パターンが存在する。コマンドインジェクションやSSRF（Server-Side Request Forgery：サーバーが攻撃者の指定した内部URLへリクエストを送らされる脆弱性）に脆弱なサーバーも一定数確認されており、ツール説明文そのものを攻撃ベクタとする「ツール説明ポイズニング」——悪意ある説明文を注入してエージェントの挙動を操作する手法——の事例も開示されている。大手ベンダーの本番パッケージで認証欠如の高深刻度脆弱性が発見・修正された事例もある。
著者が推奨する対策は以下の4点だ。
- エージェントごとに審査済みツールの明示的な許可リストを設ける（オープンディスカバリーではなく）
- すべてのリモートエンドポイントに認証を課す（「内部トラフィックだから例外」を認めない）
- エージェントのすべてのツール呼び出しを集中型の改ざん不可ログに記録する
- シークレットはサーバーのローカル設定ではなくシークレットマネージャーから動的に取得する
そして実装上の重要な注意点として、「半年前にコピーしたサンプルリポジトリではなく、現行仕様（2026年7月版）に対してビルドせよ」と強調している。ステートレス化と認証変更は見た目の修正ではなく、古いベースラインを今日ターゲットにすることは初日から技術的負債を意図的に抱えることだ。
詳細はMCP Is Not Just Another API Standardを参照していただきたい。
