法的証拠と eディスカバリー：文書とディスカバリーのエクスポートにタイムスタンプを付与する

存在証明（Proof of Existence）を使うと、法務チームはファイルについて 2 つのことを示せます。特定の公開された時刻までにそのファイルが存在していたこと、そして後から提出された複製が同じバイト列であることです。文書、証拠一式、あるいはディスカバリーのエクスポートをハッシュ化し、そのハッシュを Label 309 のもとで Cardano ブロックチェーンに公開し、元のファイルとトランザクション参照を保管しておきます。後から誰でも（相手方の弁護士や裁判所が選任した専門家を含めて）、そのハッシュを再計算し、公開チェーンと照合して一致を確認できます。しかも、ご自分のサーバーを信頼する必要はありません。

一方で、存在証明は証拠を許容可能・真正・秘匿特権付き・完全・法的に十分なものにするわけではありません。タイムスタンプは、はるかに大きなプロセスのなかの一つの裏付けとなる事実にすぎません。真正性と完全性に関する説明を補強することはできますが、事件そのものを決着させることはできません。完全性とタイミングのレイヤーとして扱い、訴訟で何らかの証明システムに頼る前には弁護士に相談してください。

タイムスタンプは実際にどんな問題を解決するのか

法的紛争はタイムラインを軸に展開し、そのタイムラインはしばしば争われます。

チームは多くの場合、次のような問いに答える必要があります。

この文書は紛争が生じる前に存在していたか
これはレビューまたは提出されたものと同じファイルか
このエクスポートは提出期限の前に作成されたか
これらの特定のファイルは証拠一式に含まれていたか
報告書は最終化された後に改ざんされたか
証拠一式は保全通知が届く前に存在していたか

社内システムは文書やログを保存できますが、それらの記録は一方の当事者が管理するインフラの内部にあるため、ある記載が実際にいつなされたのかを相手方が争うことができます。公開されたタイムスタンプ付きのコミットメントは、そのタイミングの基準点を誰の手も届かない場所へ移します。「このバイト列はブロック時刻 T までに存在していた」という主張は、発行者・ドメイン・サーバーのいずれも信頼することなく、誰でも Cardano チェーンと照合して確認できます。

何にタイムスタンプを付与できるのか

ほとんどあらゆるバイト列です。ハッシュは、そのバイトが何を意味するかを問いません。

法務チームは次のようなものをコミットできます。

契約書と証拠書類
PDF と署名付きの報告書
安定した形式にエクスポートされたメール
ディスカバリーの提出物
フォレンジックイメージやイメージのマニフェスト
証拠保管の連鎖（chain-of-custody）のログ
秘匿特権レビューのログ
証言録取の資料と記録
証拠目録
専門家の報告書
和解案のドラフト
規制当局への提出書類
案件一式のすべて

コンテンツそのものは一切公開する必要がありません。オンチェーンのレコードはハッシュだけを保持できますし、コレクション全体については単一の Merkle ルートを保持できます。証拠について読み取れるものは何一つチェーンに触れません。

単一の文書ではこれはどう機能するのか

1 つのファイルなら、流れは短いものです。

文書を作成または収集します。
そのハッシュを計算します。
ハッシュを Label 309 レコードに公開します。
元のファイルとトランザクション参照を一緒に保管します。
後で、ファイルからハッシュを再計算します。
それをオンチェーンのレコードと照合します。

ハッシュが一致すれば、手元のファイルはトランザクションの時点でコミットされたものと同じバイト列です。これこそ、紛争でしばしば必要とされる完全性とタイミングのペアです。バイトは変更されておらず、既知の公開された時点までに存在していた、というわけです。

大規模な証拠セットではこれはどう機能するのか

一つの巨大なアーカイブのハッシュではなく、マニフェストと Merkle ルートを使います。

ディスカバリーが単一のファイルとして届くことはまずありません。届くのはフォルダ、エクスポート、提出物のセット、フォレンジックのコレクションです。一つの大きな zip をハッシュ化することもできますが、その場合、検証のたびに全体を再ハッシュすることになり、1 バイトでも変われば、どこが変わったのかを指し示す手段がないままコミットメント全体が無効になります。マニフェストと Merkle ツリーがこれを解決します。

