1,723件のMCPアプリを実測：約3分の2がツール実行前の承認を要求せず

7月28日に公開された実証研究では、GitHubからModel Context Protocol（MCP）を統合した1,723件のアプリケーションを収集し、開発者によるサーバー設定、SDKの選択、人間とエージェントの間におけるコントロールポイントの配置方法を調査した。その結果、81.1%が公式SDKを使用し、85.2%がサーバー設定をファイルに保存しており、MCPの基本的な統合手法が収束し始めていることが示された。一方、設定ファイル名については共通の慣行がまだ形成されておらず、自動検出、移植、セキュリティ監査を難しくしている。

さらに注目すべきなのは、監督メカニズムの非対称性だ。90.8%のアプリケーションがログを記録し、77.2%がサーバーの有効化または無効化を可能にしている一方、ツールが実際に実行される前にブロッキング型の承認を設けているのは37.2%にすぎない。言い換えれば、大半のアプリケーションは事後の追跡が可能で、ツール群全体を一括で無効化することもできるが、ツールが有効な間は通常、モデルがそれを直接呼び出せる。ファイル書き込み、コマンド実行、外部APIへのアクセス権限を持つエージェントにとって、これら3種類の制御は同等ではない。ログでは送信済みのデータを取り消せず、サーバーレベルのスイッチでも、単発の高リスクなパラメーターを制限することは難しい。

公式のMCP仕様は、主にJSON-RPCメッセージ、ライフサイクル、認可、およびサーバーが提供するtools、resources、promptsなどの機能を定義しており、アプリケーションに統一された承認インターフェースや設定形式を義務付けてはいない。このため研究では、クライアント側の慣行も標準化の課題として捉えるべきだと提言している。エンジニアリングチームはまず、ツールごとにリスクレベルを設定し、書き込み、支払い、削除、認証情報に関する操作には同期的な承認を必須とするとともに、呼び出しパラメーターと結果を、機密情報をマスキング可能な監査ログへ記録できる。

ただし、これらの数値をMCPエコシステム全体の実態として直接捉えることはできない。サンプルは公開GitHubリポジトリのみに由来し、分類プロセスにもLLMが使用されているため、非公開の企業向けアプリケーションでは異なる制御が採用されている可能性がある。今後は、新しいステートレス・トランスポートとSDKの更新によって移植可能な権限ポリシーが実現するか、またブロッキング型の承認が単に曖昧なツール名を表示するだけでなく、実際にパラメーターを検証するものになるかを注視する必要がある。