Azureのリソースから別のAzureリソースへアクセスするとき、接続文字列やシークレットをどこかに書いていませんか。App Service から Blob ストレージへ読み書きする、仮想マシンから Azure CLI を叩く——こうした場面で資格情報を1つも管理せずに済ませるのがマネージドIDです。

この記事では、2種類のマネージドIDの違いと、実際に画面とコマンドで何が起きるのかを、手を動かす順番で説明します。

マネージドIDとは何か

Entra ID には、人のためのユーザーIDがあります。ユーザーを作り、リソースグループやサブスクリプションに対して権限（ロール）を割り当てる。この流れはおなじみです。

マネージドIDは、これと同じことを「Azureのリソース」に対してやる仕組みです。 仮想マシンやApp Service、Automationアカウントといったリソースに対して、Entra ID 上のIDを自動的に作り、そのIDに権限を割り当てます。

パスワードもシークレットも登場しません。トークンの取得はAzureの裏側が行い、そのIDが本物であることの確認まで含めて面倒を見てくれます。

マネージドIDにはシステム割り当てとユーザー割り当ての2種類があります。

システム割り当てマネージドID

リソースに紐づくIDです。仮想マシンやAutomationアカウントの作成ウィザード、あるいは作成後の「ID」設定画面で、スイッチをオンにするだけで作られます。

オンにすると、Entra ID 側に対応するIDが自動的に作られ、オブジェクトIDが画面に表示されます。

Entra ID 側ではどう見えるか

表示されたオブジェクトIDをコピーして、Entra ID のエンタープライズアプリケーションで検索すると、そのIDが見つかります。

「なぜアプリケーションなのか」と思うかもしれませんが、ここは深追いしなくて構いません。アプリケーションを登録したのと同じ扱いのIDが、Entra ID 上に出来ている——最初はそう理解しておけば十分です。Entra ID 上にIDがあるのだから、そこに権限を割り当てられる、という話につながります。

実際に使ってみる

仮想マシンにサインインして、次のコマンドを実行します。

az login --identity

az login --help を見ると、システム割り当てマネージドIDでログインする場合は --identity オプションを付けるように書かれています。

実行すると、パスワードは一切聞かれません。ただし、IDを作っただけの状態では次のように言われます。サブスクリプションへの権限がまだ無いからです。

サブスクリプションが見つからない（権限が割り当てられていない）

ロールを割り当てる

サブスクリプション（またはリソースグループ）の「アクセス制御 (IAM)」から、ロールの割り当てを追加します。ここで大事なのが、メンバーを選ぶときの分類です。

「ユーザー、グループ、またはサービスプリンシパル」ではなく、「マネージドID」を選びます。 マネージドIDは専用の選択肢として用意されていて、種類（仮想マシン、Automationアカウントなど）で絞り込めます。これは、エンタープライズアプリケーションの一覧から探すより明らかに分かりやすくするための配慮です。

閲覧者ロールを割り当ててから、もう一度 az login --identity を実行すると、今度は通ります。

az resource list

リソースの一覧が普通に取れます。認証のために何も入力していません。 サインインログを見ると、システム割り当てIDを使って認証したことが記録されています。

Azure CLI に限った話ではありません。Entra ID の認証が必要なものには、マネージドIDで認証するオプションがほぼ必ず用意されています。

ここまでの流れ（IDを有効化し、Entra ID 側で確認し、ロールを割り当て、CLIで入る）は、15分の動画（無料）で実際の画面のまま見られます。ポータルのどのメニューに何があるかは、文章より画面のほうが速いです。

システム割り当ての限界

システム割り当てIDは、リソースと一生をともにします。スイッチをオフにするとIDは消え、権限も失われます。 オフにしてから az login --identity を実行すると、IDが見つからないというエラーになります。これは正しい挙動です。

そして、ここが実運用で効いてくる制約です。負荷が上がって仮想マシンを1台追加したとしましょう。新しい仮想マシンには、まだIDがありません。 IDを有効化し、権限を割り当て直す作業が、増やすたびに発生します。

ユーザー割り当てマネージドID

そこで、IDを先に作っておくという選択肢が出てきます。これがユーザー割り当てマネージドIDです。

Azureポータルの「マネージドID」から作成します。なお、この一覧にシステム割り当てIDは表示されません。ここに並ぶのはユーザー割り当てマネージドIDだけです。自分の手で作れるのも、ユーザー割り当てのほうだけです。

作成時に指定するのはサブスクリプション、リソースグループ、リージョン、名前くらいで、難しい項目はありません。作成するとクライアントIDが表示されます。この値を後で使います。

使うときはクライアントIDを指定する

az login --identity --client-id <クライアントID>

ただし、この時点で実行しても失敗します。そのIDを仮想マシンにまだ割り当てていないからです。 自分に割り当てられていないIDは使えません。当たり前ではありますが、最初につまずくポイントです。

仮想マシンの「ID」設定 →「ユーザー割り当て済み」から、作成したIDを追加します。

ここの日本語表示は少し紛らわしく、「ユーザー割り当て済み」と出ますが、この時点ではまだ割り当てていません。「ユーザー割り当て型のマネージドID」という種類の名前だと読んでください。

追加してから同じコマンドを実行すると、今度は通ります。az group list などがそのまま使えます。

ユーザー割り当ての利点は「事前に決められる」こと

ユーザー割り当てマネージドIDは、1つのIDを複数のリソースで共有できます。逆に、1つのリソースに複数のユーザー割り当てIDを付けることもできます。

たとえば、仮想マシンに割り当てたIDを、そのままAutomationアカウントの「ID」設定から追加すれば、Automationアカウントも同じ権限で動けます。

もっとも典型的な使いどころは**仮想マシンスケールセット（VMSS）**です。負荷に応じてインスタンスが1台、2台、3台と増えていく仕組みでは、増えるたびにIDを作って権限を割り当てるやり方は現実的ではありません。

先にユーザー割り当てIDを作り、必要な権限をすべて割り当てておく。そのIDをスケールセット全体に構成しておけば、あとから増えたインスタンスも、最初から必要な権限を持った状態で動き始めます。

なお、ユーザー割り当てIDの設定画面にはフェデレーション資格情報という項目もあります。Entra ID の外部と連携するときに使うもので、最初のうちは気にしなくて構いません。

どちらを選ぶか

システム割り当て ユーザー割り当て
作り方 リソースの設定でスイッチをオンにする 自分で作成する
寿命 リソースと一体（オフにすると消える） リソースとは独立
事前の権限設計 リソースを作ってからでないとできない 先に作って権限を割り当てておける
共有 そのリソース専用 複数のリソースで共有できる
使うとき az login --identity az login --identity --client-id <ID>

システム割り当てのほうが圧倒的に手軽です。クライアントIDを覚える必要もなく、スイッチ1つで使えます。まずはシステム割り当てで考え、「リソースが増減する」「先に権限を決めておきたい」という要件が出てきたらユーザー割り当てを検討する——この順番で考えるのが実務的です。

いずれにしても、押さえるべき結論は1つです。Azureで権限管理をしたくなったら、最初に検討するのはマネージドIDです。 IDとパスワードを管理せずに、必要なものだけへ安全にアクセスできる。ここから外れる構成を選ぶときは、外れる理由を説明できるかを確認してください。