ローカルユーザーグループメンバーシップとは -Intuneで管理者権限を安全に制御する方法
2026.06.16
「ローカルのAdministratorsグループ、誰を入れたらいいのかわからない……」「追加と置換の違いで失敗した」「端末の用途によって設定を変えるべきなの？」
この記事は、そんな疑問を持ち始めた方に向けて書いています。Microsoft Intune（以下Intune）の設定手順そのものは前回までの記事で整理しました。今回は一段掘り下げて、「ローカルユーザーグループメンバーシップ」——つまり誰をどのローカルグループに入れるか——という管理の核心部分にフォーカスします。設定ミスが起きやすい「置換」の落とし穴や、端末の用途に応じた運用例まで、できるだけ実務に即して解説します。
この記事を読むと、以下の3つが理解できるようになります。
- ローカルグループ（Administrators等）の基本的な役割と管理上の注意点がわかる
- メンバーシップの「追加」と「置換」の違いと、安全な使い方が判断できる
- 端末の用途別の運用パターンと、よくあるトラブルの回避策が持てる
目次
1. ローカルグループ（Administrators等）の基本
Windowsの端末には、OS標準でいくつかのローカルグループが用意されています。その中でも特に管理上重要なのが「Administrators（管理者）グループ」です。
【用語メモ】 ローカルグループとは、個々のWindows端末上に存在するグループです。クラウド上のMicrosoft Entra ID（以下Entra ID）グループとは別物で、その端末内でのみ有効です。Administratorsグループのメンバーは端末に対してフルコントロール権限（ソフトのインストール・設定変更・他アカウントの管理など）を持ちます。
Administratorsグループには、デフォルトでWindowsの組み込みアカウント「Administrator」が含まれています。Entra ID参加（旧Azure AD参加）済みの端末では、加えてグローバル管理者やデバイス管理者のロールを持つEntra IDアカウントが構成やロールによっては自動的に追加される場合があります。 管理上おさえておきたいのは、「Administratorsグループに誰が入っているか」は端末ごとに異なる可能性があるという点です。組織全体で統一した管理をしなければ、「ある端末には一般社員が管理者グループに入っている」という状況が気づかないまま続くことがあります。
| グループ名 | 主な権限 | 管理上の注意 |
| Administrators | 端末へのフルコントロール（ソフトインストール・設定変更・他アカウント管理など） | 不要なアカウントが残りやすい。定期棚卸しが必要 |
| Users | 標準的な業務操作のみ（管理者権限なし） | 一般社員はここに分類するのが基本 |
| Remote Desktop Users | リモートデスクトップ接続のみ許可 | 遠隔サポートを許可する端末で設定する |
IntuneのアカウントポリシーはこのAdministratorsグループのメンバー構成を、Intune管理センターからMDM管理下の端末に対して一元的に制御する手段です。端末ごとに手作業でメンバーを管理する必要がなくなり、設定の統一と追跡が可能になります。
2. メンバーシップ管理の方針
– 「追加」と「置換」の考え方 –
Intuneのアカウント保護ポリシーでローカルグループメンバーシップを設定するとき、「グループとユーザーアクション」の選択が最も重要な判断になります。選択肢は大きく「追加」と「置換」の2系統に分かれますが、動作の違いを正しく理解していないと意図しない影響につながる可能性があります。
「追加（更新）」は既存のメンバーを維持しながら新しいメンバーを追加します。設定の影響範囲が限定的なため、初回設定や部分的な変更には最も安全な選択肢です。 「追加（置換）」はポリシーが適用された瞬間に現在のAdministratorsグループのメンバー全員を削除し、指定したメンバーだけで再構成します。「Administrators グループを完全に統制された状態にしたい」という目的では有効ですが、使い方を誤ると端末管理に必要なアカウントまで失われます。
「追加（置換）」を使う前に必ず確認すること
- 置換後のAdministratorsグループに、端末管理に必要な組み込みアカウントやEntra IDアカウントが含まれているか
- 適用対象の端末グループが意図した範囲に絞られているか（テナント全体への一律適用は危険）
- テスト端末1台で動作確認してから本番展開しているか
3. 端末用途別の運用例
– 標準端末 / 開発端末 / キッティング端末 –
ローカルユーザーグループメンバーシップの管理で最も避けたい失敗が「全端末に同じポリシーを一律に適用する」ことです。端末の用途によってAdministratorsグループに入れるべき対象が異なるため、用途ごとにグループを分けて管理することが実務では多く採用されます。 以下は代表的な3つの用途パターンです。
① 標準端末（一般社員向けPC）
一般社員が日常業務で使う端末では、ローカルAdministratorsグループへの一般社員の追加は原則行いません。管理者権限が不要な業務であれば、標準ユーザー（Usersグループ）のみで運用します。Intuneから配布されるアプリやポリシーで業務が完結できる構成を目指すのが理想です。
| 設定項目 | 内容 |
| Administratorsメンバー | 組み込みAdministratorアカウント（LAPS管理）＋Entra IDのデバイス管理者ロールのみ |
| 一般社員のローカル権限 | Usersグループ（標準ユーザー）のみ |
| 推奨アクション | 追加（更新）を推奨。置換の使用は事前検証を行った場合のみ |
② 開発端末（開発者・検証用PC）
開発者はローカルへのソフトウェアインストールや設定変更が業務上必要なことが多く、標準ユーザーでは作業が成立しないケースがあります。このような端末は「例外層」として位置づけ、Entra IDの開発者グループに所属するユーザーのみをAdministratorsに追加する設定を行います。
| 設定項目 | 内容 |
| Administratorsメンバー | 組み込みAdministratorアカウント（LAPS管理）＋Entra IDの「開発者グループ」 |
| 対象の端末グループ | 「開発端末グループ」のみ（一般社員端末グループには適用しない） |
| 推奨アクション | 追加（更新）で開発者グループを追加。グループのメンバーが変われば権限も自動連動 |
| 期限管理 | プロジェクト終了・異動時にEntra IDグループからメンバーを削除して権限を剥奪 |
③ キッティング端末（初期セットアップ専用PC）
新しい端末をセットアップする作業（キッティング）専用に使われる端末では、作業中は管理者権限が必要ですが、作業が終われば権限は不要です。「作業完了型」の期限付き付与が最も適したパターンです。
【用語メモ】 キッティングとは、新しいPCやスマートフォンを業務で使えるように初期設定・アプリインストール・セキュリティ設定などを行う準備作業のことです。
| 設定項目 | 内容 |
| Administratorsメンバー | キッティング担当者のEntra IDアカウントを一時追加 |
| 権限の付与期間 | 作業期間中のみ。完了後はメンバーから削除（削除（更新）アクションで実施） |
| 記録 | 申請→承認→実施→剥奪をすべて記録に残す |
4. 筆者が最初に詰まったポイント
– 「置換」で意図しないメンバー消失が起きた –
アカウント保護ポリシーの設定画面を触り始めたとき、「追加（更新）」と「追加（置換）」という2つの選択肢が並んでいても、名前の違いが意味する差をあまり深く考えずに「どうせ似たようなものだろう」と置換を選んでしまいました。 その結果、ポリシーが適用された端末でAdministratorsグループに残すつもりだったアカウントが全部消え、「なぜかIntuneの設定が一部端末に届かなくなった」という状況が発生しました。原因を特定するのに時間がかかり、復旧作業も含めてかなりのロスになりました。 「置換」は強力だからこそ、使い所を誤ると管理基盤そのものを壊しかねません。筆者の経験から言えることは、初回は必ず「追加（更新）」から始め、テスト端末で動作確認してから本番展開するという手順を守ることです。「一気に設定したほうが楽」という判断は、後から修復コストとして返ってきます。
「置換」による典型的なトラブルパターン
- Entra IDのデバイス管理者アカウントがAdministratorsから消える
→ Intuneからのポリシー適用が届かなくなる端末が発生する - 組み込みAdministratorアカウントが意図せず外れる
→ LAPSでの緊急アクセスができなくなる - テナント全体に「置換」ポリシーを一律適用してしまう
→ 数百台規模で管理者グループが再構成されてしまい、復旧に大幅な工数がかかる
5. 実務でのベストプラクティス
– 端末を用途ごとにグループ分割して管理する –
ローカルユーザーグループメンバーシップ管理で最も重要なベストプラクティスは、端末の用途ごとにEntra IDのデバイスグループを作り、用途別にポリシーを割り当てることです。 「全端末に同じポリシー」という運用は設定の手間が省けるように見えますが、実際には「開発端末にだけ必要な権限」が一般社員の端末にも広がってしまうリスクを生みます。逆に「一般社員端末向けの厳しい制限」が開発端末にも適用され、業務が止まるという問題も起きやすくなります。
グループ分割によって得られるメリットは、権限の統制だけではありません。「どのグループに属する端末か」が明確になることで、棚卸し時の確認も格段に楽になります。「この端末、なぜAdministratorsに〇〇さんが入っているの？」という状況は、グループ分割が整っていれば「このグループのポリシーで入っている」とすぐに説明がつきます。 グループ設計の初期コストはかかりますが、後から修正する手間と比べれば、最初に整理しておく価値は十分にあります。
まとめ
ローカルユーザーグループメンバーシップの管理は「誰を入れるか」だけでなく、「どのアクションで・どの端末グループに・なぜ適用するか」という設計全体を考えることが安全な運用の鍵です。「追加（置換）」の事故リスクを理解したうえで、端末の用途ごとにポリシーを分割して管理する構成が、実務での混乱を最も防ぎやすい方法です。
↓ この記事の続きを読む
↓ ガイドのトップを見る
この記事は役に立ちましたか？
もし参考になりましたら、下記のボタンで教えてください。
製造業での現場経験を経てIT業界へ転身した異色のキャリアを持ちます。製造の現場で培った「工程管理」や「業務の流れを俯瞰する視点」は、IT領域においても大きな強みです。現場を知るからこそ見えてくる無駄や非効率に対して、クラウドツールやシステムを活用した実践的な改善提案が得意です。時間とコストを削減し、現場の方が本来の仕事に集中できる環境づくりを支援します。
