MCPサーバーが利用者ごとに使えるツールを絞るとき、落とし穴になるのがキャッシュです。権限の強い人向けのツール一覧を共有キャッシュへ入れると、別の利用者に「見えてはいけない道具」が見える可能性があります。2026年7月28日版のMCP仕様は、ツール一覧を接続ではなくリクエストの認可情報で決め、キャッシュ範囲も分離する設計を明記しました。
接続は利用者の境界ではありません
最新版MCPの基本仕様は、プロトコルをステートレスと定義しています。サーバーは同じ接続で届いた過去のリクエストから、クライアントの識別情報や権限を推測してはいけません。必要な情報は各リクエストに含めます。
tools/listについても、返すツール集合を接続ごとに変えたり、同じ接続上の別リクエストの副作用で変えたりしてはいけません。一方で、そのリクエストに提示された認可情報に応じて変えることは認められています。
たとえば、同じMCPサーバーでも次のように返せます。
- 閲覧権限だけのトークン：
search_docs、read_ticket - 更新権限を持つトークン：上記に加えて
update_ticket - 管理者トークン：さらに
delete_project
重要なのは「このTCP接続は管理者用だったはず」ではなく、今回のリクエストが何を許可されているかで毎回判定することです。接続プールやプロキシを使う構成では、接続と利用者が一対一とは限りません。
ツール一覧には2種類のキャッシュがあります
2026年7月28日版では、完了したtools/listの結果にttlMsとcacheScopeを付けることが必須です。
ttlMs：何ミリ秒まで新鮮とみなせるかを示すヒントcacheScope: public：利用者をまたいで共有可能cacheScope: private：同じ認可コンテキスト内だけで再利用可能
全利用者に同じツールを返すならpublicを選べます。しかし、スコープや役割で一覧を絞るならprivateが基本です。仕様は、別のアクセストークンなど異なる認可コンテキスト間でprivateキャッシュを共有してはならないとしています。
ここで怖いのは、認証済みエンドポイントだから安全だと思い、利用者別の一覧へpublicを付けることです。仕様上、publicな結果は最初の認可コンテキストの外へ共有され得ます。認証の有無と、キャッシュを共有してよい範囲は別問題です。
キャッシュは認可の代わりになりません
ツール一覧から危険な操作を隠すことは、モデルの誤選択を減らすうえで有効です。ただし、一覧に表示しないだけでは認可になりません。攻撃者はtools/callを直接送れます。
MCP仕様も、サーバーは各プリミティブに適切なアクセス制御を実装し、cacheScopeだけで不正アクセスを防いではならないとしています。したがって、サーバー側では最低でも次の二段階が必要です。
tools/listで、現在の権限に合うツールだけを返すtools/callでも、対象ツールと引数に対する権限を再検証する
車でいえば、メーター画面から整備モードを隠すのが一覧制御、実際のECUコマンドを拒否するのが認可です。画面を隠しただけで、実行経路まで閉じたことにはなりません。
速さを落とさず安全にする4つの設計
1. キャッシュキーに認可コンテキストを含める
メソッド名とパラメータだけでなく、テナント、利用者、付与スコープ、ポリシーバージョンなど、結果を変える要素を分離します。トークンそのものをログやキー名へ露出させず、安定した内部識別子や安全なハッシュを使うのが実務的です。
2. 権限で変わる結果はprivateにする
迷ったらprivateから始めます。全利用者で同一だと検証できた一覧だけpublicへ昇格させる方が、情報漏えいのリスクを抑えられます。
3. ツール順序を安定させる
仕様は、基礎となる一覧が変わらない限り決定的な順序で返すことを推奨しています。毎回順番が揺れると、LLMへ渡すプロンプトの差分が増え、プロンプトキャッシュのヒット率が下がります。ツール名などで安定ソートすれば、認可分離と効率を両立できます。
4. TTLと変更通知を併用する
TTLは「この時間は絶対に変わらない」という保証ではなく、新鮮さのヒントです。notifications/tools/list_changedを受け取ったら、TTL内でもキャッシュを無効化します。権限変更時にも通知またはポリシーバージョン更新で、古い一覧を残さない設計が必要です。
PL視点では「誰の一覧か」を設計レビューする
レビューで確認すべきなのは、キャッシュを使っているかどうかだけではありません。
- ツール一覧は、どの認可情報で変わるか
- privateキャッシュの「同じ利用者」を何で判定するか
- 権限変更を何秒で反映するか
- 一覧にないツールを直接呼ばれたとき拒否できるか
- ツール順序が毎回変わっていないか
この5点を先に決めると、安全性と応答速度を後付けで争わずに済みます。キャッシュは高速化部品ですが、境界を誤ると権限情報の配布装置になります。
まとめ
MCPのツール一覧は、単なるメニューではありません。利用者が何を実行できるかをモデルへ伝える、認可に近い情報です。ただし、それ自体を認可の代わりにはできません。
- 接続ではなく、各リクエストの認可情報で一覧を決める
- 利用者別の一覧はprivateキャッシュへ分離する
- 実行時にも必ず権限を再検証する
- 安定した順序とTTL・変更通知で効率を保つ
AIエージェントを速くするなら、キャッシュ量より先に「誰と共有してよいか」を設計する。これが、2026年版MCP仕様から読み取れる実装原則です。