MFT・USNジャーナルとは？Windowsのファイル履歴を解析

2026年9月9日 2026年9月23日

デジタル・フォレンジック調査ラボ

WindowsのNTFSでは、$MFTからファイルやフォルダの管理情報を、$UsnJrnlからファイルシステム上の変更記録を確認できる場合があります。 両者を照合すると、ファイルが存在したことや、作成・変更・名前変更・移動・削除の流れを検証する手掛かりになります。

ただし、どちらもWindowsの全操作を再現する完全な履歴ではありません。ファイルの記録が残っていることと、特定の社員が閲覧・コピー・削除したことは、分けて判断する必要があります。

この記事では、株式会社赤井事務所／デジタルフォレンジックPROが公表する調査方針と、Microsoftの公式資料等をもとに、企業担当者が調査結果を読み解くためのポイントを説明します。

すでに重要ファイルの消失などが発覚し、証拠として調べる予定がある場合は、対象PCへの復元ソフト導入、初期化、再配布を進める前に、保全の要否を確認してください。

MFT・USNジャーナル以外も含めて、Windows PCに残るファイル操作、USB、削除、Web閲覧、ログオンなどの証拠や、PCフォレンジック全体で確認できる範囲については、PCフォレンジックで何が分かる？Windows PCに残る証拠と、確認できること・できないことで整理しています。

MFT・USNジャーナルだけでなく、LNK・Jump Lists、USB、削除ファイル、アプリ実行などWindows PCに残る証拠全体を確認したい場合は、Windows・PCフォレンジックで、主な調査項目と確認できる痕跡をまとめています。

MFTとUSNジャーナルの違い

NTFSは、Windowsで使われるファイルシステムの一つです。ファイルの保存場所や名称、属性などを管理しています。本記事は対象の保存先がNTFSである場合を中心に扱います。USBメモリがexFATやFAT32の場合などには、同じ記録を前提にできません。

証拠	主な役割	調査で見るポイント	単独では断定できないこと
`$MFT`	ファイル・フォルダの管理	名称、親フォルダ、サイズ、時刻、使用状態など	過去の全操作、削除日時、操作した人物
`$UsnJrnl`	ファイルシステム上の変更の追跡	作成、変更、名前変更、削除などの記録	変更前後の内容、操作目的、持ち出し先
LNK・Jump Lists等	ファイルや保存場所の利用に関する手掛かり	対象ファイルとの関連、利用したアプリ等	本人が本文を読んだこと、コピーしたこと

簡単に言えば、MFTでは対象ファイルの情報を、USNジャーナルではその前後の変更を調べます。 Microsoftも、MFTをファイル情報の管理に、USN Change Journalを変更の追跡に用いる仕組みとして説明しています。Master File Table、Change Journals

なお、Windowsのバックアップ機能である「ファイル履歴」、イベントビューアーで見る監査ログ、USNジャーナルは別の仕組みです。この記事で扱うのは、主にNTFSに残された記録の解析です。

$MFTから、ファイルの存在・名称・日時をどう確認するか

MFTに記録があることと、現在ファイルが存在することは別

$MFTはMaster File Tableの略です。NTFS上のファイルには、MFT内に少なくとも一つの管理用エントリがあります。サイズ、日時、アクセス権、データの格納に関する情報などは、MFTのエントリ内、またはそこから示される領域に保存されます。

Microsoftによると、ファイルが削除されると、そのMFTエントリは未使用として扱われ、再利用できる状態になります。したがって、未使用エントリに以前の情報が残っていれば、消えたファイルの名称などを確認できる場合があります。 一方、再利用や破損などで情報が失われることもあります。Master File Table

調査では「ファイル名が見つかった」で終わらず、使用中か未使用か、対象の保存先と整合するか、別のファイルに再利用された記録ではないかを確認します。

フルパスは、親フォルダの情報とつなげて確かめる

MFTに、必ず完全な保存場所が一つの文字列として残っているわけではありません。ファイル名と親ディレクトリへの参照などをたどり、パスを組み立てます。FILE_NAME structure

例えば、解析結果に「顧客一覧.xlsx」があっても、営業部の正式ファイルなのか、別フォルダの同名ファイルなのかは追加確認が必要です。

