ハクソク

世界を動かす技術を、日本語で。

MCPはWeb 2.0の到来です

367日前原文(anildash.com)

概要

  • Model Context Protocol（MCP）は、LLMがアプリやシステムと連携するための仕様であり、急速に普及中。
  • MCPの仕様自体は曖昧だが、主要プレイヤーが採用したことで事実上の標準に。
  • Web 2.0時代の「オープンなプロトコルとデータ」の精神が再び注目されている。
  • MCPの普及が、プラットフォーム間の相互運用性や開放性の復活を促進。
  • セキュリティや透明性の課題も残るが、新世代の開発者が変革を牽引する可能性がある。

MCP（Model Context Protocol）とWeb 2.0の再来

  • Model Context Protocol（MCP）はAnthropicによって設計され、LLMがアプリやシステムと情報をやりとりするための仕様であることを確認。
  • OpenAIがChatGPTでMCPをサポートしたことで、MCPは業界標準として急速に普及することを実現。
  • Windowsのような大手プラットフォームにもMCPが採用されている現状を紹介。
  • MCPの仕様自体は曖昧で厳密さに欠けるが、オープンである点が重要であることを強調。
  • 緩やかな仕様でも、広範な採用と相互運用性が技術エコシステムの成長を促すことを示唆。

Web 2.0時代の精神とMCPの関係

  • Web 2.0本来の意味は「オープンなAPIとプロトコルを通じて、開発者やユーザーが自由にデータや機能を連携できること」にあることを明示。
  • FacebookのようなクローズドなプラットフォームはWeb 2.0の精神を損なった存在であると指摘。
  • Flickr、Del.icio.us、Upcomingなどが、タグやソーシャルシェアリングといったオープンな仕組みを先駆けて導入した歴史を紹介。
  • 開発者同士が競合でありながら、相互運用性を確保するために仕様策定やドキュメント作成、議論を重ねてきた経緯を説明。
  • MCPの普及はWeb 2.0時代の「オープンな連携」の価値観を現代に再びもたらす動きであることを示唆。

オープン性の喪失と復活への期待

  • 過去10年以上にわたり、主要プラットフォームがAPIを閉鎖し、オープンデータや相互運用性が失われた経緯を説明。
  • 例えば、SNSのAPI閉鎖によりサードパーティサービスやユーザーの自由が制限された実例を挙げることを提案。
  • MCPの普及によって、AIのプログラマビリティだけでなく、他のプラットフォームも再び開放される可能性があることを期待。
  • 技術プラットフォームが他社の仕様を「忠実に」採用することは、業界全体の健全な発展につながるという提案。
  • 「独自拡張」ではなく、標準仕様に準拠することの重要性を強調することを推奨。

標準仕様への準拠の意義

  • 開発者は「より良くしよう」として独自拡張を加えがちだが、標準仕様への準拠が相互運用性とエコシステム拡大につながることを指摘。
  • HTMLなど過去の「不完全な仕様」も、広範な採用によってインターネットの発展を支えた歴史を再確認。
  • Jon Postelの「寛容さと厳格さ」の精神を例に、仕様準拠の重要性を再評価することを提案。

透明性・セキュリティ課題と今後の展望

  • MCPのようなオープンプロトコルが普及することで、開発者やユーザーが自分の体験を制御できる力を取り戻すことが可能であることを強調。
  • しかし、MCPはデータの扱いや動作の透明性・セキュリティに関しては十分な配慮がなされていない現状を指摘。
  • プラットフォームがユーザーデータをどのように扱うか、オープンスタンダードを通じた透明性の確保を推進することを提案。
  • セキュリティリスクが顕在化するまでは、仕様の改善が進みにくいという歴史的背景を説明。
  • 新しい世代の開発者が、Webの本来の「オープンでプログラム可能な」アーキテクチャへの回帰を推進する可能性に期待することを提案。

結論：MCPがもたらす未来への提案

  • MCPは万能薬ではないが、Web 2.0的な開放性と相互運用性の再興を促すきっかけとなり得ることを認識。
  • 技術やインターネットはごく一部の巨大企業の独占物ではなく、開発者やユーザー自身の手に力を取り戻すためのものだという自覚を促す。
  • 今後は、MCPのようなオープンプロトコルを通じて、ユーザーや開発者が体験を自分で制御・拡張できる環境を推進することを提案。
  • 透明性やセキュリティ課題の解決も含め、より良いテクノロジーエコシステムの構築を目指すことを推奨。
  • Webは本来、「みんなで楽しむための、急ごしらえの仕様にみんなが乗っかる」場であったことを再認識することを提案。

