Azure AI Foundry（旧 Azure AI Studio）にサインインするとローディング画面のまま固まり、ポータルが一切表示されない――そんな厄介な症状は、実は「通信は届いているのに、許可やネットワーク制御で弾かれている」ことが大半です。この記事では、最終的にRBAC（ロールベースアクセス制御）の不足が原因だった実例を踏まえ、再現しやすい切り分け手順と確実に直すためのチェックリストを、現場運用の目線で整理しました。
目次
結論と全体像
最終原因はAI Hub / AI Project 等の基盤リソースに対する RBAC 不足でした。適切なロール（少なくとも読み取り用の Reader、編集・作成を伴うなら Contributor 以上）を割り当てると、ローディングから即座に復帰し、ポータルが正常表示されました。
ローディングから進まない状態は、次のどれかが引き金になりがちです。
- 認可エラー（403/AuthorizationFailed）：RBAC が足りない、または割り当てが子リソースに継承されていない。
- ネットワーク制御：Public network access の無効化、選択 IP 限定、プロキシ／ファイアウォール／SSL インスペクション。
- 組織側の制約：条件付きアクセス、PIM（特権の Just-In-Time 有効化漏れ）、Deny Assignment、Resource Lock。
- 一時的障害：対象リージョンや依存サービスの断続的エラー。
最速で原因にたどり着くためのチェックリスト
まずは、時間対効果が高い順に下表のチェックを進めてください。5～10分で「権限問題か、ネットワーク問題か」を切り分けできます。
| 手順 | 目的 | 操作ポイント | 判定の目安 | 次のアクション |
|---|---|---|---|---|
| ブラウザ開発ツールで失敗リクエスト確認 | 隠れたエラーの正体を掴む | F12 → Network → 再読み込み。 失敗行を選び Status / Response を確認 | 403 / AuthorizationFailed / MissingSubscriptionRegistration / RequestDeniedByPolicy 等 | 権限・購読登録・ポリシー・PIM の有効化を重点確認 |
| サインイン先テナント/サブスクリプションの再確認 | 「見えているが別テナント」問題の排除 | ポータル右上のディレクトリ／サブスクリプション選択を確認 | 意図しないテナント／サブスクリプションを選択していた | 正しい組み合わせに切替、再読み込み |
| Networking ブレード確認 | IP 制限／Private 接続の有無 | AI Hub/Project → Networking Public access, Selected IPs, Private Endpoints | Public access 無効 or 選択 IP 限定 | 現在のグローバル IP を登録 or 企業網から接続 |
| IAM（アクセス制御）確認 | 必要ロール付与の有無 | 対象リソースの アクセス制御 (IAM) → ロールの割り当て | 自分に Reader/Contributor 等が無い | 最低限 Reader を付与（編集作業は Contributor 以上） |
| プロキシ/ファイアウォール/SSL 検査 | 企業網のブロック検知 | 社内プロキシ除外、SSL インスペクション対象外の確認 | 特定ドメイン/証明書でブロック | 除外設定 or 社外ネットワークで再現確認 |
| サービス障害の有無 | 手元以外の要因除外 | Azure ステータスで対象リージョンと依存サービスを確認 | 該当の断続エラーあり | 時間をおいて再試行 or リージョン切替 |
| HAR 採取 → サポート起票 | 再現性ある証跡を添付 | Network → Save all as HAR | 自己解決が難しい場合 | HAR を添付し解析依頼 |
今回の実例：RBAC 不足で進まないケース
症状は「Azure AI Foundry にアクセス後、ローディングアニメーションが回り続ける」状態。キャッシュ削除、複数ブラウザ、シークレットモード、モバイル回線などの基本対処でも改善せず、回線も下り 250 Mbps 程度で問題なし。開発者ツールの Network にて複数 API が 403 を返し、本文に AuthorizationFailed が含まれていることを確認しました。
IAM（アクセス制御）を見ると、Resource Group にのみロールが付与され、AI Hub およびその配下の AI Project や関連リソース（ストレージ、Key Vault、レジストリ等）には十分な権限が伝播していませんでした。AI Hub に Reader（閲覧）と運用担当に Contributor を付与後、画面を更新した瞬間に UI が復帰し、すべてのメニューが表示されました。
RBAC 設計の勘所：最低限どこに何を付けるか
「Resource Group に付けたから大丈夫」のつもりでも、継承範囲のズレや子リソースへの個別 Deny、管理グループ／ポリシーの制約でアクセスが成立しないことがあります。次の表をベースに見直してください。
| 対象 | 最低限必要なロール | 目的/理由 | 注意点 |
|---|---|---|---|
| サブスクリプション | Reader（閲覧者） | 一覧・メタデータ取得、UI 構築に必要な読み取り | ここだけ Reader でも UI は動くが、子に Deny があると詰まる |
| Resource Group | Reader / Contributor | グループ配下のリソース情報にアクセス | 継承が子に届かないケース（個別割り当てや Deny）に注意 |
| AI Hub | Reader 以上（UI 表示） 運用は Contributor 以上 | ポータルが最初に読み込む中心リソース | ここが欠けるとローディングから進まないことが多い |
| AI Project（Hub 配下） | Reader / Contributor | プロジェクトのメタデータ取得・設定 | Hub と Project の両方に割り当てると確実 |
| ストレージ / Key Vault / レジストリ等 | Reader（UI 表示）＋ 必要に応じて Contributor | 接続検証やシークレット参照で必要 | Vault はアクセス ポリシーや RBAC 切替状態も確認 |
よくある誤設定と正しい設定
| 誤設定例 | 何が起きるか | 正しい設定 |
|---|---|---|
| Resource Group にだけロール付与 | AI Hub/Project の API 呼び出しで 403。UI はローディングで停止 | AI Hub と Project にも Reader/Contributor を明示付与 |
| 個人アカウントに付与、実際はグループ経由ログイン | 本人にロールが見えない／意図通りに効かない | 実サインイン アカウント（Entra ID）へ割り当て直し |
| PIM ロールの有効化を忘れる | 権限があるつもりでも実際は無効。403 が続く | PIM をアクティブ化（多要素・承認）後に再読み込み |
| 管理グループのポリシー/Deny Assignment を失念 | 子の許可より上位の拒否が優先され操作不可 | 上位の Deny/Policy を確認し、例外を申請 |
ブラウザ開発ツールで「読み込み停止」の正体を見破る
ローディングは UI の見かけでしかありません。実体はバックエンド API の失敗連鎖です。次の観点でログを見れば、ほぼ原因の目星がつきます。
- Status：
401（未認証）か403（認可失敗）か。 - Response Body：
AuthorizationFailed、MissingSubscriptionRegistration、RequestDeniedByPolicy等のキーワード。 - Request URL：どのリソース プロバイダーに当たっているか（例：ストレージ、Key Vault など）。
- Timing：「一発目から 403」なら根本的な権限不足、「一部だけ 403」なら子リソースまたはネットワーク。
典型的なレスポンス例（抜粋）
{
"error": {
"code": "AuthorizationFailed",
"message": "The client '[email protected]' with object id '...' does not have authorization to perform action 'Microsoft.CognitiveServices/.../read' over scope '/subscriptions/.../resourceGroups/.../providers/...' or the scope is invalid."
}
}
{
"error": {
"code": "RequestDeniedByPolicy",
"message": "Resource '...' was disallowed by policy."
}
}
{
"error": {
"code": "MissingSubscriptionRegistration",
"message": "The subscription is not registered to use namespace 'Microsoft.CognitiveServices'."
}
}
ネットワーク設定が原因のときに見る場所
企業ネットワークでは、下記が UI 停止の引き金になります。Networking ブレードと社内プロキシ設定を同時に確認しましょう。
- Public network access = Disabled：VPN/ExpressRoute 経由のみ許可。社外からは弾かれます。
- Selected IPs：現在のグローバル IP がホワイトリストに無い。
- Private Endpoint：Private DNS 構成不備で名前解決できずタイムアウト。
- SSL インスペクション：ポータルや API の TLS が書き換えられ、認証に失敗。
- 厳格なトラッキング防止／サードパーティ Cookie 拒否：シングルサインオンが成立せず 401/403 を誘発。
対処の要点
- 現在のグローバル IP を確認し、Selected IPs に追加。
- Private エンドポイントを使う場合、Private DNS ゾーンの関連付け／レコードを点検。
- プロキシ／セキュリティ製品で Azure 関連ドメインと証明書の例外を設定。
- 一時的に社外ネットワーク（テザリング等）で再現性を確認し、切り分け。
CLI での権限・設定チェック（コピペ可）
ポータルに入れない時は CLI が強力です。以下の順に実行し、権限の穴や登録漏れを洗い出します。
ログイン状態とコンテキスト確認
# ログイン
az login
# 現在のアカウントとテナント
az account show --output table
# 対象サブスクリプションに切替
az account set --subscription 自分のロール割り当てを一覧
# サブスクリプション全体での割り当て
az role assignment list --assignee <YOUR_UPN_OR_OBJECT_ID> --all --output table
# 特定リソース（例：AI Hub）の割り当て
az role assignment list
--assignee
--scope /subscriptions//resourceGroups//providers///
--output table ロールを素早く付与（必要に応じて）
# Reader を AI Hub に付与する例
az role assignment create \
--assignee <YOUR_UPN_OR_OBJECT_ID> \
--role "Reader" \
--scope "/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RG>/providers/<PROVIDER>/<RESOURCE_TYPE>/<HUB_NAME>"
# 編集作業が必要なら Contributor
az role assignment create
--assignee
--role "Contributor"
--scope "/subscriptions//resourceGroups//providers///" プロバイダー登録の漏れを救済
# よく使う名前空間の登録（不足時エラーの原因に）
az provider register --namespace Microsoft.CognitiveServices
az provider register --namespace Microsoft.MachineLearningServices
az provider register --namespace Microsoft.Storage
az provider register --namespace Microsoft.KeyVault
az provider register --namespace Microsoft.ContainerRegistry
「それでもダメ」な時に疑う 7 つのポイント
- PIM（特権の有効化）忘れ：ロールは割り当て済みでも、アクティブ化しないと権限ゼロです。
- 条件付きアクセス：特定の場所・デバイス・アプリのみ許可。別経路では認証が通らない。
- Deny Assignment：上位の拒否が勝つため、子の許可では覆せません。
- Resource Lock（削除/更新のロック）：読み取りは可能でも、一部の操作が詰まる。
- Key Vault の認可モード：Vault access policy と Azure RBAC の切替ミス。
- テナント／サブスクリプションの取り違え：ポータル右上のフィルタを再点検。
- ブラウザ拡張・トラッキング防止：SSO が壊れて 401/403。別プロファイルで検証。
ネットワーク周りの確認表（社内に渡せる版）
| 観点 | 確認内容 | 判定/対処 |
|---|---|---|
| Public Access | AI Hub/Project の Public network access が Disabled か | Disabled なら企業網/VPN 経由のみ許可。社外からの検証は不可 |
| Selected IPs | 許可 IP に現在のグローバル IP が入っているか | 抜けていれば追加。動的 IP の場合はレンジで登録 |
| Private Endpoint | Private DNS ゾーンのリンク・A レコード整合 | 名前解決できないとタイムアウト。nslookup で検証 |
| SSL インスペクション | TLS 復号対象外に設定されているか | ポータル/API ドメインは例外に |
| プロキシ例外 | Azure 関連ドメインがブロックされていないか | 業務必須として許可リストへ追加 |
HAR 収集とエスカレーションのコツ
自己解決できない場合は、再現直後に HAR を採取してサポートへ渡しましょう。ポイントは次の通りです。
- 問題が起こる直前に F12 を開き、Preserve log をオン。
- ページを再読み込みし、読み込み停止を確認したらすぐ Save all as HAR。
- 発生時刻、対象テナント/サブスクリプション、操作内容（何を開いたか）をメモ添付。
再発防止：運用設計のベストプラクティス
- ロールの標準プロファイルを用意（閲覧専用／運用／構築など）し、AI Hub・Project・関連リソースへ一括適用。
- テナント／サブスクリプション命名規約とタグ運用を徹底し、フィルタミスを回避。
- PIM の運用手順（有効化→作業→無効化）を Runbook 化。
- Networking の変更申請テンプレート（Public/Private、IP 追加、DNS 変更）を整備。
- 監査ログ/アラート：403・ポリシー違反・MissingRegistration を検知して通知。
「すぐ使える」復旧フロー（現場配布テンプレート）
- ブラウザ開発ツールで失敗 API の
Status/Responseを 1 件サンプル取得。 AuthorizationFailedがあれば、IAM で AI Hub/Project に自分が Reader 以上を持つか確認。- 足りなければ、暫定で Reader を付与 → 画面更新で動作確認。
- 編集が必要なら Contributor を追加（PIM ならアクティブ化）。
- 403 が消えなければ、Networking（Public/Selected IP/Private）とプロキシ例外を確認。
- それでも不可なら、MissingSubscriptionRegistration の解消（プロバイダー登録）。
- 解決しない場合は HAR を採取してサポートにエスカレーション。
トラブルの兆候と対処の早見表
| 兆候 | 考えられる原因 | 一次対処 | 恒久対策 |
|---|---|---|---|
| ずっとローディング | AI Hub への読み取り権不足 | Hub に Reader 付与 | Hub/Project へ標準ロールの自動付与 |
| 一部メニューだけ空白 | 子リソースだけ権限不足 | 子に個別で Reader 付与 | 継承の整合＆Deny の棚卸し |
| 認証がループする | 条件付きアクセス／Cookie/SSO 問題 | 別ブラウザ・別プロファイルで検証 | SSO 設計とブラウザポリシーの見直し |
| 社外回線なら動く | プロキシ／SSL インスペクション | 例外設定を追加 | ネットワーク標準の例外リスト化 |
FAQ（よくある質問）
Q. Contributor を付けたのに動きません。
A. PIM のアクティブ化漏れ、上位の Deny Assignment、条件付きアクセス、あるいはネットワーク側の選択 IP 制限が残っている可能性があります。WhoAmI 的に現在のトークンが反映されていない場合もあるため、サインアウト→サインインやブラウザプロファイル切替を試してください。
Q. どのロールを付ければ最低限 UI が出ますか？
A. AI Hub と AI Project に Reader が最短です。UI の表示だけなら十分な場面が多く、編集作業の必要に応じて Contributor を加えます。
Q. Resource Group に付ければ子にも効きますよね？
A. 原則は継承されますが、Deny Assignment や個別割り当ての上書きで効かないことがあるため、ハブ／プロジェクトへ明示付与すると確実です。
Q. 会社のプロキシが厳しくて……。
A. 一時的に社外経路で再現確認し、ネットワーク要因と切り分けてから、必要なドメインの例外登録を依頼するのが最短です。SSL インスペクションの対象外化も効果的です。
実運用での「ハマりパターン」事例集
- 別テナントでの作業：招待で入った B2B テナント側にリソースがあり、既定テナントのままポータルに入っていた。
- 多段ポリシーの副作用：管理グループの「特定 SKU 禁止」ポリシーが想定外の API を拒否し、UI 構築に失敗。
- Key Vault だけ古い運用：Vault だけアクセス ポリシー方式のままで、RBAC を付けても UI が一部壊れる。
- Private DNS の短時間不一致：ゾーンリンクが切れ、短時間だけ名前解決できずローディングに。
- トークンの有効期限切れ：長時間のタブ放置でトークンが古く、401→サイレント失敗→ローディング。
復旧後にやっておきたい健全化タスク
- 標準ロール・テンプレートをコード化（Bicep/ARM/Terraform）し、ハブ作成時に自動付与。
- 監視：ポータル/API の 403/401 レートと MissingRegistration をメトリクス化。
- Runbook 整備：今回のチェックリストと CLI コマンドを社内 Wiki に固定化。
- ネットワークの常設例外：Azure 関連のプロキシ/SSL インスペクション例外を標準ポリシー化。
まとめ
- ローディングから進まないのは「通信は届くが許可/制御で止まっているサイン」。
- 最短経路は、開発者ツールで 403/エラーコードを特定 → AI Hub/Project へ Reader/Contributor の順で確認。
- ネットワーク制御（Public/Selected IP/Private、プロキシ、SSL 検査）と PIM/ポリシーも同時に点検。
- 権限を正しく付けたら即時に UI が復帰するのが典型パターン。ダメなら HAR を採ってエスカレーション。
付録：今回のチェックリスト（配布用フル版）
| 手順 | 目的 | 操作ポイント | 期待される確認結果 |
|---|---|---|---|
| ブラウザ開発ツールで失敗を特定 | 権限かネットワークかを秒で切り分け | F12 → Network → 再読み込み → 失敗行の Status/Response を確認 | 403 AuthorizationFailed があれば RBAC 重点。RequestDeniedByPolicy はポリシー確認 |
| Networking の確認 | Public/Private/Selected IP の把握 | AI Hub/Project → Networking ブレード | Public disabled なら社内回線/VPN 必須。Selected IP は現行 IP を追加 |
| RBAC の確認 | 自分のロールを可視化 | 対象リソース → アクセス制御 (IAM) | Hub/Project に Reader 以上。編集は Contributor 以上 |
| プロキシ/SSL 検査の例外 | 企業網の干渉排除 | Azure 関連ドメインの例外化 | 社外回線で再現しないならネットワーク要因濃厚 |
| サービス障害の確認 | 外的要因の除外 | Azure ステータスでリージョンと依存サービスを確認 | 障害なら待機かリージョン変更 |
| HAR 収集 | サポート解析を加速 | Network → Save all as HAR | 失敗 API と時刻・テナント情報を必ず添付 |
補足：権限設定ミスの再掲
| 誤設定例 | 正しい設定 |
|---|---|
| リソースグループにだけ権限、AI Hub サブリソースは無権限 | 継承を確認し、必要なら AI Hub と AI Project に個別割り当て |
| 個人にロール付与したが、実際は Entra グループ経由でログイン | サインイン アカウントと割り当て先オブジェクトが一致しているか確認 |
要点の再確認：読み込みループは、裏側の API が 403 等で落ちているサインです。Network タブで失敗を特定し、RBAC・ネットワーク制御・ポリシー・PIM を順番に潰せば、最短で復旧できます。とりわけAI Hub/Project への Reader/Contributor の付与は即効性が高く、今回のケースでもそれで解消しました。
コメント