Web 2.0 2.0の到来: MCP

• Model Context Protocol(MCP) が急速に採用され、新たな オープン標準 として台頭している
• MCPの中核的な価値は完璧さではなく オープン性と相互運用性 にある
• Web 2.0の本当の意味は 閉鎖的なプラットフォーム ではなく、オープンAPIとデータ共有にある
• 過去の閉鎖化の時代から再び オープンWebの価値 へ回帰する流れが起きている
• MCPの採用により、開発者が プラットフォームの統制と透明性 をさらに求める可能性がある

---

MCP: 新たなオープンWebの登場

ここ数か月のあいだに、開発者のあいだで Model Context Protocol(MCP) への関心が爆発的に高まっている。出発点となったのは、Anthropic が2023年に自社LLM（Claude）システムをさまざまなアプリと相互作用できるよう設計したことだった。その後、OpenAI がChatGPTで同じプロトコルをサポートしたことで、急速に標準として定着した。現在は Windows にも採用されるなど、主要プラットフォームへと広がっている。

興味深いのは、MCP自体の明確さや完成度よりも、使いやすさとスピードにあることだ。従来の厳密に設計された伝統的な標準とは異なり、MCPはやや曖昧で緩やかに定義された仕様であるにもかかわらず、実際にはうまく機能する点が大きな強みとなっている。とりわけ、オープンプロトコル として誰でも利用できることの重要性は高い。

真のオープンWebの意味

現実のWeb環境では、完璧ではなく多少不十分な標準であっても、迅速に採用 されるときに本当の発展が生まれる。こうした流れは、"好きなポッドキャストアプリでいつでも聴く" のような革新を生み出してきた。

Web 2.0の精神は、オープンAPI、データ共有、利用者と開発者の統制力向上といった 開かれたエコシステム を志向していた。Facebookのような閉鎖的プラットフォームは、Web 2.0を 衰退させた主体 だったことに注意すべきだ。かつて Flickr, del.icio.us, Upcoming などは、共有と接続を重視する文化を主導し、ライブブログのようなプラットフォームではAPI/プロトコルのオープン標準をめぐる議論が活発に行われていた。

オープンの復活

一世代を経て、再び 相互運用性 への期待が高まっている時点にある。過去には大手テック企業の閉鎖政策によってAPIが塞がれ、サービスが消える経験が繰り返されてきた。たとえば、筆者が構築したソーシャルネットワークのデータ分析ツールは、最終的にプラットフォーム側のAPI遮断によって廃止に追い込まれた。こうした政策は、Web 2.0のオープンデータと互換性のビジョンを崩壊させた。その結果、コンテンツの埋め込み不可やデータ移動性の阻害といった問題が日常的に起きている。

しかしMCPの登場によって、AIを引き金として プログラム可能性 と オープン性 の再浮上が期待されている。複数のプラットフォームが同一プロトコルを採用することは、技術基盤における好循環を可能にする。

プラットフォームが プロトコルをそのまま受け入れ、標準化に忠実であるとき、エコシステム全体に前向きな変化が起きる。"規格よりもっと良く作りたい" という開発者の欲が、逆説的にエコシステムを損なうことがあると強調している。HTMLなども完璧な仕様ではないが、結果としてインターネットの大規模な相互運用性の基盤となった。

標準準拠の重要性

新しい開発者世代は、同一プロトコル・フォーマット基盤のイノベーション の強さを直接体験している。こうした経験は、再び オープン標準 への強いこだわりにつながる可能性が高い。かつてRSS、Podcast、OpenID、OAuth、OpenSocialなどのオープンフォーマットが、実際にユーザーへ力を与えていた時代に似た雰囲気が再現されている。

現在は大企業の専有物ではなく、開発者とユーザーのコミュニティ自身が要求権を行使できる時点にある。誰もがプラットフォームに 体験の統制・透明性 を求められるべきであり、MCPのようなオープン標準を導入する際には、プラットフォーム内部の動作とデータ活用の透明性が必ず伴わなければならない。MCPはオープンではあるが、依然として内部動作やセキュリティの課題では不十分であり、今後の改善が求められる。

Web 2.0精神の復活可能性

MCPはあらゆる問題を解決する 万能の解決策 ではないが、Web 2.0時代の開かれたエコシステム復活を促す きっかけ にはなりそうだ。AIをめぐる議論の誇張や批判不足といった限界は依然として残っている。

しかし、若い開発者を中心に、プログラム可能なWeb、閉鎖性からの脱却 の価値が改めて見直されている。Webは一部の巨大企業だけの所有物ではなく、誰もが それぞれ望む方法で活用 できる開かれた場であり、MCPがその哲学を再び呼び起こす可能性が示されている。

