手順6：PRM（Protected Resource Metadata）を有効化する
Anthropicの仕様では、MCPサーバーはProtected Resource Metadata（PRM）を提供することが必須（MUST）です。
MCPクライアントはPRMを参照して、以下を機械的に判断します。
- このMCPサーバーの認証要件は何か
- どのAuthorization Server（AS）に対して認可フローを開始すべきか
- どのスコープが必要そうか
PRM のエンドポイントはwell-knownとして/.well-known/oauth-protected-resourceが使われます。
Azure App Serviceの場合、MCPサーバー向けのPRMを有効にするために、環境変数を追加します。
App Serviceの「環境変数」ブレードから以下を追加して保存します。
-
名前：
WEBSITE_AUTH_PRM_DEFAULT_WITH_SCOPES -
値：承認済みスコープ（例：
api://<アプリ ID>/user_impersonation）
参考：Microsoft Entra 認証を使用して Visual Studio Code から Azure App Service へのモデル コンテキスト プロトコル呼び出しをセキュリティで保護する
PRMが見えることを確認する
ブラウザで次のURLにアクセスし、JSONが返ってくることを確認します。
https://<your-app-service-name>.azurewebsites.net/.well-known/oauth-protected-resource
動作確認としては次の2点を見ておくと切り分けが速くなります。
-
authorization_serversに、想定しているAuthorization Server（Entra ID側）が入っている -
scopes_supported（または同等の項目）に、WEBSITE_AUTH_PRM_DEFAULT_WITH_SCOPESで設定したスコープが含まれている
手順7：VS Code（GitHub Copilot）から動作確認する
最後に、VS CodeからMCPサーバーへ接続します。
VS Codeを開き、Control+Shift+P（Macの場合はCommand+Shift+P）でコマンドパレットを開き、「MCP: Add Server...」を選択してサーバーを追加します。
-
サーバータイプ：
HTTP -
サーバーURL：
https://<your-app-service-name>.azurewebsites.net/mcp/stream - サーバー名：任意
- ターゲット：Workspace
<your-app-service-name>はazd upの出力にあった値を使ってください。
フォルダに.vscode/mcp.jsonが作成され、MCPサーバーが追加されます。
サーバー名の上に表示される「Start」を押下すると、Entra IDのサインイン画面が表示されます。サインインを完了するとMCPサーバーに接続され、ツール呼び出しができるはずです。
「Start」を押下すると、Entra IDのサインイン画面が表示されます。
天気予報に関するプロンプトを入力して実行し、MCPサーバーから応答が返ってくることを確認します。
よくある詰まりどころ（最小トラブルシュート）
| 症状 | ありがちな原因 | まず試すこと |
|---|---|---|
| VS Codeでサインインが進まない／画面が出ない | 同意（consent）が未作成、組織ポリシーで同意が抑止 | 手順4の/.auth/login/aadで同意を作る。組織テナントなら管理者に確認 |
/.well-known/oauth-protected-resourceが404／空 |
PRM設定が未反映、環境変数の値が誤り | 手順6の環境変数を見直し、保存後に数分待って再確認 |
| VS Codeは接続できるがInspectorは401 | client_id制限（pre-registration）でInspectorが許可されていない | 手順5の方針どおりの挙動。Inspectorも許可するならclient_idを追加 |
| ずっと401が返る | 認証は通ったがスコープが許可されていない、クライアントが許可リスト外 | 手順5-2（APIの公開）でクライアントと承認済みスコープを再確認 |
MCP Inspectorから接続できない理由
ついでにMCP Inspectorから接続できないことも確認しておきましょう。MCP Inspectorから接続を試みると、401エラーが返ってきます。
これは、「MCP Inspectorが悪い」のではなく、今回の認可設定が "VS Codeのclient_idだけを許可する" という事前登録（pre-registration）寄りの構成になっていることが原因です。
-
今回は、許可されたクライアントアプリケーションにVS Codeの
client_idしか入れていません -
そのため、別
client_idを使うクライアント（例：MCP Inspector）からのアクセスは拒否されます
また、現在のApp Serviceの認可設定ではDCRは使われていません。逆にMCP Inspector側はDCRを強制しており、認可コードフローが完了しないことも理由の一つです。
じゃあ、App Service側の組み込み認証がDCRに対応していないのが悪いのか、というとそうではありません。AnthropicのMCP Authorization仕様ではDCRは必須ではない旨が以下のように明記されています。
MCP clients and authorization servers SHOULD support OAuth Client ID Metadata Documents as specified in OAuth Client ID Metadata Document. This approach enables clients to use HTTPS URLs as client identifiers, where the URL points to a JSON document containing client metadata. This addresses the common MCP scenario where servers and clients have no pre-existing relationship.
つまり、MCPの世界では「どのクライアント登録方式を採るか」に幅があり、サーバー側の方針（許可したいクライアントの範囲）とクライアント側の実装（どの方式を優先するか）の組み合わせで、接続できたりできなかったりします。
後片付け（推奨）
検証が終わったら、作成したAzureリソースを削除してコストを止めます。
azd down
まとめ
本記事では、MCPサーバーをインターネット上で動かし、認証・認可を付けた状態でクライアント（VS Code／GitHub Copilot）から安全に接続するところまでを一通り確認しました。
-
azdでMCPサーバーをAzure App Serviceにデプロイできた - App Serviceの組み込み認証（Easy Auth）で未認証アクセスをブロックできた（＝認証の導入）
- 許可するクライアントやスコープを絞ってアクセス範囲を制御できた（＝認可の導入）
- 最後にVS Codeから接続して、ツール呼び出しまで動作確認できた
次回は、より実運用に寄せて「スコープ設計」「監査／ログ」「公開時のセキュリティ考慮」などを扱う予定です。
