みなさん、こんにちは。ネットワールドでSA（ソリューションアーキテクト）として活動している後藤です。
前回の記事でAzure Localのデプロイやシステム運用の際に必要なユーザーアカウントの整理を行いました。前回記事はこちら。
では、利用者である一般ユーザーが、Azureポータルに接続してAzure Local上で仮想マシンを作成しようとした場合、どのような権限（ロール）が必要なのでしょうか。
今回はリソースグループ関連も含めて、ユーザー運用に関する事項を考察していこうと思います。
- 1：最初に注意事項と免責事項
- 2：公式情報は？
- 3：一番単純な方法・Azure Localのリソースグループに割り当てる
- 4：Azure Localのリソースグループとは別のリソースグループに仮想マシンを作成したい
- 5：結局、どんな権限が最低限必要なの？
- 6：最後に
1：最初に注意事項と免責事項
本記事は執筆時点（2026/01初旬）の情報をもとに記述しています。
Azure Localは皆さんご存じの通り「Azureのサービス」であり、オンプレミスに展開されるクラウドサービスです。
したがって、サービスの進化に応じて何かしらの仕様が変更される可能性もありますので、必ずMicrosoftのドキュメントを参照して最新の情報を確認してください。
2：公式情報は？
Azure Local利用者のロールについて記述されたドキュメントは以下のものになります。
仮想マシンを作成する、という点においては「Azure Stack HCI VM 共同作成者」のロールが必要なようですね。
では、どのレベルで当該ロールを割り当てればよいでしょうか、という話になると思いますが、そのあたりを実際の割り当て例と合わせて整理していきたいと思います。
3：一番単純な方法・Azure Localのリソースグループに割り当てる
一番単純な方法は「Azure Localをデプロイしたリソースグループに割り当てる」です。
例えば画面1のようなAzure Localがデプロイされたリソースグループがあったとしましょう。
このリソースグループに「Azure Stack HCI VM 共同作成者（Azure Stack HCI VM Contributor）」のロールが割り当てられたユーザーを登録します（画面2）。
この状態で権限のあるユーザー（今回の場合gotosatoというユーザー）でAzureポータルにサインインすると、Azure Local上に仮想マシンを作成することができます。
画面3は仮想マシン作成の画面となりますが、権限を割り当てたリソースグループを指定して仮想マシンを作成していますが、仮想マシンは無事作成され、Azure Arcのオンボード（ゲスト管理の有効化）も完了しました。ゲスト管理を有効化する際は、「Azure Stack HCI VM 共同作成者（Azure Stack HCI VM Contributor）」のロールがあればOKです。別途「Azure Connected Machine Onboarding」のロール付与は必要ありません。
4：Azure Localのリソースグループとは別のリソースグループに仮想マシンを作成したい
前述のように、Azure Localのリソースグループに権限を割り当てて、そのリソースグループを指定して仮想マシンを作成すると、仮想マシンのリソースがAzure Localと同じリソースグループに作成されてしまいます。運用上は、やはりシステムリソースとユーザーリソースは分けたいところですね。
というわけで、今度は仮想マシン専用のリソースグループを作成して、そこに仮想マシンを作成したいと思います。
前項でAzure Localのリソースグループに登録したユーザーは削除したうえで、「AzLocal20VM」というリソースグループを作成／ユーザーを登録し、「Azure Stack HCI VM 共同作成者（Azure Stack HCI VM Contributor）」のロールを割り当てます（画面4）。
この状態で仮想マシンを作成しようとしても、仮想マシンを作成する画面にたどり着けません。仮想マシン用のリソースグループに、「Azure Stack HCI VM 共同作成者（Azure Stack HCI VM Contributor）」の権限を有していても、仮想マシンを作成するために必要なリソースへのアクセス権がないために、このような事態が発生します。
では、どのようなリソースに対する権限が必要なのか。回答は実は「権限のない状態でAzure Local上に仮想マシンを作成した」際に表示されています（画面5）
なるほど、「カスタムの場所」と「OSギャラリーイメージ」、「ネットワークインターフェース」にアクセス権があればよいのですね。
上記のアクセス権の必要なリソースですが、Azureポータル上の表記と少しずれているので、Azure Localのリソース種類名と合わせると、表1のようになります。
| エラー画面表記 | ポータル上のリソース種類名 |
|---|---|
| カスタムの場所 | カスタムの場所 |
| OSギャラリーイメージ | Azure Localギャラリーイメージ |
| ネットワークインターフェース | Azure Local論理ネットワーク |
| 表1：エラー画面とAzureポータルでの表記対応表 | |
ネットワークインターフェースは紛らわしいですけども、仮想マシンのネットワークインターフェースを作るためのもともとのリソースに対してアクセスしなければならないので論理ネットワークへのアクセスが必要になる、という感じですね。
Azure LocalギャラリーイメージやAzure Local論理ネットワークは、作成時にリソースグループを指定可能なので、Azure Localクラスターが存在するリソースグループ以外のリソースグループにも適切な権限（Azure Stack HCI Administrator）があれば作成可能です。
VM専用リソースグループに論理ネットワークとギャラリーイメージを追加したものが画面6になります。
カスタムの場所についてはAzure LocalクラスターやAzure Resource Bridge（ARB）とともにAzure Localのシステムの一部としてデプロイされるので、新規で異なるリソースグループに作成することができないかと思います。ですので、現在の「カスタムの場所」というリソースに対して「Azure Stack HCI VM 共同作成者（Azure Stack HCI VM Contributor）」の権限が付与されたユーザーを追加します（画面7）。
実はこれだけの権限だと、仮想マシン作成画面にたどり着けない（＝権限が足りない）状態になっています。何が足りないかというと、Azure Localのいくつかのリソースに対する閲覧者権限です。
Azure Localのクラスターが存在するリソースグループに対して閲覧者権限を付与してもよいのですが、Key Vaultなどの余計なリソースを見せたくない場合には、以下のリソースに対して個別に閲覧者権限を付与します。
- Azure Local
- リソースブリッジ
- ストレージパス
前述の「Azure Stack HCI VM 共同作成者（Azure Stack HCI VM Contributor）」の権限付与、並びに3つのリソースに対して閲覧者権限を付与することで、Azure Localのリソースグループとは異なるリソースグループに仮想マシンを作成することができることを検証環境にて確認しました。
ここまでロールを細かく設定すれば、特定の論理ネットワークを使用可能なユーザーを限定したり、他のユーザーが作成した仮想マシンを参照できなくするなどのアクセス制限をすることが可能となりますね。
実際作成するとこんな感じですね（画面8）。
細かく権限を割り当てることで、Azure Local上の仮想マシンの閲覧や作成、余計なリソースを参照させない、などの制御を行うことができますが、細かくやればやるほど運用コストが増えていくことが懸念されますので、そのあたりはトレードオフの関係といってもよいかもしれません。
5：結局、どんな権限が最低限必要なの？
ユーザーに対して「Azure Stack HCI VM 共同作成者（Azure Stack HCI VM Contributor）」の権限を適切なリソースに付与し、さらに閲覧者の権限を適切なリソースに対して付与することで、仮想マシンのデプロイを行うことは可能です。
「Azure Stack HCI VM 共同作成者（Azure Stack HCI VM Contributor）」が必要なリソースは以下の通り。
- カスタムの場所
- VMをデプロイするリソースグループ（ここに論理ネットワークやギャラリーイメージを登録）
閲覧者の権限が必要なリソースは以下の通りです。
- Azure Local
- リソースブリッジ
- ストレージパス
リソースグループの配置については、前項で解説した通りですが、論理ネットワークごとにリソースグループを作成するのは、AzureのvNetの考え方に近いものがあるのかもしれませんね。
ギャラリーイメージについては、さまざまなユーザーから参照されるライブラリ的な使い方が良いかと思いますので、ギャラリーイメージ専用のリソースグループを作成し、そのリソースグループに対してはすべてのAzure Local利用者に対してアクセス権を与える、という使い方が考えられます。
6：最後に
Azure Localの利用者観点での権限とリソースグループの構成を整理してみました。
利用者アカウントに対する権限付与や、実際のリソースが登録されるリソースグループの構成は、ユーザーごとのリソースアクセスに密接に関係するため、非常に重要な部分になると思います。
本記事が、適切なアカウント設計や権限付与、リソースグループ設計の参考になれば幸いです。
書いた人：後藤 諭史（Satoshi GOTO）
ソリューションアーキテクト部所属。
専門はWindows Server Hyper-VやAzure LocalといったMicrosoft仮想化技術。Microsoft SDN（Hyper-V Network Virtualization）などのWindows Server ネットワーク技術も。
Microsoft オンプレ技術以外にも、エンタープライズネットワークとかMicrosoft Azureとか、運用とか。
ネットワークやハードウェアといった物理層に近いところが大好きな、昔ながらのインフラ屋さん。得意技はケーブル整線。
Microsoft MVP for Cloud and Datacenter Management（2012-2026）
Microsoft MVP for Microsoft Azure（2024-2026）
