Microsoft Entra 管理単位ガイド

By Mirko Peters · 2026-04-30 · Updated 2026-07-18

Microsoft Entra の管理単位について、セキュリティ、ガバナンス、アクセス制御、実装、実際の利用シーンを踏まえて実践的に解説します。

Automatically translated with AI from the original post. Read the English original

Microsoft 365 や Azure で大規模な組織を管理していると、状況はあっという間に複雑になります。Microsoft Entra ID の管理単位（略称は AU）は、テナントというデジタル上の街の、いわば町内会長のような役割を果たします。ユーザーベースを細かく分割できるため、各拠点の管理者には担当範囲の管理に必要なだけの権限を与え、組織全体の管理権限までは渡さずに済みます。

組織がセキュリティ、コンプライアンス、効率性のバランスを取るうえで、これは大きな進化です。すべての管理者に同じ管理権限を与えるのではなく、AU によって適切な担当者が適切なユーザーを管理できるようになります。過不足のない状態を保てるわけです。この記事を読み進めると、AU がグループや従来の OU とどう違うのか、そしてガバナンスを厳格に保ちながら管理をどう楽にするのかが分かります。より細かいロールの範囲設定、テナントのセグメント化、あるいは単に混乱を減らしたい場合でも、Entra ID の管理単位を理解しておく価値は十分にあります。

Microsoft Entra ID の管理単位とは

Microsoft Entra ID の管理単位（AU）は、大規模な整理整頓を行うための特別なコンテナーです。デジタルな境界線と考えてください。管理者をこの境界に割り当てることで、その境界内にあるユーザーやグループだけを管理させることができます。

管理単位を設定したら、ユーザー管理者やヘルプデスク管理者などの管理権限を、その単位内のユーザーやグループに限定して委任できます。これにより、ローカルの IT チームは自分たちの担当者に集中でき、他の場所に手を出す必要がなくなります。すべての扉を一度に開けることなく、管理を分散させられるのがポイントです。

これは、学校、多国籍企業、政府機関などの大規模または複雑な組織で特に役立ちます。たとえばニュージャージーにいる管理者が東京のユーザーのパスワードリセットを行う、といった事態は避けたいはずです。管理範囲を明確に区切ることで、各担当者が自分の持ち場を守れるようになります。

オンプレミスの Active Directory にある従来の OU とは異なり、AU はマイクロソフトのクラウド上にのみ存在し、管理権限の範囲を定めることが目的です。また、主にアプリやリソースへのアクセスに使われるセキュリティグループや Microsoft 365 グループとも別物です。これらのグループは管理権限のためのものではありません。要点はこうです。AU を使えば、クラウドテナント内で「誰が何を管理できるか」を明確にでき、より的確かつ安全な管理が可能になります。

Azure 管理単位とグループ、OU の違い

• 管理単位（AU）: 委任された管理のために設計されています。AU 内の特定のユーザーやグループに対して管理者ロールの範囲を限定しますが、ファイルやメールボックスなどのリソースへのアクセス権は付与しません。
• グループ: アプリやリソースへのアクセス割り当て（例: Teams、SharePoint、ライセンス）に使われます。グループは管理の境界を制限したり定義したりするものではなく、権限の付与や配布リストのためのメンバーシップを表すものです。
• 組織単位（OU）: オンプレミスの Active Directory の概念で、グループポリシーを適用するためにオブジェクト（ユーザーやコンピューターなど）を階層的に整理するものです。クラウドや Microsoft 365 での委任用には設計されておらず、Entra ID に直接の対応物はありません。

要するに、管理範囲の指定には AU、アクセス制御にはグループ、オンプレミスの整理には OU を使います。目的に応じて適切なツールを選んでください。

管理単位の実装: Microsoft 365 における主なシナリオ

Microsoft 365 の環境が複数の国、部門、またはコンプライアンス区分にまたがる場合、中央の管理チームだけでは対応しきれなくなります。ここで管理単位の出番です。管理をコントロールしたまま、そして管理者の負担を増やさずに、複雑な構成を整理できます。

管理単位を使えば、必要最小限の権限を適切に配分できるため、ローカルのチームや部門責任者が、必要な場所でパスワードのリセットやグループメンバーシップの管理を行えます。このようにテナントを分割することで、生産性を高めつつリスクを低減できます。誰も必要以上に広い管理権限を持たなくて済むからです。

