スタンフォード大学の講義 CS146S（The Modern Software Developer）の資料を読みながら、AIと壁打ちして MCP を理解した。その過程で自分が何を勘違いしていたかを残しておく。
最初に引っかかったこと
LLM が持つ世界知識は、学習した時点で止まっている。完全に自律して動くシステムを作るなら、新しいデータをリアルタイムに渡す仕組みがいる。MCP（Model Context Protocol）は、そのための共通の作法だ。すごく雑に言うと、LLM にツールを見せるときの標準フォーマットである。
MCP がなければ、AI アプリごと、ツールごとにコネクタを書くことになる。アプリが M 個、ツールが N 個なら M×N 通りだ。MCP を挟むと、ツール側が Server を1つ、アプリ側が Client を1つ用意すれば済み、M+N に減る。認証、エラー処理、レート制限を毎回作り直さなくていいのも大きい。
登場人物は3つ
Host（ホスト）は Cursor や Claude Desktop のような、ユーザーが触るアプリ。Client はその中に組み込まれた通信用のライブラリで、MCP Server は個々のツールの前に置かれる薄いラッパーにあたる。
自分は最初、Agent と MCP Client を同じものとして考えていた。Agent 全体の中で、Server と話す部分を担当するのが Client、と分けて捉えたほうが後の話が追いやすい。
MCPのやり取りの流れ
「Jack から来たメールを要約して」と頼む場面で追ってみる。
- Client が MCP Server に「どんなツールがある？」と聞く。Server は、ツール名、用途、引数を JSON Schema（データ構造の定義）で書いた説明書を返す。これは通常、セッションの初期化時に済んでいる。
- ユーザーが Host に質問する。
- Client は、質問とツールの説明書をまとめて LLM に渡す。LLM は説明書を読み、
search_emails(from="Jack")を呼ぶと決めて、Tool Call（ツール呼び出し）を構造化データで出力する。 - Client がその Tool Call を受け取り、MCP Server に実行を依頼する。Server は裏で Gmail API を叩き、結果を返す。
- Client が結果を LLM に渡し、LLM が人間向けの文章に整えて回答する。
ここで押さえておきたいのは、LLM は「何をどんな引数で呼ぶか」を決めるだけで、自分ではネットワークに出ていかないという点だ。実際に手を動かすのは Client になる。LLM が頭脳、Client が手足と考えるとイメージしやすい。
ハマった3つの勘違い
実際に自分が間違えたところを3つ挙げる。
1つ目は、MCP Server がユーザーの依頼を見て、使うべき API を自分で探すと思っていたこと。Server は受け身のツール置き場で、判断はしない。どのツールを選び、どんな引数を渡すかを決めるのは LLM だ。
2つ目は、 tools/list を「ユーザーが入れている MCP の一覧を取る操作」だと思っていたこと。これは特定の Server に「あなたはどんなツールを持っている？」と聞く操作で、どの Server をつなぐかは Host の設定が決める。
3つ目は、ユーザーが質問する前に、Client が LLM へ Tool Call を投げているのだと思っていたこと。Tool Call を出せるのは LLM だけで、質問前に Client がやっているのは、ツール一覧を取って Prompt の材料を用意するところまでだ。
MCPとAPIは何が違うのか
| API | MCP | |
|---|---|---|
| 使う側 | 開発者、従来のプログラム | LLM、Agent |
| やり取りする中身 | データそのもの（HTTP のリクエストとレスポンス） | ツールの意味づけと、呼び出し方の標準形式 |
| 呼ぶタイミングを決めるのは | コードを書いた人 | LLM が文脈から判断する |
| 位置づけ | 一番下のサービス接続口 | LLM と下位サービスの間の中間層 |
MCP Server は多くの場合、裏で API を呼ぶ。だから MCP は「API を LLM 向けに包んだもの」と見ておけばだいたい合っている。ただ「多くの場合」であって、ローカルのファイルやデータベースを直接触る Server もあるので、必ず API が裏にあるとは言えない。
ツールが増えたときの設計
講義では、MCP Server の設計について2つの方向性が出ていた。
１. 操作ではなく結果でツールを作る
REST API をそのままツールに分解しない。たとえば送金なら、 get_users → list_account → send_payment と3つに分けて Agent に組み立てさせるより、 send_payment(user_email) を1つ用意したほうが Agent は迷わない。引数にネストした辞書を使わないこと、docstring やエラーメッセージを LLM が読む前提で書くこと、ツール名にサービス名の接頭辞をつけること、も挙がっていた。
2. 検索と実行を分ける
Server が大量に増えると、全ツールの説明書を最初から Prompt に入れるのは重すぎる。そこで LLM に見せるツールを search と execute の2つだけにする。LLM はまず search で必要なツールを探し、それから execute で実行する。講義では、これで Token が90%以上減り、Server の数にも依存しなくなると説明されていた。
違いは説明書を見せるタイミングにある。全部を最初に見せるか、薄い目次だけ見せて必要なときに中身を引くか。後者が「必要になってから読み込む」考え方だ。
SkillsはMCPの上に何を足すのか
資料では Agent Skills を、特定の領域向けに、コードと Prompt をセットにして、必要なときに読み込む標準的な能力のまとまり、と説明していた。使いどころは文書作成、PowerPoint 作成、データ分析など。
Figma で考えると分かりやすい。Figma の MCP だけあっても、Agent は create_frame のようなツールがあることを知っているだけで、Web ページ設計の作法までは知らない。位置のずれた四角形が並ぶだけの画面になりかねない。そこに figma-web-design という Skill を足す。1440px のルートフレームを作り、色や文字のルールを決め、Header、Hero、Feature Grid、Footer の順に組み、Auto Layout を有効にする、といった手順を書いておく。
自分の理解はこうなった。MCP は「そのツールを使えるか」を決め、Skills は「そのツールをうまく使えるか」を決める。
ただし、Skill が MCP に必ず依存するわけではない。Skill は自分でスクリプトを持てるので、Figma の REST API を直接呼ぶ作りもありえる。MCP は標準化されたツールの通り道、Skill は進め方の知識を担当し、組み合わせたときに一番よく働く、くらいの言い方が正確だ。
最後に、3つを並べておく。
| 何か | 誰が使うか | 主な用途 | |
|---|---|---|---|
| API | アプリが外に公開する HTTP、REST、GraphQL の接続口 | 開発者、SDK | 認証、リトライ、ページング、入力検証を開発者が自分で制御する |
| MCP | サーバー側が公開するツール定義。LLM が標準的な形式で呼ぶ | モデル、Agent の実行環境（Tool Call として） | Agent が外部のデータやサービスとやり取りする |
| Skills | 動的に読み込む再利用可能なタスクのまとまり（コードと Prompt） | Agent、Agent のフレームワーク | 文書作成、PPT 作成、データ分析などの作業手順の抽象化 |
参考
CS146S The Modern Software Developer https://themodernsoftware.dev/