マニフェストはすべてのファイルとそのダイジェストを列挙します。Merkle ルートは順序付けられたリスト全体を単一の 32 バイトの値にコミットし、そのルートだけを単一のトランザクションで公開します。後から当事者は、残りの一式を開示したり再処理したりすることなく、ある特定のファイルがセットに含まれていたことをコンパクトな包含証明で証明できます。この包含証明はバッチサイズの対数でしか増えません。ツリーの構築と包含証明の検証は純粋にオフラインの計算であり、ゲートウェイに触れるのはルートの公開だけです。同じパターンによって、単一の証明が数千のファイルまでスケールします。これについては 1 つのレコードで数千のファイルをで扱っています。

これは次のような場面に適しています。

eディスカバリーの提出物
文書レビューのエクスポート
証拠室の目録
フォレンジックのコレクション
規制当局への対応パッケージ
内部調査の一式

ルートがセットを固定します。マニフェストがそれを説明します。

法的証拠は封印すべきか

多くの場合、はい、です。証拠の大半は秘匿特権付き・機密・個人情報・営業上の機微な情報であり、平文を公開するのは誤りだからです。

機密性の高まる順に、3 つのアプローチがあります。

ハッシュのみの証明： コミットメントだけを公開し、証拠は完全に非公開のままにします。コンテンツについては、そのハッシュ以外、何一つチェーンに載りません。
Merkle 証明： 多数の非公開ファイルに対して 1 つのルートを公開し、個々の包含証明は、それを受け取る権利のある当事者にのみ開示します。
封印付き証明： 証拠またはマニフェストを暗号化し、その暗号文を、権限を持つ受信者が取得できる場所に保管します。チェーンが運ぶのは依然として平文のハッシュ、ブロック時刻、ラップされた鍵だけであり、平文も、誰が受信者であるかも決して載りません。

元のバイトを後から復元可能にしておきつつ、いまは公開してはならない場合、封印付きレコードが適切なツールです。受信者はクライアント側で復号し、平文のハッシュを再計算してオンチェーンのコミットメントと照合します。ただし限界は明確にしておいてください。封印は平文を鍵の保有者だけが読める状態に保ちますが、匿名性を保証するものではなく、受信者は復号した後に平文を漏えいさせることが常に可能です。ファイルを機密に保ちつつ何かが存在したことを証明するというパターンは、公開ファイルなしの機密開示で掘り下げています。

これは証拠保管の連鎖の代わりになるか

なりません。存在証明は証拠保管の連鎖を支えるものであり、その代わりにはなりません。

証拠保管の連鎖は人とプロセスに関わるものです。誰が証拠を収集したか、どう保管されたか、誰がアクセスできたか、どう移送されたか、どんなツールが使われたか、手順が守られたか、そして資料が改ざんから保護されていたか、です。Label 309 の証明は、ファイルやマニフェストが公開された時刻までに存在していたこと、そして後の複製がコミットされたハッシュと一致することを示せます。しかし、誰がそのバイトを扱ったか、どのように扱ったかについては何も語りません。

より広く文書化された証拠プロセスのなかで、完全性とタイムスタンプを担う一つのレイヤーとして使ってください。プロセスそのものとしてではありません。

タイムスタンプは証拠を許容可能にできるか

それ単独ではできません。許容性は、法域、裁判所の規則、事件の文脈、真正性、関連性、伝聞、秘匿特権、ディスカバリー規則、専門家証言、その他多くに左右されます。

米国連邦実務からの具体例を挙げます。これは法域に依存し、法的助言ではありません。Federal Rule of Evidence 901(a) のもとでは、提出者は「その物が提出者の主張するとおりのものであると認定するに足る証拠を提出」しなければなりません。暗号学的なタイムスタンプはこの認定に、とりわけ完全性とタイミングの点で寄与し得ますが、それが基盤のすべてではありません。Rule 901(b)(9) は「あるプロセスまたはシステムを説明し、それが正確な結果を生み出すことを示す」ことによる認証を認めており、検証可能なハッシュコミットメントが居場所とするのはまさにこの領域です。Rule 902(14) はさらに踏み込み、ハッシュ値などのデジタル識別によって「電子機器、記憶媒体、またはファイルから複製されたデータ」を認証することを具体的に想定しています。これらはいずれも自動的なものではありません。相手方は依然として真正性を争い、その他の異議を申し立てることができますし、ほかの法域では電子証拠の扱いが異なります。

ですから証明は「支える場合があります」「助けになり得ます」。許容性を保証したり、所有権を証明したり、著作者性を決着させたりするものではありません。それが案件にどう適合するかは弁護士が判断します。

証拠マニフェストには何を含めるべきか

明確で、安定していて、再現可能な状態に保ってください。

法的証拠のマニフェストは次のような項目を記録できます。

