ファイルインデックス破損時の復旧：MFT(Master File Table)解析入門

【注意】 ファイルインデックス破損（NTFSのMFT破損など）が疑われる状況で自己流の修理・復旧作業（chkdsk実行、上書きコピー、初期化、復元ソフトの試行など）を行うと、状態が収束せず悪化して復旧可能性が下がることがあります。まずは書き込みを止めて被害最小化（ダメージコントロール）を優先し、個別案件は株式会社情報工学研究所のような専門事業者へ相談してください（無料相談：https://jouhou.main.jp/?page_id=26983 ／電話：0120-838-831）。

　

第1章：監視アラートより厄介な「ファイルはあるのに開けない」—インデックス破損の初動整理

「フォルダは見えるのに、開くとエラー」「ファイル名は並ぶのに、コピーできない」「容量が0バイトに見える」。このタイプの障害は、アプリの不具合というより、ファイルシステムの“管理情報”が崩れている可能性が高いです。現場だと、原因が見えにくいぶん会話が荒れがちです。

「また障害対応か…。でも今これ以上、余計な作業を増やしたくない」

その気持ちは自然です。ここで必要なのは“英雄的な復旧手順”ではなく、まず状況をクールダウンさせて、悪化要因を止め、次の判断に必要な材料を揃えることです。言い換えると、復旧の前に“被害最小化”の設計を入れます。

---

最初の30秒でやるべきこと（安全な初動ガイド）を、症状別にまとめます。ここでの目的は「直す」ではなく「壊しきらない」ことです。

症状（よくある表示）	まず取るべき行動（被害最小化）	避けるべき行動（悪化要因）
フォルダはあるが開けない／アクセス拒否	対象ボリュームへの書き込みを止める（アプリ停止、同期停止、再起動の連打を避ける）。可能なら別媒体へログ・状況メモを保存。	権限変更の乱発、所有者変更、強制コピーの繰り返し。
0バイト表示／ファイル名だけ見える	対象ディスクの使用を中断し、取得できる範囲でディスクイメージ化の準備（別PC・別媒体）を進める。	復元ソフトを片っ端から試す、同一ドライブに出力する、上書きが発生する操作。
「スキャンして修復しますか？」／chkdsk要求	まず保全（イメージ化・複製）を優先し、修復は検証環境で行う前提に切り替える。	その場でchkdskを実行して“元の状態”を上書きすること。
外付けHDD/SSDが不安定／接続が切れる	ケーブル・ポート変更は最小限にし、通電回数を増やさない。可能なら読み取り中心の取得手順へ。	抜き差しの連打、ベンチマーク、長時間のフルスキャンを何度も回す。
サーバ/共有フォルダで多数ユーザが影響	共有の書き込みを一時停止し、影響範囲（どのボリューム／どの共有）を切り分けて通知。ログ保全。	「とりあえず再起動」で状態が変わることに賭ける運用。

---

この表の意図はシンプルで、状態を“収束”させる方向に揃えることです。インデックス破損の多くは、追加の書き込み・整合性処理・自動修復の連鎖で、取り返しのつかない差分が積み上がります。復旧の現場では「直ったように見えるが、必要なファイルが欠ける」パターンが最も痛いので、まずは“動かさない設計”へ寄せます。

そして、ここから先は一般論だけでは限界が出ます。ディスクの状態（論理破損のみか、物理障害が混ざっているか）、重要ファイルの種類（DB、VM、CAD、会計、医療画像など）、復旧の優先順位（稼働優先かデータ優先か）で、採るべき手順が変わります。判断に迷う時点で、株式会社情報工学研究所のような専門家に状況を渡して、手順の“歯止め”を掛ける方が結果的に早いことが多いです。

依頼判断の目安（今すぐ相談した方がよい条件）

• 重要ファイルが開けない／0バイト表示など、メタデータ破損が疑われる
• chkdskの実行前で、失敗時の影響を許容できない
• 外付けストレージの接続が不安定で、通電回数を増やしたくない
• サーバ共有で影響が広く、説明責任（監査・顧客影響）が重い

相談先：株式会社情報工学研究所（無料相談：https://jouhou.main.jp/?page_id=26983 ／電話：0120-838-831）

　

第2章：NTFSの“目次”としてのMFT—1つ壊れると全体が迷子になる理由

ここから技術の話に入ります。NTFSで「ファイルはあるのに開けない」が起きるとき、見に行くべき中心がMFT（Master File Table）です。MFTは、ファイルの実体（データ本体）そのものというより、“ファイルという概念を成立させる台帳”の集合です。ファイル名、作成・更新時刻、権限、そしてデータがディスク上のどこにあるか——それらがレコードとして記録され、OSはそれを頼りにアクセスを成立させます。

現場の独り言で言うと、こうです。

「ファイルの中身は残ってそうなのに、住所録が壊れて住所が引けない感じか…」

この感覚はかなり近いです。MFTが壊れると、データ本体が残っていても“辿れない”状態になります。すると、Explorerの表示、APIの戻り値、アクセス権エラー、0バイト表示などがバラバラに出て、原因が散らばって見えます。ここで大事なのは、症状を1つずつ潰すより、台帳のどこが壊れているかを押さえて、全体像を掴むことです。

---

OSがファイルを開くまでにやっていること（ざっくり）

