このアプリのすべてを形作っている、たった一つのアーキテクチャ上の判断は、言葉にすれば小さいが、実際にそれを中心に組み立てるのは厄介だ。写真ドライブは厳格に読み取り専用で開かれ、決して書き込まれない。原本の隣に置くサイドカーファイルも、隠しメタデータフォルダも、リネームも、移動した重複もない。入ってきたドライブは、1バイト単位で同じまま出ていく。
この制約は、ファイルを移動したりリネームしたりして「整理する」ツールをすべて排除する。サムネイル、顔の特徴ベクトル、イベントの境界といった派生状態を、原本の近くに保存することも排除する。アプリがアーカイブについて学んだことはすべて別の場所に置く必要があり、その場所をどこにするかを早い段階で決めなければならなかった。
派生したものはすべて内蔵ディスクに置く
答えはSQLiteで、外付けドライブではなく、Macの内蔵ディスク上にある。インデックス(日付、顔、イベントの境界、検索用の特徴ベクトル)とサムネイルキャッシュは、どちらもそこに置かれ、アーカイブ自体からは完全に分離している。アプリのデータディレクトリを削除しても、アーカイブは手つかずであることが証明できる。アーカイブについての何かが、そのディレクトリの存在に依存したことは一度もないからだ。ゼロから再インストールすれば、アプリは自分自身の状態のバックアップを信頼する必要なく、ドライブを再び読み取ることで理解を再構築する。
実際に最も効いたのは、SQLiteのライトアヘッドログ(WAL)だった。開発中に2回、シミュレートした障害ではなく本物の停電によるハードクラッシュが、実際のアーカイブに対して解析処理を実行している最中の書き込みの途中で起きた。どちらの場合も、WALジャーナリングのおかげでデータの損失はゼロだった。データベースは次回起動時に一貫した状態で立ち上がり、ほぼ中断したところから再開し、手動での修復は不要だった。外付けドライブ、何時間も動く背後の解析処理、ケーブルが時々ぶつかって外れる家庭という組み合わせの中で、公開前に本当に2回テストされたことになる。
「読み取る」ことで実際に回収できるもの
読み取り専用の保証は、それを守りながら実際に抽出できるものの分だけ役に立つ。実際の家族アーカイブのメタデータは、きれいなテストセットよりも乱雑だ。元になったアーカイブでは、92%のファイルが、そのまま使える正しいEXIFの日付を持っていた。残りの8%にはフォールバックが必要で、ファイルシステムのタイムスタンプ、フォルダ名の日付、同じイベント内の近隣写真からの推測を使い、その結果カバレッジは98.1%に達した。最後の2%が下限だ。一部のファイルには、ファイル自体にも周辺にも日付の手がかりがなく、どんなフォールバックの連鎖も、無から日付を作り出すことはできない。
理解が終わる前から、閲覧できる
読み取り専用の原本と、別の場所に置いた派生状態は、安全性の問題を解決する。それとは別に、待ち時間の問題がある。大きなアーカイブの完全な解析には数時間かかり、1枚の写真を見る前に進捗バーを眺めていたい人などいない。ライブラリは、ドライブにアプリを向けてから数分以内に閲覧可能になる。早い段階のパスが、基本的な閲覧に足るインデックスとサムネイルを揃えるからだ。もっと深いパス(顔のクラスタリング、イベントの命名、意味検索を支える特徴ベクトル)は、その裏で動き続け、写真を見ている間により豊かな答えを埋めていく。
リソース統制は、提案ではなく、ルールだ
数十万ファイルを読み取って理解する解析処理は重い作業であり、誰かの唯一のMacの上で重いバックグラウンド処理を走らせることは、ローカルAIが、使っている最中にノートパソコンを熱くする存在になってしまう典型的な原因だ。ここでの制限は厳格なルールである。解析処理がフォアグラウンド作業と競合しないようにするバックグラウンドQoSスケジューリング、ユーザーが操作を始めてから数秒以内に後退するワーカー数、メモリ使用量の上限、そしてバッテリーや発熱の圧力下での一時停止。標準的なMacで動く完全な解析処理は、感じ取れるようなものであってはならない。感じ取れるなら、それはバグだ。
読み取り専用の原本、内蔵ディスク上の派生状態、クラッシュに強いジャーナリング、実際に守られるリソース上限を合わせると、かなり地味なエンジニアリング上の立場になる。AIは端末上で動き、それ以外に信頼すべきサーバーは存在しない。だからこれらの保証のそれぞれは、あなたがすでに他のすべてを預けている、机の上の1台のマシンについてだけ真実であればよい。