MCP AI 解説：Model Context Protocol が AI エージェントに実際にもたらす変化

2026年4月7日Lin Ivan

要点

AI における MCP は Model Context Protocol のことです。host、client、server が tools、resources、prompts をどう公開するかを標準化します。
MCP が変えるのは統合境界であって、モデルの知能そのものではありません。ツール利用は見つけやすく、移植しやすく、レビューしやすくなります。
MCP だけでガバナンスは成立しません。権限スコープ、コンテキストのバージョン管理、承認、ログは依然としてシステム側の責任です。
本番エージェントにとっての最大の価値は一貫性です。使い捨てのアダプタや隠れた glue code を減らせます。
よい本番構成では、MCP をプロトコル層として使い、その下に統制されたコンテキストシステムを置きます。

AI における MCP とは何か

AI の文脈で MCP は Model Context Protocol を意味します。

名前は抽象的に見えますが、解こうとしている問題はかなり具体的です。ほぼすべてのエージェントスタックは、モデルを tools、files、APIs、prompt templates、外部 resources につなぎたいと考えています。しかし、そのつなぎ方はチームごとにばらばらです。ある framework はすべてを function calling として扱い、別の framework は独自の tool schema を作り、別のシステムはファイルアクセスを専用 plugin のように扱います。

デモが 1 つだけなら、この違いはあまり問題になりません。複数の agent、複数の runtime、複数のチームが関わり始めると、統合レイヤーが一気に最も扱いにくい部分になります。

公式の Model Context Protocol introduction は、MCP を「モデルを必要なコンテキストにつなぐためのオープンプロトコル」と説明しています。ここが重要です。統合のたびに新しい契約を作るのではなく、host 側がより予測可能なプロトコル面に向き合えるようになります。

だからこそ MCP は、一発回答のチャットボットよりも AI エージェントで意味を持ちます。エージェントは答えるだけではありません。読み、計画し、取得し、呼び出し、引き継ぎ、リトライし、ときには行動します。ステップが増えるほど ad hoc な glue は高くつきます。

MCP が実際に変えること

MCP が有効なのは、ばらつきやすい面を標準化するからです。

問題	MCP なし	MCP あり
能力発見	tools やデータの表現が統合ごとに違う	host が共通の形で能力を発見できる
ツール呼び出し	アプリ固有の wrapper と壊れやすい glue	呼び出し契約がより予測可能になる
リソースアクセス	files や docs の公開方法が stack ごとに違う	resources が第一級の面になる
Prompt の整理	テンプレートがアプリコードの中に散らばる	prompts を構造化オブジェクトとして公開できる
可搬性	host を変えると統合を書き直しがち	MCP 対応 host 間で再利用しやすくなる

実務上は、互換性のないツール体系の翻訳に費やす時間を減らし、「その agent に何を許可すべきか」という本来の設計に集中できるようになります。

公式仕様は hosts、clients、servers、そして tools、resources、prompts を第一級の要素として整理しています。最初期の Anthropic announcement も同じポイントを示していました。目的はモデルを賢くすることではなく、AI システムが外部能力やコンテキストにつながるための標準インターフェースを作ることです。最新の MCP specification も参照できます。

MCP が変えないこと

ここは新しい標準への期待が高まるほど見落とされやすい部分です。

MCP はプロトコル境界を標準化しますが、次のものを自動では与えてくれません。

きれいな元データ
安定した業務スキーマ
バージョン管理されたコンテキスト
権限を意識した retrieval
人間による承認フロー
監査可能な traces
評価と rollback

この違いは重要です。多くの本番障害は「モデルが悪い」と見なされますが、実際にはコンテキスト組み立てや capability control の問題であることが少なくありません。

例えば:

server が古いポリシー文書を公開していれば、MCP はその古い文書を忠実に届けます
tool の権限範囲が広すぎても、MCP は勝手に狭めてくれません
agent が特定顧客セグメントや特定フォルダだけを見るべきでも、MCP はそのガバナンスモデルを発明しません

正しい捉え方はこうです。

MCP はプロトコル層であり、本番向けコンテキストシステムは依然としてシステム全体である。

なぜ ad hoc な glue はエージェントで壊れやすいのか

ほとんどのエージェントシステムの最初の版が動いて見えるのは、関係するものが 3 つしかないからです。

1 つのモデル
1 つの runtime
1 つか 2 つの tools

ここまでは幸せです。

問題は次を足した瞬間に表面化します。

複数の tool provider
複数の環境
複数の agent role
人間の承認ポイント
監査やコンプライアンス要件

すると隠れていたコストが一気に出てきます。

Failure mode 1: tool schema が漂流する

あるチームは start_time、別のチームは startAt、さらに別のチームは begin と呼ぶかもしれません。モデルは時々なんとかしますが、人間は「カレンダーツール」が何を意味するのか信用しなくなります。

Failure mode 2: capability boundary が曖昧になる

その agent は ticket を読むだけなのか、それとも閉じられるのか。契約書を取得するだけか、それとも更新できるのか。インターフェースが明示しないと、ポリシーの意味はコメントや prompt、暗黙知に漏れていきます。

Failure mode 3: host ごとに雪片化する

ある host で動いた統合が、別の host ではそのまま通用しません。実験速度が落ち、セキュリティレビューも毎回重くなります。

MCP は本番スタックのどこにあるか

実用的な agent platform には、少なくとも次の 5 層が必要になることが多いです。

層	役割
データと文書	元の files、tickets、records、APIs
コンテキスト整形	正規化、schema mapping、indexing、versioning
プロトコル配信	MCP、API、その他の delivery surface
runtime 制御	planning、retries、budgets、fallbacks、approvals
ガバナンス	access control、logs、evaluation、rollback

MCP は 3 層目にあります。

これは大事な設計ヒントです。プロトコルがきれいでも、下のコンテキストが混乱していれば、それをより一貫して露出させるだけです。