「誰が設定を変えた?」の犯人探しをやめる。監査ログ(Audit Log)の正しい使い方

月曜日の朝、ふとTeamsの外部共有設定を確認すると、先週と違う値になっている。
「誰がこれ変えた?」と管理者グループに投げると、誰も心当たりがない。
時間が過ぎるほど不安は増し、犯人探しのような雰囲気が漂い始める——そんな経験はないでしょうか。

実は、Microsoft 365にはこうした状況を冷静に解決するための機能が標準で備わっています。
それが監査ログ(Audit Log)です。

ただし、この機能は「犯人を特定して責める」ためのものではありません。
「何がいつ・誰によって変更されたかを把握し、再発防止策を設計する」ためのものです。
本記事では、監査ログの正しい思想と具体的な使い方を紹介します。

目次

監査ログとは何か?何が記録されているか?

Microsoft 365の統合監査ログは、
テナント内で発生したユーザーおよび管理者の操作を横断的に記録するログです。
各サービスのアクティビティを Microsoft Purview ポータルから一元的に検索できます。

また、Microsoft Entra ID の監査ログには、ディレクトリに対するさまざまな変更操作が記録されます。

たとえば:

  • ユーザーの作成・削除・属性変更
  • グループの作成・メンバー変更
  • ロールの割り当て
  • 条件付きアクセスポリシーの編集
  • アプリケーションやエンタープライズアプリの設定変更
  • ライセンスの割り当て変更

※ ただし、すべての操作が必ず記録されるわけではなく、記録対象や保持期間はライセンスや設定に依存します。

主な記録対象サービス

統合監査ログには、次のようなサービスの操作が記録されます。

  • Exchange Online
    メールボックス設定の変更、転送設定の追加、管理者操作など
  • SharePoint Online / OneDrive for Business
    ファイルの閲覧・編集・削除、共有設定の変更など
  • Microsoft Teams
    チームの作成・削除、メンバーの追加・削除、ポリシー変更など
  • Microsoft Entra ID
    ユーザー・グループ・ロールの変更、条件付きアクセスポリシーの更新など
  • Microsoft 365 管理センター
    各種管理設定の変更

ログレコードに含まれる主な情報

各監査ログレコードには、一般的に以下の情報が含まれます。

  • 誰が(ユーザー名、アプリID、IPアドレス など)
  • いつ(日時)
  • 何をしたか(操作名/アクティビティ)
  • 何に対して行ったか(対象リソース)
  • 変更内容の詳細

変更系の操作では、変更前後の値(oldValue / newValue)が確認できる場合があります。

ただし、操作の種類によっては前後比較が表示されないケースもあります。

まず確認:監査ログは有効になっていますか?

監査ログを使う前に、有効化されているかを確認する必要があります。

Microsoft 365の監査ログは、現在、ほとんどのライセンス(Business Basic / Standard / Premium 等)において既定(デフォルト)で有効になっています。
そのため、通常は導入後すぐに利用可能な状態です。

ただし、念のため設定が「オン」になっているか、以下の手順で確認しておくことをお勧めします。

有効化の手順は以下のとおりです。

  1. Microsoft Purview コンプライアンスポータルcompliance.microsoft.com)にアクセス
  2. 左メニューから「監査」をクリック
  3. 監査が有効でない場合は
    「ユーザーと管理者のアクティビティの記録を開始する」ボタンが表示されるのでクリック

【注意】 手動で有効化した直後は、ログの収集が開始されるまでに時間を要する場合があります。
トラブルが起きてから有効化しても「過去の操作」は遡れないため、事前の確認が重要です。

参考:監査ログの検索



「設定が変わっていた」を追跡する:実践的な手順

ステップ1:Microsoft Purview ポータルから監査ログを検索する

  1. compliance.microsoft.com にサインイン(適切なロールが必要)
  2. 左メニュー「監査」をクリック
  3. 検索条件を設定する
項目設定例
日付範囲「設定が変わっていた」と気づいた日を含む前後数日
アクティビティ例:SharePoint 管理者変更、条件付きアクセスポリシー更新 など(実際の操作名で検索)
ユーザー管理者アカウント全員(空欄にすると全員対象)
ファイル・フォルダー問題の対象リソース(任意)
  1. 検索」をクリック。処理に数分かかる場合があります。

ステップ2:結果を読み解く

検索結果の各行には「日時」「ユーザー」「アクティビティ」「対象」が表示されます。気になるレコードをクリックすると詳細が展開されます。ここで特に見るべきポイントは以下です。

  • Actor(実行者):操作したアカウント名
  • Operation(操作):実行したアクション
  • ModifiedProperties(変更されたプロパティ):変更前の値(OldValue)と変更後の値(NewValue)

