Windows Sysinternals Suite深堀：ProcMonログから削除アクセス追跡

【注意】 端末・サーバで「勝手に削除された／消えた」と感じたとき、自己流の調査や復旧操作は状況を悪化させたり証拠性を落とすことがあります。まずは被害最小化（ダメージコントロール）を優先し、必要に応じて株式会社情報工学研究所のような専門事業者へ相談してください。相談導線：問い合わせフォーム https://jouhou.main.jp/?page_id=26983 ／電話 0120-838-831

第1章 「誰が消した？」ではなく「どのプロセスが何をした？」を追う設計に切り替える

現場の本音として、「またログ調査？ どうせ決定打が出ないんでしょ」という疲れがあります。しかも上からは「原因と再発防止を今日中に」と言われる。これ、責められているのは“人”ではなく“現場の不確実性”なんですよね。

削除アクセスの追跡で重要なのは、犯人探しよりも先に「観測の単位」を揃えることです。Windowsでは、ユーザーの操作が最終的に“プロセス”のI/Oとして実行されます。エクスプローラ、Office、バックアップソフト、同期ツール、AV/EDR、管理スクリプト、サービスプロセス……。実態は「誰かのクリック」ではなく「プロセスのファイル操作」です。

ProcMonが強いのは、ファイルシステムのイベントを時系列で並べ、

• プロセス名／PID
• 対象パス
• 操作（Operation）
• 結果（Result）
• 詳細（Desired Access, ShareMode, Disposition など）

を同じ画面で揃えられる点です。ここまで揃うと、議論が「推測」から「確認」に寄っていきます。たとえば“削除”に見える事象も、実際は「リネームで隔離」や「属性変更＋後続処理で削除」など、複数イベントの連鎖で起きます。

この章の結論はシンプルで、追跡の主語を“人”から“プロセス”へ変えるだけで、判断の精度と速度が上がるということです。次章からは、そのための初動と観測条件を具体化します。

第2章 被害最小化（ダメージコントロール）を優先する：調査より先に“壊さない”

削除が疑われると、つい「とにかく復旧」や「とにかく証拠を探す」に走りがちです。でも、現場で一番起きやすい事故は“善意の操作で証跡を壊す”ことです。特にファイルサーバや共有フォルダは、人が多いほど上書きが速い。

まずやるべきは、状況を落ち着かせる（温度を下げる）ための初動です。以下は一般的な指針で、環境によって正解は変わりますが、少なくとも「推測で手を動かす」を減らせます。

初動の考え方（止められない現場向け）

• 影響範囲を固定：対象パス、影響期間（例：◯時〜◯時）、疑いの操作（削除／移動／暗号化など）をいったん“仮”で良いので確定させる。
• 変更操作を減らす：対象共有への書き込み制限、特定グループのみアクセス許可、メンテ時間の確保など、現場の運用と折り合いをつけた“歯止め”をかける。
• 観測条件を決める：どの端末／サーバで、誰の権限で、どの時間帯に、どの範囲を記録するか。

ここで大事なのは「全部止める」ではなく、業務を続けながらも観測できる最小構成を作ることです。ProcMonは強力ですが、サーバで闇雲に回すと負荷やログ量が跳ね上がります。だから次章で“絞り方”を中心に説明します。

相談導線を最初に置く理由

削除アクセスの追跡は、実は“技術”だけの問題ではありません。監査の観点、法務・労務、委託先との契約、ログの保全ポリシーなどが絡みます。「一般論で安全にできる範囲」と「個別案件で設計が必要な範囲」の境界が早い段階で出てきます。

もし、(1) 被害が継続している／(2) 影響範囲が読めない／(3) 内部不正やマルウェアの可能性が否定できない／(4) 顧客データが絡む――このあたりが当てはまるなら、早めに株式会社情報工学研究所への相談（https://jouhou.main.jp/?page_id=26983 ／0120-838-831）を検討してください。現場が“孤立して消耗する”のが一番まずいです。

