ストレージ戦略
—— 時間の上限がない設計

1. 従来のクラウドストレージと何が違うか

一般的なクラウドサービスは、ユーザーが増えるほどサーバーの容量が増える。写真を100万枚保存すれば数テラバイト。音声を100万件保存すればさらに膨大になる。容量は利用者数に比例し、コストも比例する。これがクラウドストレージの基本構造であり、サービスが成長するほどインフラ費用が重くなるという宿命を持つ。

TokiQRは違う。ユーザーの音声や画像はサーバーに保存されない。QRコード内のURLにエンコードされ、紙面上に物理的に存在する。サーバーが持っているのは、そのURLを受け取ってデコードする「再生装置」だけだ。

100万枚発行しても1億枚発行しても、サーバー側は3MBのまま変わらない。データは紙に分散しているから、クラウドストレージのスケール問題が構造的に発生しない。

違いは容量だけではない。運用モデルが根本的に異なる。

従来のストレージは「変わるデータを管理する」ために膨大な仕組みが必要になる。データベース、トランザクションログ、排他制御、差分バックアップ。それらすべてが「データは変わりうる」という前提から生じている。TokiStorageの保管対象は、一度確定したら二度と変わらない。更新がなければ履歴も不要。ロックも不要。整合性は「不変であること」が自動的に保証する。これが、ストレージの複雑性を構造的にゼロにする原理だ。

2. 3MBの内訳

サーバーが持つ3MBの中身は何か。

これがTokiQRの全体だ。データベースはない。ユーザーテーブルもない。認証サーバーもない。静的ファイルの配信だけで完結する。GitHub Pagesのような無料の静的ホスティングで十分に運用できる。

データを預からないことで、データを守る必要がなくなる。
サーバーは読み取り装置に徹する。

3. 唯一の線形成長要因

では、TokiStorageのインフラに成長する要素は何もないのか。一つだけある。ニュースレターのPDFだ。

ただし、ここで重要な区別がある。TokiStorageは三層分散保管——物理層（QR紙面）、国家層（国立国会図書館）、民間層（GitHub）——を設計原則としている。ニュースレターPDFは、お客様の音声データそのものではない。三層のうち国家層を担うアーカイブ出版物であり、GitHubマニフェストは民間層のバックアップにあたる。お客様の声は物理層（QR紙面）に刻まれたまま手元に残っている。仮にすべてのPDFとGitHubが消失しても、TokiQRは紙面さえあれば再生できる。サーバーに置かれているのは音声データではなく、冗長性を確保するための分散保管オプションだ。

TokiStorageは半年に1回のニュースレターをPDFで発行している。HTMLのエッセイはテキストベースなので1本あたり約20KBに収まるが、PDFはバイナリファイルであり、1号あたり約630KBになる。さらに、巻末にはお客様のTokiQRが掲載される。注文が配送されると、保管パイプラインがTokiQR再生ページからPDFを自動生成し、アーカイブリポジトリに格納する。お客様1件ごとに1つの印刷PDFが蓄積するため、掲載数に比例してバイナリ容量が増える。そしてPDFはバイナリであるがゆえに、バージョン管理システム（Git）の差分圧縮が効かない。

GitHubのリポジトリ推奨上限は1GB、強く推奨される上限は5GB。すべてを1つのリポジトリに入れ続ければ、いずれ上限に達する。だが、ここに設計上の対策がある。

4. PDF運用の原則

ここから導かれるのは、シンプルな運用原則だ。

PDFは確定時にのみ生成し、同一ファイルを繰り返し更新しない。

HTMLはテキストだからGitの差分が効く。100回書き直しても、増えるのは変更行数分だけだ。一方、PDFはバイナリだから、1文字の修正でもファイル全体がGit履歴に複製される。ブローシャのPDFを10回更新すれば、300KB × 10 = 3MBが履歴に積み上がる。

