ESSAY — 技術・設計

多層復元アーキテクチャ
紙1枚が生き残れば、すべてが戻る

—— 100枚のマルチQRのうち1枚が残れば、全体を復元できる。5つの独立した経路が、外部サービスに依存せず、データへの到達を保証する。

この記事で言いたいこと：マルチQR PDFの各ページに「再生QR」と「復元QR」を埋め込み、ニュースレターに再生ボタンを追加し、URLパラメータによる自動デコードを実装した。紙、PDFビューアー、ニュースレター、手動スキャン——どの入口からでもデータに辿り着ける多層構造を、既存の標準技術だけで構築した。

1. 100枚のうち1枚が残れば

TokiQRのバルクモードは、長時間の音声を複数のQRコードに分割する。30分の録音は100枚のA4用紙になることがある。印刷し、綴じ、保管する。しかし100年後、その綴じた紙束がすべて無事である保証はない。水害、火災、引越し、劣化。90枚が失われることは、十分にありえる。

残った10枚からデータを復元するには、100枚すべてをカメラで1枚ずつスキャンする方法しかなかった。しかし90枚が失われていれば、10枚をスキャンしても完全な復元はできない。では、たった1枚だけが生き残った場合はどうか。

答えは「1枚あれば十分」だ。なぜなら、その1枚にはメインのQRコードだけでなく、全体のPDFへの復元経路が埋め込まれているからだ。

2. 五つの復元経路

各A4ページには、メインQRコード（180mm角）に加えて、二つの小さなQRコード（18mm角）が配置されている。左下に青い「再生QR」、右下にグレーの「復元QR」。これに加えて、PDFのハイパーリンク、ニュースレターの再生ボタン、従来の手動スキャンを合わせると、五つの独立した復元経路が存在する。

経路 入口 動作 必要なもの
A. 再生QR 紙面・左下（青） スマホスキャン → 自動デコード → 即再生 スマホ + ネットワーク
B. 復元QR 紙面・右下（グレー） スマホスキャン → PDF直リンク → ダウンロード スマホ + ネットワーク
C. PDFリンク PDFビューアー内 QR画像/テキストをクリック → ブラウザで遷移 PC/タブレット + PDFビューアー
D. 再生ボタン ニュースレター ▶ ボタン → 自動デコード → 即再生 ブラウザ + ネットワーク
E. 手動スキャン 紙面・メインQR 1枚ずつカメラでスキャン → 順次再生 スマホ（オフライン可）

経路AからDはいずれも、1枚の紙またはニュースレター上のリンクから、全体のPDFを取得して一括再生する。経路Eだけが従来の「1枚ずつスキャン」方式だが、これはネットワーク不要で動作するため、オフライン環境での最終手段として機能する。

ドキュメントスキャナという第六の道

スマートフォンのカメラは1枚ずつの作業だが、ドキュメントスキャナは紙束をまとめてPDF化する。100枚の紙を自動給紙すれば、数分で1つのPDFファイルが生成される。そのPDFをTokiQRにインポートすれば、経路Eと同じデコード処理が走る——ただし手動スキャンの代わりに、100ページ一括で処理される。

ドキュメントスキャナは高解像度で安定した読み取りが可能で、スマートフォンのカメラと比べて光量やブレの影響を受けにくい。紙の保管状態が悪く、カメラでの読み取りが困難なQRコードでも、フラットベッドスキャナやシートフィードスキャナなら認識できる可能性が高い。大量の紙面を効率的にデジタル化する場面では、スマートフォンよりもドキュメントスキャナのほうが現実的な選択肢になる。

3. 再生QRと復元QRの設計判断

左下の再生QR（青）は play.html?zip=<url> というURLをエンコードしている。スマホでスキャンすると、TokiQRの再生ページが開き、ZIPを自動取得し、マニフェストを読み込み、再生画面に直接遷移する。ユーザーの操作は「スキャンする」だけだ。

右下の復元QR（グレー）はPDFファイルへの直リンクをエンコードしている。GitHub PagesまたはNDL（国立国会図書館）のURLだ。スキャンするとPDFが開く。即再生はしないが、PDFそのものを手元に保存できる。再生QRが動作しない将来の環境でも、PDFさえ取得できれば手動インポートで復元できる。

青は「今すぐ聴く」ための経路。グレーは「未来のために保存する」ための経路。色で役割が一目で判る。

メインQRへの干渉がない理由