第3章 ProcMonの取り方で結果が決まる：フィルタ設計が8割、保存設計が残り2割

ProcMonを初めて触る人がつまずくのは、たいてい「ログが多すぎて何も分からない」です。これはツールの問題というより、観測設計が未定のまま“全部取った”ことが原因です。逆に言えば、最初にフィルタを正しく作るだけで追跡は現実的になります。

基本方針：最初から“対象パス”で絞る

削除アクセス追跡では、まず対象をパスで固定します。共有フォルダなら、該当の共有パス配下（例：D:\Share\ProjectX\…）に絞ります。ProcMonは条件に合わないイベントも表示できますが、運用ではDrop Filtered Events（フィルタ外イベントを捨てる）の考え方が重要です。サーバでの観測は特に、ログ量が膨らむほど保全も解析も苦しくなります。

• Include：Path begins with / contains（対象パス）
• Include：Operation（後述する削除関連の操作）
• Include/Exclude：Process Name（明らかなノイズを除外）

「何を除外してよいか」が不安な場合は、まず“対象パスのInclude”だけを先に作り、そこからProcess NameやOperationで段階的に絞るのが安全です。

保存の考え方：PMLは“証跡”として扱う

削除が疑われる局面では、PML（ProcMonのネイティブ形式）を“後から再解析できる証跡”として残す発想が必要です。CSVに変換してしまうと、情報量（詳細や内部構造）が落ちることがあります。まずはPMLのまま保全し、必要ならバックアップコピーを取り、解析用に複製を作る、という順番が無難です。

• 記録の開始・終了時刻をメモ（別ログでもよい）
• 対象端末／サーバ名、取得者、権限、取得目的を記録
• 可能なら時刻同期（NTP等）を確認し、ズレがあれば“ズレ量”を記録

ここまでやって初めて、「会議で説明できるログ」になります。現場の調査が評価されるのは、“頑張った”ではなく“再現性と説明可能性”です。

ProcMonで最低限押さえる表示列

削除アクセス追跡では、以下が見えていると解析が速いです。

• Time of Day（時刻）
• Process Name / PID（プロセス）
• Operation / Result（操作と結果）
• Path（対象）
• Detail（Desired Access などの詳細）

次章では、この“Operation”をどう読めば「削除の連鎖」を正しく追えるかを整理します。

第4章 “削除”はイベント1回で起きない：Windowsの削除セマンティクスとProcMonの読み方

「Deleteが出たら犯人」という理解は、現場を混乱させやすいポイントです。Windowsのファイル削除は、見た目より“段階的”です。特にNTFSの典型パターンでは、削除は削除フラグの設定 → ハンドルクローズ時に実体が消えるという流れになり得ます。つまり、削除の意図は早い段階で現れ、実体の消失は後段で起きることがあります。

ProcMonで“削除に近い”操作として見るべきもの

環境やWindowsバージョン、アプリ実装によって表現は変わりますが、削除や移動に絡む代表例として、次の系統を意識します。

• CreateFile：対象を開く（DetailにDesired AccessやDispositionが出ることがある）
• SetDispositionInformation / SetDispositionInformationFile（表示名は環境差あり）：削除フラグの設定に相当
• SetRenameInformation：別名へのリネーム（移動や“隔離”もここに出る）
• CloseFile：クローズ（ここで実体削除が確定するケースがある）

ここで重要なのは、「削除操作は、削除フラグ・リネーム・クローズなどの連鎖で観測される」という見方です。だから“1イベントだけ見て断定”が危険になります。

「結果（Result）」が示すのは“正しさ”ではなく“OSの判断”

ProcMonのResultにSUCCESSが出ても、それは“良いこと”ではなく“OSがその操作を許可した”という意味です。逆にACCESS DENIEDが出た場合は、権限や共有モード、整合性レベル、保護機構（AV/EDR等）などの“防波堤”が働いた可能性があります。

削除追跡でありがちな誤解は、

• SUCCESS＝正常、失敗＝異常
• ACCESS DENIED＝犯人の痕跡