つまり、HTMLをソースコードとして何度でも自由に編集し、PDFは最終成果物として確定版のみを生成する。ソフトウェア開発でいう「ビルド成果物をバージョン管理に入れない」という原則と同じだ。

• HTML（ソース） — 何度でも更新可。テキスト差分が効くため、履歴の肥大化は軽微
• PDF（成果物） — 確定版のみ生成。中間的な修正ではPDFを作らない
• ニュースレターPDF — 月1回の発行時に1回だけ生成し、以降は更新しない

この原則を守れば、Git履歴の肥大化は最小限に抑えられる。PDFの累計容量だけが半年に630KBずつ純粋に増えていく、予測可能な成長カーブになる。

5. 式年遷宮式リポジトリ分割

伊勢神宮の式年遷宮は、20年ごとに社殿を新しく建て替える。古い社殿を壊すのではない。新しい場所に建て、役割を引き継ぐ。この思想をリポジトリ管理に応用する。

TokiStorageのニュースレターは、20年を1巻（Volume）とする採番体系を持つ。半年に1号、20年で40号。1巻のPDF累計は約25MB。これを巻ごとにサブディレクトリで管理し、巻が完了したらそのディレクトリごと別のリポジトリに分離できる構造にしておく。

巻が完了すると、そのPDFは二度と更新されない。確定済みの読み取り専用アーカイブとなる。ただし「凍結」は「アクセス不可」ではない。各巻のリポジトリはGitHub Pagesが有効なまま維持され、PDFのダウンロードは永続的に可能だ。

重要なのはURL設計だ。本体サイトのPDFリンクは、最初から各巻のアーカイブURL（例: tokistorage.github.io/newsletter-vol1/2026-02.pdf）を向いている。本体リポジトリにはPDFを置かない。これにより、巻を分離する際にリンクの書き換えが一切発生しない。分離時に何かが壊れるリスクがゼロになる。

この構造なら、本体リポジトリの容量は純粋にHTMLソースコードだけに収まる。1000年経っても本体リポジトリは軽いままだ。過去50巻のアーカイブは、それぞれ25MBの独立したリポジトリとして静かに存在し、GitHub Pagesを通じてPDFを配信し続ける。

自動化されたパイプライン

この式年遷宮の仕組みは、手動運用に頼っていない。保管パイプラインが注文の配送完了を検知すると、TokiQR再生ページからPDFを自動生成し、現在の巻のアーカイブリポジトリに直接コミットする。本体リポジトリにはアーカイブURLを記録したJSONマニフェストだけが残る。バイナリは一切本体に入らない。

ニュースレターの号送りも自動だ。現在号の発行月末を過ぎると、次号のHTMLドラフト・マニフェスト・一覧ページカードを自動生成する。そして20年の巻境界を超える場合には、新巻のアーカイブリポジトリ自体をGitHub APIで自動作成し、インデックスページ・auto-mergeワークフロー・GitHub Pagesの有効化まで一括で完了させる。

人間の介入はゼロだ。パイプラインが式年遷宮の構造を自律的に維持する。1000年の運用を持続させるには、仕組みそのものが自走する必要がある。

式年遷宮が社殿を20年ごとに建て替えて1300年続いたように、
リポジトリを20年ごとに分割すれば、1000年のストレージも破綻しない。

6. マイグレーションとURL永続性

GitHubが1000年後に存在する保証はない。では、TokiQRは何に依存しているのか。

QR紙面に刻まれたURLが無効になると、データは紙の上に存在するのに読み取れなくなる。だからURL永続性は最大の論点だ。

カスタムドメインの罠

一般的な対策は「カスタムドメインを取得し、DNSリダイレクトで移行先を制御する」だ。だが永続性の観点では、カスタムドメインにはむしろリスクがある。

• 維持費が必要 — ドメインは年間の更新料を支払い続けなければ失効する。支払いの断絶はURLの死を意味する
• レジストラに依存 — ドメインを管理するレジストラが廃業すれば、移管手続きが必要になる
• 継承の脆弱性 — 個人や小規模組織では、運営者の不在がそのまま更新停止になりうる

