Windows Server 監査ログのイベントID 5145が同一操作で大量発生する原因と対処法

Windows Server の監査ログを本番で有効にすると、「イベント ID 5145（詳細なファイル共有の監査）」が同じ共有名・同じアクセスマスクで大量に並び、ログがノイズだらけに見えることがあります。これは設定ミスというより SMB の設計思想に起因する“仕様”であり、振る舞いを理解したうえで監査ポリシーとログ収集のチューニングを行うことが重要です。本記事では、なぜ 5145 が同一操作でも数十件出るのか、その原因と実務的な抑え方、さらに Microsoft Q&A で質問するときのカテゴリやタグの選び方まで、現場目線で詳しく解説します。

Windows Server 監査ログ「イベント ID 5145」が大量発生する現象とは

典型的な相談内容は次のようなものです。

ユーザーが \\server\share1 を開いただけなのに、イベント ID 5145 が同じ共有名・同じアクセスマスクで数十件も続けて記録される
違っているのは「送信元ポート（ソースポート）」くらいで、他の項目はほぼ同じ
監査ログを証跡として使いたいのに、ノイズが多すぎて追いきれない

結論から言うと、これは SMB クライアント／サーバーの並列・多重処理の結果であり、基本的には異常ではありません。監査設計を「ユーザーの操作 1 回につきイベント 1 件」というイメージで考えてしまうと、ここでつまずきます。

まずは Windows と SMB がどのように共有アクセスを処理しているのか、その前提から整理していきます。

なぜ同じ 5145 が大量に出るのか ― SMB の並列処理が前提

SMB クライアントは 1 操作を複数の要求に分解する

最近の Windows クライアントは、エクスプローラーで共有フォルダーを 1 回開くという単純な操作でも、内部的には多くの SMB 要求をサーバーに送ります。例えば次のような処理が並列に発生します。

フォルダー一覧の取得（列挙）
各ファイルの属性情報の取得（サイズ、更新日時など）
サムネイル表示用の一部読み取り
プレビュー用の読み取り
バックグラウンドのアプリケーションによるファイル参照（ウイルススキャン、インデックス作成など）

これらの要求は、1 本の TCP 接続だけでなく、複数の TCP セッションにまたがって処理されることがあります。その結果、サーバー側では送信元ポートが異なる、よく似た SMB 要求が多数到来することになります。

サーバー側は要求ごとにアクセスチェックを行う

Windows Server のファイルサーバーは、到着した各 SMB 要求ごとにアクセスチェックを行います。その結果を監査ログとして出力するのが、イベント ID 5145（Audit Detailed File Share）です。

重要なのは、サーバー側から見ると「ユーザーの操作が何回か」ではなく、「SMB の要求が何回か」でしか判断しない、という点です。そのため次のようなズレが生じます。

視点	操作の捉え方	5145 の件数
ユーザー	エクスプローラーで共有を 1 回開いた	「1 回の操作」
SMB サーバー	フォルダー列挙、属性取得、サムネイル読み込み…など多数の要求	「要求の数だけ 5145 が出る」

つまり、「同じ共有名・同じアクセスマスクの 5145 が大量に並ぶ」のは、ユーザー操作が複数の SMB 要求に分解されている結果であり、異常動作ではないと言えます。

SMB マルチチャネルや NIC/RSS による多重接続

さらに Windows Server 2012 以降では、SMB マルチチャネルが既定で有効になっています。これは帯域と冗長性を高めるために、クライアントとサーバーの間で複数の TCP 接続を並行して張る仕組みです。

複数 NIC がある場合：各 NIC ごとに SMB 接続が張られうる
RSS（Receive Side Scaling）有効な 10GbE NIC など：1 NIC 内でも複数のキューに分散して複数接続を張る

この結果、同じクライアント・同じユーザー・同じ共有に対しても、送信元ポートやローカルアドレスが異なる複数の TCP セッションが存在し、それぞれで同様の SMB 要求が飛び交います。当然、そのぶん 5145 のイベント件数も増加します。

同一アクセスマスクが繰り返し出る理由

イベント ID 5145 の「Access Mask」は、その SMB 要求で求められたアクセス権の種類を示します。フォルダー一覧や属性取得などでは、同じようなアクセス権（読み取り、フォルダー列挙など）が繰り返し要求されます。

そのためログ上では、

同じ ShareName
同じ Relative Target Name
同じ Access Mask（たとえば 0x120089）

といった行が、送信元ポートだけ変えながら大量に並ぶことになります。これは「同じ種類の要求が複数のセッション／スレッドで並行処理された結果」であり、仕様どおりの動作です。

イベント ID 5145 と他のイベント ID の役割の違い

