安全は、作る側の責任

ここまで4回にわたって、ツール・リソース・プロンプト、そしてサンプリング・通知・ルートという仕組みを見てきました。最後に扱うのは、機能ではなく責任の話です。

仕様は「強制できない」と自分で言っている

MCPの公式仕様には、安全と信頼についてまとめた章があります。そこにある一文が、この章全体の前提になっています。

仕様が掲げている原則は4つです。ユーザーの同意と制御、データのプライバシー、ツールの安全な扱い、そしてサンプリングを人間が統制できること。どれも「こうあるべきだ」という指針であって、破ったら通信できなくなる、という類いの強制ではありません。守るかどうかは、実装する人の手に委ねられています。

この構造は、他の多くの通信規格とは少し違います。通信の形式そのものは厳密に決めながら、その中身をどう安全に使うかは実装側に委ねる。MCPはこの線引きを最初から選んでいて、だからこそ「誰が作ったサーバーか」「誰が作ったクライアントか」を、つなぐ側が意識する必要があります。

サーバー側が引き受けること

MCPサーバーを作る側には、仕様が具体的な義務を挙げています。ツールを提供するなら、入力を検証すること、適切なアクセス制御を持つこと、呼び出しの頻度を制限すること、返す出力を無害な形に整えること。この4つです。

リソースについても、URIを検証すること、機微なリソースにはアクセス制御を持たせることが挙げられています。読み取り専用だからといって、何でも無条件に渡してよいわけではありません。

クライアント（つなぐ側のアプリ)が引き受けること

サーバーを作らず、既存のMCPサーバーをつなぐだけの立場でも、引き受ける責任があります。つなぐ側のアプリが担うのは、主に「人に確かめさせる」役割です。

ルートについても同様です。クライアントは、境界を検証してから公開する責任、パスをたどって範囲外に出ようとする操作を防ぐ責任を負っています。サーバー任せにできる部分ではありません。

ルートは「自動では守られない」を思い出す

前のレッスンで触れたとおり、ルートの境界は仕様上「尊重すべきもの」であって、通信の仕組みが自動で遮断してくれるものではありません。サーバーを作る側は、渡された境界の外に出ようとしていないかを確かめる処理を、自分のコードの中に書く必要があります。

もう一つ、比較的新しく加わった仕組みにも触れておきます。Elicitationと呼ばれるもので、処理の途中でサーバーがユーザーに直接、追加の情報を尋ねられる仕組みです。ただし仕様は、この仕組みを使って機微な情報を求めてはならないと明記しています。便利な機能ほど、使ってよい範囲が狭く区切られているという点は覚えておく価値があります。

やってみよう

演習1：つなぐ前に確かめる

自分がこれからつなぐ予定のMCPサーバーを1つ思い浮かべてください。それは読み取り専用でしょうか、それとも書き込みもできるでしょうか。書き込みができるなら、どんな操作の前に確認を求めてくれるか、つなぐ前に確かめてみてください。

演習2：作るなら最初に何を実装するか

自分がMCPサーバーを作るとしたら、この章のチェックリストの中から、最初に実装すべき安全対策を1つ選んでください。どれを最優先にするかは、そのサーバーが何に触れるかによって変わります。

今日のまとめ

3行で振り返ります。

• MCPの仕様は、安全をプロトコルレベルで強制できないと自ら明記している
• サーバー側は入力検証・アクセス制御・呼び出し制限・出力の無害化を引き受ける
• クライアント側は、実行前に見せる・確認を求める・結果を検証する・記録を残すことを引き受ける

これで、MCPをもっと知るコースは終わりです。つなぐ・使うという入口から、誰が何を選び、誰が何を確かめるかという仕組みの全体まで見てきました。