親フォルダ自体が後から移動・改名・削除されていれば、現在のMFTだけを使って組み立てたパスが、当時の保存場所と一致しない場合もあります。CyberCXの技術検証では、この問題に対してUSNの過去記録も利用する方法が示されています。NTFS Usnjrnl Rewind

作成日時・更新日時・アクセス日時は「人の操作時刻」と同じではない

ファイルには、作成、最終書き込み、最終アクセス、変更に関する複数の時刻があります。解析ツールで「MFT変更時刻」などと表示される項目も、文書本文を編集した時刻と同じ意味とは限りません。FILE_BASIC_INFORMATION

特に、次の読み方は避けます。

作成日時があるから、その時刻に本人が文書を最初から作ったと決める
最終アクセス日時があるから、その時刻に本人が本文を読んだと決める
MFTの変更時刻を、そのままファイルの削除日時にする

タイムスタンプの更新はOSやアプリの処理に左右され、ファイル内容を変えずに日時を設定することも可能です。NTFSではアクセス時刻の更新が遅延する場合もあります。日時の前後関係が不自然でも、それだけで改ざんと判断せず、コピー・移動・保存方法や周辺記録と照合します。File Times

$UsnJrnlから、どのような変更を確認できるか

$UsnJrnlは、ファイルやディレクトリの変更を追跡するUSN Change Journalです。NTFSでは$Extend\$UsnJrnlに関連する情報があり、実際の変更記録を含む$Jストリームが解析対象になります。NTFS Journal Viewer

代表的なレコード形式には、ファイル名、ファイル参照番号、親ディレクトリの参照番号、タイムスタンプ、変更理由を表すReasonなどが含まれます。ファイル参照番号は、名前が変わったファイルを対応付ける手掛かりです。USN_RECORD_V2

Reasonは、変更の種類を表す

次は代表例です。表では公式名称の共通部分USN_REASON_を省略しています。

Reasonの例	記録が示す変更	読み違えやすい点
`FILE_CREATE`	ファイル等の作成	文書の著者や、内容の最初の作成時刻とは限らない
`FILE_DELETE`	ファイル等の削除	不正目的や証拠隠滅の認定ではない
`RENAME_OLD_NAME`・`RENAME_NEW_NAME`	変更前・変更後の名称	名前と時刻だけで対応付けない
`DATA_EXTEND`・`DATA_OVERWRITE`	データの拡張・上書き	変更した文章や数値は分からない
`BASIC_INFO_CHANGE`	属性・タイムスタンプ等の変更	直ちに改ざんとは言えない
`CLOSE`	ファイル等を閉じたことに関する記録	人がアプリを終了した時刻とは限らない

名称と意味はMicrosoftのUSN_RECORD_V2のReason一覧に基づきます。

1レコード＝1回の操作ではない

USNジャーナルでは、同じファイルに対する変更理由が蓄積・集約される場合があります。Microsoftは、ファイルを閉じて開き直さないまま複数回書き込んでも、同じ種類の変更が毎回別レコードになるとは限らないと説明しています。

そのため、レコード件数をそのまま編集回数やクリック回数として数えられません。 閉じる際の記録に複数のReasonがあっても、その一行だけでは変更の順序を確定できません。

また、USNが記録するのは変更の発生や種類であり、変更を元に戻せるだけの内容ではありません。「上書きがあった」ことと「見積額をいくらからいくらへ変えた」ことは、別の確認です。Change Journal Records

名前変更・移動・削除を、MFTとUSNで時系列にする

両者を組み合わせる利点は、現在または残存するファイル情報と、過去に生じた変更を突き合わせられることです。

ファイル名だけでなく、参照番号と世代を確認する

同じ名前のファイルが複数あったり、削除後に同名ファイルが作られたりすることがあります。そこで、同一ボリューム上のファイル参照番号や親ディレクトリを確認します。

NTFSの参照情報では、エントリ番号に加えて、再利用を見分けるためのシーケンス番号も重要です。番号の一部だけが一致していても、世代が異なれば以前のファイルとは限りません。FILE_RECORD_SEGMENT_HEADER

架空例：名前変更から削除までを追う

以下は仕組みを説明するための架空例であり、当社の実案件ではありません。 対象は同じNTFSボリュームで、必要なUSNレコードが残り、参照番号・世代・親フォルダの対応も確認できたものとします。時刻は日本時間で統一した例です。

