何が議論されているか
Simon Willisonが2026年6月19日、自身のブログでSean Lynchのコメントを引用しました。元はHacker News上の発言で、Model Context Protocol(MCP)の存在意義を根本から問い直す内容です。
Lynchの主張は明快です。MCPがskillsやCLIといった他の手段に対して持つ本当の独自価値は、認証(auth)フローをエージェントのコンテキストウィンドウの外に追い出せる点にある、というもの。さらに踏み込んで「認証フローはハーネス(エージェント実行基盤)の外に出してしまえる可能性すらある」と述べ、「MCPの理想形はAPIのための認証ゲートウェイそのもの、それ以外は何も要らないかもしれない。それでも十分な勝利だ」と結論づけています。
なぜこの視点が重要なのか
MCPは登場以来、「ツール接続の標準プロトコル」「LLMが外部世界とつながるUSB-C」といった文脈で語られてきました。しかしskillsやCLI呼び出しでも、ツール実行という機能自体は実現できます。違いはどこにあるのか——Lynchの指摘は、その差分を「認証の取り回し」に絞り込みます。
エージェントに直接APIキーやOAuthトークンを扱わせれば、それらは必然的にコンテキストウィンドウに乗ります。プロンプトインジェクションでの漏洩、ログ蓄積、誤った権限委譲——リスクは大きい。MCPサーバーが認証を「肩代わり」してくれるなら、エージェント本体は資格情報を一切見ずに済みます。
skillsとの対比から浮かぶ輪郭
Willisonの記事タグにskills(13件)とmodel-context-protocol(27件)が並んでいることからも、両者の比較が継続的な論点であることが伺えます。skillsは「やり方の指示書」、CLIは「実行手段」、MCPは「認証ゲートウェイ」——という役割分担として整理し直すと、各技術の住み分けが見えてきます。
💼 事業会社視点：これは自社にどう効くか
事業会社の視点:MCP導入判断の軸が変わる
この指摘は、社内でMCPサーバー導入を検討している事業会社にとって決定の軸を変える材料です。
SaaS・受託開発の経営者は、自社プロダクトに「MCP対応」を実装する際、機能の網羅性で勝負するのではなく「認証ハンドリングの堅牢さ」を訴求点にすべきです。OAuth、SAML、短命トークンの自動更新——ここで差がつきます。逆に既存APIがあるなら、MCPサーバーは薄い認証ゲートウェイとして実装し、ツールロジックはskillsに寄せる構成が合理的です。
社内エージェント運用を始めた事業責任者は、エージェントに直接APIキーを渡している現行構成を見直すべきタイミングです。情シス・セキュリティ部門と「資格情報をLLMコンテキストに乗せない」原則を共有し、MCPを認証分離レイヤとして再定義することで、監査説明が一気に楽になります。
EC・金融など規制業種では、この設計判断は将来の事故対応コストを左右します。エージェントが万一プロンプトインジェクションで侵害されても、認証情報が分離されていれば被害範囲を限定できる——これは経営報告できるレベルの差です。「全部入りMCP」ではなく「認証だけのMCP」を要件定義に書き込む発想転換が、今期の意思決定で効いてきます。
