MCP認証とは？詳細ガイド

Model Context Protocol（MCP）を使った開発に時間を費やしたことがあるなら、その強力さをすでにご存知でしょう。MCPは基本的に、AIエージェントがツールと連携し、データにアクセスし、アクションを実行し、実際のシステムに接続するための明確な方法を提供します。 

その力は素晴らしいものですが、大きな責任も伴います。エージェントがファイルを読み取ったり、APIと通信したり、操作をトリガーしたりできるようになった瞬間、それが何を 許可されるべきか を制御する方法が必要になります。ここで、認可がシステム全体の最も重要な要素の1つとなるのです。

MCPクライアントは、ツールを一度呼び出すこともあれば、長い推論ループ中に200回呼び出すこともあります。無害な情報を要求することもあれば、機密情報にアクセスしようとすることもあります。適切な認可がなければ、サーバーはいつ許可し、いつリクエストを拒否すべきか判断できません。AIエージェントの場合、たった一度の誤った「許可」が、意図しないデータ漏洩やアクションの実行につながる可能性があります。

MCPは、2つの懸念事項を分離することで、これを管理しやすくします。認証はクライアントが誰であるかを証明し、認可はそのクライアントが何ができるかを定義します。本記事では、認可がMCPにどのように組み込まれるか、権限モデルの設計方法、どのような標準（OAuth 2.1など）を活用しているか、そしてTrueFoundryのようなプラットフォームが、AIスタックを安全かつスケーラブルに保ちながら、実装をいかに簡素化するかについて解説します。

MCP認可とは？

MCP認可とは、MCPサーバーまたは MCP Gatewayで認証された後、接続されたクライアントが何を行うことを許可されているかを管理するシステムです。認証が「あなたは誰ですか？」と答えるなら、認可は「何にアクセスできますか？」そして「どのようなアクションが許可されていますか？」と答えます。これは、すべてのツール呼び出し、ファイルリクエスト、および操作を、設定した境界内に保つレイヤーです。

MCPにおいて、認可は単一の組み込み機能ではありません。むしろ、各サーバーが自身のセキュリティ要件に基づいて実装する設計パターンです。一部のサーバーはシンプルなアプローチを取り、認証されたクライアントをすべて信頼します。他のサーバーは、特定のツール、フォルダー、API、またはアクションへのアクセスを制御するきめ細かいルールを実装します。MCPは意図的にこの柔軟性を残しており、それは異なる環境が非常に異なるセキュリティ要件を持っているためです。

認可は、サーバーとやり取りするためのルールブックのようなものだと考えることができます。クライアントはディレクトリからの読み取り権限を持つかもしれませんが、書き込み権限は持たないかもしれません。内部APIを呼び出すことは許可されても、特定のパラメーターでのみ許可されるかもしれません。特定のツールセットに制限され、他のツールからは完全にブロックされるかもしれません。これらすべてが認可です。

MCPでこれが非常に重要である理由は、AIエージェントが試行錯誤によって機能を探索することが多いためです。クライアントが実行すべきではないリクエストを試みた場合、サーバーはそれを停止できる必要があります。適切な認可は、プロトコルを破ったりシステムの有用性を制限したりすることなく、その動作をきれいに制御することを可能にします。

MCP認可はどのように機能するのか？

MCPにおける認可は、シンプルな原則に従います。サーバーが何を許可するかを決定し、クライアントはその制限内に留まることが期待されます。その背後には、重厚なフレームワークや複雑なミドルウェアはありません。MCPはリクエストがどのように行き来するかを定義し、その上に独自の権限ロジックを適用します。

クライアントが接続すると、サーバーはそれを認証します。識別が確認された後、認可が引き継がれます。この時点から、すべてのリクエストはサーバーが定義したルールと照合されます。これは継続的なプロセスであり、一度限りの承認ではありません。

基本的な流れは次のとおりです。

• クライアントは、ツールを呼び出したりリソースを読み取ったりするなどのリクエストを送信します。
• サーバーは、クライアントがその特定のアクションを実行することを許可されているかを確認します。
• 許可されている場合、サーバーはリクエストを実行します。
• 許可されていない場合、サーバーは認証エラーを返して適切に拒否します。