実際の現場では、さまざまな課題が次々と発生します。たとえば、学部ごとに分かれた大学、州ごとに店舗を展開する小売業者、地域ごとに IT チームを持つグローバル企業などです。管理単位は、組織のどの範囲を誰が担当するのかを定義し、社内ポリシーを確実に徹底させるための基本的な手段になります。

以下では、これらの管理単位を導入する際によく見られるシナリオと判断ポイントをいくつか紹介します。なぜそれが重要なのかだけでなく、コンプライアンス、最小特権アクセス、地域ごとの自律性といったよくある課題にどう対処できるのかも見ていきます。

複雑な管理シナリオで管理単位を使用するタイミング

• 地理的に分散した組織: 地域のIT チームに、その地域(例: ヨーロッパ、アジア)のユーザーだけを管理させます。グローバル テナント全体へのアクセスは与えません。
• 部門ごとの分離: 人事、経理、学部などに管理権限を委任し、各チームの管理権限を自部門の範囲内に限定します。
• コンプライアンスやプライバシーの境界: GDPR や HIPAA などの異なる規制が適用されるユーザーを専用の管理単位 (AU) に分け、セキュリティの境界を明確にします。
• 合併や買収: 新しい事業部門や買収した企業を取り込み、その組織が自律的に管理できるようにします。ただし、環境全体へのアクセスは開放しません。
• 教育機関や学区: 学校の管理者には自校の生徒と教職員だけを管理させ、他校のデータには手が届かないようにします。

Azure 管理単位を使用した Microsoft 365 テナントのセグメント化

• 分散型の管理: 管理単位 (AU) を使うと、現場の管理者には管理が必要なユーザーやグループだけを割り当てられます。日常的な作業のためにグローバル管理者を使う必要はなくなります。これにより「船頭が多すぎる」状態を防ぎやすくなります。
• 明確なセキュリティ境界: AU でテナントを分割すると、部門、地域、法人単位に沿った境界を設けられます。各境界には、それぞれに合った管理権限を設定できます。
• コンプライアンスへの対応が容易に: IT チームが自分の担当範囲のユーザーだけを参照する形になるため、監査への対応、最小特権の徹底、データ露出リスクの低減がずっと簡単になります。
• トラブルシューティングの簡素化: 現場の管理者は、他チームのデータに影響を与えることなく、パスワードのリセット、ライセンスの管理、メンバーシップの調整を行えます。日常の管理がスムーズになります。
• ガバナンス戦略のサポート: RBAC、PIM、ポリシーの適用に関する高度な戦略については、実践的なヒントとしてAzure のガバナンスと RBAC のベスト プラクティスについての解説をご覧ください。

Microsoft Entra ID で管理単位を設定する方法

Microsoft Entra ID で管理単位を展開するには、まず明確な考え方が必要です。誰を管理し、誰にその管理を任せるのか。これを整理できたら、AU の設定は、管理単位そのものを作成し、適切なユーザーまたはグループを追加し、最後に適切な制御レベルで管理者ロールを割り当てる、という流れで進めます。

AU は Azure ポータルで直接作成できます。段階的に進むわかりやすい操作画面が用意されています。大規模または動的な組織の場合は、Microsoft Graph API を使ってスクリプトに大量の処理を任せることもできます。

その後は、ユーザーを適切な AU に配置する作業になります。必要に応じて 1 人ずつ、大規模な場合は一括で追加します。グループのメンバーシップは直接管理することも動的に管理することもできます。ただし、デバイスやリソース(SharePoint サイトなど)には制限があるため、後ほど取り上げます。

最後に、従来の Azure AD モデル、または Privileged Identity Management (PIM) を使って管理者ロールを割り当てます。PIM を使うと、ジャストインタイムのアクセスと監査証跡を確保できます。以降のセクションでは各手順を詳しく説明します。これを読み終える頃には、自信を持って管理単位を構築し、保護し、権限を委任できるようになっているはずです。

Microsoft 365 で管理単位を作成して構成する

• Azure ポータルにアクセスする: Microsoft Entra ID に移動し、「管理単位」を選択して、「+ 新しい管理単位」をクリックすると設定が始まります。
• 名前、説明、スコープを設定する: 管理単位にわかりやすい名前を付けます(例: 「APAC 営業管理者」)。必要に応じて、今後の管理者向けに説明も追加します。
• メンバーを追加する: ユーザーまたはグループを直接メンバーとして割り当てられます。この管理単位でどのユーザーを管理するかを決めます。管理者の操作は、ここに含まれるユーザーにだけ影響します。
• 自動化のオプション: コードでの作業がお好みですか。一括処理や自動化されたワークフローで管理単位を作成、更新、管理するには Microsoft Graph API を使います。スクリプトを使うと大規模な変更が行いやすくなり、ミスも減ります。
• メンバーシップの重複を確認する: 厳密なスコープ設定が必要な場合は、管理単位同士でメンバーシップが重複しないようにします。ユーザーは、特定のロールのコンテキストにおいて、1 つの管理単位でしか管理できません。

