「MCPは結局ただのRPC」新ロードマップにHacker Newsで賛否
Model Context Protocol(MCP)の新しいロードマップ発表を受けて、Hacker Newsで議論が盛り上がった。最新リリースでリモートMCPサーバーが普通のHTTPワークロードと同じ扱いになったことを歓迎する声が上がった一方、「REST APIとskills.mdファイルで十分では」「結局ただのRPCエンドポイントでは」といった懐疑的な意見も相次いだ。
認証方式やCLIとの比較、ツール乱立によるコンテキスト肥大化の懸念まで、話は多岐にわたった。
新しいMCPロードマップ
出典: blog.modelcontextprotocol.io / 元記事はこちら
「2026年7月28日のリリースで、リモートMCPサーバーは他のHTTPワークロードと何も変わらなくなった」いいことだ。独自プロトコルを新たに持ち込んだのは、MCPが最初のリリースでやらかした中でも特に頭の悪い判断だったと思う。
最初のロールアウトのひどさは信じられないレベルだった。HTTP/streamingとstdio、bearer認証とOAuthの組み合わせが乱立してて、クライアントとMCPサーバーの組み合わせごとに実装されている部分がバラバラだった。
MCPのエンドポイントが、RESTエンドポイント＋skills.mdファイルに比べてエージェントにとって扱いやすいという理屈がいまだに理解できない。
うちの会社（Parallel AI）では、きっちり文書化したOpenAPI仕様を作って、そこからMCPを生成している。UI・API・MCPが完全に一致するから余計な作業が発生しない。他にもこうやってる人いる?自分には当たり前に思えるんだけど、あまりそう言ってる人を見かけない。
あるいはCLIでもいいよね。
自分も同じ。結局ただのRPCエンドポイントだし、極端な話Sun RPCでもこの手のことは全部できる。
「MCP」って見ると未だに頭の中で「マスターコントロールプログラム」（TRONの意）に変換される。
自分だけ歳を取ったのかと思ってたよ。
v1でMCPをステートフルにしたのはデプロイの観点で最悪だった。動かすために複雑な永続化層が必要になる。結局のところ、OpenAPIスキーマをAIに見せるためのおしゃれな方法でしかないのに。
アクターモデルを思い出す(Akkaのドキュメントへのリンクあり)。
そもそもこれが存在すると知っているかどうかで半分は決まる。
すべてのエージェントがサンドボックスやCLI、コード実行環境を持っていて自由にAPIを叩けるわけじゃない。MCPはサンドボックスなしでもツール呼び出しができる点で意味がある。逆にサンドボックスがあるなら、MCPにこだわるよりコードモードでやった方がいい(Cloudflareのブログへのリンクあり)。
モデル自身はMCPのことなんて一切意識してない。MCPサーバーとやり取りしてツールとしてモデルに提示するのはハーネス側の仕事。モデルからツールの出所が分かる唯一の手がかりは名前に付く「mcp__」というプレフィックスだけ。
その通り。ちゃんと文書化されたopenapi.yamlを返すエンドポイントを用意しておくのは、エージェント用途としてかなり効果的だと感じている。一番の違いは、RESTのAPIをRPCっぽい単位に分解できて、ツールの切り方次第でトークンを節約できること。実用面では「エージェントに/api/v3/openapi.yamlを叩かせろ」で済むのはかなり便利。
正直、この仕様は何もかも複雑にしすぎだと思う。長期間有効な認証トークンを発行して、MCPの設定にヘッダーとして仕込んでおけば、余計な特別ルールなんて全部避けられる。「長期トークンなんて危険だ」と言われそうだけど、1PasswordのCLIみたいなシークレットマネージャーに入れておいてエージェントを起動すればいいだけの話……
自分はそれ以上のことを実現できるプロトコルを作っている最中。来週にはNOSTR/Buzzでのデモを目標に、概念実証を進めているところ。
できればかなり多く実現してほしい。完全に自律したエージェントで、人間が逐一介在する場面を減らせるという発想が個人的にすごく好き。例えばprojects.devみたいなもの。解決すべきセキュリティ上の問題は山ほどあるけど、それでもこの分野の未来はそっちに向かってほしいと思っている。
なぜかって、方向性としては全部その通りだから。言っていることは明らかに正しい。ブラウザで手動でクリックしなきゃいけないのはボトルネックだし、本気で使うユーザーほどそれを許容しなくなっていく。しかもその移行のための個々の作業自体も、エージェントがやることになる。
今の時点でも、MCPサーバー自体がセキュリティ関連の選択肢を全部実装する必要はない。agentgatewayみたいなものを、MCPサーバー用の認証プロキシとして使えばいい。
オーバーエンジニアリングの典型例だよね。普通にOAuthを使えばいいのでは?
OAuthは対話的な操作があることを前提にしている(エージェントの自動実行には向かない)。
「コードモードとして」ってどういう意味?
要するにCloudflareのコードモードのことを指してる。AWSのMCPが「EOLです」ばかり言ってくるのにうんざりしてたところなんだ。
「最低でも3年は実績のあるものしか使わない」うわぁ…変化に振り回されたくない気持ちは分かるけど、それを本当に守ったらキャリアの自殺行為だと思う。新しいものに挑戦するのは欠かせない。
変化についていくこと自体には価値がある。とはいえ、まだ成熟していない、生き残るかどうか分からないものを本番環境に入れるのを避けるのも賢明なことが多い。ポステルの法則を強引にもじるなら「学ぶことには寛容に、デプロイすることには保守的に」ってところ。
3年なんて大したことない期間だよ。直近3年以内にリリースされたものが必要になる仕事って一体何をしてるの?自分は元の投稿者じゃないけど、そのシニアな開発者たちは「試す」のと「(本番で)使う」のをちゃんと区別してたんじゃないかな。
その方法の問題点は、しばしばMCPツールが乱立してコンテキストが肥大化してしまうこと。それってそもそもMCPが作られた理由のひとつだったはずなのに。
.NETやJavaのバックエンドまわりでは、基本的に既にあるものを拡張しているだけ。ローコード・ノーコードのツールでは、webhook用の追加メタデータが手に入る、という感じ。
CLIはMACHアーキテクチャのようなクラウド環境では機能しない。それに、毎回プロセスを立ち上げるのもどうなのという話。
LLM向けにCLIを使うことへの反論としては、今まで見た中で一番説得力がある。ありがとう。
※本記事は5ch(Hacker News)スレッド「The New MCP Roadmap」より抜粋・要約して構成しています。
まだコメントはありません。