技術ロードマップ
—— 10年ごとのマイグレーション計画

1. 非対称性の問題

トキストレージの三層分散保管には、一つの構造的な非対称性がある。

物理層（石英ガラス）の寿命は3億年以上。日立製作所と京都大学の共同研究で、加速劣化試験により実証されている。一方、デジタル層の技術サイクルは10年単位で変わる。QRコードの規格、URLの仕組み、ブラウザの仕様、ホスティングサービスの存続——すべてが入れ替わりうる。

つまり、「器」は千年もつが、「読み方」が先に消える。

ただし、トキストレージのQRコードにはURLだけでなく、Codec2で符号化された音声データそのものがBase64URLパラメータとして埋め込まれている。つまりURLが死んでも、データ自体は石英ガラスの中に残っている。失われるのはデータではなく、「スキャンすれば即座に声が聴こえる」という体験だ。100年後の誰かがQRコードを読み取れば文字列は得られる——だがそれを再生する手段がなければ、声には戻らない。

2. 三つの層、三つの時間軸

この問題に対するトキストレージの設計は、三層それぞれに異なる時間軸のマイグレーション戦略を持たせることだ。

物理層：石英ガラス——マイグレーション不要

石英ガラスに刻まれたデータは、レーザー加工によるフェムト秒パルスでナノグレーティング構造として記録される。温度、湿度、紫外線、化学変化に対して極めて安定しており、読み取りに必要なのは偏光顕微鏡だけだ。光学原理は物理法則そのものなので、技術が変わっても原理は変わらない。

この層は「マイグレーションしない」ことが設計の核だ。変わらないからこそ、他の層が変わっても基盤が残る。

国家層：国立国会図書館——制度によるマイグレーション

国立国会図書館（NDL）のウェブアーカイブは、納本制度という法的枠組みに基づいて運用されている。技術フォーマットの移行はNDL自身が組織的に行う。WARCフォーマットからの変換、メタデータスキーマの更新、ストレージ基盤の刷新——これらは国の機関として予算と人員を投じて実施される。

個人や企業が50年後のフォーマット互換性を心配する必要がない。それが国家層に託す意味だ。

民間層：GitHub——コミュニティによるマイグレーション

GitHubは現在、1億人以上の開発者が利用するプラットフォームだ。Arctic Code Vaultプログラムにより、オープンソースコードはノルウェーのスヴァールバル諸島の永久凍土下に物理的にもアーカイブされている。

だがGitHub自体の存続は保証されない。10年後にMicrosoftが方針を変えるかもしれない。だからこの層のマイグレーション戦略は「Gitそのもの」に依拠する。Gitは分散型バージョン管理システムであり、リポジトリのクローンさえあれば、どのホスティングサービスにも移行できる。GitHub → GitLab → Codeberg → 自前サーバー。移行先は無数にある。

3. 10年サイクルの点検項目

三層の設計があっても、放置すれば機能しなくなる。だから10年ごとに以下を点検する。

QRコード規格の互換性

QRコードはISO/IEC 18004として国際標準化されている。1994年の発明以来、後方互換性を維持したまま拡張されてきた。だが30年後、50年後に同じ規格が読み取り可能である保証はない。10年ごとに、主要なスマートフォンのカメラアプリでQRコードが正常に読み取れるかを検証する。読み取り率が低下していれば、新しいコード規格への移行を検討する。

URL・ドメインの存続

石英ガラスに刻まれたQRコードにはURLが埋め込まれている。ドメイン（tokistorage.github.io）の存続は、GitHub Pagesの継続に依存する。10年ごとに、ドメインの有効性と代替ホスティングの選択肢を評価する。独自ドメインへの移行が必要になった場合に備え、リダイレクト設計を常に最新化しておく。

ファイルフォーマットの可読性

音声データはCodec2（オープンソース音声コーデック）、画像はPNGとJPEG、テキストはUTF-8のプレーンテキストとHTML。いずれもオープン規格を選んでいるのは、プロプライエタリなフォーマットが10年で読めなくなるリスクを避けるためだ。10年ごとに、保管しているフォーマットが現行の主要ブラウザとデバイスで再生可能かを検証する。

再生環境の互換性

play.htmlはブラウザ上で音声を再生するページだ。WebAudio API、WASM（WebAssembly）、Base64URLエンコーディング——これらのWeb標準が10年後も機能するかを検証する。もし特定のAPIが非推奨になった場合、代替実装に切り替える。

4. 式年遷宮という先例

伊勢神宮は20年ごとに社殿を建て替える。式年遷宮と呼ばれるこの儀式は、1300年以上続いている。

木造建築は永遠ではない。だが20年ごとに建て替えることで、建築技術の伝承と材料の更新が同時に行われる。結果として、建物そのものは常に新しいが、「建て方」の知識は途切れない。

永遠に保つ方法は二つある。
変わらない素材を使うか、変わり続ける仕組みを作るか。

トキストレージは両方を採用した。石英ガラスは変わらない素材。10年ごとのマイグレーションは変わり続ける仕組み。物理層が「永遠」を担い、デジタル層が「更新」を担う。

式年遷宮の知恵は、「壊れる前に建て替える」ことにある。劣化してから慌てるのではなく、まだ機能しているうちに次の形に移す。トキストレージの10年サイクルも同じだ。QRコードがまだ読める間に、次の10年も読めるかを確認する。

5. 運営者不在時の設計

千年保管を掲げる以上、運営者がいなくなるシナリオは想定しなければならない。

トキストレージの設計は、バーンレート・ゼロ（固定費ゼロ）を基盤にしている。サーバー費用、ドメイン費用、ストレージ費用——すべてが無料枠の範囲で運用されている。つまり、誰も課金しなくても、システムは動き続ける。

だがそれでも、10年ごとの点検は誰かがやらなければならない。

ここで三層設計が機能する。仮にデジタル層のメンテナンスが途絶えても、物理層の石英ガラスは手元にある。国家層のNDLアーカイブは制度として存続する。三層のうち一層が失われても、残りの二層でデータは生き延びる。

理想は、10年ごとの点検を継続すること。だが現実には、途絶える可能性もある。だからこそ三層なのだ。冗長性は「うまくいかなかったとき」のために存在する。

6. ロードマップは公開する

このマイグレーション計画を非公開にする理由はない。

公開することで、三つの効果がある。第一に、利用者が「自分の保管物がどう守られるか」を理解できる。第二に、技術コミュニティからのフィードバックが得られる。第三に、将来の運営者（あるいはフォークする誰か）が、設計思想ごと引き継げる。

トキストレージのコードはGitHubでオープンソース公開されている。このエッセイ自体が、技術ロードマップの公開文書の一部だ。設計思想がコードの横に並んでいれば、10年後の誰かが「なぜこう作ったのか」を理解した上でマイグレーションを実行できる。