管理単位へのユーザーとグループの割り当て

• 直接割り当て: Azure ポータルで([ユーザー] > [メンバーの追加] の順に)ユーザーまたはグループを手動で追加すると、それらが管理単位の管理対象オブジェクトになります。
• 動的グループ（制限あり）: 動的グループを AU のメンバーとして追加することはできます。ただし、AU 自体では現在、動的ルールをネイティブに適用できません。動的グループのルールは AU ではなくグループ側に存在するためです。
• 一括インポート: 大規模な組織では、PowerShell や Graph API を使って複数のユーザーやグループを効率よく割り当てましょう。作業時間を短縮でき、設定の一貫性も保てます。
• メンバーシップの定期的な見直し: 定期的なチェックを設定し、孤立したアカウントを削除するとともに、ユーザーの管理範囲が適切かどうかを確認しましょう。人事異動は避けられません。管理の境界線は常に最新の状態に保ちましょう。
• デバイスの扱い: 現時点では、ノート PC やスマートフォンなどのデバイスを AU のメンバーにすることはできません。AU で管理できるのはユーザーとグループのみで、ハードウェアやリソースは対象外です。

Privileged Identity Management でのadministrator への ロール割り当て

• AU ごとのロール割り当て: AU の内側から、User Administrator、Groups Administrator、Helpdesk Admin などのロールを割り当てます。これにより、委任された管理者は、その AU 内の権限のみを持つことになります。
• JIT アクセスのための PIM の活用: Azure AD の Privileged Identity Management（PIM）を使用して、ジャストインタイム（JIT）の管理者アクセスを付与しましょう。ロールは一時的にアクティブ化できるため、「常時有効」によるリスクを減らせます。
• 承認ワークフローの実行: PIM の承認を設定し、管理者アクセスには追加の承認が必要となるようにしましょう。コンプライアンス要件が厳しい環境や、高いセキュリティが求められる環境では非常に有効です。
• アクセスの監視と監査: 誰が、いつ、どのロールをアクティブ化したかを把握しましょう。監査ログは Microsoft Sentinel に接続するか、Purview Audit を使って、M365 全体のユーザー活動を詳細に追跡しましょう。これにより、ガバナンスが強化され、セキュリティの説明にも説得力が増します。
• 割り当て済み特権の見直し: 付与したロールを定期的に確認しましょう。不要になった権限や使われなくなった権限は削除し、権限の肥大化を防ぎ、最小権限の原則を徹底します。

管理上の要件、ライセンス、制限事項

AU を使ってテナントを分割する前に、確認すべき前提条件と制約があります。すべての Microsoft 365 サブスクリプションが同じ機能を備えているわけではありません。AU の利用には、通常、対象ユーザーと割り当てられる管理者の両方に、少なくとも Azure AD Premium P1 ライセンスが必要です。

ユーザーとグループの管理機能は充実していますが、デバイス、SharePoint サイト、その他のリソースについては制約があります。AU は現時点ではハードウェアの管理や、リソースへのきめ細かいアクセス割り当てを想定して設計されていません。また、ライセンスの割り当てや一部のプロパティ管理機能にも制限があるため、大規模な環境や変更の多い環境では、工夫した回避策が必要になる場合があります。

階層構造も注意すべき点です。従来の Active Directory の OU とは異なり、AU はフラットな構造です。ネストや親子関係はないため、その複雑さのない前提でセグメント化を設計する必要があります。見方によっては、柔軟性が制限されているとも言えるでしょう。

以下で詳しく見ていくように、AU の機能的な境界を理解することで、IT スタッフと事業部門の関係者の双方に対して、現実的な期待値を設定できるようになります。

主な管理上の制限事項: 階層構造、デバイス、SharePoint