AIエージェントは常に予測可能な動作をするわけではないため、このリクエストごとの検証は重要です。エージェントは、コンテキスト、試行錯誤、または多段階の推論に基づいて、異なるアクションを試みる可能性があります。リアルタイム認証により、サーバーはセッションを終了することなく、安全でない、または意図しない操作をブロックできます。

クライアントも安全性の確保に貢献します。優れたMCPクライアントは、サーバーの機能リストを読み取り、その境界外での呼び出しを避けます。これにより、不要な失敗が減り、エージェントがよりスムーズに動作するのに役立ちます。

MCP認証が重要なのはなぜですか？

AIエージェントが現実のシステムや機密データとやり取りする機会が増えるにつれて、そのアクションが安全で、意図的で、ユーザーによって承認されたものであることを保証するために、認証は不可欠になります。

• セキュリティとリスク軽減： 厳格な権限境界を強制することで、AIエージェントがエラー、ハルシネーション、またはプロンプト操作が原因であっても、機密システムにアクセスしたり、有害なアクションを実行したりできないようにします。
  
• データ保護： ユーザーデータ、財務記録、知的財産などの機密情報が、明示的に許可されたエージェントとツールのみがアクセスできるようにします。
  
• 制御とガバナンス： 組織がエージェントの機能を管理し、コンプライアンスおよび規制要件を満たすのに役立つ、明確で監査可能な権限モデルを提供します。
  
• 実行時の安全策： 実行前に、エージェントが提案するアクションが定義された権限と一致することを保証するための検証レイヤーとして機能します。
  
• きめ細かなアクセスを可能にします： スコープ付きの権限を要求および受領することで、AIアシスタントがユーザー固有のタスク（例：メールの検索やカレンダーの管理）を実行できるようにします。
  
• 標準化と相互運用性： AIエージェントが権限を要求および受領するための一貫した方法を確立し、さまざまなAIシステム間での信頼性とセキュリティを向上させます。
  
• エラーと権限昇格の防止： 試行錯誤による探索を制限し、不正な権限拡大を阻止することで、偶発的または連鎖的な障害を軽減します。

MCP 認可 (AuthZ) と認証 (AuthN)

多くの人が認証と認可を混同しがちですが、MCPではそれぞれが全く異なる役割を担っています。最も分かりやすい考え方は次のとおりです。認証は、 誰が クライアントであるかを証明し、認可は 何を そのクライアントができるかを決定します。どちらも重要ですが、解決する問題は異なります。

認証は本人確認です。クライアントがMCPサーバーに接続する際、サーバーは相手が誰であるかを確認する必要があります。これはAPIキー、トークン、またはサーバーが実装する任意のカスタムメカニズムを通じて行われます。そのIDが検証されると、サーバーは将来のすべての決定のための安定した基準点を得ます。

認可はその後に行われます。「あなたは誰ですか？」と尋ねる代わりに、次のように尋ねます。

• このクライアントはどのツールを呼び出せますか
• どのリソースにアクセスできますか
• どの行動をブロックすべきですか
• どのパラメーターが安全と見なされますか

MCPでは、これら2つの層は連携しながらも独立しています。認証方法を認可ロジックに触れることなく入れ替えたり、その逆も可能です。この分離により、開発者は柔軟性を得られ、システム全体をより理解しやすくなります。

なぜこれが重要なのでしょうか？AIエージェントはしばしば動的に振る舞うためです。一度認証されたとしても、その行動は時間とともに変化する可能性があります。認可は、セッション開始時に行われた仮定に依存するのではなく、個々のリクエストすべてを処理する必要があります。

つまり、認証が信頼を確立する一方で、認可は境界を定義します。そしてMCP環境では、エージェントが探索したり即興で行動したりする場合でも安全性を保つシステムを構築するために、両方が不可欠です。

AuthNとAuthZ、その関係性、そして MCPセキュリティにおける重要性について深く掘り下げるには、この洞察に満ちたチュートリアルをご覧ください。

MCPにおけるパーミッションモデル

