Azure AI Foundryの認証と承認で今すぐ押さえるべき結論は、本番環境ではAPIキー中心の設計から、Microsoft Entra ID、RBAC、マネージドIDを前提にしたキーレス認証へ寄せるべきという点です。公式ドキュメント「Authentication and authorization in Microsoft Foundry」では、Foundryの操作をコントロールプレーンとデータプレーンに分け、それぞれに適切なRBACを割り当てる考え方が整理されています。Microsoftは本番ワークロードではMicrosoft Entra IDの利用を推奨し、APIキーは迅速な評価や限定的なテスト用途に向くものとして位置付けています。(Microsoft Learn)
特に管理者・開発者が確認すべきポイントは、APIキーでは対応できない機能があること、FoundryのRBACロール名が「Azure AI User」などから「Foundry User」などへ移行中であること、そして自動化スクリプトではロール名ではなくロール定義IDを使うべきことです。英語版の公式ページは2026年5月12日付で更新されており、日本語版では更新日やロール名の反映に差が残っているため、移行判断では英語版の最新情報とロールIDを照合するのが安全です。(GitHub)
結論：Azure AI Foundryの本番認証はMicrosoft Entra IDを標準にする
Azure AI Foundryで本番アプリ、社内業務システム、顧客向けAI機能、エージェント機能を運用するなら、認証方式はMicrosoft Entra IDを標準にすべきです。
APIキーは実装が簡単ですが、ユーザー単位の追跡や細かな権限制御ができません。キーを持っている主体が誰なのかを区別しにくく、漏えい時にはキーのローテーションが必要になります。一方、Microsoft Entra IDでは、条件付きアクセス、MFA、Just-In-Timeアクセス、マネージドID、RBACによる最小権限設計を組み合わせられます。(Microsoft Learn)
実務では、次のように切り分けると判断しやすくなります。
| 利用シーン | 推奨される認証方式 | 判断の理由 |
|---|---|---|
| 個人検証、短期PoC、孤立したテスト環境 | APIキーも可 | 実装が早い。ただし期限、保管場所、ローテーション手順を決める |
| 本番アプリケーション | Microsoft Entra ID | RBAC、監査、条件付きアクセス、マネージドIDを使える |
| Azure上で動くFunctions、App Service、VM、AKSなど | マネージドID + RBAC | アプリにシークレットを持たせずに済む |
| CI/CDや自動化パイプライン | サービスプリンシパルまたはマネージドID | APIキーより権限範囲と失効管理を設計しやすい |
| Agents、Evaluations、Toolboxを使う構成 | Microsoft Entra ID | 公式の機能マトリックス上、APIキーでは対応しない機能がある |
何が変わるのか：変更点というより「運用ルールの明確化」が重要
今回の公式情報は、単に認証方法を列挙したものではありません。Azure AI Foundryを企業で安全に使うための運用ルールを明確にした内容と捉えるべきです。
| 確認ポイント | 公式情報で整理された内容 | 実務への影響 |
|---|---|---|
| 認証方式 | Microsoft Entra IDとAPIキーをサポート | 本番はEntra ID、APIキーは検証用途に限定する方針が立てやすい |
| 権限制御 | コントロールプレーンとデータプレーンを分離 | リソース管理者とAI機能利用者を分けて権限設計できる |
| 機能対応 | Agents、Evaluations、ToolboxなどはEntra ID前提 | APIキーだけで設計した構成は将来の拡張で詰まりやすい |
| ロール名 | Foundry Userなどへリネーム中 | 旧名がポータルや日本語ドキュメントに残る可能性がある |
| 自動化 | ロール名ではなくGUID利用が推奨 | Terraform、Bicep、Azure CLI、CI/CDで名前解決の揺れを避けられる |
| 移行 | 全呼び出し元をトークン認証へ移した後、キー認証を削除 | いきなりローカル認証を無効化すると既存アプリが停止する |
公式ドキュメントでは、コントロールプレーンはAzure RBACのactions、データプレーンはdataActionsに関連付けられると説明されています。つまり「Azureポータルでリソースを作れる人」と「SDKからモデル推論やエージェントを実行できる人」は、同じ権限である必要はありません。(Microsoft Learn)
コントロールプレーンとデータプレーンを分けて理解する
Azure AI Foundryの認証と承認を理解するうえで、最初につまずきやすいのが「どの操作にどの権限が必要か」です。Foundryでは、操作を大きく2つに分けます。
| 区分 | 主な操作 | 利用するツール例 | 権限設計の考え方 |
|---|---|---|---|
| コントロールプレーン | Foundryリソース作成、プロジェクト作成、モデルデプロイ、接続作成、キーのローテーション、Private Link設定 | Azureポータル、Azure CLI、ARM、Bicep、Terraform | リソース管理者・基盤管理者向け。過剰付与を避ける |
| データプレーン | チャット、埋め込み生成、エージェント実行、評価、Content Safety呼び出し、ファインチューニング | SDK、REST API、Foundryポータルのプレイグラウンド | 開発者・アプリ実行主体向け。最小権限で割り当てる |
たとえば、開発者が「事前にデプロイされたモデルを使ってチャット機能を試す」だけなら、リソース作成やキーのローテーション権限は不要です。逆に、管理者が「モデルのデプロイやネットワーク分離を設定する」場合は、データプレーンだけでは足りません。
この分離を意識しないと、全員にOwnerやContributorを付ける運用になりがちです。短期的には楽ですが、退職者・異動者・委託先・CI/CDアカウントの棚卸しが難しくなり、監査時に説明しづらい構成になります。
APIキーでできること、できないこと
APIキーは完全に不要になるわけではありません。短期の検証や孤立したテスト環境では便利です。ただし、公式の機能サポートマトリックスを見ると、APIキーだけでは対応できない機能が明確にあります。Agents service、Evaluations、Toolbox、マネージドID、要求ごとのユーザー属性付け、組み込みロールやカスタムロールによる最小権限は、Microsoft Entra ID側の機能として整理されています。(Microsoft Learn)
| 機能・要件 | APIキー | Microsoft Entra ID | 実務上の判断 |
|---|---|---|---|
| 基本的なモデル推論 | 対応 | 対応 | PoCはAPIキーでもよいが、本番はEntra IDを優先 |
| ファインチューニング操作 | 対応 | 対応 | 監査性を考えるとEntra IDが有利 |
| Agents service | 非対応 | 対応 | エージェント構成はEntra ID前提で設計する |
| Evaluations | 非対応 | 対応 | 評価ジョブを使うチームはRBAC設計が必要 |
| Toolbox | 非対応 | 対応 | ツール連携ではマネージドID利用を検討する |
| 最小権限 | 非対応 | 対応 | 本番・社内利用ではEntra IDが基本 |
| 要求ごとのユーザー追跡 | 非対応 | 対応 | 監査ログや責任分界に影響する |
| 自動化パイプライン | シークレット管理が必要 | サービスプリンシパルまたはマネージドID | 長期運用ではEntra IDが扱いやすい |
APIキー運用で特に注意すべきなのは、「キーを知っている人」ではなく「キーそのもの」に権限が紐づく点です。ユーザーAが使ったのか、CI/CDが使ったのか、別システムが使ったのかを細かく分けにくくなります。ソースコードや環境変数にキーを残したまま退職・異動・委託終了が発生すると、棚卸しと無効化の負担が大きくなります。
管理者が確認すべき設定
カスタムサブドメインが構成されているか
Microsoft Entra IDによるトークンベース認証には、Foundryリソースのカスタムサブドメインが必要です。公式ドキュメントでも、Microsoft Foundryリソースにカスタムサブドメインが構成されていることが前提条件として示されています。Foundry Tools側の公式情報でも、Microsoft Entra認証ではAzureリソースのカスタムサブドメイン名を使用する必要があり、リージョンエンドポイントではサポートされないと説明されています。(Microsoft Learn)
移行前に、次を確認してください。
- 既存のFoundryリソースにカスタムサブドメインがあるか
- アプリケーションがリージョンエンドポイントを直接参照していないか
- SDK、REST API、IaCテンプレートでエンドポイントを固定していないか
- 本番、検証、開発環境でサブドメイン命名ルールが統一されているか
ここを見落とすと、コード側でトークン取得に成功しても、呼び出し先エンドポイントの条件が合わず認証エラーになります。
RBACの割り当てスコープを整理する
FoundryのRBACでは、サブスクリプション、リソースグループ、Foundryリソース、Foundryプロジェクトなどのスコープを意識する必要があります。公式のRBACドキュメントでは、Foundryリソースは管理・セキュリティ・監視の境界、FoundryプロジェクトはAPI、ツール、開発ワークフローのアクセス制御に使うサブスコープとして説明されています。(Microsoft Learn)
| 利用者・主体 | 推奨ロール例 | 割り当て先の考え方 | 注意点 |
|---|---|---|---|
| 一般開発者 | Foundry User | Foundryプロジェクト、必要に応じてFoundryリソース | データプレーン利用が中心。管理書き込みは不要 |
| チームリード | Foundry Project Manager | Foundryリソース | プロジェクト作成やデプロイ管理を行う場合に検討 |
| 基盤管理者 | Foundry Account Owner | Foundryリソース | 高権限。日常的な開発用アカウントには付けない |
| フルセルフサービス利用者 | Foundry Owner | Foundryリソース | 管理と開発の両方が必要な場合のみ |
| 監視担当 | Foundry User + Azure Monitor Reader | Foundryリソース、Application Insights | トレースや監視の閲覧要件を別途確認 |
ロールを割り当てるには、対象スコープでOwnerまたはUser Access Administratorが必要です。権限を付与した後は、az role assignment listなどで対象プリンシパルとスコープを確認しましょう。公式ドキュメントでも、ロール割り当て後に一覧取得で確認する手順が示されています。(Microsoft Learn)
旧ロール名と新ロール名の混在に注意する
FoundryのRBACロールは最近リネームされており、旧名が一部の画面やドキュメントに残る可能性があります。公式情報では、ロールIDと中核的な権限は変更されていないと説明されています。自動化コードではロール名ではなく、ロール定義IDを使うのが安全です。(GitHub)
| 新しいロール名 | 以前のロール名 | ロール定義ID |
|---|---|---|
| Foundry User | Azure AI User | 53ca6127-db72-4b80-b1b0-d745d6d5456d |
| Foundry Owner | Azure AI Owner | c883944f-8b7b-4483-af10-35834be79c4a |
| Foundry Account Owner | Azure AI Account Owner | e47c6f54-e4a2-4754-9501-8e0985b135e1 |
| Foundry Project Manager | Azure AI Project Manager | eadc314b-1a2d-4efa-be10-5d325db5065e |
特にBicep、Terraform、Azure CLI、GitHub Actions、Azure DevOpsでロール割り当てを自動化している場合は、ロール名の文字列一致に依存しないよう見直してください。日本語UIやローカライズ済みドキュメントでは旧名が見えることがあるため、実装ではGUID、運用手順書では新旧名の対応表を併記すると混乱を防げます。
Cognitive Services系ロールを安易に流用しない
FoundryのRBACドキュメントでは、Cognitive Servicesで始まる組み込みロールはAI Servicesリソースへ直接アクセスするためのもので、Foundryシナリオには適用しないよう注意されています。また、名称から誤解しやすいAzure AI Developerロールも、FoundryプロジェクトやFoundry hosted agents向けではないため、FoundryのプロジェクトアクセスにはFoundry UserまたはFoundry Ownerを使うよう説明されています。(Microsoft Learn)
「Azure AI関連だから似たロールでよい」と判断すると、403エラーや過剰権限の原因になります。ロール設計では、サービス名ではなく、対象がFoundryリソースなのか、Foundryプロジェクトなのか、接続先のAzure StorageやAzure AI Searchなのかを分けて確認してください。
開発者が確認すべきコードと実装ポイント
DefaultAzureCredentialでトークンを取得する
PythonでMicrosoft Entra ID認証を使う場合、公式サンプルではazure-identityのDefaultAzureCredentialを使い、https://ai.azure.com/.defaultをスコープとしてアクセストークンを取得しています。ヘッダーにはAuthorization: Bearer <token>を付けます。(Microsoft Learn)
from azure.identity import DefaultAzureCredential
credential = DefaultAzureCredential()
token = credential.get_token("https://ai.azure.com/.default")
headers = {
"Authorization": f"Bearer {token.token}",
"Content-Type": "application/json"
}ここで重要なのは、トークン取得のスコープと、実際に呼び出すFoundryエンドポイントを混同しないことです。APIバージョンやパスは利用する機能のリファレンスに合わせて更新し、ハードコードした古いエンドポイントを使い回さないようにしてください。
アプリの実行場所ごとにIDを選ぶ
Azure AI Foundryを呼び出す主体は、人間のユーザーだけではありません。Webアプリ、バックエンドAPI、バッチ処理、CI/CD、エージェント、評価ジョブなど、さまざまな実行主体があります。公式情報では、ユーザープリンシパル、サービスプリンシパル、システム割り当てマネージドID、ユーザー割り当てマネージドIDが整理されています。(Microsoft Learn)
| IDの種類 | 向いている場面 | 注意点 |
|---|---|---|
| ユーザープリンシパル | 開発者のローカル検証、管理者の手動操作 | 個人権限に依存するため本番アプリ実行には向かない |
| サービスプリンシパル | CI/CD、外部実行環境、自動化処理 | シークレットや証明書の期限管理が必要 |
| システム割り当てマネージドID | App Service、Functions、VMなど単一リソースで完結する処理 | リソース削除と同時にIDも消える |
| ユーザー割り当てマネージドID | 複数リソースで同じIDを使う処理 | どのリソースにアタッチしたか棚卸しが必要 |
Azure上で動くアプリなら、まずマネージドIDを検討してください。アプリにAPIキーやクライアントシークレットを保存しない設計にでき、キー漏えいリスクを減らせます。Foundry Toolsの公式情報でも、マネージドIDとMicrosoft Entra認証を組み合わせることで、クラウドで実行されるアプリケーションに資格情報を保存することを避けられると説明されています。(Microsoft Learn)
401と403を切り分ける
開発中に混同しやすいのが、401と403です。
401は「認証に失敗している」状態です。トークンがない、期限切れ、スコープが誤っている、APIキーが無効といった原因が考えられます。403は「認証はできたが、権限が足りない」状態です。プリンシパルにFoundry Userなどの適切なRBACロールがない、または割り当てスコープが違う場合に発生します。公式ドキュメントでも、401ではトークン取得スコープやAPIキー、403ではRBACロール割り当てを確認するよう整理されています。(Microsoft Learn)
APIキーからMicrosoft Entra IDへ移行する手順
APIキーを使っている既存環境では、いきなりローカル認証を無効化しないでください。まず呼び出し元を棚卸しし、Entra IDで動作する経路を作ってから、段階的にキー依存を減らします。
| 手順 | 作業 | 判断基準 | 失敗しやすいポイント |
|---|---|---|---|
| 1 | APIキー利用箇所を棚卸しする | アプリ、バッチ、CI/CD、手動ツール、ノートブックを確認 | 環境変数や古い検証コードにキーが残る |
| 2 | カスタムサブドメインを確認する | Entra ID認証に必要 | リージョンエンドポイントを使い続けて認証エラーになる |
| 3 | プリンシパルを決める | 人、アプリ、CI/CD、Azureリソースごとに分ける | 個人ユーザーの権限で本番アプリを動かす |
| 4 | RBACロールを割り当てる | Foundry User、Project Managerなどを最小権限で選ぶ | リソーススコープとプロジェクトスコープを取り違える |
| 5 | コードをBearerトークン方式へ変更する | DefaultAzureCredentialやマネージドIDを使う | トークン取得スコープを誤る |
| 6 | 401・403をテストする | 認証エラーと認可エラーを分けて確認 | ロール反映待ちを考慮せず再設定を繰り返す |
| 7 | APIキーをローテーションする | 旧キー利用が残っていないか確認 | 片方のキーだけ更新して古いキーが残る |
| 8 | キー認証を削除・ローカル認証を無効化する | 全呼び出し元がトークン認証へ移行済み | 監視ジョブや古いパイプラインが停止する |
Azureのロール割り当ては即時反映されないことがあります。Foundry Toolsの公式情報では、Azureロール割り当ての反映に最大5分かかる場合があると記載されています。移行テストでは、ロール付与直後の403を即座に設定ミスと判断せず、反映待ちとスコープ確認を分けて扱いましょう。(Microsoft Learn)
全ての呼び出し元がトークン認証へ移行した後に、キーベース認証を削除します。公式ドキュメントでも、全呼び出し元がトークン認証を使った後にキーベース認証を削除し、必要に応じてデプロイテンプレートでローカル認証を無効化する流れが示されています。(Microsoft Learn)
展開時に見落としやすい注意点
ファインチューニングはデータプレーンだけでは完結しない
ファインチューニングは、実行するだけならデータプレーンの操作に見えます。しかし、ファインチューニング済みモデルのデプロイはコントロールプレーン権限に関わります。FoundryのRBACドキュメントでは、ファインチューニングにはデータプレーンとコントロールプレーンの両方の権限が必要で、組み込みロールで両方を持つのはFoundry Owner、またはFoundry UserとFoundry Account Ownerを組み合わせる選択肢が示されています。(Microsoft Learn)
開発者にFoundry Userだけを付けて「ファインチューニングが最後までできない」となるケースは想定できます。ファインチューニングの実行者、モデルをデプロイする責任者、本番反映を承認する管理者を分ける場合は、事前に権限分掌を設計してください。
エージェント公開には追加の権限が必要になる
エージェントを作るだけでなく公開する場合、権限要件が上がることがあります。FoundryのRBACドキュメントでは、エージェントを公開するにはFoundryリソーススコープでFoundry Project Managerロールが最小要件として示されています。(Microsoft Learn)
「プレイグラウンドでは動いたのに公開できない」「開発者のローカルでは試せたが、チーム展開で失敗する」という場合は、認証方式ではなくRBACロール不足を疑ってください。
日本語ドキュメントやポータル表記の差異を前提にする
日本語版ドキュメントでは、更新日やロール表記が英語版と異なる場合があります。実際に日本語版では旧ロール名が残る箇所があり、英語版の新しい表記と完全には一致しません。(Microsoft Learn)
運用手順書では、次のように併記すると問い合わせを減らせます。
| 手順書での記載 | 目的 |
|---|---|
| Foundry User（旧：Azure AI User） | ポータルや日本語画面で旧名が見えても判断できる |
| ロール定義IDを併記 | CLIやIaCで名前の揺れを避ける |
| 英語版公式ドキュメントの更新日を確認 | ローカライズ反映待ちによる誤解を避ける |
| 権限変更時の確認コマンドを記載 | 付与済みかどうかを作業者が確認できる |
APIキーを残す場合は「例外」として管理する
すぐに全システムをEntra IDへ移行できない場合、APIキーを一時的に残すことはあります。その場合でも、APIキーを通常運用の標準にしないことが重要です。
APIキーを残す場合は、最低限次を決めてください。
- どのアプリがAPIキーを使っているか
- キーの保管場所はどこか
- キーのローテーション担当者は誰か
- キーを無効化する予定日はいつか
- ソースコード、Issue、Wiki、チャットログにキーが残っていないか
- ローカル認証を無効化できない理由は何か
「後でEntra IDにする」とだけ書いた移行計画は、ほぼ確実に後回しになります。APIキーを使う場合は、PoC終了日や本番リリース前の切替条件まで決めておくべきです。
よくあるエラーと確認ポイント
| エラー | 主な原因 | 確認すること |
|---|---|---|
| 401 Unauthorized | トークンなし、期限切れ、スコープ誤り、無効なAPIキー | https://ai.azure.com/.defaultでトークンを取得しているか。APIキー方式ならキーが正しいか |
| 403 Forbidden | RBACロール不足 | 対象プリンシパルにFoundry Userなどの適切なロールがあるか。割り当てスコープは正しいか |
| AADSTS700016 | アプリ登録が対象テナントにない | テナントID、クライアントID、アプリ登録の存在を確認する |
| Custom subdomain required | カスタムサブドメインではなくリージョンエンドポイントを使用 | Foundryリソースにカスタムサブドメインを構成し、アプリのエンドポイント設定を見直す |
| ロール付与直後の403 | ロール割り当て反映待ち | 数分待って再試行し、az role assignment listで割り当てを確認する |
公式ドキュメントでも、401、403、AADSTS700016、カスタムサブドメイン不足が代表的な認証エラーとして整理されています。まずはエラーコードを見て、「トークン取得の問題」なのか「RBACの問題」なのかを切り分けると、調査時間を短縮できます。(Microsoft Learn)
管理者と開発者が次にやるべきこと
Azure AI Foundryをすでに使っている組織は、まずAPIキー利用箇所の棚卸しから始めてください。次に、Foundryリソースのカスタムサブドメイン、RBACロール、マネージドID、サービスプリンシパル、CI/CDの認証方式を確認します。
優先順位は次の通りです。
| 優先度 | 対応 | 対象 |
|---|---|---|
| 高 | 本番アプリのAPIキー利用を洗い出す | 管理者、開発リード |
| 高 | Foundry Userなどの新ロール名とロールIDを手順書に反映する | 管理者、IaC担当 |
| 高 | Agents、Evaluations、Toolbox利用予定のプロジェクトをEntra ID前提にする | 開発者、アーキテクト |
| 中 | CI/CDをサービスプリンシパルまたはマネージドIDへ移行する | DevOps担当 |
| 中 | APIキーのローテーションと無効化計画を作る | セキュリティ担当 |
| 中 | 401・403の切り分け手順を運用ドキュメント化する | サポート担当、開発者 |
| 低 | 検証環境のAPIキー利用に期限を設定する | PoC担当 |
Azure AI Foundryの認証と承認は、「APIキーを使うか、Entra IDを使うか」だけの話ではありません。誰がリソースを管理し、誰がモデルやエージェントを使い、どのアプリがどの権限で実行されるのかを分けて設計することが重要です。
最初の一歩として、現在のAPIキー利用一覧、RBAC割り当て一覧、アプリ実行主体の一覧を作成してください。そのうえで、本番環境から順にMicrosoft Entra ID、マネージドID、最小権限RBACへ移行すれば、監査性と安全性を高めながらAzure AI Foundryを展開できます。
コメント