存在証明とは何か

存在証明（Proof of Existence）とは、誰もが検証できる公開タイムスタンプを用いて、特定のデータがある時点までに存在していたことを示す方法です。

その仕組みは単純です。データをハッシュ化し、そのハッシュをタイムスタンプ付きの公開レコードに公開します。後から、元のデータを持つ人なら誰でもハッシュを再計算し、レコードと照合できます。2 つのハッシュが一致すれば、検証者は同じバイト列がそのレコードの時刻までに存在していたと確認できます。検証者は、公開した人やそのサーバー、そのアカウントを信頼する必要はありません。信頼するのは公開レコードと数学だけです。

ファイルそのものを公開する必要は一切ありません。証明は公開しつつ、コンテンツは非公開のままにできます。

存在証明は何を証明するのか

それは、狭くも有用な 1 つの主張を証明します。

これらの正確なバイト列は、この公開時刻までに存在していました。

基本的な証明が主張するのはこれだけです。そして、その強さは具体性の高さから生まれます。

ほとんどのものは暗号学的ハッシュに還元できます。文書、画像、動画、データセット、ソースコードのアーカイブ、ビルド成果物、契約書、ログファイル、モデル出力、マニフェストなどです。ハッシュは、1 つの正確なバイト列の短い指紋です。1 バイトでも変えれば、指紋は完全に変わります。

そのハッシュが公開レコードに記録されると、レコードは時刻の証人になります。後から元のファイルを誰かに見せると、その人はもう一度ハッシュを計算します。新しいハッシュが記録されたものと一致すれば、目の前のファイルが以前にコミットされたデータと同一であること、つまりレコードのタイムスタンプの時点かそれ以前に存在していたことを確認できます。

このため、存在証明はタイミングが重要な場面でいつでも価値を発揮します。

紛争が起きる前にファイルが存在していたことを示す
監査の期限前にレポートが存在していたことを示す
リリース時点でソフトウェア成果物が存在していたことを示す
改変される前にデータセットのスナップショットが存在していたことを示す
異議を申し立てられる前に AI 出力、プロンプトセット、メディアファイルが存在していたことを示す

証明はファイルの説明ではありません。ファイルの正確なバイト列に対する暗号学的なコミットメントです。

なぜファイルを公開しなくてよいのか

公開される主張がファイルではなくハッシュだからです。

優れたハッシュ関数は、一方向の指紋のように働きます。誰でもファイルからハッシュを計算できますが、ハッシュだけを見た人がそこからファイルを復元することはできません。だからこそ、非公開の文書が公開の証明を担えるのです。レコードは「ある人がこの時刻にこれらの正確なバイト列にコミットした」と語りますが、バイト列そのものは明かしません。

たとえば、ある企業は機密のデータセットマニフェストをハッシュ化し、そのハッシュだけを公開できます。データセットは非公開のままです。後からスナップショットの内容を証明する必要が生じたら、マニフェスト全体、その一部、あるいは単一項目の包含証明のいずれかを、状況に応じて開示できます。

存在証明が法務・コンプライアンス・セキュリティの各チームに適しているのも、このためです。非公開の証拠を公開データベースに置くことなく、外部のタイムスタンプを作り出せます。このパターンの詳細はファイルを公開せずに機密情報を開示するをご覧ください。

ブロックチェーンはどんな役割を果たすのか

ブロックチェーンは公開された時刻の証人です。発行者を含め、誰も密かに書き換えられない部分です。

ハッシュが自分のデータベースの中にしか存在しないなら、証明は自分のシステムに完全に依存します。後からタイムスタンプが疑われたとき、データベースが書き換えられたのではないか、バックアップから復元されたのではないか、管理者に編集されたのではないか、日付を遡って記録されたのではないか、と問われても無理はありません。公開ブロックチェーンはその疑念を取り除きます。トランザクションが確認されると、タイムスタンプ付きレコードは誰の目にも見えるようになり、もはや発行者だけの管理下にはありません。

CardanoWall では、証明レコードを Cardano のトランザクションメタデータに、メタデータラベル 309 の下で記録します。検証者は、自分で選んだ公開の Cardano エクスプローラーからトランザクションを取得し、レコードを読み、コンテンツのハッシュを元のバイト列と照合します。このチェックに CardanoWall のサーバーは一切関与しません。証明が私たちなしで成立すること、それこそが要点です。

ブロックチェーンは文書の中身を理解しませんし、理解する必要もありません。ブロックチェーンは証明データを記録するだけです。意味は、検証者がハッシュを再計算し、バイト列の一致を確認することから生まれます。

最も単純な証明とは

最も単純な証明はハッシュのみのものです。