モデルコンテキストプロトコル（MCP）は、組み込みのパーミッションモデルを定義していません。仕様内に公式なロール、アクセス階層、またはルールカテゴリは存在しません。代わりに、MCPはトランスポート層に焦点を当て、サーバーが認証を有効にすることを選択した場合、OAuth 2.1の慣例に従います。これは、プロトコルが認証の仕組みを扱うものの、パーミッションの具体的な内容を規定するものではないことを意味します。誰が何を行えるかに関する実際のルールは、サーバーの実装に完全に委ねられています。

実際には、MCPにおける認証はOAuthスタイルのスコープを中心に展開されます。サーバーは機能（capabilities）を公開し、各機能は必要なアクセスレベルを表すスコープと紐付けられます。クライアントがリクエストを行うと、サーバーはクライアントのアクセストークンをチェックし、含まれるスコープを検証して、リクエストを続行すべきかどうかを判断します。これが、仕様が直接認めている唯一のパーミッションメカニズムです。

それ以外に、開発者はサーバーが公開する内容に応じて独自のパーミッションロジックを設計します。特定のスコープをチェックしてからツール呼び出しを許可するサーバーもあれば、特定の操作に昇格された権限が必要となるように、異なるスコープの背後にツールをグループ化するサーバーもあります。仕様が意図的にこの部分をオープンにしているため、これらのパターンは多岐にわたります。これにより、MCPは小規模な個人用ツールからエンタープライズサービス、そしてその間のあらゆるものに適合できます。

重要な点は、MCPが認証の構造を提供するものの、パーミッションの整理方法を指示するものではないということです。ルールはあなたが決定します。MCPは、プロトコルがそれらを一貫して強制できることを保証します。

MCP認証フロー

MCPサーバーが機密性の高いツールやリソースを保護する場合、標準化されたOAuth 2.1スタイルの認証フローに依存します。全体的な考え方はシンプルです。サーバーがクライアントに認証を要求し、クライアントが認証の詳細を発見し、ユーザーがアクセスを許可し、その後クライアントは将来のすべてのリクエストに使用できるトークンを受け取ります。MCPは新しいセキュリティシステムを発明するのではなく、実績のあるOAuthの慣例を再利用することで、準拠するクライアントとサーバーが相互に信頼できるようにします。

ディスカバリーと初期チャレンジ

フローはMCPクライアントが接続を試みた瞬間に始まります。認証が必要な場合、サーバーは401 Unauthorizedステータスで応答し、WWW-Authenticateヘッダーを含めます。このヘッダーには、 保護されたリソースのメタデータ （PRM）ドキュメントへのリンクが含まれており、クライアントがどのように認証すべきかを記述しています。これはサーバーが「認証が必要です。ここから始めてください」と伝えているのと同じです。

メタデータディスカバリー

クライアントはPRMドキュメントを取得します。このメタデータは、クライアントがどの認証サーバーを使用すべきか、利用可能なスコープは何かを伝えます。そこから、クライアントは認証サーバーのメタデータ（発行者、トークンエンドポイント、登録エンドポイントなど）を取得することで、その機能を発見します。これらの手順は、OAuth 2.1、RFC 8414、およびRFC 9728の標準に準拠しています。

クライアント登録

この段階で、クライアントは認証サーバーに登録されている必要があります。事前に登録されている場合もあれば、動的クライアント登録（RFC 7591）を通じて動的に自身を登録することもできます。どちらも利用できない場合、ユーザーは手動でクライアントクレデンシャルを提供する必要があります。

ユーザー認証

登録が完了すると、クライアントはユーザーを認証エンドポイントに誘導します。ユーザーはログインし、スコープに同意すると、認証サーバーは認証コードを返します。クライアントはこのコードをアクセストークン、そして通常はリフレッシュトークンと交換します。

認証済みリクエスト

クライアントが有効なトークンを取得すると、Authorizationヘッダーを使用して各リクエストにそれを付与します。MCPサーバーはトークンを検証し、そのスコープとオーディエンスをチェックし、その後初めてリクエストを処理します。この時点で、クライアントは完全に認証されており、付与されたパーミッションに従ってサーバーとやり取りできます。

クライアントサイド認証