記録上の時刻	確認した記録	言える範囲
09:01	「顧客一覧.xlsx」の作成に関するUSNレコード	そのファイルオブジェクトの作成を示す記録がある
09:12	同じ参照番号に対する旧名・新名の記録。新名は「引継資料.xlsx」	名称変更の流れと整合する
09:15	ファイル名は同じで、旧・新の親ディレクトリを示す記録	同一ボリューム内で保存場所が変わった流れと整合する
09:22	同じ対象の`FILE_DELETE`を含む記録	対象ファイルの削除を示す記録がある

さらにMFTの残存情報と再利用の有無を確認し、名称や親フォルダの対応に矛盾がないかを調べます。USN上の改名・移動と旧・新の親の関係は、Microsoftの仕様にも説明があります。USN_RECORD_V2

この例で裏付けられるのは、ファイルシステム上の変更の流れです。「社員が顧客名簿を隠すために改名し、USBへ持ち出してから消した」とまでは言えません。 内容、転送先、操作者、目的は別に検証します。

なお、表の時刻は各レコードの時刻です。USNに集約された複数の変更を、すべてその瞬間に実行したと読み替えないことも必要です。

別ボリュームへの移動は、同じ追い方ができるとは限らない

同一ボリューム内の移動では親ディレクトリの変化が手掛かりになりますが、PCからUSBなど別ボリュームへの移動は事情が異なります。

例えば、WindowsのMoveFileExでは、所定のオプションで別ボリュームへファイルを移す際、コピーと削除で移動を実現します。人には一回の「移動」に見えても、元と先では別の変更として調べる必要があります。MoveFileExA

保存先でファイルが作られ、元で削除されているだけでは、その二つが一回の移動で結び付くとは限りません。対象ファイル、時系列、内容、使用アプリなどを照合します。

コピー・閲覧・操作者について、追加で何を見るか

コピー先の作成記録だけでは、コピー元は決まらない

MFTやUSNジャーナルは、すべてのコピーについて「AからBへコピーした」と直接示す万能ログではありません。

コピーを検証する場合は、コピー元・先の実ファイル、サイズ、内容のハッシュ値、作成・変更の記録、外部媒体の識別情報、LNK・Jump Lists、取得済みのDLPやクラウドのログなどを組み合わせます。

例えばPCとUSBに内容が同じファイルがあっても、内容の一致だけでは、コピーの方向、時刻、操作した人物まで決まりません。 両方が別の共通の場所から取得された可能性も検討します。

USB接続の有無、同時間帯のファイル操作、USB本体の内容などをどのように組み合わせて評価するかについては、USBメモリの接続履歴を調査｜ファイルコピー・情報持ち出しの痕跡で詳しく解説しています。

MFT・USNだけではコピー元とコピー先の関係を確定できないため、ファイルコピーを調べる際の証拠の組み合わせについては、Windowsでファイルコピー履歴は分かる？USBへのコピー痕跡と調査方法も参照してください。

「開いた」「読んだ」は、変更記録とは別の課題

ファイルの作成や属性変更があっても、本人が文書本文を読んだことの証明にはなりません。アクセス時刻も、アプリケーションによる処理や更新の条件を考慮する必要があります。File Times

閲覧を調べる場合は、ユーザーごとのLNK、Jump Lists、Recent Files、Officeの最近使ったファイル情報などが確認対象になります。ただし、それらについても、生成された理由を確認し、本文の閲読やコピーまで結論を広げないようにします。

LNKファイルやJump Listsなど、Windowsに残るファイル利用・閲覧の痕跡については、Windowsでファイルを開いた履歴は分かる？LNK・Jump Listsの調査方法で詳しく解説しています。

誰が操作したかは、ユーザー・プロセスの記録と照合する

MFTやUSNは主にファイルシステム側の情報です。USNにあるSecurityIdも、操作した社員の名前を直接記録する欄としては扱えません。USN_RECORD_V2

操作者を評価する場合は、Windowsログオン、対象ユーザーの利用痕跡、プロセス情報、端末割当、共用・遠隔操作の有無などを照合します。

例えば、ファイルアクセス監査のイベント4663には、アカウント、対象、プロセス等の情報があります。ただし、必要な監査設定等の条件を満たす場合に生成されるもので、今から設定して過去の監査ログを作れるわけではありません。Microsoft：イベント4663

アカウントを特定できても、共用や第三者による利用の可能性があれば、本人操作とは区別して評価します。

