機密情報の撤廃
—— ポリシーはロジをも変容する

1. 原則——サーバーに何も持たない

TokiQRのサーバーはわずか3MBだ。音声データはQRコード紙面のURL内に符号化されている。サーバーにユーザーデータベースはない。アカウントもない。セッションもcookieもない。録音も再生もすべてブラウザ上で完結し、サーバーは静的ファイルを配信するだけだ。

これは偶然ではない。「個人情報をサーバーに持たない」という原則を設計制約として置いた結果だ。データがなければ漏洩もない。サーバーが落ちてもQRコードは読み取れる。依存関係を極限まで削ぎ落とした構造が、1000年保存という使命と整合する。

2. 例外——「配送は特別」という判断

しかし、物理商品を売るとなると話が変わった。ラミネートQRシートやクォーツガラスQRは、形あるものだ。形あるものは届けなければならない。届けるには住所がいる。住所を聞くには名前と連絡先がいる。

「配送は特別だから仕方ない」——そう判断して、注文フォームに住所欄を設け、備考欄を用意し、配送ステータスの管理機能を実装した。通貨の選択肢も加えた。ポリシーに例外が生まれた瞬間だった。

例外は小さく見えた。配送に必要な情報だけだ。しかし例外は一度認めると、次の例外を呼ぶ。配送管理のためにステータス遷移が生まれ、発送通知のためにメールアドレスが求められ、未発送の追跡のためにレポートが複雑になる。例外は静かに根を張っていた。

3. 転機——バルクモードと特集権

変化は、決済フローの進化から始まった。

マルチQRクレジットコードの仕組みを作った。Wiseに入金すると、referenceに含まれた注文コード（TOKI-XXXX-XXXX-XXXX）がWebhookで自動検出され、コードが発行される。ユーザーはフロントエンドでコードを入力するだけでアクティベートできる。住所を聞く場面がどこにもない。

特集権（NDL納本権）も同じフローで購入できるようにした。Wise Pay Linkで支払い、コードを受け取り、アクティベートする。KYCはWise側で完結する。TokiStorage側は金額とコードだけを見ている。

ここで気づいた。デジタル商品の決済は、すでに個人情報なしで回っている。物理商品だけが例外として残っている。

4. 振り返り——運用の視座から

開発フェーズでは「必要だから作る」と考える。しかし運用フェーズに入ると「本当に必要か？」と問い直す余裕が生まれる。

配送という概念を前提にしていたが、実態を見つめ直した。

DIY——顧客が自分で印刷する場合、配送は存在しない。データはQR URLとして渡るだけだ。ラミネート加工も市販のラミネーターで完結する。

保管拠点製造——佐渡やMauiの保管拠点で製造する場合、製品はそのまま現地に保管される。「届ける先」と「保管する場所」が同じだ。物流は発生しない。

つまり、配送先と保管先が同一であるなら、物流という概念自体が消滅する。配送が必要だという前提が、そもそも正しくなかった。

納期という制約

そしてもう一つ、見落としていた制約があった。「いつ届くんですか」——配送には納期がつきまとう。1件ごとに発送する前提では、注文のたびに製造し、梱包し、追跡番号を発行し、配送日数を気にしなければならない。外注すれば送料と管理コストが積み上がる。

しかし保管拠点での製造なら、この制約からも解放される。GitHub保管とNDL納本は注文の翌日に自動完了する。顧客の音声データはデジタルで即日保全される。物理商品は「届けるもの」ではなく「保管するもの」だから、製造は創業者が拠点に滞在するタイミングでまとめて行えばいい。1週間後でも半年後でも構わない。配送日数という概念自体が消える。

まとめて製造する自由

まとめて製造できるなら、選択肢も広がる。現地で機材や素材を調達してもいい。拠点ごとに製造方法を変えてもいい。現地の業者にまとめて依頼することもできる。1件ごとの配送を前提にしたときには見えなかった柔軟性が、物流を手放した瞬間に現れた。バーンレートゼロの設計思想と、完全に整合する。

5. 撤廃——例外をなくす

気づいてしまえば、あとは実装するだけだった。