NTFSでファイルを開くとき、OSは概ね次の段取りで情報を辿ります（細部は実装や条件で変わりますが、理解の芯としてはこれで十分です）。

1. ディレクトリ（フォルダ）を辿り、対象の“名前”を探す
2. 名前に紐づく参照情報（MFT参照）を取得する
3. MFTレコードから属性（メタ情報）と、データの配置（クラスタの連なり）を得る
4. 必要なクラスタを読み取り、アプリにデータを渡す

この流れのどこが壊れるかで、見える症状が変わります。たとえば「一覧は出るが開けない」は、(1)は成立しているが(2)(3)が壊れている可能性が上がります。「フォルダが空に見える」は(1)側（ディレクトリインデックス）の破損が疑われます。つまり、同じ“開けない”でも、壊れている層が違うので対処が違う、ということです。

---

MFTレコードの読み方（入門として必要な最小セット）

解析入門として、まず押さえるべきは「MFTレコードに何が入っているか」です。専門ツールや仕様書の細部に踏み込む前に、設計思想だけ理解すると、復旧判断がぶれにくくなります。

要素	役割	壊れると起きがちなこと
参照（レコード番号等）	ファイルを一意に指すキー。名前やパスから最終的に辿り着く“ID”。	別ファイルを指してしまう／参照不能で開けない。
属性（標準情報・ファイル名・データ等）	タイムスタンプ、名前、実体データの説明など、ファイル成立に必要な情報群。	名前は見えるが権限やサイズが不正／メタ情報が破綻。
データ配置情報（Runlist等）	データ本体がディスク上のどこに並んでいるかを示す地図。	0バイト表示、読み取りエラー、途中までしか復元できない。

ここで重要なのは、MFTが“データ本体の箱”というより、“データへ辿り着くための設計図”であることです。設計図が壊れていると、復旧の作業は「修理して元に戻す」より「残っている情報から再構成する」寄りになります。だからこそ、最初の章で書いた通り、対象へ書き込む行為は控え、まず観測対象を固定する（イメージ化する）方向が合理的になります。

個別案件では、障害が論理破損だけか、物理障害が混ざっているかで、取れる選択肢が大きく変わります。一般論で進めるほど“やった操作の分だけ状態が変わる”ので、MFTが疑わしい時点で、株式会社情報工学研究所のような専門家に状況を共有して、作業のブレーキを掛ける判断が現実的です。

　

第3章：典型症状で切り分ける—アクセス拒否・0バイト・フォルダ消失・chkdsk要求

ここでは、現場で遭遇しやすい症状を「どの層の破損が疑わしいか」という観点で整理します。目的は、復旧作業そのものを急ぐのではなく、判断を誤って“状態が変わる操作”を積み上げないことです。復旧の成功率は、テクニックより先に、最初の判断の精度で決まります。

---

症状は「見え方」であり、原因ではない

まず前提として、Explorerの表示やエラーメッセージは“症状の一断面”です。表示はキャッシュ、権限、ネットワーク、フィルタドライバ、ウイルス対策ソフトなどの影響も受けます。したがって、単一の症状から断定せず、複数の観測点（別PC、別アカウント、別プロトコル、イベントログ、S.M.A.R.T.、ボリューム状態）を集めて整合させます。

ただし、緊急時に全部はできません。そこで、典型パターンを「疑う層」と「最初にやること」で束ねます。

典型症状	疑う層（目安）	最初の安全な一手
一覧は出るが開けない／コピー不可	MFT参照・属性・データ配置情報の不整合	書き込み停止→ログ保全→イメージ化の準備
フォルダが空に見える／一部だけ消えた	ディレクトリインデックス（後述の$I30）側の破損	自動修復を避け、検証環境で列挙方法を変えて確認
0バイト表示／サイズ・日付が不自然	メタデータ（属性）破損、または配置情報の欠落	対象ボリュームでの追加操作を止め、出力先は別媒体へ
chkdskを促す表示／整合性チェック要求	ファイルシステム整合性の破綻（修復で状態が変わる）	まず保全。修復は“元に戻る”作業ではない前提で判断
接続が切れる／読み取りが極端に遅い	物理障害が混在する可能性（論理破損だけと決めない）	通電回数を増やさず、取得優先の方針へ切り替え

---

「修復」と「復旧」を分けて考える理由

ここで一番伝えたいのは、修復（整合性を取る）と、復旧（必要なデータを取り出す）は目的が違うということです。修復はファイルシステムを“使える形”に整える行為で、整合性のためにリンクの付け替えや再配置が起きえます。一方、復旧は“必要なデータを安全に確保する”行為で、状態変化を最小にする方が筋が通ります。

現場だと、こういう葛藤が出ます。

「直せばサクッと戻るなら直したい。でも、その直す操作で消えたら説明できない」

この迷いは、責任ある人ほど持ちます。そして健全です。だからこそ、まずはクールオフして、状態を変える操作（その場のchkdsk、同一ドライブへの書き込み、復元ソフトの乱用）を止める。そのうえで、保全→解析→復旧（必要なら修復）の順に並べ替えます。

---

この章の結論：一般論で踏み抜くポイントは決まっている

典型的に踏み抜くのは次の3つです。

