複数のMicrosoft Entraテナントを管理していると、テナントごとにローカル管理者を作成し、パスワード、MFA、退職者対応、権限棚卸しを個別に行う運用が負担になります。
結論から言えば、Microsoft Entra Tenant Governanceのcross-tenant delegated administrationを利用すると、許可された管理者はgoverning tenantの資格情報でサインインしたまま、governed tenantを管理できます。各governed tenantにローカル管理者やB2Bゲストアカウントを用意する必要はありません。ただし、管理できるのは、事前にガバナンスポリシーテンプレートで許可され、governed tenantが承認したMicrosoft Entraロールの範囲に限られます。(Microsoft Learn)
なお、2026年8月時点のMicrosoft Entraリリース情報では、Tenant Governanceのガバナンス関係はPublic Previewとして案内されています。本番環境へ展開する場合は、最新の提供状況、サポート対象、ライセンス条件を事前に確認してください。(Microsoft Learn)
governing tenantのIDで複数Entraテナントを委任管理できる仕組み
Microsoft Entra Tenant Governanceでは、テナント間に方向性を持つgovernance relationship（ガバナンス関係）を作成します。
中央で管理者IDを保持する側がgoverning tenant、管理される側がgoverned tenantです。関係は一方向であり、governing tenantがgoverned tenantを管理できても、逆方向の管理権限が自動的に付与されるわけではありません。(Microsoft Learn)
| 要素 | 役割 |
|---|---|
| governing tenant | 管理者アカウント、管理グループ、ポリシーテンプレートを保持する中央テナント |
| governed tenant | governing tenantから委任管理される対象テナント |
| ガバナンスポリシーテンプレート | どのセキュリティグループに、どのMicrosoft Entraロールを付与するかを定義 |
| governance relationship | 2つのテナント間で合意された管理関係 |
| GDAP | Granular Delegated Admin Privileges。最小権限のクロステナント管理を実現する基盤 |
| ロール割り当て可能なセキュリティグループ | governing tenantの管理者を職務単位でまとめ、governed tenant側のロールへ関連付けるグループ |
実際の権限の流れは、次のようになります。
- 管理者はgoverning tenantの自分のアカウントで認証する
- 管理者が所属するセキュリティグループを確認する
- ガバナンスポリシーテンプレートに設定されたロールを確認する
- governance relationshipを通じて、governed tenant側のGDAPロールが適用される
- 割り当てられたロールの範囲で管理操作を実行する
重要なのは、governing tenantが「すべてのテナントを無条件に操作できるマスターテナント」になるわけではない点です。テナント関係、セキュリティグループ、ロール、承認の4つがそろって初めて管理できる仕組みです。ポリシーテンプレートは複数のgoverned tenantに再利用できるため、同じ管理基準を複数テナントへ展開できます。(Microsoft Learn)
ローカル管理者やB2Bゲストによる管理との違い
これまでの複数テナント管理では、各テナントにローカル管理者を作成する方法や、中央テナントの管理者をB2Bゲストとして招待する方法がよく使われてきました。
Tenant Governanceのcross-tenant delegated administrationは、これらをすべて禁止する機能ではありません。特にB2Bはコラボレーション用途で引き続き利用できます。一方、複数テナントの管理権限を標準化する用途では、GDAPを利用したガバナンス関係の方が、権限をグループとテンプレートで管理しやすくなります。(Microsoft Learn)
| 管理方式 | 管理者が使用するID | 管理対象テナント側のアカウント | 権限管理 | 向いている用途 |
|---|---|---|---|---|
| ローカル管理者 | 各テナントのローカルID | 必要 | テナントごとに設定 | 独立性が高いテナント、緊急用アカウント |
| B2Bゲスト管理者 | ホームテナントのID | B2Bゲストオブジェクトが必要 | ゲスト単位またはグループ単位 | 外部コラボレーション、一部の管理シナリオ |
| Tenant Governanceによる委任管理 | governing tenantのID | ローカルID、B2Bアカウントともに不要 | セキュリティグループとテンプレートで標準化 | グループ会社、部門別テナント、顧客テナントの集中管理 |
Tenant Governanceへ移行すると、ローカル管理者を直ちにすべて削除できるわけではありません。日常業務用の重複アカウントは減らせますが、障害やガバナンス関係の不具合に備えた緊急アクセス手段は別に残す必要があります。
委任管理を始める前の前提条件
cross-tenant delegated administrationを利用するには、少なくとも次の条件を満たす必要があります。
- governing tenantとgoverned tenantの間に、有効なgovernance relationshipがある
- ガバナンスポリシーテンプレートで委任管理が構成されている
- Microsoft Entra組み込みロールが、governing tenantのセキュリティグループに関連付けられている
- 管理者が、そのセキュリティグループのメンバーになっている
- ガバナンス関係を構成する管理者がTenant Governance Administratorロールを持っている
- 対象となる管理ポータルや操作がGDAPに対応している
公式ドキュメントでは、ガバナンス関係の作成にTenant Governance Administratorロールが必要です。また、委任管理を利用する管理者は、ポリシーテンプレートに指定されたセキュリティグループへ所属している必要があります。(Microsoft Learn)
必要なライセンス
2026年7月30日更新の公式ライセンス情報では、GDAPを使用するcross-tenant governance relationshipは、次のライセンスで利用できます。
- Microsoft Entra ID P1
- Microsoft Entra ID P2
- Microsoft Entra ID Governance
ライセンスはgoverning tenant側で必要とされ、governed tenant側にはガバナンス関係用のライセンスは要求されません。公式の計算例では、ガバナンス関係を構成する管理者ごとに1ライセンスが必要であり、管理対象テナントやガバナンス関係の数が増えても、それだけで必要ライセンス数が増えるわけではありません。(Microsoft Learn)
ライセンス条件は変更される可能性があるため、実際の導入時にはMicrosoft 365契約、Microsoft Entra契約、利用する機能の組み合わせを確認してください。
governing tenantのIDで複数Entraテナントを委任管理する方法
管理業務ごとにセキュリティグループを分ける
最初に、governing tenantで管理者を所属させるセキュリティグループを設計します。
管理者全員を1つの万能グループに入れるのではなく、業務ごとにグループを分けるのが基本です。
| 管理業務 | グループ名の例 | ロール候補 |
|---|---|---|
| 全体構成の参照 | TG-Global-Readers | Global Reader |
| サインインや監査ログの確認 | TG-Report-Readers | Reports Reader、Security Reader |
| ユーザー管理 | TG-User-Operators | User Administrator |
| 認証方法のサポート | TG-Authentication-Operators | Authentication Administrator |
| 条件付きアクセス管理 | TG-CA-Administrators | Conditional Access Administrator |
| セキュリティ運用 | TG-Security-Operators | Security Reader、Security Administrator |
ロール名だけで判断せず、「管理者が実行する具体的なタスク」から必要な最小権限を選びます。恒常的なGlobal Administratorの付与は避け、既知の制限回避などで必要になる場合も、期間限定で運用するのが安全です。MicrosoftもGDAPでは、タスクとワークロードに応じた最小権限ロールの利用を推奨しています。(Microsoft Learn)
権限の強いグループには、Privileged Identity Managementを適用し、常時メンバーではなく有資格メンバーとして登録する方法が適しています。必要な時間だけグループメンバーシップを有効化すれば、管理者アカウントが侵害された場合の影響を抑えられます。
ガバナンスポリシーテンプレートを作成する
governing tenantで、次の手順を実行します。
- Tenant Governance Administrator以上の権限でMicrosoft Entra管理センターにサインインする
Tenant governanceからTemplatesを開く- 新しいガバナンスポリシーテンプレートを作成する
Delegated administrationで必要なMicrosoft Entra組み込みロールを選択する- 各ロールを、governing tenantのロール割り当て可能なセキュリティグループへ関連付ける
- 内容を確認してテンプレートを保存する
1つのグループには複数のロールを割り当てられ、1つのテンプレートには複数のグループを登録できます。テンプレートは異なるgoverned tenantとのガバナンス関係に再利用できます。(Microsoft Learn)
例えば、グループ会社10社を同じ基準で管理する場合、次のようにテンプレートを分けられます。
Standard-ReadOnly：監査・参照専用Standard-IdentityOps：ユーザーと認証サポート用Standard-SecurityOps：セキュリティ運用用Exceptional-FullAdmin：例外的な高権限作業用
最初から高権限テンプレートだけを作るのではなく、参照用、定常運用用、例外作業用に分離することで、最小権限を維持しやすくなります。
governance relationshipを作成する
ガバナンス関係の作成方法は、テナント間の既存関係によって異なります。
| 条件 | 使用する方法 | 処理の流れ |
|---|---|---|
| 共有請求情報などのbilling signalがない | 3ステップ方式 | governed tenantから招待、governing tenantからリクエスト、governed tenantで承認 |
| billing signalで関連テナントと判定されている | 2ステップ方式 | governing tenantからリクエスト、governed tenantで承認 |
| 同じテナント間に既存の有効な関係がある | 2ステップ方式 | governing tenantから追加リクエスト、governed tenantで承認 |
3ステップ方式では、governing tenant側で一時的にガバナンス招待を受信できるようにします。
- governing tenantで
Tenant governanceからSettingsを開く - ガバナンス招待を有効にする
- governed tenantからgoverning tenantへ招待を送信する
- governing tenantで招待を確認する
- 使用するガバナンスポリシーテンプレートを選んでリクエストを送信する
- governed tenantの管理者が内容を確認して承認する
- 招待を受信した後は、不要であれば招待設定を無効に戻す
ガバナンス招待の有効期間は30日、ガバナンスリクエストの有効期間は14日です。関係が成立すると、governed tenant側にクロステナントロール割り当てと、パートナー固有のクロステナントアクセス構成が作成されます。(Microsoft Learn)
ここで重要なのは、governing tenant側だけでは関係を成立させられないことです。既存テナントを管理対象に追加する場合、原則としてgoverned tenant側の管理者による確認と承認が必要です。
Microsoft Entra管理センターからgoverned tenantへサインインする
ガバナンス関係とGDAPロール割り当てが有効になったら、管理者は次の手順で対象テナントへアクセスできます。
- governing tenantの資格情報でMicrosoft Entra管理センターへサインインする
Tenant governanceからGoverned tenantsを開く- 管理するgoverned tenantを選択する
- コマンドバーの
Sign in to tenantを選択する - サイドペインでサインイン可否と付与されるロールを確認する
- PIMの有資格メンバーである場合は、
Activateを選択してグループメンバーシップを有効化する - 開きたい管理ポータルを選択する
- 新しいタブで、governing tenantの資格情報を使って認証する
サイドペインには、対象テナントへサインインできるかどうかと、利用できるロールが表示されます。ただし、同じテナント間に複数の有効なガバナンス関係がある場合、選択した関係に含まれるロールだけが表示され、実際に利用可能なロールをすべて表示しないことがあります。(Microsoft Learn)
管理ポータルのURLを直接開く
Microsoft Entra管理センターの一覧を経由せず、対象テナントのドメイン名またはテナントIDをURLへ指定する方法もあります。
https://entra.microsoft.com/{governed-tenant-domain-or-id}例えば、governed tenantのテナントIDを指定してURLを開き、governing tenantの管理者資格情報でサインインします。認証後は、セキュリティグループに割り当てられたロールの範囲で管理操作を実行できます。(Microsoft Learn)
ブックマークを作成する場合は、表示名だけでなくテナントIDも管理台帳に記録しておくと、同名テナントや名称変更による誤操作を防ぎやすくなります。
委任管理された管理者をログで識別する方法
governing tenantの管理者は、governed tenantの通常ユーザーとは異なる形式で表示されます。
- ユーザー名：
user_{governing tenant側のユーザーオブジェクトIDからハイフンを除いた値} - サインインログと監査ログの表示名：
{governing tenant名} Technician
例えば、governing tenant名がContoso ITであれば、ログ上ではContoso IT Technicianと表示されます。(Microsoft Learn)
サインインログを確認する
governed tenant側で、次の手順を実行します。
- Reports Reader以上の権限でMicrosoft Entra管理センターへサインインする
IdentityからMonitoring & health、Sign-in logsを開く- ユーザーフィルターを追加する
- 検索語に
Technicianを指定する - サインイン日時、対象アプリ、成功・失敗、条件付きアクセスポリシーの評価結果を確認する
監査ログを確認する
IdentityからMonitoring & health、Audit logsを開くInitiated by (actor)フィルターを追加する- governing tenant名を入力する
- 実行された操作、対象リソース、成功・失敗、変更前後のプロパティを確認する
governed tenant側で「外部の管理者が何を変更したか」を追跡できるよう、サインインログと監査ログの確認手順を運用開始前に整備しておくことが重要です。
個人を特定する必要がある場合は、ログに記録されたuser_以降の値と、governing tenant側のユーザーオブジェクトIDを照合します。退職者や異動者の調査に備えて、オブジェクトIDを含む管理者台帳を保持しておくと追跡しやすくなります。
権限を変更しても自動では反映されない
ガバナンスポリシーテンプレートを変更しただけでは、既存のgovernance relationshipには反映されません。
権限を追加、削除、変更する場合は、次の処理が必要です。
- governing tenantでガバナンスポリシーテンプレートを更新する
- テンプレートのバージョンが1つ増える
- 更新したテンプレートを使用して、新しいガバナンスリクエストを送信する
- governed tenantの管理者が変更内容を確認する
- governed tenantでリクエストを承認する
- ガバナンス関係のポリシースナップショットとロール割り当てが更新される
テンプレート変更が自動適用されないのは、governing tenantが一方的に管理権限を拡大できないようにするためです。governed tenantには、権限変更を確認して承認する機会が残されています。(Microsoft Learn)
権限変更の申請では、少なくとも次の情報を記録しましょう。
- 変更するロール
- 対象セキュリティグループ
- 変更理由
- 影響する管理業務
- governed tenant側の承認者
- 変更予定日
- ロールバック方法
ガバナンス関係を終了するとどうなるか
governance relationshipが不要になった場合は、関係を終了できます。
governing tenantから終了する場合は、終了リクエストを送信し、governed tenant側の確認が必要です。一方、governed tenant側は、governing tenantの承認を待たずに関係を直接終了できます。(Microsoft Learn)
関係を終了すると、governed tenant側から主に次のリソースが削除または更新されます。
- GDAPロール割り当て
- ガバナンス関係に関連するクロステナントアクセス構成
- 関係によって作成されたサービスプリンシパル
- サービスプリンシパルに付与されたアクセス許可
管理委託の終了、子会社の売却、顧客契約の終了などでは、管理者をセキュリティグループから外すだけでなく、不要になったガバナンス関係そのものを終了する必要があります。
GDAPでもすべての操作ができるとは限らない
GDAPロールが割り当てられていても、すべてのMicrosoft管理ポータルや機能が同じように動作するとは限りません。
公式のGDAP対応ワークロード情報では、Microsoft Entraの多くのタスクがサポートされていますが、現行情報では次のような制限があります。
- Microsoft 365グループの作成
- 動的メンバーシップルールの管理
- 一部のExternal Identities機能
- Log Analytics、診断設定、Workbooksなど一部の監視機能
- Microsoft Entra Connect Health
- 一部画面でのサインインユーザーのロール表示
また、Microsoft 365管理センター、Teams、Exchange、SharePoint、Intune、Microsoft Defender、Microsoft Purviewなどは、ワークロードごとにサポートされるロールと操作が異なります。(Microsoft Learn)
「ロールを付けたのに操作できない」場合は、すぐにロール不足と判断せず、次の順序で確認してください。
- 対象機能がGDAPに対応しているか
- 使用している管理ポータルがGDAPに対応しているか
- セキュリティグループに必要なロールが設定されているか
- 管理者がグループの有効なメンバーか
- PIMの有資格メンバーシップを有効化したか
- 更新したガバナンスリクエストがgoverned tenantで承認済みか
よくあるトラブルと確認ポイント
| 症状 | 主な原因 | 確認・対処 |
|---|---|---|
Sign in to tenantが利用できない | ガバナンス関係が未成立、終了済み | relationship statusがActiveか確認する |
| サインイン不可と表示される | 対象グループに所属していない | governing tenant側のグループメンバーシップを確認する |
| PIM利用者が操作できない | 有資格メンバーシップを有効化していない | サイドペインのActivateから有効化する |
| サインインできるが変更できない | ロール不足、対象機能がGDAP非対応 | 実行タスクに必要な最小権限と対応ワークロードを確認する |
| テンプレートを変更したのに権限が変わらない | テンプレート変更を既存関係へ反映していない | 新しいガバナンスリクエストを送り、governed tenantで承認する |
| サイドペインのロールが少ない | 同じテナント間に複数の関係がある | 選択中のガバナンス関係以外の割り当ても確認する |
| ログで管理者の名前が分からない | Technician形式で記録される | user_に続く値をgoverning tenant側のオブジェクトIDと照合する |
| 委任管理が停止して復旧できない | ローカルの緊急アクセス手段がない | governed tenantごとに緊急アクセスアカウントを維持する |
安全に運用するための設計ポイント
高権限を1つのグループへ集約しない
読み取り、ユーザー管理、条件付きアクセス、セキュリティ運用を別グループに分けます。
1人が複数業務を担当する場合は、その人を必要なグループへ追加します。1つのグループに多数のロールを集約すると、業務変更時に不要な権限だけを外しにくくなります。
PIMで必要な時間だけ有効化する
Global Readerのような参照ロールは常時割り当て、変更権限を持つグループはPIMで有資格にするなど、リスクに応じて運用を分けます。
特にGlobal AdministratorやSecurity Administratorなど影響範囲の大きい権限は、PIMの対象として優先的に保護することが推奨されています。(Microsoft Learn)
governed tenantごとに緊急アクセスアカウントを残す
Tenant Governanceを導入しても、すべてのローカル管理者を削除するのは危険です。
governing tenantの障害、条件付きアクセスの誤設定、PIMの問題、ガバナンス関係の終了などが発生すると、通常の委任管理経路を利用できなくなる可能性があります。
Microsoftは、管理アクセスを失う事態に備えて、各Microsoft Entra組織に2つ以上のクラウド専用緊急アクセスアカウントを用意することを推奨しています。これらは日常運用には使わず、認証方法、保管方法、監視、定期テストを通常の管理者アカウントと分離します。(Microsoft Learn)
最初は参照権限で試行する
本番導入では、最初からユーザー変更や条件付きアクセス変更を許可するのではなく、次の順序で段階的に展開すると安全です。
- 検証用または影響の小さいgoverned tenantを1つ選ぶ
- Global ReaderやReports Readerなどの参照ロールだけを設定する
- governing tenantのIDでサインインできることを確認する
- サインインログと監査ログの表示を確認する
- PIMの有効化と失効を確認する
- 必要な変更権限を業務単位で追加する
- 新しいリクエストと承認の流れをテストする
- 緊急アクセスアカウントから復旧できることを確認する
- 問題がなければ他のテナントへ同じテンプレートを展開する
テナント台帳とグループ台帳を一体で管理する
最低限、次の情報を一覧化します。
- governed tenantの表示名
- テナントID
- プライマリドメイン
- governance relationshipの状態
- 使用中のポリシーテンプレートとバージョン
- 委任されているMicrosoft Entraロール
- 関連付けたセキュリティグループ
- グループ所有者
- governed tenant側の承認担当者
- 緊急アクセス手順
- 最終棚卸し日
管理対象テナントだけを記録しても、どの管理者がどの権限を持っているかは判断できません。テナント、テンプレート、グループ、管理者の4つを関連付けて管理することが、複数テナント運用では重要です。
まず1テナントを参照権限で委任管理する
Microsoft Entra Tenant Governanceのcross-tenant delegated administrationを使えば、管理者はgoverning tenantの資格情報を利用して、複数のgoverned tenantへアクセスできます。各テナントに重複したローカル管理者やB2B管理者を作る運用を減らし、セキュリティグループとガバナンスポリシーテンプレートで権限を標準化できる点が大きな利点です。
ただし、導入の成否は機能を有効にすることではなく、誰に、どのテナントで、どのロールを、どの期間だけ許可するかを設計できるかで決まります。
最初に行うべき作業は、管理対象テナントの棚卸しと、管理業務ごとのセキュリティグループ作成です。その後、参照専用テンプレートを1つ作成し、影響の小さいgoverned tenantでサインイン、PIM、ログ、権限変更、緊急復旧まで確認してから展開範囲を広げてください。
コメント