Model Context Protocol（MCP）は、AIアプリケーションがファイル、データベース、SaaS、業務ツールへ接続するための共通プロトコルです。接続が標準化されるほど導入は容易になりますが、認証・認可を誤ると、一つのAIクライアントから多くのデータや操作へ到達できる危険があります。特に、別サービス用のトークンをそのまま受け取る「トークンパススルー」は、公式仕様で明確に禁止されています。
本稿では、MCPの2026年7月28日版仕様にある認可とセキュリティ上の考慮事項を基に、トークンの対象確認、PKCE、リダイレクトURI、HTTPS、SSRF、混同代理問題、権限設計を企業向けに解説します。仕様は今後更新される可能性があるため、実装時は利用するSDKと最新版仕様も確認してください。情報は2026年9月5日時点です。
MCP認証で守る対象
MCPでは、クライアントがMCPサーバーへ接続し、サーバーが公開するツールやリソースを利用します。サーバーがGoogle Drive、CRM、データベースなど別の上流サービスへ接続する場合、認証関係は二段になります。利用者からMCPサーバーへの権限と、MCPサーバーから上流APIへの権限を分けて考える必要があります。
最初に保護すべきものはログイン画面だけではありません。誰がどのMCPサーバーへ接続できるか、どのツールを見られるか、どの引数を使えるか、どのデータ行へ到達できるか、書き込みや削除が可能かを制御します。認証は本人確認、認可は許可範囲の決定です。認証済みだから全ツールを使えるという設計は避けます。
AIエージェントでは、利用者が直接ボタンを押さなくてもモデルがツールを選びます。利用者の意図、モデルの判断、外部文書に含まれる不正命令を区別しなければなりません。高リスク操作は、トークンを持っているだけで実行せず、操作内容を示して人の承認を得ます。
トークンのオーディエンスを検証する
アクセストークンには、どのサービスで使うために発行されたかという対象、すなわちオーディエンスがあります。MCPサーバーは、自分自身を対象として発行されたトークンだけを受け入れる必要があります。別API用のトークンを受け取って上流へ転送してはいけません。
オーディエンス検証をしないと、攻撃者が他サービス用に取得したトークンをMCPサーバーへ提示し、意図しない権限として扱わせる可能性があります。また、MCPサーバーが受け取ったトークンを別サービスへそのまま渡すと、監査上の主体が曖昧になり、トークン漏えい時の影響範囲が広がります。
実装では、発行者、オーディエンス、有効期限、署名、必要なスコープをすべて検証します。文字列が存在することだけで認証成功にしてはいけません。複数環境を持つ場合は、本番用トークンが開発サーバーで受理されないよう、対象値と鍵を分けます。
トークンパススルーが禁止される理由
トークンパススルーとは、MCPクライアントから受け取ったアクセストークンを検証せず、または自サーバー向けでないまま、上流APIへ転送する構成です。MCP仕様はこの方法を禁止しています。
第一の問題は、信頼境界が崩れることです。上流サービスは、本来MCPサーバーを信用して発行したものではないトークンを受け取る可能性があります。第二に、ログ上で誰がどの権限を使ったか追いにくくなります。第三に、MCPサーバーがトークンを盗む中継点になり得ます。
正しい構成では、MCPサーバーは自分向けトークンでクライアントを認証し、上流サービスへは別に取得した上流用トークンを使います。OAuthの委任フローやトークン交換が必要な場合も、対象を明示した正式な仕組みを利用します。クライアントが持つ万能トークンを単に横流ししません。
resourceパラメーターの役割
仕様ではOAuthのresourceパラメーターを用い、クライアントがアクセスしようとする保護対象を明示する考え方が示されています。認可サーバーは、そのリソースに限定されたトークンを発行できます。これにより、一つのトークンを複数の異なるMCPサーバーへ使い回す危険を抑えます。
複数のMCPサーバーを運用する組織では、サーバーごとに明確なリソース識別子を持たせます。環境名やURLの正規化を曖昧にすると、似た名前の攻撃サーバーへトークンが発行される可能性があります。登録値と完全一致で確認し、ワイルドカードを広く使わないことが重要です。
リソース限定はスコープ限定と併用します。「どのサーバーへ」と「そのサーバーで何ができるか」は別の軸です。経理MCPへ接続できても、請求書の閲覧と支払確定は同じスコープにしません。
PKCEはS256を使う
公開クライアントやデスクトップアプリでは、認可コードが途中で奪われる攻撃へ備えるため、Proof Key for Code Exchange（PKCE）を利用します。仕様はS256方式を要求します。クライアントはランダムな検証値を作り、そのハッシュを認可要求へ含め、トークン交換時に元の値を提示します。
認可コードだけを盗んだ攻撃者は、元の検証値を持たないためトークンへ交換できません。単純なplain方式は使わず、十分な長さのランダム値を毎回生成します。検証値をログやURLへ出さないことも必要です。
PKCEは利用者を偽サイトへ誘導する攻撃や、端末自体の侵害をすべて防ぐものではありません。state、厳密なリダイレクトURI、TLS、ブラウザー表示の確認と組み合わせます。
リダイレクトURIとstateの検証
OAuth認可後に戻るリダイレクトURIは、事前登録した値と完全一致で照合します。部分一致や前方一致を許すと、攻撃者が似たドメインや追加パスへ認可コードを送らせる可能性があります。開発用のlocalhostと本番URLも分けて登録します。
stateは、認可開始時にクライアントが生成し、戻ってきた値が一致するかを確認するために使います。これにより、別の認可処理を差し込むCSRFを防ぎます。stateには予測できない値を使い、短時間で失効させ、一回使ったら再利用できないようにします。
リダイレクト処理では、エラー時も機密なコードやトークンを画面、解析サービス、Refererへ残さないようにします。OAuthコールバックページへ不要な第三者スクリプトを置かないことも有効です。
HTTPSとローカル接続
本番の認可通信とMCP通信にはHTTPSを使い、証明書を適切に検証します。暗号化されていないHTTPでは、トークン、ツール引数、応答が盗聴・改ざんされる可能性があります。社内ネットワークだから安全という前提は置きません。
ローカル開発ではlocalhostを例外として扱うことがありますが、待受アドレスに注意します。全ネットワークインターフェースへ公開すると、同じネットワーク上の端末から接続される可能性があります。必要ならループバックだけへバインドし、開発用資格情報を本番へ流用しません。
証明書エラーを無視する設定は一時的な検証でも残りやすいため、コードへ恒久化しないでください。社内CAを使う場合は、信頼チェーンと更新手順を端末へ正しく配布します。
短命トークンと更新トークン
アクセストークンは短い有効期限にし、漏えい時の利用可能時間を制限します。長時間動くAIエージェントには更新トークンが必要になる場合がありますが、更新トークンはより強い秘密として保管します。
仕様は更新トークンのローテーションを推奨します。利用のたびに新しい更新トークンへ置き換え、古いものを再利用できないようにすると、盗まれたトークンの同時利用を検知しやすくなります。失効、端末紛失、従業員退職時に関連トークンをまとめて無効化できる仕組みも必要です。
トークンをプロンプトやツール結果へ含めてはいけません。モデルが見える文脈に入ると、回答、ログ、外部ツールへ流出する可能性があります。認証情報はモデル外の実行基盤が付与し、AIには秘密値そのものを見せない構成にします。
混同代理問題への対策
混同代理問題は、信頼されたMCPサーバーが、攻撃者の意図に気付かず自分の権限で上流操作を行う問題です。例えば、利用者が閲覧だけを意図しているのに、外部文書の指示をモデルが読み、MCPサーバー経由で別の場所へデータを送る状況です。
対策は、利用者の同意を具体的な操作へ結び付けることです。「このMCPを許可する」という一度の包括同意ではなく、「顧客Aのファイルを外部Bへ送る」など重要操作の対象と結果を表示します。読み取りと書き込み、内部と外部送信を別スコープにします。
MCPサーバーは、上流APIへ自らの広いサービス権限でアクセスする場合でも、元利用者の権限を超えないようにします。テナントID、所有者、行レベル権限を毎回確認し、ツール引数だけを信用しません。
SSRFと動的クライアント登録
MCP実装が外部URLを取得する場合、Server-Side Request Forgery（SSRF）へ注意が必要です。攻撃者が指定したURLへサーバーがアクセスすると、クラウドのメタデータサービス、社内管理画面、localhostへ到達する可能性があります。
許可するスキームをHTTPSに限定し、DNS解決後のIPも検査し、プライベート・ループバック・リンクローカル範囲を拒否します。リダイレクト先も再検査し、取得サイズと時間を制限します。URLの文字列だけで外部ドメインかを判断してはいけません。
動的クライアント登録を利用する場合は、攻撃者が無制限にクライアントを作成できないよう、登録アクセス、メタデータ検証、レート制限を設けます。クライアント名やロゴを信用表示に使う場合、正規サービスに似せた名称にも注意します。
ツール単位の最小権限
MCPサーバーの認証が正しくても、一つのadminツールが任意操作を受け付ければ危険です。業務操作は、目的が明確な小さなツールへ分けます。例えば「顧客を管理する」ではなく、「顧客を検索する」「下書きを作る」「承認済み下書きを送信する」に分けます。
ツールの引数は型、長さ、許可値、テナントを検証します。SQL、シェル、任意URLをそのまま渡せる引数は避けます。削除や公開は、対象IDと現在状態を取得し、利用者へ確認してから実行します。冪等性キーを使えば、再試行で二重送信や二重請求が起きるのを防ぎやすくなります。
結果にも最小化が必要です。検索ツールが必要以上の個人情報を返すと、モデル文脈やログへ広がります。表示に必要な項目だけを返し、件数上限、ページング、マスキングを設定します。
監査と異常検知
監査ログには、利用者、クライアント、MCPサーバー、ツール、引数の要約、対象リソース、結果、時刻、承認者を記録します。トークンや秘密値、不要な本文は記録しません。相関IDを使い、AIの依頼から上流APIの操作まで追跡できるようにします。
異常検知では、短時間の大量取得、通常と異なるツール組み合わせ、複数テナントへの横断、深夜の権限変更、連続失敗を監視します。検知後に通知するだけでなく、トークン失効、接続遮断、操作保留を自動化する条件を決めます。
ログ自体も機密です。閲覧権限、保存期間、改ざん防止、削除を設計し、監査担当者のアクセスも記録します。
導入時のテスト項目
正常系に加え、期限切れトークン、別オーディエンス、署名不正、スコープ不足、state不一致、リダイレクトURI不一致を試します。すべてが安全に拒否され、トークン内容をエラーへ表示しないことを確認します。
さらに、悪意あるWebページや文書にツール実行指示を埋め込み、モデルが許可外操作を試みないか確認します。SSRF用にlocalhostやクラウドメタデータ相当のURLを指定し、到達できないことをテストします。上流API停止時に、権限の弱い代替経路へ勝手に切り替わらないことも重要です。
SDKや仕様を更新した際は同じ試験を再実行します。標準対応という表示だけでは、実装の設定ミスやバージョン差を検出できません。
まとめ
MCPの認証・認可では、MCPサーバー向けに発行されたトークンだけを受け入れ、上流サービス用トークンと分離することが基本です。トークンパススルーを禁止し、resource、オーディエンス、スコープ、PKCE S256、厳密なリダイレクトURI、state、HTTPSを組み合わせます。
さらに、ツール単位の最小権限、人の承認、SSRF対策、短命トークン、監査、異常時の停止が必要です。Accomplirでは、MCPサーバーの設計・導入、OAuth連携、脅威分析、テスト、監査可能なAIエージェント基盤の構築を支援しています。
よくある質問
MCPサーバーへGoogleなどのアクセストークンをそのまま渡してよいですか
いけません。MCP仕様はトークンパススルーを禁止しています。MCPサーバーは自分向けのトークンでクライアントを認証し、上流サービスには別の正式な委任トークンを使います。
PKCEはplain方式でもよいですか
仕様ではS256を使用します。十分にランダムな検証値を毎回生成し、認可コードと結び付けます。
HTTPSなら安全ですか
HTTPSは必須ですが、それだけでは不十分です。オーディエンス、スコープ、リダイレクトURI、state、ツール権限、SSRF、監査も必要です。
AIへアクセストークンを見せる必要がありますか
ありません。認証情報はモデル外の実行基盤が安全に付与し、プロンプトやツール結果へ秘密値を含めない構成にします。