1. なぜCloudflare WorkersとGASなのか
一人で運用するプロジェクトには、一人で運用できるインフラが要る。スケールではなく、統合が必要だ。
Google Apps Script——1ファイルに収まる運用基盤
GASを選んだ理由は明快だ。メール送信、スプレッドシート、スケジュール実行——通常なら3つの別サービスが必要な機能が、ひとつの環境に統合されている。契約不要、設定不要、コストはゼロ。
トキストレージのGASスクリプト（code.gs）は1,564行。注文受付、Wise入金確認、保管パイプライン自動化、日次アクセスレポート、入金リマインダー、月次パートナーレポート、ニュースレター自動生成——一人プロジェクトの運用基盤が、この1ファイルに収まっている。
Cloudflare Workers——52行で解決する
Cloudflare Workerを使う理由は技術的に明確だ。GASのexec URLは302リダイレクトを返すため、WiseのWebhook URLバリデーションに通らない。52行のプロキシがこれを解決する。CORSの処理を担い、GAS再デプロイ時のURL変更もWorker側で吸収する。コストはゼロ。
つまり、運用のバックエンドはCloudflare Workers + GAS + Googleスプレッドシートで構成されている。外部依存だ。しかしこの依存は、合理的な選択の結果であって、妥協ではない。
一人プロジェクトのインフラに必要なのは、スケールではなく、統合だ。
GASはメール・スプレッドシート・スケジューラを一つの環境で提供する。
2. 運用レイヤーと永続レイヤー
トキストレージのアーキテクチャには、2つのレイヤーがある。
| 運用レイヤー | 永続レイヤー | |
|---|---|---|
| 役割 | 注文受付、問い合わせ、解析 | 音声の保存、存在の記録 |
| 依存先 | Cloudflare Workers, GAS, Google Sheets | QRコード（物理）, GitHub, NDL |
| 寿命の想定 | 数年〜十数年 | 100年〜1000年 |
| 代替可能性 | 他のサービスで代替可能 | 代替不可——データ自体が自己完結 |
| 停止時の影響 | 新規注文が受けられない | 影響なし——既存のQRコードは永久に再生可能 |
この分離が設計の核心だ。運用レイヤーは外部に依存してよい。しかし永続レイヤーは、何にも依存してはならない。
QRコードに刻まれた音声データは、URLパラメータとしてQRコード内に完結している。サーバーに問い合わせる必要がない。CloudflareもGASもGoogleスプレッドシートも関係ない。QRコードを読み取り、ブラウザで開くだけで音声が再生される。
3. もしCloudflareが消えたら
Cloudflare Workerが停止した場合、影響を受けるのは以下だ。
- QRサイトの注文フォームが送信できなくなる
- QRサイトの問い合わせフォームが送信できなくなる
- WiseのWebhook通知が届かなくなる
影響を受けないものは以下だ。
- すべての既存QRコード——再生に一切影響なし
- QR生成ツール——完全にクライアントサイドで動作
- すべての物理製品——QRコードが刻まれた金属プレートは物理的に存在し続ける
- NDLの記録——国立国会図書館に納本されたニュースレターは独立して保存されている
復旧は容易だ。GASのexec URLに直接POSTするようフォームを書き換えるか、別のプロキシサービスに差し替えればよい。Cloudflare Workerのコードはわずか52行だ。
4. もしGASが消えたら
GASがEOL（End of Life）になった場合、影響を受けるのは以下だ。
- 注文・問い合わせのスプレッドシート記録が停止する
- メール通知が届かなくなる
- アクセス解析が停止する
影響を受けないものは以下だ。
- すべての既存QRコード——再生に一切影響なし
- すべての物理製品——変わらず存在し続ける
- NDLの記録——独立して永続する
- LPサイト——静的HTMLなので、GASが消えてもフォームとトラッカー以外は正常に表示される
代替策もある。GASのコードは131行のシンプルなスクリプトだ。フォーム受信・スプレッドシート記録・メール通知。同等の機能は、Supabase、Netlify Functions、あるいは単純なメールAPIで代替できる。
5. 依存の設計原則
トキストレージの外部依存には、明確な原則がある。
原則1: 永続レイヤーは外部に依存させない
QRコードのデータはURLパラメータとして自己完結する。音声の復号はクライアントサイドのWASMで行う。物理製品は金属に刻印される。NDLへの納本は紙と電子の両方で行われる。いずれも、Cloudflare/GAS/GitHub/BASEの生死に影響されない。
原則2: 運用レイヤーは便利なものを使い、代替可能に保つ
GASを使う理由は単純だ。無料で、セットアップが速く、スプレッドシートとの連携が自然だからだ。Cloudflare Workerを使う理由は、GASの302リダイレクト問題を解決するためだ。どちらも合理的な選択だが、どちらも明日差し替え可能なように設計している。
原則3: 依存先のコードを自分で保持する
GASのソースコード（contact-form-gas.js）はリポジトリに保管されている。Cloudflare Workerのソースコード（wise-webhook-proxy.js）もリポジトリにある。サービスが消えても、ロジックは手元に残る。
原則4: パイプラインに秘匿データを流さない
そもそも、Cloudflare WorkerとGASを通過するデータに「漏れたら困るもの」がない。これが最も根本的な設計原則だ。
外部サービスを使うなら、そのサービスが消えた日のことを設計に含めろ。
そして、そのパイプラインに秘匿データを流すな。
6. 漏れて困るデータがない
注文フォームからCloudflare Worker → GAS → Googleスプレッドシートに流れるデータを整理する。
| データ | パイプライン経由 | 最終的な行き先 |
|---|---|---|
| QR URL（音声データ） | 注文情報として送信 | 物理製品に刻印、GitHub公開（選択時）、NDL納本（選択時） |
| 名前・住所 | 配送先として送信 | 配送ラベル。includePersonal選択時はアーカイブにも含まれる |
| 保管オプション | 選択内容として送信 | どの公開保管レイヤーに乗せるかの指示 |
| クレジットカード情報 | 一切通過しない | Wiseのプラットフォーム上で直接入力・処理（PCI DSS準拠） |
QR URLに含まれる音声データは、最終的に物理製品に刻まれ、希望すればGitHubで公開され、NDLに納本される。公開を前提としたデータだ。名前と住所は配送に必要な情報であり、購入者が望めばアーカイブにも含まれる。
そしてクレジットカード情報は、このパイプラインを一切通らない。決済はWiseのプラットフォーム上で完結する。注文確定後にWiseの決済リンクがメールで届き、購入者はWise上でカード情報を入力する。トキストレージのCloudflare WorkerにもGASにもGoogleスプレッドシートにも、カード番号は一度も記録されない。
パイプラインに秘密が存在しない——これは偶然ではなく、設計だ。保管対象のデータが公開前提であること、決済を外部プラットフォームに委託していること、この二つの設計判断が、外部サービスを安全に使える構造を作っている。
この設計思想の原点は、技術書ではなく墓地にある。家紋、苗字、墓誌——お寺でも公営墓地でも、墓石は見る人を選ばない。拒まない。永く残すものは、最初から公開を前提に刻まれる。トキストレージのQRコードも、同じ構造をとっている。
セキュリティの最善策は、守るべき秘密をそもそも持たないことだ。
墓石はそれを、何百年も前から知っている。
7. 結び——使うことと、頼ることは違う
使うことと、頼ることは違う。
壊れたら困るものを外部に置くな。
壊れても困らないものは、便利なところに置け。
トキストレージはCloudflare WorkersとGASを使っている。これは事実だ。
しかし、これまで製造したすべてのQRコード、すべての物理製品、NDLに納本されたすべてのニュースレターは、CloudflareにもGASにも一切依存していない。明日両方のサービスが消えても、永続すべきものは何ひとつ失われない。
これは偶然ではない。最初からそう設計した。
外部サービスは道具だ。良い道具は使えばいい。しかし道具に命綱を預けてはならない。命綱は、自分の手の中になければならない。