MCPにおけるクライアントサイド認証とは、MCPクライアントが保護されたMCPサーバーに接続する際に、認証クレデンシャルをどのように発見し、要求し、保存し、使用するかに関するものです。クライアント側の責任は、 決定する 権限だけでなく、サーバーが要求するOAuth 2.1ベースのフローに正しく従い、すべてのリクエストに有効なトークンを付与することです。

クライアントが保護されたMCPサーバーにアクセスすると、サーバーは401ステータスで応答し、その保護リソースメタデータ（PRM）へのポインタを提供します。クライアントはこのメタデータを取得し、どの認証サーバーがサポートされているかを把握し、その後、認証サーバー自身のメタデータを取得する必要があります。これにより、クライアントは認証、トークン交換、およびオプションの動的クライアント登録に必要なエンドポイントを得ることができます。

その時点で、クライアントは事前登録されたクレデンシャルを使用するか、認証サーバーがサポートしている場合は動的クライアント登録を実行します。 

登録が完了すると、クライアントは標準のOAuth PKCE付き認可コードフローを開始し、ユーザーにログインと要求されたスコープへの同意を促します。

アクセストークンを受け取った後、クライアントはすべてのMCPリクエストのAuthorizationヘッダーにそれを埋め込みます。クライアントはトークンの有効期限も追跡し、必要に応じてトークンを更新し、有効なトークンなしでリクエストを送信してはなりません。これにより、MCPサーバーはすべての操作に対してアクセス制御を正しく適用できます。

MCPにおける認可メカニズム

MCPは独自の認可フレームワークを考案していません。その代わりに、クライアントとサーバー間の認可を処理するために、主にOAuth 2.1および関連仕様といった確立された標準に依拠しています。これは意図的なものです。MCPはプロトコルをシンプルに保ち、セキュリティを実績があり広く採用されているメカニズムに委ねています。

中核となるメカニズムは、PKCE付きOAuth 2.1認可コードフローです。MCPサーバーが認可を要求する場合、クライアントは認可サーバーからアクセストークンを取得する必要があります。トークンは、ユーザーが付与した権限をOAuthスコープを通じてエンコードしたものです。MCPサーバーはOAuthリソースサーバーとして機能します。各リクエストにはAuthorizationヘッダーに有効なBearerトークンを含める必要があり、サーバーは操作を処理する前にそのトークンを検証する必要があります。

トークンによって適用される内容

• クライアントにどのスコープが付与されているか
  （例：サーバーがmcp:toolsスコープを定義している場合）
• トークンがアクティブで、有効期限が切れていないか
• トークンがこの特定のMCPサーバー向けであるか

OAuth以外にも、MCPはRFC 9728（保護リソースメタデータ）やRFC 8414（認可サーバーメタデータ）などの標準も参照し、クライアントが認可の仕組みを理解するのに役立てています。

不十分な認可によるセキュリティリスク

MCPサーバーにおける脆弱な認可は、静かに深刻なセキュリティ問題を引き起こす可能性があります。MCPサーバーはAIエージェントがトリガーできるツール、リソース、または操作を公開することが多いため、保護が不十分なエンドポイントは、意図しないアクセスやアクションにつながる可能性があります。

最も一般的なリスクは以下の通りです。

• データ漏洩： スコープやアクセスチェックが誤って設定されている場合、クライアントは本来アクセスを許可されていないファイル、API、またはユーザー固有のデータにアクセスしてしまう可能性があります。
• 不正な操作： エージェントは、許可なくデータを変更したり、リクエストを送信したり、ワークフローをトリガーしたりするツールを呼び出す可能性があります。
• トークンの悪用： オーディエンス、スコープ、または署名を検証せずにトークンを受け入れると、攻撃者が認証情報をリプレイまたは再利用できるようになります。
• 権限昇格： チェックが不足していると、通常のクライアントが管理操作や影響の大きい操作を実行できてしまう可能性があります。

これらのリスクをインフラストラクチャ層で軽減するには、以下を実装できます。 ランタイムガードレールを備えたエンタープライズAIセキュリティ MCP環境内で。たった1つの設定ミスのあるルールでもMCPサーバー全体が危険にさらされる可能性があるため、厳格なリクエストごとの認可が不可欠です。

