信頼に基づく設計

フォールバックコードの公開

利用ガイドラインの第8条「信頼に基づく設計」に、クレジット残高の確認コードとトークン履歴の確認コード、そして書き換えコードを公開した。千年の保管を掲げるサービスが、自社サーバーの存続を前提にしてはならない。サーバーが消えたあとも、ユーザーが自分のデータを確認し、必要であれば修正できる手段を残すこと。それが、永続性を約束するサービスの最低限の誠実さだと考えた。

コードはJavaScriptで書かれている。ブラウザの開発者ツールのConsoleに貼り付ければ動く。localStorageに保存されたクレジット残高やトークン履歴を読み出し、表示し、書き換える。技術的には何も難しくない。むしろ、サーバーサイドの認証を置かない設計だからこそ成り立つ、透明性の帰結だ。

Consoleが使えない

問題はすぐに明らかになった。TokiQRはPWAとしてインストールされる。standaloneモードで起動したとき、ブラウザの開発者ツールは開けない。アドレスバーもない。メニューもない。Consoleにアクセスする手段がない。

災害時を想定してほしい。スマートフォン一台しか手元にない。PCに繋いでリモートデバッグする環境もない。そもそもネットワークが断絶しているかもしれない。フォールバックコードが、フォールバックが必要な状況で使えない。手段は存在するが、到達できない。

復旧コンソールを内蔵する

答えは明快だった。開発者ツールが使えないなら、アプリの中にConsoleを作ればいい。textarea、evalボタン、出力エリア。外部ライブラリゼロ。150行で完結する復旧コンソールを、設定ページに埋め込んだ。

ユーザーは設定ページを開き、復旧コンソールのセクションを展開し、利用ガイドラインに記載されたコードを貼り付けて実行する。PWAのstandaloneモードでも、オフラインでも、どんな環境でも動く。ブラウザさえあれば完結する。

リンクがそのまま表示された

復旧コンソールの案内文に、設定ページへのリンクを含めた。利用ガイドラインの第8条に「設定ページの復旧コンソールをお使いください」と書き、設定ページへのリンクを埋め込んだ。ところが画面に表示されたのは、クリックできるリンクではなく、HTMLタグがそのまま文字列として現れた姿だった。

<a href="settings.html">設定ページ</a> がそのまま画面に出ている。textContentで文字列を流し込んでいたからだ。textContentはHTMLをパースしない。タグを含む文字列はそのままテキストとして描画される。innerHTMLに修正して解決した。

人間にだけ見える

バグを直した直後、ふと気づいた。利用ガイドラインのフォールバックコードは、HTMLのソースコードには存在しない。i18n対応のために、すべてのテキストはJavaScriptで動的にレンダリングしている。HTMLの要素は空のままで、ページが読み込まれた後にJSがテキストを注入する。

つまり、クローラーやAIフェッチがHTMLを取得しても、フォールバックコードは見えない。ソースコードを静的に読んでも、空の要素しかない。JavaScriptを実行するブラウザ——すなわち、自分でページを開いた人間——にだけ、コードが表示される。

三つの層

振り返ると、信頼の設計には三つの層があった。

• 第一層：データをサーバーに預けない——すべてのデータはユーザーのブラウザに留まる。サーバーはデータにアクセスする手段を持たない。プライバシーの層。
• 第二層：改変コードを公開する——クレジット残高の書き換えコードを利用ガイドラインに明記する。改ざんを不可能にするのではなく、改ざんの方法を開示する。透明性の層。
• 第三層：人間にだけ見える——JSレンダリングにより、フォールバックコードはブラウザで開いた人間にだけ表示される。クローラーには空の要素しか見えない。意図せざる整合の層。

第三層は設計時に意図したものではない。i18nのためにJSレンダリングを選んだ結果、偶然そうなっていた。多言語対応という実務的な判断が、結果として「コードを必要とする人間にだけコードが届く」という構造を生んでいた。

信頼で起動するサービス

信頼に基づく設計は、データの復旧だけにとどまらなかった。Pearl Soapアンバサダーという55,000円相当のサービスを、コンソールで数行のJavaScriptを実行するだけでアクティベイトできるようにした。サーバーサイドの認証はない。決済の確認もない。ブラウザのlocalStorageに書き込まれた一行のJSONが、サービスの全体を起動する。