Hackerたちの意見

結局、「セマンティックウェブ」はずっと構文的なウェブだったってことか、これが本物なのかな？

「MCPの台頭は、コーダーの間でAIの人気が高まることで、他のプラットフォームもプログラム可能になることを期待させる。ただし、LLMがそれらを制御できるためだけではない。」逆だと思う、MCPはセマンティックウェブが失敗したのと同じ理由で失敗する運命にある。物事がロックされていないと誰もお金を稼げないから。AIが私たちのためにウェブを検索する機能（ごめん、「深いリサーチ」をすることね）が、もっと良い方法で解決できたのではないかと考えさせられる。レストランがメニューをメタデータ形式で公開して、誰でもテキサスで一番安いタコスを見つけるためのPythonスクリプトを書けるようにしてもよかったのに、左手はデータを人工的な障壁の背後にロックし、右手はそれを回避するためにAI（データセンターも含めて）を構築する。マクロ的には単純に愚かだよ。

└

逆だと思う、MCPはセマンティックウェブが失敗したのと同じ理由で失敗する運命にある。物事がロックされていないと誰もお金を稼げないから。これが正しいと思う。MCPは進化したrobots.txtみたいなもので、でもまだまだ「私たちが利用するためにリソースを説明して」って感じ。前のエージェントの波が消えた理由（90年代のJavaのやつ）は、結局みんなが自分のコードを信頼できなくなったから。根本的に、相互作用するエージェント間には情報の非対称性の問題があって、これは完全に設計によるもの。これを取り除くと、社会の大部分が機能しなくなるだろうね。

└

MCPの人気は、今AIを駆動しているハイプバブルの副産物だと思う - AIでできる派手なことの一つ。もしデータを標準形式で公開することに「簡単な」価値があったら、相互運用可能なエンドポイントの採用がもっと進んでいたはず（例えば、schema.orgを使うとか、常に特別な魔法のSDKが必要なカスタム形式ではなく）。

└

MCPは、私が見る限り、基本的にAPIのV2だと思う。具体的な仕様は進化するだろうけど、便利でニッチではない、特にそれらが比較的簡単に組み合わせられるときはね。その意味では、次のユーザーインターフェースの構成要素になると思う、会話型の。ウェブ2.0の言及がここでのすべてのネガティブな反応を引き起こしているかもしれないけど、それ自体は有用で、私たちがソフトウェアやシステムとどのように対話するかを変える可能性がある。

└

HATEOASは2010年代初頭の夢だったけど、結局はswagger yamlを生成する以上のことは何もなかった。APIの利用を簡単にすることを意図していたにもかかわらず。HATEOASと名付けた人は、基本的にそれを失敗させるために仕組んだようなものだね。

└

セマンティックウェブが失敗した理由は、「物事がロックされていないと誰もお金を稼げない」だけじゃない。全文検索やインデックス作成、適度なファジーマッチングが、より速くて信頼性が高いから、無限のメタデータを生成する時間なんて誰もない。LLMは、彼らの存在がもたらす技術的・社会的な影響が嫌いだけど、実際には後者のさらなる発展だから、消えることはない。ウェブサイトの手動または半自動のカタログ化（さらにキュレーションすること）は、「ウェブで情報を見つけるにはどうすればいいか」という答えにはならなかった — Googleがそれだった。メニューのための標準化されたメタデータ形式を持つのは間違いなくいいけど、それを使わせるのは難しい。無理だよ。誰にとっても、任意の情報レイアウトのウェブサイトをスクレイピングして、関連データを抽出するためにLLMに食わせる方が、はるかに安くて簡単だからね。「関連性」が何かは人それぞれ違うし、可能な関連メタデータの完全なリストを事前に決めることはできない。また、500項目の長いフォームを埋めさせるのも難しい。そんな時間は誰にもないよ。

└

普通の人間が読めるテキストは「人工的な障壁」じゃない。それは私たちの世界の本質だ。レストランにメニューをメタデータ形式で公開させるのは人工的な障壁だ。これが新しいNLPツールの美しさだよ。レストランのオーナーにJSONを学ばせたり、JSONを生成するソフトウェアパッケージを買わせたりする必要はない。データをそのまま使えるんだから。便利なツールを作るコストはほぼゼロに近づく。精度は欠けるかもしれないけど、それが人間の言語なんだ。

└

あんまり詳しく見てなかったけど、なんでMCPベースのAPIでお金を稼げないんだろう？なんでプロバイダーはAPIキーや支払いを要求して、自分たちの機能を呼び出させないの？

└