• 同一ディスクへ出力する（復元先に同じボリュームを選ぶ）
• 自動修復を“戻るボタン”のように扱う（修復が状態を変えることを軽視する）
• 物理障害の混在を見落とす（遅い・切れる・異音などを軽視する）

この3つを避けるだけでも、復旧可能性は保ちやすくなります。ただし、どこまでが論理破損で、どこからが物理障害か、どのデータを優先するかは個別条件で変わります。案件・契約・システム構成が絡むほど、一般論の限界が早く来ます。迷った時点で、株式会社情報工学研究所のような専門家に状況を渡し、判断の“歯止め”を掛けるのが合理的です。

　

第4章：まず守るべき原則—書き込み停止→イメージ化→検証環境で作業する

インデックス破損（MFT関連）が疑われる局面で、最初にやるべきことは「復旧を始める」ではなく「状態を落ち着かせる」です。具体的には、対象ボリュームへの追加書き込みを止め、観測対象を固定し、検証環境で作業できる形に整えます。ここがぶれると、状況が収束せず、後から説明も復旧も難しくなります。

---

原則1：書き込みを止める（被害最小化のための歯止め）

Windowsやサーバは、ユーザーが何もしなくてもバックグラウンドで書き込みが発生します。インデックス破損時は、その“自然な書き込み”が復旧難易度を上げることがあります。次の観点で「止める対象」を整理します。

• 同期・バックアップ：クラウド同期、バックアップエージェント、レプリケーションを一時停止する
• アプリ：DB、仮想化、ログ集約、スプールなど、書き込みが多いプロセスを停止する
• 共有：SMB共有の書き込みを止める（読み取りも最小限にする）
• 自動修復：OSのスキャン・修復や整合性チェックの自動実行を避ける

「止めたら業務が止まる」という事情は現場では普通にあります。その場合も、まずは“どこまで止めれば状態が落ち着くか”の最小ラインを決めるのが実務的です。全停止が無理でも、書き込みのピークを抑えるだけで、後工程の見通しが大きく変わります。

---

原則2：イメージ化で観測対象を固定する（ダメージコントロールの核）

復旧判断を設計に寄せるなら、イメージ化（複製・取得）が基準点になります。理由は単純で、原本に対して試行錯誤すると「やった操作の分だけ状態が変わる」ためです。イメージ化してしまえば、解析・抽出・検証を繰り返しても、原本の状態をこれ以上動かさずに済みます。

イメージ化では、次の2点が現場で重要になります。

• 出力先は必ず別媒体：同一ボリュームへの出力は上書きのリスクを持ちます
• 取得の完全性を残す：ハッシュ（例：SHA-256等）や取得ログ、日時、機材、担当を記録し、後から説明できる形にする

---

「原本・複製・検証」の役割分担（やってよい作業／避ける作業）

作業対象	目的	やってよい作業	避ける作業
原本（障害発生媒体）	現状維持（証拠・状態の固定）	最小限の観測（必要情報のメモ、ログ採取、読み取り中心の取得準備）	chkdsk実行、復元ソフト試行、同一ドライブへのコピー、再フォーマット
複製（クローン／イメージ）	解析・復旧の作業台	解析、ファイル抽出、整合性検証、必要に応じた修復の“試験”	結果を原本へ戻して“上書き反映”する運用
検証環境（別PC／隔離VM）	安全な試行錯誤	ツール検証、手順の再現、復旧データの整合チェック	業務本番に直結する状態での無計画な操作

---

原則3：物理障害の混在を前提にする（“遅い・切れる”は軽視しない）

インデックス破損は論理破損の話に見えますが、現場では物理障害（読み取り不良、接続断、極端な遅延）が混ざることがあります。ここを見落とすと、イメージ化やスキャンで読み取り負荷をかけ続け、状況が悪化しやすいです。特に「接続が切れる」「読み取りが一定周期で止まる」「異常に時間がかかる」などの兆候がある場合は、取得優先の方針へ早めに切り替えるのが現実的です。

---

この章の結論は、復旧を“作業”ではなく“設計”にするための土台は、書き込み停止→イメージ化→検証環境という順で場を整えること、という点です。個別案件では、停止できる範囲、重要データの種類、監査・説明責任、期限などの制約で最適解が変わります。ここから先は一般論だけで突っ走るほどリスクが上がるため、状況整理の時点で株式会社情報工学研究所のような専門家へ相談し、判断の歯止めを掛けるのが合理的です。

　

第5章：MFTレコード入門—FILEシグネチャ／参照番号／属性／Runlistの読み方

MFT解析と聞くと、いきなりバイナリの海に見えますが、復旧判断に必要なのは「何を見れば、何が分かるか」の道筋です。この章では、MFTレコードを読むときの基礎要素を、現場で役立つ粒度に絞って整理します。目的は、ツールの出力を“眺める”から“根拠として使う”に変えることです。

---

レコードの入口：FILEシグネチャと整合の前提

多くの解析ツールは、MFTレコードの先頭にあるシグネチャ（いわゆる「FILE」）を手掛かりにレコードを認識します。ここが崩れている場合、ツール側で「レコードが壊れている／未割当として扱う」といった判断になりやすく、同じ媒体でもツール差で見え方が変わることがあります。つまり、ツールの結果が食い違うときは“どの前提でレコードを有効とみなしているか”を疑うのが筋です。

---

参照番号とシーケンス：リンクがズレると起きること

