あらゆるデジタル製品は、人や物に関するデータを記録することから始まります。データがアプリケーション、ベンダー、データベース、そして時にはブロックチェーンを経由するにつれ、責任の所在は曖昧に感じられるかもしれません。しかし、ブロックチェーンは管理を分散させることはできても、説明責任を消滅させることはできません。
中央のデータベース管理者が不在であることは、意思決定や義務、あるいはその結果が不在であることを意味しません。システムに何を入力し、なぜそれが必要で、どのくらいの期間保持すべきか、そして誤りがあった場合にどう対処するかを決定する主体は依然として存在します。
データに「所有者不在」は存在しない
所有権はあくまで法的な比喩の一つに過ぎません。より実践的な問いは、「データライフサイクルの各段階において、誰がどのような責任を負うのか」という点です。データによって記述される本人には権利があり、データの利用目的や方法を決定する当事者がルールを定めます。サービス提供者はストレージやセキュリティを実装し、エンジニアはポリシーをスキーマや権限設定に変換します。インフラ運用者はシステムの可用性を維持し、監査人や規制当局が監視を行います。
GDPR（EU一般データ保護規則）の下では、管理者が処理の目的と手段を決定し、処理者が管理者に代わって実行します。管理者は、目的の制限、データ最小化、正確性、保存期間の制限といった原則に準拠していることを証明しなければなりません。この構造は管轄区域を超えて適用されます。収集は必要だったか？本人は通知を受けていたか？誤りは修正可能か？苦情に対応できる実在の当事者が存在するか？といった問いが重要です。
ブロックチェーンが変えるもの、変えないもの
従来のアプリケーションでは、一人の運用者がレコードの編集、取り消し、削除を行う広範な技術的権限を持っています。その権限は修正を可能にする一方で、検閲や改ざんの温床にもなります。ブロックチェーンはこれを変えます。複数のノードが順序付けられた履歴を複製し、共通のルールに基づいて変更を検証することで、一方的な書き換えを困難にします。NIST（米国国立標準技術研究所）は、ブロックチェーンを魔法のように不変なものではなく、「改ざん検知可能（tamper-evident）」かつ「改ざん耐性がある（tamper-resistant）」ものと定義しています。
これにより、新たなトレードオフが生じます。許可なく記録を変更することが困難になればなるほど、正当な理由で変更が必要になった際の修正も困難になるのです。責任は消滅するのではなく、移動します。アプリケーション設計者は何を送信するかを決め、プロトコル開発者は有効な状態遷移を定義し、バリデーターはルールを強制し、ノード運用者は履歴を複製し、ガバナンスがソフトウェアの進化を決定します。フランスのCNIL（情報処理自由国家委員会）も同様の結論に達しており、データを登録することを決定した参加者は管理者と見なされ得ると述べています。「プロトコルが勝手にやった」という言い訳は、説明責任のモデルとして通用しません。
データをオンチェーンに書き込むべき時
ブロックチェーンが正当化されるのは、複数の当事者が共有状態を必要とし、互いを完全には信頼しておらず、順序付けと来歴を必要とし、独立した検証を重視し、かつその記録が正当に永続的であるべき場合です。そのため、コンセンサスに不可欠な状態（残高、送金）、公開の確約（タイムスタンプ付きハッシュ）、ステータスや取り消しのレジストリ、共有の監査イベント、検閲耐性のある通信状態などにおいて、オンチェーンストレージは説得力を持ちます。永続性は製品の一部であり、副作用ではありません。
データをオフチェーンに留めるべき時
ほとんどのアプリケーションデータは、上記の条件を満たしません。生の個人プロフィール、病歴、プライベートな文書、変更可能な設定、大容量のメディアファイルなどは、永続的な複製には不向きです。レコードを暗号化すれば現在は内容を保護できますが、暗号文は何十年も残る可能性があります。鍵の漏洩、アルゴリズムの老朽化、メタデータによる関係性の露呈といったリスクがあります。「鍵を削除する（クリプトシュレッディング）」ことは、すべてのコピーを削除することと同義ではありません。ハッシュは自動的に匿名になるわけではなく、個人と紐付けられたり、小さな入力セットと比較されたりすれば、仮名化された個人データとして機能する可能性があります。
NISTによるプライバシー保護を強化した分散型台帳に関する研究は、従来の不変性が、修正や削除を求めるプライバシー規則と衝突する可能性があるという観察から始まっています。研究者たちは、整合性を維持しつつ制御された消去を可能にする、修正可能な台帳構造を模索しています。ブロックチェーンは一つの神聖なデータ構造ではなく、設計の選択肢の一つに過ぎません。
実践的なデフォルト：オンチェーンで証明し、オフチェーンで保存する
多くの製品にとって、最も強力なアーキテクチャはハイブリッド型です。機密レコードは暗号化されたアクセス制御システムに保持し、最小限の証明のみをオンチェーンに置くことです。文書はオフチェーンに保存し、ハッシュをオンチェーンにアンカーします。選択的開示が可能な検証可能なクレデンシャル（Verifiable Credentials）を発行し、機密内容を含まない取り消しエントリを公開します。バージョン管理を用いて修正された状態を認識し、ローテーション可能な鍵で暗号化し、保持ポリシーを定義します。
W3Cの検証可能なクレデンシャルモデルは、発行者、保持者、主体、検証者を分離します。個人はアイデンティティ記録全体をさらすことなく、事実を証明できます。目標は、信頼をポータブルにしつつ、共有する情報を最小限にすることです。
時には、ブロックチェーンが全く不要な場合もあります。適切に管理されたデータベースは、暗号化、アクセス制御、署名付き監査イベント、迅速な修正を提供します。Merkleツリーを用いた透明性ログ（Certificate Transparency, RFC 9162など）は、分散コンセンサスなしで包含証明を提供します。決定的な問いは「ブロックチェーンを使えるか？」ではなく、「私たちはどの失敗を防ごうとしているのか？」です。
最初のトランザクション前の7つの質問
データを永続化する前に、プロジェクトは以下の質問に平易な言葉で答える必要があります。検証すべき正確な主張は何か？誰が状態に同意する必要があるか？一人の責任ある運用者で許容できるか？データが誤りや有害なもの、あるいは法的に消去すべきものになる可能性はあるか？証明でペイロードを代替できるか？修正や救済は誰が担当するか？20年後に鍵の侵害や暗号技術の老朽化が発生した場合、どう対処するか？
ADAMANT：転送のための永続性、コンテンツのためのプライバシー
ADAMANTは、意図的なトレードオフの具体的な例を提供しています。このネットワークは、通信のための分散型信頼レイヤーとして、Delegated Proof of Stake（DPoS）ブロックチェーンを使用しています。クライアントは、共有されたトランザクション履歴を保存するために、特定の企業のサーバーを信頼する必要はありません。
しかし、ブロックチェーンは平文を公開する言い訳にはなりません。ADAMANTのドキュメントによると、メッセージのトランザクション資産は、トランザクションにパックされ、署名され、ブロードキャストされる前に暗号化されます。基本的なチャットにはNaCl boxに基づく認証付き公開鍵暗号が使用され、キーバリューストアにはNaCl secretboxが使用されます。クライアントは暗号化処理をローカルで行います。
暗号化されたメッセージ本体はプライベートなままですが、ネットワークはアクティビティを検証およびルーティングするために、送信者、受信者、タイムスタンプ、手数料、署名といったトランザクションメタデータを必要とします。暗号化はコンテンツを保護しますが、すべての関係性を不可視にするわけではありません。ADAMANTのアーキテクチャは、ブロックチェーンの正当な利用事例を示しています。ある企業がアカウントを閉鎖したからといって通信が消滅してはなりませんが、システムは公開ノードがプライベートなメッセージ自体について理解する必要がある情報を最小限に抑えています。
責任は機能である
信頼性の高い製品は、最も多くのデータを収集したり、すべてのデータベースを不変だと宣言したりすることで成功するわけではありません。責任の所在を明確にすることで成功します。ユーザーは何が記録され、何がプライベートなままなのかを知るべきです。開発者は各フィールドが存在する理由を説明すべきです。運用者は自身のセキュリティ上の義務を認識すべきです。ガバナンスは修正への道筋を提供すべきです。分散化は、説明責任を排除することなく不要な制御を排除する際に、最も強力な力を発揮します。ブロックチェーンは、物語のすべてではなく、証明を運ぶときに最も強力になります。
オフチェーン、ハイブリッド、オンチェーンのデータ保存を選択するための実践的な意思決定マップ。