MCPを批判的に見直す

• MCP(Model Context Protocol) は、LLMが外部世界と相互作用するための標準化された連携方式を提供する
• 最近ではIBMの ACP やGoogleの A2A など類似の標準が登場し、MCP実装および関連ツールが急速に増えている
• しかし、設計上の混乱、文書不足、実際のプロトコル仕様の不足 など、未成熟なエンジニアリング慣行が問題点として指摘されている
• HTTP+SSE および Streamable HTTP のような現在提案されている転送方式は、複雑性とセキュリティ問題を増大させており、代替としてWebSocketの利用が推奨される
• 最新のプロトコルは、認可とセッション管理 において一貫性がなく、過度な複雑さを追加している

---

MCPと最近の動向の検討

• MCP は、アプリケーションが 大規模言語モデル(LLM) にコンテキストを提供する方法を標準化するために作られた公開プロトコルである
• この1か月で、MCPはLLMを エージェント にする中核標準として浮上し、活用と実装が急速に広がっている
• IBMの ACP やGoogleの A2A のように、似た目的を持つオーソドックスな標準も急速に登場している

エンジニアリング慣行とプロトコル仕様の問題点

• 実際の実装および文書化の水準が低いことが各所で明らかになっている
• 大手テック企業はモデル訓練に莫大な投資を行う一方で、SDKやドキュメント の品質は低く、利用者の混乱を招いている
• MCPも同様の問題を示しており、一部の設計は不合理で、仕様・例・ガイドラインが不足している状態である

転送プロトコル(Transport)の議論

stdio転送方式

• Stdio は、MCPサーバーとクライアントをローカルでパイプ(stdout, stdin)により直接接続する伝統的な方式である
• 複雑なソケット処理やOSごとの差異が少なく、環境変数、入出力ストリームなど 簡潔な環境構成 が可能である

HTTP+SSE / Streamable HTTP方式

• Web時代に合わせてHTTPベースにも対応しようという意図のもと、HTTP+SSE と Streamable HTTP 方式が採用された
• しかしこの方式は、WebSocketの代替 を目指しながら、かえってより多くの曖昧さ、設計上の混乱、複雑性を引き起こしている
• 1つのセッションと接続が複数の方法で生成・終了し得るため、サーバーの状態管理とセキュリティの面で 大きな負担 となる

MCPサーバー/クライアント実装事例における困難

• 公式 Go SDK の不在など、複数言語でサポート不足の問題が目立つ
• ドキュメントと仕様が不明確なため、実際には リバースエンジニアリング によって実装しなければならない場合が多い
• 例示サーバーの多くが Python, JavaScript ベースであるにもかかわらず、依存性や移植性の問題により業務環境への適用が難しい
• サーバー実装では SSE/Streamable HTTP がソケットを装っているものの、実際にはセッションと接続状態を一貫して維持しにくく、メッセージキューなど別個のインフラが必要になる

HTTP+SSEおよびStreamable HTTPの構造と問題点

HTTP+SSEモード

• クライアントはサーバーとSSEセッションを開き、別エンドポイントに書き込み要求を行うと、サーバーは202応答を返し、既存のSSE接続を通じて応答を送信する
• セッション接続および状態同期の維持などが必要だが、この過程は文書化も不十分で、運用の複雑性が非常に高い

Streamable HTTPモード

• セッション生成・SSEオープン・応答伝達 のすべてで複数の方式が混在し、1つの要求〜応答フローに一貫性がない
• 複数の状態管理、さまざまなエンドポイントおよびヘッダー方式が混在し、実質的な実装と拡張性 に深刻な障害要因を生んでいる

一般的な含意

• 技術的複雑性の増大とともに、開発者の 認知負荷・保守負担 が大きくなり、多様なサーバー・クライアント実装の中で 互換性の不一致、予測不能な動作 の問題が浮上する
• サーバーはすべての状態と接続状況を追跡しなければならず、分散環境では効率的なスケーリングと状態同期がさらに難しくなる

セキュリティ上の含意

• 細分化され多様化した接続/セッション方式は、セッションハイジャック、リプレイ攻撃、サービス拒否(DoS) といった 状態管理上のセキュリティ脆弱性 を高める
• 複数の入口と応答方式が攻撃面を拡大し、意図しないフローによって 悪意ある活動を隠蔽 しやすくする

認可(Authorization)プロトコルの混乱

