バックアップ復元の「成功」をどう判定するか：型・ID・参照関係の3ケースを実測

JSONを読み込めた、復元件数が合った、一覧に表示された。それぞれは確認できても、元どおりに使えるとは限りません。公開アプリの固定版を検証した結果を、入力の型・IDの利用可能性・レコード間の関係という3つの観点で比較します。

対象と入力	固定版での観測	分けるべき成功条件
DevTasks：UIで作ったDOCSの実際の出力	自身の読み込み時のスキーマ検査が拒否。標準FEATUREはPASS	自分が保存できる値を受け入れるか
Kaioken 1.7.1：合成した不正ID	数値IDは保存・一覧が通っても詳細不可。オブジェクトIDは未処理エラー。同一テストで1.7.2は3 PASS。実ファイル往復ではない	保存したIDでデータを開けるか
WA-archiver：固定版のサーバー側SQLiteと実バックアップ	restoreはHTTP 200、messagesImported: 3。選択した通常フィールドはすべて一致、replyToはobjectからnullへ	レコード間の関係が戻ったか

「復元が成功した」を一つの条件にすると、この違いが隠れます。実ファイルの往復で失敗したのは表の1行目と3行目。2行目は、不正な入力に対してimportをどう終えるかの検査です。入力の出どころが違うため、同じ失敗率として集計できません。

以下は、AIを使って運営しているaichance側が、固定した公開ソースと合成データで行った独立したローカル測定です。作者自身によるテスト実行の報告ではありません。検証日と固定コミットの範囲で読み、現在の上流版の状態とは分けてください。

自分が出力した値を受け入れるか

最初のDevTasksは、2026年10月12日の検証です。ソースをd59dc107に固定し、通常UIから分類DOCSを追加してタスクを保存しました。その後、アプリのExport JSONで取得したファイルを編集せず、保存データのない別のブラウザコンテキストに読み込ませると、スキーマ検査で拒否され、復元先にタスクは入りませんでした。

同じ操作で標準分類FEATUREを使うと、完全なタスクレコードが戻り、再読み込み後も表示されました。固定ソースでは、分類追加UIが受け付ける文字列と、読み込み側が許すFEATURE・BUG・REFACTORの範囲が一致していません。この対照は、保存可能な値とimportの受け入れ範囲を突き合わせる調査につながります。

ここで拒否をPASSに読み替えると、「不正なファイルを拒否する」という別の要件へすり替わります。DOCSはアプリ自身のUIが作り、自身が出力した値です。読み込み時の検証処理だけから有効な検証用JSONを手作りすると、この食い違いを飛ばしてしまいます。自分のアプリなら、ユーザーが追加できる分類や拡張値を含めて、UIで作れるデータの範囲を先に列挙するのが出発点です。再実行用の手順とspecには、標準分類の正常対照も残しています。

保存したIDでデータを開けるか

次のKaiokenは、2026年10月16日（JST）の検証です。1.7.1の固定ソースafe0e19dで、通常UIから既存のroutineを一つ作り、Settingsに合成したJSONを入力しました。実際のExportで得たファイルを戻す試験ではありません。文字列IDを正常対照に、数値12345とオブジェクト{}を比較しています。

数値IDでは、レコード数が1→2になり、再読み込み後も2のままでした。完全なレコードと型を含めた主キーも保持されています。それでも追加した項目を開くと詳細へ進めず、Homeの見出しが表示されました。保存と一覧だけなら通るのに、そのデータを利用する操作が通らない状態です。オブジェクトIDでは未処理のDataErrorが発生し、明示的な拒否が出ませんでした。こちらは元の1レコードと主キーが変わっておらず、既存データが消えたという結果ではありません。

この検査は、不正IDの扱いを一つに決め打ちしていません。明示的に拒否して既存の保存データと画面を維持するか、利用可能な文字列IDへ修復し、入力の他のフィールドと既存レコードを保つか、どちらでも受け入れます。受け入れた場合は詳細を開き、再読み込み後にもう一度開くところまでを条件にします。正常な文字列IDは、理由なく書き換えないことも対照です。

作者の修正報告後、同じ10月16日（JST）に1.7.2の15ef9f23を測定すると、変更していない同一specで、1 PASS・2 FAILから3 PASSになりました。観測したのは拒否の分岐ではなく、数値・オブジェクトIDを利用可能な文字列へ修復する分岐です。入力の他のフィールドと既存routineを保ち、詳細を再読み込み前後に開けています。公開specと修正前後の結果を並べると、どの期待値を維持したまま修正を確認したかが分かります。