• 配送ステータス（発送済み・配送済み）をシステムから削除
• 注文フォームから住所欄・備考欄・通貨選択を削除
• GitHub保管・国会図書館納本を常時有効に（オプションではなく前提）
• 唯一の識別子をWisetag（Wiseアカウント名）に統一
• 決済はWise Pay Link → 注文コード → アクティベーションの一本道
• パートナーへの手数料送金はWisetagからWise APIで自動実行

コードを削除していく過程は、快感に近かった。住所フィールド、備考テキストエリア、USD価格テーブル、配送条件分岐、未発送カウンター——すべて消えた。システムが軽くなっていく。例外がなくなることで、コードもデータフローも劇的にシンプルになった。

6. 何が残ったか

撤廃後、TokiStorageのシステムが保持する個人情報はゼロになった。

Wisetagは識別子として使っているが、これはWise側の公開ユーザー名であり、TokiStorageが管理する個人情報ではない。決済情報はWise側で完結する。住所は配送がないので不要。メールアドレスは通知経路が存在しないので不要。

漏洩するデータが存在しないということは、セキュリティインシデントが構造的に発生しないということだ。暗号化も、アクセス制御も、データ保持期限の設定も、プライバシーポリシーの法的レビューも、そのほとんどが不要になる。守るべきものがなければ、守る仕組みもいらない。

信頼のコストゼロ

この構造は、顧客獲得にも効く。TokiStorageにはモニタープログラムがある。参加に必要なのはWisetagだけだ。メールアドレスも住所も氏名も求めない。「あなたの個人情報を一切持たない」——これは参加のハードルを劇的に下げるメッセージになる。通常、新しいサービスに個人情報を預けることには抵抗がある。しかし預ける情報がそもそも存在しないなら、信頼のコストはゼロだ。ポリシーが、セキュリティだけでなくマーケティングにも効いている。

通知アーキテクチャの変容

副次的な効果もある。顧客のメールアドレスを持っていないから、顧客向けのメール通知がゼロになった。注文確認、発送通知、配送完了——すべて存在しない。残っているのは管理者への内部通知だけだ。将来システムを移行するとき、メール配信基盤もテンプレート管理も顧客通知の設計もまるごと不要になる。個人情報を持たないことが、マイグレーションのロードマップまで軽量化した。

その内部通知も、さらに絞り込んだ。注文のたびに管理者にメールを送る仕組みを廃止し、日次のスケジュールレポートに集約した。決済検知、コード発行、パートナー送金成功——これらはすべて、日次・月次のレポートで十分に把握できる。即時通知が必要なのは、送金失敗のように人間の介入が求められるケースだけだ。

数字で見ると変化は明快だ。改善前は1件の注文で最大3通のメールが飛んでいた——決済検知、注文完了、パートナー送金完了。Google Apps Scriptのメール送信上限は1日100通。つまり1日33件の注文でシステムが詰まる計算だった。改善後は、日次レポート1通、月次レポート1通、あとは障害時のアラートだけだ。注文件数にかかわらず、1日に2通程度しか送らない。送信上限がスケーラビリティの天井でなくなった。

7. ポリシーはロジを変容する

通常、ビジネスの設計はこの順序で進む。ビジネスモデルを決め、物流を設計し、プライバシーポリシーがそれに追従する。ポリシーは現実の後追いだ。

TokiStorageでは順序が逆になった。「個人情報を持たない」というポリシーが先にあり、それが物流を再設計させた。配送を前提としない商品提供の形を見つけ、物流という概念自体を消滅させた。

ポリシーを「現実の制約に合わせて妥協するもの」と捉えると、例外が一つ、また一つと増えていく。やがてポリシーは形骸化し、「一応こう書いてあるが実態は違う」というものになる。

しかしポリシーを「設計制約」として扱えば、話は変わる。制約があるからこそ、従来の前提を疑い、別の解を探す。配送が必要だという思い込みを手放せたのは、ポリシーが制約として機能していたからだ。

特許を手放したときも同じ構造だった。「独占より普及を」という思想が先にあり、それが知財戦略を変えた。ポリシーが技術の扱いを変え、物流の形を変え、ビジネスモデル全体を変容させていく。

技術的負債の制度化

開発段階で正解だった仕様が、運用段階では最適解でなくなる——これは珍しいことではない。しかしエンタープライズの現場では、気づいたとしても簡単には変えられない。変更管理プロセスが複雑で、予算の承認が必要で、構成変更に伴う不具合リスクを許容できず、コードとドキュメントの整合性を維持する工数が膨大になる。結果、「変えた方がいいと分かっているが、変えない方が安全」という判断が積み重なり、技術的負債が制度化されていく。