[GN⁺]

Hacker Newsの意見

• 多くの人が、MCPの本質がエンタープライズソフトウェアに適している点を見落としがちだと感じている。LLMは一種の万能翻訳機のように、相互接続しにくいシステム同士をつなぐ柔軟な中間レイヤーとして機能しうるからだ。実際、B2B SaaS業界でもMCPサーバーの導入が活発に進んでおり、社内でもAPIの利用パターンに合わせて制限や構造を調整する議論が増えている。たとえこのプロトコルがさまざまな意味で「エンタープライズ対応」ではないとしても、それはそれほど重要ではないという見方をしている。標準の歴史を見ても、洗練されていない「雑な」仕様でも市場の需要に合えば結局採用される例は珍しくない
  • MCPは長い接続上で動くRPCのようなもので、概ねWebSocketベースだと理解している。個人的にはRPCのほうが簡単だと思う。理由は第一に、RESTエンドポイント設計で、POSTで全体を置き換えるのかPUTでフィールドだけ更新するのかといった不要な議論を減らせること。第二に、LLMがRESTの用語やセマンティクスを知らなくても、RPCメソッドだけ見ればすぐ呼び出せる点だ。結論として、この2点が大きな強みだ
  • 企業の観点では、MCPは優れた収益モデルだという点を指摘したい。各データリクエストが有料のLLM実行に直結する構造だからだ。一方で、MCP導入によって将来のクエリをより安価にするスキーマ交渉のような最適化がまったくないのは惜しい
  • すでにRESTとOpenAPIがあり、それ自体でself-discovery（自動探索）のような機能を支援している。MCPを提供する企業であっても、どうせ皆よいAPIを提供するはずだという立場だ
  • 本当に共感する点だが、大企業には9時から5時まで格好いい仕事だけに集中し、退勤後は会社のことなど一切考えないエンジニアが多い。だとすれば企業としては、就業時間内に限って従業員の生産性を最大化する機会をつかむのが最善という、ごく常識的な結論になる
• MCPサーバーでゴキブリのような生物を制御する実験が登場するまで、どれくらいかかるのか気になる。実際、過去10年以上にわたり、ロボローチ実験、サイボーグゴキブリなど多くの事例があった
• 昔はUnix開発者が徹底して仕様書を書いていたが、時代は変わった。この厳格さとeXtensibleであることへの疲労感が、XMLベースのアーキテクチャ失敗の一因だったと言いたい。当時はXSL、XHTML、XSD、WSDL、RDF、RSSなど、アーキテクチャが過度に複雑で、その結果JSONのような単純なフォーマットが人気を得た背景がある。ただ最近は、XML活用が増えているトレンドも目にしている。特にAnthropicのようなLLMシステムプロンプトでは、XMLやMarkdownのような構造化テキストが多く使われていると感じる。しかしMCPモデルは間違っていると思う。モデルに情報を「引っ張ってこい」とさせるより、「押し込む」方式、つまり事前にコンテキストを提供するほうがよいという意見だ
  • 興味深いのは、最近JSONベースのマクロ拡張言語を作っていて、実はXSLTやXPathの再発明をしていると気づいたことだ。グラフ探索に卓越したxpath仕様には感心した経験がある。BaseXのようなツールで任意のXMLをDBに取り込み、XPATH/XQUERYで問い合わせられるので便利だ。LLMにでたらめを言わせないための確実なデータインターフェースを作るなら、XMLスキーマをシステムプロンプトに入れてデータ問い合わせ文を生成させる方法が最善の解だと思う
  • 「事前にコンテキストをプッシュするモデル」が現実的にどこまでの問題に対応できるのか疑問だ。もしユーザーが事前に情報を知っているなら、そのまま問題を解決するだろうし、MCP需要の大半は「15個のソースの接続方法を学ばなくてもクエリ処理だけしてくれ」といった要望だと感じる
  • LLMはタグ形式のXMLはうまく処理するが、実際には大半がまともなXMLの塊（<?xml version="1.0" encoding="UTF-8"?>で始まり、名前空間やスキーマなどを含むもの）ではなく、単なるSGML風タグの寄せ集めにすぎないと指摘したい
  • セマンティックウェブが失敗した本当の理由は、広告挿入やビジネスモデル連携に成功しなかったからだという現実的な要因を強調したい
  • 「コンテキストをプッシュする」方式には批判的だ。LLMのコンテキスト処理容量（context window）は非常に限られているので、必要な情報だけを最小限渡すのが最適だからだ。各モデルが必要な文脈だけを自分で選んでpullできるときにこそ、限界を乗り越えられる可能性が高い
