Microsoftは、大規模組織が複数のテナントでMicrosoftサービスを運用する理由として、M&A、セキュリティやプライバシーに配慮したワークロードの分離、テスト環境などを挙げている。さらに多くの組織には、中央のIT部門が管理しておらず存在自体を知らないことも多い、利用者が作った「シャドーIT」テナントがあるとも書いている[1]。自社にテナントがいくつあるかを即答できない状態は、日本企業のID基盤担当にも思い当たるところがあるはずだ。
2026年8月10日、Microsoftはこうしたテナントを可視化して統制下に置く「Microsoft Entra Tenant Governance」を一般提供（GA）した[2]。Entra ID（旧Azure Active Directory、Microsoftのクラウド版ID基盤）、Intune、Exchange Online、Teams、Purview、Defenderの6サービスを横断し、シャドーテナントと設定ドリフト（承認済みの設定基準からのずれ）を検出する[1]。以下では、検出の仕組みとライセンス条件を整理したうえで、多階層の子会社を抱える日本企業でどこまで効くのかを検討する。
予備知識
- シャドーテナント: 情報システム部門が把握していない、事業部や子会社が独自に契約したMicrosoft 365・Entra IDの環境。
- 設定ドリフト: 承認済みの設定基準（ベースライン）から、実際の設定が時間とともにずれていく状態。
- ガバナンス関係: あるテナント（統治側）が別のテナント（被統治側）に対し、最小権限で管理タスクを実行できるようにする委任の仕組み。
- 構成ベースライン: あるべき設定状態をJSON形式で定義した基準で、監視の比較対象になる。
テナント統制を担当する前に、Entra IDの基本操作とテナント設定の全体像を押さえておきたい担当者向け。
Entra Tenant Governanceは何を一般提供したのか
Microsoft Entra Tenant Governanceは、公開プレビューを経て2026年8月10日に一般提供へ移行した[2]。Microsoft自身が受けた、注目度の高い高度なインシデントへの対応から得た知見をもとに設計されたという[2]。
機能は4つに整理される[1]。
- 関連テナント: 自組織に関係するテナントを自動検出する
- ガバナンス関係: 検出したテナントに最小権限の管理関係を樹立する
- テナント構成管理: 6サービス横断で設定基準を監視する
- 安全なテナント作成: 新規テナントの作成者を制御し、作成時点からガバナンス関係を自動で結ぶ
公開プレビュー以降の追加点として、ID Governance・Entra Suite・Microsoft 365 E7ライセンスを持つ顧客向けに監視・スナップショットの上限が引き上げられた。関連テナントについて得られる情報も充実し、可視性が深まったとしている。スナップショットからモニターを作成する管理ポータルの新UIがプレビュー提供されているほか、エンタープライズ契約（EA）や従量課金（PAYG）といった旧来の契約形態の追加テナントもガバナンス対象に含められるようになった[2]。
監査側がテナントの統制状況をどう評価するかを理解すると、Tenant Governanceのスナップショットを監査証跡として位置づけやすくなる。
シャドーテナントと設定ドリフトをどう検出するか
関連テナントの検出は3種類のシグナルに基づく。B2B（企業間）連携のシグナルは他テナントとの招待・登録・管理者アクセスの有無を測定し、マルチテナントアプリのシグナルは権限を持つアプリの登録元・アクセス先のテナントを特定する[1]。共有請求先アカウントのシグナルは、同じ請求アカウントに紐づく他テナントを洗い出す[1]。
構成管理は、Entra ID、Intune、Exchange Online、Teams、Purview、Defenderの6サービスにまたがる200種類超のリソースタイプに対応する[1]。あるべき状態をJSON形式のベースラインとして定義し、「既知の良好な状態」にあるテナントのスナップショットから作成を始めることもできる。モニターは6時間ごとに実際の状態と照合し、ずれたプロパティを一覧表示する[1]。
Microsoftは、架空企業Caldovaを使った説明シナリオを2つ示している。そのうちの一つは主要テナントを対象にしたもので、承認された状態で取得しておいたスナップショットからモニターを作成しておけば、Intuneのデバイスコンプライアンスポリシーが意図せず変更されて監査で不適合を指摘されたときに、何がどう変わったかを特定して承認済みの設定に戻せる、という流れである[2]。ドリフト監視がなければ、監査ログを手作業で追い、変更が悪意によるものか誤操作かを推測し、あるべき設定を再構築する必要があった、とMicrosoftは説明する[2]。
数千台のサーバーの特権ID（root権限やDB管理者アカウントなど強い操作権限を持つID）をCyberArkで一元管理し、年次の内部監査でアクセス統制の証跡を求められるセキュリティ担当者にとって、この買収は他人事ではない。Palo Alt[…]
ライセンスと費用構造——BasicとPremiumの境界
Tenant Governanceは、Tenant Governance BasicとTenant Governance Premiumの2つのサービスレベルで提供される[1][3]。
| ライセンス | 監視の上限（1テナントあたり） | スナップショットの上限（1テナントあたり） |
|---|---|---|
| Entra ID P1/P2（Basic、M365 E3・Business Premium・E5に含む） | 最大30モニター、1日800設定リソースまで | 月2万リソースまで、アクティブジョブ12件まで |
| Entra ID Governance追加1ライセンス（Premium） | 基本容量に加え1日10設定リソース追加 | 基本容量に加え月35設定リソース追加 |
表のとおり、P1とP2でTenant Governanceの容量は変わらない。容量に差が出るのはEntra ID Governanceを持つかどうかだけである[3]。Premiumは追加購入したライセンス1本ごとに容量が積み上がる仕組みで、一括りの上位プランではない。監視対象が基本容量の800リソースを超えた分だけ、必要本数のライセンスを追加する。Microsoftは、1,000リソースを日次監視したい場合に超過分200リソースをまかなうには20本が必要になる、という計算例を挙げている[3]。
関連テナントの検出機能はEntra ID Governanceライセンスが必須で、検出を有効化した管理者本人に加え、結果を閲覧・操作する管理者全員がライセンスを要る。統治対象のテナント数やテナントの管理者数は関係せず、利用する管理者の人数だけが必要ライセンス数を決める[3]。
ガバナンス関係の樹立は、クロステナントの委任管理（GDAP）であればP1・P2・Governanceのいずれかで足りるが、カスタムのマルチテナントアプリを注入する高度な用途にはGovernanceが要る。ライセンスが必要なのは関係を構成する統治側テナントの管理者のみで、被統治側テナントにはライセンスが不要である[3]。
安全なテナント作成は、有償のMicrosoftクラウド契約を持つ顧客であればEntra ID Freeでも利用でき、追加ライセンスは不要である[3]。個別のライセンス価格は、確認した一次情報には明記されていなかった。
Google Cloud上でマイクロサービス数十〜数百単位のアラートポリシーを運用している企業のSRE・クラウドコスト管理担当にとって、アラート自体は「無料で使える安全網」という位置づけだった。Google Cloudは今後、この前提を変[…]
導入プロセス——検出から是正までの実務ステップ
Microsoftが示す導入シナリオは次の順で進む。まず共有請求先アカウントのシグナルから、社員が独自に作成したテスト用テナントなどのシャドーテナントを検出する[2]。
次に、そのテナントへの管理者サインインの形跡を確認し、申請と承認のプロセスを経てガバナンス関係を樹立する。この時点でTenant Governance Administratorロールが付与され、新たな管理者アカウントを作らずに設定監視を展開できる[2]。
続いて、既に運用している主要テナントのスナップショットを取得し、それを土台に対象テナントの構成ベースラインを定義する。Microsoftの例では、この段階で条件付きアクセスポリシーが未設定であることが判明し、重大なリスクとして扱われている[2]。ベースラインを設定した後は継続的なドリフト監視に移行し、検出された差分から着手し、統制プログラムの成熟に合わせてモニターを見直していく[2]。
ガバナンス関係は隣接領域にも拡張されている。プレビュー中のMicrosoft Agent 365によるマルチテナントエージェント管理では、統治テナント側にTenant Governanceライセンス、被統治テナント側にAgent 365ライセンスが必要になる[2]。DefenderとSentinelの委任管理も同様にプレビュー提供されており、MSP・MSSPが顧客テナントを完全な管理者権限なしに運用できる仕組みが用意されている[2]。
多階層の子会社を抱える日本企業でテナント統制はどう機能するか
Microsoftが複数テナント化の理由に挙げるM&Aとワークロードの分離は[1]、持株会社の下に子会社が連なる日本企業の構図とそのまま重なる。買収した会社が既存のMicrosoft 365契約を維持したまま連結に入れば、本社の管理が届かないテナントがその数だけ増える。
ここで取り違えやすいのが、ライセンス種別と容量の関係である。Tenant Governanceの容量はP1でもP2でも同じで、差が出るのはEntra ID Governanceを持つかどうかだけだ[3]。子会社ごとに契約が分かれていても、P1どまりかP2かで監視できるリソース数は変わらない。効いてくるのは、1日に何リソースを監視対象にするかという一点である。
費用の増え方も、テナント数ではなくリソース数に連動する。ガバナンス関係で必要なライセンス数は関係を構成する管理者の人数で決まり、関係の本数は影響しない[3]。子会社が10社に増えても、関係を構成するのが本社の管理者1人なら1本のままだ。増えるのは監視対象リソース数に比例するPremiumの本数のほうである。
一方、関係の樹立には招待・申請・承認のワークフローが挟まる[1]。被統治側の手続きが入る分、統制の適用が完了するまでの時間は子会社の数だけ積み上がる。ライセンスの見積もりより先に動かすべきは、この合意形成のほうだ。
監査との接点では、スナップショットが一定の監査要件を満たす助けになるとMicrosoftは書いている[1]。承認済みの構成をそのまま記録として残せるため、設定変更の是非を後から説明する材料になる。
よくある質問（FAQ）
シャドーテナントとは何ですか
情報システム部門が把握・管理していない、社員や事業部、子会社が独自に作成・契約したMicrosoft 365やEntra IDのテナントを指す。Microsoftは、存在を知らないテナントがあると各テナントの設定が適切かを検証しにくく、組織のセキュリティとコンプライアンスの目標に対するリスクになると説明している[1]。
既存のMicrosoft 365 E3でもテナントガバナンスを使えますか
使える。M365 E3に含まれるEntra ID P1のライセンスで、Basic容量（1テナントあたり最大30モニター、1日800設定リソースまでの監視、月2万リソースまでのスナップショット）を追加コストなしに利用できる[3]。
子会社のテナントを本社が勝手に監視できますか
既存テナントとのガバナンス関係は招待・申請・承認のワークフローで定義する仕組みで、被統治側テナントでの手続きを経る[1]。ただし、本社の商用請求アカウントの配下で作られたアドオンテナントについては別の経路がある。Microsoft Entraのアセットを使って管理アクセスを回復できる仕組みが用意されており、そのテナントの最後の管理者が退職した場合や、攻撃者がテナントを侵害した場合が想定用途として挙げられている[1]。
まとめ
Tenant Governanceは、シャドーテナントの検出と設定ドリフトの監視を、既存のEntra ID P1/P2に含まれるBasic容量の範囲でまず試せる[3]。容量を超えた分だけPremiumを積み増す設計なので、投資額は「1日に何リソースを監視対象にするか」でほぼ決まる。
先に確定させるべきは、ガバナンス関係を結ぶ子会社の数ではなく、監視したい設定項目の範囲である。関係の本数はライセンス数に影響しないが、監視対象リソース数は800を超えた分がそのままライセンス本数に変換されるからだ[3]。共有請求先アカウントのシグナルで関係するテナントを洗い出し、その構成リソース数を数えるところから始めるのが、見積もりへの最短経路になる。
出典
[1] What is Microsoft Entra Tenant Governance?[2] Microsoft Entra Tenant Governance is now generally available
[3] Licensing for Microsoft Entra Tenant Governance