無料でオープンなAPIを提供してるからって、誰もお金を稼げないってわけじゃないんだよね。そういうAPIを運営するには、基本的に無限のリソースが必要になるから。どれだけリソースを投入しても、誰かがそのリソースを使い果たす方法を見つけるんだよ。MCPがあると、AIエージェントがオープンなMCPサーバーに群がってくるから、問題はさらに悪化すると思う。安定した選択肢は、コールごとのRPC料金になるんじゃないかな。少なくとも、Web 2.0のAPIよりは実現可能だと思うし、モデルやエージェントを運営してる団体がすべての支払いのクリアリングハウスとして機能するからね。（彼らの最も可能性の高い請求モデルは、これらのコストをサブスクリプションプランに組み込むことだと思う？それがインセンティブを合わせる一番いい方法に見える。）

└

確かに、「HTTP」でお金を稼いだ会社はあまりなかったけど、たくさんの人や会社がそれを採用して大儲けしたよね。

└

MCPはウェブをオープンにする手段として説明されてるけど、実際にはウェブが本当にオープンだったらできる面白いことのデモを作る手段なんだよね。

昔は仕様が細かいことを気にする古いUnixのおじさんたちによって書かれていたけど、これはセマンティックウェブが失敗した理由の一つだと思う（著者の言ってることとは矛盾しないけど、彼のポイントは「悪い方が良い」っていうマントラだし）。人々はXMLのeXtensibleな部分にすごく注力して、ある程度の疲れが出てきたと思う。XSL、XHTML、XSD、WSDL、XSLT、RDF、RSSなどはちょっと多すぎた。データフォーマットに関しては、当時必要だったのはシンプルなインターチェンジフォーマットだったのに（JSONがそれに合ってた）。でも、実際にはXMLの時代が来たと思ってる。Anthropicみたいなところから漏れたシステムプロンプトにXMLがよく出てくるのに気づいた。LLMは構造化されたテキストフォーマット（特にMarkdownやXML）でうまく機能するみたい。だけど、MCPは間違ったモデルだと思う。モデルに「プッシュ」してコンテキストを与えるべきで、彼らに自分で「プル」させるべきじゃないと思う。

└

2年前なら「うるさい白髪のUnixおじさんたち」って書いてたよね。

└

モデルにコンテキストを「プッシュ」するべきだと思うんだ。自分でコンテキストを「プル」する方法を教えるんじゃなくて。人々がインターンに解決してほしいケースで、それがどう機能するの？もし事前に情報を知ってたら、自分で問題を解決するだろうし。MCPから得られる価値って、要するに「クエリを実行してくれ、15のソースをつなぎ合わせる方法を学ばせないで」って感じだよね。

└

XMLタグはLLMにとってうまく機能する。でも、ほとんどはただのXMLタグなんだよね。誰も™が、XML宣言（最初にあるやつ）付きの整形式XMLをLLMに与えてないし、名前空間やXSLT、XMLスキーマなんかも使ってない。ただのアドホックなSGMLスタイルのタグの集まりだよ。

└

「セマンティックウェブ」が失敗した主な理由は、基本的に誰も「セマンティックウェブ」が何なのか、何に役立つのかを説明できないからだと思う。結局、データを何らかの方法で交換するための一般的なバズワードの集まりに過ぎないんだよね。

└

セマンティックウェブは失敗した 失敗したのは、広告をどうやって詰め込むかがわからなかったからだよ。

└

モデルにコンテキストを「プッシュ」すべきだと思う、自分たちで「プル」する方法を指示するのではなく。モデルはコンテキストの容量が非常に非常に限られていて、それが主なボトルネックの一つだから、できるだけその情報を最適化（最小化）することが重要なんだ。モデルが自分が必要だと思うものを引き出すことを許可することで、その制約を満たすのがずっと楽になるよ。

└

面白い観察だね。最近XML/XSLTにちょっとハイプしてたんだけど、JSONマクロ展開言語に取り組んでて（自分自身をマクロの展開で置き換える4つの異なるマクロタグ、#= #& #? #! の代入、置換、条件分岐のようなcond、カスタム関数の呼び出し）XSLTを再発明していることに気づいたんだ。でも本当に欲しかったのはxpath、グラフを横断する方法で、異なる軸に沿って前後に移動する方法なんだ。実際、素晴らしい仕様だよ。それからbasex [0]を見つけたんだ。これは任意のXML文書をクエリ可能なデータベースに取り込んで、XPATHやXQUERYでクエリを記述できるんだ。私の考えでは、幻覚なしでデータセットに信頼できる自然言語インターフェースを作成する最良の方法は、XMLスキーマをシステムプロンプトに渡して、データを取得するためのクエリを書かせることだと思う。[0] https://basex.org/