NTFSでは、ディレクトリからファイルへ辿る際に「MFT参照」が使われます。参照にはレコード番号だけでなく、再利用時のズレを検知するための情報（シーケンス番号等）が関わります。ここが壊れると、次のような症状が起きやすくなります。

• 同名ファイルの扱いが不安定になる（見える／見えないが揺れる）
• “別のものを指してしまう”リスクが上がる（整合性エラー、アクセス不可）
• 復元ソフトでファイル名やパスが崩れる（番号ベースでの抽出になる）

現場では「ファイルが消えた」のではなく「参照が破綻した」ケースが混ざるため、ここを見落とすと判断がぶれます。

---

属性（Attributes）：何が“ファイル”を成立させているか

MFTレコードの中身は属性の集合です。入門として押さえるべきは「標準情報」「ファイル名」「データ」の3系統です。これらが揃って初めて、OSは“それっぽいファイル”として扱えます。

属性の種類（代表例）	含まれがちな情報	壊れると起きがちなこと
標準情報	作成・更新時刻、フラグ、基本メタ情報	日時が不自然、属性情報の不整合が増える
ファイル名	名称、親ディレクトリ参照、名称の複数候補	パス崩れ、別名で出る、ディレクトリから辿れない
データ	実データの位置情報（後述Runlist）や、常駐データ	0バイト表示、読み取り失敗、途中欠損

---

常駐（Resident）と非常駐（Non-resident）：復旧の難易度が変わる分岐点

データ属性は、内容が小さい場合に「MFTレコード内に格納（常駐）」されることがあり、一定以上になると「クラスタ上に配置（非常駐）」されます。この違いは復旧に直結します。

• 常駐：レコードさえ読めれば内容を取り出しやすい（ただしレコード破損で失われる）
• 非常駐：レコードにある“配置情報”が鍵になる（配置情報が壊れると復旧が難しくなる）

「ファイル名は見えるが中身が取れない」ケースでは、非常駐データの配置情報が壊れている可能性が高く、ここでRunlistの読みが重要になります。

---

Runlist：データの“地図”を読む（断片化と欠損の扱い）

非常駐データでは、データがディスク上のどこにあるかをRunlist（クラスタの連なり）で表現します。断片化があるとRunlistは複数区間になり、読み取りはその区間を順番に辿る必要があります。復旧では次の視点が要点です。

• Runlistが読めるか：配置情報が欠けると、データ本体が残っていても辿れない
• 区間の数：断片化が激しいほど、欠損時の再構成が難しくなる
• 読み取りエラーの位置：物理障害が混在すると、特定区間で読めないことがある

この段階で「ツールが復元できた／できない」を鵜呑みにせず、“配置情報がどうなっているか”を見に行くと、次の手が設計しやすくなります。

---

この章の結論は、MFT解析の価値は「レコードが読める／読めない」ではなく、「参照・属性・Runlistのどこが壊れていて、何が残っているか」を言語化できる点にあります。ここまで言語化できると、復旧の方針（抽出優先か、修復を試すか、物理障害の可能性を上げるか）がブレにくくなります。個別案件では、重要データ（DBやVMなど）の配置や断片化で判断が変わるため、状況が複雑な時点で株式会社情報工学研究所のような専門家に相談し、解析結果の読み違いを防ぐのが現実的です。

　

第6章：伏線① $MFTMirrの役割—“戻せる破損”と“戻せない破損”の境界

ここからが「伏線」の1つ目です。NTFSには、MFTが壊れたときに手掛かりになる冗長情報が用意されています。その代表が$MFTMirrです。$MFTMirrは、MFTの先頭付近の重要レコードを複製して保持する領域で、主に“MFTの位置や初期レコードが壊れたときにMFTへ辿り着く”ための支えになります。

---

$MFTMirrが何をミラーしているか（入門としての要点）

$MFTMirrは、一般にMFTの先頭の一部（重要レコード群）を複製します。これにより、ボリュームの先頭側が損傷してMFT本体の先頭が読めない場合でも、ミラー側から復旧の足場を作れる可能性があります。ここで大事なのは、$MFTMirrは“全MFTの完全バックアップ”ではない、という点です。したがって、広範囲のレコード破損や、後半の論理破損を直接直す用途には向きません。

---

ブートセクタとバックアップ：MFTに辿るための2つの錨

NTFSでは、ブートセクタにMFTや$MFTMirrの位置情報が含まれます。さらに、ブートセクタ自体にもバックアップが用意されることがあり、位置情報の“入口”を取り戻せる場合があります。復旧設計としては、次のように「入口が壊れているのか」「入口はあるが中身が壊れているのか」を分けると整理しやすいです。

壊れている可能性が高い場所	見えがちな症状	手掛かり（観測ポイント）
ブート情報（入口）	ボリューム認識が不安定、マウントできない、異常な容量表示	ブート情報の整合、バックアップ側の存在、MFT位置情報の妥当性
MFT先頭レコード	ファイルシステムとしての一貫性が崩れる、整合性チェック要求	$MFTMirrの読める範囲、先頭レコードの整合
MFT後半・個別レコード	特定フォルダ・特定ファイルだけ開けない、0バイト表示が混在	該当レコードの属性とRunlist、ディレクトリインデックスとの整合

---