ファイルを 1 つ選びます。ソフトウェアが SHA-256 や BLAKE2b-256 などのハッシュを計算します。そのハッシュが、Cardano メタデータに公開されるレコードに入ります。後から検証者が元のファイルで同じハッシュ計算を繰り返し、ダイジェストが一致すれば証明は通ります。

つまり、最初のレベルは 3 つの事実に集約されます。

コンテンツが存在する。
そのハッシュがチェーン上に記録されている。
元のコンテンツを持つ人なら誰でも一致を検証できる。

多くの用途では、これで十分です。タイムスタンプ付きのハッシュが強力なのは、まさにそれが単純だからです。設定を誤る余地はほとんどなく、信頼すべきものもありません。

ハッシュだけでは不十分なのはどんなときか

単なるハッシュは 1 つの問いにはよく答えますが、あらゆる問いに答えるわけではありません。

それは誰がファイルを作成したのかを語りません。バイト列が存在したことを示すだけです。同じ公開 PDF を 2 人が持っていれば、どちらもそのハッシュを公開できます。ハッシュだけでは作成者について何も語れません。

それはファイルを保存しません。元のバイト列を失えば、公開ハッシュは残っても、照合する相手が何もなくなってしまうかもしれません。

そして、それはファイルを誰にも届けません。別の人が元のデータを必要としても、単なるハッシュではそれを渡せません。

だからこそ、基盤となるレコード形式は階層構造になっています。ハッシュのみのレコードも完全に有効ですが、この標準は署名、封印された（暗号化された）ペイロード、受信者宛ての配信、Merkle バッチ処理にも対応します。それぞれが、タイムスタンプの上に 1 つずつ機能を追加します。

署名は証明をどう変えるのか

署名は、鍵に裏打ちされた主張を追加します。

署名付きレコードは「これらのバイト列はこの時刻までに存在した」だけでなく、もっと多くを語れます。「この鍵がこのレコードに署名した」とも語れるのです。これは作成者性、承認、内部統制、業務ワークフローにおいて重要です。組織は署名鍵を使って、特定のシステム、チーム、アイデンティティがレコードの裏付けとなったことを示せますし、制作者は証明に署名して自分のアイデンティティを作品に結び付けられます。

ただし、表現は正確に保つ必要があります。署名は、その鍵がレコードに署名したことを示すのであって、現実世界で誰がその鍵を保有しているかは示しません。鍵を人物に結び付けるには、レコードの外で確立された文脈が必要です。（CardanoWall は設計上、署名を任意としています。誰でも公開でき、検証者が発行者を信頼する必要は決してありません。）

封印は証明をどう変えるのか

封印付き証明は、暗号化された保存を追加します。

封印付きレコードでも、オンチェーンの証明は依然として平文のハッシュにコミットします。しかしファイルそのものは暗号化され、コンテンツアドレス指定の保存先、つまり ar://（Arweave）や ipfs:// のアドレスに保存され、レコードにはその参照だけが入ります。チェーンが平文を見ることはありません。

これは、元のファイルを失うとハッシュが使いにくくなる場面で重要です。封印付き証明があれば、正しい鍵を持つ人は後から保存された暗号文を取得し、復号し、平文のハッシュを再計算して、復号したファイルがチェーン上にコミットされたコンテンツとまったく同じであることを確認できます。保存先のアドレスはバイト列そのものから導出されるため、受信者はストレージゲートウェイを信頼することなく、そのゲートウェイが正しいバイト列を返したことも判断できます。

公開チェーンが平文を露出させる必要は一切ありません。暗号化されたペイロードは証明とともに移動し、復号鍵はそれを保持すべき人の手元に留まります。

受信者への配信は証明をどう変えるのか

受信者への配信により、封印付きレコードを他人宛てに暗号化できます。

受信者の受信アドレス（その人が共有した公開鍵）が分かれば、その人だけが自分の鍵で開封できる封印付きレコードを公開できます。注目すべきは、レコードには「これはアリス宛て」と記すフィールドがないことです。チェーン上に宛先は一切ありません。受信者のソフトウェアが公開レコードを走査し、自分の鍵宛ての可能性があるものを密かに試行復号（trial-decrypt）し、実際に自分宛てだったものだけを開封します。

これにより、存在証明は個人的なタイムスタンプ付与にとどまらないものになります。機密情報の開示、法的証拠の交換、非公開のコンプライアンスパッケージ、内部監査の引き継ぎなど、タイムラインは公開すべきだがコンテンツは公開してはならないワークフローを支えられます。ただし、誰かに何かを封印する前に、その鍵が本当にその人のものか確かめる価値があります。ファイルを封印する前に受信者を検証するをご覧ください。

正直に言えば、1 つの限界があります。暗号化が守るのはバイト列であって、人ではありません。封印は平文を鍵の保有者だけが読める状態に保ちますが、匿名性を保証するものではなく、受信者は一度復号すればいつでも平文を漏らせます。

