- Model Context Protocol（MCP） は、AnthropicがLLMと外部アプリ・システムを接続するために作った仕様で、OpenAIがChatGPTでサポートした後、複数のプラットフォームの共通インターフェースのように広がった
- 仕様が緩く不完全でも、複数の参加者が素早く同じ方式を採用すれば、実際のウェブでは オープンプロトコル が力を持ちうる
- Web 2.0の本来の価値は、閉鎖的なソーシャルサイトよりも、オープンAPI と相互運用可能なツールが作る開発者・ユーザーのエコシステムに近かった
- FacebookやTwitterのような大規模プラットフォームがAPIを閉じたことで弱まった相互運用性への期待を、MCPがAIコーディングツールの流れの中で再び プログラム可能なプラットフォーム としてよみがえらせる可能性がある
- MCPは万能な解決策ではなく、データ処理の不透明さや セキュリティリスク も大きいが、標準準拠と透明性を求める新たなきっかけになりうる
MCPが標準のように広がった背景
- Model Context Protocol、つまり MCP はAnthropicがClaudeのために設計した仕様である
- LLMが複数のアプリに情報を要求したり、他のシステムと相互作用できるようにすることを目的としている
- OpenAIが数か月前にChatGPTで同じプロトコルをサポートしたことで、MCPは各所で採用される標準のような存在になった
- WindowsにもMCPが含まれ、その拡大範囲を示している
- 重要なのは仕様の完成度より、複数のプレイヤーが同じインターフェースを素早く採用したという事実である
- MCPは緩い仕様に近いが、開かれていて動くという点 でウェブの成功のしかたに似ている
Web 2.0が本来指していたもの
- Web 2.0はFacebookのような閉鎖的で独占的なサイトを意味する言葉ではない
- 初期のWeb 2.0コミュニティの中心には、複数のサイトが オープンAPI を提供し、開発者とユーザーが人やデータをつなげられるようにする流れがあった
- Flickr、Del.icio.us、Upcomingは、タグやソーシャル共有のような機能を切り開いた時代を代表するサイトだった
- LiveJournalやMovable Typeのようなプラットフォームも、APIとプロトコルをめぐるオープン標準の取り組みに影響を与えた
- 当時共有されていた価値観は比較的明確だった
- ツール、技術、プラットフォームを オープンデータ とオープンプロトコルの上に構築する
- ユーザーがコントロール権を持つ
- 開発者が一貫性があり相互運用可能なツールでシステムと相互作用する
閉鎖型プラットフォームが断ち切った相互運用性
- 一世代のあいだ、開発者がアプリとプラットフォームの間の相互運用性を当然のものとして期待することが難しくなった
- 大手VCやテック業界のリーダーたちが開放性の時代を終わらせたという批判も付きまとった
- ソーシャルネットワークの活動を分析するツールは、大手ソーシャルネットワークプラットフォームがAPIを閉じたことで、製品やユーザー向けサービスが停止する事例を経験した
- FacebookやTwitterのようなプラットフォームは、多くの人にとって オープンデータ と相互運用可能な技術というWeb 2.0の期待を打ち砕いた
- その結果、ユーザーが自分のネットワークを望む形で扱いにくい状況が日常化した
- Twitterのタイムラインで埋め込みInstagram写真を見ることができない
- fediverseやBlueskyで可能な、フォロワーのインポート・エクスポートのような機能を使いにくい
- 自分の望むアプリで自分のネットワークを制御しにくい
MCPが再び開ける可能性
- MCPの台頭は、AIがコーダーのあいだで人気を集める流れと重なり、プラットフォームがLLMだけでなく 多様なプログラミング目的 にも開かれうるという期待を生んでいる
- Anthropicが作った仕様を他のプラットフォームがそのまま採用した点が重要である
- 他社のプロトコルを忠実に二番手として採用すれば、エコシステム全体が同じやり方でより簡単に動けるようになる
- 逆に、プロトコルをコピーして拡張し、最終的に消してしまうようなやり方はエコシステムを傷つけうる
- 同じインターフェースを使おうという善意の採用があるとき、複数のツールやプラットフォームが連携して動く余地は大きくなる
標準をそのまま守ることの難しさ
- 標準をそのままサポートすることは見た目以上に難しい
- AIプラットフォーム向けの セマンティックキャッシュ製品 をリリースしたときも、開発者に一般的なChatGPT APIをそのまま使ってもらうよう説得するのは簡単ではなかった
- 開発者は「もっと良くできる」と考えがちだが、標準から外れた瞬間にかえって悪くなることがある
- 不一致の多い悪い仕様であっても、全員が同じやり方で実装するほうが重要な場合がある
- HTMLも多くのものが欠けた不完全な仕様だったが、ウェブはその上に築かれた
- インターネット全体も複数の不完全な仕様の上に成り立っている
標準準拠と透明性への要求
- 新しい世代の開発者は、好きなツールやプラットフォームが同じプロトコルや形式を使うときに生まれる創造性と可能性を体験している
- RSS、ポッドキャスティング、OpenID、OAuth、OpenSocialのような流れの一部は、のちにfediverseやActivityPubのような成果へとつながった
- 開発者、コーダー、技術愛好家、一般ユーザーも、プラットフォーム上でコードによって体験を制御するためのアクセス権を要求できる
- MCPのようなオープン標準でアクセスするときには、プラットフォームが実際に何をしているのかについての 透明性 も同時に求めるべきである
- MCPは柔軟だが、多くのリスクを残している
- プラットフォームがユーザーデータをどう扱っているのか不透明である
- MCPを通じた相互作用でどのような動作が起こるのか分かりにくい
- セキュリティリスクが非常に大きい
- プロトコルはこうした懸念を十分に扱っていない
Web 2.0的な開放性の限界と期待
- MCPは開発者エコシステムのすべての問題を解決する万能策ではない
- AIをめぐる誇張や議論のゆがみを正すものでもない
- ただし、前世代のWeb 2.0期を経験していない若い開発者たちが、MCPをきっかけにウェブを本来のアーキテクチャに近い姿へ戻そうとする可能性はある
- ウェブは独占的であったり、少数の大企業の数人に制御される構造として意図されたものではない
- ウェブは、みなが急いで採用した粗削りな仕様を通じてプログラム可能であるべきものであり、そのハック可能な楽しさはウェブにバージョン番号が付く前から存在していた
1件のコメント
Hacker News のコメント
MCP について多くの人が見落としているのは、これがエンタープライズソフトウェアにうまく合うという点だと思う
LLM は汎用翻訳機なので、間にある程度ゆるい層がなければ接続が極めて難しい、分断されたシステム同士をつなぎ合わせる接着剤に向いている
だから B2B SaaS 業界が MCP サーバーを出していて、内部では変化した利用パターンに合わせて API とその制限をどう再設計するかを議論しているのだと思う
このプロトコルは多くの定義で「エンタープライズ対応」とは言えないが、筆者が言うように、それはそれほど重要ではない。標準の歴史を見ると、雑で「悪い」ものでも、適切なタイミングで適切な人々に刺されば広く採用される
ユーザーオブジェクトのフィールドを変えるのが、元のユーザーオブジェクトを置き換える PUT なのか POST なのか、といった議論が減る。REST の動詞をめぐってかなり多くの時間を費やしたことがある
LLM も API の REST セマンティクスを理解する必要がない。利用可能な RPC メソッドを見て、できそうな呼び出しをすればよい。要点は本当にその程度だと思う
エンドポイント同士が今後安く問い合わせられるスキーマを交渉するような仕組みでもない
それだけでも自己発見のような機能は可能だ
MCP を提供するようなところなら、どうせまともな API も提供するはずだ
勤務時間中に従業員から最大限の生産性を引き出したいと思わない会社があるだろうか
「昔は気難しい年配の Unix おじさんたちが仕様を書いていた時代と比べると」という部分は、セマンティック Web が失敗した複数の理由の一つだと思う。筆者の「悪いほうがよい」という趣旨とも矛盾しない
人々は XML の eXtensible にのめり込みすぎ、ある程度の疲労感がたまったのだと思う。XSL、XHTML、XSD、WSDL、XSLT、RDF、RSS などが多すぎた
当時の世界に必要だったのは単純な交換形式で、JSON はその要求に合っていたが、XML 側はデータ形式に対するアーキテクチャ上の宇宙飛行に近かった
しかし今こそ XML の時代が来たとも信じている。Anthropic のようなところの流出したシステムプロンプトでは XML がよく見られる。LLM は構造化テキスト形式、特に Markdown と XML をかなりうまく扱うようだ
ただし MCP は間違ったモデルだと思う。モデルに直接コンテキストを「取りに行かせる」よう指示するより、私たちがモデルへコンテキストを「押し込む」べきだと思う
4つのマクロタグ（
#=、#&、#?、#!）がそれぞれ代入、置換、condのような条件分岐、ユーザー定義関数呼び出しとして、自分自身をマクロ展開結果に置き換える仕組みだったが、結局 XSLT を作り直しているのだと気づいた本当に欲しかったのは XPath だった。グラフを複数の軸に沿って前後にたどる方法を記述するやり方で、実際によくできた仕様だ
その後、任意の XML 文書を問い合わせ可能なデータベースとして取り込み、XPath や XQuery で問い合わせられる BaseX https://basex.org/ を見つけた
ハルシネーションのない信頼できる自然言語データセットインターフェースを作るなら、XML スキーマをシステムプロンプトに渡し、モデルにデータを取得するクエリを書かせる方式がいちばんよさそうだ
事前に情報を知っているなら、おそらく自分で問題を解いていただろう
MCP から得られる価値は、「15個のソースをつなぎ合わせる方法を覚えさせるのではなく、自分の代わりにどのクエリを実行すべきか判断して実行してくれ」に近いように見える
誰も™ XML 宣言で始まる正しい XML を LLM に食わせておらず、名前空間や XSLT、XML Schema のようなものも使っていない
ただ SGML 風のタグを任意に寄せ集めたものに近い
XML は山括弧以上の大きな仕様であり、あらゆるケースを網羅し、セキュリティと文字エンコーディングをきちんと扱おうとする
そのため「プレーンテキスト編集」はかなり直感的ではない。この段落のようなものを入力すると、互換モードではパースできるかもしれないが、有効ではないかもしれない
交換形式や、それに合わせて作られたアプリケーションに読み込まれる形式としては可能性がよりあり、LLM も間違いなく理解に苦労しないだろうから、それは良いことだ
過去の多くの問題は、時間が足りず機能を早くねじ込みたいプログラマーたちが、強く構造化された仕様を鈍器のように振り回したことから来ていた。「XML？正規表現で書けばいいだろう」を別々のプログラム3つと作者3人が繰り返せば、大混乱になる
個人的に欲しかったものに実際近い形式は BBCode だった。多くのものの元形式として優れている。基本的にはやはり山括弧系だが、汎用フロントエンド構文として使うのにちょうどよい構造と柔軟性を備えている
初期実装は「正規表現で書けばいいだろう」だったが、数十年の実戦検証を経て、今ではより洗練されたパーサーもある
「MCPの台頭は、AIがコーダーの間で人気を得るにつれて、LLMが制御するためだけでなく、どんな目的にもプログラム可能なように他のプラットフォームを開放できるという希望を与える」という文とは逆に考えている
MCPはセマンティックWebが失敗したのとまったく同じ理由で失敗する運命にある。何かがロックされていなければ、誰も金を稼げないからだ
AIが私たちの代わりにWebを検索すること、すまないが「deep-research」と呼ばれている機能のうち、どれだけの部分がもっと良い方法で解決できたのか気になる
レストランがメニューをメタデータ形式で公開し、誰でもPythonスクリプトでテキサスで一番安いタコスを探せたはずなのに、現実には片手でデータを人工的な壁の向こうに閉じ込め、もう片手ではそれを迂回しようとしてデータセンター込みのAIを作っている。マクロに見ると、ただ愚かなことだ
以前のエージェントの波が死んだ理由は、結局のところ、誰もが交渉相手であるマシン上で実行される自分のコードを信頼できないと気づいたからだ。90年代のJava方面の話だった
根本的に、相互作用するエージェントの間には意図的に設計された情報の非対称性の問題がある。それを取り除けば、社会の大きな部分が機能しなくなるだろう
どれだけ多くのリソースを問題に投入しても、誰かがごく小さな利益のためにそれを枯渇させる方法を見つけ出すだろう
MCPは、AIエージェントが公開MCPサーバーへイナゴの群れのように押し寄せることで、問題をさらに悪化させるだけだ
安定した選択肢は、呼び出しごとの課金RPC価格設定になりそうだ。少なくともモデルやエージェントを運用する主体が決済クリアリングハウスの役割を果たすはずなので、Web 2.0 APIの頃よりは可能性がある
おそらく最もあり得る課金方式は、こうした費用をサブスクリプションプランに含めることだろう。それがインセンティブを合わせる最善策に見える
そもそもHATEOASという名前を付けた人が、失敗するように場を整えていたようなものだ
データを標準形式で公開することに「簡単な」価値があったなら、相互運用可能なエンドポイントはもっと広く採用されていたはずだ
たとえばschema.orgや一般的な共通オントロジーを使う方法のことだ。しかし現実には、毎回特別な魔法のSDKが必要なカスタム形式が多い
レストランにメニューをメタデータ形式で公開しろと求める側こそが人工的な壁だ
新しい自然言語処理ツールの美しさはここにある。レストランのオーナーがJSONを学んだり、JSONを生成するソフトウェアパッケージを買ったりする必要がない
私たちはデータをそのまま使える。有用なツールを作るコストはほぼ0に近づく
不正確ではあるだろうが、そもそも人間の言語はそういうものだ
MCPがあれば何にでもアクセスできると思っている人たちは気の毒に見える
そうしたものは、決済検証と認証レイヤーの何十もの層の背後に隠れるだろう。もちろん許可リストIPも付くだろうし、当然IPv4だろう
あなたたちに見えるのは
ERR 402;だけになりそうだMCPで最も心配なのは、プロトコルの出来がひどいことよりも、それを直して改善する仕事がAnthropicとOpenAIの内部チームだけに依存していることだ
プロトコルを作っている人たちは、実際に実装もしてみるエンジニアのようには見えない
ぼんやりとVisa-Mastercardの寡占のように感じる
https://techcrunch.com/2025/05/19/github-microsoft-embrace-a...
いまやLLMがAPIドキュメントを読んで適応できるなら、標準APIに従う必要性は以前より低くなったのではないか
私にとって重要な利点は、サイトがMCP仕様に従っているかどうかにかかわらず、APIを「持っている」という期待が生まれることだ
ドキュメントが良くても、LLMがAPIとやり取りする誤ったコードを生成することがある。生成されたコードを修正し、LLMにそのコードを呼び出させてAPIとやり取りさせるなら、結局は中間層へ向かう道に入っていることになる。実質的には「MCPのような」サーバーを作っているわけだ
LLMにAPIへの直接アクセスを与える場合、セキュリティやリソース割り当ての問題もある。LLMはAPIが最後にいつ呼び出されたかについての知識が限られている。頻繁に呼び出しすぎる可能性があり、呼び出しあたりのコストが高ければ、予想外のインフラ請求が発生する
ほかにも、間に何かを置けば解決できる潜在的な痛点は多い
その「何か」がMCPであるべきかどうかについては、合理的な人々の間でも見方が分かれる。今のところは、人々がやるべきことを処理するには十分うまく機能しているようだ
これでセマンティックWebを作れる。組織がSQLの
CREATE TABLEDDLをMCPアプリが読める静的ファイルとして共有する小さなプロトコルを作るだけでよい。MCPの任意拡張で十分だそうすれば、AI/LLMの関数呼び出しをSQLにつなぐ既存のツールを使ってデータを理解しクエリできるので、それがセマンティックWebになる
この方式は、セマンティックWebを常に阻んできた欠けたリンクを埋める。企業に独自データ型ではなく標準の「データ型」を使わせるインセンティブがなかったという問題だ
MCPQ、つまりクエリを含むMCPができれば、組織がデータ構造レイヤーで協力する理由が突然生まれる
結局のところ「セマンティックWeb」はずっと構文Webだったのであり、もしかすると今回は本物かもしれない
誰かがゴキブリみたいなものを制御する MCP サーバーを作るまで、どれくらいかかるのか気になる
参考資料:
https://www.technologynetworks.com/informatics/news/robo-roa...
https://www.sciencealert.com/scientists-turned-cockroaches-i...
それに、10年以上前にさかのぼる別の例もたくさんある
「仕様を気難しい年老いた Unix おじさんたちが書いていた時代」という表現がかなり笑える
この世代が「年老いた Unix おじさんたち」を気難しい人たちとして想像しているのが面白い。Unix は MIT 学派に対抗する究極の 素早く動いて壊す 反乱だったのに、という話
変わらないものもあるみたいだ :-)