監査ログの設計を考えるうえで、5145 を「どのレイヤーのログなのか」という視点で理解しておくと整理しやすくなります。

イベント ID	概要	主な用途
5140	ファイル共有へのアクセス（セッション確立）	どの共有に誰がアクセスしたかの粗い把握
5145	詳細なファイル共有の監査（SMB 要求単位）	共有レベルでのアクセス要求内容の詳細確認
4663	オブジェクトへのアクセス（ファイル／フォルダー）	特定ファイルの読み取り／書き込み／削除の記録

5145 はあくまで「SMB 要求」単位のログであり、ユーザー操作やファイル単位の操作とは 1 対 1 で対応しません。一方、4663 は SACL の設定次第でファイル／フォルダー単位の実操作をかなり正確に把握できます。

この性質を踏まえると、日常的な監査運用では、

5140：全体のアクセス状況を把握するための「入口ログ」
5145：トラブルシュートや詳細調査のときに絞って使う「詳細ログ」
4663：重要フォルダーに対してきちんと設計したうえで常時収集する「本命ログ」

と使い分けるのが現実的です。

実務でのノイズ低減テクニック ― 監査ポリシー編

「詳細なファイル共有の監査（5145）」の成功ログを常時オンにしない

最初に見直したいのは、監査ポリシーの粒度です。5145 は非常に「おしゃべり」なイベントであり、成功ログを常時オンにすると、すぐに膨大な件数になります。

ローカルセキュリティポリシー（またはグループポリシー）の「詳細監査ポリシー構成」で、次のような設定を検討します。

オブジェクトアクセス > ファイル共有の監査（Audit File Share）
→ 成功（Success）を有効化して、まずは粗めに「誰がどの共有を使っているか」を把握
オブジェクトアクセス > 詳細なファイル共有の監査（Audit Detailed File Share）
→ 失敗（Failure）のみ、または通常は無効にしておき、調査時にのみ一時的に有効化

「とりあえず全部ログに出しておけば安心」という発想は、5145 に関しては逆効果になりがちです。ログ量が爆発すると保管コストも上がり、肝心なときに人間が追えなくなります。

調査時だけ 5145 をオンにする運用例

たとえば、重要共有で不審なアクセスが疑われたときだけ、次のような手順で 5145 を一時的にオンにする運用が考えられます。

通常時は 5140 と 4663 を中心に監査・収集
問題が発生・疑われた共有サーバーで、GPO などから「詳細なファイル共有の監査（成功／失敗）」を有効化
一定期間（数時間～数日）だけ 5145 を収集し、SIEM などで詳細なアクセスパターンを分析
調査完了後は再び 5145 の成功監査をオフにして、通常モードに戻す

このように「オンにする理由」と「いつオフに戻すか」を監査ポリシーに明記しておくと、監査ログ運用が破綻しにくくなります。

実務でのノイズ低減テクニック ― SACL と 4663 編

重要フォルダーに SACL を設定し、4663 を本命ログにする

「誰がどのファイルを読み取ったか／書き込んだか／削除したか」を知りたい場合、5145 だけでは心もとないケースが多くなります。その理由は、5145 が共有レベルの要求ログであり、実際にファイルに対してどの操作が行われたかまで、完全には追いきれないためです。

そこで、重要フォルダーには NTFS のSACL（監査設定）を適切に構成し、イベント ID 4663 を本命ログとして取得することが推奨されます。

監査したいフォルダーのプロパティ > セキュリティ > 詳細設定 > 監査から SACL を設定
対象ユーザー／グループを指定（Everyone で広く取るとログが爆発するので注意）
監査するアクセス権を、書き込み／削除／属性変更／権限変更など、リスクの高いものに絞る

これにより、当該フォルダー配下で実際に行われた操作（Create/Write/Delete など）は、4663 として比較的わかりやすい形で記録されます。

5145 と 4663 を組み合わせて意味のある監査にする

5145 と 4663 には次のような役割分担があります。

項目	5145（Detailed File Share）	4663（Object Access）
レイヤー	共有レベル（SMB 要求単位）	ファイル／フォルダーオブジェクト単位
得られる情報	どの共有・どのパスにどのようなアクセス権を要求したか	どのファイルに対して実際に読み取り／書き込み／削除などが行われたか
用途	SMB レベルの動作解析、アクセス権評価の確認	証跡としての操作履歴、インシデント調査

たとえば不正な削除が疑われる場合、

4663 で「Delete」が記録されているファイル名・ユーザー・時刻を起点にする
その前後で 5145 を参照し、どの共有経由でアクセスされていたか、どのアクセス権が評価されていたかを確認

