Azure Virtual Desktop（AVD）をAzure PortalのQuickstartで作ろうとすると「Owner / Contributor が必要」と表示されて止まることがあります。原因の多くは“所有者のつもり”と実際のRBAC割り当てスコープがズレていること。本記事では最短での確認手順と、Key Vaultで詰まる手動構築のコツまで整理します。
症状：AVD Quickstartで「Owner / Contributor が必要」と出て進めない
AVD を Azure Portal の Quickstart（ウィザード）で追加しようとしたとき、次のようなメッセージが表示されて先に進めないケースがあります。
Requires owner or contributor role assignment. Check permission or contact the subscription administrator to change your access.
日本語の感覚だと「自分はサブスクリプションの所有者のはずなのに、なぜ？」となりがちですが、Azure では“所有者っぽい肩書き”がいくつか存在し、AVD Quickstartが見ている権限（Azure RBAC）と一致していないことがよくあります。
結論：Quickstartが評価しているスコープで、Owner / Contributor が付いていないのが主因
AVD Quickstart は、ホストプールやワークスペースなど複数のリソースをまとめて作成します。そのため、作業対象のスコープ（サブスクリプション／リソースグループ）で、あなたのアカウントに Owner または Contributor が割り当てられていないと、権限不足として止まります。
特に多いのは次のズレです。
- “Ownerのつもり”＝課金管理やテナント管理（Entra IDロール）側の権限で、Azureリソース操作（RBAC）のOwnerではない
- Owner/Contributor が付いているのが別サブスクリプション、または別リソースグループ
- 付与されているのが“閲覧系”（Reader 等）で、作成系の権限がない
- PIM（特権ID管理）で“Eligible（割り当て可能）”になっていて、作業時に有効化していない
- ロール付与直後で反映がまだ（数分〜）
最短で直すチェックリスト（まずここだけ見ればOK）
- Azure Portal 右上のディレクトリ/サブスク表示が、作業したいサブスクリプションになっている
- 対象スコープ（まずはサブスクリプション）の「アクセス制御（IAM）」で、あなたがOwner か Contributorになっている
- Quickstart で新規リソースグループを作る場合、サブスクリプションスコープの権限が不足していない（RGだけOwnerでも作れないことがある）
- PIM を使っているなら、Owner/Contributor を“アクティブ化”してから再実行する
- 付与し直した直後なら、数分待つ／サインアウト＆サインイン／別ブラウザで再試行
Azure Portalでの確認手順（アクセス制御（IAM）で確実に見る）
サブスクリプションスコープで確認する
- Azure Portal で サブスクリプション を開く
- 対象のサブスクリプションを選択
- 左メニューの アクセス制御（IAM） を開く
- ロールの割り当て で、検索ボックスに自分の名前（またはメールアドレス）を入れて絞り込む
- 自分が Owner または Contributor として割り当てられているか確認する
リソースグループスコープで確認する（既存RGに作る場合）
Quickstart の入力で「既存のリソースグループを選ぶ」運用の場合は、対象RGでも同様に確認します。
- Azure Portal で リソース グループ を開く
- 対象RGを選択
- アクセス制御（IAM） → ロールの割り当て を確認
ポイント：サブスクリプションでOwner/Contributorが付いていれば、配下のRGやリソースにも基本的に継承されます。一方、RGだけに付いている場合は、Quickstart が RG の新規作成やサブスクリプション側の操作をしようとして止まることがあります。
「Ownerのはずなのに…」が起きる代表原因まとめ（表で整理）
| よくある状況 | 何がズレている？ | 確認ポイント | 対処 |
|---|---|---|---|
| 課金管理者/請求書管理の権限はある | それはRBACのOwnerではない | サブスクリプションIAMでOwner/Contributorが見当たらない | サブスク or RG に Owner/Contributor を割り当ててもらう |
| 別のサブスクでは作れるが、このサブスクだと失敗 | 権限が別サブスクに付いている | Portal上部のサブスク切替、サブスク一覧 | 対象サブスクにロール付与（もしくはサブスクを切り替える） |
| RGではOwnerだが、Quickstartが進まない | Quickstartがサブスク操作（RG作成など）を必要としている | Quickstartで新規RGを作っていないか | 既存RGを使うか、サブスクでContributor以上を付与 |
| 昨日までできたのに今日は権限不足 | PIMでロールが非アクティブ／期限切れ | 自分のロールがEligibleになっていないか | PIMでOwner/Contributorを有効化して再実行 |
| 付与した直後なのに失敗する | 反映遅延・トークンが古い | 付与時刻、ブラウザのセッション | 数分待つ、サインアウト/イン、別ブラウザ、Cloud Shellで確認 |
| Contributorなのに一部だけ失敗する | ロール割り当て作業が必要な操作が含まれる | エラーが「RoleAssignment」や「Microsoft.Authorization」を含む | Owner または User Access Administrator を検討 |
AVD運用で押さえたいロール設計（Owner/Contributorだけに頼らない）
Quickstart を通すだけなら Owner/Contributor で解決することが多い一方、運用を始めると「何でもOwner」で回すのは危険・非効率になりがちです。AVDには管理用の組み込みロールが用意されているため、用途別に割り当てると事故が減ります。
| ロール | できること（ざっくり） | 向いている担当 | 注意点 |
|---|---|---|---|
| Owner | 全操作＋ロール割り当て | 基盤管理（最小人数） | 強すぎるため常用は避けたい |
| Contributor | リソース作成・変更はできるが、原則ロール割り当て不可 | 構築担当 | 「権限の付与」が絡む操作で詰まることがある |
| User Access Administrator | ロール割り当て（RBAC）管理 | 権限管理担当 | Ownerでなくても権限付与ができるため運用分離に有効 |
| Desktop Virtualization Contributor | AVD（ホストプール/ワークスペース/アプリグループ等）の管理 | AVD運用担当 | ユーザー割り当てや関連リソースは別権限が必要な場合あり |
| Desktop Virtualization Reader | AVD設定の参照 | 監査/ヘルプデスク | 変更はできない |
「Quickstartを通すためにOwnerを一時付与 → 作成が終わったら Desktop Virtualization Contributor など最小権限に落とす」という流れにすると、現場の運用が安定しやすいです。
Ownerを“付与し直したら通った”理由（再発防止の考え方）
実務でよくあるのが、以前はOwnerだったが、いつの間にか割り当てが変わっていた／別スコープだった、というパターンです。Ownerを付与し直すと解消する理由は主に次の通りです。
- スコープが正しくなった（RGではなくサブスクリプションに付与し直した等）
- グループ経由の付与が変わっていた（グループから外れていた、動的グループ条件変更など）
- PIMの有効化が必要な状態だった（常時有効ではなく、作業時にアクティブ化が必要）
- トークン更新が走り、Portal側の「見え方」が揃った
一度通った後も、将来の運用で同様の詰まりを防ぐには「誰が・どのスコープで・いつまで・どの権限を持つか」を棚卸しして、権限付与をグループ化・標準化しておくのがおすすめです。
Portalでうまくいかない場合：Azure CLI / PowerShellで確認・付与を進める
Portalが重い、権限の見え方が怪しい、作業を自動化したい場合は、CLI/PowerShellで事実確認すると早いです。特に「自分がどのスコープで何のロールを持っているか」をコマンドで見ると、ズレが一発で分かります。
Azure CLI：サブスク確認とロール確認
# まずサブスクリプションのコンテキスト確認
az account show
# サブスクリプションを明示的に切り替える（必要なら）
az account set --subscription ""
# 自分（UPN）に紐づくロール割り当てを一覧
az role assignment list --assignee "<[[email protected]](mailto:[email protected])>" --all -o tableAzure CLI：Owner（またはContributor）を付与する例
自分で付与できる権限を持っている前提ですが、確認用の例として記載します。
# サブスクリプションにOwnerを付与（スコープが重要）
az role assignment create \
--assignee "<[email protected]>" \
--role "Owner" \
--scope "/subscriptions/<SUBSCRIPTION_ID>"PowerShell（Az）：ロール割り当て確認の例
# サブスクリプションを選択
Set-AzContext -SubscriptionId "<SUBSCRIPTION_ID>"
# 自分のロール割り当て確認
Get-AzRoleAssignment -SignInName "<[[email protected]](mailto:[email protected])>" | Select-Object RoleDefinitionName, Scopeコマンドで「Owner/Contributor がどのスコープに付いているか」が見えれば、Quickstart で詰まる理由を説明しやすくなり、管理者への依頼もスムーズになります。
Quickstartの次に詰まりやすい：手動構築でKey Vault周りで止まる理由
Quickstart は通ったのに、いざ手動でAVDを組もうとすると Key Vault 周辺で詰まることがあります。ここで重要なのは、Key Vault には大きく分けて2種類の権限の見方がある点です。
- 管理プレーン（Management Plane）：Key Vaultリソース自体を作る/設定する権限（例：Owner/Contributor）
- データプレーン（Data Plane）：シークレット/キー/証明書を取得・登録する権限（Key Vault専用ロール、またはアクセス ポリシー）
つまり「サブスクOwnerだからKey Vaultも何でもできるはず」と思っていても、Key Vault が RBAC モードで運用されている場合、シークレットのGet/List/Setができないなどの状態が起こりえます。
Key Vaultで詰まる典型パターンと、最短の切り分け
まず確認：Key Vaultの「アクセス構成」がRBACかアクセス ポリシーか
Key Vault を開き、設定の中にある アクセス構成（名称は環境により多少異なります）を確認します。
- Azure ロールベースのアクセス制御（RBAC）：IAM（ロール割り当て）でデータプレーン権限を管理する
- Vault アクセス ポリシー：Key Vault独自のアクセス ポリシーで管理する
ここが分からないまま権限を足していくと、いつまで経っても解決しません。まずは方式を確定させます。
次に確認：「誰が」Key Vault にアクセスして失敗しているか
手動構築でKey Vaultが絡む場面では、アクセス主体が複数あり得ます。
- あなた自身（Portalで操作するユーザー）
- デプロイに使っているサービスプリンシパル（CI/CD、Terraform等）
- VMやスクリプトのマネージドID（拡張機能、カスタムスクリプト等）
エラーメッセージに出てくる Object ID / App ID を見て、どの主体が拒否されているかを特定すると、付与すべきロールが明確になります。
よくあるKey Vaultエラーと原因（表）
| エラーの雰囲気 | 原因になりやすいもの | 最短の対処 |
|---|---|---|
| Forbidden / Access denied / 権限がない | データプレーン権限不足（Secrets/Keys/Certificates） | RBACならKey Vault Administrator/Secrets Officer等、アクセス ポリシーなら必要なGet/List/Setを追加 |
| ネットワーク的に到達できない | Key Vaultのネットワーク設定（パブリックアクセス無効、ファイアウォール、Private Endpoint） | 接続元の許可、Private DNSの確認、検証時は一時的に到達性を確保 |
| 名前は存在するのに作れない／復元が必要 | Soft Delete状態で残っている | 回復（Recover）/パージ（Purge）を検討、命名変更も現実的 |
| 証明書が作れない／参照できない | Certificates系の権限不足、または操作対象が「秘密」ではなく「証明書」 | Certificates Officerなど、対象オブジェクトに合う権限を付与 |
Key Vaultで必要になりがちなロール（RBAC運用時の目安）
RBAC運用の場合、目的別に付けるロールを間違えると「管理はできるのにシークレットが取れない」などが起こります。目安として、よく登場する組み込みロールをまとめます。
| 目的 | 付与先 | おすすめロール例 | 補足 |
|---|---|---|---|
| Key Vaultのフル管理（最初の整備） | 基盤管理者 | Key Vault Administrator | 強い権限。常用は最小人数に |
| シークレットの登録/更新（パスワード等） | デプロイ用ID/担当者 | Key Vault Secrets Officer | 「読むだけ」ではなく「書く」も必要ならこちら |
| シークレットの参照（取得のみ） | VMのマネージドID等 | Key Vault Secrets User | アプリ側は最小権限にする |
| キーで暗号化（CMKなど） | 暗号化対象のサービス | Key Vault Crypto User / Crypto Service Encryption User 等 | 用途で必要ロールが変わるため要確認 |
アクセス ポリシー運用の場合は、Key Vault の「アクセス ポリシー」で、対象主体（ユーザー/アプリ/マネージドID）に対し Secrets: Get/List/Set など必要な権限を明示的に付けます。
AVDの手動構築を成功させる“実務的な順番”（Key Vaultに寄り道しない）
「手動構築」という言葉が、実際には複数のパターンを含みます。まずは最短で動く最小構成を作り、その後にKey Vaultやセキュリティ強化を積み上げると、原因切り分けが簡単です。
| ステップ | やること | 決めるべきポイント | 詰まりやすい箇所 |
|---|---|---|---|
| 設計 | 参加方式（AD DS / Entra ID Join / ハイブリッド）を決める | ユーザー管理、デバイス管理、既存AD資産 | DNS/参加方式の選択ミス |
| 基盤 | VNet/Subnet、DNS、必要ならVPN/ExpressRoute | 名前解決、ルーティング、NSG | ドメイン参加失敗、到達性不足 |
| AVD作成 | ホストプール、アプリグループ、ワークスペースを作成 | Pooled/Personal、最大セッション数 | 権限不足、サブスク/RGの取り違え |
| セッションホスト | VMを作成し、ホストプールへ登録 | イメージ、サイズ、参加方式 | 登録トークン期限、エージェント未登録 |
| ユーザー割り当て | アプリグループにユーザー/グループを割り当て | 配布単位をグループに寄せる | 割り当て漏れ、Entra IDのグループ設計 |
| プロファイル | FSLogix 等のユーザープロファイルを構成 | Azure Files/NetApp Files 等 | 権限、ストレージ接続、パフォーマンス |
| 運用強化 | スケーリングプラン、監視、バックアップ | コスト最適化、SLA | スケール条件、ログ設計 |
Key Vault は「必要になったら導入する」でも遅くありません。最初から“秘密情報の安全な保管”まで完璧を目指すと、権限やネットワークで詰まって本筋（AVDを動かす）に到達しづらくなります。
それでもKey Vaultが必要になる場面と、詰まらない進め方
次のようなケースでは、手動構築でもKey Vaultが登場しやすいです。
- デプロイスクリプトでドメイン参加用の資格情報を参照する
- ストレージ接続情報（キー、SAS等）を安全に保管して参照したい
- 証明書を安全に保管し、アプリやゲートウェイで利用したい
- IaC（Bicep/Terraform）で「秘密を直書きしない」運用にしたい
詰まらないためのコツは以下です。
- アクセス主体を1つずつ増やす（最初は自分のユーザーだけでGet/Setできることを確認 → 次にデプロイ用ID → 次にVMのMI）
- RBAC方式かアクセス ポリシー方式かを固定し、混ぜない
- ネットワーク制限は最後に強める（動作確認が終わってからPrivate EndpointやFWを厳格化）
- エラーが出たら「何がしたかったか（Secret/Key/Cert）」と「誰が拒否されたか」をログで見る
AVD Quickstartと手動構築の使い分け（現場目線）
Quickstart が悪いのではなく、目的が違います。使い分けると学習も構築も早くなります。
| 方法 | 向いている | メリット | 注意点 |
|---|---|---|---|
| Quickstart（Portalウィザード） | とにかく早く触りたい、検証・PoC | 最短で形になる、入力項目が少ない | 権限不足に弱い／細かい設計を反映しにくい |
| 手動構築（Portalで丁寧に） | 運用を見据えた設計 | 構成要素を理解でき、トラブル対応力が付く | 手順が多く、Key Vaultやネットワークで迷子になりがち |
| IaC（Bicep/Terraform等） | 再現性・標準化・複数環境 | 同じものを何度でも作れる、監査に強い | 初期学習が必要。権限設計が重要 |
ガイド動画・ドキュメントの探し方（迷わない検索キーワード）
AVD と Key Vault は情報量が多く、検索キーワードがズレると別物が出てきます。次のキーワードで探すと、公式ドキュメントや解説動画に当たりやすいです。
| 探したいもの | おすすめ検索キーワード例 | 補足 |
|---|---|---|
| ホストプール作成（Portal） | Azure Virtual Desktop create host pool portal | Quickstart相当の手順を公式で確認しやすい |
| セッションホスト登録トラブル | AVD session host registration token expired | “Unavailable”や“Agent”で絞るのも有効 |
| RBACとIAM | Azure RBAC scope subscription resource group | 「スコープ」の理解が最重要 |
| Key Vault RBAC | Key Vault RBAC secrets officer secrets user | 管理プレーンとデータプレーンの混同を防げる |
| 動画で学ぶ | Azure Virtual Desktop tutorial video / Microsoft Mechanics AVD | “Mechanics”は製品担当者の解説が多い |
動画で追う場合は「AVDの全体像（ワークスペース/アプリグループ/ホストプール/セッションホスト）」→「運用（スケーリング/監視/イメージ）」→「セキュリティ（Key Vault/Private Endpoint）」の順で観ると理解が崩れにくいです。
まとめ：この問題を一発で解決し、再発させないために
- AVD Quickstart の「Owner / Contributor が必要」は、“そのスコープでRBACが付いていない”がほぼ原因
- まずは サブスクリプション → IAM で自分のロールを確認し、必要なら Owner/Contributor を明示的に付与する
- 運用では Owner 常用を避け、Desktop Virtualization Contributor など役割に合ったロールに分離する
- 手動構築で Key Vault が詰まるときは、アクセス方式（RBAC/アクセス ポリシー）とアクセス主体の特定が最短ルート
- 最初から完璧を目指さず、最小構成で動作確認 → セキュリティ強化の順で進めると失敗しにくい
もし Quickstart は通るのに、手動構築で特定の Key Vault エラー（Forbidden の本文や Object ID など）が出ている場合は、そのエラー文字列に合わせて「誰にどのロールが足りないか」をピンポイントで潰せます。ログとエラー文を丁寧に読むだけで、遠回りが一気に減ります。
コメント