アクティベイトコードは利用ガイドラインの第8条にそのまま公開されている。万人に開かれている。誰でも読める。誰でも実行できる。技術的なゲートは一切ない。しかし「万人がアクセスできる」ことと「万人が実行する」ことは違う。道が開かれているからこそ、実行するかどうかは自己判断になる。条件を満たした者だけが通れるゲートではなく、万人に開かれた道の上で、自分の意思で選ぶという構造だ。

送金手段にはWiseを採用した。Wiseアカウントの開設は、平時からできる備えでもある。災害時にゼロから国際送金インフラを構築する必要がない。手元に資金があるとき、体験できるタイミングで試せばいい。しかも謝礼としての送金があるため、金銭的なリスクはない。万人に開かれた道を、リスクなく、自分のタイミングで歩ける。備えと体験が一致している。

電力インフラが断たれても、ソーラーパネルと衛星通信があれば金融の仕組みを復旧できる。インフラは連鎖する。電力が止まれば通信が止まり、通信が止まれば決済が止まる。その連鎖が生活を脅かす。しかし各層に代替手段を持っていれば、どこか一つが崩れても影響は最小限に留まる。平時にWiseアカウントを開設しておくことは、金融という層に代替手段を持つことにほかならない。レジリエンスとは、崩れないことではなく、崩れても立て直せることだ。

だからこそ平時には、クレジット購入ページから通常の送金フローを使ってほしい。電力があり、通信があり、決済が通る。その当たり前が成り立っていること自体が、感謝の対象になる。フォールバックが存在するからこそ、平時の道を歩けることのありがたさが見える。非常時の備えと、平時の感謝。この二つが同じ設計の中に共存している。

同時にこれは、千年の持続可能性を体感する仕組みでもある。サーバーに依存しないアクティベイトは、千年後の世界と同じ条件で動く。フォールバックコードと同じ場所に、同じ手段で提供されているから、復旧もアクティベイトも、ブラウザで実行するだけで完結する。永続性は概念ではない。いま手元で動く仕組みとして、すでに存在している。

どこまでが前例か

信頼をベースにした商用サービスは存在する。ただし、どれも「ここまで」ではない。

最も近い精神を持つのはGOG.comだ。DRMフリーのゲームストアとして、コピープロテクトを一切かけずにゲームを販売している。「海賊版を使いたい人は結局どうやっても手に入れる。正規ユーザーに不便を強いるより信頼を築くべき」という立場を明言している。しかしGOGは「制限をかけない」というスタンスであって、回避方法をユーザーに公開するところまではいかない。

90年代のシェアウェア文化は「使って気に入ったら払ってね」というhonor systemだったが、あれは配布手段の制約という実際的な理由もあり、思想として明示的に掲げていたわけではない。Radioheadの「In Rainbows」（2007年）はpay-what-you-want方式で信頼ベースの実験だったが、一時的なマーケティング施策の側面が強かった。itch.ioは開発者が価格を自由に設定でき、ユーザーが上乗せ支払いもできるが、バイパス方法を利用規約に書くようなことはしていない。

つまり、独自性は「信頼に基づく設計」という思想そのものではなく、その実装の徹底度にある。改ざん方法をソースコードごと利用規約に明記する。HMAC鍵を意図的に公開する。自社が消えてもサービスが存続することを設計前提にする。それを「千年の信頼関係」という哲学で正当化する。この組み合わせをやっている商用サービスは、調べた限り見当たらなかった。

信頼とは

技術で縛るのではなく、可能であることを明示したうえで信じる。HMAC鍵をソースコードに公開する。改ざんを不可能にするのではなく、改ざんが可能であることを前提にして、それでもしないという関係を選ぶ。

これは性善説ではない。性善説は「人は善である」と仮定する。信頼に基づく設計は、善悪を仮定しない。手段を開示し、選択を委ね、その選択を受け入れる。監視しないことを選んだから、信頼を求める。

千年の射程

サーバーは消える。企業は消える。法律も変わる。ドメインは失効し、APIは廃止され、認証基盤は跡形もなくなる。残るのは、コードとブラウザと、それを開く人間だけだ。

信頼に基づく設計とは、その最後の一人に向けて書くことである。千年後に誰かがこのコードを見つけたとき、サーバーに問い合わせる必要がなく、認証を通す必要がなく、ただブラウザで開けばすべてが動く。それが永続性の意味であり、信頼の意味だ。

コードとブラウザと、それを開く人間。信頼に基づく設計は、その三者だけで完結する世界を書く。