• 階層構造がないこと: AU はフラットな構造です。ネストや親子関係という概念はありません。たとえば、「北米」の AU の下に州や地域ごとの子 AU を作成することはできません。各 AU は独立して存在します。
• デバイス管理の制限: ノート PC、スマートフォン、プリンターなどのデバイスは、AU で直接管理することはできません。デバイス単位で管理範囲を設定する必要がある場合は、別のソリューションや Intune ポリシーの利用が必要になることがあります。
• SharePoint/OneDrive の制限: AU では SharePoint サイトや OneDrive に対する管理者権限の範囲を設定できません。これらのアプリでデータガバナンスを管理するには、個別の戦略を立てるか、複雑なデータが必要な場合は Microsoft Dataverse などの代替手段を検討する必要があります。
• ライセンス割り当ての課題: AU 内のユーザーにライセンスを割り当てることはできますが、AU 単位で組み込みの自動化機能はありません。そのため、大規模に自動化するのは難しくなります。
• プロパティ管理: AU 内のユーザープロパティを一括更新したり、レポートを作成したりする機能は限られています。こうした不足を補うには、外部ツール、PowerShell、Graph API を使うことが多くなるでしょう。

セキュリティ、ガバナンス、および管理単位の代替手段

セキュリティとガバナンスは管理単位の設定だけで終わるものではありません。テナント(そして組織の信頼)を守るには、管理単位をどのように管理するか、誰に委任権限を与えるか、特権アクセスをどのように監視、レビュー、取り消すかを継続的に考える必要があります。

ベストプラクティスには、最小権限の原則の適用、PIM を使った承認ワークフローの活用、すべてのロール割り当ての監査が含まれます。継続的な監視も欠かせません。特権アクセスのレビュー、異常なアクティビティのアラート、定期的なレポートにより、実際に誰が環境を運用しているのかをより確実に把握できるようになります。

組織によっては、どれほど優れた管理単位の設計をもってしても十分ではない場合があります。多階層のセグメンテーション、より高度なコンプライアンス管理、または高度な自動化が必要になることもあるでしょう。そのような場合に、CoreView の仮想テナントのような代替ソリューションが役立ちます。管理単位ではまだ対応できない方法で、テナントを細かく分割できます。

ガバナンスを徹底する方法(ポリシーの適用、RBAC、自動化されたガードレールを含む)をさらに詳しく知りたい場合は、Azure ガバナンス戦略の解説をご覧ください。AI や自動化に取り組んでいる場合は、Copilot と Graph のアクセス許可の保護も必読です。コパイロットやボットが普及する時代にコンプライアンスを維持するための重要な情報が得られます。

残存するセキュリティ上の影響と仮想テナントという代替手段

• 権限の肥大化(Privilege Creep): 管理者権限が見直されないと、元管理者や転職者が「ゾンビ」権限を蓄積してしまう可能性があります。これは内部リスクの代表的な原因の一つです。定期的なレビューと権限の削除が不可欠です。
• 監査と可視性のギャップ: ネイティブの監査ログでは、どの管理単位の中で誰が何を変更したのかを容易に把握できない場合があります。エンタープライズレベルの監視を実現するには、Entra のログを SIEM ツールに連携するか、Microsoft Purview や Sentinel を利用して、堅牢な監視とコンプライアンスレポートを用意してください。Agentageddon のようなエピソードでは、Microsoft 365 における AI とガバナンスの監査が遅れた場合のリスクが解説されています。
• 適用範囲の制限: 管理単位では、クラウドをまたぐ環境やハイブリッド環境をネイティブに分割することはできません。ハイブリッド環境やマルチクラウド環境では、より強固な境界と一元的なガバナンスを実現するために、サードパーティ製ツールや仮想テナントのソリューションを検討してください。
• 代替手段を検討すべきとき: 管理単位では実現できない多階層のセグメンテーション、コンプライアンスのマッピング、高度なワークフロー自動化が必要な場合は、CoreView の仮想テナントのようなソリューションを検討してください。シャドー IT と AI には高度な監視が必要です。その他のアイデアについては、Microsoft Foundry と Purview の要点に関するこちらの分析をご覧ください。

あわせて聴いていただきたいエピソード

Microsoft Entra の管理単位について調べている場合は、以下のエピソードで、ID セキュリティ、ガバナンス、特権アクセス、実装に関する実践的な背景を確認できます。

• Microsoft Defender XDR – Simply Explained — ID ガバナンスとセキュリティシグナル、調査、対応を結びつけます。
• Conditional Access – Simply Explained — ポリシーベースのアクセス制御によって ID に関する判断を適用する仕組みを学びます。
• Privileged Identity Management – Simply Explained — ジャストインタイムの特権、承認、アクセスレビューについて理解を深めます。
• Microsoft Teams Governance – The Illusion of Control — アクセス許可と所有権を、再現可能な運用へとつなげるガバナンスの考え方を紹介します。