Azure Local（Azure Stack HCI）を Hyper‑V ホストにデプロイする際、検証ステップで「ValidateArcIntegration」「MSI@50342 does not have access…」といったエラーにより Arc 統合が通らないことがあります。本記事では MSI@50342 の正体、発生しやすい条件、RBAC と Az モジュール統一で確実に検証を通すための手順を Q&A 形式で整理します。
Azure Local（Azure Stack HCI）デプロイ時の Arc 統合検証エラーとは
2 台の Hyper‑V ホスト（同一ハードウェア・同一 OS）に Azure Local（Azure Stack HCI）をデプロイしていると、検証フェーズで次のようなエラーが出るケースがあります。
Type ‘ValidateArcIntegration’ of Role ‘EnvironmentValidator’ raised an exception:
“The provided account MSI@50342 does not have access to subscription ID “7080……”.
Please try logging in with different credentials or a different subscription ID…”
このメッセージが厄介なのは、次のような「見えづらい」状況が同時に起こりやすい点です。
- Entra ID（旧 Azure AD）のユーザー一覧やエンタープライズ アプリに MSI@50342 が見当たらない
- 途中で「通ったように見えた」のに、別のタイミングで同じエラーが再発する
- ノードは同じ構成なのに、結果が不安定（片方だけ失敗、再実行で結果が変わる など）
結論から言うと、この手の ValidateArcIntegration 失敗は「ID の正体」＋「RBAC」＋「PowerShell Az モジュールの整合性」＋「テナント／サブスクの接続コンテキスト」を揃えると収束することが多いです。
結論：MSI@50342 の正体と、失敗が起こる代表パターン
MSI@50342 は「ユーザー」ではなく、システム割り当てマネージド ID
MSI@50342 は、実在のユーザー アカウントではありません。Azure Local（Azure Stack HCI）/ Azure Arc 連携の検証・登録処理の中で利用されるシステム割り当てマネージド ID（Managed Identity）が、ログ上で「MSI@xxxxx」のような形で見えているものです。
そのため、Entra ID の「ユーザー」一覧に出てこないのは正常です。見え方としては、Azure 側の対象リソース（Azure Stack HCI クラスター リソース等）に紐づくサービス プリンシパル（ID）として扱われます。
ValidateArcIntegration が落ちる直接原因は「その MSI に RBAC が足りない」
エラーメッセージに書かれている通り、検証処理が MSI（マネージド ID）で対象サブスクリプションへアクセスしようとした際に、必要な RBAC ロールが付与されておらず失敗しています。
「途中で通ったように見えた」→ 再発するのは、複数要因が重なっているサイン
このエラーが一度だけでなく、通過したように見えた後にも再発する場合、次のような“揺れ”が起きがちです。
- 検証が複数ノードで段階的に走る（あるノードでは通っても、別ノードの処理で落ちる）
- 処理の途中で参照する ID が変わる（最初は実行者のコンテキスト、後半で MSI を使う、など）
- Az.* モジュールのバージョンや構成がノード間で不一致で、同じコマンドでも挙動がブレる
- サブスクリプション／テナント コンテキストが意図せず切り替わる（別の既定サブスク、別テナントでログインしている等）
まずは状況整理：切り分けの全体像（最短で当たりを付ける）
| 症状 | 疑うポイント | すぐできる確認 | 改善の方向性 |
|---|---|---|---|
| MSI@xxxxx がサブスクにアクセスできない | マネージド ID の RBAC 不足 | Azure ポータルで IAM を確認 | 対象スコープに Contributor 以上を付与 |
| 同じ手順なのに、通ったり落ちたりする | Az モジュール不整合／自動導入 | 各ノードの Get-InstalledModule | 全ノードで同一バージョンに固定 |
| 想定外のサブスク ID を参照している気がする | 接続コンテキスト不一致 | Get-AzContext / Get-AzConfig | TenantId/SubscriptionId を明示して再接続 |
| 実行者は Owner なのに落ちる | 実行者ではなく MSI 側が不足 | IAM の「対象メンバー」を確認 | “クラスター リソースのマネージド ID” に付与 |
Q&A：MSI@50342 の正体と「見つからない理由」
Q. MSI@50342 は誰ですか？勝手に作られたユーザーですか？
A. ユーザーではありません。検証処理が利用するシステム割り当てマネージド IDが、ログ上で MSI@50342 のように表示されています。Azure Local / Azure Stack HCI の Arc 統合では、処理の一部をこの ID（サービス プリンシパル相当）で実行するため、サブスクリプションに対する権限が必要になります。
Q. Entra ID の「ユーザー」や「エンタープライズ アプリ」に見当たりません
A. “ユーザー一覧にいない”のは自然です。マネージド ID は、Azure 上の対象リソースに紐づく ID として管理されるため、見つけ方がユーザー検索と異なります。現場で確実なのは、「ロール割り当て時に、対象リソース（Azure Stack HCI クラスター等）を“マネージド ID”として選択する」方法です（後述）。
Q. なぜ「50342」のような番号が付くのですか？
A. 表示上の識別子であり、運用者が意図して作ったアカウント名ではありません。重要なのは “番号そのもの” ではなく、その MSI が Azure 側でアクセスしようとしているのに RBAC が足りないという事実です。
解決手順：検証を確実に通すための実践セット
ここからは、実際に Arc 統合の ValidateArcIntegration を安定して通すための手順を、順番にまとめます。ポイントは「全ノードで同じ状態を作る」ことです。
手順1：Azure への接続コンテキスト（テナント／サブスク）を明示して揃える
まず、デプロイを実行する PowerShell セッションで「今どのサブスクリプション／テナントを見ているか」を固定します。特に、複数サブスク・複数テナントを扱っている環境では必須です。
現在のコンテキスト確認
Get-AzContext
# 必要に応じて
Get-AzConfigテナント／サブスクリプションを明示して接続
Connect-AzAccount -TenantId <テナントID> -SubscriptionId <サブスクリプションID>（任意）明示的にコンテキストを設定
Set-AzContext -TenantId <テナントID> -SubscriptionId <サブスクリプションID>また、作業端末やサーバーで過去のコンテキストが自動保存されていると、意図せず別サブスクに向くことがあります。検証中だけでもコンテキスト自動保存を抑止したい場合は、プロセス スコープで無効化するのが安全です。
Disable-AzContextAutosave -Scope Process実行アカウントの権限としては、対象サブスクリプションに対して最低でも Owner または Contributor を持っていることを確認してください（ただし今回の主役は MSI 側の RBAC です。実行者が Owner でも MSI が無権限なら落ちます）。
手順2：マネージド ID（MSI@50342 相当）に RBAC を付与する
ここが最重要です。ValidateArcIntegration は MSI でサブスクリプション内のリソースへアクセスしようとするため、その MSI に RBAC を付けます。
RBAC を付与する“考え方”
- 「MSI@50342 という名前のユーザーを探して付与」ではありません
- 「Azure Stack HCI クラスター（または関連リソース）に紐づくシステム割り当て ID」に対して付与します
- 付与スコープは、運用ポリシーにより「サブスクリプション」または「リソース グループ」が選択肢になります
推奨の付与先とロール（迷ったときの指針）
| 付与スコープ | 推奨ロール | メリット | 注意点 |
|---|---|---|---|
| リソース グループ（Azure Local/Arc 関連を集約） | Contributor | 最小権限に寄せやすい | 関連リソースが別 RG に散ると不足する |
| サブスクリプション | Contributor（必要に応じて Owner） | 検証・デプロイ時の権限不足を潰しやすい | 権限が広い（統制が必要） |
Azure ポータルでの代表的な付与手順
- 対象の サブスクリプション または リソース グループ を開く
- 「アクセス制御（IAM）」 → 「追加」 → 「ロール割り当ての追加」
- ロールに Contributor（必要なら Owner）を選択
- メンバーの選択で 「マネージド ID」 を選ぶ
- マネージド ID の種類から Azure Stack HCI / Azure Local に相当するリソース種別を選び、対象クラスター（または関連リソース）を指定して追加
この操作により、裏側ではそのリソースのシステム割り当てマネージド IDにロールが付与されます。結果として、ログ上では MSI@50342 のように見えていた主体が、サブスクリプションへアクセスできるようになります。
ポイント：RBAC の反映には多少のタイムラグがあるように見えることがあります。検証を連続で叩いていると「さっき通った／落ちた」が混在しやすいため、RBAC 付与後は一度セッションや検証プロセスを整理してから再実行すると安定します。
手順3：Az PowerShell モジュールのバージョンを“全ノードで完全一致”させる
Arc 統合周りは PowerShell Az モジュールを利用する場面が多く、ノード間で Az.Accounts / Az.Resources などのバージョンが揃っていないと、同じ検証でも結果がブレる原因になります。
さらに厄介なのが、検証・デプロイの途中で別バージョンが自動的に入ったように見える状況です。結果として、次のような状態になります。
- ノードA：Az.Accounts 4.x
- ノードB：Az.Accounts 5.x が混在
- 同じ ValidateArcIntegration でも内部の認証処理が変わり、挙動が不安定
まずは全ノードで現状確認
各ノードで、インストール済みモジュールとバージョンを確認します。
Get-InstalledModule -Name Az.Accounts -AllVersions
Get-InstalledModule -Name Az.Resources -AllVersions複数ノードをまとめて確認したい場合は、管理用端末から PowerShell リモートで横断チェックすると見落としが減ります。
$nodes = @("NODE01","NODE02")
Invoke-Command -ComputerName $nodes -ScriptBlock {
"=== $env:COMPUTERNAME ==="
Get-InstalledModule -Name Az.Accounts -AllVersions | Select-Object Name,Version
Get-InstalledModule -Name Az.Resources -AllVersions | Select-Object Name,Version
}Az.Accounts は「単一バージョン運用」に寄せる
実例として、Az.Accounts を 4.0.2 のみに揃えたことで安定したケースがあります（特定時点の検証ツールや依存関係が、この系統のバージョンを前提としている場合があります）。重要なのは「4.0.2 でなければ絶対ダメ」というより、混在を作らず、全ノード同一にすることです。
4.0.2 以外を削除し、必要なら 4.0.2 を入れ直す例
# 4.0.2 以外を削除
Get-InstalledModule -Name Az.Accounts -AllVersions |
Where-Object { $_.Version -ne '4.0.2' } |
ForEach-Object {
Uninstall-Module -Name Az.Accounts -RequiredVersion $_.Version -Force
}
# 必要なら 4.0.2 をインストール
Install-Module -Name Az.Accounts -RequiredVersion "4.0.2" `
-Force -AllowClobber -SkipPublisherCheckAz.Resources など他モジュールも、全ノードで同一バージョンへ
Az.Resources なども、片方だけ新しい／古いがあると不具合の温床になります。ここは「どのバージョンが正」ではなく、クラスター全体で同じバージョンに揃えるのが主目的です。
Get-InstalledModule -Name Az.Accounts,Az.Resources -AllVersionsモジュール不整合が起きやすい“現場あるある”
- インストール先が混在（AllUsers と CurrentUser、PowerShell 5.1 と 7、など）
- 別ツールが依存関係で Az を追加導入し、結果としてバージョンが増える
- 検証用の PowerShell セッションと、実際にデプロイが使う実行コンテキストが異なり、参照されるモジュールが変わる
運用的には、デプロイに使う PowerShell（多くの環境では Windows PowerShell 5.1）を決め打ちし、“その実行環境で見える Az.* を揃える”のが事故を減らします。
手順4：再検証で通らない場合の「再発防止チェック」
RBAC とモジュール統一を行ってもまだ落ちる場合、次の観点を追加で確認すると、原因の取りこぼしを減らせます。
| チェック項目 | 確認の観点 | 確認例 |
|---|---|---|
| サブスクリプション ID の一致 | 検証が狙いのサブスクを見ているか | Get-AzContext の Subscription |
| テナント ID の一致 | 別テナントにログインしていないか | Get-AzContext の Tenant |
| MSI の付与スコープ | 必要な範囲に RBAC が付いているか | IAM のロール割り当て一覧 |
| ノード間の Az モジュール一致 | バージョン・複数混在がないか | Get-InstalledModule -AllVersions |
| 再実行時のキャッシュ | 古いトークンや状態を引きずっていないか | PowerShell セッションを作り直す |
「通ったように見えたのに再度失敗」の理由を、動きで理解する
現場で混乱しやすいのが、まさにこのパターンです。見た目としては「一瞬通過した」ので、原因が別にあるように錯覚します。
しかし、ValidateArcIntegration のような検証は、次のような“複合処理”になりやすいです。
- 検証が 1 回ではなく、フェーズやノードを変えて複数回走る
- 初期フェーズは実行者コンテキストで進み、後半でMSI（マネージド ID）に切り替わる
- ノードごとに参照する Az モジュールが異なると、同じ認証処理でも結果が変わる
つまり、「途中で通った」は “問題が解決した” ではなく “その回・そのフェーズ・そのノードでは条件が揃っていた”に過ぎないことがあります。最終的に安定させるには、RBAC とモジュール整合性を全ノード・全フェーズで揃えるのが近道です。
最終的に何を揃えたら解決したのか（実務の答え）
同様の事例で「これを揃えたら Arc 統合検証が通り、デプロイが完了した」という最終セットは、次の 3 点に集約されます。
- MSI（システム割り当てマネージド ID）に RBAC を付与（少なくとも Contributor）
- 全 Hyper‑V ノードで Az.* モジュール構成を完全一致（Az.Accounts / Az.Resources 等）
- Connect-AzAccount のテナント／サブスク コンテキストを明示し、ズレを排除
特に、MSI@50342 を「存在しないユーザー」として追いかけ続けると遠回りになりがちです。“MSI はリソースに紐づく ID。権限は IAM で付ける”と捉え直すと、切り分けが急にシンプルになります。
実運用でのコツ：次回から詰まらないためのチェックリスト
デプロイ前にやっておくと強いこと
- 作業アカウントの TenantId / SubscriptionId を明示して接続する習慣をつける
- Az.* モジュールは全ノードで事前に同一バージョンを配備し、混在を作らない
- Azure Local / Azure Stack HCI 関連リソースをまとめる 専用リソース グループを用意し、MSI の RBAC もそこへ集約する
検証エラーが出たときのおすすめ切り分け順
Get-AzContext/Get-AzConfigでサブスクリプション＆テナントを確認- 実行アカウントの RBAC（Owner/Contributor）を確認
- マネージド ID の RBAC（最低 Contributor）を確認
- 全ホストで Az.* の構成（特に Az.Accounts, Az.Resources）を完全一致させる
まとめ：MSI@50342 は“犯人”ではなく“権限不足を知らせるサイン”
ValidateArcIntegration の「MSI@50342 does not have access…」は、見慣れない文字列のせいで混乱しやすいものの、本質はシンプルです。
- MSI@50342 はユーザーではなく、Arc 統合が使うマネージド ID
- その ID に RBAC が無いと検証が失敗する
- Az モジュール不整合があると、途中で通ったり落ちたりして原因が見えにくくなる
RBAC（MSI 側）と Az.*（全ノード一致）と接続コンテキスト（テナント／サブスク明示）を揃えれば、同様の環境でも Arc 統合の検証が通り、Azure Local（Azure Stack HCI）のデプロイ完走につながります。
コメント