といった単純化です。実際には、攻撃・誤操作・自動処理のどれでもSUCCESSになり得ます。だから次に見るべきは、プロセスの親子関係やコマンドライン、実行ユーザーなど“文脈”です。

リネームと削除の見分け（現場で効く視点）

「消えた」と言われても、実態が“移動”のことはよくあります。例えば、アーカイブ処理や同期ツールの競合、アプリの一時ファイル運用で、リネーム＋後段クリーンアップが入るケースです。ProcMonでは、同じプロセスが短時間に

1. 対象パスを開く
2. 別パスへリネームする
3. 元を削除扱いにする（またはクリーンアップする）

といった“整然とした連鎖”を出すことがあります。この連鎖が見えてくると、議論は「誰がやった」から「この運用・このツールがこの挙動をするのは設計として妥当か？」へ移っていきます。ここが腹落ちポイントです。

次章では、その文脈を確定するために、プロセスツリー（親子）とコマンドライン、そして権限（Desired Access / ShareMode）をどう読むかを解説します。

第5章 「犯人」を作らないために：親子プロセスとコマンドラインで“経路”を確定する

現場でいちばん消耗するのは、「結局だれ？」という問いが先行して、ログが“人の責任”を補強する材料扱いになる瞬間です。ここで大事なのは、ProcMonのログから“人”を断定することではなく、「削除に至った実行経路」を確定することです。経路が確定すると、再発防止が具体化します。逆に、経路が曖昧なままだと、対策は「注意喚起」「ルール強化」になりがちで、また同じ事故が起きます。

ProcMonでまず確定する3点

• Process Name / PID：どのプロセスが実行したか
• Parent（親）：誰に起動されたプロセスか（＝運用経路の手がかり）
• Command Line：どんな引数で動いたか（＝タスク/スクリプト/ツールの特定に直結）

ProcMonのイベント詳細や列設定で、可能な範囲でコマンドラインやユーザー情報にアクセスできるようにしておくと、解析の手戻りが減ります。環境によってはProcMon単体で十分見えないこともあるため、Sysmon（Microsoft SysinternalsのSysmon）やWindowsの監査ログ、タスクスケジューラの履歴と突き合わせる設計も現実的です。

“親子”で見える、現場にありがちな経路

ここでのポイントは、「プロセス名の印象」で断定しないことです。例えばpowershell.exeが出ても、管理者が作った健全なバッチかもしれないし、侵入後の攻撃者が使ったかもしれない。見分ける鍵は親子関係とコマンドライン、そして実行ユーザーの文脈です。

心の会話：現場が言いたいこと

「また“運用が悪い”って言われるのかな……。いや、運用は頑張ってるんです。止められないシステムで、現実的な手順に落とすのが一番大変で。」

この感覚は健全です。だからこそ、ログから“個人の責任”を作るのではなく、運用経路（タスク・スクリプト・ツールの設定）を確定して、改善点を一点に絞るのが最短です。

次章では、削除の実行可否を決める「アクセス権と共有モード」を、ProcMonのDetailからどう読むかを整理します。

第6章 アクセス権の壁を越える：Desired Access / ShareMode / Integrityの読み方

削除追跡は、最終的に「なぜそのプロセスが削除できたのか」「なぜ防げなかったのか」に行き着きます。ここで効いてくるのが、ファイルアクセスの詳細です。ProcMonのDetailには、操作に応じて様々な情報が出ますが、削除や改変を理解する上で特に重要なのはDesired AccessとShareMode、そして（見える範囲での）権限文脈です。

Desired Access：そのプロセスが“何をしたかったか”

Desired Accessは「このハンドルで何をしたいか」を表します。削除に関係しやすいのは、書き込み系の権限やDELETE相当の意図です。環境によって表示の粒度は異なりますが、ポイントは“読み方”です。

• 読み取り中心：参照や列挙はできても削除や改変は難しい
• 書き込み・属性変更・削除意図：削除フラグ設定やリネーム、クリーンアップに繋がりやすい

