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