Microsoft Entra ID Governance を手作業の管理から policy-as-code に近づけたい IAM engineers や platform teams にとって、2026年4月16日時点で注目すべき更新は Tenant Configuration Management APIs、いわゆる tenant-config APIs です。結論から言うと、このAPIは「現在のテナント設定を取得する」「望ましい状態との差分を検知する」「複数テナントで同じガバナンス設定を再現する」ための土台になります。Microsoft の March 2026 更新では、Microsoft Entra ID Governance の新機能として Tenant configuration management APIs が掲載されており、TCM APIs は Microsoft Graph 経由で複数ワークロードのテナント構成を管理・監視する仕組みとして説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
特に重要なのは、tenant-config APIs が「管理画面で設定する便利機能」ではなく、構成を宣言的に扱うためのAPI である点です。条件付きアクセス、認証方法、エンタイトルメント管理、外部ID関連ポリシーなどを手作業だけで維持している組織では、例外設定の戻し忘れ、担当者ごとの設定差、監査時の証跡不足が起きやすくなります。tenant-config APIs を活用すると、こうしたIDガバナンスの設定をコードレビュー、差分検知、監査証跡、再利用可能なベースラインに組み込みやすくなります。
tenant-config APIs が ID ガバナンスで重要になる理由
Microsoft Entra ID Governance の現場で難しいのは、アクセスレビューやライフサイクルワークフローを「作ること」だけではありません。むしろ難しいのは、作った後に安全な状態を保ち続けること です。
たとえば、次のような問題は多くのIAM運用で起こります。
- 障害対応のために条件付きアクセス ポリシーを一時的に無効化し、そのまま戻し忘れる
- 外部ユーザー向けアクセスパッケージの承認者や有効期限が、部門ごとにばらつく
- 管理者がポータルから直接変更したため、なぜ設定が変わったのか追跡しづらい
- 本番テナント、検証テナント、地域別テナントでガバナンス設定が少しずつズレる
- 監査前に現在設定を手作業でエクスポートし、証跡作成に時間がかかる
tenant-config APIs が重要なのは、こうした「人が画面で見て直す」運用を、APIで取得し、差分を検知し、必要に応じてコード管理する運用 に変えられるからです。
Microsoft の説明では、TCM APIs はテナント構成を宣言的な表現で管理し、現在の構成状態を取得する snapshot APIs と、望ましい状態からの逸脱を監視する monitoring APIs を提供します。対応ワークロードとしては Microsoft Defender、Microsoft Entra、Exchange Online、Intune、Purview、Teams が挙げられています。(Microsoft Learn)
つまり、これは Microsoft Entra ID Governance 単体の話に閉じません。Microsoft 365 全体のセキュリティ設定やガバナンス設定を、より再現性の高い運用モデルに寄せる動きとして見るべきです。
2026年4月時点の更新で何が変わったのか
Microsoft Entra の March 2026 更新では、Microsoft Entra ID Governance の新機能一覧に Tenant configuration management APIs が追加されています。併せて、Microsoft Graph の TCM API ドキュメントでは、構成スナップショット、構成モニター、構成ドリフト、監視結果といったリソースが整理されています。(TECHCOMMUNITY.MICROSOFT.COM)
実務上は、次の4つを押さえると理解しやすくなります。
| API領域 | できること | 実務での使いどころ |
|---|---|---|
| Snapshot APIs | 現在のテナント構成を抽出する | 既存設定の棚卸し、監査前の証跡取得、ベースライン作成 |
| Configuration Monitor | 望ましい構成をもとに定期監視する | 条件付きアクセスや外部ID設定の変更検知 |
| Configuration Drift | 望ましい状態との差分を取得する | 例外設定の戻し忘れ、無断変更、設定ミスの検知 |
| Monitoring Result | モニター実行結果や検知件数を確認する | 運用ダッシュボード、アラート、SRE的な運用指標化 |
configurationMonitor は定期的にバックグラウンドで実行されるモニターを作成するAPIで、Microsoft のドキュメントでは1テナントあたり最大30個、実行間隔は固定で6時間、全モニター合計で1日あたり最大800構成リソースを監視できると説明されています。(Microsoft Learn)
一方、snapshot は現在のテナント構成を非同期ジョブとして抽出する仕組みです。createSnapshot API は POST /admin/configurationManagement/configurationSnapshots/createSnapshot で呼び出し、対象リソース名を指定して構成スナップショットを作成します。(Microsoft Learn)
注意したいのは、TCM APIs は「何でも自動修復してくれる仕組み」ではないことです。Microsoft の説明では、monitoring APIs によって逸脱を検出し、管理者は関連する管理センターやその他の方法で drifts を解決するとされています。現時点では、少なくとも設計上は 検知、可視化、証跡化を中核に置くAPI と考えるのが安全です。(Microsoft Learn)
policy-as-code に効くポイント
policy-as-code というと、Terraform や Bicep のように「コードでリソースを作る」ことだけを想像しがちです。しかしIDガバナンスでは、より重要なのは 意図したポリシーが維持されているか です。
tenant-config APIs は、この維持管理の部分に効きます。
望ましい状態をベースラインとして扱える
Snapshot APIs で現在の設定を取得し、それを出発点としてベースライン化できます。たとえば、本番テナントの条件付きアクセス ポリシーや認証方法ポリシーを抽出し、不要な環境依存値を除いたうえで Git リポジトリに保存します。
これにより、「現時点の設定」が単なるポータル上の状態ではなく、レビュー可能な構成ファイルになります。
実務では、最初から理想状態をゼロから書くよりも、次の順序が現実的です。
| フェーズ | 作業 | 成果物 |
|---|---|---|
| 現状把握 | Snapshot API で現在設定を抽出 | 現在構成のJSON、対象リソース一覧 |
| 整理 | 命名規則、不要な例外、環境依存値を見直す | ベースライン候補 |
| レビュー | IAM、Security、Platform、監査担当で確認 | 承認済みベースライン |
| 監視 | configurationMonitor を作成 | ドリフト検知の仕組み |
| 運用 | 差分をチケット化し、修正後に再確認 | 証跡、変更履歴、改善ループ |
この流れを作ると、IDガバナンス設定が「担当者の記憶」ではなく「レビュー済みの設計」として残ります。
管理ポータルでの直接変更を検知しやすくなる
IAM engineers が最も困るのは、ポータル上で行われた小さな変更です。
たとえば、条件付きアクセス ポリシーの State が enabled から disabled に変わった場合、ログを追えば変更者は分かるかもしれません。しかし、毎回ログを検索して影響を評価する運用は長続きしません。
configurationDrift では、リソース種別、対象リソース、逸脱したプロパティ、現在値、望ましい値を取得できます。Microsoft の例では、条件付きアクセス ポリシーの State が Disabled になり、望ましい値が Enabled であるような差分が示されています。(Microsoft Learn)
この情報を Teams、Slack、ServiceNow、Azure DevOps、GitHub Issues などに連携すれば、ID設定の変更を通常のインシデント管理や変更管理の流れに乗せられます。
複数テナントで同じガバナンス設定を再現しやすい
グローバル企業では、本社テナント、地域別テナント、買収企業のテナント、検証テナントが並存することがあります。このとき問題になるのは、「どのテナントが標準設定から外れているのか」が分かりにくいことです。
tenant-config APIs を使うと、標準ベースラインを中心に据え、各テナントの構成差分を比較しやすくなります。
たとえば、以下のような運用が可能です。
- グローバル標準の条件付きアクセス設定をベースライン化する
- 地域ごとの法規制や業務要件で必要な差分だけを例外として管理する
- 各テナントの snapshot を定期取得し、標準との差分をレビューする
- 新規テナント作成時に、同じベースラインを初期設定チェックリストとして使う
これは platform teams にとって大きな意味があります。IDガバナンスを個別テナントの属人的な設定作業ではなく、再利用可能なプラットフォーム機能 として提供できるからです。
Microsoft Entra ID Governance との具体的な接続点
tenant-config APIs は、アクセスレビューやライフサイクルワークフローそのものを置き換えるものではありません。役割としては、Microsoft Entra ID Governance の設定や関連ポリシーを、より一貫して管理するための基盤です。
Microsoft Entra の対応リソースには、条件付きアクセス ポリシー、認証方法ポリシー、名前付き場所、外部IDポリシー、エンタイトルメント管理のアクセスパッケージ、アクセスパッケージ割り当てポリシー、カタログ、接続済み組織などが含まれています。特に entitlementManagementAccessPackage や entitlementManagementAccessPackageAssignmentPolicy は、Identity Governance Administrator ロールや Entitlement Management 関連の Microsoft Graph 権限が関係するリソースとして説明されています。(Microsoft Learn)
IAM engineers が最初に見るべき候補は、次の領域です。
| 監視対象 | なぜ重要か | 典型的なドリフト例 |
|---|---|---|
| 条件付きアクセス ポリシー | サインイン制御の中核になる | 緊急対応後にポリシーが無効化されたまま |
| Named locations | 信頼済みネットワーク判定に影響する | IP範囲の追加・削除がレビューされていない |
| 認証方法ポリシー | MFA、Temporary Access Pass、パスキー運用に影響する | 一部ユーザーに弱い認証方法が許可される |
| 外部ID・クロステナント設定 | B2Bコラボレーションの境界を決める | 外部テナントの信頼設定が広がりすぎる |
| アクセスパッケージ | 部門や外部ユーザーのアクセス付与を自動化する | 不要なリソースがパッケージに残る |
| アクセスパッケージ割り当てポリシー | 承認者、期限、レビュー条件を定義する | 有効期限やレビュー設定が緩くなる |
特にアクセスパッケージ割り当てポリシーは、承認、期限、レビュー、質問、requestor scope などを含むため、ガバナンス品質に直結します。ここが担当者ごとにばらつくと、「アクセス申請は自動化されているが、統制は弱い」という状態になります。
IAM engineers が取るべき実装アプローチ
tenant-config APIs を本番導入する際は、いきなり全テナント・全リソースを監視対象にしないほうが安全です。まずは、影響が大きく、ドリフトの意味を判断しやすい領域から始めます。
最初は「壊れると危険な設定」に絞る
最初の対象としては、条件付きアクセス、認証方法、外部ID、アクセスパッケージ割り当てポリシーが向いています。
理由はシンプルです。これらはアクセス制御に直結し、変更の影響が大きく、レビューの必要性を説明しやすいからです。
反対に、最初から大量の設定を対象にすると、次の問題が起きます。
- ドリフト通知が多すぎて誰も見なくなる
- どの差分が本当に危険なのか判断できない
- 正常な変更までノイズ扱いされる
- API制限や監視対象数の管理が複雑になる
configurationMonitor には、1テナントあたりのモニター数や1日あたりの監視リソース数に制限があります。まずは高リスク設定に絞り、運用品質を確認してから対象を広げるのが現実的です。(Microsoft Learn)
ベースラインは「完璧な理想」ではなく「合意済みの現実」から作る
policy-as-code 導入で失敗しやすいのは、最初から理想的なポリシーセットを作ろうとすることです。既存の大規模テナントでは、例外、暫定対応、歴史的経緯が必ずあります。
そのため、初期ベースラインは次の3分類で整理します。
| 分類 | 例 | 扱い方 |
|---|---|---|
| 標準設定 | 全ユーザーにMFAを要求する条件付きアクセス | そのままベースライン化 |
| 承認済み例外 | break glass account の除外 | 理由、期限、承認者を別途記録 |
| 是正対象 | 不要な除外グループ、古い外部組織設定 | ベースラインに入れず、改善チケット化 |
この整理をせずに snapshot をそのまま正とすると、過去の設定ミスまで「標準」として固定してしまいます。Snapshot APIs は強力ですが、取得した状態を無批判に正解扱いしないことが重要です。
ドリフト通知は「誰が判断するか」まで設計する
ドリフトを検知しても、通知先が曖昧だと運用は止まります。
たとえば、条件付きアクセス ポリシーの変更は Security team が見るのか、IAM team が見るのか。アクセスパッケージの承認者変更は業務部門のオーナーが判断するのか、Platform team が差し戻すのか。ここを決めずにAPIだけ導入すると、アラートが流れるだけになります。
実務では、以下のように分けると運用しやすくなります。
| ドリフト種別 | 一次対応 | 判断者 | 期限の目安 |
|---|---|---|---|
| 条件付きアクセス無効化 | Security Operations | IAM owner | 即日 |
| 認証方法の緩和 | IAM engineering | Security architect | 1〜3営業日 |
| アクセスパッケージの期限変更 | IAM operations | Resource owner | 3〜5営業日 |
| 外部組織設定の変更 | IAM / Legal / Business owner | External collaboration owner | 重要度に応じて判断 |
ポイントは、すべてをIAMチームだけで抱えないことです。tenant-config APIs は差分を可視化できますが、差分の妥当性は業務文脈とセットで判断する必要があります。
platform teams にとっての価値
platform teams にとって、tenant-config APIs の価値は「ID設定の自動化」だけではありません。より大きいのは、IDガバナンスを開発者や業務部門に安全に提供するための 共通基盤 を作れることです。
ガードレールをサービスとして提供できる
開発チームや業務部門は、アプリケーション公開、外部ユーザー招待、グループ管理、SaaS利用のスピードを求めます。一方、IAMやSecurityは最小権限、MFA、外部共有制御、定期レビューを求めます。
この衝突を解消するには、単に「禁止する」のではなく、標準パターンを用意する必要があります。
tenant-config APIs を使えば、次のようなガードレールを作りやすくなります。
- 新しいアクセスパッケージは、承認者・有効期限・レビュー設定を必須にする
- 条件付きアクセス ポリシーの無効化を検知したら、自動でインシデントを起票する
- 検証テナントと本番テナントの差分を定期的に比較する
- 外部コラボレーション設定の変更を業務オーナーにレビューさせる
- 監査用に月次 snapshot を安全な保管場所へ保存する
このように、platform teams は「各チームが自由に設定できるが、危険な逸脱は検知される」状態を作れます。
GitOps 的な変更管理に組み込みやすい
tenant-config APIs の導入後は、次のようなGitOpsに近い流れを作れます。
- 変更要求をIssueまたはチケットで受け付ける
- ベースラインJSONまたは設定テンプレートをPull Requestで変更する
- IAM、Security、対象業務オーナーがレビューする
- 承認後、Graph APIや既存の管理ツールで変更を適用する
- configurationMonitor でドリフトが解消されたことを確認する
- 変更履歴、承認、実際の状態を監査証跡として残す
この流れは、クラウドインフラのIaC運用に慣れた platform teams と相性が良いです。IDガバナンスだけが手作業で残ると、変更管理、レビュー、再現性の面でボトルネックになります。tenant-config APIs は、そのギャップを埋める部品になります。
導入時の注意点
tenant-config APIs は有用ですが、導入時に誤解しやすいポイントがあります。
| 注意点 | なぜ重要か | 対策 |
|---|---|---|
| snapshot は長期保管用バックアップではない | Microsoft のAPI制限では snapshot の保持期間や表示件数に制限がある | 必要な証跡は自社の保管先にエクスポートする |
| drift detection は自動修復ではない | 検知後の判断と修正フローが必要 | チケット化、承認、修正、再確認の流れを作る |
| 6時間間隔はリアルタイム検知ではない | 緊急変更の即時検知には向かない | 重要操作は監査ログやアラートと併用する |
| 権限設計が複雑になりやすい | Graph権限と各ワークロード側の権限が関係する | 専用サービスプリンシパルと最小権限で設計する |
| クラウド展開に差がある | 一部APIはGlobal serviceのみ対応として記載されている | Government、DoD、中国クラウドは事前確認する |
API制限として、snapshot は月間リソース抽出数、表示可能な snapshot job 数、保持期間などに制限があります。monitor についても、1テナントあたりのモニター数、固定実行間隔、1日あたりの監視リソース数が定義されています。(Microsoft Learn)
また、認証設計も重要です。TCM APIs を扱うには Microsoft Graph への認証に加え、monitor や snapshot job が各ワークロードのエンドポイントにアクセスするための認証設定が必要です。Microsoft のドキュメントでは、TCM service principal をテナントに追加し、必要な権限を付与する手順が説明されています。(Microsoft Learn)
特に本番環境では、Global Administrator のような広い権限で動かすのではなく、対象リソースごとの最小権限を確認し、サービスプリンシパル、条件付きアクセス、証明書またはシークレット管理、監査ログをセットで設計してください。
実務で使える運用モデル
tenant-config APIs を使ったIDガバナンス運用は、次のモデルにすると導入しやすくなります。
日次運用
日次では、configurationDrifts と monitoring results を確認します。ドリフトがある場合は、影響度で分類します。
- 高: 条件付きアクセス無効化、認証方法の緩和、外部アクセス範囲の拡大
- 中: アクセスパッケージの承認者変更、有効期限変更、レビュー設定変更
- 低: 命名、説明文、表示順などセキュリティ影響が限定的な変更
高リスクのドリフトは、通常の変更管理ではなくセキュリティインシデント候補として扱います。特に条件付きアクセスや外部ID設定のドリフトは、攻撃面の拡大につながる可能性があります。
週次運用
週次では、ドリフト傾向を見ます。
単発の差分だけでなく、「どの設定が頻繁に変わるのか」「どの部門で例外が多いのか」「承認された変更と未承認変更の比率はどうか」を確認します。
この分析により、単なる検知運用から改善運用に進めます。
たとえば、あるアクセスパッケージで毎週のように有効期限延長が発生しているなら、業務プロセスに合っていない可能性があります。承認者が頻繁に手動変更されるなら、リソースオーナー情報の管理が古いのかもしれません。
月次・四半期運用
月次または四半期では、snapshot を使って監査証跡を整備します。
重要なのは、snapshot を取得して終わりにしないことです。次の情報をセットで残すと、監査対応に強くなります。
| 証跡 | 内容 |
|---|---|
| 構成snapshot | 対象日時の設定状態 |
| ベースライン | 承認済みの望ましい状態 |
| 差分レポート | 何が標準から外れていたか |
| 例外一覧 | 承認済み例外、期限、オーナー |
| 是正記録 | 修正日時、担当者、確認結果 |
これにより、「定期的にレビューしています」ではなく、「どの設定を、いつ、誰が、どの基準で確認し、何を修正したか」まで示せます。
成功させるための設計判断
tenant-config APIs の価値を最大化するには、API導入前にいくつかの判断基準を決めておく必要があります。
何を正とするかを決める
policy-as-code では、最終的に「何が正しい状態なのか」を決める必要があります。
候補は大きく3つあります。
| 正とするもの | 向いているケース | 注意点 |
|---|---|---|
| 本番テナントの現状 | まず棚卸ししたい初期段階 | 既存の設定ミスも含まれる |
| Git上のベースライン | 成熟した運用、複数テナント管理 | レビューと適用プロセスが必要 |
| セキュリティ標準テンプレート | 新規テナント、標準化プロジェクト | 現場例外を吸収する設計が必要 |
おすすめは、初期段階では本番テナントの現状を取得し、レビューで整理したうえでGit上のベースラインへ移行する方法です。
例外を禁止するのではなく期限付きにする
IDガバナンスでは、例外を完全になくすことは現実的ではありません。重要なのは、例外を「見える状態」にし、期限と責任者を持たせることです。
たとえば、break glass account の条件付きアクセス除外は必要になることがあります。しかし、除外理由、対象アカウント、保管方法、レビュー頻度が曖昧だとリスクになります。
tenant-config APIs でドリフトを検知する場合も、すべての差分を即時修正するのではなく、次のように扱うと現場に受け入れられやすくなります。
- 承認済み例外は期限付きで許可する
- 期限切れの例外は自動的にレビュー対象にする
- 未承認の差分はチケット化する
- 高リスク差分は即時エスカレーションする
自動修復は段階的に導入する
ドリフトを検知したからといって、すぐに自動修復するのは危険です。特に条件付きアクセスや外部ID設定では、業務停止につながる可能性があります。
段階としては、次の順序が安全です。
- 検知のみ
- 検知と通知
- 検知とチケット起票
- 承認後の半自動修正
- 低リスク項目のみ自動修復
自動修復を入れる場合でも、最初は説明文、タグ、命名規則など低リスク項目から始めるのが現実的です。アクセス制御に直結する設定は、承認フローを挟むべきです。
すぐに始めるためのチェックリスト
tenant-config APIs を検証するなら、次の順序で進めると失敗しにくくなります。
| ステップ | 実施内容 | 完了条件 |
|---|---|---|
| 対象決定 | 条件付きアクセス、認証方法、アクセスパッケージなどから選ぶ | 最初の対象が5〜20リソース程度に絞れている |
| 権限設計 | TCM service principal と必要なGraph権限を確認する | 最小権限の設計メモがある |
| snapshot取得 | 現在構成を抽出する | ベースライン候補が保存されている |
| レビュー | Security、IAM、業務オーナーで確認する | 標準、例外、是正対象が分類されている |
| monitor作成 | 承認済みベースラインで監視する | ドリフト検知が動作している |
| 通知設計 | Teams、チケット、SIEMなどに連携する | 担当者とSLAが明確になっている |
| 定期見直し | 月次または四半期でベースラインを更新する | 証跡と変更履歴が残っている |
まずは「重要な条件付きアクセス ポリシーが無効化されたら検知する」など、小さくても価値が明確なユースケースから始めるのがおすすめです。成功体験を作ってから、アクセスパッケージ、外部ID、認証方法、IntuneやPurviewなどへ広げると、関係者の合意を得やすくなります。
tenant-config APIs は再現可能なIDガバナンスの土台になる
Microsoft Entra ID Governance における tenant-config APIs の価値は、単に管理作業をAPI化することではありません。より重要なのは、IDガバナンス設定を 見える化し、レビュー可能にし、差分を検知し、複数テナントで再現できる状態にすること です。
IAM engineers にとっては、条件付きアクセス、外部ID、エンタイトルメント管理の設定を継続的に守る仕組みになります。platform teams にとっては、IDガバナンスを標準化されたプラットフォーム機能として提供するための部品になります。
次に取るべき行動は明確です。まずは高リスクな設定を1つ選び、snapshot で現状を取得し、ベースラインをレビューし、configurationMonitor でドリフト検知を始めてください。tenant-config APIs は、手作業に依存したIDガバナンスから、policy-as-code と repeatable governance へ移行するための現実的な第一歩になります。
コメント