第13章　規格であることの意味（読み物）

📖 MCPサーバーを作って学ぶ AIに道具を持たせる入門 — はじめに・目次 ← 目次に戻る 最終章です。コードは1行も出てきません。 ここまで作ってきたものを、一段引いたところから眺め直します。手を動かす必要はありません。お茶でも飲みながら読んでください。

ここまでで、あなたは何を作ったのか

改めて振り返ると、あなたが作ったものは、驚くほど地味です。

  • フォルダの中の .md ファイルを検索する
  • 1つ読む
  • 1つ書く

それだけ。プログラムとしては、初心者向けの練習問題のようなものです。それが Claude Desktop から使えて、自作のアプリからも使えた。 特別なことは何もしていないのに、そうなりました。

この「特別なことをしていないのに繋がった」という部分が、実はこの教材でいちばん大事なところです。今日はその話をします。

規格が生まれると、何が起きるのか

歴史の中には、「つなぎ方だけを決めた」ものが、いくつかあります。中身については何も言わず、境目の形だけを決めたもの。それが起きたあと、たいてい、誰も予想していなかったことが起きています。

箱の話

1956年4月26日、アメリカで、改造されたタンカー船に58台のトレーラーの荷台が積まれ、ニュージャージー州ニューアークからテキサス州ヒューストンへ運ばれました。Malcom McLean という運送業者が仕掛けた実験です。

やったことは、「荷物を、決まった大きさの箱に入れる」、ただそれだけです。箱の中身については何も決めていません。バナナでも機械部品でも構わない。決めたのは箱の外側の寸法と、掴む場所（角の金具）だけでした。

その寸法が国際規格になったのは、実験から12年後です。1968年1月に ISO 668 が寸法と等級を定め、続く数年で識別表示（1968年）、角金具（1970年）、内寸（1970年）が順に決まっていきました。規格になるまでには時間がかかった、ということも覚えておいてください。

その結果どうなったか。港の風景が変わりました。人手で荷物を積み下ろしていた作業がクレーンの仕事になり、港湾労働の姿は大きく変わった、と言われています。そしてこれは「船の話」で終わりませんでした。同じ箱がそのままトラックに載り、鉄道の貨車に載る。船とトラックと鉄道が、初めて同じ単位で話せるようになったのです。

箱の寸法を決めた人たちが「これで世界中の工場が海外に部品を発注できるようになる」と考えていたかというと——おそらく、そこまでは考えていなかったでしょう。規格の効果は、決めた人の想像を超えたところに出ます。

差し込み口の話

もう少し身近な例。USB です。

USB 1.0 の仕様が出たのは 1996年1月15日。Compaq、DEC、IBM、Intel、Microsoft、NEC、Nortel の7社が共同で作りました。当時のパソコンの背面には、シリアルポート、パラレルポート、ゲームポート……と、用途ごとに違う形の穴が並んでいました。マウスとプリンタとジョイスティックで、それぞれ別の穴だったのです。

USB がやったのは、「穴の形を1つにする」こと。それだけです。

面白いのは、すぐには広まらなかったことです。USB 1.0 の時点では対応機器はほとんど市場に出ず、広く使われるようになったのは 1998年の USB 1.1 以降だとされています。規格は、決まった瞬間に勝つわけではありません。

そして、広まったあとに何が起きたか。USBメモリ、USB扇風機、USBカップウォーマー、USB接続の顕微鏡。「差し込み口の形を決めた7社」が想定していたはずのない製品が、大量に生まれました。彼らが決めたのは穴の形だけで、何を差すかは決めていなかったからです。

手紙と、ページの話

SMTP（メールを配送する取り決め）が RFC 821 として文書になったのは 1982年です。40年以上前の取り決めが、いまもあなたのメールを運んでいます。

HTTP もそうです。「このURLをください」「はい、これです」という、ほとんど呆れるほど単純な取り決め。それが決まったあと、その上に検索エンジンが乗り、SNSが乗り、銀行が乗り、いまあなたが読んでいるこのページが乗っています。

HTTP を作った人たちは、その上でショッピングが行われるとは決めていません。 ただ「ページの受け渡し方」を決めただけです。あとは、他人が勝手に作りました。

💡 共通しているのは、規格そのものは、たいてい退屈だということです。箱の寸法、穴の形、文字列のやりとりの順番。それ自体には何の面白みもありません。面白いものは、いつも規格の上に、他人が勝手に作ります。