“戻せる破損”の条件：冗長情報が読めること

$MFTMirrが効くかどうかは、結局「読める冗長情報が残っているか」で決まります。論理破損だけなら、ミラー側が有効なケースがあります。一方、物理障害が混在していてミラー領域も読めない、あるいは読み取りエラーが散発している場合は、冗長情報に頼れず、取得優先の方針へ寄せる必要が出ます。

現場の本音で言うと、こうです。

「“直せる”に賭ける前に、“読めるか”を確かめたい」

この順番が重要です。直す行為（修復）は状態を変えます。読めるかどうか（観測）を先に確かめ、その結果に基づいて方針を決める。これが復旧の軟着陸につながります。

---

この章の結論は、$MFTMirrは“復旧の万能薬”ではなく、“入口と足場の確保”に効く冗長情報であり、読める冗長性が残るかどうかが分岐点になるということです。ここから先は、個別の破損箇所（ディレクトリインデックス側など）との組み合わせで判断が変わります。状況が複雑なほど一般論は外れやすいので、方針を決める段階で株式会社情報工学研究所のような専門家に相談し、無駄な試行で状況を揺らさない判断が現実的です。

　

第7章：伏線② インデックス($I30)の正体—「一覧できる」と「参照できる」は別物

MFTが“台帳”なら、ディレクトリ（フォルダ）のインデックスは“索引”です。NTFSでは、ディレクトリ配下のエントリを効率よく列挙するためにインデックス構造が使われ、その実体が一般に$I30として表現されます。ここが壊れると、ファイル自体やMFTレコードが残っていても、フォルダの一覧として出せなくなります。つまり「存在しているのに見えない」「空に見える」が起きます。

この違いが現場では混乱の元になります。

「見えないなら消えた？ でも容量は減ってない。どっちなんだ…」

結論から言うと、“一覧できない”と“参照できない”は別問題です。インデックスは一覧のための仕組みなので、ここが崩れると表示が崩れます。一方、MFT側の参照やRunlistが生きていれば、別経路で辿れてデータが取れることもあります。逆に、一覧が見えていても参照が壊れていれば開けません。ここを分けるだけで、復旧の設計が一段クリアになります。

---

$I30の破損で起きがちな現象（実務の見え方）

• フォルダが空に見える（配下が列挙できない）
• 一部のファイルだけ見えない／見えるものが不自然に偏る
• 検索やインデックスが異常に遅い（列挙処理が再試行・失敗を繰り返す）
• 整合性チェック要求が出やすい（ディレクトリ構造の不整合）

ただし、これらは$I30“だけ”が原因とは限りません。MFT側の参照不整合や物理障害でも似た見え方になります。重要なのは、症状の「見え方」から断定せず、どの層が壊れている可能性が高いかを、観測点を増やして評価することです。

---

“見える経路”を変えて確認する（安全な切り分けの考え方）

一覧と参照の分離を確認するには、同じデータを“別の経路”で見に行くのが有効です。ここでの目的は、対象をいじって直すことではなく、壊れている層を推定して復旧手順の順序を決めることです。

観測の切り口	何を見ているか	判断のヒント
フォルダ一覧（GUI）	ディレクトリインデックス中心	空に見える・一部欠けるなら$I30側の可能性が上がる
別手段での列挙（ツール差）	列挙ロジックや前提が異なる	ツールによって見え方が違うならインデックス破損の疑い
MFTベースの探索	ディレクトリを経由せず、レコードから辿る	一覧できなくてもレコードが見えるなら“存在はある”側に寄る
ファイル実体の抽出	Runlist等でデータ本体にアクセス	参照が崩れていても、実体が取れる場合がある

---

インデックス破損でやりがちな失敗（状況を揺らす操作）

ディレクトリが空に見えると、人は“直して見えるようにしたく”なります。そこで状態を揺らす操作を入れると、後から復旧根拠が薄くなります。典型的には次のような動きです。

• 「表示がおかしいだけだろう」と同一ボリュームへファイルを作成・移動してしまう
• 整合性ツールで“直った表示”を優先し、必要ファイルの欠落に後から気づく
• 復元ソフトの出力先を同一ドライブにして、上書きが混ざる

インデックス破損では、見え方を直すより先に、必要データを確保する方が筋が通ります。見え方を直す行為は、状況が収束する方向にも悪化する方向にも働き得るため、方針としては“確保→検証→必要なら修復”の順に寄せた方が安全です。

---

この章の結論は、ディレクトリインデックス（$I30）は「一覧」のための仕組みで、一覧できないことは必ずしも実体消失を意味しない、という点です。逆に、一覧できても参照が壊れていれば開けません。この分離ができると、復旧の順番（列挙の修復を急がない、抽出優先で進める）が組み立てやすくなります。個別案件では、どの列挙手段が有効か、どのデータが優先かで手順が変わるため、迷いが出た時点で株式会社情報工学研究所のような専門家へ相談し、判断の歯止めを掛けるのが現実的です。

　

第8章：解析フロー—MFT健全性チェック→欠損推定→復元候補の抽出まで

ここからは、解析を“作業手順”としてではなく、“意思決定フロー”として整理します。現場で求められるのは、完璧な解析より、期限とリスクの中で最適な手を選ぶことです。解析の出力は「今やるべきこと」を決めるための材料であり、材料が揃った段階で方針を収束させるのがゴールになります。