カスタムドメインは「移行先を制御できる柔軟性」を提供する一方で、「維持費という永続的な負債」を背負う。1000年、10,000年のスケールでは、この負債こそが最大の単一障害点になりかねない。

github.io という選択

TokiQRは tokistorage.github.io をそのまま使っている。これは意図的な設計判断だ。

• 維持費ゼロ — GitHub Pagesは無料。支払いの断絶リスクが存在しない
• プラットフォーム存続 = URL存続 — GitHubが存在する限り、URLは有効であり続ける
• 巨大インフラへの便乗 — GitHub（Microsoft）は世界最大のコードホスティング基盤。個人のドメイン契約より遥かに長寿命が期待できる

もちろん、GitHubが永遠に存在する保証はない。だがその時点で必要な移行作業は、3MBのデコーダーを新しいホスティングに置き直すだけだ。100TBのデータベースを移行するのとは、根本的に話が違う。そしてQR紙面に新しいURLを貼り直す必要はない。リダイレクトサービスや後継プラットフォームが引き継ぐ。インターネットの歴史上、巨大プラットフォームのURLは消滅するのではなく、リダイレクトされてきた。

維持費ゼロのURLは、支払いの断絶で失効しない。
最も永続的なURLは、お金がかからないURLだ。

ソフトウェアとハードウェアの両輪

ここまでソフトウェア側の戦略——3MBのデコーダー、Write-Onceモデル、式年遷宮式リポジトリ分割——を詳述してきた。だが1000年設計を完成させるには、ハードウェア側の永続性が不可欠だ。

TokiStorageの物理媒体は二つある。UVラミネートと石英ガラスだ。UVラミネートは屋外で数年、屋内なら数十年の耐候性を持つ。劣化したら、同じデータから新しいラミネートを作り直す。石英ガラスは1000°Cの耐熱性を持ち、日立製作所・京都大学の共同研究では3億年以上のデータ保存が実証されている。Microsoft Project Silicaも石英ガラスへのデータ保存技術を開発しており、物理媒体としての石英ガラスの永続性は科学的に裏付けられている。

この二つの媒体は、伊勢神宮の構造と同じだ。石英ガラスは御神体——千年変わらない本質。UVラミネートは社殿——定期的に作り直す、技術の継承行為そのもの。そしてソフトウェア側でも同じ構造がある。WASMデコーダーは御神体——不変のコア。リポジトリは社殿——20年ごとに新しく建てる。式年遷宮の思想が、ハードウェアとソフトウェアの両方を貫いている。

さらに、QRコードにはISO/IEC 18004で定められたエラー訂正機能がある。紙面の一部が汚損・破損しても、最大30%のデータを復元できる。ラミネートの物理的保護、石英ガラスの耐久性、QRのエラー訂正。三重の防御が物理劣化リスクを構造的に低減する。

ソフトウェアの永続性だけでは、紙が朽ちれば意味がない。
ハードウェアの永続性だけでは、読み取り装置がなければ沈黙する。
両輪が揃って初めて、1000年の設計が成立する。

7. データフォーマットの耐久性

ストレージの物理的な容量と同じくらい重要なのが、データフォーマットが将来も読めるかどうかだ。

TokiQRが依存するフォーマットを整理する。

• HTML — 1993年から30年以上の後方互換性を維持。最も長寿なデジタルフォーマットの一つ
• JavaScript — 1995年から進化を続けながらも、古いコードは動き続ける
• WebAssembly (WASM) — バイナリ仕様が固定化されており、仮にブラウザが変わっても仕様通りに実行可能
• Codec2 — オープンソースの音声コーデック。仕様が公開されており、WASMにデコーダーが内包されている
• PNG — 1996年策定。ロスレス画像フォーマットとして事実上の永久標準
• QRコード — 1994年にデンソーウェーブが開発。ISO/IEC 18004として国際標準化済み