N×M が N+M になることの、本当の意味

第1章で N×M問題 の話をしました。復習すると——AIが4種類、道具が5種類あったら、規格がなければ 4×5＝20回の実装が要る。規格があれば 4＋5＝9回で済む。

これは「効率の話」として説明されます。実際そうです。でも、それは半分です。

もっと大事なのは、こちらです。

N×M が N+M になると、作る人の数が変わります。

考えてみてください。あなたが今回作ったメモサーバーを、規格のない世界で作ろうとしたらどうなるか。

  • Claude 用の作り方を調べる
  • ChatGPT 用の作り方を調べる
  • Cursor 用の作り方を調べる
  • それぞれ別に書いて、それぞれ別にメンテナンスする

週末の趣味では、絶対に無理です。 そんな時間はありません。だから規格のない世界では、「AIに道具を足す人」は、それを仕事にしている会社の人だけになります。

規格があると、そこが変わります。あなたは1回だけ書けばいい。しかも書いたのは、ファイルを検索して返すだけの、ごく普通のプログラムです。それが——

  • あなたの Claude Desktop から使える
  • あなたが自作したアプリから使える
  • そして理屈の上では、あなたがまだ知らないAIからも使える

最後の行が重要です。あなたは、繋ぐ相手を全部知っている必要がない。 規格に合わせた時点で、まだ存在していない相手とも繋がる資格を持ちます。これはコンテナが「まだ建っていない港」でも降ろせるのと同じことです。

つまりN＋Mの本当の意味は、コストが減ることではなく、作る人の裾野が広がることです。趣味で書いた小さなプログラムが、産業の道具と同じ穴に刺さる。それが規格というものの、いちばん奇妙で、いちばん効く性質だと思います。

規格の、裏返しのコスト

ここまで良い話ばかりしたので、反対側も書きます。規格には確実に代償があります。

①　決まったことは、変えにくい

一度みんなが合わせてしまうと、あとから直すのが極端に難しくなります。「もっと良い形」を思いついても、すでに世界中がその形で作ってしまっている。

メールがいい例です。SMTP が決まったのは1980年代前半で、当時は「送り主を詐称する人がいる」ことがあまり想定されていませんでした。その結果、なりすましへの対策は後から外付けで足すことになりました。最初の設計に足りなかったものを、あとから貼り足していく——規格の宿命です。

MCPも例外ではありません。この教材でも、旧式の繋ぎ方（古いHTTPのやり方）が非推奨になった話が出てきました。まだ動きの速い規格なので、これからも同じことは起きるでしょう。

②　最小公倍数になる

規格は「みんなが実装できること」しか決められません。だから、どのAIでも共通してできることに収束します。

これは、あるAIだけが持っている尖った機能が、規格の枠に入りにくいということでもあります。「MCP経由だと、そのアプリ専用の連携より少しだけ不便」という場面は、これからも出てくると思います。コンセントの形が世界共通でないのと同じで、共通化には必ず取りこぼしがあります。

③　誰も責任を持たない場所ができる

これがいちばん厄介です。

規格は「境目」を決めます。境目のこちら側はホストを作る会社の責任。あちら側はサーバーを作った人の責任。では、そのあいだは？

たとえば——あなたが作った write_note が、ホストの判断でユーザーの確認なしに呼ばれて、大事なファイルを上書きしたとします。誰の責任でしょうか。

  • 確認なしで呼んだホストが悪い？
  • 確認を自分で入れなかったサーバーが悪い？
  • そういう危ない道具を無条件に繋いだユーザーが悪い？

規格は、この問いに答えません。 「こういう形式でやりとりしましょう」としか言っていないからです。境目を決めるということは、境目の両側に、押し付け合える隙間を作ることでもあります。

第9章で「書ける道具は、危ない道具」という話をしました。あれは、この隙間の話でもありました。誰も責任を持ってくれない場所があるから、自分のサーバーには自分で確認を入れる——そういう理屈です。

避けて通れない話：誰でも作れる、ということは

ここからは、この章でいちばん真剣に読んでほしいところです。

良い性質は、そのまま悪い性質でもある

さっき「規格があると、作る人の裾野が広がる」と書きました。素晴らしいことです。そして——まったく同じ理由で、悪意のある人の裾野も広がります。

  • 誰でも作れる ＝ 誰でも作れる
  • どのAIにも繋がる ＝ どのAIにも繋がる

