MCP認証移行ガイド——APIキーからOAuth 2.1へ

公開されているMCPサーバーの53%が長期間有効なAPIキーや Personal Access Token に依存し、25%は認証自体が存在しない。この調査結果が示すのは、AIエージェントと業務システムが直接つながる時代に、多くのMCP実装がセキュリティ上の盲点を抱えているという事実だ。「とりあえず動く」からと先送りにしてきたAPIキー認証を、MCPが要求するOAuth 2.1へ移行するための実践手順を示す。

MCPサーバーのAPIキー認証はなぜ危険なのか

MCPサーバーの53%がAPIキーに依存しており、漏洩した場合に有効期限のない無期限アクセスが最大リスクとなります。

APIキーは一見シンプルで扱いやすいが、セキュリティ上の構造欠陥がある。最大の問題はアイデンティティの消失だ。APIキーは「誰のツール呼び出しか」を区別しない。Aというユーザーが実行した操作も、Bというユーザーが実行した操作も、同じAPIキーを使えば監査ログ上で区別がつかない。

加えて、APIキーには以下の特性が組み合わさる。

有効期限がない：発行後に明示的に失効させない限り、永続的に有効
粒度がない：ツールごとの細かい権限制御ができない
漏洩リスクが高い：設定ファイルやコードにハードコードされることが多く、Git履歴やログを通じた漏洩事例が後を絶たない

MCPはAIエージェントに業務SaaSへのアクセスを与えるプロトコルだ。CRM・ドキュメント・カレンダーを操作するエージェントのAPIキーが漏洩すれば、攻撃者はそのエージェントと同等の操作権限を永続的に持つことになる。

OAuth 2.1認証の仕組みと移行が必要な理由

OAuth 2.1はPKCEを必須とし、有効期限付きのスコープ制御トークンで、APIキーにはない詳細な権限管理とユーザー紐付けを実現します。

MCPの最新仕様（2026年仕様）は、インターネット経由でアクセスするリモートMCPサーバーにOAuth 2.1の実装を要件として定めている。この変更は任意ではなく、公開MCPサーバーを運用する事業者にとって準拠が必須となる。

OAuth 2.1でMCPが変わる点は3つある。

トークンの有効期限

OAuth 2.1のアクセストークンには有効期限がある。期限切れトークンは自動的に無効化され、リフレッシュトークンを使って再取得する仕組みが要件に組み込まれている。APIキーのような「永続的な認証情報」の概念がなくなる。

ユーザーの文脈保持

トークンにはユーザーのアイデンティティ情報が紐付く。どのユーザーが、どのAIエージェントを通じて、どのツールを呼び出したかを正確に追跡できる。コンプライアンス監査やインシデント対応の基盤になる。

スコープによる細粒度制御

各ツール呼び出しに必要なスコープを定義し、トークン発行時に用途を絞り込める。「カレンダー読み取りのみ許可、書き込みは不可」といった制御がプロトコルレベルで実装できる。

PKCE（Proof Key for Code Exchange）はOAuth 2.1で必須化された安全機構だ。クライアントが乱数（コードベリファイア）を生成し、その派生値（コードチャレンジ）で認可コードを保護する。認可コードを傍受されても、元のベリファイアがなければアクセストークンを取得できない。

APIキーからOAuth 2.1への移行3フェーズ

移行は「現状監査→認可エンドポイント構築→本番切替」の3フェーズに分け、1フェーズ1週間を目安に段階的に進めます。

突然の全面切り替えはリスクが高い。既存のMCPクライアント（Claude Desktopや自社エージェント）への影響を最小化しながら移行するために、次の3フェーズで進める。

フェーズ1（Week 1）：現状監査

まず現在のAPIキー利用状況を棚卸しする。

全MCPサーバーのリスト化：サービス別に使用中のAPIキーを列挙する
権限マッピング：各APIキーが何のツールにアクセスできるかをドキュメント化する
クライアント確認：APIキーを使用しているMCPクライアント（Claude for Work、自社エージェント、MCP Inspector等）を把握する