バイブコーディングという突破口

ポリシーをコードに反映する——言うのは簡単だが、運用中のシステムで実行するのは別の話だ。動いているものを壊すリスク、影響範囲の見落とし、ロールバックの不安。その躊躇が、ポリシーを理想のまま棚に置かせ、コードは例外を抱えたまま走り続ける。この壁を超える力になったのが、AIとの協働開発——いわゆるバイブコーディングだった。影響範囲の調査、コードの追跡、Before/Afterの整理。躊躇の原因となる「見えない工数」をAIが吸収することで、「やるべきだけど怖い」が「やるべきだからやる」に変わった。ポリシーからコード変更、そして言語化までが一つのセッションで完結する。設計制約が実装に落ちるまでの距離が、劇的に縮まった。

念のために補足しておく。エンタープライズの変更管理プロセスは、規模と責任に応じた合理的な仕組みだ。慎重さには意味がある。ここで述べているのは、TokiStorageのような小規模プロダクトがバイブコーディングで得られた機動力であり、エンタープライズの手法を否定するものではない。また、AIとの協働開発にはAPI利用料というコストが発生する。推敲のサイクルが回しやすくなる分、利用コストは上がりうる。ただし、エンタープライズの変更コスト——変更管理委員会のレビュー、影響分析の工数、テスト環境の構築、ドキュメント更新、承認フロー——が人件費と時間で数週間から数ヶ月を要することと比べれば、API利用料は桁が違う。設計制約が実装に落ちるまでの距離が縮まる恩恵に対して、そのコストは軽微だ。肝要なのは、プロジェクトの特性に応じて最適なガバナンスを選択することだ。TokiStorageの要件が変われば——たとえば医療データを扱うことになれば——安全性を重視した厳格なプロセスを採用することを躊躇しない。機動力は手段であって、目的ではない。

8. 守るものがなければ、守る仕組みもいらない

この軽量なプロセスが、結果的にセキュアソフトウェア開発ライフサイクル（SSDLC）の要件を構造的に満たしていることに気づいた。保持データゼロによる脅威面の消滅。ポリシーが実装を駆動する設計。全変更がプルリクエスト経由でトレーサブル。影響範囲を分類してから変更を実行する影響分析。送信上限のBefore/Afterのような定量検証。そしてコード変更と同一セッションでドキュメント（このエッセイ自体がそうだ）が更新される同期性。エンタープライズが膨大なコストをかけて「データを守る仕組み」を構築するのに対し、TokiStorageは「守るデータを持たない」ことでセキュリティ要件を満たしている。軽量だからといって脆弱なわけではない。むしろ、攻撃面が存在しないという意味で、セキュリティ姿勢はより強固だ。

DevSecOpsの変容

DevSecOpsの姿も変わる。従来のDevSecOpsは、開発パイプラインにセキュリティツールを組み込むことを意味していた。静的解析（SAST）、動的解析（DAST）、依存関係の脆弱性スキャン、シークレット検出、個人情報の漏洩チェック。しかし保持データがゼロなら、スキャンすべきシークレットも、検出すべきPII漏洩も、分類すべきデータも存在しない。DevSecOpsの「Sec」が、ツールチェーンではなくアーキテクチャで充足される。ペネトレーションテストも同様だ。従来のペンテストは「侵入後にどんなデータを窃取できるか」が焦点となる。SQLインジェクションによるデータベース流出、権限昇格による顧客情報へのアクセス——しかし窃取すべきデータが存在しなければ、テストのスコープは大幅に縮小し、工数もコストも激減する。セキュリティは後から追加するレイヤーではなく、設計の時点で織り込まれている。

DevSecOpsが組織運営に載ったとき、しばしば悲劇が起きる。セキュリティ要件の充足に追われるあまり、顧客価値の提供にかかるコストが膨れ上がる。多段階の承認フロー、差し戻し、関係者への根回しと説明——その間に市場は動いている。セキュリティを守ることに忙殺され、市場の変化に目を向ける余裕を失い、気がついたときには淘汰されている。守ることが目的化し、守っている間に守るべきビジネスが失われる構図だ。保持データをゼロにするというポリシーは、この構図をアーキテクチャのレベルで回避する。守るデータがなければ、守るためのプロセスが顧客価値を圧迫することもない。