Key Metrics for Evaluating Gateway

Criteria	What should you evaluate ?	Priority	TrueFoundry
Latency	Adds <10ms p95 overhead for time-to-first-token?	Must Have	✅ Supported
Data Residency	Keeps logs within your region (EU/US)?	Depends on use case	✅ Supported
Latency-Based Routing	Automatically reroutes based on real-time latency/failures?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported

MCP Gateway Evaluation Checklist

A practical guide used by platform & infra teams

MCP認可のユースケース

MCPサーバーがすべてのクライアントに自由にアクセスされるべきではない機能を公開する場合、認可は不可欠になります。一般的なユースケースは、ユーザー固有のデータを保護することです。 

例えば、MCPサーバーがメール、ドキュメント、またはプライベートデータベースへのアクセスを提供する場合は、OAuthベースの認可により、正しいユーザーまたはクライアントのみがそれらのエンドポイントに到達できることが保証されます。もう1つの強力なユースケースは、異なる社内アプリケーションやチームが同じMCPサーバーに接続するエンタープライズツールへのアクセスです。 

認可により、サーバーはどのクライアントがどのツールを使用できるかを強制できます。特に、一部のツールが管理操作や影響の大きい操作をトリガーする場合には重要です。MCP認可は、監査可能性と使用状況制御にも役立ちます。リクエストをIDとスコープに紐付けることで、組織はアクティビティを追跡し、最小権限アクセスを強制し、偶発的または不正な操作を防ぐことができます。

MCP認可のベストプラクティス

MCP認可を安全に実装するには、単にフローに従うだけでは不十分であり、悪用を防ぎ、データを保護し、AIエージェントとクライアント全体で予測可能な動作を保証するベストプラクティスを採用することが不可欠です。

• 実績のある認可ライブラリを使用する： 定評のあるOAuthおよびセキュリティライブラリを使用してMCP認可を実装します。わずかなミスが深刻な脆弱性につながる可能性があるため、カスタムのトークン解析または検証ロジックは避けてください。
  
• すべてのアクセストークンを厳密に検証する： デフォルトでトークンを信頼しないでください。ツールやリソースへのアクセスを許可する前に、常にその署名またはイントロスペクションステータス、有効期限、意図されたオーディエンス、および必要なスコープを確認してください。
  
• 短命なトークンで最小権限を適用する： MCPツールやアクションに直接マッピングされるようスコープを厳密に定義したアクセストークンを発行し、トークンが侵害された場合の被害を最小限に抑えるため、有効期限を短く設定してください。
  
• 安全な転送と認証情報管理: すべてのプロダクション通信にHTTPSを必須とし、認証情報を役割（サーバーとユーザー向けクライアント）ごとに分離し、シークレットは安全なシークレット管理システムにのみ保存してください。
  
• 明確な認可境界を強制する: マルチテナンシーが明示的に設計されていない限り、MCPサーバーを特定の認可レルムまたはテナントにバインドしてください。他のレルムや環境向けに発行されたトークンは拒否します。
  
• エラーとログを安全に処理する: アクセストークン、認可コード、シークレットは決してログに記録しないでください。クライアントには最小限のエラー情報のみを返し、内部的には相関IDを使用して詳細な診断情報を記録します。
  
• セッション識別子を非権威的なものとして扱う: アクセス制御にセッションIDを依存しないでください。それらを信頼できない入力と見なし、認可状態が変更されたら再生成し、そのライフサイクルを安全に管理してください。

TrueFoundry上のMCPにおける認可の実装

TrueFoundryの AI Gateway を使用してMCPサーバーを実行する場合、認可はサーバーの登録方法と公開方法に直接組み込まれています。その流れはシンプルです。Gatewayでサーバーを設定し、受信リクエストをどのように認証するかを選択し、どのユーザーまたはチームがアクセスを許可されるかを割り当てます。その後、すべての権限チェックは自動的に行われます。

