セーブとシリアライズ/バージョニング

セーブとは何か：実行時状態を永続バイト列へ落とす

横にスクロール

ゲームのセーブは、メモリ上に散らばった実行時状態——プレイヤー座標、インベントリ、クエスト進行、ワールドの改変差分——を、プロセス終了後も残るバイト列へ変換してストレージに書き出す処理です。この「メモリ上の構造をバイト列に落とす」変換がシリアライズ（直列化）、逆にバイト列から構造を復元する処理がデシリアライズです。

本質的な難所は、ゲームの内部データ構造が生ポインタや参照で相互に絡み合っている点にあります。オブジェクトAがオブジェクトBを指すポインタは、次回起動時にはまったく別のアドレスへ配置されるため、そのまま書き出しても意味を持ちません。そこでシリアライズでは、ポインタを識別子（ID・インデックス）へ置き換え、復元時にIDから実体を引き直す（ポインタスワッピング）方式を取ります。参照グラフに循環がある場合は、訪問済みオブジェクトをID管理して二重書き込みと無限再帰を防ぐ必要があります。

シリアライズ形式：テキストとバイナリ、スキーマの有無

シリアライズ形式は大きくテキスト系とバイナリ系に分かれ、さらに「スキーマ（型定義）を持つか」で性質が変わります。

• テキスト形式（JSON・XML・YAML等）: 人間が読め、差分（diff）やデバッグが容易。反面サイズが大きく、パースが遅く、浮動小数点は10進表記で丸め誤差や桁数の問題が出やすい。フィールド名を文字列キーで持つため、キー名を変えない限りフィールドの追加・削除に強い（未知キーを無視しやすい）。
• バイナリ形式（独自バイナリ・Protobuf・FlatBuffers・MessagePack等）: 小さく高速。ただし生の独自バイナリは「何バイト目が何か」を暗黙のレイアウトで決めるため、フィールドを1つ挿入しただけで以降のオフセットが全部ずれ、旧セーブが読めなくなる（スキーマ進化に極端に弱い）。
• スキーマ付きバイナリ（Protobuf・FlatBuffers）: 各フィールドにtag番号（フィールド番号）を振り、番号でフィールドを識別する。これによりフィールド順序に依存せず、未知の番号は読み飛ばせるため、後述する後方・前方互換を構造的に確保できる。FlatBuffersはさらにパース不要（ゼロコピー）でオフセット参照だけで読める設計で、大きなセーブの読み込み遅延を抑えられる。

数値のバイト順（エンディアン）も無視できません。独自バイナリをそのままメモリコピーで書くと、書き出した環境と読む環境でエンディアンが異なる場合に数値が壊れます。クロスプラットフォームで配布するなら、リトルエンディアン等に明示的に正規化して書くか、エンディアン非依存の形式を用います。テキスト形式や整数の可変長符号化（varint）はこの問題を回避できます。

バージョニングとマイグレーション：後方互換の設計原理

ゲームは更新のたびにセーブ構造が変わります。新武器スロット追加、ステータスの内部表現変更、クエストフラグの再編——これらを経ても古いセーブを読めること（後方互換）が、プレイヤー体験の生命線です。中核となる手法がバージョニングです。

ファイルの先頭（ヘッダ）にマジックナンバー（この形式であることの識別子）とスキーマバージョン番号を埋め込みます。ロード時はまずヘッダを読み、記録された版と現行版を比較します。版が古ければ、版ごとのマイグレーション（変換）関数を順に適用し、データ構造を現行版まで段階的に引き上げてから通常のデシリアライズへ渡します。

セーブファイルの典型レイアウト:

  [ magic number ]   例 "TSAV"（形式識別）
  [ format version ] 例 v7（スキーマ版）
  [ flags/length   ] 圧縮有無・ペイロード長など
  [ payload         ] 本体（シリアライズされた状態）
  [ checksum        ] payload に対する CRC32 等

ロード時のマイグレーション連鎖（例: 保存版 v3 を現行 v7 へ）:

  v3 の bytes
    -> migrate_v3_to_v4   フィールド名変更・単位換算
    -> migrate_v4_to_v5   新フィールド追加（既定値を補完）
    -> migrate_v5_to_v6   enum 値の再割り当てを吸収
    -> migrate_v6_to_v7   構造再編（配列 -> マップ 等）
    -> 現行デシリアライザへ