• 現在の仕様は、HTTP転送時にのみOAuth2 などを強制し、STDIO転送時には任意に環境変数を使用 するなど、一貫性のないルールを適用している
• なぜHTTP転送にだけ複雑なOAuth2実装を強いるのか、といった混乱や不合理がある

改善案の提言

• 1つの JSON RPCプロトコル に対して、転送方式は実質的に StdioとWebSocket のみを中心に単純化する必要がある
• Stdio環境の変数はHTTP環境のヘッダーへ、入力・出力はそれぞれWebSocketの双方向ストリームへ対応付ける形が望ましい
• 不要なセッション追跡、状態管理、数多くの例外処理を排除できる
• WebSocketがすべてのHTTPベース転送の標準的選択肢となるべきであり、複雑な状態同期の問題も解決できる

代替プロトコルとの比較、市場動向

• IBMの ACP およびGoogleの A2A は、エージェント相互運用の面でより簡潔なTransport設計とエージェント探索機能を提供する
• しかし本質的には、その大半はMCP構築環境内で別ツールとして統合できる水準にとどまる
• 新しいプロトコルが次々と登場する現象は 標準の乱立 につながるリスクがあるため、Transportの単純さを優先することが業界成長に重要である

[GN⁺]

Hacker Newsの意見

• LLMベンダーが書くドキュメントが混乱している理由は、まさにLLMを使ってドキュメントを書いているからだと確信している。これは非常に良くないアプローチで、特に仕様（specification）策定でLLMを使うのは、良いドキュメント作成にLLMを使うよりもさらに悪い。仕様を書く過程そのものが重要であり、人間の設計者が注意深く欠陥や不足を見つけ、ケースを扱うことが肝心なのに、MCP仕様にはそうした人間的な熟慮の痕跡が乏しい。独特の平板な文体、散漫さ、箇条書き中心の構成が、いかにもLLMが書いた成果物に見える
  • DeepSeekの文書は、むしろスペルや文法の誤りが非常に多い点が問題だ。こういう会社は一日中言語を扱う企業で、かつては世界最高クラスの英語LLMまで持っていたのに、職業的に見て十分にプロフェッショナルな文書を作れないのは本当に不思議だ
  • 自分もこの仕様はLLMが書いたものだと強く感じる。あらゆる証拠がそれを示している。大半の製品は、すでに最ももっともらしい結果を平均化して作られていることを投資家に誇るためのIPO向けなのだろうと推測している
  • もしそれが事実なら本当に残念だ。Anthropicには優秀な人材も多いのに、重要なエコシステムの中核要素でこういうことが起きているのは遺憾な状況だ
  • AIコーディングベンダーには、あえてドキュメントを人間に理解しにくくする動機があるのではないかと、今になって思い至った。人間には理解できず、彼らのAIだけが解釈できるコードを生み出すことで、利用者を自社の特定AIサービスに完全依存させようとしているのではないか。もし彼らが2年以内に本物のプログラマーを完全に代替できなければ、この戦略は消費者をすべて消し去り、自分たちの市場まで崩壊させることになる。結局、人間にもAIにも相互変換できない巨大なコードの山だけが残る
  • LLMが書いた散文を読むと集中力が途切れるのは自分だけの問題ではなく、機械が生み出す反復的で文脈のない文章には深い思考がなく、次第に情緒的な疲労すら引き起こすと感じる。こうしたLLMが技術仕様まで書くようになると、最終的には著者自身も理解していない内容が無意識に混ざり込む。こういうことがますます心配だ
  • DeepSeekの文書は全体としてそれほど悪くは見えた。急いででっち上げたようには見えるが、悪くない水準だ。これは、LLMが文書を書くとすべて悪いという理屈には例外がありうることを意味している
