MCPとは、Rest APIとの関係
大規模言語モデル（LLM）は、単体でも十分に賢くなりました。しかし、業務で本当に使えるAIにするためには、外部のデータやシステムとどうつなぐかが依然として最大の課題です。
これまでこの役割を担ってきたのは、言うまでもなくAPIでした。
APIは人間（開発者）が仕様を理解し、コードを書き、バージョン差分を追い続ける前提で設計されています。
ところが2024年後半、Anthropicが発表した Model Context Protocol（MCP） は、この前提を根本から揺さぶります。
MCPは「APIをAIに使わせる方法」ではなく、**「AIが自律的に能力を理解し、使いこなすための標準」**として設計されています。
本記事では、MCPを理解するうえで欠かせない3つのポイントを整理します。
1. MCPを一言で言うなら「AIアプリのUSB-Cポート」
MCPを最も分かりやすく表現する比喩は、
**「AIアプリケーションのためのUSB-Cポート」**です。
USB-Cが登場する以前、周辺機器ごとに異なる端子やドライバに悩まされていました。しかしUSB-Cという共通規格によって、
-
どのメーカーの機器でも
-
同じポートに挿せば
-
だいたい動く
という世界が実現しました。
MCPが目指しているのは、まさにこれです。
-
AIアプリ（MCPホスト）
-
AIエージェント（MCPクライアント）
-
データベース、SaaS、社内ツール（MCPサーバー）
これらを 共通プロトコル で接続することで、
「このAIはどのサービスにどう接続できるのか？」という個別実装の地獄から開発者を解放します。
APIが「点と点をつなぐ」仕組みだとすれば、
MCPは「AI連携のための土台（インフラ）」と言えるでしょう。
2. AIが自分で学ぶ仕組み ― 動的ディスカバリーという発想
MCPの本質的な革新は、**動的ディスカバリー（Dynamic Discovery）**にあります。
MCPでは、AIエージェントがサーバーに接続した際に、
「あなたは、どんなことができますか？」
と問い合わせることができます。
するとサーバーは、
-
利用可能なツール一覧
-
アクセスできるリソース
-
使えるプロンプトテンプレート
を 機械可読な形で返します。
ここが、従来のAPIとの決定的な違いです。
REST APIでは、
-
新しいエンドポイントが増えたら
-
OpenAPIを更新して
-
クライアントコードを書き直して
-
再デプロイする
という流れが不可避でした。
一方MCPでは、
AIが実行時に「最新の能力」を自分で把握します。
つまり、
-
サーバー側が機能追加
-
クライアントは無改修
-
AIが自律的に新機能を利用
という世界が成立します。
これは単なる便利機能ではなく、
「AIは固定ロジックではなく、適応する存在である」
という思想の転換を意味しています。
3. MCPはAPIを置き換えない。むしろ"活かす"
MCPの話をすると、よくこんな疑問が出ます。
「じゃあAPIはいらなくなるの？」
答えは NO です。
実際、多くのMCPサーバーは、内部で既存のREST APIをそのまま使っています。
MCPはAPIを捨てるのではなく、AI向けにラップするレイヤーなのです。
たとえばGitHub向けのMCPサーバーでは、
-
外部には
repository/listのようなAI向けツールを提供 -
内部ではGitHub REST APIを呼び出す
という構成になっています。
つまり、
-
API：人間とアプリのための低レイヤ
-
MCP：AIエージェントのための高レイヤ
という役割分担です。
この構造により、
一度MCPサーバーを作れば、
どのAIエージェントからでも使える
という Build once, integrate many の世界が見えてきます。
まとめ：MCPは「AI前提」で設計された最初の標準
MCPは単なる新プロトコルではありません。
それは、
-
AIが
-
自分で能力を理解し
-
自分で選択し
-
自分で実行する
ことを前提に設計された、初の本格的なAIネイティブ標準です。
重要なのは、MCPが既存のAPI資産を否定しない点です。
APIの上に立ち、AIが使いやすい形へ翻訳する――
MCPは言わば 「AIスタックのユニバーサル翻訳機」 です。
今後、AIエージェントが当たり前になるにつれ、
「どう賢いか」よりも「どうつながるか」が差別化要因になります。
そのとき、MCPはどこまで"当たり前の存在"になっているのか。
エンジニアとして、今のうちに理解しておく価値は十分にあるでしょう。