診断マトリクス：セーブデータ破損の症状とデータ復旧の実現性
PCゲームで長時間のプレイデータが突然「セーブデータが破損しています」と表示されて読み込めなくなる悲劇は、書き込み処理中の異常終了によって引き起こされます。
| 破損の兆候・エラー表示 | 根本的な技術的原因 | ファイルシステムの実態 | 復旧の可能性と手順 |
|---|---|---|---|
| ロード時に「破損のため読み込めません」と表示 | 保存中の電源断やクラッシュによる終端データ欠落 | データ本体は残存、チェックサム（ハッシュ）不一致 | 極めて高い（同階層の .bak ファイルで復元） |
| ファイルサイズが完全に「0 KB」になっている | ファイル生成直後に書き込みが行われずプロセス停止 | エントリのみ存在し、データセクタの中身が空白 | 中（Windowsの「シャドウコピー」から復元） |
| クラウド同期の競合で古いデータに上書きされた | ローカルとクラウドのタイムスタンプ不整合 | 最新データが上書きされたが、一時領域に残存 | 極めて高い（Steamの userdata 内部から救出） |
| ロードは可能だがキャラがマップ外に落ちる等 | ゲーム内スクリプト変数の論理的破綻 | ファイル構造は正常だが、内部の座標配列が破損 | 低（専用のセーブエディター等による修正が必要） |
安全な保存を実現する「アトミック書き込み」と隠れたバックアップ
多くのゲームエンジンは、既存のセーブデータを直接上書きせず、以下のような安全手順（アトミック置換）を踏みます：
- 一時ファイル（例：
save.dat.tmp）に最新データを書き込む。 - 整合性が確認できたら、既存の正常なセーブデータを
save.dat.bakにリネームして退避。 - 一時ファイルを正式な
save.datにリネーム。
もし書き込み途中でPCが落ちた場合、正式なファイルは壊れていても、直前の完全に正常なデータが .bak や .old という拡張子で同じフォルダにそのまま残されているケースが非常に多いです。
セーブデータ救出の3ステップ
ステップ1：ローカルフォルダ内のバックアップ（.bak）探索
- 一般的なセーブデータ保存先を確認します：
%USERPROFILE%\Saved Games\（保存したゲーム）%LOCALAPPDATA%\[ゲーム名]\Saved\SaveGames\- Steamクラウドローカルキャッシュ：
[Steam導入先]\userdata\[ID]\[AppID]\remote\
- エクスプローラーで「ファイル名拡張子」を表示させ、更新日時順にソートします。
.bakや.tmpの拡張子がついた、サイズが正常なファイルを探します。フォルダ全体をバックアップした上で、壊れた本体ファイルを退避させ、.bakファイルの名前を本来のセーブファイル名に変更します。
ステップ2：Windowsのシャドウコピー（以前のバージョン）からの復元
ファイルが0 KBになってしまった場合：
- セーブデータが入っているフォルダを右クリックし、「プロパティ」を開きます。
- 「以前のバージョン」 タブを選択します。
- システムの保護機能によってクラッシュ前の日時の復元ポイントが存在する場合、それを選択して「復元」を実行します。
ステップ3：Hexエディタによるバイナリヘッダーの確認
- フリーのバイナリエディタ（HxDなど）で破損ファイルを読み込みます。
- 先頭16バイト（ヘッダー）を確認します：
- 全てが
00 00 ...で埋まっている場合は完全に消滅しています。 - 先頭に
GVAS（Unreal Engine）等の識別文字列が存在する場合、中身は生きているため、末尾の修復や別スロットへの移植で復旧できる可能性があります。
- 全てが