Microsoft Entra Tenant Governanceの2026年4月更新で最も重要なのは、Tenant Configuration Management APIs（TCM APIs）が一般提供（GA）になったことです。結論から言うと、セキュリティ管理者、IDチーム、コンプライアンス担当者は、Microsoft 365テナントの設定を「手作業で点検する対象」から「APIで取得し、ベースラインと照合し、継続監視する対象」へ移行しやすくなりました。Microsoftは2026年4月23日、Microsoft EntraにおけるTCM APIsの一般提供を発表し、6つのMicrosoft 365ワークロードにまたがる200以上のテナント構成設定をエクスポート・監視できると説明しています。(TECHCOMMUNITY.MICROSOFT.COM)
今回の更新は、単なる新APIの追加ではありません。複数テナントを運用する企業、M&A後の統合を進める組織、地域別・事業部別にMicrosoft 365テナントを持つグローバル企業にとって、「設定のばらつき」「監査証跡の不足」「意図しない設定変更」を早く見つけるための土台になります。
Microsoft Entra Tenant Governanceの2026年4月更新ポイント
Microsoft Entra Tenant Governanceは、複数テナント環境の可視化、ポリシー適用、構成管理を中央から扱うための製品体験です。一方、Tenant Configuration Management APIsは、その構成管理機能を支えるMicrosoft Graph APIです。Microsoft公式ブログでは、Tenant Governanceを「製品体験」、TCM APIsを「構成管理機能を支える基盤API」と位置付けています。(TECHCOMMUNITY.MICROSOFT.COM)
今回の更新で押さえるべきポイントは、次の4つです。
| 更新ポイント | 実務上の意味 |
|---|---|
| TCM APIsが一般提供（GA） | 検証だけでなく、本番運用を見据えた導入判断をしやすくなった |
| Microsoft Graphから構成管理できる | PowerShell、CI/CD、チケット管理、監査レポートなど既存運用に組み込みやすい |
| Snapshot、Baseline、Monitor、Configuration driftの考え方が明確化 | 現在値、望ましい状態、継続監視、差分検出を分けて設計できる |
| 6つのワークロードに対応 | Microsoft Entra、Intune、Exchange Online、Teams、Purview、Defenderを横断した構成管理に近づいた |
注意したいのは、「Tenant Governance全体がすべてGAになった」と早合点しないことです。Microsoft Learnでは、Tenant configuration management APIsは一般提供だが、その他のTenant Governance体験にはプレビューのものがあると説明されています。導入時は、API、管理ポータル、ライセンス、サポート範囲を分けて確認する必要があります。(Microsoft Learn)
Tenant Configuration Management APIsとは何か
Tenant Configuration Management APIsは、Microsoft Graph経由でテナント構成を取得、定義、監視するためのAPI群です。従来は管理者が各ポータルを開き、設定値を目視確認したり、個別スクリプトで取得したりする運用が中心でした。TCM APIsでは、構成を宣言的な形式で扱い、望ましい状態からのズレを継続的に検出する考え方に寄せられます。Microsoft Learnでは、TCM APIsが単一または複数ワークロードにまたがる設定管理を可能にし、Microsoft Defender、Microsoft Entra、Exchange Online、Intune、Microsoft Purview、Microsoft Teamsをサポート対象として挙げています。(Microsoft Learn)
実務で理解しやすいように言えば、TCM APIsは「Microsoft 365テナント向けのConfiguration as Codeに近い運用」を実現するための部品です。ただし、現時点では「検出したドリフトを自動で元に戻す万能ツール」と考えるのは危険です。Microsoft GraphのAPI概要では、モニタリングAPIでドリフトを確認し、管理者が関連する管理センターや利用可能な方法で解決すると説明されています。(Microsoft Learn)
何が変わったのか：手作業の監査から継続監視へ
今回のGAで大きいのは、構成管理を「年に数回の棚卸し」から「継続的な状態確認」へ移しやすくなった点です。
たとえば、セキュリティ管理者が本社テナントで望ましい設定を定義し、各国・各事業部のテナントで同じ状態を維持したいケースを考えます。従来は、各テナントの管理センターを開き、設定表と照らし合わせ、Excelや監査シートに記録する作業が発生しがちでした。TCM APIsを使えば、現在の構成をSnapshotとして取得し、Baselineとして望ましい状態を定義し、Monitorで差分を検出できます。
| 従来の運用 | TCM APIsを使った運用 |
|---|---|
| 管理ポータルを個別に確認 | Microsoft Graph APIで構成情報を取得 |
| 監査時だけ設定を確認 | モニターで定期的に差分を確認 |
| 設定変更の影響を後から調査 | Configuration driftとしてズレを検出 |
| テナントごとに属人的な確認 | ベースラインを標準化し、複数テナントに展開 |
| 証跡がスクリーンショットや手作業メモに依存 | Snapshotやモニタリング結果を監査・レビューに活用 |
この変化は、特にグローバル組織で効果が出やすいです。国や地域ごとに運用チームが異なる場合でも、「どの設定を守るべきか」をBaselineとして定義すれば、各チームの裁量を残しながら、最低限のセキュリティ基準を継続的に確認できます。
TCM APIsの中核概念：Snapshot、Baseline、Monitor、Drift
TCM APIsを理解するには、4つの用語を整理するのが近道です。Microsoft公式ブログでも、Snapshot、Baseline、Monitor、Configuration driftsを中核概念として説明しています。(TECHCOMMUNITY.MICROSOFT.COM)
| 概念 | 意味 | 実務での使い方 |
|---|---|---|
| Snapshot | ある時点のテナント構成を取得したもの | 現状把握、監査用の記録、既存テナントからのベースライン作成に使う |
| Baseline | 望ましい構成状態を表す定義 | セキュリティ標準、コンプライアンス要件、グローバル標準設定をJSON形式で表す |
| Monitor | 現在の状態とBaselineを比較する仕組み | 定期的に構成差分を検出し、運用チームへ通知・確認する |
| Configuration drift | Baselineと現在の構成との差分 | 意図しない変更、例外設定、未承認の変更を調査する起点にする |
ここで重要なのは、SnapshotとBaselineを混同しないことです。Snapshotは「今どうなっているか」であり、Baselineは「どうあるべきか」です。既存テナントのSnapshotをそのままBaselineにすると、過去の例外設定や暫定対応まで標準化してしまう危険があります。Baseline化する前に、セキュリティ、ID、コンプライアンスの各チームでレビューしましょう。
セキュリティ管理者・IDチーム・コンプライアンス担当者への影響
今回の更新は、読むべき人によって価値が少し異なります。役割別に見ると、導入時の優先順位を決めやすくなります。
| 主な読者 | 期待できる効果 | 最初に見るべきポイント |
|---|---|---|
| Security admins | 意図しない設定変更やセキュリティ標準からの逸脱を検出しやすくなる | 高リスク設定を優先してBaseline化する |
| Identity teams | Microsoft Entra関連設定を含む複数ワークロードの構成管理を自動化しやすくなる | Microsoft Graphの権限、サービスプリンシパル、監視対象リソースを確認する |
| Compliance teams | 監査時点の構成証跡や、継続監視の結果を説明しやすくなる | Snapshotの保管、例外承認、変更履歴との突き合わせを設計する |
特にコンプライアンス担当者にとっては、「監査のために人が設定を見に行く」よりも、「どのベースラインに対して、いつ、どの差分が検出されたか」を説明できる方が強力です。ただし、Snapshotは永続保存前提ではありません。Microsoft GraphのAPI制限では、Snapshotは最大7日で自動削除されると説明されています。監査証跡として使う場合は、取得後に自社の証跡保管ルールに従って保存する設計が必要です。(Microsoft Learn)
導入前に確認すべき前提条件
TCM APIsを使うには、Microsoft Graphへの認証と、TCMサービスプリンシパルの準備が必要です。Microsoft Learnでは、モニター管理やSnapshot実行のためにMicrosoft Graphへ認証し、さらにモニターが各ワークロードエンドポイントへアクセスするための認証設定が必要だと説明されています。(Microsoft Learn)
確認すべき項目は次のとおりです。
| 確認項目 | 実務上のチェック内容 |
|---|---|
| Microsoft Graph権限 | アプリケーションで使う場合、モニター管理にはConfigurationMonitoring.Read.AllまたはConfigurationMonitoring.ReadWrite.All、SnapshotにはConfigurationMonitoring.ReadWrite.Allが必要になる |
| 管理者ロール | ユーザー委任フローで操作する場合、対象操作に応じた特権ロールを持つ管理者が必要になる |
| TCMサービスプリンシパル | 公式のTenant Configuration Managementサービスプリンシパルをテナントに追加する |
| ワークロード側の権限 | Entra、Exchange Online、Intuneなど、監視対象ワークロードに必要な権限を付与する |
| 権限設計 | 広すぎる権限付与を避け、監視対象と運用目的に合わせて段階的に付与する |
公式ドキュメントでは、Tenant Configuration ManagementサービスプリンシパルのアプリケーションIDとして03b07b79-c5bc-4b5e-9bfa-13acf4a99998が示されています。また、M365 Admin Servicesサービスプリンシパルがテナントに存在することも確認するよう案内されています。(Microsoft Learn)
実務では、最初から全ワークロードに広い権限を付与するのではなく、1つのテナント、1つのワークロード、少数の高リスク設定から始めるのが安全です。特に本番テナントでは、API検証用アプリ、権限付与、監視対象、ログ取得先、例外承認フローを事前に文書化しておきましょう。
API制限から考える運用設計
TCM APIsは継続監視に役立ちますが、無制限に何でも監視できるわけではありません。Microsoft GraphのAPI概要では、モニター数、実行頻度、監視リソース数、Snapshot保持期間などの制限が示されています。(Microsoft Learn)
| 項目 | 現時点の主な制限 | 設計上の注意 |
|---|---|---|
| configurationMonitor数 | 1テナントあたり最大30個 | 部門別・ワークロード別に細かく作りすぎない |
| Monitor実行頻度 | 固定で6時間ごと | リアルタイム検知ではなく、定期検査として設計する |
| 監視可能な構成リソース | 1テナントあたり1日最大800リソース | 高リスク設定を優先し、低リスク項目を詰め込みすぎない |
| Snapshot抽出量 | 1テナントあたり月間最大20,000リソース | 月次監査、変更前後比較、棚卸しの頻度を調整する |
| 表示可能なSnapshotジョブ | 最大12件 | 古いジョブの削除や証跡保管の運用を決める |
| Snapshot保持期間 | 最大7日 | 監査証跡は別システムへ保存する |
| 修正済みDrift | 解決後30日で削除 | 長期分析が必要なら、外部ログやレポートに退避する |
この制限を見ると、導入初期にやるべきことは明確です。すべての設定を監視するのではなく、「変更されると重大なリスクになる設定」を先に選びます。たとえば、ID保護、外部アクセス、メールセキュリティ、データ保護、管理者操作に関わる設定などを優先候補にします。
実務での導入手順
TCM APIsを本番に近い形で試すなら、次の順序が現実的です。
監視対象テナントとワークロードを絞る
最初の対象は、全社標準に近い「代表テナント」または、運用リスクが高い「重要テナント」にします。グローバル企業であれば、本社、リージョン、買収企業、開発・検証環境を同時に対象にするのではなく、まず1つのテナントで構成取得とドリフト検出の動きを確認します。
対象ワークロードも絞りましょう。Microsoft Entra、Intune、Exchange Online、Teams、Purview、Defenderのすべてを一気に扱うと、権限設計、Baseline設計、ドリフト調査の負荷が高くなります。
Snapshotで現在の構成を把握する
次に、現在の構成をSnapshotとして取得します。Snapshotは「今の状態」を把握するための入口です。Microsoft Learnでは、Snapshot APIにより複数ワークロードの現在の構成を取得し、監査、レビュー、トラブルシューティングに役立てられると説明されています。(Microsoft Learn)
ここでのポイントは、Snapshotを取得して終わりにしないことです。取得結果を見て、次のように分類します。
| 分類 | 判断基準 | 次のアクション |
|---|---|---|
| 標準化したい設定 | セキュリティ基準や監査要件に合致している | Baseline候補にする |
| 例外として認める設定 | 業務上必要だが標準から外れている | 例外理由、期限、承認者を記録する |
| 修正すべき設定 | リスクが高く、標準にも合わない | 先に是正してからBaseline化する |
| 判断保留の設定 | 所有者や影響範囲が不明 | ワークロード管理者へ確認する |
Baselineを作る
Baselineは、監視の基準になる「望ましい構成」です。Microsoft Graphのリソース定義では、configurationBaselineは、監視したい少なくとも1つのリソースと1つのプロパティを含むものとして説明されています。(Microsoft Learn)
Baseline設計で失敗しやすいのは、現状をそのまま正解にしてしまうことです。古い例外設定や一時対応が残っているテナントを「known good」として扱うと、問題のある設定まで標準化されます。Baselineは、Snapshot、社内セキュリティ基準、規制要件、運用実態を突き合わせて作るべきです。
複数テナントへ展開する場合は、テナントごとに異なる値をパラメータ化することも検討します。Microsoft Learnでは、baselineParameterにより、テナント固有の値を抽象化し、1つのBaselineを複数テナントの監視に使えると説明されています。(Microsoft Learn)
Monitorを作成して定期確認する
Monitorは、Baselineと実際のテナント構成を比較する仕組みです。configurationMonitorは、望ましい構成状態からの逸脱を定期的に検出するリソースとして定義されています。実行頻度は標準で6時間ごとで、現在はGMTの6時、12時、18時、0時に固定的に処理されると説明されています。(Microsoft Learn)
このため、Monitorをアラート運用に組み込む場合は、「即時検知」ではなく「数時間単位の構成ドリフト検知」として扱うのが適切です。重大なセキュリティイベントのリアルタイム監視には、Microsoft Defender、Microsoft Sentinel、監査ログなどの別機能と組み合わせましょう。
Driftを調査し、変更管理に接続する
Configuration driftは、Baselineと現在値の差分です。configurationDriftリソースでは、ドリフトが検出されたリソース、プロパティ、初回検出時刻、ステータスなどを確認できます。(Microsoft Learn)
ドリフトが出たら、すぐに「インシデント」と決めつけるのではなく、まず次の順に確認します。
| 確認項目 | 見るべき内容 |
|---|---|
| 承認済み変更か | 変更管理チケット、作業申請、メンテナンス予定と一致するか |
| 例外設定か | 期限付きの例外、地域要件、業務要件として承認されているか |
| 権限のある管理者が変更したか | 管理者操作ログや監査ログと突き合わせる |
| 影響範囲はどこか | 単一テナントか、複数テナントに広がるか |
| Baseline側が古くないか | ポリシー変更により、Baseline更新が必要ではないか |
ドリフトを検出するだけでは、運用は改善しません。検出結果を、チケット管理、変更承認、例外管理、監査レポートに接続して初めて価値が出ます。
グローバル組織での活用シーン
Microsoft Entra Tenant GovernanceとTCM APIsは、単一テナントの小規模運用よりも、複数テナントを抱える組織で効果が出やすい機能です。Microsoft Learnでも、Tenant GovernanceはM&A、セキュリティやプライバシー要件による分離、テスト環境、ユーザー作成のシャドーITテナントなど、複数テナント運用の課題に触れています。(Microsoft Learn)
代表的な活用シーンは次のとおりです。
| シーン | 活用方法 |
|---|---|
| M&A後のテナント統制 | 買収企業の既存テナントをSnapshotで把握し、本社標準との差分を確認する |
| 地域別テナントの標準化 | 各国テナントの設定をBaselineと比較し、最低限のセキュリティ基準を維持する |
| 監査対応 | 監査時点の構成証跡と、定期的なドリフト確認結果を提示しやすくする |
| MSP・パートナー運用 | 複数顧客や複数テナントに対して、標準化された監視ワークフローを構築する |
| シャドーIT対策 | 関連テナントの可視化と組み合わせ、管理外テナントのリスク把握につなげる |
ここでの独自の判断基準は、「どのテナントを統制するか」より先に、「どの設定の逸脱を許容できないか」を決めることです。テナント数が多い組織ほど、対象範囲から考えると設計が膨らみます。先に守るべき設定を定義すれば、対象テナントの優先順位も決めやすくなります。
導入時に失敗しやすいポイント
TCM APIsは強力ですが、導入方法を誤ると、監視結果が増えるだけで運用が回らなくなります。
すべての設定を一度に監視しようとする
API制限や運用負荷を考えると、最初から全設定を対象にするのは避けるべきです。まずは「逸脱したらリスクが高い設定」に絞ります。ドリフト件数が多すぎると、現場は通知を無視し始めます。
Snapshotを監査証跡として永久保存できると思い込む
Snapshotの保持期間には制限があります。監査証跡として使うなら、取得後に自社のログ保管基盤、GRCツール、ドキュメント管理システムへ保存する流れを作ってください。(Microsoft Learn)
Baseline更新の影響を軽視する
Microsoft GraphのAPI概要では、既存MonitorのBaselineを更新すると、そのMonitorで過去に生成されたモニタリング結果と検出済みドリフトが自動削除されると説明されています。Baseline変更前には、結果の退避、変更承認、影響範囲の確認を行いましょう。(Microsoft Learn)
ドリフト検出と自動修復を混同する
TCM APIsは構成状態の取得と監視に強みがありますが、検出された差分をどう是正するかは、別途運用設計が必要です。ドリフトが出たら誰が確認するのか、どの管理センターやスクリプトで修正するのか、例外をどう扱うのかを決めておきましょう。
権限を広く付けすぎる
複数ワークロードにまたがる監視では、サービスプリンシパルに必要な権限が増えがちです。便利だからといって広い権限をまとめて付けると、監視基盤そのものが高権限リスクになります。段階的に権限を付与し、アプリの所有者、資格情報の保護、アクセスレビューをセットで設計しましょう。
まず何から始めるべきか
TCM APIsのGAを受けて、すぐに大規模展開する必要はありません。現実的には、次の順序で小さく始めるのが安全です。
| フェーズ | やること | 成果物 |
|---|---|---|
| 1 | 監視したいテナントとワークロードを1つずつ選ぶ | 対象範囲の一覧 |
| 2 | Snapshotを取得して現在の設定を棚卸しする | 現状構成レポート |
| 3 | セキュリティ標準に沿ってBaseline候補を作る | Baseline草案 |
| 4 | Monitorを作成して数回の実行結果を見る | ドリフト検出結果 |
| 5 | ドリフトをチケット管理・例外管理に接続する | 運用フロー |
| 6 | 対象テナントとワークロードを段階的に広げる | 標準化された構成監視プロセス |
最初のゴールは、「すべてを監視すること」ではなく、「重要な構成変更に気づける状態を作ること」です。Security adminsは高リスク設定、identity teamsはMicrosoft Graph権限とサービスプリンシパル、compliance teamsはSnapshotとドリフト結果の証跡化から着手すると、役割ごとの責任が明確になります。
まとめ：GAを機に構成管理を“点検”から“継続運用”へ移す
2026年4月のMicrosoft Entra Tenant Governance更新で、Tenant Configuration Management APIsが一般提供になったことは、Microsoft 365テナント運用における重要な転換点です。これにより、テナント構成をSnapshotで取得し、Baselineで望ましい状態を定義し、Monitorで継続的に比較し、Configuration driftとして差分を確認する運用を組み立てやすくなりました。
ただし、導入で成果を出すには、APIを呼び出すだけでは不十分です。監視対象の優先順位、権限設計、Baselineレビュー、ドリフト対応、監査証跡の保存まで含めて設計する必要があります。
次に取るべき行動は明確です。まずは重要テナントを1つ選び、対応ワークロードを絞り、Snapshotを取得してください。その結果をもとにBaseline候補を作り、Monitorで実際にどのようなドリフトが出るかを確認します。小さな監視サイクルを作ってから、グローバル標準や複数テナント運用へ広げるのが、TCM APIsを安全に活用する近道です。
コメント