信頼で書く利用規約

前提の転倒

一般的なWebサービスの利用規約を読むと、ある前提に気づく。「私たちはあなたのデータにアクセスできる。だから、ルールに従ってもらう」という構造だ。データを収集し、行動を監視し、違反を検出し、アカウントを停止する。免責事項と禁止事項は、この権力構造の上に成り立っている。

TokiStorageの利用ガイドラインは、この前提を持たない。すべての処理はユーザーのブラウザ内で完結する。音声も画像もテキストも、サーバーに送信されない。クレジット残高すらブラウザのlocalStorageに保存される。TokiStorageはユーザーのデータにアクセスする手段を持たない。

導出としての利用規約

ここで起きていることの本質は、法務文書のフォーマットが「サーバーがデータを持つ」という暗黙の前提に依存してきたことの露呈だ。利用規約のテンプレートが存在するということ自体が、アーキテクチャの均質性を前提にしている。サーバーがある、データベースがある、ユーザーアカウントがある、管理画面がある。その前提が崩れたとき、テンプレートごと使えなくなる。

普通はそこで「弁護士に相談して新しい規約を作ろう」となる。技術者が設計を説明し、法務が法的言語に翻訳し、その過程で技術的事実は抽象化される。TokiStorageのガイドラインはそうやって作られていない。アーキテクチャの技術的事実を一つずつ書き下ろし、それがそのまま法的文書になるという構造を取った。規約を「書いた」のではなく、設計から「導出した」。

この構造が前例にないのは、法務とエンジニアリングの間にある翻訳レイヤーを消したからだ。通常、技術者が設計し、法務が規約に翻訳し、マーケティングがブランドメッセージに変換する。三つの部門が三つの言語で同じ事実を語る。TokiStorageのガイドラインにはその抽象化がない。「サーバーに送信しない」という一つの事実が、技術仕様であり、免責根拠であり、プライバシー保証であり、ブランドステートメントでもある。一つの事実が四つの機能を同時に果たしている。

8つのセクションの設計意図

TokiQRの利用ガイドラインは8つのセクションで構成されている。それぞれが従来型の規約とは異なる役割を担っている。

セクション1：コンテンツに関するユーザーの責任

従来の規約では「違反コンテンツを発見した場合は削除します」と書く。TokiQRにはその能力がない。データはQRコードの中にあり、TokiStorageのサーバーにはない。だから、最初から明確にする。権利の責任はユーザーにある。これは責任転嫁ではなく、技術的事実の記述だ。

セクション2：TokiStorageの免責

免責条項は通常、サービス提供者を法的リスクから守るための防御文書だ。だがこのセクションは、免責の根拠そのものが異なる。「データにアクセスできないから責任を負えない」という構造的な事実を述べている。TokiQRはオフラインで動作し、データがネットワークを経由しない。監視・追跡する手段がないという告白が、そのまま免責の根拠になる。

セクション3：禁止事項

ここが従来型との最大の分岐点だ。普通の禁止事項は「これをやったらBANします」という警告だ。しかしTokiStorageには検出する手段もBANする手段もない。だから冒頭にこう書いた。「セクション2に記載のとおり、TokiStorageはユーザーのデータにアクセスする手段を持ちません。そのため、以下の禁止事項の遵守はユーザー自身の良心と判断に委ねられています」。これはセクション8「信頼に基づく設計」への橋渡しでもある。禁止事項を書きながら、その遵守を信頼に委ねるという構造は、矛盾ではなく設計だ。

セクション4：「消せない」ことへの注意

一般的なサービスの規約に「消せない」という注意書きは存在しない。削除機能があるのが前提だからだ。しかしQRコードに埋め込まれたデータは、印刷された時点でサーバーから独立する。石英ガラスに刻まれたデータは物理的に削除できない。国立国会図書館に納品されたデータは撤回が極めて困難だ。永続性がサービスの価値であるからこそ、「消せないことのリスク」を利用者に正直に伝える責任がある。

セクション5：TokiQRの技術的特性

このセクションは技術者向けのように見えるが、実は法的にも重要だ。「データはブラウザ内で完結する」「サーバーへの送信は行わない」という記述は、プライバシーポリシーの裏付けでもある。収集しないデータについてプライバシーポリシーを書く必要があるのか、という問いへの答えがここにある。技術的特性を利用規約に明記することで、プライバシーの保証がアーキテクチャレベルで担保されていることを示している。

セクション6：プリペイドクレジットについて

クレジット残高がブラウザに保存されているという事実は、設計上の選択だ。サーバーに残高を持たせればデバイス間同期もできるし、不正操作のリスクも下がる。だがそれは、ユーザーのデータをサーバーに預けることを意味する。TokiStorageはその選択をしなかった。代わりに、「ブラウザデータの消去やデバイスの変更により残高が失われた場合、TokiStorageは復旧の責任を負いません」と明記した。デバイス移行機能もない。QRコードのデータはQRコード自体に、納本対象のデータはGitHubと国立国会図書館にある。デバイスに依存しない設計だからこそ、デバイス移行を実装しないという選択が成り立つ。

