2026年4月16日時点で Microsoft Entra ID audit logs を確認している Identity 管理者や SOC チームが押さえるべき更新は、Authentication Methods Policy Update / Reset の監査ログが読みやすくなるという点です。結論から言うと、認証方法ポリシーの一部だけを変更した場合に、監査ログ上で「変更されたプロパティ」と「変更前後の値」を追いやすくなります。これにより、MFA、パスキー、登録キャンペーン、認証方法の許可設定などで「急に挙動が変わった」ときの原因調査時間を短縮しやすくなります。
Microsoft は 2026年3月の Microsoft Entra 更新まとめで、この改善を Microsoft Entra ID の新リリースとして取り上げています。Microsoft Learn では、2026年4月から Authentication Methods Policy Update と Authentication Methods Policy Reset の監査ログについて、従来のようにポリシー全体のペイロードを old / new value に出すのではなく、変更されたプロパティとその変更前後の値を表示するよう更新されたと説明されています。なお、アクティビティ名、トリガーされるイベント、ポリシー動作そのものは変更されません。(TECHCOMMUNITY.MICROSOFT.COM)
Microsoft Entra ID audit logs の更新で何が変わるのか
今回のポイントは、監査ログに記録される情報の意味が変わるのではなく、表示・構造が読み取りやすくなることです。Identity チームにとって重要なのは、「誰が」「いつ」「どの認証方法ポリシーを」「どう変えたのか」を短時間で判断できるかどうかです。
| 項目 | 以前の見え方 | 更新後の見え方 |
|---|---|---|
| 対象ログ | Authentication Methods Policy Update / Reset | 同左 |
| Modified properties | 小さな変更でも認証方法ポリシー全体のペイロードが表示されることがあった | 変更されたプロパティと old / new value が中心になる |
| 調査時の負荷 | JSON 全体を比較し、実際の差分を探す必要がある | 差分箇所を直接確認しやすい |
| アクティビティ名 | 変更なし | 変更なし |
| ポリシーの適用動作 | 変更なし | 変更なし |
| 注意点 | – | Registration Campaigns や System-preferred MFA のようなポリシー全体に関わる更新では、引き続きフルペイロードが含まれる場合がある |
この改善は、監査ログの可読性を上げるための更新です。したがって、「この更新が原因で MFA の判定が変わる」「認証方法ポリシーの適用範囲が変わる」といった理解は誤りです。Microsoft も、今回の更新はフォーマット上の変更であり、ポリシー動作は変更しないと説明しています。(Microsoft Learn)
なぜ監査ログの可読性がトラブルシューティング時間を短縮するのか
Identity 管理者が Microsoft Entra ID audit logs を見る場面は、多くの場合「何かが起きた後」です。
たとえば、次のような問い合わせです。
- 一部ユーザーだけ MFA 登録を求められるようになった
- パスキー登録の対象者が想定と違う
- Microsoft Authenticator の挙動が変わったように見える
- Temporary Access Pass を使えるはずのユーザーが使えない
- SOC のアラート後、認証方法ポリシーに変更があったか確認したい
このとき、監査ログにポリシー全体の JSON が大量に表示されると、調査者は「本当に変わった箇所」を探すために old value と new value を目視またはツールで比較しなければなりません。変更が 1 つだけでも、巨大なペイロードの中に埋もれると、原因特定に時間がかかります。
更新後は、変更されたプロパティが前面に出るため、調査の初動で次の判断がしやすくなります。
| 調査で知りたいこと | 監査ログで見るポイント | 判断例 |
|---|---|---|
| 誰が変更したか | initiatedBy | 管理者操作か、自動化アプリか、サービスプリンシパルか |
| いつ変更したか | activityDateTime / TimeGenerated | 問い合わせ発生時刻の前後か |
| 何の操作か | activityDisplayName / OperationName | Update か Reset か |
| 何が変わったか | modifiedProperties | 対象グループ、認証方法、登録キャンペーン設定など |
| 変更の影響範囲 | targetResources / oldValue / newValue | 全社影響か、一部グループ影響か |
Microsoft Entra の監査ログでは、発生日時、サービス、アクティビティ名、状態に加え、詳細画面で相関 ID、アクター、ターゲットリソース、変更されたプロパティの古い値と新しい値を確認できます。つまり、監査ログは「設定変更の証跡」であり、サインインログだけでは分からない変更原因を追うための入口になります。(Microsoft Learn)
Authentication Methods Policy はどの運用に影響するのか
Authentication Methods Policy は、Microsoft Entra ID で利用できる認証方法を管理する中心的なポリシーです。パスワードレス認証を含む認証方法の管理に使われ、管理者はユーザー全体または特定グループに対して認証方法を有効化できます。Microsoft Learn では、認証方法ポリシーを管理するには少なくとも Authentication Policy Administrator として Microsoft Entra 管理センターにサインインし、Entra ID > Authentication methods > Policies を参照すると説明されています。(Microsoft Learn)
実務では、Authentication Methods Policy の変更はユーザー体験に直結します。たとえば、MFA の登録方法、パスキーの利用可否、Authenticator の利用条件、対象グループの変更などは、ヘルプデスク問い合わせや SOC の調査対象になりやすい領域です。
特に注意したいのは、認証方法ポリシーの変更が「障害」のように見えるケースです。設定変更としては正しくても、影響を受けるユーザーから見ると「昨日まで使えた方法が使えない」「突然登録画面が出た」と見えます。このギャップを埋めるのが監査ログです。
調査時はサインインログだけでなく監査ログを見る
認証まわりのトラブルでは、まずサインインログを確認しがちです。しかし、サインインログは「そのユーザーのサインインがどう評価されたか」を見るものです。一方、Microsoft Entra ID audit logs は「設定やディレクトリにどのような変更が行われたか」を見るものです。
| ログ種別 | 主な用途 | 代表的な確認ポイント |
|---|---|---|
| 監査ログ | 設定変更、管理操作、ポリシー変更の追跡 | 誰が、いつ、何を変更したか |
| サインインログ | サインイン結果、条件付きアクセス、MFA 要求の確認 | ユーザー、アプリ、結果、リスク、適用ポリシー |
| Authentication methods activity | 認証方法の登録・利用状況の把握 | どの方法が登録・使用されているか |
| Log Analytics / SIEM | 長期保存、横断検索、アラート | KQL、相関分析、検知ルール |
「ユーザーが急に MFA を求められるようになった」という問い合わせでは、サインインログだけを見ると「MFA が要求された」ことは分かっても、「なぜその設定になったのか」は分からない場合があります。監査ログで Authentication Methods Policy Update / Reset を追うことで、ポリシー変更とユーザー影響をつなげやすくなります。
Identity チーム向けの調査手順
Microsoft Entra ID audit logs の可読性が改善されても、調査の流れが曖昧だと時間短縮にはつながりません。運用では、次の順番で確認すると原因にたどり着きやすくなります。
| 手順 | やること | 判断基準 |
|---|---|---|
| 1 | 問い合わせ内容を具体化する | 影響ユーザー、認証方法、発生時刻、対象アプリを整理する |
| 2 | 監査ログの期間を絞る | 変更発生が疑われる前後 24〜72 時間から見る |
| 3 | Activity / OperationName を絞る | Authentication Methods Policy Update / Reset を中心に確認する |
| 4 | initiatedBy を確認する | 人の操作か、自動化か、サービスプリンシパルかを分ける |
| 5 | modifiedProperties を見る | oldValue / newValue で実際の差分を確認する |
| 6 | サインインログと突き合わせる | ポリシー変更後に該当ユーザーの挙動が変わったかを見る |
| 7 | 変更管理記録と照合する | 承認済み変更か、想定外変更かを判断する |
| 8 | 必要に応じて是正する | 設定戻し、対象グループ修正、周知、検知ルール更新を行う |
Microsoft Entra 管理センターで確認する場合は、Entra ID > Monitoring & health > Audit logs から期間やアクティビティを絞り込みます。Microsoft Entra activity logs を見るための最小権限として Reports Reader が示されており、ログスキーマでは activityDisplayName、initiatedBy、targetResources などの重要フィールドが定義されています。(Microsoft Learn)
Log Analytics で確認する場合の KQL 例
Log Analytics に Microsoft Entra の監査ログを送っている環境では、KQL で Authentication Methods Policy 関連の変更を横断的に確認できます。Microsoft Learn では、Microsoft Entra のアクティビティログを Log Analytics ワークスペースに送信している場合、AuditLogs テーブルに対してクエリを実行できると説明されています。(Microsoft Learn)
以下は、直近 14 日間の Authentication Methods Policy 関連操作を探す例です。OperationName の表記はテナントやログ出力の実態に合わせて調整してください。
AuditLogs
| where TimeGenerated >= ago(14d)
| where OperationName has "Authentication Methods Policy"
| project
TimeGenerated,
OperationName,
Result,
InitiatedBy,
TargetResources,
CorrelationId
| order by TimeGenerated desc変更プロパティを確認したい場合は、TargetResources の中にある modified properties を展開して確認します。実際のスキーマは環境や出力先によって見え方が異なる場合があるため、まず 1 件を表示して構造を確認してから本番クエリに組み込むのが安全です。
AuditLogs
| where TimeGenerated >= ago(14d)
| where OperationName has "Authentication Methods Policy"
| mv-expand TargetResources
| extend TargetName = tostring(TargetResources.displayName)
| extend ModifiedProperties = TargetResources.modifiedProperties
| project
TimeGenerated,
OperationName,
Result,
TargetName,
InitiatedBy,
ModifiedProperties,
CorrelationId
| order by TimeGenerated descSOC の運用では、このクエリをそのままアラートにするのではなく、まずはダッシュボードやハンティングクエリとして使い、通常変更の頻度や管理者操作のパターンを把握するのがおすすめです。通常変更のベースラインがないまま検知ルール化すると、定期メンテナンスや自動化処理でノイズが増えます。
自動処理・SIEM 連携で見直すべきポイント
今回の更新で最も注意すべきなのは、人間が読む画面よりも、既存の自動処理です。以前のログ形式を前提に、modified properties 内のフルペイロードをパースしている場合、更新後に期待したフィールドを拾えなくなる可能性があります。
見直すべき対象は次の通りです。
| 対象 | 見直すポイント | 対応例 |
|---|---|---|
| SIEM の検知ルール | full payload 内の特定文字列に依存していないか | OperationName と changed property を軸にする |
| カスタムパーサー | oldValue / newValue が常にポリシー全体だと仮定していないか | changed property 単位の処理に変更する |
| 監査レポート | 差分抽出ロジックが二重比較になっていないか | 表示済みの差分を活用する |
| SOAR / Logic Apps | フィールド欠落時に失敗しないか | null 処理と例外処理を追加する |
| 変更管理連携 | チケット番号や管理者名だけで判断していないか | CorrelationId と変更プロパティも記録する |
「ログが読みやすくなる」更新は、人間には歓迎されますが、機械処理には影響が出ることがあります。特に、アラートや監査レポートが「ペイロード内に特定設定が含まれるか」を見ている場合は、実際のテナントで変更後のサンプルログを取得し、パーサーを検証しておくべきです。
監査ログの保存期間も合わせて確認する
トラブルシューティング時間を短縮するには、ログが読みやすいだけでなく、必要な期間のログが残っていることも重要です。Microsoft Entra ID のデータ保持はレポート種類とライセンスによって異なり、Microsoft Learn では Activity reports の Audit logs について、Microsoft Entra ID Free は 7 日、Microsoft Entra ID P1 / P2 は 30 日と説明されています。また、既定の保持期間を超えて保持したい場合は Azure Storage へのルーティングなどを利用できます。(Microsoft Learn)
Microsoft Entra の診断設定では、アクティビティログを Log Analytics workspace、Storage account、Event Hubs、パートナーソリューションなどにルーティングできます。長期保存、SIEM 連携、横断検索が必要な組織では、監査ログをポータル上で見るだけでなく、診断設定による外部保存を設計しておくことが現実的です。(Microsoft Learn)
特にグローバル組織では、時差、地域ごとの管理者、外部委託チーム、複数テナント運用が絡みます。問い合わせが数週間後に届くこともあるため、30 日以内に原因調査が完結する前提は危険です。監査・セキュリティ要件に応じて、保持期間と検索手段を先に決めておきましょう。
よくある失敗と回避策
ログ形式の変更をポリシー変更と誤解する
今回の更新は、監査ログの表示・構造を分かりやすくするものです。ポリシーの評価ロジックやユーザーへの適用条件が変わるわけではありません。問い合わせが増えた場合は、まず実際の Authentication Methods Policy の変更有無、対象グループ、サインインログを確認しましょう。
サインインログだけで原因を判断する
サインインログは「結果」を見るには便利ですが、「誰が設定を変えたか」は監査ログで確認する必要があります。MFA や認証方法の挙動変化では、サインインログと監査ログをセットで見る運用にしてください。
modifiedProperties の形が常に同じだと仮定する
今回の更新後も、ポリシー全体に関わる更新ではフルペイロードが含まれる場合があります。つまり、modifiedProperties は「必ず小さい差分だけになる」と決め打ちしないほうが安全です。自動処理では、単一プロパティの差分とフルペイロードの両方を扱えるようにしておきましょう。
変更管理チケットとログの突き合わせを省略する
監査ログで変更者が分かっても、それが承認済みの変更かどうかは別問題です。Identity チームと SOC チームの間で、認証方法ポリシーを変更した場合のチケット番号、変更理由、想定影響範囲を記録するルールを作ると、後日の調査が大幅に楽になります。
Identity admins と SOC が今すぐやるべきこと
今回の更新を運用品質の改善につなげるには、単に「ログが読みやすくなった」で終わらせないことが大切です。次の作業を優先して実施しましょう。
| 優先度 | 実施内容 | 目的 |
|---|---|---|
| 高 | Authentication Methods Policy Update / Reset の最新ログを確認する | 自テナントでの実際の出力形式を把握する |
| 高 | SIEM、KQL、カスタムパーサーを点検する | full payload 前提の処理を見つける |
| 高 | 認証方法ポリシー変更時の調査手順を Runbook 化する | 担当者ごとの判断差を減らす |
| 中 | 変更管理チケットに old / new value の要点を残す | 後日調査を短縮する |
| 中 | 監査ログの保持期間と外部保存を確認する | 期限切れで追跡不能になるリスクを減らす |
| 中 | SOC 向けの検知条件を見直す | ノイズを減らし、重要な変更を拾う |
最初にやるべきことは、直近の Authentication Methods Policy 関連ログを 1〜2 件確認し、自社の SIEM や Log Analytics でどのように見えているかを把握することです。そのうえで、変更プロパティを起点に調査できる KQL、アラート、運用手順に更新しましょう。
まとめ：読みやすい監査ログは Identity 運用の MTTR を下げる
Microsoft Entra ID audit logs の Authentication Methods Policy Update / Reset が読みやすくなることで、Identity 管理者や SOC チームは、認証方法ポリシーの変更点を以前より素早く確認しやすくなります。特に、MFA、パスキー、Authenticator、登録キャンペーンなど、ユーザー体験に直結する設定では、変更差分をすぐ把握できることがトラブルシューティング時間の短縮につながります。
ただし、今回の更新はポリシー動作の変更ではありません。重要なのは、可読性の改善をきっかけに、監査ログの検索手順、Log Analytics の KQL、SIEM パーサー、変更管理プロセスを見直すことです。まずは自テナントの最新ログを確認し、Authentication Methods Policy の変更を「誰でも同じ手順で追える」状態に整えてください。
コメント