この2行は、良い話として読むこともできるし、悪い話として読むこともできます。同じ性質です。 規格は道具の中身を検査しません。形さえ合っていれば繋がります。コンテナが箱の中身を問わないのと、まったく同じです。

ローカルサーバーは、あなたと同じ権限で動く

具体的に何が怖いのか。MCPの公式仕様には、セキュリティのベストプラクティスをまとめた文書があり、そこには「ローカルMCPサーバーの侵害」という項目が立っています。書かれていることを、かみ砕くと——

  • ローカルのMCPサーバーは、あなたのパソコンでプログラムを実行します
  • しかも、それを繋いだアプリと同じ権限で動きます
  • 設定ファイルに書かれた起動コマンドが、そもそも悪意のあるコマンドである可能性がある
  • サーバーの中身自体に、悪意のある処理が仕込まれている可能性がある

仕様書には、悪意ある起動コマンドの例として、秘密鍵ファイルを外部に送信するようなコマンドが挙げられています。設定ファイルの1行に、そういうものが混ざっていても、あなたには見えません。

思い出してください。あなたが第2章で書いた設定は、こういう形でした。

「このコマンドを、この引数で起動してください」

それは、あなたのパソコンで任意のプログラムを実行する指示です。MCPサーバーの設定を1つ足すというのは、技術的には「知らないプログラムを1つインストールする」のと、ほぼ同じ重さの行為なのです。

「便利ですよ」と配られたものを、無条件に繋いでいいのか

いま、MCPサーバーは大量に公開されています。GitHub で見つかりますし、「これ便利です」と紹介する記事もたくさんあります。実際、便利なものがほとんどでしょう。

でも、繋ぐ前に、これだけは考えてほしいのです。

問い なぜ効くか
誰が書いたか分かるか 素性が分かるものと、分からないものは違う
中のコードを読めるか 読めないものは、判断のしようがない
何にアクセスできる設定になっているか env で渡しているフォルダは狭いか
書き込み・削除・コマンド実行の道具があるか 読むだけの道具より、はるかに危ない
繋いだあと、AIが勝手に呼べるのは何か ツールはモデルが判断して呼ぶものだった（第1章の表）

最後の行が、実は一番効きます。ツールは、あなたが押すボタンではありません。AIが自分で判断して呼びます。 つまり「危ないツールは、自分が使わなければ安全」ではないのです。繋いだ時点で、呼ばれる可能性が生まれます。

そして、AIが道具を呼ぶかどうかを決めるのは——説明文でした。この教材の通奏低音です。説明文は、道具を作った人が自由に書けます。 親切な説明を書くこともできるし、AIを誘導するような説明を書くこともできる。

⚠️ 第9章では「自分のサーバーを、自分のために安全に作る」話をしました。この章の視点だと、それはエコシステム全体の問題になります。あなたが第9章でやった封じ込め（NOTES_DIR の外に出さない）を、他人のサーバーがやってくれている保証はどこにもありません。

だから、どうすればいいのか

大げさな話にはしません。現実的な線でいうと、こうなります。

  1. 繋ぐ数を絞る。使っていないサーバーは設定から外す。第12章でも、道具が多すぎるとAIが選べなくなる話をしました。安全と性能で、理由が一致します
  2. 中を読む。この教材を終えたあなたは、他人のMCPサーバーのコードを読めます。読めるようになったことが、そのまま防御になります
  3. env で渡す範囲を狭くする。フォルダを丸ごと渡さない
  4. 書き込み系の道具には慎重になる。読むだけの道具とは、リスクの桁が違います
  5. ホスト側の確認ダイアログを、面倒がって全部「常に許可」にしない

規格の設計者たちも、この問題を分かっています。仕様側では、ワンクリックでローカルサーバーを追加できるクライアントは実行前に明確な同意を取らなければならない（MUST）とされ、実行されるコマンドを省略せずに表示することなどが求められています。サンドボックス（隔離環境）で動かすことも推奨されています。

とはいえ——最後にそのダイアログを読んで「はい」を押すのは、あなたです。 規格は、そこまでは面倒を見てくれません。

これから、どうなりそうか