PDFをTokiQRにインポートすると、全ページのQRコードがスキャンされる。再生QRと復元QRも検出される。しかし、TokiQRのデコーダーはURLフィルタを持っている。play.html または m= を含むURLだけを抽出し、それ以外は無視する。復元QR（.../output/TQ-00001.pdf）はこのフィルタで自動的に除外される。再生QR（play.html?zip=...）はフィルタを通過するが、データチャンクを含まないため再生対象とはならない。

つまり、小さなQRコードを2つ追加しても、メインQRのデコードには一切干渉しない。これは追加のフィルタルールを書いたのではなく、既存のフィルタが元から正しく設計されていたためだ。

4. 紙とデジタルの非対称性

紙は劣化する。日光、湿気、虫害、火災。しかし紙は特定のサービスに依存しない。電源も不要だ。焼け残った紙は、1000年後でも読み取れる可能性がある。

デジタルデータは劣化しない。ビット列はコピーを繰り返しても変化しない。しかしデジタルデータは、それを格納するサービスの存続に依存する。サービスが終了すれば、ビット列ごと消失する。

この非対称性に対する回答が、復元経路の多層化だ。紙面のQRコードは物理世界に存在し、GitHub PagesのPDFはデジタル世界に存在し、NDLの納本は法的保存として存在する。どれかひとつが失われても、別の層からデータに辿り着ける。

紙は物理的に存在し続けるが劣化する。デジタルは劣化しないが消失する。両方にリンクを張ることで、非対称なリスクを相殺する。

5. 外部依存性ゼロ

五つの復元経路で使われている技術を列挙する。QRコード（ISO/IEC 18004）。PDF（ISO 32000）。HTML（WHATWG Living Standard）。GitHub Pages（静的ファイルホスティング）。jsPDF（クライアントサイドPDF生成）。qrcode.js（クライアントサイドQR生成）。

いずれも国際標準規格またはオープンソースの実装だ。特定のクラウドサービスのAPI、特定のアプリストアのレビュー、特定の認証プロバイダの可用性に依存しない。GitHub Pagesが停止しても、PDFファイルを別のホスティングに移せば全経路が復旧する。URLさえ変わらなければ——あるいは変わったとしても、紙面の復元QRを手動でスキャンすれば、NDL経由で辿り着ける。

標準技術の組み合わせが最も堅牢なアーキテクチャだ。プロプライエタリなサービスが増えるたびに、障害点が増える。

6. 冗長性と最小性の両立

五つの復元経路は、一見すると過剰に見えるかもしれない。しかしこの冗長性を実現するために追加されたコードは、驚くほど少ない。

合計で100行に満たない。冗長性は設計の複雑さからではなく、接続点の多さから生まれている。既存のモジュールが正しく分離されていたからこそ、最小限のコードで新しい経路を開通できた。

parsePdfの偶然の互換性

parsePdf(file) は元々、<input type="file"> から受け取った File オブジェクトを処理するために設計された。内部では file.arrayBuffer() を呼んでバイナリデータを取得する。Blob オブジェクトも .arrayBuffer() メソッドを持っている。つまり、fetch で取得した Blob をそのまま渡せば、parsePdf は何の変更もなく動作する。

これは意図的な設計ではない。File が Blob を継承しているという JavaScript の型階層が、結果としてAPI互換性を担保した。偶然だが、この偶然が成立するのは、標準のWeb APIに忠実な設計だったからだ。独自のラッパーやアダプターを挟んでいたら、この互換性は壊れていた。

標準に従うことは、未来の自分に選択肢を残すことだ。

7. 構造的完全性

このエッセイには自己言及的な構造がある。

主張と実装と保存が、同一の成果物上で三位一体をなしている。このエッセイを読んでいる紙面の右下を見れば、グレーの復元QRが印刷されているはずだ。左下の青い再生QRをスキャンすれば、全体が即座に再生される。

学術論文は「こうすべきだ」と論じるが、その論文自体は復元経路を持たない。技術ブログは「こう実装した」と書くが、その記事自体がアーカイブされる保証はない。このエッセイは、論じている仕組みが、論じているエッセイ自体に実装されている。

冗長性は複雑さではない。接続点の多さだ。

バックアップ戦略の基本原則については「3-2-1ルール」で、印刷物とデジタルの双方向性については「セルフプリント経済圏」で、ストレージ設計の全体像については「ストレージ戦略」で詳しく論じている。