いちばん引っかかったのは、MCPそのものより「ちゃんと運用すると、急に話が現実になる」という空気でした。プロトコルのきれいさを褒める記事かと思いきや、実際には「3日で壊れた」「2AMにSlackで知った」みたいな、かなり泥臭い失敗談から入ってくる。そこがよかったです。AIまわりの話って、デモの気持ちよさに寄りがちですが、この記事は最初から“壊れる前提”で読ませにきている。
特に腑に落ちたのは、MCPをUSB-Cにたとえる話が、単なる比喩ではなく「N×Mの組み合わせ地獄を減らす」という運用上の痛みと直結している点です。LLMとツールの接続が増えるほど、個別実装の継ぎはぎは本当にきつくなる。ここでJSON-RPCという共通の会話形式に寄せるのは、地味だけどかなり強い発想だと思います。派手な機能より、まず“壊れにくい共通語”を作る。AI時代のインフラっぽさがある。
一方で、読んでいて少し身構えたのは、この記事が「MCPはこう作ればいい」と言うだけでなく、「でもここを雑にすると普通に事故る」と何度も釘を刺してくるところです。特にOAuth 2.1やstateless scalingの話は、きれいな理想というより、実運用ではそこを外すと詰む、という警告に見えました。プロトコルが整うほど、逆に認証・権限・セッション管理の責任がはっきりする。便利になる代わりに、雑な作り方は通らなくなるわけです。
この記事を読んで思ったのは、MCPが面白いのは「AIのための新技術」だからではなく、古くからある設計原則――stateless、標準化、権限分離、idempotent の考え方――を、AI接続にそのまま持ち込もうとしているからなんだろう、ということでした。派手さはないけれど、こういう方向のほうが長生きする気がします。少なくとも、デモはできても運用できない仕組みより、ずっと信頼できる。
参考: Production MCP: JSON-RPC, OAuth 2.1, Transport, and Scaling