---

ステップ0：目的と優先順位を固定する（議論が過熱する前に）

解析に入る前に、目的を1行で固定します。これをやらないと、解析途中で「復旧より稼働」「稼働より証拠」「証拠よりとにかく直せ」が行ったり来たりし、場が整いません。

• 最優先は何か（例：特定フォルダのデータ確保、稼働復旧、監査対応）
• 許容できないことは何か（例：上書き、欠損、タイムスタンプ改変）
• 期限はいつか（例：今夜中、週末まで、月末監査前）

この3点が揃うだけで、解析の深さと順番が自然に決まります。

---

ステップ1：観測対象の固定と取得の妥当性確認

イメージ化できている場合は、そのイメージが解析対象です。取得ログ、取得日時、対象範囲（ディスク全体かパーティションか）、ハッシュ等の記録があると、後から「何を根拠に判断したか」を説明できます。取得が不完全（途中で失敗、切断が多い、読み取りエラーが大量）なら、解析結果に“穴”がある前提で進める必要があります。

---

ステップ2：MFTの入口が健全か（辿り着けるか）

まずはMFTへ辿り着けるかを確認します。入口が壊れている場合、個別ファイルの解析以前に、ファイルシステム構造の把握が不安定になります。ここで観測するのは「MFTの位置情報の妥当性」「先頭レコードの整合」「冗長情報（$MFTMirr等）の読める範囲」です。

観測項目	見る理由	次の打ち手の分岐
MFT先頭の読める範囲	レコード認識の土台が崩れていないか	崩れていれば冗長情報の確認へ
$MFTMirrの可読性	入口の足場を作れるか	読めれば“入口回復”の可能性が上がる
読み取りエラー分布	物理障害混在の疑い	広がるなら取得優先へ寄せる

---

ステップ3：MFTレコードの健全性チェック（残っている情報を見積もる）

MFTの入口がある程度読めるなら、次にレコードの健全性を見積もります。ここでは“全件を完璧に”ではなく、重要領域（対象フォルダ、対象期間、重要拡張子等）に絞って、どの属性が残っているかを確認します。

• ファイル名属性が残っているか（パス復元の見込み）
• データ属性の配置情報が読めるか（実体抽出の見込み）
• 常駐データの割合（小ファイルは救いやすい可能性）
• 断片化の度合い（Runlist区間が多いほど難易度が上がる）

---

ステップ4：欠損推定（何がどれだけ欠けているか）

復旧の現場では「全部戻るのか」が最初に問われます。しかし、現実には“欠ける可能性の説明”が重要です。欠損推定は、失敗の言い訳ではなく、復旧方針を収束させるための材料です。

欠損推定の観点は次の通りです。

• 読み取りエラーが集中している領域があるか（物理障害・一部欠損の可能性）
• 重要ファイルがその領域に載っているか（Runlistで位置を推定）
• インデックス（$I30）側の破損で“見えないだけ”の範囲があるか
• タイムスタンプやサイズが不自然な群があるか（属性破損の疑い）

---

ステップ5：復元候補の抽出（優先順位で救う）

欠損推定ができたら、復元候補を“優先順位順に”抽出します。現場では全量復旧より「業務が前に進む最小セット」の価値が高い場面が多いからです。抽出は次の切り口で行うと、説明もしやすくなります。

• 業務優先（例：会計データ、顧客データ、設計データ、DB）
• 期限優先（例：本日締め、監査提出、顧客報告）
• 復旧容易性（例：常駐データ、小さなファイル、断片化が少ないもの）

抽出したデータは、必ず別媒体へ出力し、整合性（開けるか、アプリで読めるか、ハッシュ一致等）を検証して“使える”状態まで落とします。ここで初めて、状況が収束しやすくなります。

---

この章の結論は、解析の価値は「原因究明」より「方針を決めて状況を収束させる」ことにある、という点です。目的の固定→入口確認→残存見積もり→欠損推定→優先抽出、という順に並べると、議論が過熱しにくく、判断がぶれにくくなります。個別案件では、重要データの種類、期限、説明責任、物理障害の混在で最適解が変わるため、ここで迷った時点で株式会社情報工学研究所のような専門家に相談し、判断の歯止めを掛けるのが現実的です。

　

第9章：導入・検討のハードルに正面から答える—「復旧手順を標準化したい」現場の現実

ここまで読むと、頭では分かっても、現場の感情としてはこうなりがちです。

「理屈は分かる。でも毎回イメージ化？ そんな時間も人手もない。結局、現場にしわ寄せじゃない？」

この疑いは健全です。復旧や保全の話は、きれいな理想論に寄せるほど、現場の運用に跳ね返ります。だからこの章では、あえてハードルを“現実のコスト”として並べ、どう設計すれば軟着陸できるかを整理します。狙いは、完璧主義を捨てて「続く仕組み」に寄せることです。

---

ハードル1：時間がない（止められない・待てない・期限がある）

ファイルインデックス破損は、障害そのものより「説明・判断・調整」に時間が溶けます。原因が見えにくく、対応が割れやすく、議論が過熱しやすいからです。ここで有効なのは、作業手順より先に“判断の型”を作ることです。

たとえば、次の3つを最初に固定すると、時間の浪費が減ります。