といった形で両者を組み合わせると、「なぜその操作が許可されてしまったのか」という権限設計の問題まで追いやすくなります。

イベントビューアー／WEF／SIEM でのノイズ低減テクニック

5145 から「書き込み系」だけを抽出する

5145 のすべてをそのまま見るのではなく、Accesses / Access Mask を使って「見るべきログ」を絞り込むと、分析の効率が大きく変わります。

読み取り専用アクセス（ReadData, ReadAttributes など）のみのイベントは、一旦ノイズ扱い
書き込み（WriteData）、削除（Delete）、権限変更（WriteOwner, WriteDAC）などを含むイベントだけを抽出

イベントビューアーであれば、XML ビューで XPath フィルタを設定することで、Accesses に特定の文字列を含むイベントだけを出すことも可能です。

&lt;QueryList&gt;
  &lt;Query Id="0" Path="Security"&gt;
    &lt;Select Path="Security"&gt;
      *[System[(EventID=5145)]] 
      and
      *[EventData[Data[@Name="AccessMask"] and 
        (contains(., "0x2") or contains(., "0x4") or contains(., "0x10000"))
      ]]
    &lt;/Select&gt;
  &lt;/Query&gt;
&lt;/QueryList&gt;

AccessMask の値は環境によって異なるため、実際のログを見ながら「書き込み系のビット」を特定していくとよいでしょう。

WEF や SIEM 側での「数秒単位の重複排除」

Windows Event Forwarding（WEF）や各種 SIEM 製品を使っている場合は、サーバー側ではなく収集基盤側で集約・重複排除（デデュープ）を行うのが現実的です。

具体的には、次のようなキーで数秒単位の集約を行います。

ShareName（共有名）
RelativeTargetName（相対パス）
AccessMask
Client Address（クライアント IP）
SubjectLogonId（ログオン ID）
Protocol / SMB バージョンなど（製品による）

これらが同じで、タイムスタンプが例えば 5 秒以内に収まるイベントを 1 つの「論理イベント」とみなし、

first seen（最初に観測した時刻）
last seen（最後に観測した時刻）
count（発生回数）

といった情報だけを記録するようにすると、「実際に何が行われたか」を把握しやすくなります。

バックグラウンドスキャナの影響を抑制する

ウイルス対策ソフトやインデクサがイベントを爆増させる

意外に見落とされがちなのが、

ウイルス対策ソフトのオンアクセススキャン
Windows Search などのインデックス作成サービス
バックアップソフトや DLP 製品などのエージェント

といったバックグラウンドプロセスの存在です。これらが共有フォルダーを頻繁に走査していると、5145 および 4663 のイベントがユーザー操作とは無関係に大量発生します。

対策としては、次のような見直しが考えられます。

ファイルサーバー側のウイルススキャン対象から、特定の共有やフォルダーを除外（業務要件とリスクを慎重に評価したうえで）
インデックス作成対象からファイルサーバー共有を外す、または頻度を下げる
バックアップソフトのフルスキャンタイミングと監査要件をすり合わせる

特に「バックアップ開始のたびにログが雪崩のように増える」といった場合は、これらバックグラウンド要因を疑う価値があります。

SMB マルチチャネルを使った切り分け（検証環境向け）

5145 の多重発生が SMB マルチチャネルによるものか、他の要因なのかを確かめたい場合、検証環境に限って一時的に SMB マルチチャネルを無効化して比較する方法があります。

PowerShell から次のように設定します。

# サーバー側（検証環境のみで実行）
Set-SmbServerConfiguration -EnableMultiChannel $false

# クライアント側（同じく検証環境のみ）
Set-SmbClientConfiguration -EnableMultiChannel $false

# 現在の多重接続状況を確認
Get-SmbMultichannelConnection

マルチチャネルを無効化した状態で同じ操作を行い、5145 の件数や送信元ポートのバリエーションがどう変化するかを比較すると、ログ増加の要因をある程度切り分けられます。

ただし、本番環境で SMB マルチチャネルを恒久的に無効化すると、性能低下や冗長性低下に直結する可能性があるため、原則として切り分け目的の一時的な利用に留めるべきです。

イベント ID 5145 の読み方ミニガイド

5145 を活かすには、「どのフィールドをどう見ればよいか」を押さえておくと便利です。代表的なフィールドを簡単に整理します。

フィールド名	意味	ポイント
SubjectUserName など	アクセス元のユーザー／アカウント	誰がアクセスしたかを特定する基本情報
ShareName	アクセスされた共有名（例：\\server\share1）	どの共有が対象かを把握する
RelativeTargetName	共有ルートからの相対パス	実際にどのフォルダー／ファイルが対象かを特定
AccessMask / Accesses	要求されたアクセス権	読み取りだけか、書き込み／削除を含むかを判断
Client Address	クライアントの IP アドレス	どの端末からのアクセスかを特定
SourcePort	クライアント側の TCP 送信元ポート	異なるポート＝別セッション／並列処理の可能性が高い