タイムゾーンに注意
監査ログの時刻は 既定では UTC(協定世界時) で表示されます。
日本時間(JST)に変換する場合は +9時間 してください。
CSVエクスポート後にExcel / Power Queryで一括変換するのが便利です。

ステップ3:CSVでエクスポートして記録を残す

結果画面の「エクスポート」ボタンからCSVファイルをダウンロードできます。
1回の検索で最大50,000件のエントリをダウンロード可能です。
このCSVはインシデント記録や再発防止の文書として保存しておくことを推奨します。

参考:監査ログ アクティビティ



Microsoft Entra ID の監査ログも忘れずに

Microsoft 365の設定変更のうち、
ユーザー・グループ・ロール・条件付きアクセスなどのディレクトリ関連の変更は、Microsoft Entra 管理センターからも確認できます。

アクセス方法

  1. https://entra.microsoft.com にアクセス
  2. 「ID」セクション内の「監査ログ」(監視カテゴリ内)を選択

※ UIは更新されることがあるため、「監査ログ」で検索する方法も有効です。

参考:Microsoft Entra 監査ログとは

監査ログの活用例

日本マイクロソフトの Azure & Identity サポートチームが運営する
Japan Azure Identity Support Blog では、Entra ID 監査ログの活用例が紹介されています。

特に「監査ログを使用した特権ロール割り当ての管理」という記事では、

  • 誰が
  • いつ
  • どのロールを
  • 誰に割り当てたか

といった変更履歴を監査ログで確認できることが解説されています。

これにより、

  • 不要なロール付与の発見
  • 過剰な特権の是正
  • ロール変更履歴の追跡

といった棚卸し作業の補助として活用できます。

※ 現在のロール割り当て状況の確認は「ロールと管理者」画面で行います。
※ より高度な特権管理には PIM(Privileged Identity Management)の活用が推奨されます。

サインインログとの違い

Entra ID では、監査ログとは別に

  • サインインログ(認証履歴)
  • 監査ログ(設定変更履歴)

を確認できます。

  • サインインログ → 「誰がログインしたか」
  • 監査ログ → 「誰が何を変更したか」

という役割の違いがあります。

参考:Azure AD サインイン ログ取得方法まとめ



「犯人探し」から「再発防止設計」へ:ログ活用の心得

監査ログを見て「〇〇さんが変えていた!」と分かったとして、それで終わりにしてはいけません。
大切なのはその先——「なぜその変更が起きたのか」「どうすれば意図しない変更を防げるか」を考えることです。

ログで分かること/分からないこと

ログで分かること

  • 誰が
  • いつ
  • 何を
  • どのリソースに対して変更したか

ログだけでは分からないこと

  • 変更の意図
  • 業務上の必要性
  • 承認を得ていたかどうか

ログは「証跡」であって、「背景」までは教えてくれません。

再発防止のための具体策

ログをきっかけに、以下のような再発防止策を検討しましょう。

1. 管理者ロールの見直し(最小権限の原則)
「全員にグローバル管理者を付与している」という運用が最も危険です。
ユーザーに本当にロールが必要かどうかを判断するには、ユーザーのアクティビティを監視し、業務を遂行できる最小権限のロールを見つけることが重要です。
監査ログで実際に誰が何をしているかを確認し、ロールを適切に絞り込みましょう。

2. 変更管理フローの導入
「誰でも・いつでも設定を変えられる」状態をやめ、変更申請→承認→実施というプロセスを設ける。
このプロセスがあれば、変更の意図と実施者が記録に残ります。

3. 定期的な監査ログレビューの習慣化
月に1回、管理者全員で重要設定の変更ログを確認するルーティンを作る。
問題が起きてからではなく、プロアクティブ(事前)にチェックする文化が、長期的に組織を守ります。



まとめ:監査ログは「ガバナンスの基盤」

監査ログは、問題が起きてから使う「事後対応ツール」ではありません。

定期的に確認することで、意図しない変更の早期発見・ロール運用の最適化・変更管理プロセスの改善など、組織全体のITガバナンスを継続的に高めるための基盤となります。

「誰かが変えたせいで問題が起きた」という属人的な事象を減らすためには、変更を透明化し、チーム全体で管理の責任を共有する体制が必要です。

免責事項:Microsoft 365の機能や仕様は変更される可能性がありますので、実施前には最新の公式ドキュメントをご確認ください。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

目次