• 復旧の優先順位（例：顧客提出物、会計、設計、DB、VMの順）
• 許容できないこと（例：上書き、タイムスタンプ改変、欠損の隠蔽）
• コミュニケーションの最小セット（誰に何をいつ伝えるか）

「復旧は技術、現場は根回し」と分けたくなりますが、実際は一体です。型があるだけで、“やること”が早く収束します。

---

ハードル2：人がいない（属人化している・夜間がつらい）

復旧対応がつらいのは、経験値が必要なのに、経験値が溜まる前に担当が燃え尽きるからです。ここで現場が求めているのは「誰でも同じ復旧ができる」ではなく、「誰がやっても悪化させにくい」ことです。

そのために効くのは、難しい手順の教育より先に、次の2つの“禁止ライン”を共有することです。

• 同一ボリュームへの書き込みが発生する操作を避ける（出力先・修復・自動処理）
• 状態が揺れる操作を増やさない（再起動の連打、スキャンの乱発、ツールの試行錯誤）

この2つを押さえるだけで、復旧可能性の下振れを抑えられます。教育としてもシンプルで、運用に落ちやすいです。

---

ハードル3：機材がない（イメージ取得のための余裕がない）

イメージ化の理屈は正しくても、現場では「受け皿がない」「容量がない」「ネットワークが細い」という壁に当たります。ここは“最初からフル装備を目指さない”方が軟着陸します。

段階的には、次の順で整備すると現実的です。

1. 最小セット：外付けの安全な保管先（十分な容量）と、取得ログのテンプレ
2. 標準セット：検証用PC（隔離できる）と、取得・検証のチェックリスト
3. 強化セット：複数媒体の並列取得、エラー耐性のある取得フロー、保管・持ち出し管理

最小セットでも、「原本を揺らさない」文化が作れれば、復旧の成功率は上がります。

---

ハードル4：社内調整が重い（説明責任・監査・顧客影響）

インデックス破損は、技術より説明が難しい障害です。「ファイルはあるのに開けない」「一覧は出るのに中身が取れない」など、直感に反します。説明が難しいと、現場は“いったん直してから報告したい”方向に寄りますが、そこで状態を揺らす操作が入りがちです。

このギャップを埋めるには、説明の言葉を先に用意しておくのが効きます。たとえば、次のように言語化します。

• 「データ本体が消えたとは限らないが、参照情報が崩れて辿れない可能性がある」
• 「修復は状態が変わるため、先に必要データの確保を優先する」
• 「確保と検証ができるまで、復旧完了とは言えない」

この3文があるだけで、“直す前に確保”の方針が通りやすくなります。

---

一般論の限界と、外部専門家を挟む意味

ここまでのハードルは、運用設計でかなり緩和できます。しかし、個別案件になると、一般論では決められない分岐が必ず出ます。たとえば次のような分岐です。

• 物理障害の混在が疑われる（遅い・切れる・エラーが散る）
• 重要データがDB/VM/暗号化領域など、抽出と検証が重い
• 欠損が許容できない（契約・監査・顧客影響が大きい）

この局面で“現場だけで抱える”と、判断が揺れて状況が収束しにくくなります。外部専門家を挟む価値は、作業を代行することだけではなく、判断の基準点を置いて、議論が過熱する前に場を整えることにあります。

個別条件を踏まえた復旧方針の設計や、必要データの優先抽出、説明責任を含む進め方に迷う場合は、株式会社情報工学研究所への相談を検討してください（無料相談：https://jouhou.main.jp/?page_id=26983 ／電話：0120-838-831）。

　

第10章：帰結—MFT解析は“復旧テクニック”ではなく、現場を収束させる意思決定の道具

最後に、このテーマの帰結をはっきり置きます。MFT解析は、バイナリを読むこと自体が目的ではありません。目的は、状況が揺れて収束しない現場で「どこが壊れていて、何が残っていて、次に何をすべきか」を根拠を持って決めることです。

「復旧って、結局は運と経験でしょ？」

そう感じたくなる場面はあります。でも、運の比率を下げる方法は確実にあります。書き込みを止める、観測対象を固定する、残っている情報を見積もる、欠損の可能性を説明できる形にする。そして、優先順位で救う。ここまでを“設計”として積み上げると、復旧はギャンブルではなく、ダメージコントロールのプロセスになります。

---

このブログの一本線（書き出し→伏線→帰結）

最初は「ファイルはあるのに開けない」という、現場のモヤモヤから入りました。次に、MFTが“台帳”であり、ディレクトリインデックス（$I30）が“索引”であるという伏線を置きました。そして、$MFTMirrなどの冗長性が効く条件、効かない条件を通して、“戻せる破損”と“戻せない破損”の境界を整理しました。

この流れの先にある結論はこうです。

• 一覧（索引）と参照（台帳）を分けると、症状の見え方に振り回されにくくなる
• 修復より先に確保（抽出と検証）を置くと、状況が収束しやすくなる
• 解析は「原因当て」ではなく「次の一手を決める」ための道具になる

---

小さな一歩—今日から変えられる3つ

大掛かりな仕組みをいきなり作らなくても、今日から変えられることがあります。