削除の痕跡は、いつまで残るのか

MFTにもUSNにも、全PC共通の保存日数はない

USNジャーナルは容量等に応じて管理されます。Microsoftは、領域を確保するために古いレコードが削除される場合があると説明しています。Change Journal Records

保持範囲は、最大サイズの設定だけでなく、変更の発生量、削除・再作成の有無などにも左右されます。「必ず30日分」「PC購入時から全部」といった保持範囲は保証できません。管理上の目標最大サイズと割り当て単位があり、単純な日数制のログではないためです。Creating, Modifying, and Deleting a Change Journal

MFTの削除済み情報も、エントリの再利用等に左右されます。記録がないときは、操作がなかったのか、対象期間が残っていないのか、取得・解析の範囲が足りないのかを区別します。

削除ファイル名の確認と、ファイル本体の復元は別

MFTやUSNに削除されたファイル名が残っていても、その内容まで復元できるとは限りません。逆に、現在のMFTに対象情報がなくても、残存するUSNから過去の名称や変更を調べられる場合があります。OSForensics：$UsnJrnl Viewer

削除を調べる際は、ごみ箱の記録、LNK・Jump Lists、保存されているバックアップやVSS等の過去状態も、利用できる範囲で照合します。ごみ箱への移動と、その後の削除を同じ一つの時点として扱わないことも大切です。

削除や保存領域の解放で利用できなくなったUSN記録についても、復元を保証することはできません。以前に取得したジャーナルや、関連データを含む過去の保全物があれば比較します。記録が残っていない部分を、現在のMFTだけで完全に埋めることはできません。

初期化後・SSDでも、条件ごとに判断する

初期化、OS再インストール、再利用後は、MFTやUSNの状態が変化している可能性があります。何を初期化したか、どの方式だったか、その後どの程度書き込まれたかを確認します。「初期化後でも必ず分かる」「何も残らない」のどちらとも一律には言えません。

SSDかHDDかだけでも結論は決まりません。SSD等では、削除に伴って解放された領域をストレージへ通知するTRIM等も考慮します。ただし、削除された本体の領域と、MFT・USNに残る管理情報は同じものではありません。Microsoft：fsutil behavior

調べる前の保全と、自社確認・専門調査の目安

対象PCに変更を加える前に、知りたい事実を整理する

最初に、対象ファイルの名称・元の保存場所・最後に確認した時期・消失に気付いた時期・端末の利用状況を整理します。初期化や復元ソフトの使用など、すでに実施した操作も日時とともに残してください。

そのうえで、証拠として調べる場合は次を意識します。

対象PCの通常利用や再配布、不要なインストール・クリーンアップを控える
記録を探す目的でUSNジャーナルを削除・再作成したり、容量設定を変えたりしない
PCが停止中なら調査目的だけで起動せず、稼働中なら電源状態・暗号化・必要な記録を踏まえて保全方法を決める
継続中の削除や漏えいがあれば、管理担当者が被害を止める対応と保全を調整し、実施内容を記録する

少し操作しただけですべての痕跡が消えるという意味ではありません。問題は、調査対象だった状態に新たな変更を重ね、過去と現在を区別しにくくすることです。

専門的な保全では、目的に応じてイメージ取得や必要データの収集を選び、取得条件・ハッシュ値・作業記録等を残します。書き込み防止や取得データの整合性確認、電源操作を一律に決めない考え方は、NISTのフォレンジック指針でも扱われています。NIST SP 800-86：4.2節・5.2節

自社で足りるかは、必要な結論から決める

必要な確認	進め方の目安
現在の保存場所や業務用ファイルを見つけたい	管理権限の範囲で、既存のファイル一覧・バックアップ・クラウド版履歴等を確認する
サーバーやクラウド上の変更を確認したい	IT担当者が、当時のログ設定と保存期間、対象アカウント・ファイルを確認する
消えたファイルの名称や、改名・移動・削除の順序を知りたい	対象媒体を保全し、MFT・USN等の解析を検討する
操作者や持ち出し先まで調べたい	端末・媒体・アカウント・周辺システムの証拠を組み合わせる
退職者PCや紛争資料として、第三者へ経緯を説明したい	取得の経緯と解析根拠を残せる専門調査を検討する

単にファイルが見つかれば業務上の目的を満たす場合と、誰がいつ変更したかを立証したい場合では、必要な調査が異なります。