なぜAPIだけでは生成AIに足りないのか
API はプログラム同士の約束としては完成形です。ただし使う側が生成AIになると、どの窓口をどう使うかを人が説明文で教え込み、つなぐ相手ごとに接続を作り込む手間が残ります。この隙間を埋める共通規格が MCP です。
各ブロックや矢印をクリックすると、その仕組みの説明がここに表示されます。
MCPはAPIを置き換えない — 上に載って生成AI向けに通訳する
この図をテキストで読む
構成図「MCPはどこに置かれるか（階層で見る）」。ブロック4個、つながり3本。 【ブロック】 - 生成AI（頭脳）: Claude・ChatGPT・Gemini など / 道具を選び、使い方を判断する - MCP（道具の通訳）: 生成AIと道具をつなぐ共通規格 / 何ができるかを生成AIへ自動で伝える - API（サービスの窓口）: いままでどおりの接続規格 / 実際の処理はこれまで通りここを通る - サービス本体: メール・予定表・業務システム / データと機能の持ち主 【図の符号】青の枠=人・利用者 / 緑の枠=関門・経由点 / 赤紫の枠=データの置き場 【流れ】 - 依頼が実行に変わるまで: 生成AI（頭脳） → MCP（道具の通訳） → API（サービスの窓口） → サービス本体
つないだ瞬間に何が起きるか
各ステップ・参加者・分岐をクリックすると、その仕組みの説明がここに表示されます。
この図をテキストで読む
シーケンス図「MCP接続の流れ（自己紹介 → 道具を使う）」。参加者3人、ステップ6個。 【参加者】（左から右） - 生成AI: 道具を使う頭脳 - MCPサーバー: サービスの手前に立つ通訳 - 既存のサービス（API）: 実処理はここ 【流れ】（上から下へ） ── ① つないだ瞬間 ── 道具の一覧が自動で伝わる（自己紹介） ── 1. 生成AI → MCPサーバー: 接続して「何ができますか?」と尋ねる 2. MCPサーバー → 生成AI: 道具の一覧＋使い方（入力と出力の形）を返す（応答） ── ② あとは生成AIが道具を選んで使う ── 3. 生成AI → MCPサーバー: 「あす15時に打ち合わせを登録して」と道具を呼ぶ 4. MCPサーバー → 既存のサービス（API）: 既存のAPIの形式に変換して取り次ぐ 5. 既存のサービス（API） → MCPサーバー: 登録完了の結果を返す（応答） 6. MCPサーバー → 生成AI: 結果を決まった形で返す（応答）
接続の作り込みはどう変わる?
各ステップ・参加者・分岐をクリックすると、その仕組みの説明がここに表示されます。
つなぐ数だけ作り込みと教え込みが増える — 変更のたびに直す
この図をテキストで読む
シーケンス図「API直結（従来のつなぎ方）」。参加者2人、ステップ3個。 【参加者】（左から右） - 開発チーム: 接続を作る人 - 生成AIアプリ: サービスごとに個別接続 【流れ】（上から下へ） 1. 開発チーム → 生成AIアプリ: サービスごとに接続プログラムを作る（×つなぐ数） 2. 開発チーム → 生成AIアプリ: どの窓口をいつ使うか、説明文で教え込む 3. 生成AIアプリ → 開発チーム: 相手の仕様変更のたびに修正が発生（応答）
普及への現在地
- 1
HTTPと同じ道筋
HTTP以前のインターネットは、接続の方法がサービスごとにバラバラでした。HTTPにそろって一気につながった歴史を、MCPは生成AIと道具の間で繰り返そうとしています。
- 2
まだ若い共通規格
MCPは2024年に公開された新しい規格です。対応サービスは急速に増えていますが、権限管理などの整備は発展途上で、仕様の進化も続いています。
道具には権限の線引きを
生成AIが道具を直接使えるということは、判断を誤ればメール送信やデータ変更も起こせるということです。使える道具を必要最小限に絞り、取り消せない操作には人の承認をはさむ——権限の設計とセットで導入します。
押さえておきたい言葉
- MCP（Model Context Protocol）
- API
- MCPサーバー
- ツール（道具）
- AIエージェント この用語の解説を読む
- プロトコル