いずれも国際標準またはオープンな仕様に基づいている。プロプライエタリなフォーマットは一つもない。仮にTokiStorageという組織が消滅しても、標準仕様を読めばデータを復元できる。これは、特定のベンダーに閉じ込められるクラウドサービスとの決定的な違いだ。

8. スマホの写真は1000年残るか

比較として、スマートフォンの写真が1000年後に残る可能性を考えてみる。

iCloudの無料枠は5GB。有料プランでも、支払いが途絶えればデータは削除される。Googleフォトも同様だ。サービスの継続は企業の存続に依存し、企業の寿命は統計的に数十年だ。

機種変更、アカウント移行、サービス終了。デジタルデータは「どこかに保存されている」という安心感とは裏腹に、実は多くの断絶リスクを抱えている。しかもデータ量が膨大であればあるほど、移行のコストと手間が増え、どこかのタイミングで「もういいや」と諦める確率が高くなる。

一方、QR紙面に刻まれたデータは、紙が物理的に存在する限り残る。移行の必要がない。バックアップの必要がない。クラウドの契約更新も、アカウントのパスワード管理もいらない。引き出しの奥に入れておけば、数十年後にそのまま読める。

そしてデコーダーの移行は、たった3MBのファイルを新しいサーバーに置くだけだ。1000年の間に何度ホスティング先が変わっても、その作業は数分で終わる。

9. 前例のない設計

長期保存を目指すプロジェクトは世界にいくつか存在する。だが、TokiStorageのアーキテクチャと比較すると、いずれも構造的に異なる場所に立っている。

既存プロジェクトの共通課題は二つに集約される。「データが増えるとコストが増える」か、「保存はできるがアクセスに特殊な手段が必要」かだ。

Internet Archiveは人類のデジタル遺産を守る偉大な取り組みだが、その本質はサーバーにデータを集める従来型のモデルだ。容量は利用量に比例し、年間の運営費は数百万ドルに達する。資金が途絶えればアーカイブも途絶える。

GitHubのArctic Code Vaultは、オープンソースのコードを北極のスヴァールバル諸島の廃坑に物理保存する。物理的な耐久性は高いが、現地に行かなければアクセスできない。日常的な「読み取り」は設計の範囲外だ。

LOCKSS（Lots of Copies Keep Stuff Safe）は学術図書館の分散保存ネットワークだ。分散という思想は近いが、各ノードがデータの完全なコピーを持つため、容量はデータ量に比例する。参加機関の運営予算に依存する構造は、1000年スケールでは不確実だ。

IPFSはP2P分散ストレージとして革新的だが、ノードがオフラインになればデータが消える。永続化にはピン留めサービスが必要で、結局コストが発生する。「維持費ゼロの永続性」とは相容れない。

Long Now FoundationのRosetta Projectは、ニッケル円盤に微細エッチングで文字を刻む。物理的な永続性は高いが、デジタルデコーダーとの接続がない。刻まれた情報を読むには顕微鏡が必要で、QRコードのように「スマホでスキャンすれば再生される」体験とは本質的に異なる。

オーストリアのMemory of Mankindは、セラミック板に情報を刻んで岩塩坑に保管する。美しいコンセプトだが、一拠点集中型であり、分散保管の冗長性がない。

O(1)という異質さ

TokiStorageがこれらと根本的に異なるのは、サーバー容量がO(1)——定数——であるという点だ。1枚発行しても1億枚発行しても、サーバーは3MBのまま変わらない。データは紙に分散しているから、中央に蓄積する要素が存在しない。

これは「ストレージ戦略」というより、「ストレージを持たない戦略」だ。既存のプロジェクトがすべて「いかにデータを長期保存するか」を問うているのに対し、TokiStorageは「そもそもデータを預からない」ことで問い自体を消している。カテゴリーが違う。