• MCPは、AIの人気によってさまざまなプラットフォームがどんな目的にでもプログラム可能になるという希望を抱かせるように見えるが、むしろ失敗する運命だと思う。なぜならセマンティックウェブが失敗した理由も収益構造を構築できなかったことにあったからだ。AIがWebの代わりに深く掘り下げる「リサーチ」機能も同様だ。たとえばレストランのメニューをメタデータとして公開すれば、「テキサスで最も安いタコスを探す」といった自動化が可能だったはずだが、現実にはデータの囲い込みと、それを回避するAIクローラーとのインフラ競争になっている。大きく見れば、現行システムは非効率だという結論になる
  • MCPも結局はrobots.txtが進化した形にすぎないという評価だ。本質的には「自分のリソースをうまく説明してくれれば活用する」というモデルだ。過去の90年代のJavaベースエージェントシステムも、エージェント間の情報の非対称性の問題で失敗したし、この設計上の限界を取り除いてしまうと、社会やビジネス全体が機能停止する可能性すらあるという懸念だ
  • Open APIは金銭的収益の問題以前に、実際には無制限のリソース投入をしない限り、AIエージェントのリクエストボットの波で資源枯渇を起こして結局破綻する、という経験的な判断だ。長期的にはRPCのpay-per-call料金体系が安定した代替案になるだろうと見ている。モデルやエージェントの運営者が決済クリアリングハウスの役割を担い、そのコストをサブスクリプション料金などに織り込む方向が有力だと予想する
  • HATEOASのようなRESTアーキテクチャの理想像は2010年代初頭に大流行したが、swagger yamlなどの自動化ツール以外には実質的な拡張もなく廃れた。用語自体が難しすぎて、失敗要因を自ら招いたのだと思う
  • 人が読むテキストを人工的障壁とみなす見方には異論がある。むしろレストランにJSON生成スキルやソフトウェア導入を求めるほうが、実際には人工的な障壁だ。NLPツールのおかげで既存データをそのまま活用でき、開発コストはほぼゼロ水準まで縮小された。言語的な不正確さはあるにせよ、それは人間の言語に本来的な性質なので、大きな問題とは考えない立場だ
  • セマンティックウェブを批判している流れで言及するのは慎重になるが、実際にその気のあるレストラン経営者なら、いつでもメタデータを公開できるし、買い手と売り手を簡単につなぐきっかけにもなりうると思う。WordPressプラグインを例に取れば、すでに schema.org/Restaurant、Menu、MenuItem、Offer などのメタデータ支援があるので、結局のところ最大の障壁はCloudflareのようなゲートキーピングではないかと推測している。実際、Python自動化のアイデアを妨げる実質的要因だ
• LLMはAPIドキュメントを読んで自動適応できるため、標準API規格への準拠は以前ほど必須ではないという考えだ。MCP仕様の採用とは無関係に、各サイトで「API提供」が期待されるようになったこと自体が大きな変化だ
  • 実環境ではAPIドキュメントが不十分なこともあるので、LLMが誤ったコードや呼び出しを生成する可能性がある。ユーザーがそれを修正してLLMに渡せば、結局は中間層（MCP風サーバー）を作る結果になる。LLMにAPIへの直接アクセス権を与える場合は、セキュリティやリソース管理の面でも危険があり（呼び出し過多でコストが爆発する可能性がある）、ほかにもいくつものpain pointが存在する。その一部は、そもそも間にMCPのようなインターフェースがある構造で解決される。その「仲介者」が必ずしもMCPである必要はないにせよ、現時点では十分に実用的なソリューションだ
• MCPで最も懸念しているのは、不十分なプロトコル水準そのものではなく、AnthropicやOpenAIのような企業内チームにだけ改善・修正権限が集中している点だ。実際の開発者・運用者中心ではなく、ブレインストーミング段階にとどまっている仕様ではないかという警戒感もある。まるでVisa-Mastercardのデュオポリーの影が重なるようだ
  • Microsoftもsteering committeeに参加した例がある
• 「セマンティックウェブ」は実際には文法構造にすぎず、MCPのほうが本当に実現可能性を持っているのではないかという期待もある
• 「主要な古参Unix開発者は過度に厳格だった」という認識があるが、むしろUnixこそ「まず試して壊してみる」文化の元祖だったという点に皮肉を感じる。世代が違っても本質は変わらないと思う
• MCPがGoogle検索のSEOのように、AIに向けた広告やスパムの拡散に悪用される可能性があるという現実的な懸念がある
• MCPのおかげで誰もが各種データに簡単にアクセスできるようになると思い込むのは危険だと考える。実際には何重もの決済認証や許可されたwhite list IPなどのセキュリティ装置に縛られ、実ユーザーには「ERR 402」エラーだけが返ってくる現実のほうがしっくりくる