【ITニュース解説】Preserve First: Recovery Design for Local Creative Data

ITシステム開発において、ユーザーが作成した大切なデータを守ることは非常に重要である。特に、データをまずユーザーのデバイスに保存し、サーバーへの依存を減らす「ローカルファースト」なアプリケーションでは、このデータ保護の考え方が一層重要になる。ローカルファーストのアプリは、インターネット接続がなくても作業でき、パフォーマンスも向上するが、データがユーザーのデバイスにしか存在しないため、もしデータが壊れたり失われたりした場合、サーバーから復元するという選択肢がない。これが、ローカルファーストアプリにおけるデータ復旧設計を極めて重要なものにする理由である。

クリエイティブな作業ツールで最も危険なのは、問題が発生したときに表示される「復旧ダイアログ」だとこの記事は指摘している。「プロジェクトを読み込めませんでした。新しく開始しますか？」といったメッセージが表示され、うっかりクリックすると、読み込みに失敗したファイルが数秒で完全に消去される可能性がある。これは、ツールが助けようとして、意図せずデータを破壊してしまう状況だ。ローカルファーストアプリでは、一度データが失われると取り返しがつかないため、アプリの復旧コードは、ユーザーへの「データの保存はデフォルトであり、破壊するには厳格な許可が必要である」という約束を果たす必要がある。

この「保存第一」の原則を具体的にどう実現するか、WorldScript Studioというオープンソースのライティングスタジオの事例を基に、五つの設計原則が示されている。

一つ目の原則は「拒否し、即興で対応しない」である。自動保存の際、アプリはディスク上のファイルを書き込む前に、そのファイルの状態を厳密に分類する。「形式が壊れている」「将来のバージョンで作成された」「サポート対象外」といった分類だ。重要なのは、現在のクリーンな状態ではないファイルを見つけた場合、アプリは「何とかしよう」と即興で書き換えるのではなく、明確に「保存を拒否する」という判断を下すことである。この拒否は、「保存できませんでした。理由はこれです」とユーザーに明示的に通知される。これにより、ユーザーはデータの損失を後で発見するのではなく、その場で問題に気づき、対処できる。これは、アプリが勝手にデータを上書きして、問題を悪化させるのを防ぐための重要な設計だ。

二つ目の原則は「破壊には厳格な許可が必要」というものだ。もしアプリの起動自体が失敗した場合でも、復旧に関する破壊的な操作は、デフォルトではすべて「いいえ」と判断される。例えば、読み込みに失敗したプロジェクトファイルがあっても、そのファイルを勝手に隔離したり、データベースをリセットしたりすることはしない。破壊的な操作である「隔離」「リセット」「安全なオープン」といった選択肢は、特定の、そして非常に限定された状況でのみ許可される。データの入出力エラーや、ブラウザ内のレコードの破損など、データを破壊しない種類の失敗は、決して「隔離」のような破壊的な権限にはエスカレートしない。復旧の選択肢は、UIの状況に左右されず、失敗の種類に基づいて厳格に、一箇所で決定されるべきだという考え方である。

三つ目の原則は「隔離は名前変更であり、削除ではない」だ。もしデータの一部を隔離する必要が生じた場合、アプリはそのプロジェクトのディレクトリを「隔離されたプロジェクト」という領域に移動する（名前を変更する）。これは、ファイルを削除するのではなく、安全な場所に避難させることで、いつでもデータを元に戻したり、内容を確認したりできるようにするためだ。この名前変更のプロセスを守るために、いくつか工夫が凝らされている。例えば、破壊的な操作を行う際には必ず「プロジェクトロック」という仕組みを使って、他の処理が同時にデータを変更するのを防ぐ。また、ロックファイル自体もプロジェクトディレクトリとは別の場所に置くことで、隔離操作によってロックが移動してしまい、保護の役割を果たせなくなるのを防ぐ。さらに、「生成トークン」というランダムな識別子をプロジェクトファイルと一緒に保存する。これは、ユーザーがプロジェクトを削除し、その後同じ名前で新しいプロジェクトを作成した場合でも、システムがこれらを「同じプロジェクトの続き」と誤解しないようにするためだ。これにより、以前削除されたデータが、古いバージョンのウィンドウから誤って復活してしまうような事態を防ぎ、ユーザーの「削除する」という意図を確実に尊重する。

四つ目の原則は「リセットが失敗した場合でも安全に失敗する」だ。ブラウザのデータベース（IndexedDB）をリセットするという、いわば「最後の手段」のような操作を行う際にも、アプリは非常に慎重だ。もしデータベースのリセット中に、他の部分がまだ古いデータベースに接続したままだと、新しいデータベースと古いデータベースという二つの異なる状態が存在することになり、状況は悪化する。これを防ぐため、アプリはデータの世代を区別する仕組みを用いて、リセット中に開始された接続が新しいデータベースに進むことを許さない。また、リセットを完了させる前に、古いデータベースへのすべての接続が確実に切断されなければならない。もし途中で何らかのエラーが発生して接続が切れなかった場合、リセット操作全体が拒否され、古い状態が手付かずのまま残される。これは「中途半端な復旧は、全く復旧しないよりも悪い」という考えに基づいている。アプリは、完全に安全にリセットできない限り、古い状態を維持することを選ぶ。

最後の五つ目の原則は「ユーザーが所有する脱出ハッチ」だ。これまでの原則はすべて、アプリ内部でデータを保護するためのものだったが、最終的にはユーザー自身がアプリの外にデータのコピーを持つことが最も重要になる。そのため、WorldScript Studioは、すべてのプロジェクトをまとめて一つのアーカイブファイルとしてバックアップする機能を提供する。このバックアップファイルは、強力な暗号方式で暗号化されており、その暗号化キーはユーザーが設定したパスフレーズから、複雑な計算を繰り返して生成される。これにより、パスフレーズはユーザーのみが知るものであり、アプリのベンダーやアカウントに依存しない。たとえアプリ自体が消滅したり、ベンダーが事業を停止したりしても、ユーザーは自分のパスフレーズさえ覚えていれば、バックアップファイルからデータを復元できる。また、バックアップファイル自体が暗号化されているため、クラウドストレージに保存したり、メールで送ったりしても、他人に内容が見られる心配がない。

これらの原則をまとめると、データ復旧設計における重要なチェックリストが導き出される。それは、あらゆる問題に対して明確な理由を伴う拒否を返すこと、破壊的な操作には厳格な条件を設けること、削除ではなく安全な隔離を行うこと、大規模なリセット操作は安全が確認できない限り実行しないこと、そしてユーザー自身がアプリに依存しない形でデータをバックアップできる手段を提供することだ。もしアプリが、破損したファイルを読み込んだ際に、最初の選択肢でデータを破壊するようなら、その復旧設計はまだ不十分だと言える。システムエンジニアを目指す上で、このようなユーザーのデータを守るための深い配慮と厳密な設計思想を学ぶことは、非常に価値があるだろう。