版を1つずつ上げる連鎖マイグレーションには利点があります。N個の過去版があっても変換関数はN個で済み（各隣接版間に1つ）、「v3から直接v7へ」といった全組み合わせ（O(N^2)）の変換を書かずに済みます。各変換は「1つ前の版の構造」だけを知ればよく、テストも局所化できます。

破壊を避けるフィールド進化の原則

後方互換（新しいコードで古いセーブを読む）と前方互換（古いコードで新しいセーブを読む）を両立させるには、フィールドの変更に規律が要ります。

• 追加は安全、削除・改名は危険: フィールド追加は、旧セーブにその値が無いだけなので既定値で補完すれば読める。逆に削除・改名は、旧コードや旧セーブとの対応が崩れる。
• 未知フィールドは無視して保持: 古いコードが新しいセーブを読むとき、知らないフィールドはエラーにせず読み飛ばす。可能ならそのまま保持して書き戻す（passthrough）ことで、古いクライアントが再保存しても新フィールドが消えない。
• 欠損フィールドは既定値: 新しいコードが古いセーブを読むとき、存在しないフィールドは型の既定値（0・空文字・空配列）や意味のある初期値で埋める。「フィールドが在る／欠けている」を区別できる形式（optional・presence bit）だと、既定値と明示的なゼロを取り違えずに済む。
• enumは末尾追加のみ: 列挙値は既存値の番号を変えず末尾に足す。中間に挿入して番号を詰め直すと、旧セーブの数値が別の意味になる。

チェックサムと破損対策：検知と、書き込みのアトミック性

ストレージは万能ではありません。ビット反転、書き込み途中の電源断、セーブ改ざんツール——これらでセーブは壊れます。壊れたデータをそのまま読み込むとクラッシュや進行不能を招くため、検知と予防の両輪が要ります。

検知にはチェックサムを使います。ペイロード全体からCRC32（巡回冗長検査）等の短い値を計算し、ファイル末尾に付けます。ロード時に再計算して一致しなければ破損とみなし、ロードを拒否してバックアップへフォールバックします。CRC32はランダムなビット化けや断片破損の検知に有効ですが、暗号学的なハッシュではなく、改ざん防止にはならない点が重要です。CRCの値はデータから機械的に決まるため、チートツールはデータを書き換えたうえでCRCも計算し直せます。改ざん検知が目的なら、秘密鍵を用いるHMAC（鍵付きハッシュ）でなければ意味がありません（ネットワーク／セキュリティの基礎 も参照）。

破損対策の設計は、次の3層で考えると整理できます。(1) 検知層——チェックサムで壊れを見つける。(2) 予防層——一時ファイル＋renameで書き込み中の全損を防ぐ。(3) 回復層——世代バックアップやクラウド同期で、壊れた最新から過去の健全なセーブへ戻す。オートセーブとクイックセーブでスロットを分け、オートセーブが常に上書きされても手動セーブは残す設計も、実質的な回復層として機能します。

まとめ

ゲームのセーブは、実行時のメモリ状態を永続バイト列へ落とすシリアライズであり、ポインタのID化と「再現不能な進行だけを保存する」切り分けが土台になります。形式はテキスト（可読・大きい・進化に中程度）とバイナリ（小さい・速い）に分かれ、Protobuf／FlatBuffersのようなtag番号ベースのスキーマ付き形式は、フィールド順序に依存せず未知フィールドを読み飛ばせるため後方・前方互換を構造的に確保できます。更新でセーブ構造が変わっても古いセーブを読み続けるには、ヘッダにスキーマ版を埋め、隣接版間のマイグレーションを連鎖適用して現行構造へ引き上げるのが定石で、tag番号の再利用禁止・追加は安全／削除改名は危険・未知フィールドの保持・欠損の既定値補完といった進化の規律が破壊を防ぎます。破損に対しては、CRC32等のチェックサムで検知しつつ（ただし改ざん防止にはHMACが要る）、一時ファイル＋fsync＋renameによるアトミック書き込みで書き込み中の全損を防ぎ、世代バックアップで回復層を用意します。検知・予防・回復の3層と、明示的な版番号＋スキーマ駆動形式の組み合わせが、アップデートを重ねてもプレイヤーのセーブを壊さないための実務的な要諦です。