1. 禁止ラインを共有する：同一ボリュームへの書き込みが発生する操作を避ける、状態が揺れる操作を増やさない
2. 判断テンプレを用意する：優先順位、許容できないこと、説明の3文（確保優先・修復は状態変化）
3. 検証環境を作る：原本を触らずに試せる場（隔離PC/VM、出力先、ログ雛形）

この3つだけでも、現場の夜間対応は軽くなります。「また面倒が増える」ではなく、「余計な悪化を防ぐ仕組みが増える」方向に寄せられます。

---

一般論の限界—個別案件で分岐が増える瞬間

一方で、ここまでの話は“考え方”としては有効でも、個別案件では分岐が増えます。特に次の条件が絡むと、一般論だけで進めるほどリスクが上がります。

• 物理障害の混在が疑われる（取得中のエラー、接続断、極端な遅延）
• 重要データがDB/VM/暗号化領域など、抽出・検証に専門性が要る
• 欠損や改変が許容できない（契約、監査、顧客影響、法務）

この瞬間に必要なのは、“さらに頑張る”ではなく、“判断の歯止め”です。状況を収束させるために、第三者の基準点を入れる価値が出ます。

---

次のアクション—相談の使い方（押しつけない、でも迷わせない）

「自分で何とかしたい」という気持ちは尊重されるべきです。ただ、インデックス破損は“やるほど状態が変わる”領域でもあります。迷いが出た時点で、いったん状況をクールダウンさせ、専門家に「今やるべきこと／やるべきでないこと」を確認するだけでも、結果が変わることがあります。

具体的な案件・契約・システム構成に紐づく判断が必要な場合は、株式会社情報工学研究所への相談・依頼を検討してください（無料相談：https://jouhou.main.jp/?page_id=26983 ／電話：0120-838-831）。

---

付記：主要プログラム言語ごとの留意点（ログ・復旧・保全の観点）

ファイルインデックス破損の影響は、アプリ側のI/O特性とログ運用に直結します。ここでは、現場でよく使われる言語ごとに「やりがちな罠」と「障害時の寄せ方」を整理します。

言語	やりがちな罠（障害時に悪化しやすい点）	寄せるべき運用（被害最小化）
C / C++	低レベルI/Oでエラー処理が弱いと、部分書き込みや破損状態を“成功扱い”にしやすい。独自バイナリ形式は検証が重い。	書き込みAPIの戻り値・fsync相当の扱いを統一し、障害時はログと対象ファイルの出力先を別媒体へ。検証ツールを事前に用意。
C# / .NET	例外で握り潰すと、ファイルI/O失敗が上位に伝播せず、リトライで状態を揺らしやすい。バックグラウンドタスクが書き込みを継続しやすい。	例外ログを必ず残し、障害時はサービス停止手順をテンプレ化。ログのローテーション先を別ドライブに分離しておく。
Java	大量の小ファイル出力（ログ、キャッシュ）が多いと、障害時に書き込みが止まらず、復旧の邪魔になりやすい。JVM周辺のログが分散しがち。	ログ/キャッシュの配置を分離し、障害時はまず書き込み系プロセスを止める手順を確立。重要データはジャーナリング前提で検証フローを用意。
Python	スクリプトで「とりあえずコピー」「とりあえずスキャン」を回しがちで、同一ボリュームへの出力ミスが起きやすい。ツールチェーンが人に依存しやすい。	出力先の固定（必ず別媒体）をコードと運用で強制。復旧用スクリプトはログと実行条件を必ず保存し、再現可能性を確保。
Go	並列I/Oが強いぶん、障害時に同時アクセスが増えて状況を揺らしやすい。エラーハンドリングが統一されていないと挙動が割れる。	障害時の同時実行数を制限し、I/O失敗を即座に上位へ伝播する方針に統一。ログ出力先と重要データ領域を分離。
Node.js / TypeScript	非同期処理で失敗が表面化しにくいと、再試行が積み重なり、アクセスが増える。ビルド成果物やキャッシュが大量に生成されやすい。	障害時はプロセス停止と書き込み抑制を優先。キャッシュや一時出力を重要データと別ボリュームに逃がし、ログを集中管理。
PHP	Webサーバ経由で“気づかない書き込み”が発生しやすい（セッション、アップロード一時ファイル、ログ）。共有ストレージでは影響範囲が広がる。	セッション・アップロード・ログの配置を分離し、障害時は書き込み経路（Web/バッチ）を止める手順を明確化。バックアップ/復旧の検証を定期化。
Ruby	運用が属人化しやすく、障害時の手順が口伝になりがち。ログとテンポラリが肥大化すると、障害時の負荷が増える。	手順をテンプレ化し、障害時の最小停止範囲を明文化。ログ/テンポラリの配置とローテーションを整理し、検証環境を用意。
Rust	堅牢に作りやすい一方、障害時の周辺運用（ログ、デプロイ、ストレージ設計）が追いつかないと、復旧判断が属人的になりやすい。	アプリ外側（ログ、ストレージ分離、監視）の設計を先に固める。障害時は取得・検証フローを最優先し、状態を揺らす操作を避ける。

言語やフレームワークが違っても、障害時に効く原則は同じです。書き込みを止め、観測対象を固定し、確保と検証を優先する。個別案件では、システム構成や契約要件で最適解が変わるため、判断に迷う段階で株式会社情報工学研究所のような専門家に相談し、状況を収束させる方向へ寄せるのが現実的です。