ProcMonで削除が起きた時間帯の直前に、同じプロセスが対象パスをどんなアクセスで開いているかを追うと、「最初から削除の意図で開いた」のか「別目的の処理の後段で削除に至った」のかが見えやすくなります。

ShareMode：他プロセスとの“同時利用”が許されるか

ShareModeは、他のプロセスが同じファイルにどんなアクセスを許されるか（共有の仕方）を意味します。削除事故でありがちなのは、

• 同期ツールが“排他”に近い開き方をして、別処理が失敗→リトライ→思わぬ削除連鎖
• アプリが一時ファイルを作ってすぐ消す（短時間の連鎖）

といった“競合の結果としての削除”です。ProcMonでは成功・失敗が混在することがあり、その混在は競合の兆候になります。成功だけを見て断定しないことが重要です。

Integrity/権限文脈：実行ユーザーと権限設計の穴

削除が成立する背景には、NTFS ACL、共有権限、UAC、サービスアカウント、グループポリシー、委任などが絡みます。ProcMon単体で全てが見えるわけではありませんが、少なくとも「どのユーザー文脈で実行されたか」は追跡の軸になります。

ここでの再発防止は、単に「削除禁止」にすることではなく、

• 削除が必要な運用経路（例：アーカイブ）を“明示的な専用アカウント”に寄せる
• 業務ユーザーの権限は“必要最小限”に落とす
• 監査ログ（ファイル監査、Sysmon、EDRログ）と組み合わせて説明可能性を上げる

といった設計に落とすことです。ここから先は「一般論」ではなく、業務要件・停止できない制約・既存ツールの相性で最適解が変わります。終盤で“相談すべき境界”を明確にします。

次章では、短命プロセスやバッチ、サービス、EDRなど、ProcMon追跡が難しい典型ケースの対処を整理します。

第7章 追跡の落とし穴：短命プロセス、サービス、EDRの“代理操作”をどう扱うか

ProcMonを回しても「それっぽい削除イベントが見つからない」ことがあります。これは“削除が起きていない”のではなく、観測の難しい形で起きている可能性があります。現場で特に多いのが、短命プロセス、サービス経由、EDR/AVの隔離動作です。

短命プロセス：起動してすぐ終わる（ログが流れる）

例えば一時的なスクリプト実行、インストーラ、更新処理などは、プロセスが一瞬で消えます。ProcMonの画面を眺めているだけでは追いきれません。対策としては、

• 対象パスをIncludeしてログ量を減らす
• 時間窓を短く区切る（例：10分×複数回）
• 可能ならプロセス名でIncludeし、PIDの揺れを許容する

といった“観測設計”が効きます。ここでのコツは、完璧を狙わず、追跡可能な範囲で“再現性”を作ることです。

サービス経由：人の操作が見えない

タスクスケジューラ、バックアップソフト、同期ツール、ファイルサーバのメンテナンス機構などは、サービスとして動きます。この場合、削除イベントはユーザーのexplorer.exeではなく、サービスプロセスとして観測されます。

このとき重要なのは、プロセスの「説明」ではなく「経路」です。どの設定（ジョブ定義）でそのサービスが対象パスを処理しているのか。ProcMonだけで詰め切れない場合は、該当ツールのジョブログや設定ファイル、Windowsイベントログ、タスク履歴を合わせて、経路を確定していきます。

EDR/AVの代理操作：隔離・削除・修復が“正義”として実行される

セキュリティ製品は、検知したファイルを隔離したり、削除したり、修復したりします。現場視点では「勝手に消えた」ですが、製品視点では“被害最小化（ダメージコントロール）”です。

このときの注意点は、

• 隔離先に移動されている可能性（削除ではなく移動）
• ポリシー更新や定義ファイル更新直後に集中的に起きる可能性
• ProcMonでは製品のサービスが実行者として出るため、“誰が”に結びつけないこと

です。EDR/AVのログと突き合わせると、説明が一気に通るケースがあります。一方で、誤検知や運用ミスが背景にある場合もあり、ここも個別案件の設計が必要になります。