振り返ると、ユーザーデータベース、認証基盤、セッション管理、配送システム、在庫管理、メール配信基盤、データ暗号化、アクセス制御、監査ログ、DevSecOpsツールチェーン——通常のプロダクトが当然のように構築するものを、すべて「不要」にした。削ったのではない。ポリシーから導出された設計の帰結として、そもそも存在する理由がなくなった。

通常、制約は機能を削る。しかしここでは、制約が不要なものを消した。引き算が価値になっている。3MBのサーバー、バーンレートゼロの運用、個人情報ゼロのセキュリティ姿勢——これらは妥協の産物ではなく、一つのポリシーを設計制約として貫いた結果だ。

そしてこの構造は、パートナーシップの拡張性をも生んでいる。通常、外部との提携で最も時間を要するのは、個人情報の取り扱いに関する合意だ。データの共有範囲、保管責任、漏洩時の責任分界点、プライバシーポリシーのすり合わせ——これだけで契約交渉が何ヶ月もかかる。TokiStorageの場合、「個人情報を一切持ちません」で完結する。データ連携の設計も、責任分界点の協議も、ほぼ丸ごとスキップできる。

たとえばウェディング市場への展開を考えたとき、式場やプランナーとの提携に必要なのは、WisetagとコードベースのフローをTokiStorageが担い、顧客対応はパートナー側が行うという役割分担だけだ。顧客の個人情報はパートナーが持ち、TokiStorageは音声の符号化と保管だけを担う。パートナーから見れば、情報漏洩リスクがゼロの外部サービスを自社のオペレーションに組み込める。導入判断のハードルは極めて低い。

葬儀、介護、自治体の記録保存、文化財のデジタルアーカイブ、教育機関の卒業記念——どの領域でも「音声を1000年残す」というコア機能は変わらない。変わるのはパートナーの顔ぶれとユースケースの文脈だけだ。TokiStorage側のシステムに手を入れる必要がない。3MBのサーバーのまま、何業種にでも展開できる。ゼロPIIが、プラットフォームとしてのスケーラビリティを構造的に担保している。

実際にそれは起きた。ウェディング向けの先端技術演出を専門とするプロダクト開発技術者と会話する機会があり、取り組みをご紹介いただいたその日にウェディング向けブローシャを書き上げ、市内のウェディングホテル10箇所に配布した。出会いからアクションまでの距離がこれほど短いのは、パートナーのデータを預からないアーキテクチャが、連携に必要な合意事項を極限まで減らしているからだ。

ウェディング向けブローシャを見る →

この構造は誰が実現できるのか

大企業には難しい。既存の顧客データベース、KYC/AML義務、レガシーシステム、部門間の合意形成——ゼロPIIへの移行は技術の問題ではなく組織構造の問題になる。個人事業主なら可能だ。意思決定者と実装者が同一で、ポリシーをビジネスモデルに反映する権限が100%ある。中小企業は、創業者がCTOを兼ね、かつグリーンフィールド（新規事業）であれば射程に入る。グローバルスタートアップは最も相性がいいかもしれない。GDPR、CCPA、各国のプライバシー規制をすべてクリアしなければならない文脈で、「持たない」はすべての法域で最強のコンプライアンス戦略になる。

核心は会社の規模ではない。条件は5つある。グリーンフィールドであること——既存データの移行ではなく、最初からゼロPIIで設計できるか。プロダクトの性質——決済やKYCを外部に委譲し、本当にPIIなしで成立するか。意思決定の距離——ポリシーをビジネスモデルに反映する決裁権が、実装者からどれだけ近いか。哲学的確信——ゼロPIIを「あったらいいな」ではなく「設計制約」として扱う意志があるか。そしてタイミング——バイブコーディングが実用化し、ポリシーを即座にコードに反映できる手段が存在する時代に、ちょうどその位置にいるか。

5つの条件の積は、相当に狭い。しかし希少だから記録する意味がある。このエッセイ自体が、その記録だ。

配送は特別だと思っていた。
しかし特別だったのは、配送が必要だという思い込みだった。