ここは正直に書きます。私にも分かりません。 なので、断定はしません。「こう言われています」という温度で並べます。

  • 標準の勝敗はまだ決まっていない、と言われています。 MCPは主要なAIアプリや開発ツールに広く採用されていますが、規格が長生きするかどうかは、採用の広さだけでは決まりません。USBが広まるのに2年かかったことを思い出してください。逆に、広まったあとで別の規格に置き換わった例も、技術の歴史にはたくさんあります
  • サーバーを「探す・選ぶ」ところが問題になる、と言われています。 数が増えれば、どれを信頼するかという話が必ず出てきます。アプリストアの審査のようなものが要るのか、それとも別の形になるのか——ここはまだ誰も答えを持っていないように見えます
  • 安全側の作り込みが増えるかもしれません。 隔離して動かす、権限を細かく刻む、といった話は、仕様の文書にもすでに現れています。ただし、そういう仕組みが実際にどこまで普及するかは別の問題です
  • 「AIが道具を選ぶ」こと自体が、設計対象になるかもしれません。 第12章でやった「道具が多すぎて選べない」問題は、たぶん本質的で、道具を増やす限りついて回ります

そして、いちばん正直なところ。

この章に書いたことの一部は、数年後には古くなっているでしょう。 MCPという名前が残っているかどうかも分かりません。それでいいと思っています。理由は、次の節に書きます。

締め：あなたが手に入れたもの

最後に。

この教材を終えたあなたが手に入れたのは、「MCPの知識」ではありません。

MCPは規格です。規格は変わります。関数の名前は変わるでしょうし、繋ぎ方が増えたり減ったりもするでしょう。この教材のコードが、そのままでは動かなくなる日も、たぶん来ます。

では、残るものは何か。

AIに能力を足すとは、どういうことか。

あなたはそれを、手で触って理解しました。具体的には、こういうことです。

  • AIの能力は、後から外付けできる。 モデルを賢くしなくても、道具を渡せば、できることが増える
  • AIが知っているのは、あなたが書いた説明文だけ。 コードは読まれない。だから説明の設計が、機能の設計である
  • 道具ができないことは、AIにもできない。 第2章の「東京の天気」がそうでした。AIの限界は、しばしば道具の限界です
  • 見えない通信は、覗ける。 ログがあり、Inspector があり、切り分けの手順がある。「動かない」は、神秘ではなく手順の問題です
  • 書ける道具は、危ない道具。 能力を足すことは、必ず危険を足すことでもある
  • 境目を決めると、境目の両側に責任の隙間ができる。 その隙間は、自分で埋めるしかない

これは全部、MCPという名前がなくなっても成り立つ話です。次にどんな規格が出てきても、あなたが最初に見るところは同じでしょう。「どうやって道具を登録するのか」「AIには何が見えているのか」「どこまで壊せる権限を渡しているのか」。

規格を覚えたのではなく、規格の読み方を覚えた。それが持ち帰りです。

そして、もう1つ。

あなたが週末に作った、ファイルを検索するだけの小さなプログラム。あれは、産業の道具と同じ穴に刺さります。 それが規格というものの、地味で、退屈で、そして少しだけ愉快なところだと思います。

お疲れさまでした。

ここから先へ

この教材はここで終わりですが、行き先はいくつかあります。短く挙げておきます。

  • 実在のMCPサーバーのコードを読む。 いちばん効きます。有名なサーバーを1つ選んで、registerTool の並びと、各ツールの説明文だけを追ってみてください。「この説明文だと、AIはこう呼ぶだろうな」が読めるようになっているはずです。ついでに、第9章の目で「ここが危ない／ここが親切」も見えます
  • 公式ドキュメントを読む。 modelcontextprotocol.io が本家です。とくに仕様のセキュリティのページは、この章で触れた話が詳しく載っています。MCPは動きが速いので、迷ったら必ず一次情報に戻ってください
  • 自分のサーバーを、自分の困りごとに合わせて育てる。 メモ以外でも構いません。あなたが毎日開いているものは、たいてい道具にできます
  • 前の3作に戻る。 未読のものがあれば、この教材のあとに読むと見え方が変わります。第1弾はデータの持ち主、第2弾は記憶と守り、第3弾はループと安全が背骨です。とくに第3弾の第3章（道具を持たせる基礎）は、今なら別の意味に読めるはずです
  • 付録に寄る。 Python で書き直したい人は 付録A　Python版で同じものを作る、Claude Code に繋ぎたい人は 付録B　Claude Code に繋ぐ、設定でつまずいたら 付録C　設定ファイルの場所とトラブル、エラー文言から引きたいときは 付録D　よくあるエラー集 へ

関連ページ