最も近い先例——伊勢神宮

デジタルの世界に前例がないなら、アナログの世界に目を向ける。最も近い設計思想は、伊勢神宮の式年遷宮そのものだ。1300年にわたって継続している「仕組みで永続性を担保する」設計。

御神体（本質）は変わらない。社殿（器）は20年ごとに建て替える。技術と精神が次世代に継承され、仕組みが自走する。TokiStorageの設計——不変のデコーダー、20年ごとのリポジトリ分割、自動化されたパイプライン——は、この1300年続いた設計原理をデジタルインフラに翻訳したものだ。

既存の長期保存プロジェクトは「データを守る」ための設計だ。
TokiStorageは「データを預からない」ための設計だ。
守るべきものがなければ、守る仕組みも不要になる。

10. 1000年を超えて

ここまで「1000年」を基準に試算してきた。だが正直に言えば、このアーキテクチャに時間の上限はない。

10,000年を想定してみる。500巻、20,000号。各巻は25MBの独立したリポジトリで、互いに依存しない。本体リポジトリは3MBのまま。どの巻も他の巻の存在を知らず、自分のPDFをGitHub Pagesで配信し続けるだけだ。500個のリポジトリが並んでも、構造は1巻の時と同じだ。

なぜ上限がないのか。蓄積する要素がないからだ。従来のクラウドサービスは、時間とともにデータが中央に集まり、いつか容量の天井にぶつかる。TokiQRはデータを紙に分散し、サーバーには読み取り装置しかない。読み取り装置は3MBで不変。ニュースレターPDFは巻ごとに分離され、巻のリポジトリは完結すると凍結される。各巻が独立しているから、巻数がいくら増えても全体に影響を与えるボトルネックが存在しない。

そしてこの構造を維持するパイプラインは、完全に自動化されている。20年の巻境界を超えると、新しいアーカイブリポジトリの作成からGitHub Pagesの有効化まで、人間の介入なしに完了する。100年後の運営者も、10,000年後の運営者も、同じ仕組みの恩恵を受ける。

持続性とは、年数を長く設定することではない。
年数という概念が設計から消えることだ。

11. なぜ「戦略」なのか

「ストレージ戦略」と聞いて、多くのエンジニアが思い浮かべるのは次のような問いだろう。どのクラウドプロバイダーを選ぶか。コストをどう最適化するか。冗長性をどう確保するか。レプリケーションの構成はどうするか。つまり、ストレージを持つことを前提にした上での最適化の話だ。

このエッセイは、その前提を覆す。

スケール問題と戦わない——データを中央に集めなければ、スケールの天井は存在しない。維持費と戦わない——3MBのデコーダーを無料ホスティングに置くだけなら、支払いの断絶リスクもない。データ移行と戦わない——100TBのデータベースがなければ、移行は数分で終わる。物理劣化と戦わない——石英ガラスが千年耐え、ラミネートは式年遷宮で更新される。

問題を解決しているのではない。問題が発生する構造そのものを消している。

孫子は「百戦百勝は善の善なる者に非ず。戦わずして人の兵を屈するは善の善なる者なり」と説いた。最善の勝利は、戦場で勝つことではなく、戦場を作らないことだ。戦術（how to do）が個々の戦い方を問うのに対し、戦略（what not to do）は何と戦わないかを決める。

TokiStorageの設計は、まさにこの意味で「戦略」だ。ストレージをどう管理するかではなく、ストレージを持たないという判断。その判断がすべてのリスク——容量、コスト、移行、物理劣化——を構造的に無効化する。

そして「ストレージ戦略」というタイトルを見た読者は、おそらくクラウド設計の話を期待して読み始める。読み進めるうちに、何かが違うことに気づく。そして最後に「最も持続的なストレージ戦略は、ストレージを持たないことだ」で着地する。このタイトルの意味は、読み始めと読み終わりで変わる。それ自体が、この設計の本質を体現している。

