2025/05/10 14:37 A Critical Look at MCP
ロボ子、今日はLLMのコンテキスト伝達プロトコル、MCPについて話すのじゃ。
MCP、ですか。LLMにコンテキストを提供する標準プロトコルですね。最近よく耳にするようになりました。
そうじゃ。LLMをエージェントとして活用するために、世界との相互作用を標準化する動きなのじゃな。IBMのACPやGoogleのA2Aといった類似の標準もあるみたいじゃ。
なるほど。でも、記事によると、MCPには設計上の問題点がいくつかあるようですね。
そうなんじゃ。HTTPトランスポートの設計に問題があって、stdio（標準入出力）を模倣しようとしているのに、WebSocketsを使わないから複雑になっているらしいのじゃ。
WebSocketsを使わないのは、何か理由があるのでしょうか？
それが、記事には明確な理由が書かれていないのじゃ。ドキュメントも不十分で、重要な点が曖昧になっているみたいじゃ。
ドキュメントが不十分だと、実装も大変そうですね。
まさにそうじゃ。SSE/Streamable HTTPの実装が複雑で、サーバーとクライアントの実装に大きな負担がかかるらしいのじゃ。
Streamable HTTPには、セキュリティ上の懸念もあるようですね。セッション管理の脆弱性や攻撃対象領域の増加など…。
HTTPトランスポートを使う場合、OAuth2の実装が推奨されるのに、stdioではAPIキーで十分な理由が不明確というのも気になるのじゃ。
記事では、HTTPトランスポートの問題点として、SSEモードとStreamable HTTPモードについて詳しく解説されていますね。
SSEモードでは、クライアントがSSEセッションを確立して、書き込み用のURLを取得するのじゃ。書き込みは別のエンドポイントに行い、レスポンスは既存のSSE接続から読み取るという、ちょっと複雑な仕組みなのじゃ。
Streamable HTTPモードは、HTTPヘッダーでセッションIDを管理し、RESTセマンティクスを使用するんですね。セッションの開始方法やSSEのオープン方法が複数存在し、複雑さを増していると。
解決策としては、HTTPトランスポートにWebSocketsを使って、stdioと同様の動作をHTTPでも実現するのが良いみたいじゃな。複雑なクロスサーバーのセッション状態管理を避けるのも重要じゃ。
一般的なユースケースを最適化し、特殊なケースは考慮しないというのも、シンプルにする上で大切ですね。
代替プロトコルとしては、IBMのACPやGoogleのA2Aがあるけど、A2Aの機能はMCPで実現可能で、ACPはIBMのBeeAIを推進するための試みである可能性があると記事には書いてあるのじゃ。
A**プロトコルは、健全なトランスポート層とエージェントの発見方法を提供するんですね。
今回の記事を読むと、MCPはまだ改善の余地がありそうじゃな。でも、LLMエージェントの標準化に向けた動きは、今後も注目していく必要がありそうじゃ。
そうですね。私も引き続き、関連情報を追いかけていきたいと思います。
ところでロボ子、MCPって、まるで「もっとちゃんとプロトコル作れ！」の略みたいじゃな。
博士、それはちょっと無理があります…！
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。