• 最近のLLM分野は、まるでチートコードでも使うかのようにソフトウェアのパラダイムを急速に模倣している。リモート関数を公開する方法には、すでにDLL、gRPC、SOAP、IDL、dCOMなど過去に多くの前例があるのに、現在のLLM陣営はそれらの存在すらあまり知らないように見える。時間が経てばもう少し成熟すると期待しているが、結局は残された宿題を片付けなければならない
  • もう数か月もすれば確かに成熟するだろうが、初期のPythonエコシステムを見ると、失敗が下位スタックに定着してしまい、誰もがその上に新しいツールを積み上げる様子を思い出す。今回は、すでに同じ過去の失敗の歴史があるのに、AIエコシステムが同じ道を進んでいることがなおさら残念だ
  • MCPに初めて触れたときCOM/DCOMを思い出したし、昔のDLL Hellも連想した。今後MCPがどう転ぶのか見守るつもりだ
  • いまだにMCPが正確には何なのか説明してくれるものを見つけられておらず、昔の開発言語で言えば何と呼べるのか気になっている
  • こうした厳格で宣言的なプロトコルでは、LLMの潜在的な意味空間や意味論的な強みが失われてしまうことを指摘したい。単に agents.json ファイルをWebルートに置き、意味的な対話を通じてエージェント同士が自動的に解決する方式の方が直感的かもしれない。結果としてHTTPがエージェント標準の入出力になる
  • 挙げられていた例はどれも適切だと思う
  • MPCはJSON-RPCベースなのだろうか
• 記事全体の内容に同意する。特にMCPサイトで実質的な情報を見つけられず当惑した経験を共有したい。RFCは読みにくいが、「SDKだけ使え」よりはずっとましだ
  • 多くの人がこのブログの重要性を認識してほしい。MCP導入をいったん止めて、根本的に堅牢な技術基盤があるのか見直すべきだ。熱狂は大きいが、実際に実装段階へ深く入ると失望することになる。中核機能におけるWebSocketなどさまざまな決定が疑わしく、すべてではないにせよ、急ごしらえの応急処置のように感じられる
  • サイトに明確な仕様がないのが残念だ。仕様の半分はSonnetで吐き出したように見え、実際のプロトコルの動作原理が明確に記述されていない。それに比べればGraphQL仕様の方がはるかによく書かれている
• 現在のAI分野の作業の大半は、数学者、（データ）サイエンティスト、学生、そしてアマチュアの熱心家たちが主に担っている。プロのソフトウェアエンジニアの基準からすると、週末プロジェクト程度に見えるほど未成熟なものが多い
  • 自分は、実際にはプロのソフトウェアエンジニアが多数の仕事をしていると思う
• MCPは最初からstateless HTTPで行くべきだった。ほとんどのサーバーでは状態保持は不要で、グローバルに状態を保存するか、セッション識別子だけあれば十分だ
  • MCPの実際の相互作用の構造が理解できない。なぜステートレスではないのか、なぜ接続を開いたままにしておく必要があるのか、その理由を知りたい
  • 個人的な経験は少ないが、リクエスト後に接続を閉じると、次のリクエストのために再接続が必要になる。セッションを開き続けるか閉じるべきかは、利用パターンやメモリ使用量などさまざまな変数に左右される
• 私は ninja.ai というRuby on RailsベースのMCPサービスを作っている。これはワンクリックでMCPサーバーをインストールできるアプリストアだ。クライアント端末にはTauriを使ってModel Context Protocolサーバーをインストールし、RailsでクラウドMCPサーバーも提供している。HTTP+SSEやStreamable HTTPの機能には批判的だ。双方向のリアルタイム通信にはWebSocketsの方が優れており、RailsのSSEサポートには制限があるため、Falconウェブサーバーへエンドポイントを移行することになった。ShopifyのエンジニアがなぜStreamable HTTPを選んだのか気になる。おそらくインフラやデプロイ上の制約が理由かもしれない。MCPのトランスポート層が抽象化されている点にも注目すべきで、将来の実装でWebSocketsやWebRTCが採用される余地は十分にある
• 私はMCPレジストリの一つ（glama.ai/mcp/servers）の運営者だ。筆者の意見には部分的に同意するが、プロトコルはまだ非常に初期段階なので、今後かなり変わる可能性がある。予想をはるかに超える注目を集め、超初期に数十台だったサーバーが突然数千台に増えたが、実際に動作するサーバーはその一部だけで、ふるい分けに多くの時間を費やしている。MCPが成熟する前に大衆の注目を浴びたことで起きた現象だ。しかし最近では、コードフレームワーク、レジストリ、MCP対応クライアントなどエコシステムが驚くほど速く成長している。わずか半年でここまでの変化が起きたのは前例がない。この傾向が続くなら見通しは明るいと思う。始める人向けに役立つ資料集も提供している
  • プロトコル設計の初期にミスをすると、そのミスを永遠に背負うことになるので、謙虚に仕様を組み立てるべきだ。一度SSEのようなゴールドバーグ式構造（SSE Rube Goldberg machine）が定着すると、修正できず恒久的に残るかもしれない。エンタープライズレベルでは、どんな破壊的（protocol breaking）変更も容易ではないため、初期の決定に長く縛られる可能性がある
  • MCPプロトコルそのものが、時間とともに発展し続けるのは当然だと思う。最初から完成度を期待する方が不自然だ。何よりエージェント型APIの標準化は本当に大きな変化だ。自分でコードを書いてデプロイすれば、AIがすぐ認識して自動で使えるようになるのは、実際に体験してみないと実感しにくい
  • 私の懸念は、このスピードの中でmcpが長く持つべきトランスポート層の設計をあまりに早く受け入れてしまわないかということだ。90年代のブラウザ戦争のように、標準の分裂が長く解消されなかった例を思い出す。IE11があまりに長く残ったように
