MCPサーバーをAPI Managementで守る - 従量課金プランで低コスト＆セキュアな認証ゲートウェイ -

こんにちは！DXソリューション営業本部の大和矢です。

MCPサーバーをクラウドで公開するとき、「認証をどうするか」は避けて通れない課題ですよね。
誰でもアクセスできてしまう状態では、業務で使うMCPサーバーとして安心して運用できません。

Azure API ManagementをMCPサーバーの前段に置いて、Entra IDによるJWT認証でアクセスを制御する構成を検証しました。
今回はConsumption tier（従量課金プラン）を採用し、低コストかつセキュアにMCPサーバーを保護するアーキテクチャを紹介します。

全体アーキテクチャ

今回の構成の全体像は以下の通りです。クライアントからMCPサーバーまでの間にAPI Management（Consumption tier）をゲートウェイとして配置し、認証・認可を一元管理しています。

大きな流れとしては、以下の3ステップです。

1. クライアントがJWTを取得：Entra IDで認証し、MCPサーバー宛のアクセストークンを取得する
2. API Managementがトークンを検証：JWTの署名・有効期限・発行者・audienceを検証し、不正なリクエストを遮断する
3. API ManagementがFunction Appに転送：マネージドIDの別トークンを使い、正規ルートからのリクエストであることを証明してFunction Appに転送する

ポイントは、クライアントの認証とバックエンドの保護を別々の仕組みで行っていることです。この分離により、それぞれを独立して管理・変更できるようになっています。

なぜConsumption tierなのか

API Managementには複数のtier（価格プラン）がありますが、今回Consumption tierを選んだ主な理由は以下の通りです。

• 従量課金で低コスト：100万リクエスト/月まで無料で利用でき、使った分だけの課金
• インスタンス作成が高速：約2分で作成が完了し、すぐに利用開始できる
• SLA 99.95%：運用レベルの可用性が保証されている

一方で、Consumption tierには注意点もあります。
コールドスタート（一定時間リクエストがないとインスタンスが停止し、次のリクエスト時に数秒の遅延が発生する）という特性があります。
また、SSE（Server-Sent Events）には非対応のため、通信方式はStreamable HTTPに限定されます。
利用頻度が高ければコールドスタートは発生しにくくなりますが、これらの制約が許容できるかは検討が必要です。

2段階JWT認証の仕組み

今回の構成では、APIゲートウェイの一般的なパターンに沿って2つの異なるJWTを使い分けています。

第1段階：クライアント → API Management

クライアントはEntra IDで取得したJWT①（ユーザーのアクセストークン）をAuthorizationヘッダーに付けてリクエストを送信します。API Managementはこのトークンの署名・有効期限・発行者・audienceを検証し、正規のユーザーからのリクエストであることを確認します。

第2段階：API Management → Function App

API Managementは、ユーザーのJWT①をJWT②（マネージドIDのトークン）に差し替えてFunction Appに転送します。Function App側では、このJWT②を検証することで「API Management経由の正規ルートからのリクエストか」を判定します。

マネージドID認証によるバックエンド保護

バックエンドのFunction Appを保護する方法として、今回はマネージドID認証を採用しています。

マネージドIDとは

マネージドIDは、Azureリソースに自動的に付与される「身分証」のようなものです。人間がパスワードやキーを管理する必要がなく、Azureが内部でトークンの発行・管理を自動的に行うため、キー漏洩のリスクがなく、トークン偽造も事実上不可能です。

この仕組みにより、Function AppのURLを直接叩いてもマネージドIDのトークンがないため401エラーで弾かれ、API Management経由でしかアクセスできない状態になります。

ユーザー情報の引き継ぎ

2段階JWT認証には1つ課題があります。ユーザーのJWTがAPI ManagementでマネージドIDのトークンに差し替えられるため、Function App側ではユーザーが誰なのかわからないという点です。

この問題を解決するために、API ManagementのポリシーでJWTが差し替えられる前にユーザー情報をカスタムHTTPヘッダーに退避して、Function Appに転送する仕組みを実装しています。

流れとしては以下の順序です。

1. API ManagementがユーザーのJWTを検証する
2. 検証済みJWTからユーザー情報（メールアドレス、オブジェクトIDなど）を読み取り、カスタムヘッダーに設定する
3. AuthorizationヘッダーをマネージドIDのトークンに差し替える
4. Function Appはカスタムヘッダーからユーザー情報を取得する

この設計のポイントは、ヘッダーの退避をトークン差し替えの前に行うことです。順序を間違えるとユーザー情報が失われてしまうため、ポリシーの配置順序が重要になります。

検証：Foundryからの呼び出し

実際にAzure AI FoundryからMCPサーバーに接続し、ツール呼び出しを試してみます。API Management（Consumption tier）を経由して、認証が正しく機能しているか確認します。

ユーザー情報取得ツールの呼び出し

Foundryに接続し、MCPサーバーに用意したwhoamiツールを呼び出してみます。API Managementが転送したカスタムヘッダーから、認証したユーザーのName・メールアドレス・ObjectIdが正しく取得できていることが確認できます。

画面上部には「サインインに成功しました」と表示されており、Entra IDによる認証が完了していることがわかります。その状態でツールを呼び出すと、API Managementが設定したカスタムヘッダー経由でユーザー情報がMCPサーバーに届き、正しく返却されています。

まとめ：低コストとセキュリティの両立

今回の検証で、API ManagementのConsumption tierでMCPサーバーのJWT認証が正常に動作することを確認できました。

改めて、今回の構成のポイントを整理します。

• 低コスト：
  従量課金で100万リクエスト/月まで無料、インスタンス作成も約2分
• 2段階JWT認証：
  クライアント認証とバックエンド保護を分離し、それぞれ独立して管理できる設計
• マネージドID認証：
  キー管理不要かつ堅牢なバックエンド保護を実現
• ユーザー情報の引き継ぎ：
  カスタムヘッダーを使って、トークン差し替え後もFunction App側でユーザーを識別可能に

Consumption tierにはコールドスタートの遅延や他tierへのアップグレード不可といった制約もあります。しかし、検証用途や利用頻度がそこまで高くないケースであれば、コストと機能のバランスに優れた選択肢と言えるでしょう。

次の記事では、この構成をベースにGraph APIを組み合わせることで、ユーザーの詳細プロファイル（役職・部署など）まで取得できるようにした拡張構成を紹介します。

※このブログで参照されている、Microsoft、Azure、Azure API Management、Azure Functions、Entra ID、Microsoft Graph APIは、Microsoft Corporationの米国およびその他の国における商標または登録商標です。