このプロセスは、サーバーグループを作成し、プロバイダーアカウントの下にMCPサーバーを追加することから始まります。セットアップ中に、サーバーが使用すべき認証方法を選択します。TrueFoundryは、認証なし、ヘッダー認証、OAuth2、動的クライアント登録などのオプションをサポートしています。サーバーが追加された後、どのユーザーまたはチームがそれにアクセスできるかを指定します。これがGatewayが強制する認可ポリシーとなります。

クライアント側では、ベアラートークンを介してアクセスが行われます。Gatewayエンドポイントにリクエストを行う際、パーソナルアクセストークンまたは仮想アカウントトークンのいずれかを使用します。トークンは呼び出し元のIDを表し、GatewayはMCPサーバーにリクエストを転送する前にそれを検証します。コードでは、統合識別子を使用してMCPサーバーを参照し、呼び出したいツールをリストアップし、ヘッダーにトークンを含め、通常通りリクエストを発行します。

TrueFoundryは、トークンの検証、アクセス権の確認、および認可された呼び出し元のみがMCPツールや操作をトリガーできるようにする処理を行います。TrueFoundry MCPゲートウェイがAuthNおよびAuthZワークフローをどのように処理するかについての詳細な説明は、以下のガイドを参照してください TrueFoundry AI Gatewayにおける認証とセキュリティ。

まとめ

認可は、安全で信頼性の高いMCPベースのシステムを構築する上で最も重要な要素の一つです。それは、AIエージェントが実行できるすべてのツール呼び出し、リソースリクエスト、および操作の境界を定義します。明確なID、適切に定義された権限、および適切な検証を組み合わせることで、機能性を制限することなくMCPサーバーのセキュリティを確保できます。標準のOAuthフロー、ローカル認証情報、またはTrueFoundryのAI Gatewayのようなプラットフォーム機能を使用しているかどうかにかかわらず、強力な認可こそが、強力なMCP統合を本番環境対応のシステムへと変えるものです。

AIエージェントをエンタープライズグレードのMCP認証で保護する準備はできていますか？ デモを予約する そして、TrueFoundryがLLMアプリケーションのアクセス制御の複雑さをいかに簡素化するかをご覧ください。

よくある質問

MCP認証の例を教えてください。

MCP認証の例としては、AIエージェントが保護されたツールを介してユーザーのカレンダーへのアクセスを要求するケースが挙げられます。MCPサーバーはきめ細かな権限を適用し、エージェントが明示的に許可されたイベントのみを読み書きできるようにすることで、偶発的なデータ漏洩や不正な操作を防ぎます。

MCPには認証機能がありますか？

はい、MCPサーバーの認証はOAuth 2.1スタイルの認証および認可フローに依存しています。MCPサーバーはクライアントに認証を要求し、保護されたリソースメタデータ（PRM）の検出を案内し、適切なユーザーの同意が得られた後にのみトークンが発行されることを保証します。これにより、機密性の高いAIツールやリソースへの安全なアクセスが提供されます。

MCP認証の方法と種類にはどのようなものがありますか？

MCP認証の方法には、PKCE付き認可コードフロー、トークンイントロスペクション、動的クライアント登録が含まれます。種類は通常、ツールまたはアクションによってスコープが設定され、最小権限アクセスをサポートします。これらの方法により、MCPサーバーはAIエージェントに対して正確な権限を適用し、APIや保護されたリソースとの安全なやり取りを保証します。

MCP認証では、通常どのような種類の権限やロールが必要ですか？

MCP認証のロールと権限は通常、AIエージェントがどのツール、データ、またはアクションにアクセスできるかを定義します。例としては、カレンダーへの読み書きアクセス、メールの検索権限、API固有のスコープなどがあります。ロールは最小権限アクセスを適用するのに役立ち、エージェントがユーザーまたは管理者によって設定された境界を超えることがないようにします。

MCP認証は従来のAPI認証メカニズムとどう異なりますか？

MCP認証は、AIエージェントと動的でユーザー承認済みのアクセスに焦点を当てることで、従来のAPI認証とは異なります。標準的なAPIキーとは異なり、OAuth 2.1フロー、PKCE、およびPRMメタデータを使用して、リクエストごとの最小権限アクセスを適用します。このアプローチにより、誤用、データ漏洩、AI駆動型アクションの不正な実行が防止されます。