複数のMicrosoft Entraテナントで、管理者ロールや業務アプリの権限を個別に設定していると、テナントごとの差異や過剰権限が生じやすくなります。Microsoft Entra Tenant Governanceのgovernance policy templates（ガバナンスポリシーテンプレート）を使えば、統治側テナントで委任するロールとアプリ権限をひな型化し、複数のgoverned tenantへ一貫した基準で展開できます。
ただし、テンプレートは既存テナントへ設定を強制配布する仕組みではありません。各ガバナンス関係には適用時点のポリシースナップショットが保存され、テンプレートを更新しても既存の関係には自動反映されません。変更を適用するには、統治対象テナントによる再確認と承認が必要です。標準化しながら、各テナントの独立性と承認プロセスを維持する設計になっています。なお、2026年7月末時点でMicrosoft Entra Tenant Governanceはプレビュー段階のため、本番展開前に最新の公式情報を確認してください。(Microsoft Learn)
複数Entraテナントへ同じガバナンスポリシーを適用するテンプレート
Microsoft Entra Tenant Governanceでは、管理の中心となるテナントを「governing tenant」、管理される側を「governed tenant」と呼びます。
ガバナンスポリシーテンプレートは、この2つのテナント間に作成するgovernance relationshipの設計図です。1つのテンプレートを複数のgovernance relationshipで再利用できるため、子会社、部門、開発環境、買収先などに共通の管理基準を適用できます。
基本的な流れは次のとおりです。
- governing tenantでガバナンスポリシーテンプレートを作成する
- テンプレートに委任管理ロールとマルチテナントアプリを設定する
- governed tenantに対して、対象テンプレートを指定したガバナンス要求を送る
- governed tenantの管理者が要求内容を確認して承認する
- 承認された内容がgovernance relationshipのポリシースナップショットとして保存される
- 同じテンプレートを使い、別のgoverned tenantにもガバナンス要求を送る
Microsoft Entra Tenant Governanceは、1つのgoverning tenantから複数のgoverned tenantを管理する「1対多」の構成をサポートしています。一方、あるテナントがgoverned tenantであると同時に、別のテナントのgoverning tenantになる多階層構成はサポートされていません。地域統括テナントを挟む階層型の運用を考えている場合は、中央テナントから各テナントを直接統治する構成を検討する必要があります。(Microsoft Learn)
ポリシーテンプレートで標準化できる範囲
ガバナンスポリシーテンプレートで定義できる中心的な要素は、次の2つです。
| 設定項目 | 標準化できる内容 | 展開時の動作 |
|---|---|---|
| クロステナント委任管理 | Microsoft Entraの組み込みロールと、governing tenant側のセキュリティグループとの対応 | governed tenantにGDAPベースのクロステナントロール割り当てを作成 |
| マルチテナントアプリ管理 | カスタムマルチテナントアプリと、そのアプリに付与するアクセス許可 | governed tenantにサービスプリンシパルと対応するアクセス許可を作成 |
| ポリシースナップショット | 関係作成時または更新時に承認されたロールとアプリ権限 | governance relationship単位で適用内容を保持 |
委任管理では、governing tenantにあるロール割り当て可能なセキュリティグループへMicrosoft Entraの組み込みロールを対応付けます。グループのメンバーはgoverning tenant側で管理でき、対象テナントごとにローカル管理者アカウントやB2Bゲストアカウントを作成しなくても、governing tenantの資格情報を使って管理できます。
governance relationshipが成立すると、governed tenantにはgoverning tenant側のセキュリティグループに対応するリモートテナントグループが作成されます。誰に委任権限を与えるかはgoverning tenant側のグループメンバーシップで管理し、どのロールを許可するかは承認済みのgovernance relationshipで管理する構造です。(Microsoft Learn)
テナント内の全設定を統一する機能ではない
ここで注意したいのは、ガバナンスポリシーテンプレートが、条件付きアクセスや認証方法、Teams、Exchange Online、Intuneなどの設定値を直接そろえるテンプレートではないことです。
目的別に使い分けると、次のようになります。
| 実現したいこと | 使用する仕組み |
|---|---|
| 複数テナントで同じ管理者ロールを委任する | ガバナンスポリシーテンプレート |
| 同じカスタムアプリと権限を複数テナントへ展開する | ガバナンスポリシーテンプレート |
| テナント設定が基準からずれていないか検出する | Configuration Managementのベースラインとモニター |
| AzureやDefender固有の管理権限を付与する | 各ワークロードのRBAC |
| 検出した構成差異を修正する | 委任管理、個別操作、または別途用意した自動化 |
Tenant GovernanceのConfiguration Managementでは、望ましいテナント構成をJSON形式の構成ベースラインとして定義し、実際の設定との差異をモニターできます。したがって、複数テナントの標準化では、ポリシーテンプレートで管理経路を統一し、構成ベースラインで設定差異を検出するという組み合わせが実用的です。(Microsoft Learn)
テンプレートは対象テナントの種類ごとに分ける
すべてのテナントへ同じ強い権限を与える巨大なテンプレートを1つ作ると、運用は簡単に見えても、最小権限の原則から外れやすくなります。
実務では、テナントの用途や管理責任に合わせてテンプレートを分ける方法が適しています。
| テンプレート例 | 主な対象 | 設計方針 |
|---|---|---|
TG-READONLY-v1 | 監査対象、買収直後、管理範囲が未確定のテナント | 読み取り中心のロールだけを設定 |
TG-IDENTITY-OPS-v1 | 中央IT部門がID運用を担当するテナント | ユーザー、認証、グループなど担当業務に必要なロールだけを設定 |
TG-APP-MGMT-v1 | 共通管理アプリを利用するテナント | カスタムアプリと必要なアクセス許可を分離して管理 |
default | セキュアな新規テナント作成機能で追加するテナント | 新規作成直後に必要な最小限の管理権限を設定 |
テンプレート名には、用途と版数を含めると管理しやすくなります。さらに、テンプレートごとに次の情報を台帳化しておくと、後から権限の根拠を説明できます。
- テンプレートの所有部門
- 対象となるテナント区分
- 委任するMicrosoft Entraロール
- ロールを割り当てるセキュリティグループ
- 対象アプリとアクセス許可
- 適用済みテナント
- 現在のテンプレートバージョン
- 最終レビュー日
- テナント固有の例外
特に、買収直後のテナントや外部組織が管理するテナントには、最初から運用権限を広く与えないことが重要です。まず読み取り中心のテンプレートで構成や運用状況を確認し、管理責任が明確になってから権限を追加する段階的な展開が安全です。
ガバナンスポリシーテンプレートを作成する手順
事前条件を確認する
テンプレートを作成してgovernance relationshipを設定するには、governing tenant側でTenant Governance Administratorロールが必要です。
また、委任管理に利用するセキュリティグループは、あらかじめgoverning tenantに用意します。グループのメンバー管理者と、権限変更を承認する責任者も決めておきましょう。(Microsoft Learn)
Microsoft Entra管理センターでテンプレートを作成する
Microsoft Entra管理センターで、次の順に操作します。
- governing tenantへTenant Governance Administratorとしてサインインする
Tenant governanceを開くTemplatesを選択するCreate templateを選択する- クロステナント委任管理に使用する組み込みロールを選択する
- 各ロールをgoverning tenant側のセキュリティグループへ割り当てる
- 必要に応じてカスタムマルチテナントアプリを追加する
- アプリのアクセス許可を確認する
- テンプレートを保存する
1つのセキュリティグループには複数のロールを対応付けられ、1つのテンプレート内に複数のグループを定義できます。ただし、ロールをまとめすぎると職務分離が難しくなるため、「監視担当」「ID運用担当」「アプリ運用担当」など、実際の担当業務に合わせてグループを分けることが重要です。(Microsoft Learn)
governed tenantへガバナンス要求を送る
governance relationshipの作成方法は、テナント間の関係によって異なります。
共有課金アカウントに基づくbilling signalがある場合や、すでに有効なgovernance relationshipがある場合は、governing tenantから要求を送り、governed tenantが承認する2段階の手順を利用できます。
それ以外の場合は、次の3段階です。
- 将来のgoverned tenantからgoverning tenantへ招待を送る
- governing tenantがテンプレートを指定してガバナンス要求を送る
- governed tenantが内容を確認して承認する
3段階の手順を使用する場合、governing tenant側でガバナンス招待の受信を有効にする必要があります。この設定は既定で無効です。招待の受信後は、不要な招待を受け付けないよう再び無効にする運用が推奨されます。
ガバナンス招待の有効期間は30日、ガバナンス要求の有効期間は14日です。複数テナントへ展開する場合は、各テナントの承認担当者と日程を合わせてから要求を送ると、期限切れによるやり直しを防げます。(Microsoft Learn)
まず1テナントでパイロット展開する
テンプレートを作成した直後に全テナントへ要求を送るのではなく、影響の小さいテナントでパイロット展開します。
確認すべき項目は次のとおりです。
- 想定したセキュリティグループだけにロールが割り当てられているか
- governing tenantの対象ユーザーがgoverned tenantへサインインできるか
- 不要な管理画面や操作まで許可されていないか
- カスタムアプリのサービスプリンシパルが作成されているか
- アプリに想定外のアクセス許可が付与されていないか
- governed tenant側のサインインログと監査ログに操作が記録されるか
- AzureやDefenderなどで追加のワークロード固有ロールが必要ではないか
governed tenantでは、governing tenantからアクセスした管理者が、サインインログや監査ログ上で「テナント名＋Technician」という形式の表示名になる場合があります。この表示を利用してサインインや変更操作を追跡できます。(Microsoft Learn)
パイロットで問題がなければ、低リスクのテナントから順に展開します。一括展開よりも、数テナントずつ承認、検証、記録を繰り返す方が、過剰権限やアプリ権限の誤りを早期に発見できます。
テンプレートを更新しても既存テナントには自動反映されない
ガバナンスポリシーテンプレートを変更して保存すると、テンプレートのバージョン番号が増加します。しかし、すでに作成済みのgovernance relationshipは、以前に承認されたポリシースナップショットを保持したままです。
変更内容を既存のgoverned tenantへ適用するには、次の操作が必要です。
- governing tenantでテンプレートを更新する
- 対象のgoverned tenantへ更新後のテンプレートを指定したガバナンス要求を送る
- governed tenantの管理者がロールとアプリ権限の変更内容を確認する
- governed tenantが要求を承認する
- governance relationshipのポリシースナップショットが更新される
- GDAPロール割り当てやサービスプリンシパルのアクセス許可が更新される
この再承認は手間ではありますが、governing tenantが一方的に権限を拡大できないようにするための重要な制御です。(Microsoft Learn)
更新は段階的に展開する
テンプレート更新時は、次の順番で適用すると安全です。
- 検証用または低リスクのテナント
- 中央IT部門が直接管理するテナント
- 子会社や部門テナント
- 外部関係者や別組織が承認を担当するテナント
どのテナントがどのテンプレートバージョンを承認済みなのか、別途展開台帳で管理してください。テンプレートを更新しただけでは全テナントが同じ状態にならないため、バージョンの未適用テナントを定期的に確認する必要があります。
また、既存のgovernance relationshipを更新する際には、元となったテンプレートへのアクセスが必要です。利用中のテンプレートを削除すると、そのテンプレートを使った関係を通常の更新手順で更新できず、新しい関係の作成が必要になります。不要に見える旧テンプレートも、適用中の関係が残っている間は削除せず、「廃止予定」などの状態で管理する方が安全です。(Microsoft Learn)
新規テナントにはdefaultポリシーテンプレートを使える
Tenant Governanceのセキュアなadd-on tenant作成機能を利用する場合は、特別なdefaultポリシーテンプレートを使用できます。
通常のテンプレートにはGUID形式のIDが割り当てられますが、defaultテンプレートのIDはdefaultです。新しいadd-on tenantを作成すると、親テナントと新規テナントの間に、このテンプレートを使ったgovernance relationshipが自動的に作成されます。
ただし、defaultテンプレートは事前に構成しておく必要があります。defaultテンプレートが存在しない場合、新規テナントを作成してもガバナンス関係は自動作成されません。新規テナントを最初から管理下に置きたい場合は、テナント作成手順を開始する前に設定を済ませてください。(Microsoft Learn)
defaultテンプレートには、日常運用で使うすべての権限を詰め込むのではなく、初期管理とアクセス回復に必要な最小限の権限を設定するのが基本です。テナントの用途が確定した後で、用途別テンプレートを使った関係へ段階的に移行すると、不要な権限を残しにくくなります。
ポリシーテンプレートの上限を確認する
2026年7月末時点で、ガバナンスポリシーテンプレートには次の上限があります。
| 項目 | 上限 |
|---|---|
| 1テンプレートに設定できるマルチテナントアプリ | 10個 |
| 1つのマルチテナントアプリに設定できるアクセス許可 | 100個 |
| 1テンプレートに設定できるロール割り当て | 10個 |
アプリやロールを1つのテンプレートへ集約しすぎると、上限だけでなく、承認時の確認も難しくなります。上限に近づく前に、委任管理用とアプリ配布用、または業務単位でテンプレートを分割することを検討してください。
プレビュー期間中は上限や画面構成が変更される可能性があります。設計書へ数値を固定的に記載する場合は、確認日も併記しておくと更新漏れを防げます。(Microsoft Learn)
必要なライセンスは利用機能によって異なる
クロステナントのGDAP委任管理を含むgovernance relationshipには、governing tenant側でMicrosoft Entra P1、Microsoft Entra P2、またはMicrosoft Entra ID Governanceが必要です。
カスタムマルチテナントアプリをgoverned tenantへプロビジョニングする機能には、Microsoft Entra ID Governanceが必要です。
ライセンスはgoverned tenantの全ユーザーへ割り当てるのではなく、governing tenantでgovernance relationshipを構成する管理者に必要です。管理対象テナントやgovernance relationshipの数が増えても、それだけを理由にライセンス数が増えるわけではありません。複数の管理者が関係を構成する場合は、構成を担当する管理者ごとに必要なライセンスを確認します。(Microsoft Learn)
| 利用内容 | 主なライセンス条件 |
|---|---|
| GDAPによるクロステナント委任管理 | Microsoft Entra P1、P2、またはID Governance |
| カスタムマルチテナントアプリのプロビジョニング | Microsoft Entra ID Governance |
| governed tenant側 | governance relationship用ライセンスは原則不要 |
| ライセンス数 | 関係を構成するgoverning tenant側管理者を基準に算定 |
標準化で失敗しやすいポイント
1つのテンプレートに権限を集約しすぎる
監視、ユーザー管理、アプリ管理、緊急対応を1つのテンプレートにまとめると、すべての担当者が広い権限を持ちやすくなります。担当業務とリスクに応じて、グループやテンプレートを分割してください。
テンプレート更新だけで全テナントが更新されたと思い込む
テンプレートを保存しても、既存のgovernance relationshipは更新されません。各テナントへの再要求、承認、適用確認までを変更作業として扱う必要があります。
テナント固有の事情を確認せず展開する
同じ組織内でも、法令、データ管理責任、外部委託契約、運用時間帯、既存管理者などが異なる場合があります。共通テンプレートをそのまま適用するのではなく、適用可否と例外をテナントごとに確認します。
AzureやDefenderの権限まで付与されたと考える
ガバナンスポリシーテンプレートで定義するMicrosoft Entraロールだけでは、Azure RBACやDefender Unified RBACなどのワークロード固有操作ができない場合があります。必要な追加権限は、governed tenant側で目的を確認したうえで個別に割り当てます。(Microsoft Learn)
アプリのアクセス許可を十分に確認しない
サービスプリンシパルを複数テナントへ展開すると、誤ったアクセス許可も複数テナントへ広がります。アプリ名だけで判断せず、APIアクセス許可、管理者同意の必要性、データ参照範囲を確認してください。
展開後の監査を行わない
標準化は、テンプレートを適用して終わりではありません。セキュリティグループのメンバー、サインインログ、監査ログ、アプリ権限、適用済みテンプレートのバージョンを定期的に確認する必要があります。
最初は読み取り中心のテンプレートから始める
Entra Tenant Governanceのガバナンスポリシーテンプレートを使うと、複数テナントに対する委任管理ロールとカスタムアプリ権限を再利用可能な形で標準化できます。
一方で、テンプレートは全テナント設定を強制的に同一化するものではありません。各governance relationshipには承認時点のポリシースナップショットが保持され、更新時にもgoverned tenant側の承認が必要です。
導入時は、次の順に進めると安全です。
- 管理対象テナントと管理責任者を一覧化する
- 必要な管理作業と最小権限を整理する
- 読み取り中心のパイロット用テンプレートを作成する
- 影響の小さい1テナントへ適用する
- ロール、サービスプリンシパル、サインインログ、監査ログを確認する
- テナント区分ごとにテンプレートを分ける
- バージョンと承認状況を台帳で管理しながら段階展開する
- 構成ベースラインによる設定差異の監視を組み合わせる
最初から全テナントを完全に統一しようとせず、まず「誰が、どのテナントで、何を管理できるか」をそろえることが重要です。その管理経路をポリシーテンプレートで標準化したうえで、Configuration Managementによる構成差異の検出を追加すると、複数テナント運用を継続的に統制しやすくなります。
コメント