└

セマンティックウェブはまだ完全には失敗していないよ。ほとんどの企業は内部で限られたクローズドワールド版を実装しているからね。多くの人々がLLMの出力を修正するための解決策として提案しているんだ。

MCPがあるからって、何かにアクセスできると思ってるバカがかわいそうだね。そういうものは、支払いの検証や認証の何重ものレイヤーの後ろに隠れてるから。ホワイトリストに登録されたIP（もちろんv4）もね。ERR 402; それがみんなに見えるすべてだよ。

LLMがAPIドキュメントを読んで適応できるようになった今、標準APIに準拠することはあまり必要ないんじゃない？私にとっては、サイトがAPIを持っているという期待が勝ちなんだ。MCP仕様に準拠しているかどうかは関係ない。

└

-APIのドキュメントがひどく書かれてるかもしれない。 -良いドキュメントがあっても、LLMがAPIとやり取りするための不正確なコードを生成することがある。（生成されたコードを修正して、LLMにそのコードを呼び出させるだけなら、結局中間者を作ることになるよ。要するに「MCPっぽい」サーバーを構築してるってこと。） -LLMにAPIへの直接アクセスを与えるときのセキュリティやリソース割り当ての問題。（LLMはAPIが最後に呼ばれた時の知識が限られてるから、呼び出しすぎてしまうことがあるし、各呼び出しが高額なら、驚きのインフラ費用が発生することも。） -他にもいろいろな潜在的な問題が、中間的なものを持つことで解決される。じゃあその「何か」はMCPであるべきか？それについては合理的な人々が意見を異にするよね。今のところ、人々が必要なことをやるには十分に機能してると思うけど。

仕様が細かいことを気にする古いUnixのおじさんたちによって書かれていた時代、今の世代が「古いUnixのおじさん」をペダンティックだと想像してるのが面白いね。UnixはMITスクールに対する「速く動いて壊す」反乱だったのに。変わらないものもあるね :-)

多くの人がMCPで見落としてるのは、企業向けソフトウェアにぴったりってこと。LLMはユニバーサル翻訳者だから、いろんなバラバラなシステムをつなぐ理想的な接着剤なんだ。だからB2B SaaSの世界でMCPサーバーがどんどん展開されてるし、これらの企業の内部では、異なる使用パターンに応じてAPIやその制限をどう再調整するか話し合ってる。確かに、プロトコルはさまざまな定義で「企業向け準備完了」ってわけじゃないけど、著者が指摘してるように、そこまで重要じゃないし、スタンダードの歴史が示すように、混乱した「悪い」ものでも、適切なタイミングで適切な人々に響けば広く受け入れられるんだよね。

└

RESTとOpenAPIがあるから、自己発見とかもできるしね。MCPを提供する人は、どんなに良いAPIでも提供するよ。

└

これは素晴らしい金儲けだね。データリクエストごとにLLMを通じて有料の旅があるんだ。エンドポイントが将来の安いクエリのために使えるスキーマを交渉するわけじゃないし。

└

MCPは長寿命の接続を介したRPCに過ぎない、ほとんどの場合はWebsocketだね。個人的にはRPCの方が設定が簡単だと思う理由は、1. ユーザーオブジェクトのフィールドを変更するのがPUTかPOSTかで作者たちが無駄に議論しないから。RESTの動詞について無駄に時間を使ったことがあるからね。2. LLMはAPIのRESTセマンティクスを理解する必要がないから。利用可能なRPCメソッドを見て、うまくいくと思うRPC呼び出しをするだけなんだ。これが本質だと思う。

└

完全に同意だね。大企業には、9時から5時まで素晴らしいことをしたいエンジニアがたくさんいて、その後はサインオフして翌日まで仕事を忘れているんだ。ビジネス時間中に従業員から最大限の成果を引き出そうとしない企業があるわけないよね。

MCPについて一番心配なのは、プロトコルがひどく作られてることじゃなくて、改善するのがAnthropicやOpenAIの内部チームの気まぐれにかかってることなんだ。プロトコルを考えてる人たちが、実際にそれを実装しようとしてるエンジニアじゃないみたいに見える。なんとなく、VisaとMastercardの独占状態みたいな感じ。

└

マイクロソフトも運営委員会に参加したよね。https://techcrunch.com/2025/05/19/github-microsoft-embrace-a...

これってAIに広告や「検索エンジン最適化」みたいなスパムを送るために使われるんじゃないの？