ここまでのまとめ：追跡できないのではなく、追跡の設計が必要

ProcMonは万能ではありませんが、観測条件を揃えることで、削除の経路はかなりの確率で見えてきます。次章では、ログを“証拠として残す”ための保全と、報告書に落とす型を整理します。

第8章 証拠として残す：PML保全、時刻同期、ハッシュ、報告の型

削除アクセス追跡が“仕事”として評価されるかどうかは、結果の派手さよりも「説明できる形で残っているか」にかかっています。現場の会議では、ログのスクショ1枚より、時系列で整った記録が効きます。

保全でやること（最低限）

• PMLを原本として保存：解析用にコピーを作り、原本は変更しない。
• 取得条件の記録：端末/サーバ、取得者、権限、フィルタ条件、開始・終了時刻。
• 時刻の整合：NTPの有無、ずれがあるならどれくらいか（分かる範囲で）を記録。

報告の型（現場が揉めないための書き方）

報告で避けたいのは「断定しすぎる」ことです。ログは“観測された事実”を示しますが、“意図”は別です。だから型としては、

1. 観測した事実（いつ、どのプロセスが、どのパスに、何をした）
2. その解釈（削除フラグの設定と推定、移動の可能性、競合の兆候など）
3. 追加確認が必要な点（EDRログ、タスク定義、バックアップ設定、監査ログ）
4. 暫定対策（アクセス制限、ジョブ停止、監視強化）

の順で書くと、技術と運用の会話が噛み合いやすくなります。

次章では、ここまでの追跡結果を「再発防止」に落とすための考え方を整理し、一般論の限界と“専門家に相談すべき境界”を明確にします。

第9章 再発防止に落とす：ProcMonの“結果”を、監査・権限・運用の設計へつなぐ

ProcMonで削除アクセスの経路が見えてくると、現場の空気が少し落ち着きます。ここが重要で、議論の温度を下げて（空気を落ち着かせて）初めて、再発防止が“具体”になります。

ただし、ProcMonのログは「起きた事実」を示しても、「なぜ防げなかったか」を単体で解き切れるとは限りません。再発防止は、だいたい次の3レイヤに分解すると進みます。

1) 監査（見える化）：ProcMonは“スポット観測”、監査は“常設観測”

ProcMonは非常に強力ですが、常時稼働させる前提の監査基盤ではありません。多くの現場では、ProcMonは「問題が起きたときのスポット観測」として使い、平時はWindowsの監査ログやEDR、Sysmonなどで“常設観測”を作る、という分業が現実的です。

Windowsでファイル操作を監査する場合、一般に「監査ポリシー（Object Access）」と、対象フォルダに設定する監査（SACL）が噛み合って初めて、必要なイベントがSecurityログに出ます。ここは“設定さえ入れれば全部出る”ではなく、ログ量・性能・運用の都合で設計が必要です。

• どの共有／どのフォルダを監査対象にするか（全部は現実的でないことが多い）
• 削除（Delete）だけを見るのか、改変や権限変更まで含めるのか
• 誰の操作（ユーザー／サービスアカウント）を重視するのか

この設計ができていると、次回は「ProcMonで追う前に、まず監査ログで当たりを付ける」という流れが作れます。現場の負担が大きく下がります。

2) 権限（防波堤）：削除権限を“誰にでも”持たせない

削除が成立したということは、権限として成立していた可能性が高い、ということです。もちろん例外（システム権限、サービス、EDR/AVなど）はありますが、多くの事故は「便利さのために、結果的に削除できる人が広すぎる」ことが背景にあります。

ここでやりがちな失敗は、極端に削除を禁止して業務が回らなくなることです。狙いは“禁止”ではなく、削除を実行できる経路を限定して、堤防を築くことです。

• 専用アカウント化：バックアップやアーカイブなど“削除が必要な処理”は、専用アカウントに寄せる
• 共有権限とNTFS ACLの整理：どこで制御しているかを明確化し、二重管理で事故らないようにする
• 委任の棚卸し：誰が管理者権限を持ち、どのスクリプトがどの権限で動くかを台帳化する

