ハクソク

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

MCPはWeb 2.0の到来です

2025年5月24日原文(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はウェブをオープンにする手段として説明されてるけど、実際にはウェブが本当にオープンだったらできる面白いことのデモを作る手段なんだよね。

Hacker Newsで議論の続きを見る