特に RelativeTargetName と AccessMask（または Accesses） を主キーにしてイベントを束ねると、「どのパスに対して、どのような権限の要求が、どれくらいの頻度で発生しているか」が把握しやすくなります。

監査設計のベストプラクティスまとめ

ここまでのポイントを、監査設計の観点から整理すると次のようになります。

5145 の成功ログを常時フルで集めない
成功だらけの 5145 を常時収集すると、ノイズとコストが増えるだけになりがちです。通常時は 5140 ＋ 4663（必要箇所）＋失敗系イベントを中心にし、5145 は調査用に絞り込んで使うのが現実的です。
重要領域には SACL を設定し、4663 を本命ログにする
書き込み／削除／権限変更といったリスクの高い操作は、SACL 設計をきちんと行った 4663 で確実に捕捉します。
集中管理基盤（WEF／SIEM）でフィルタと集約を行う
5145 は AccessMask に基づくフィルタと、キー項目＋短時間ウィンドウによる集約で、実質的な操作単位にまとめて扱うのが効果的です。
バックグラウンド要因（AV／インデクサ／バックアップ）を把握する
ユーザー操作とは別にログを増やしている要因を把握し、必要に応じて除外設定やスケジュール調整を行います。
必要に応じて SMB マルチチャネルなどで切り分けを行う
検証環境でマルチチャネルを一時的に無効化し、ログの傾向差を確認することで、原因の見極めに役立ちます。

Microsoft Q&A に質問するときのカテゴリ／タグの選び方

最後に、この種の「イベント ID 5145 が大量発生する」「SMB 監査ログの解釈が分からない」といった内容を Microsoft Q&A に投稿する場合の、カテゴリ／タグ選びの目安を整理します。

基本は「Windows Server」カテゴリを選ぶ

5145 は Windows Server のセキュリティログ（Security イベント）に出力されるイベントであり、ファイルサーバー／SMB に密接に関連します。そのため、メインのカテゴリとしては「Windows Server」を選択するのが自然です。

サブ領域やタグで絞り込む

さらに、質問内容の主な焦点に応じて、次のような領域やタグを組み合わせると、専門家に届きやすくなります。

観点	想定されるサブカテゴリ／タグ	主なテーマ
ファイルサーバー／SMB の動作	File Services / SMB	SMB の動作、共有の設定、パフォーマンスなど
ネットワーク／セッションの観点	Networking	TCP セッション、マルチチャネル、ネットワーク設計など
監査／セキュリティ設計	Security / Auditing	監査ポリシー、イベントログの解釈、セキュリティ設計

タイトルや本文には、キーワードとして次のような語句を含めるとよいでしょう。

「Security Auditing」
「SMB Auditing」
「Event ID 5145」
「Detailed File Share」

Microsoft Q&A は必ずしも細かな専用タグが揃っているわけではありません。そのため、

最も近いカテゴリ（Windows Server / File Services / Security など）を選ぶ
件名で「SMB 監査ログ」「イベント ID 5145」「同一操作で大量に出る」など、論点を明確に書く

といった工夫をすることで、適切な担当分野の回答者からレスポンスを得やすくなります。

まとめ ― 5145 は「多すぎる」のではなく「そういう設計」

Windows Server のイベント ID 5145 が「同じ共有名・同じアクセスマスクで大量に出る」現象は、

SMB クライアント／サーバーが並列処理を前提としている
1 回のユーザー操作が複数の SMB 要求に分解される
SMB マルチチャネルやバックグラウンドスキャナがさらに要求を増やす

という設計上の理由によるものであり、基本的には異常動作ではありません。

実務上は、

監査ポリシーの粒度調整（5140 と 5145、失敗系中心の運用）
SACL と 4663 の活用による「本当に見たい操作」の捕捉
WEF／SIEM によるフィルタと集約、バックグラウンド要因の抑制

といった工夫を組み合わせることで、監査ログを「単なるノイズの山」ではなく、「意味のある証跡」として活用できるようになります。

もし設計や設定に迷った場合は、本記事で紹介した観点を整理したうえで、Microsoft Q&A の Windows Server カテゴリに質問を投稿し、環境情報と期待する証跡レベルを具体的に書き添えると、的確なアドバイスを得られるはずです。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Windows Server 監査ログのイベントID 5145が同一操作で大量発生する原因と対処法

Windows Server 監査ログ「イベント ID 5145」が大量発生する現象とは