この段階では変更を加えない。「何がつながっているか」の地図を作ることが目的だ。

フェーズ2（Week 2）：認可エンドポイントの構築

認証基盤を構築する。多くの中小企業にとって現実的な選択肢はマネージド認証プロバイダーの活用だ（詳細は次セクション）。

プロバイダーを選定したら、MCPが要求する3つのエンドポイントを設定する。

/.well-known/oauth-protected-resource：MCPサーバーが認証を要求していることを示すメタデータエンドポイント
/authorize：ユーザーの同意を取得する認可エンドポイント
/token：アクセストークンを発行するトークンエンドポイント

この段階ではAPIキー認証を並行運用し、新規クライアントのみOAuthを使用させてテストする。

フェーズ3（Week 3以降）：本番切替と旧APIキーの廃止

テストが完了したら、既存クライアントをOAuthベースの設定に順次移行する。すべてのクライアントがOAuthに移行したことを確認してから、旧APIキーを失効させる。

失効前には必ず30日間の移行猶予期間を設け、APIキーを使用した接続試行がないことをログで確認する。この「ゼロ接続確認」が完了してから失効させるのが安全な手順だ。

認証プロバイダーの選び方と中小企業の現実解

中小企業にはWorkOS等のマネージドプロバイダーが最適で、既存ユーザー管理を変えずにOAuth 2.1対応を追加できます。

OAuth 2.1の実装を自前で構築するのは現実的ではない。認証サーバーのセキュリティ維持・アップデート・インシデント対応を引き受けることになり、専門人材のいない中小企業には負荷が高すぎる。マネージドプロバイダーを選ぶのが合理的な判断だ。

中小企業に向く主要な選択肢は3つある。

プロバイダー	特徴	中小企業向け評価
WorkOS	既存ユーザー管理に重ねてOAuth追加が可能（Bring Your Own Users）	◎ 最もSMB向け
Cloudflare workers-oauth-provider	Cloudflare Workers上で無料運用可能	○ Cloudflare利用者向け
Keycloak	オープンソース・無料	△ 運用負荷が高い

WorkOSが中小企業に最も向く理由は「既存のユーザー管理システムを維持したまま、MCP用OAuth 2.1を追加できる」構造にある。新たにID基盤を構築し直す必要がなく、既存の社内ユーザーDBとの連携設定だけで完了する。Stytch（Twilioが買収済み）やAuth0（Okta傘下）は買収後の価格変更リスクがあり、長期的なコスト予測が立てにくい。

スコープ設計のコツとして、最初は広めのスコープから始めるのが現実的だ。例えば最初は calendar.read・calendar.write・docs.read のような大まかなスコープを定義し、運用実績が積み上がったら細分化する。完璧なスコープ設計を最初から追求すると移行が滞る。

KuuではAI-Opsサービスを通じて、MCPサーバー認証設計の支援から移行後の監視体制構築まで一括して対応している。APIキーの棚卸しから始まる実践的な進め方については、まず現状を整理することから着手できる。

参考

まとめ

MCPサーバーの認証をAPIキーからOAuth 2.1に移行することは、AIエージェントが業務システムに接続する環境では避けられない要件だ。移行は「現状監査→認可エンドポイント構築→本番切替」の3フェーズに分けることで、既存システムへの影響を最小化しながら段階的に完了できる。WorkOS等のマネージドプロバイダーを活用すれば、認証インフラの専門知識がなくても2週間での完了が現実的な目標になる。

まず始めるべきは棚卸しだ。自社のMCPサーバーが何本のAPIキーで動いているかを把握するだけで、リスクの所在が見えてくる。KuuのAI-Opsサービスでは、MCP認証移行の初期アセスメントから対応まで支援している。現状確認だけでも、お気軽にご相談ください。