セクション7：取り消し・返金について

「取り消し・キャンセルの機能はありません」。これは原則ではなく、技術的事実だ。実装していない。決済は一方向の処理として設計されている。返金が必要な場合は、別トランザクションとして同額を送金する。「返金不可」と書くのではなく「取り消し機能が存在しない」と書くこと。「返金を拒否する」のではなく「同額の送金で対応する」と書くこと。表現が変わるだけで、特定商取引法との整合性も変わる。

セクション8：信頼に基づく設計

ブラウザの開発者ツールを使えばクレジット残高を改変できる。これは隠すべき脆弱性ではなく、設計上の帰結だ。サーバーに認証を置かない以上、クライアントサイドのデータは改変可能になる。TokiStorageはこの事実を隠さず、利用規約に明記した。そのうえで「千年の信頼関係を見据えて、不正や悪意ある操作を実行する前に立ち止まってください」と書いた。セキュリティの穴を告白して信頼を求める。これは従来の利用規約にはない構造だ。

三つの視点から読む

技術者の視点

アーキテクチャが利用規約を決める。サーバーレスでオフライン動作するサービスは、データの収集・監視・削除ができない。この技術的制約を利用規約の言語に翻訳するとき、従来のテンプレートは機能しない。「利用停止」「アカウント凍結」「コンテンツ削除」——これらの措置を規定できないサービスの利用規約は、別の設計原則が必要になる。その原則が「信頼」だ。

法務の視点

特定商取引法や消費者保護法の観点から見ると、「返金不可」と「返金機能が存在しない」は異なる意味を持つ。前者はサービス提供者の拒否、後者はシステムの技術的特性だ。同様に、「禁止事項の遵守をユーザーの良心に委ねる」という記述は、責任放棄ではなく「監視手段を持たない」という技術的事実の法的表現だ。プライバシーファーストのサービスが増える中で、この種の利用規約の書き方は法務の新しいリテラシーになる。

経営者の視点

信頼に基づく利用規約は、ブランドの設計でもある。「データを取らない」ことを技術的特性として持つサービスが「信頼を求める」と書くとき、それは法的文書であると同時にブランドステートメントでもある。千年残すサービスが「千年の信頼関係を見据えて」と利用規約に書く。この一貫性が、プライバシーファーストという選択をマーケティング資産に変える。

従来型との対照表

従来の利用規約がカバーする領域と、TokiStorageのガイドラインを対比すると、構造の違いが鮮明になる。

• データ管理——従来型：「弊社がデータを管理します」。TokiStorage：「データはあなたのブラウザにあります」。
• 違反検出——従来型：「違反を検出した場合、措置を講じます」。TokiStorage：「違反を検出する手段を持ちません」。
• アカウント停止——従来型：「規約違反の場合、アカウントを停止します」。TokiStorage：アカウントが存在しない。
• 削除権限——従来型：「不適切なコンテンツは削除します」。TokiStorage：「一度刻まれたデータは消せません」。
• 返金——従来型：「返金ポリシーに基づき対応します」。TokiStorage：「取り消し機能がありません。同額を別トランザクションで送金します」。
• 信頼の根拠——従来型：サーバーサイドの認証と検証。TokiStorage：千年の信頼関係。

新しい型として

TokiStorageの利用ガイドラインは、特殊な事例に見えるかもしれない。しかしプライバシーファーストのアーキテクチャを採用するサービスが増えるにつれ、この「型」の需要は確実に生まれる。エンドツーエンド暗号化、ゼロナレッジ証明、ローカルファーストなアプリケーション。いずれもサーバーがユーザーデータにアクセスできない設計だ。これらのサービスが利用規約を書くとき、従来のテンプレートはそのまま使えない。

必要なのは、「管理できない」ことを出発点にした利用規約の設計方法論だ。アーキテクチャの制約を正直に記述し、制約の帰結としての責任分界を明確にし、そのうえで信頼を求める。TokiStorageの利用ガイドラインがその一つの型を提示できているとすれば、それは意図してそう書いたのではなく、技術的事実に正直に向き合った結果だ。

テンプレートで済ませられた時代が終わるとき、設計思想から利用規約を導出できる人間が必要になる。それは弁護士でもエンジニアでもなく、両方の言語を持っている人間だ。アーキテクチャの制約を法的言語に翻訳するのではなく、制約そのものが法的文書として成立する地点を見つけること。その能力は、法務概念がコモディティ化してきた時代への根本的な問いかけでもある。

利用規約は法的防御のための文書ではない。サービスの設計思想を、利用者との契約として言語化したものだ。