デバイスローカル管理者をどう設計すべきか -標準と例外の線引きと運用設計の実践
2026.06.16
「ローカル管理者の3層モデルはわかった。でも、じゃあ自社はどういう設計にすればいいの？」「標準と例外の線引き、どこで引けばいいかが一番わからない」
この記事は、そんな状態にある方に向けて書いています。 前回までの記事で、ローカル管理者の基本・リスク・3層モデルの考え方・Microsoft Intune（以下Intune）での設定手順まで解説してきました。今回はその集大成として、「実際に自社の設計をどう組み立てるか」という実践的な観点にフォーカスします。設計の原則・職種・端末種別ごとのパターン・Break-glassの運用・定期レビューの視点まで、できるだけ具体的に整理します。
この記事を読むと、以下の3つが理解できるようになります。
- ローカル管理者設計の基本原則（最小権限・期限・監査・自動化）が整理できる
- 職種・部門・端末種別ごとの設計パターンを自社に当てはめられるようになる
- Break-glassと平時運用の分離、設計レビューの具体的な進め方がわかる
目次
1. 設計の4原則
– 最小権限・期限・監査・自動化 –
設計のパターンや具体的な手順に入る前に、どんな組織規模・業種でも共通して適用すべき「4つの原則」を押さえておきましょう。これが設計全体の判断軸になります。
2. パターン集
– 職種別・部門別・端末種別の設計例 –
「原則はわかった。では実際、どのパターンに自社は近いか」を判断するために、代表的な設計パターンを整理します。組織ごとに完全に同じにはなりませんが、近いパターンを出発点として、自社の実情に合わせて調整するのが現実的なアプローチです。
職種・部門別パターン
| 職種・部門 | ローカル管理者の推奨設定 | 理由・補足 |
| 一般社員（営業・管理・総務等） | 付与しない（標準ユーザー） | 業務アプリはIntune展開でカバーできる。管理者権限は不要なケースがほとんど |
| ITヘルプデスク担当者 | LAPS経由での一時アクセスのみ | 常時付与は不要。現地対応時にLAPSパスワードで作業し、完了後はアクセスが自然に切れる設計が望ましい |
| ソフトウェア開発者 | 開発端末グループに対して期限付きで付与（半年ごとに再承認） | 開発環境の構築・デバッグで管理者権限が必要なケースが多い。ただし業務PCと開発PCは分けるのが理想 |
| 情報システム部門・Intune管理者 | 作業端末では標準ユーザー。管理作業はIntune管理センター経由 | 「管理者だから端末も管理者でいい」は誤り。管理操作はクラウドコンソール上で行うため、ローカル管理者権限を常時付与する必要はないが、障害対応やBreak-glassなど特定のケースでは必要になる |
| 現地・製造・工場等の現場スタッフ | 専用機の場合のみ期限・申請付きで付与を検討 | 特殊なローカルソフトウェアの導入が必要なケースがある。ただし「現場だから全員付与」は避ける |
端末種別パターン
職種よりも「端末の用途」で分類する方が、Intuneのポリシー設計と連動しやすい場合があります。
| 端末種別 | ローカル管理者の設定方針 | Intuneポリシーの割り当て先グループ例 |
| 標準業務PC | 付与しない。標準ユーザーポリシーを全端末ベースラインとして適用 | 全Intune管理端末（ベースライン） |
| 開発・検証端末 | 期限・承認付きで例外層として管理。申請ごとにMicrosoft Entra ID（以下Entra ID）グループへ追加 | 開発グループ（申請制で追加） |
| キッティング作業端末 | キッティング期間中のみ有効化。完了後に標準ポリシーへ戻す | キッティング グループ（一時的） |
| 障害対応用端末（Break-glass専用） | 平時は権限なし。LAPS経由で一時アクセス。作業ログを必ず残す | 障害対応 グループ（使用時のみ） |
| 共有端末・受付端末等 | 管理者権限は不要。キオスクモードやアプリフィルタリングで制御 | 共有グループ |
【用語メモ】
キオスクモードとは、端末を特定のアプリのみ起動できる状態に制限する設定です。受付・公共端末など、不特定多数が使う端末でよく用いられます。Intuneの「キオスク設定」から構成できます。ローカル管理者権限を付与しなくても、業務上必要な操作範囲に絞って制御できます。
キオスクモードとは、端末を特定のアプリのみ起動できる状態に制限する設定です。受付・公共端末など、不特定多数が使う端末でよく用いられます。Intuneの「キオスク設定」から構成できます。ローカル管理者権限を付与しなくても、業務上必要な操作範囲に絞って制御できます。
「職種」と「端末種別」どちらを優先するか迷ったときは、「端末に対してポリシーを当てる」IntuneのMDMの仕組みに合わせ、端末種別ベースで設計するほうが運用上の混乱が少なくなります。職種ベースはEntra IDグループで補完する形が現実的です。
3. Break-glassと平時運用の分離
【用語メモ】
Break-glass（ブレークグラス）とは、「非常用消火器のガラスケースを割って取り出す」英語の慣用表現が由来です。IT・セキュリティの文脈では通常の管理手段が使えない緊急時にだけ使う、最後の手段としてのアクセス手段・アカウントを指します。「緊急アクセスアカウント（Emergency Access Account）」と同義で、Microsoftのドキュメントでも両方の表記が混在して使われています。なお、Intuneに「Break-glass」という専用の設定項目はなく、LAPS・Conditional Access除外・監査ログなどを組み合わせて運用上の概念として実現するものです。
Break-glass（ブレークグラス）とは、「非常用消火器のガラスケースを割って取り出す」英語の慣用表現が由来です。IT・セキュリティの文脈では通常の管理手段が使えない緊急時にだけ使う、最後の手段としてのアクセス手段・アカウントを指します。「緊急アクセスアカウント（Emergency Access Account）」と同義で、Microsoftのドキュメントでも両方の表記が混在して使われています。なお、Intuneに「Break-glass」という専用の設定項目はなく、LAPS・Conditional Access除外・監査ログなどを組み合わせて運用上の概念として実現するものです。
設計で最も見落とされやすいのが「緊急用」と「平時」の運用が混在してしまう問題です。Break-glass（緊急時アクセス）は、正しく分離されて初めて機能します。
Break-glassが必要な理由
たとえば、Intuneのポリシーが端末に正常に適用されない状態で障害が発生した場合、通常のフロー（Intuneポリシー経由でのアクセス）では対応できません。このような「通常の管理手段が使えない緊急事態」に備えた、例外的なアクセス手段がBreak-glassです。LAPSによる端末ローカル管理者パスワードの取得が、その代表的な実装手段になります。
落とし穴①：「緊急用」が日常利用される
「LAPSのパスワードを調べれば入れるから、毎回それで作業している」——こうなると、Break-glassはすでにBreak-glassではありません。緊急アクセス手段が日常化すると、「本当の緊急時」のための手段が形骸化します。さらに、使用記録が残らない・ローテーションが遅れる・誰でもアクセスできる状態になるという二次的なリスクも生まれます。
Break-glassを使ったら必ず記録し、使用後にLAPSパスワードを手動ローテーションする手順を明文化しておくことが重要です。
「LAPSのパスワードを調べれば入れるから、毎回それで作業している」——こうなると、Break-glassはすでにBreak-glassではありません。緊急アクセス手段が日常化すると、「本当の緊急時」のための手段が形骸化します。さらに、使用記録が残らない・ローテーションが遅れる・誰でもアクセスできる状態になるという二次的なリスクも生まれます。
Break-glassを使ったら必ず記録し、使用後にLAPSパスワードを手動ローテーションする手順を明文化しておくことが重要です。
LAPSパスワード取得の権限も設計に含める
LAPSパスワードの取得（閲覧）ができる人を絞ることも設計の一部です。Intune管理センターでのパスワード表示（閲覧）権限はEntra IDのディレクトリ権限で制御され、ローテーションなどの操作はIntuneのRBACロールで制御されます。「全員が見られる」状態は、Break-glassの意義を損ないます。LAPSパスワードを取得できる人は、ヘルプデスクリード・Intune管理者・情報セキュリティ担当者など、限られた役割に絞りましょう。
4. 設計レビューの観点
– 四半期・半期の棚卸しをどう回すか –
設計は「作ったら終わり」ではなく、定期的に見直すことで実効性が保たれます。ここでは、棚卸しを実際に回すための具体的な観点を整理します。
落とし穴②：例外の可視化がない
「例外を管理している」と言えるには、例外の全体像が見えている状態でなければなりません。台帳に記録されていない例外、口頭で承認されてそのまま残っている権限——こういった「見えない例外」が蓄積すると、棚卸しをしても全容が把握できない状態になります。
「台帳にないものは存在しないものとして扱い、発見したら即記録する」というルールを、チームで共有しておくことが重要です。例外の可視化なくして、設計の維持はできません。
「例外を管理している」と言えるには、例外の全体像が見えている状態でなければなりません。台帳に記録されていない例外、口頭で承認されてそのまま残っている権限——こういった「見えない例外」が蓄積すると、棚卸しをしても全容が把握できない状態になります。
「台帳にないものは存在しないものとして扱い、発見したら即記録する」というルールを、チームで共有しておくことが重要です。例外の可視化なくして、設計の維持はできません。
実務でのベストプラクティス：棚卸しをカレンダー予定として先に入れる
棚卸しが「やろうと思ってできていない」最大の原因は、日程を決めていないことです。四半期・半期の棚卸し日程を年度初めにカレンダーへ入れてしまい、「その日が来たら必ず実施する」という習慣にすることが、継続のための最も確実な方法です。担当者1人ではなく、関係者（情報システム責任者・セキュリティ担当）も同席させることで、形骸化を防ぐ効果もあります。
棚卸しが「やろうと思ってできていない」最大の原因は、日程を決めていないことです。四半期・半期の棚卸し日程を年度初めにカレンダーへ入れてしまい、「その日が来たら必ず実施する」という習慣にすることが、継続のための最も確実な方法です。担当者1人ではなく、関係者（情報システム責任者・セキュリティ担当）も同席させることで、形骸化を防ぐ効果もあります。
5. 筆者が最初に詰まったポイント
– 「緊急用が日常化」していることに気づかなかった –
正直に話すと、設計を組んでから数ヶ月後、「LAPSのパスワードを調べてアクセスするのが当たり前になってきた」という状況に、自分では気づけていませんでした。気づいたのは、別の担当者から「これって毎回LAPSで入るのが正しい手順ですよね？」と聞かれたときです。 改めて使用ログを確認すると、Break-glass用のLAPSアクセスが週に何度も発生していました。それは「緊急事態への備え」ではなく、「平時の作業手順として定着したBreak-glass」でした。 根本の原因は、「平時に使えるアクセス手段が設計されていなかった」こと。ヘルプデスクが日常的に必要とする作業のための適切な権限を例外層として整備せずに、Break-glassだけを用意していたのです。Break-glassの日常化は、平時の設計が不完全なサインでもあります。 設計を見直す際は「Break-glassが月に何回使われているか」を確認することをお勧めします。頻繁に使われているようであれば、平時の設計に改善の余地があります。
まとめ
デバイスローカル管理者の設計に「正解のひな形」はありません。ただ、4つの原則（最小権限・期限・監査・自動化）を土台に、自社の職種・端末種別に合わせたパターンを当てはめ、Break-glassを平時から分離し、定期レビューで設計を維持する——この流れは、どんな組織でも共通して有効です。 設計は一度作れば終わりではなく、組織の変化とともに育てていくものです。まず「現状の例外を台帳に可視化する」ことから始めてみてください。
↓ 全体像をもう一度確認する：Intune管理者完全ガイド
この記事は役に立ちましたか？
もし参考になりましたら、下記のボタンで教えてください。
製造業での現場経験を経てIT業界へ転身した異色のキャリアを持ちます。製造の現場で培った「工程管理」や「業務の流れを俯瞰する視点」は、IT領域においても大きな強みです。現場を知るからこそ見えてくる無駄や非効率に対して、クラウドツールやシステムを活用した実践的な改善提案が得意です。時間とコストを削減し、現場の方が本来の仕事に集中できる環境づくりを支援します。