権限は一般論が通りにくい分野です。業務要件・既存ツール・レガシー制約で最適点が変わります。だからこそ、ProcMonで“実際の経路”が分かった後に、そこへピンポイントで歯止めをかけるのが効率的です。

3) 運用（経路の固定）：同期・バックアップ・清掃ジョブが“削除”を生む

削除アクセスの経路として実務で多いのは、同期ツールやバックアップ、ログローテーション、アーカイブ、クリーンアップなどの“定期処理”です。運用の意図は正しくても、設定ミスや例外ケース（パス変更、権限変更、タイミング競合）で削除に見える事象が起きます。

再発防止として効きやすいのは、次のような「運用の場を整える」施策です。

• 変更管理：ジョブ設定や対象パス変更は、必ず記録してレビューする
• 検証環境：本番と同じパス構造・権限に近い検証環境でテストする
• 例外ルール：退避先や例外フォルダ（消してはいけない）を明確にする
• 責任分界：委託先ツール・社内ツール・セキュリティ製品の境界を整理する

心の会話で言うと、ここで現場が求めているのは「正論」ではなく「運用として回る設計」です。

「“ちゃんとやれ”は分かる。でも、その“ちゃんと”を実装するコストを誰が持つの？って話なんですよね。」

この視点を持ったまま、次章では“一般論の限界”と、専門家に相談すべき境界を明確にして締めます。

第10章 帰結：ログが示すのは“削除の原因”ではなく“削除に至った設計の穴”——埋めるべき一点を決める

ProcMonで削除アクセスの追跡をすると、分かることが増えます。けれど同時に、分からないことも見えてきます。ここが落とし穴で、「ログを取ったのに断定できない」こと自体が、現場の罪悪感につながりがちです。

でも、それは自然です。ProcMonは“観測”であって、“真相の自動判定装置”ではありません。ログが示すのは、たいてい次のような事実です。

• どのプロセスが、どのパスに、どんな操作をしたか
• その操作が成功したか、拒否されたか
• 前後で、どんな連鎖（リネーム／削除フラグ／クローズなど）があったか

そして本当に大事なのは、この事実から「次に埋めるべき穴」を一点に絞ることです。穴とは、たとえば以下のどれかです。

一般論の限界：ログの“外側”に答えがあることが多い

ここまで読んで、「よし、ProcMonで追えば全部解ける」と思った方もいるかもしれません。けれど実際は、削除アクセスの背景には、契約・委託・監査要件・個人情報や機密の取り扱い・セキュリティ製品の運用・停止できないレガシーの制約などが絡みます。

つまり、ログの解析だけで完結する問題ではなく、「業務として許容できる設計」に落とす必要があります。ここが一般論の限界です。たとえば、

• 監査を強くするとログ量と運用コストが増える
• 権限を絞ると業務が止まる可能性がある
• EDR/AVの動作はセキュリティ要件とトレードオフになる

こうしたトレードオフは、個別案件（組織、契約、システム構成、運用体制）によって最適点が変わります。だから、終盤での結論は次のとおりです。

ProcMonは“現場が腹落ちする材料”を作る道具であり、最終的な再発防止は“設計”と“運用合意”で決まる。

次の一歩：相談するなら、まず何を揃えるか

もしあなたが今、具体的な案件・契約・システム構成で悩んでいるなら、遠回りせずに株式会社情報工学研究所のような専門家へ相談するのが合理的です。相談が早いほど、被害最小化（ダメージコントロール）もしやすくなります。

相談時に揃っていると話が速い情報は、次のとおりです（分かる範囲で十分です）。

• 対象パス（共有名・フォルダ構造の概要）
• 発生期間（いつから／いつ気づいたか）
• 影響範囲（消えた/移動した/権限が変わった等）
• 関係しそうな自動処理（同期、バックアップ、清掃ジョブ、EDR/AV）
• 取得できたログ（ProcMon PML、監査ログ、EDRログなど）