Merkle バッチ処理は証明をどう変えるのか

Merkle バッチ処理により、1 つのレコードで多数の項目に一度にコミットできます。

ファイルごとに 1 つのトランザクションを使うのではなく、システムは数千、数百万の項目をハッシュ化し、それらのハッシュを Merkle ツリーに畳み込み、単一の 32 バイトのルートを公開できます。後から包含証明によって、特定の 1 項目がコミットされたバッチの一部であったことを示せます。検証者はすべてのファイルがチェーン上にある必要はありません。ルートが公開のコミットメントであり、短い包含証明（バッチサイズの対数でしか増えないもの）が個々の項目をそのルートへと結び付けます。バッチ内のほかの項目はすべて非公開のままです。

これは大量処理のワークフローに適しています。

CI/CD 成果物とリリースマニフェスト
日次のコンプライアンスログ
大規模に生成される AI コンテンツ
データセットのスナップショット
監査証拠のフォルダ
メディアおよび出版アーカイブ

Merkle モードは、オンチェーンのレコードを極小に保ちながら、1 つの証明で膨大な項目の集合をカバーできるようにします。実例については数千ファイルを 1 レコードでをご覧ください。

存在証明は何を証明しないのか

このセクションこそ、証明を正直に保つものです。タイムスタンプ付きのコミットメントが強いのは、それが具体的だからです。そして具体的であるということは、そもそも行わない主張があるということです。

それは、文書が真実であることを証明しません。偽の文書も、真の文書と同じくらい簡単にタイムスタンプを付与できます。

それは、所有権を証明しません。誰でも、自分が所有していないファイルをハッシュ化できます。

それは、それ自体では作成者性を証明しません。作成者性には、署名、鍵管理、そして現実世界の文脈を上に重ねる必要があります。

それは、ソフトウェアのビルドが安全であることを証明しません。ある時点でどの成果物、SBOM、ログ、マニフェストが存在したかは示せますが、安全性はビルドプロセスとそれを取り巻く統制に依存します。

それは、データセットが合法的に収集・利用されたことを証明しません。データセットのコミットメントが存在したことは示せますし、それは重要な証拠になり得ますが、法的権利は別の問題であり、各自の管轄区域と顧問の判断に依存します。

要するに、存在証明が与えるのはタイミングと完全性であって、真実や権利ではありません。それ以上の主張は、この基盤の上に慎重に組み立てる必要があります。証明が証明しないことでは、その線引きがどこにあるのかをさらに掘り下げています。

なぜ CardanoWall は Label 309 を基盤とするのか

証明は、可搬性がある分だけ有用です。1 つのウェブサイトの中だけで機能するものは、たいした証明ではありません。本物の証明は、独立したツールで読め、公開インフラから検証でき、元のサービスが書いたわけではないソフトウェアにも理解されるべきです。

だからこそ CardanoWall は Label 309 を基盤としています。これは Cardano 上の存在証明のための、オープンでベンダー中立な標準です。耐久性のある成果物は CardanoWall アプリではなく Label 309 です。ウェブアプリ、コマンドラインツール、SDK は、その下流にあるリファレンス実装です。この標準は、単なるタイムスタンプから上へとスケールする 1 つのレコード形式を定義します。

単純な存在のためのハッシュのみの証明
鍵に裏打ちされた作成者性の主張のための署名付き証明
暗号化された保存のための封印付き証明
非公開の配信のための受信者封印付き証明
大量バッチのための Merkle 証明
名前付きアルゴリズム識別子。これにより、古いレコードを壊すことなく暗号方式を時とともに進化させられます

この形式は公開レビューにもかけられています。メタデータラベル 309 の下での存在証明は Cardano CIP プロセスに提出され、Metadata カテゴリの提案として CIP エディターの審査を受けています。（メタデータラベル 309 はオンチェーンの識別子であり、CIP 番号はプロセスによって別途付与されます。）標準の全文、そのリファレンス実装、そしてオープンソースのコードは、すべて寛容なライセンスのもとで github.com/cardanowall に公開されています。

CardanoWall はインターフェースです。Label 309 はレコード形式です。証明は、その両方より長く生き続けるように設計されています。証明の公開を手助けしたインターフェースも、会社も、です。

さらに読む

Label 309 の仕組み（すべての CardanoWall の証明を支える標準）
ブロックチェーンに載るもの（どのバイト列が公開され、どれがご自分のデバイスから決して出ないのか）
Label 309 レコードを検証する（公開インフラだけを使って、自分で証明をチェックする方法）
存在証明をほかのタイムスタンプおよび来歴システムと比較する: OpenTimestamps との比較、タイムスタンプ局との比較、C2PA / Content Credentials との比較。