自分のアプリでも、IDの正規形式と用途を先に決める必要があります。再採番が正当な仕様なら、その対応と参照先の整合性を期待値に含めます。比較からIDを一律に除外してしまうと、保存されたデータが利用できない理由を見逃します。一方で、再採番の仕様があるのに生のID一致だけを要求すれば、正しい復元まで失敗扱いになります。

件数と本文に加えて、参照関係も戻るか

最後のWA-archiverは、2026年10月16日（JST）、固定ソース7983cd4e、package.json記載の版1.1.0-beta.1のサーバー側SQLiteモードです。合成した親メッセージと通常メッセージを準備し、通常のmessages APIで返信を追加しました。出力前には、通常の読取APIのreplyToと、画面の親メッセージの引用を確認しています。

Settingsからダウンロードした1783 bytesの実ファイルを、独立して新規作成したSQLite DB側へ同じバイト列のまま読み込ませました。復元応答はHTTP 200で、messagesImported: 3。再読み込み後の3件について、選択した通常のmessages DTOからreplyToを除いた全フィールドは一致しました。一方、返信のreplyToはobjectからnullになり、画面でも引用が消えました。再実行キットと結果に、通常fieldと参照関係のフィールドの比較を分けてあります。

このケースでは、固定版のbackup出力がreplyToIdを含まず、restoreも関係を戻していません。復元前後のbackup JSON同士が一致しても、両方が同じフィールドを落としていれば検出できません。そこで、出力処理とは別の通常のmessages読取APIから、解決済みのreplyToを比較しました。件数、本文、HTTPの成功応答を見た後にも、残る関係を読める経路が必要だったわけです。対象は選択したmessageのDTOと引用表示であり、DB全体の完全復元を測った結果ではありません。

実行経路にも違いがあります。App Crash Lab 0.10.0の組み込みのbackup-roundtripはブラウザ内のJSON保存を対象にします。WA-archiverの通常のreloadと不正JSON拒否はCLIで両方PASSしましたが、サーバーDBの実ファイル復元は別のPlaywright診断です。Kaiokenの不正ID importも別specです。CLIの通常保存検査が通ったことを、これらのimport検査が通った証拠にはできません。

特にサーバーDBは、新しいbrowser contextを作っても空になりません。WA-archiverでは復元先のDBを別に作り、対象chatが存在せず、backupのchatsが空であることを確認してから読み込んでいます。既存データを「復元できた」と取り違えないためには、分離する単位を実際の保存先に合わせる必要があります。

自分のアプリへ持ち帰るテスト仕様

この比較を自分のアプリ用のテスト仕様にすると、たとえば次の短い依頼文になります。

使い捨てのローカル環境で、通常UIから作れる標準値と拡張値を用意する。
有効データの試験は、実際にexportした同じbytesを空の保存先へrestoreする。
不正IDの合成入力は別試験とし、拒否か修復かの方針を明示する。
選んだ完全なレコードと主キーを比較し、受け入れた項目を再読み込み前後に開く。
正当な再採番・変換がある場合は、対応関係と保持すべきフィールドを先に宣言する。
参照関係のフィールドはexporterとは別の通常の読取経路と、意味のある画面操作から確認する。
サーバーDBは新しいブラウザコンテキストだけでは分離できないため、独立した保存先の空状態を確認する。
正常対照を残し、保存完了待ちや環境不成立をデータ損失の判定と分ける。

成功と呼ぶ境界を明確にすると、失敗したときに調べる場所も絞れます。自分が出力した値を受け入れること、保存したIDを使えること、参照関係が戻ることを別々の期待値にすると、修正後も同じ仕様で回帰を確かめられます。自分のアプリへ合わせた際は、入力の種類・固定版・期待する拒否／修復方針と実際の差分を添えて、コメントで教えてください。

追記：自分のテストへ足す検査を選ぶ

検査の抜けを選びやすいように、4つの保存・復元チェックリストと、コピーして使える実測済みテストをまとめました。実ファイルの受け入れと参照関係に加え、「保存レコードは残るがHistoryに出ない」「閉じる直前の編集が残らない」も、固定版の結果と再実行手順から選べます。

まず自分のアプリに当てはまる1つを選び、通常データと、分類追加などの境界条件を含む有効データを用意して、対応するテストを合わせる使い方です。既存のPlaywrightへ残せるspecとApp Crash Labの設定を分けて案内しています。これは過去の固定版での運営側の実測集であり、各アプリの最新版の不具合や作者によるツール利用を示すものではありません。