問い合わせフォーム：https://jouhou.main.jp/?page_id=26983 ／電話：0120-838-831

現在のプログラム言語各種にそれぞれの注意点（削除追跡・ログ設計の観点）

最後に、現場でよくある「アプリ側の実装が原因かも？」という観点に触れておきます。ここは断定ではなく、設計・実装で起きやすい落とし穴の整理です。言語というより“ライブラリと運用”の影響が大きい点に注意してください。

• C/C++
  • 低レベルAPIを直接叩ける分、ファイル削除・リネームが意図せず走る（例：一時ファイル運用、エラー時クリーンアップ）ことがある。
  • 例外/エラー処理で「失敗したら消す」が実装されていると、障害時にだけ削除が発生し、再現が難しい。
  • 共有ファイルの排他制御（ロック、ShareMode相当）設計が甘いと、競合が削除連鎖を誘発する。
• C# / .NET
  • File/Directory APIは扱いやすい反面、再試行（リトライ）や例外処理の方針次第で、短時間に大量の操作が発生して追跡が難しくなる。
  • サービスとして動かす場合、実行アカウント（サービスアカウント）の権限が強すぎると“設計上の穴”になりやすい。
  • 監視（FileSystemWatcher等）はイベント欠落や順序の揺れがあり得るため、監査の代替として過信しない。
• Java
  • NIOのファイル操作は抽象度が高く、実体としてはリネーム＋置換＋削除の連鎖になることがある（ログ上は“削除に見える”）。
  • Windowsサービス化やバッチ実行の経路が複雑になりやすいので、コマンドライン・起動元・実行ユーザーの記録を残す設計が重要。
  • 例外時のクリーンアップ（テンポラリ削除）が障害時だけ発火するケースに注意。
• Python
  • 運用で多いのはスクリプトの自動実行（タスクスケジューラ、ジョブ管理）。“誰が実行したか”より“どのジョブ経路か”が重要。
  • ファイル操作が簡単なぶん、誤ったパス（ワイルドカードや相対パス、環境変数展開）で想定外の削除が起きやすい。
  • ログ設計が弱いと、ProcMonで追えても「なぜそのスクリプトが動いたか」まで辿れない。ジョブ定義・引数・実行履歴を残すべき。
• JavaScript / Node.js
  • ビルド/デプロイ/クリーン処理でディレクトリ削除が入ることがある。CI/CD経路（どのジョブがいつ動いたか）をログとして残すのが重要。
  • 依存パッケージの更新で挙動が変わることがあり、同じソースでも運用中に“削除タイミング”が変わることがある。
  • サービス実行ユーザーの権限が強いと、事故の影響範囲が広がる。
• Go
  • 単一バイナリでサービス化されやすく、実行経路が“サービス”に寄る。監査と起動元管理（設定ファイル、引数、更新履歴）が重要。
  • 並行処理でファイル操作が集中すると、ProcMonでの追跡は可能でも、人間が読み解くのが難しくなる。対象パスと操作の絞り込み設計が必要。
• PowerShell / バッチ
  • 削除事故の頻出経路。タスク化されると“人の記憶”から消えやすいので、ジョブ定義と引数、対象パスの台帳化が効く。
  • ワイルドカードやパス組み立てミスで範囲が広がる典型がある。実行前に対象をDry-runで確認する設計が望ましい。

ここまでの内容は、あくまで「削除アクセス追跡を、現場が回る形で設計に落とす」ための一般論です。実際の現場では、レガシー制約、契約、委託、監査要件、セキュリティ製品、運用体制の組み合わせで最適解が変わります。

だからこそ、具体的な案件・契約・システム構成で悩んだタイミングでは、株式会社情報工学研究所への相談・依頼を検討してください。現場の状況を前提に、被害最小化（ダメージコントロール）と再発防止を“運用として回る形”に落とす支援ができます。問い合わせフォーム：https://jouhou.main.jp/?page_id=26983 ／電話：0120-838-831