Azure AI FoundryでMCPサーバーをエージェントに接続する場合、最初に決めるべきことは「どの認証方式で、誰の権限としてツールを呼び出すか」です。結論から言うと、MCPサーバーがMicrosoft Entra認証に対応しているなら、まずMicrosoft Entra認証を検討し、ユーザーごとの権限を維持したい場合はOAuth IDパススルーを選ぶのが基本です。APIキーやPATを使うキーベース認証は便利ですが、共有シークレットとして扱う前提でアクセス制御とローテーションを設計する必要があります。
本稿では、2026年5月16日時点で確認すべき公式情報として、Azure AI Foundryの「Set Up MCP Server Authentication – Microsoft Foundry」の内容を整理します。なお、Microsoft Learnの該当ページには最終更新日として2026年4月9日が表示されているため、社内の変更管理や監査資料では「参照日」と「公式ページ上の最終更新日」を分けて記録しておくと安全です。(Microsoft Learn)
Azure AI FoundryのMCPサーバー認証で何が変わるのか
Azure AI FoundryのMCPサーバー認証で重要なのは、MCPサーバー接続が単なる「外部ツールのURL追加」ではなく、エージェント、プロジェクト接続、認証方式、ユーザー同意、承認フローを含む設計対象になった点です。
Microsoft Foundry Agent Serviceでは、エージェントがMCPサーバーに接続し、外部ツールやデータソースを呼び出せます。公式ドキュメントでは、MCPサーバーの認証方式として、キーベース認証、Microsoft Entra認証、OAuth IDパススルー、認証なしアクセスが整理されています。多くのMCPサーバーでは、サーバー本体だけでなく、その背後にあるサービスへアクセスするための認証が必要です。(Microsoft Learn)
この変更を実務目線で言い換えると、次のようになります。
| 観点 | これまで見落とされやすかった点 | 今後確認すべきこと |
|---|---|---|
| 接続設定 | MCPサーバーのURLだけを見ていた | server_url、server_label、project_connection_id、認証方式をセットで管理する |
| 権限管理 | エージェントがどの権限で動くか曖昧になりやすい | 共有IDか、ユーザー個別IDかを先に決める |
| シークレット管理 | APIキーを実行時に渡してしまう | 共有資格情報はプロジェクト接続に保存し、アクセスできるユーザーを制限する |
| ユーザー体験 | OAuth同意画面や承認待ちを考慮していない | oauth_consent_requestやmcp_approval_requestをアプリ側で処理する |
| 展開管理 | テスト時のIDと公開後のIDの違いを見落とす | エージェントID、プロジェクトマネージドID、ロール割り当てを展開段階ごとに確認する |
特に本番環境では、「接続できるか」だけでなく、「誰の権限で、どのツールを、どこまで実行できるか」を明確にすることが重要です。
対象者は管理者・開発者・セキュリティ担当の全員
この設定は、開発者だけの作業ではありません。Azure AI FoundryでMCPサーバーを使う場合、管理者、開発者、セキュリティ担当がそれぞれ異なる観点で確認する必要があります。
| 対象者 | 主な確認ポイント | 見落とすと起きやすい問題 |
|---|---|---|
| Azure管理者 | Foundryプロジェクト、RBAC、プロジェクト接続、マネージドID | 接続作成やツール実行に必要な権限が不足する |
| 開発者 | MCPツール設定、OAuth同意リンク、承認要求、エラー処理 | ユーザーが同意しても処理が再開しない |
| セキュリティ担当 | 最小権限、共有シークレット、トークンローテーション、監査 | APIキーの過剰権限や共有範囲の拡大 |
| 運用担当 | 本番展開、障害時の切り分け、トークン期限切れ対応 | 401/403エラーや承認待ちを障害として誤認する |
MCPサーバーを導入するチームは、まず「誰がプロジェクト接続を作成できるか」「誰がエージェントを構成できるか」「どの認証方式を標準にするか」を決めておくべきです。公式情報でも、開始前の前提条件として、Foundryポータルとプロジェクトへのアクセス、プロジェクト接続とエージェント構成の権限、リモートMCPサーバーエンドポイント、選択した認証方式に応じた資格情報が挙げられています。(Microsoft Learn)
認証方式の選び方
Azure AI FoundryのMCPサーバー認証では、主に「共有認証」と「個別認証」のどちらを使うかを決めます。共有認証では、エージェントの利用者全員が同じIDでMCPサーバーにアクセスします。一方、個別認証では、各ユーザーが自分のアカウントで認証し、ユーザーごとの権限やコンテキストを維持します。(Microsoft Learn)
| 認証方式 | 向いているケース | ユーザーごとの権限維持 | 注意点 |
|---|---|---|---|
| キーベース認証 | APIキー、PAT、外部SaaSのトークンで接続する | できない | 共有シークレットとして扱い、プロジェクトアクセスを絞る |
| Microsoft Entra – エージェントID | エージェントごとに異なる権限を持たせたい | できない | 公開前後でエージェントIDの扱いを確認する |
| Microsoft Entra – プロジェクトマネージドID | プロジェクト内の全エージェントで同じ権限を使う | できない | 権限が広くなりすぎないようにする |
| OAuth IDパススルー | ユーザー本人の権限でツールを使わせたい | できる | 同意フロー、テナント条件、ロール条件を確認する |
| 認証なしアクセス | 認証不要の公開MCPサーバーやネットワーク分離前提の内部サーバー | できない | 利用規約、レート制限、公開範囲を確認する |
判断に迷う場合は、MCPサーバーが対応している限りMicrosoft Entra認証から検討するのが現実的です。シークレットを直接管理せずに済み、トークンローテーションも組み込みで扱えるためです。公式ドキュメントでも、不明な場合はMicrosoft Entra認証から始めることが推奨されています。(Microsoft Learn)
ただし、Microsoft Entra認証は「すべての利用者の個別権限を反映する」方式ではありません。たとえば、営業部のユーザーはCRMの一部データだけを見られるが、管理職は全件を見られる、といったユーザー単位の権限制御を維持したい場合は、OAuth IDパススルーを選ぶ必要があります。
キーベース認証で確認すべきこと
キーベース認証は、APIキー、個人用アクセストークン、その他のトークンを使ってMCPサーバーに接続する方式です。外部サービスのMCPサーバーをすばやく検証するには便利ですが、本番利用では最も運用ルールを明確にすべき方式でもあります。
公式情報では、プロジェクトにアクセスできるユーザーは、プロジェクト接続に保存されたAPIキーへアクセスできるため、プロジェクト接続には共有シークレットのみを保存し、ユーザー固有のアクセスにはOAuth IDパススルーを使うよう説明されています。(Microsoft Learn)
キーベース認証を使う場合は、次の点を必ず確認してください。
| 確認項目 | 実務上の判断基準 |
|---|---|
| キーの権限 | 読み取りだけで十分なら書き込み権限を付けない |
| キーの所有者 | 個人アカウントではなく、運用管理された共有アカウントやサービス用資格情報を使う |
| 保存場所 | 実行時に渡さず、プロジェクト接続に保存する |
| ローテーション | 期限、更新手順、更新後の接続テスト担当を決める |
| ヘッダー形式 | Authorization: Bearer <token>なのか、X-API-KeyなのかをMCPサーバー側の仕様で確認する |
失敗しやすいのは、ヘッダー名と値の形式です。たとえば、あるMCPサーバーではAuthorizationヘッダーにBearer <token>が必要でも、別のサーバーではApi-Keyヘッダーにトークン本体だけを渡す場合があります。キーが正しくても形式が違えば、MCPサーバーからunauthorizedが返ります。
Microsoft Entra認証で確認すべきこと
Microsoft Entra認証は、MCPサーバーとその背後のサービスがMicrosoft Entraトークンに対応している場合に使います。Azure Storage、Azure Functions、社内APIなど、Entra IDベースでアクセス制御できる環境では、キーベース認証よりも管理しやすい選択肢です。
Azure AI Foundryでは、Microsoft Entra認証として「エージェントID」と「プロジェクトマネージドID」を使い分けます。エージェントIDは、特定のエージェントにスコープを限定したい場合に向いています。プロジェクトマネージドIDは、プロジェクト内の複数エージェントで同じアクセスレベルを共有したい場合に向いています。どちらの場合も、MCPサーバーの背後にあるサービス側で必要なロール割り当てを行う必要があります。(Microsoft Learn)
特に注意したいのは、エージェントIDの扱いです。公式情報では、公開前のFoundryプロジェクト内ではすべてのエージェントが同じエージェントIDを共有し、エージェントを公開すると一意のエージェントIDを取得すると説明されています。(Microsoft Learn)
そのため、本番展開前には次の確認が必要です。
| タイミング | 確認すること |
|---|---|
| 開発・検証時 | 共有されているエージェントIDに必要なロールがあるか |
| 公開直後 | 公開後の一意のエージェントIDにロールを再付与する必要がないか |
| 権限変更時 | エージェント単位で権限を分けるべきか、プロジェクト単位で統一すべきか |
| 障害発生時 | 401/403が出た場合、MCPサーバーではなく基盤サービス側のRBAC不足を疑う |
「テストでは動いたのに公開後に失敗する」場合は、公開後のエージェントIDに必要なロールが割り当てられていない可能性があります。
OAuth IDパススルーで確認すべきこと
OAuth IDパススルーは、エージェントを使うユーザー本人にMCPサーバーへのサインインと承認を求め、そのユーザーの資格情報でツールを呼び出す方式です。ユーザーごとのアクセス権限を反映したい場合に最も重要な方式です。
たとえば、Microsoft 365、SharePoint、Teams、外部SaaSなどで「ユーザー本人が見られるデータだけをエージェントにも使わせたい」という要件があるなら、共有IDではなくOAuth IDパススルーを検討します。公式情報では、OAuth IDパススルーを使う場合、ユーザーには少なくともFoundry Userロールが必要で、ユーザーのMicrosoft EntraテナントはFoundryプロジェクトのテナントと一致している必要があり、クロステナントのトークン交換はサポートされないと説明されています。(Microsoft Learn)
また、FoundryのRBACロール名は最近変更されており、Foundry User、Foundry Owner、Foundry Account Owner、Foundry Project Managerは、以前はAzure AI User、Azure AI Owner、Azure AI Account Owner、Azure AI Project Managerという名称でした。ロールIDと中核的な権限は変更されていないものの、移行期間中は旧名称が表示される可能性があります。(Microsoft Learn)
OAuth IDパススルーで開発者が見落としやすいのは、同意フローをアプリケーション側で処理する必要がある点です。ユーザーが新しいツールを初めて使う場合、応答内にoauth_consent_requestが含まれ、consent_linkをユーザーに表示する必要があります。ユーザーが同意した後は、前回の応答IDを使って別の応答を送信し、処理を継続します。(Microsoft Learn)
OAuth IDパススルーを使う場合は、次のようなユーザー体験まで設計しておきましょう。
| 場面 | アプリ側で必要な対応 |
|---|---|
| 初回利用時 | consent_linkをユーザーに表示する |
| 同意完了後 | 前回の応答IDを指定して処理を再開する |
| 同意拒否時 | 「このツールを使うには承認が必要です」と分かりやすく表示する |
| 別ユーザーの利用時 | ユーザーごとに同意が必要になることを想定する |
| トークン失効時 | 再同意や再サインインが必要になる可能性を考慮する |
OAuthはセキュリティ上は適切でも、同意画面や再実行の実装が不十分だと、ユーザーには「エージェントが止まった」と見えてしまいます。本番展開前に、初回ユーザー、同意済みユーザー、同意拒否ユーザー、別ユーザーの4パターンで検証しておくと安全です。
MCPツール設定で確認すべきパラメーター
MCPサーバー認証を設定したら、エージェント側のMCPツール設定も確認します。公式ドキュメントでは、mcpツールを使ってエージェントを作成または更新する際、server_url、server_label、require_approval、project_connection_idを指定する流れが説明されています。(Microsoft Learn)
| パラメーター | 役割 | 注意点 |
|---|---|---|
server_url | MCPサーバーのURL | 接続側と異なるURLを指定した場合、接続内のエンドポイントが使われる |
server_label | エージェント内でのMCPサーバー識別子 | 複数MCPサーバーを使う場合は分かりやすい命名にする |
require_approval | ツール呼び出し時の承認要否 | 既定値はalways。意図せず承認待ちになることがある |
project_connection_id | 認証情報やエンドポイントを保持する接続名 | 認証方式と資格情報の管理対象になる |
require_approvalは特に重要です。値を指定しない場合、既定でalwaysとなり、すべての呼び出しに開発者の承認が必要になります。検証環境では安全ですが、本番のユーザー向けエージェントで意図せず設定したままだと、ツール呼び出しが毎回ブロックされたように見えることがあります。
一方で、すべてをneverにするのも危険です。データ削除、外部送信、チケット作成、メール送信など影響が大きいツールでは承認を残し、読み取り系や低リスクな検索系ツールだけ承認不要にする、といった設計が現実的です。
移行・展開時のチェックリスト
既にMCPサーバーを試験導入しているチームは、今回の認証整理を機に、接続設定を棚卸しすることをおすすめします。特に、実行時にトークンを渡している、個人PATを使っている、プロジェクト全員が共有キーへアクセスできる、といった状態は本番運用前に見直すべきです。
| チェック項目 | 確認内容 |
|---|---|
| MCPサーバー一覧 | 利用中・検証中のMCPサーバーURL、用途、所有者を一覧化する |
| 認証方式 | キーベース、Entra、OAuth、認証なしのどれかを明記する |
| 権限モデル | 共有IDでよいか、ユーザー個別権限が必要かを判断する |
| プロジェクト接続 | エンドポイント、認証方式、資格情報が適切に保存されているか |
| ロール割り当て | エージェントIDまたはプロジェクトマネージドIDに必要最小限のロールがあるか |
| OAuth設定 | クライアントID、シークレット、認証URL、トークンURL、更新URL、スコープが正しいか |
| 承認フロー | mcp_approval_requestをアプリや運用で処理できるか |
| 同意フロー | oauth_consent_requestをユーザーに表示し、同意後に処理を再開できるか |
| 障害対応 | 401/403、トークン失効、DNS不通、承認待ちを切り分けられるか |
MCPサーバーを組織内で共有する場合は、組織ツールカタログやカスタムMCPツールとして接続できます。公式情報では、Azure API Centerに登録したMCPサーバーをFoundryポータルから検出・構成できること、カスタムツールとして直接追加する場合は、リモートMCPサーバーエンドポイントと認証方式を指定することが説明されています。(Microsoft Learn)
また、MCPツールの利用範囲も確認してください。別の公式ページでは、allowed_toolsを指定しない場合、既定でMCPサーバー内のすべてのツールが対象になると説明されています。認証だけを正しく設定しても、エージェントが使えるツール範囲が広すぎるとリスクが残ります。(Microsoft Learn)
プライベートMCPサーバーとローカルMCPサーバーの注意点
社内APIや内部システムに接続する場合、パブリックなMCPサーバーではなく、プライベートMCPサーバーを使うケースがあります。Agent Serviceでは、パブリックとプライベートのMCPサーバーエンドポイントがサポートされますが、プライベートMCPにはプライベートネットワークと仮想ネットワーク内の専用MCPサブネットを使うStandard Agentセットアップが必要です。(Microsoft Learn)
ローカルで動かしているMCPサーバーをそのままAgent Serviceに接続することはできません。公式情報では、Agent ServiceランタイムはリモートMCPサーバーエンドポイントのみを受け入れるため、ローカルMCPサーバーを追加したい場合は、Azure Container AppsまたはAzure Functionsでセルフホストしてリモートエンドポイントを用意する必要があると説明されています。(Microsoft Learn)
ローカルMCPサーバーをクラウド化する際の判断基準は次のとおりです。
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| Azure Container Apps | コンテナー化済み、任意の言語スタック、UVX/NPXを使いたい | Linuxコンテナー前提。特権コンテナーは使えない |
| Azure Functions | Functionsベースで軽量に公開したい | Functions用の構成が必要。OSレベル依存や一部の起動コマンドに制約がある |
| プライベートエンドポイント | 社内ネットワーク内のサービスに閉じたい | 専用MCPサブネット、委任、プライベートDNSを確認する |
| パブリックエンドポイント | 外部SaaSや公開MCPサーバーに接続したい | 認証、レート制限、利用規約を確認する |
検証時はパブリックエンドポイントで簡単に始め、本番ではプライベート接続へ移す、という進め方もあります。ただし、その場合は認証方式、URL、DNS、RBAC、承認フローが変わる可能性があるため、単純なURL差し替えで済むとは考えない方が安全です。
よくある失敗と対処法
MCPサーバー認証のトラブルは、エージェントの不具合ではなく、認証方式、ロール、ヘッダー形式、承認フローのいずれかに原因があることが多いです。公式のトラブルシューティングでも、OAuth同意リンクが表示されない、同意後に失敗する、キーベース認証が失敗する、Microsoft Entra認証が失敗する、require_approvalによりツール呼び出しがブロックされる、といったケースが整理されています。(Microsoft Learn)
| 症状 | よくある原因 | 確認すること |
|---|---|---|
oauth_consent_requestが出ない | OAuth IDパススルーとして構成されていない、またはツール呼び出しが発生していない | プロジェクト接続の認証方式と、プロンプトがMCPツールを使う内容か確認する |
| 同意後もツール呼び出しが失敗する | ユーザーが基盤サービスへアクセスできない | ユーザーのサービス側権限とFoundryプロジェクトのロールを確認する |
| キーベース認証が失敗する | キー期限切れ、ヘッダー名違い、値形式違い | キーをローテーションし、AuthorizationやX-API-Keyなどの仕様を確認する |
| Microsoft Entra認証が失敗する | エージェントIDまたはプロジェクトマネージドIDのロール不足 | 基盤サービス側のRBACを確認する |
| ツールが予期せず止まる | require_approvalがalwaysのまま | 承認が必要なツールと不要なツールを分ける |
| プライベートMCPサーバーに到達できない | サブネット、委任、DNS設定の不備 | 専用MCPサブネット、Microsoft.App/environments委任、プライベートDNSを確認する |
| 時間が経つとOAuthが失敗する | 更新URLやリフレッシュトークンの問題 | refresh URLとOAuthプロバイダーの更新仕様を確認する |
運用で特に多いのは、認証エラーを「MCPサーバーが落ちている」と誤解するケースです。401/403が出た場合は、まず資格情報、ヘッダー形式、ロール割り当て、OAuthスコープ、承認状態を順番に確認しましょう。
管理者と開発者が今すぐやるべきこと
Azure AI FoundryでMCPサーバーを使うなら、まず現在の接続を棚卸しし、認証方式ごとに運用ルールを分けることが重要です。すべてをOAuthにする必要はありませんが、「ユーザー本人の権限が必要な処理」と「共有IDでよい処理」を混ぜると、後から権限設計を修正しづらくなります。
次の順序で確認すると、実装と運用の両方で失敗しにくくなります。
| 順序 | 作業 | 完了条件 |
| -: | ———————– | ————————————— |
| 1 | 接続するMCPサーバーを特定する | URL、用途、提供元、利用するツールが分かっている |
| 2 | 共有認証か個別認証かを決める | キーベース・Entra・OAuthの選択理由が説明できる |
| 3 | プロジェクト接続を作成または見直す | エンドポイント、認証方式、資格情報が整理されている |
| 4 | ロールとスコープを確認する | エージェントID、プロジェクトマネージドID、ユーザーに必要最小限の権限がある |
| 5 | require_approvalを設計する | 高リスク操作は承認あり、低リスク操作は必要に応じて承認なしにする |
| 6 | OAuth同意フローを実装する | 初回同意、同意拒否、再実行、別ユーザーの動作を確認済み |
| 7 | 本番展開前に検証する | 認証エラーなしでツール出力が返り、障害時の切り分け手順がある |
Azure AI FoundryのMCPサーバー認証は、エージェント活用を広げるための便利な設定である一方、外部サービスや社内データへのアクセス経路を作る設定でもあります。まずはMicrosoft Entra認証を基本線として検討し、ユーザー単位の権限制御が必要な場面ではOAuth IDパススルーを使い、キーベース認証は共有シークレットとして厳格に管理する。この方針で整理すれば、MCPサーバーを安全に展開しやすくなります。
コメント