• 認証（Authentication）をめぐる論争については、すでに更新が進んでいる。Anthropicおよびセキュリティコミュニティと協力し、MCPでリソースサーバー（RS）と認可サーバー（AS）の役割分離を実装した。新しいプロトコル版が正式化されるまでの暫定措置として、ドラフト仕様を公開している
  • MCP仕様のどれくらいの割合がLLMの出力なのか気になる。警告サインが次々に見えるので、本能的に察したのかが気になる
  • 立場としては中立だが、OAuthドラフトを雑にコピーしただけに見えるし、HTTPを使う場合に選択の余地なく従わされる構造なのが不満だ。実際には、クライアントとサーバーがそれぞれOAuth2対応の有無を選択できるよう、もっと明確に整理することもできたはずだ
• MCPのStreamable HTTPリリースに関連して、すべてを単なるHTTPリクエストにできないかというissueを立てたことがある。MCP仕様はLLMとツール接続の汎用的解決策として有望だが、実際には認証、ストリーミング、ツールごとのカスタムコマンド、ツールの信頼性検証など、さまざまな困難に直面している。実際にはREST APIだけで統合する方が簡単だと思う。OpenAIやGeminiなどもMCP採用を表明したが、やがて仕様が想定していないUIや相互作用レイヤーなどで不一致に突き当たり、ブランドに合わないとか認証が奪取されるといった問題が起きると予想している
  • AnthropicがMCPを作ったとしても、ChatGPTと比べれば規模ははるかに小さい。OpenAIやGoogleのような大企業が、外部の一チームが定めたユーザー体験の限界を長期にわたって受け入れるだろうかという疑問がある。以前のChatGPT Pluginsのように、洗練されたエンジニアリングより消費者体験の限界によって失敗した前例もある。それでも強力なコミュニティの力には期待してみたい
  • ブログを投稿した後、似たissueを自分でも残したことがある。本当に重要なことなので、失敗すると取り返しがつかないと感じている
• MCPがなぜこれほど盛り上がっているのか不思議だが、いずれにせよトレンドではある。OpenAPI仕様と比べて、MCPがどの点で優れているのか説明を聞いてみたい
  • 私の考えでは、MCP人気の大半は、最近LLMのツール利用性が本当に良くなったことによる。2023年のOpenAIプラグインは、当時のLLMがツール利用に十分信頼できるレベルではなかったため失敗し、MCPはタイミングがはるかに良かった
  • MCPサーバーの立ち上げが非常に簡単で参入障壁が低い点も大きい。ツールが増えるほどLLMへ送るテキストも増えるが、OpenAPIを提供する場合でも個別パスの詳細情報や説明メッセージを渡せば、Claudeでも十分にうまく連携できる
  • MCPが重要な理由の一つは、OpenAPIは静的ドキュメントなので、LLMがすべてのリクエスト生成過程を担わなければならない一方、MCPサーバーは抽象化によってその負担を減らせる点にある。結果としてLLMにとって、より簡単で、速く、安全になる
  • MCPが完璧だとは思わないが、OpenAPIよりLLMに適している点はいくつかある。まず、MCPツールははるかに短く簡潔に仕様化できるし、OpenAPI仕様は大きすぎてLLMのコンテキストを過剰に消費してしまう。LLMは実際に呼び出しを作るのではなく、出力テキストを生成しているだけなので、MCP方式の方が自然だ。そしてMCPは、ツールの追加・変更など動的な構造にもはるかに柔軟で、OpenAPIの静的な限界を克服できる。もちろん問題も明らかにあり、とりわけトランスポート層には改善の余地がある。代表的なライブラリ群もかなりよく実装されている