Microsoft Entra ID（旧Azure AD）を触りはじめて、最初にやることになるのがユーザーとグループの管理です。「新しく入った人のアカウントを作る」「部署ごとにアクセス権を分ける」といった、いわばAzure運用のいちばん土台の部分ですね。
ところが、いざMicrosoft Learnの公式ドキュメントを開くと、機械翻訳まじりの説明と大量の画面用語に押されて、「で、結局どこをどう触ればいいの？」と手が止まってしまう。私自身、Azureを学びはじめた頃にまさにここでつまずきました。
「ユーザーとグループって、それぞれ何のために作るの？権限はどっちに付けるのが正解なの？」
この記事では、Entra管理センターでのユーザー作成・管理、グループ（セキュリティ／Microsoft 365）の使い分けとメンバー管理、そして少し進んだ動的グループ（属性で自動的にメンバーが決まる仕組み）までを、公式の正確さは押さえつつ、初心者がつまずく所を日本語で噛み砕いて解説します。読み終わるころには「誰にどうアクセス権を渡すか」を自分で設計できるようになります。
なお、そもそもEntra IDが何者なのか全体像があやふやな方は、先に Microsoft Entra IDの基本機能と活用方法 に目を通しておくと、この記事の位置づけがはっきりします。本記事はその中の「ユーザー・グループ管理」を深掘りする子記事です。
まず押さえたい「ユーザー」と「グループ」の役割分担
手を動かす前に、この2つの関係だけ頭に入れておくと迷いません。会社の建物にたとえると分かりやすいです。
ユーザーは「社員証を持った一人ひとり」です。田中さん、佐藤さんといった個人。これがないとそもそもAzureにもMicrosoft 365にもログインできません。一方のグループは「部署」や「プロジェクトチーム」のような、社員をまとめる箱です。
ここで実務上いちばん大事な原則があります。権限は、できるだけ個人ではなくグループに付けるということです。理由はシンプルで、田中さん個人に10個の権限を直付けしていると、田中さんが異動・退職したときに10個を手で外すことになります。でも「経理グループ」に権限を付けておけば、田中さんをグループから外すだけで済む。人の入れ替わりに強い設計になるわけです。
この記事はその順番どおり、まずユーザーを作る→次にグループにまとめる→さらに属性で自動的にまとめる（動的グループ）、と進んでいきます。
ユーザーを作成・管理する
操作の入り口は Microsoft Entra管理センター（entra.microsoft.com）です。左メニューの「ID」→「ユーザー」→「すべてのユーザー」を開き、上部の「新しいユーザー」から「新しいユーザーの作成」を選びます。Azureポータル（portal.azure.com）内のEntra IDからでも同じ画面にたどり着けるので、見慣れたほうで構いません。
作成時に迷いやすい項目
入力欄はたくさん並んでいますが、最初に必須なのは基本的に2つだけです。ユーザープリンシパル名（UPN）と表示名ですね。UPNは tanaka@yourcompany.onmicrosoft.com のような、そのユーザーの「ログインID兼メールアドレス」にあたる文字列です。@の後ろのドメイン部分は、テナントが持っているドメインの中から選ぶ形になります。
パスワードは「自動生成」のままにしておき、初回サインイン時に本人へ変更させるのが基本です。作成直後に表示される初期パスワードは一度しか出ないので、コピーし忘れに注意してください。ここで慌てて閉じてしまうと、あとでパスワードのリセットからやり直すハメになります（私は一度やりました）。
作成後、そのユーザーを開くと「プロパティ」タブから部署（Department）・役職（Job title）・勤務地といったプロファイル情報を編集できます。ここは飾りではなく、後半で扱う動的グループのルールで参照される重要な情報になります。「部署」を空欄のまま運用しはじめると、あとで自動化しようとしたときに効いてこないので、最初から埋めておくクセをつけておくと後がラクです。
退職・休職のときは「削除」ではなく「無効化」
もう一つ、初心者がやりがちなのが「もう使わないから」とアカウントをいきなり削除してしまうことです。実務では、まずサインインのブロック（無効化）から入るのが定石です。ユーザーの「プロパティ」で「サインインのブロック」を「はい」にすると、アカウントは残したままログインだけを止められます。
なぜ削除ではなく無効化かというと、削除するとそのユーザーが所有していたデータやライセンスの割り当てが一気に外れてしまい、復帰時や監査時に困るからです。削除したユーザーは30日間だけ「削除済みユーザー」から復元できますが、その保険に頼るより、いったん無効化して様子を見るほうが安全です。
「とりあえず無効化、本当に不要と確定したら削除」。この二段構えを覚えておくだけで事故がぐっと減ります。
大量に作るなら一括インポートも
入社シーズンなどで一度に何十人も追加するときは、一人ずつ画面で作るのは現実的ではありません。ユーザー一覧の上部にある「ユーザーの一括操作」からCSVテンプレートをダウンロードし、UPN・表示名などを埋めてアップロードすれば、まとめて作成できます。まずは1人を手作業で作って画面の項目を理解し、慣れたらCSVに移行する、という順番がおすすめです。
グループを作ってメンバーを管理する
ユーザーが揃ったら、次はグループでまとめます。作成場所は「ID」→「グループ」→「すべてのグループ」→「新しいグループ」です。ここでまず選ばされるのがグループの種類で、初心者が最初に「どっち？」と固まるポイントなので、違いをはっきりさせておきましょう。
セキュリティ vs Microsoft 365 の使い分け
セキュリティグループは、リソースへのアクセス権をまとめて渡すためのグループです。「このグループにAzureの読み取り権限を付与」「このグループにだけ特定アプリの利用を許可」といった、権限管理が主目的。Azureのロール割り当て（RBAC）でよく相手にするのはこちらです。
対してMicrosoft 365グループは、グループを作ると同時に共有メールボックス・SharePointサイト・Teamsとの連携などがセットで付いてくる、コラボレーション向けのグループです。プロジェクトメンバーで資料やチャットを共有したい、というときはこちら。
迷ったときの判断はシンプルで、「アクセス権を配りたいだけ」ならセキュリティグループ、「みんなで共有スペースを持ちたい」ならMicrosoft 365グループです。この記事の主眼であるAzureの権限管理では、基本的にセキュリティグループを選んでおけば問題ありません。
メンバーの管理と「割り当て済み」の意味
グループ作成時、種類の下に「メンバーシップの種類」という項目があります。ここで「割り当て済み（Assigned）」を選ぶと、メンバーを手動で足したり外したりするふつうのグループになります。まずはこれで問題ありません。
作成後、グループを開いて「メンバー」→「メンバーの追加」から、先ほど作ったユーザーを検索して入れていきます。逆に外したいときはメンバー一覧でチェックして「削除」。この追加・削除がそのまま「誰にアクセス権があるか」に直結するので、グループにRBACのロールを割り当てておけば、あとは人の出入りに合わせてメンバーを足し引きするだけで権限管理が回ります。冒頭で触れた「権限はグループに付ける」の実物がこれです。
動的グループ：属性でメンバーを自動化する
ここまでの「割り当て済み」グループは便利ですが、規模が大きくなると弱点が出ます。人の追加・削除を毎回手でやらないといけないのです。新しく営業部に人が入るたびに「営業グループへ手動で追加」を忘れずやる——現実にはこれ、必ず抜け漏れます。
そこで登場するのが動的グループ（動的メンバーシップ）です。これは「メンバーを人が決める」のではなく、ユーザーの属性を条件にして、メンバーを自動で出し入れするグループです。
仕組みのイメージ
たとえば「部署（department）が営業（Sales）の人」というルールを設定しておくと、ユーザーのプロファイルの部署が「Sales」の人は自動的にこのグループのメンバーになります。逆に、その人が別部署に異動して部署の値が書き換わると、ルールに合わなくなった時点で自動的にグループから外れます。前半で「プロファイルの部署を埋めておこう」と念押ししたのは、まさにこの自動判定で使われるからです。
設定は、グループ作成時に「メンバーシップの種類」で「動的ユーザー」を選び、ルールを書くだけです。GUIの「動的メンバーシップ規則」で属性・演算子・値を選んでいくと、次のようなルール式が組み上がります。
(user.department -eq "Sales")複数条件を組み合わせることもできます。たとえば「日本にいる営業部の人」なら、こう書きます。
(user.department -eq "Sales") -and (user.country -eq "Japan")読み方は難しくありません。user.department が参照する属性、-eq が「等しい」という演算子、"Sales" が比較する値です。-eq のほかに -contains（含む）や -startsWith（で始まる）などが使えるので、「部署名が『営業』で始まる人すべて」といった柔軟な条件も作れます。
つまずきポイントと前提条件
便利な動的グループですが、使う前に知っておくべき注意点が2つあります。
1つ目は反映に時間差があること。属性を変えても、グループへの反映は即時ではなく、数分程度かかることがあります。「ルールを書いたのにメンバーに出てこない」と焦る前に、少し待ってから確認してください。テナントの規模によっては、もう少しかかることもあります。
2つ目はライセンスが必要なこと。動的メンバーシップは、対象ユーザーにMicrosoft Entra ID P1以上のライセンスが必要な有償機能です。無料版のEntra IDでは「動的ユーザー」を選べません。学習で試すだけなら、期間限定の評価版テナントを使うと費用をかけずに触れます。
ちなみにP1は動的グループのためだけの機能ではなく、条件付きアクセス（「社外ネットワークからのアクセス時はMFAを必須にする」といったアクセス制御）などもここに含まれます。動的グループで「営業部の人」を自動的にまとめておき、そのグループを条件付きアクセスの対象にする、という合わせ技はよくある実務パターンです。ただ、条件付きアクセスは話が大きくなるのでこの記事では深追いせず、別途取り上げます。ここでは「動的グループとP1はセットで出てくる」とだけ覚えておけば十分です。
まとめ
この記事では、Entra IDのユーザー・グループ管理を、実務でつまずく順に見てきました。要点を振り返っておきます。
- ユーザー：Entra管理センターで作成。UPNと表示名が要。プロファイルの「部署」は動的グループで効くので埋めておく。
- 退職・休職：いきなり削除せず、まずサインインのブロック（無効化）から。削除は本当に不要と確定してから。
- グループの種類：アクセス権を配るならセキュリティグループ、共有スペースが欲しいならMicrosoft 365グループ。
- 権限は個人ではなくグループに付ける。人の入れ替わりに強くなる。
- 動的グループ：属性ルールでメンバーを自動管理。反映に時間差あり・P1ライセンス必須という前提を忘れずに。
ここまでできれば、「誰に、どうやってアクセス権を渡すか」という設計の土台は固まりました。次のステップは、そうして整理したユーザー・グループに対して実際にどうアクセスを制御するか——多要素認証（MFA）や条件付きアクセスの世界です。そちらは別記事で扱います。
あわせて読みたい：
