稼働率と外部依存
——千年保存に外部サービスは使えない

※本稿はトキストレージの設計思想を解説するエッセイです。特定のサービスを批判する意図はありません。

1. 99.9%の幻想

クラウドサービスの営業資料には「SLA 99.9%」「99.99%」といった数字が並ぶ。一見すると盤石に見える。しかし、これを時間に換算すると景色が変わる。

99.9%を「ほぼ完璧」と思う人は多い。しかし100年では36.5日——つまり丸1ヶ月以上、サービスが停止する計算になる。そして、これは「そのサービスが100年存続する」という前提での話だ。

2. 外部依存の連鎖

現代のWebサービスは、驚くほど多くの外部依存を抱えている。典型的な構成を見てみよう。

• ホスティング：AWS / GCP / Azure
• ドメイン：レジストラ（年次更新が必要）
• SSL証明書：認証局
• メール送信：SendGrid / Mailgun
• 決済：Stripe / PayPal
• 認証：Auth0 / Firebase Auth
• チャット：LINE API / Intercom
• 予約：Calendly / STORES

これらのサービスがひとつでも停止すれば、ユーザー体験のどこかが壊れる。そして10年以内にサービスを終了するSaaS企業は珍しくない。Googleですら、Google+、Google Reader、Hangoutsなど数えきれないプロダクトを終了してきた。

依存の連鎖は確率的に破綻する

5つの外部サービスにそれぞれ99.9%の稼働率があるとする。すべてが同時に稼働している確率は：

0.999 × 0.999 × 0.999 × 0.999 × 0.999 = 0.995 = 99.5%

——年間停止時間は43.8時間（約1.8日）に膨張する

外部依存が増えるほど、システム全体の稼働率は指数関数的に低下する。これは理論ではなく算数だ。

3. トキストレージの設計原則

千年スケールでは、あらゆる外部サービスが消滅し得る。この前提に立つと、設計原則は明確になる。

原則1：外部依存を最小化する

トキストレージの三層分散保管は、三つの層がそれぞれ独立して存続する設計になっている。

• 物理層（石英ガラス / ラミネート）——電源もサーバーも不要。人間の目とスマホカメラがあれば読める
• 国家層（国立国会図書館 法定納本）——法律が存続する限り消えない。サーバー代も不要
• 民間層（GitHub）——世界中に分散されたホスティング

物理層はそもそもサービスではない。国家層は法律に基づく制度であり、企業の事業判断では廃止できない。民間層だけがサービスだが、GitHubが消えても他の二層が残る。

原則2：障害モードを分離する

三層の障害モードは互いに無関係だ。

• 石英ガラスが物理的に割れる事象
• 国会図書館法が廃止される事象
• GitHubが事業を終了する事象

これらは同時に起こらない。地震でガラスが割れても、法律は変わらない。企業が倒産しても、図書館は閉じない。障害モードが独立しているからこそ、全滅の確率は限りなくゼロに近づく。

原則3：フォールバックを設計する

これはインフラだけの話ではない。日常の接点ひとつにも同じ原則が貫かれる。

たとえば、問い合わせフォーム。トキストレージはかつてLINE公式アカウントとCalendlyを使っていた。しかし、これには構造的な問題があった。

• LINE——PCではLINEのWebサイトにリダイレクトされ、離脱が発生する。メッセージングアプリのAPIであり、SLAは公開されていない
• Calendly——スタートアップSaaSであり、事業継続の保証は限定的。予約という機能に対して重すぎる外部依存

現在は、静的JavaScriptフォーム＋Google Apps Scriptに移行した。フォームのUI自体は静的ファイルであり、GitHub Pages上で動作する。GASが停止しても、フォームは表示され、フォールバックとしてメールアドレスが直接表示される。

4. SLAの正しい読み方

SLAを評価するとき、数字だけを見てはいけない。以下を確認する必要がある。

1. 対象範囲——何が保証されているのか。「サーバーの稼働」と「API応答」は別物
2. 補償内容——SLA違反時にどうなるか。多くはサービスクレジット（利用料の返金）であり、データ損失の補償ではない
3. 存続前提——そのSLAは「サービスが存続する限り」という暗黙の前提がある。サービス終了時にSLAは消滅する
4. 依存連鎖——そのサービス自体が依存している外部サービスは何か。依存先のSLA違反は、あなたのSLA計算に含まれていない

5. Google Workspace——現実的な選択

トキストレージが問い合わせフォームのバックエンドにGoogle Apps Scriptを選んだのには理由がある。

• SLA 99.9%——Google Workspaceとして公式に保証
• インフラ規模——Gmail障害が起きれば世界中がニュースにする。つまり障害検知が事実上無料
• 無料枠——GAS実行、Gmail送信、スプレッドシート記録のすべてが無料枠内で完結
• 月間制限なし——Web3Formsの月250通制限と異なり、GASのメール送信は日100通（個人アカウント）

しかし、ここでも原則は同じだ。Googleに依存しきるのではなく、Googleが落ちたときのフォールバック（メールアドレスの直接表示）を用意する。外部依存を完全にゼロにはできないが、障害時の代替手段を必ず設計する。

6. 千年設計の静かな基準

結局のところ、千年保存の設計思想とは「いつか必ず壊れる」という前提から始まる。

サーバーはいつか停止する。企業はいつか消滅する。法律ですら改正される可能性がある。だからこそ、ひとつの層が壊れても他の層が残る設計にする。ひとつのサービスが落ちても連絡手段が断絶しない設計にする。

"Everything fails, all the time."

——Werner Vogels, CTO of Amazon Web Services

AWSのCTO自身が認めている。すべてはいつか壊れる。この事実を受け入れたうえで、壊れてもなお機能する設計をすること。それが、千年スケールのインフラ設計であり、トキストレージの全レイヤーに通底する思想だ。