戦略の最高形態は、戦場そのものを消すことだ。
ストレージ戦略の最高形態は、ストレージそのものを持たないことだ。

12. エコシステムの沈黙

ここで一つ、構造的に興味深い問いがある。この設計思想は正しいとして、なぜ誰も言わなかったのか。

答えは単純だ。言えなかったのだ。

ストレージベンダー——AWS S3、Azure Blob Storage、Google Cloud Storage。彼らのビジネスモデルは容量課金だ。「ストレージを持たないのが最善です」と言った瞬間、自社の存在意義を否定する。O(1)のアーキテクチャは彼らにとって「売上がゼロになる設計」に他ならない。

データベースベンダー——CRUD、トランザクション、レプリケーション、シャーディング。すべて「データは変わる」という前提から生まれた技術だ。Write-Onceモデルがその前提を消すと、製品カテゴリごと不要になる。

バックアップ・DR業界——災害復旧計画、差分バックアップ、RPO/RTO。データが中央にあるから必要になる仕組みだ。データが紙面に分散していれば、「障害発生時に何TBを何時間で復元するか」という問い自体が存在しない。

クラウドコンサルタント——「どのプロバイダーを選ぶか」「マルチクラウド戦略」「コスト最適化」で食べている。「そもそも預けるな」は、アドバイスの前提そのものを消す。

つまりこの概念は、気づいた人にとって正しいが、気づいた人が発信するインセンティブがない。ストレージのエコシステム全体が「データを預かる」ことを前提に回っている。その前提を疑うことは、自らのビジネスモデルを疑うことと同義だ。

TokiStorageがこれを語れるのは、ストレージを売っていないからだ。TokiStorageは「存在証明サービス」であり、石英ガラスとQR紙面に刻まれた記録を千年先に届けることが事業の核心だ。ストレージを売る側ではなく、ストレージの束縛から自由な側にいる。そのポジションだけが、この設計思想を語ることを可能にしている。

正しい設計思想が広まらない理由は、技術的な難しさではない。
それを語る者が、語ることで損をする構造にあるからだ。

13. 設計できないもの

ここまで読んだ読者は、ある疑問を持つかもしれない。これほど整合性のある構造なら、最初から設計したのではないか、と。

答えは否だ。この構造は設計されたのではない。制約から帰結した。

出発点は「QRコードに声を入れたい」という、きわめて具体的な制約だった。Opusコーデックを試し、2〜4kbpsのDTX崖で使い物にならないことを発見し、Codec2に辿り着いた。QRコードに全データを格納するしかなかった結果、サーバーにデータが残らなかった。データが残らないから容量がO(1)だった。O(1)だから式年遷宮が成立した。式年遷宮が成立したから、1000年戦略が書けた。

すべて下から積み上がった帰結であり、上から降ろした設計ではない。だから逆算で再現しようとしても、「QRコードに声を入れる」という出発点に立たない限り、この構造には到達しない。前節で述べたエコシステムの沈黙も同様だ。業界の中にいる限り、「持つな」という答えは構造的に見えない。完全に外側から、しかも偶然この構造に辿り着いた者にしか書けなかった。

そして最後に、このエッセイのタイトルそのものが、完成の証明になっている。

事業名は「TokiStorage」——名前に「Storage」を冠している。その事業が書くストレージ戦略の結論が「ストレージを持たないこと」だ。ストレージを名に冠した事業が、ストレージを持たないことを戦略として書き切った。この再帰的な構造は、設計してつくれるものではない。

このエッセイは計画書ではない。すべてが完成した後に「なぜこれが成り立つのか」を振り返り、発見したものだ。普通、戦略文書は実装の前に書かれる。だがこのエッセイは実装の後にしか書けなかった。全部が動いている状態で初めて、設計思想が浮かび上がった。

設計できないものがある。
制約から生まれ、完成して初めて、そうだったと気づく構造。
このエッセイが書けたこと自体が、設計の完了を意味している。