事件または案件の ID
収集日
管理者（カストディアン）または情報源
ファイル名または中立的な識別子
ファイルサイズ
ハッシュアルゴリズム
ダイジェスト
秘匿特権の状態
機密区分の状態
収集ツールのバージョン
レビュー担当者または承認者
保存場所
Merkle のリーフインデックス
包含証明の参照
Label 309 のトランザクション参照

弁護士が承認していない限り、公開されることになるマニフェストに秘匿特権付きの事実や機微な事実を記載しないでください。マニフェスト自体は非公開のままにすることも封印することもできます。チェーンに載せる必要があるのはそのルートだけです。

レコードへの署名は何の役に立つのか

署名は、特定の鍵がレコード本体を保証したことを示します。これは Label 309 では任意です。標準は発行者に依存せず、署名がまったくなくても証明は完全に有効です。とはいえ、説明責任が重要になる場合もあります。

署名付きレコードは次のような主体が作成し得ます。

法律事務所のアイデンティティ
企業の法務部門
eディスカバリーのベンダー
フォレンジックチーム
コンプライアンス担当者
指定された証拠管理者

署名はいかなる法的事実も証明しません。署名鍵がレコード本体に署名したという、それだけを証明します。それに依拠する者は、誰がその鍵を管理しているのか、その署名プロセスが何を意味するのかを依然として説明しなければなりません。暗号は鍵を証明するのであって、その背後にある組織を証明するものではないのです。

レコードが変わるとき、置き換え（supersedence）は何の役に立つのか

法的記録は訂正され、補充され、改訂されます。マニフェストは作り直され、提出物のセットは補充され、報告書は修正され、秘匿特権ログは更新されます。

Label 309 は任意の置き換えポインタを保持します。新しいレコードのなかに、より古いレコードを指す 32 バイトのトランザクションハッシュを持たせるものです。このポインタは、先行するレコードを削除・取消し・無効化しません。チェーンは追記専用であり、検証ツールは、より古いレコードを依然として存在し独立して検証可能なものとして扱い続けなければなりません。これは単に、訂正からそれが訂正した対象への、可視でサービスに依存しないリンクを作るだけです。

その可視性こそが眼目です。法的な経緯は静かに消えるべきではありません。訂正は訂正として読み取れるべきであり、両方のバージョンが証明可能であるべきです。

何がうまくいかなくなり得るのか

たくさんあります。そしてその大半は暗号ではなく、プロセスの問題です。

チームは誤ったファイルをハッシュ化してしまうことがあります。元のバイトを失うこともあります。マニフェストやリーフリストを保全し損ね、有効なルートだけが残って、それに対する証明を誰も構築できなくなることもあります。誤って機微なデータを開示してしまうこともあります。誰も管理していない鍵で署名してしまうこともあります。背後に文書化された手順のないまま証明を振りかざしてしまうこともあります。

証明が暗号学的に健全であっても、周囲のプロセスがずさんであれば、法的にはなお弱いものになり得ます。より広い限界もここで当てはまります。存在証明は、特定のバイトが公開された時刻までに存在していたことを示すものであり、真実・所有権・著作者性・適法性・排他的権利を証明するものではありません。この境界は身につけておく価値があり、証明が証明しないことで説明しています。

法的に良い使い方には、ハッシュだけでなく手順が必要です。

要点

Label 309 は法務チームが証拠にタイムスタンプを付与するのを助けます。文書をハッシュ化し、証拠セットには Merkle ルートを使い、機微な資料を封印し、説明責任が重要なときはレコードに署名します。マニフェスト、リーフリスト、トランザクション参照、元のファイルを一緒に保全してください。入力を再構築できない証明には、ほとんど価値がありません。

証明は完全性とタイミングを示せます。証拠保管の連鎖、法的判断、裁判所の規則の代わりにはならず、真実や所有権を決めることも決してありません。健全なプロセスのなかで使えば、どの単一の当事者も支配しない基準点をタイムラインに与えます。

さらに読む

公開された Label 309 標準とその仕様：label309.org。
リファレンス実装（各種 SDK と cardanowall コマンドラインツール）はオープンソースで、github.com/cardanowall にあります。
本提案は Cardano の CIP プロセスに提出され、メタデータカテゴリの CIP として CIP エディターによるレビュー中です：pull request #1205。
Federal Rule of Evidence 901 — 証拠の認証または識別：law.cornell.edu/rules/fre/rule_901。
Federal Rule of Evidence 902 — 自己認証する証拠（902(13) および 902(14) を参照）：law.cornell.edu/rules/fre/rule_902。