MCPとは ― 道具ごとに作り直していた世界

AIに社内のファイルや業務システムを触らせたい。その繋ぎを道具ごとに書いていた時代と、差し込み口を1つに決めた後を、同じ図が動きながら比べます。MCPが決めていること・決めていないことまで。

AIは、自分の外側を見られない

言語モデルは、学習した内容と、その場で渡された文章だけを見て答えを作ります。あなたの会社の共有フォルダも、昨日の課題チケットも、社内データベースの中身も、何もしなければ見えていません。

だから「今週の障害チケットを要約して」と頼んでも、モデル単体では答えようがありません。答えさせるには、誰かがチケットを取ってきて、文章としてモデルに渡す必要があります。

この「取ってきて渡す」部分を、誰がどう書くかの話が、この教材のテーマです。

やることは単純です。ファイルを読む処理を書き、課題管理のAPIを叩く処理を書き、データベースに問い合わせる処理を書く。そして「モデルがこの道具を使いたいと言ったら、この関数を呼ぶ」という対応表を、アプリの中に作ります。

問題は、この3本がそのアプリ専用であることです。認証の渡し方も、引数の形も、エラーの返し方も、書いた人が好きに決めています。他のAIアプリからは使えません。

道具が3つなら3本です。まだ手に負えます。

AIアプリが3つに増えました。道具は同じ3つです。必要な繋ぎは 3+3 ではなく、3×3で9本になります。

これが N×M問題と呼ばれるものです。AIアプリがN個、道具がM個あるとき、素朴に書くと N×M 本の実装が要ります。道具側の仕様が変われば、それを使っている全部のアプリを直すことになります。

同じ「課題管理を読む」という仕事を、3つのアプリが3回ずつ書き直している状態です。

真ん中に、決まった形の差し込み口を1つ置きます。AIアプリ側は「この形で話す」を1回だけ実装し、道具側も「この形で応える」を1回だけ実装します。

すると必要な実装は N×M から N+M に落ちます。上の図で言えば9本が6本に。道具が10個・アプリが10個なら、100本が20本になります。増えるほど差が開くのが要点です。

この「決まった形」を文書にしたものが MCP（Model Context Protocol） です。2024年11月に Anthropic が公開し、その後も版を重ねています。この教材は 2026-07-28 版を基準に書いています。仕様の最新版

ここを取り違えないでください。MCPが決めているのは、やりとりの形です。

- 道具の一覧をどう尋ねるか
- 道具をどう呼び出すか
- 結果をどんな形で返すか
- お互いに何ができるかを、どう伝え合うか

決めていないのは、こちらです。

- どのモデルを使うか。MCPはモデルに触れません
- モデルがいつ道具を使うと判断するか。これはアプリとモデルの仕事です
- 何を道具として公開するか。サーバーを作る人が決めます

公式の説明も「MCPは文脈をやりとりするプロトコルだけを扱い、AIアプリがモデルや文脈をどう使うかには踏み込まない」と明記しています。アーキテクチャ概要

道具を作る人の変化。自分のサービスに1つMCPサーバーを用意すれば、対応済みのAIアプリすべてから使ってもらえます。アプリごとの個別対応がなくなります。

AIアプリを作る人の変化。MCPクライアントを1回実装すれば、世の中にあるMCPサーバーがそのまま候補になります。連携先を増やす作業が、コードを書く作業から設定を足す作業に変わります。

使う人の変化。今日は課題管理を、明日はカレンダーを、と繋ぎ先を差し替えられます。AIアプリを乗り換えても、繋ぎ先はそのまま持っていけます。

言い換えると、MCPの価値は新しい機能ではなく乗り換えやすさです。

答えはいいえです。モデルの能力は1ミリも変わりません。変わるのは、モデルが触れる範囲です。

MCPは配線の規格です。電源タップを増やしても家電の性能が上がらないのと同じで、繋ぎ方を揃えても推論は良くなりません。解消されるのは「昨日のチケットを知らない」という状態のほうです。

とはいえ、実際の体感はかなり変わります。手元の本当のデータを見て答えられるようになるからです。能力ではなく前提が変わる、と覚えてください。

次の章では、この差し込み口に誰と誰が立っているのかを見ます。