← すべての記事

約12分で読めます

学習データを公開せずに証明する方法

非公開のデータセットスナップショットをハッシュまたは Merkle ルートにコミットし、タイムスタンプ付きの証明を 1 つだけ公開します。データは非公開のままで、後から特定のファイル・行・バージョンがコミット済みのセットに含まれていたことを選択的に証明できます。

はい、データセットそのものを公開しなくても、非公開のデータセットが存在したことを証明できます。

手順は短くまとまっています。データセットのマニフェストを作成し、その各エントリをハッシュ化し、それらのハッシュを単一の Merkle ルートにまとめ、Cardano 上に Label 309 の存在証明（Proof of Existence）レコードを 1 つ公開します。データセット自体はご自分の管理下から一切外れません。後から、特定の 1 ファイル・1 行・マニフェストの 1 エントリ、あるいは包含証明だけを開示することで、それがコミット済みのスナップショットに含まれていたことを示せます。それ以上は何も明かしません。

これは、ある時点における事前の保有を証明します。ただしそれ自体が、所有権・著作権の状態・同意・適法な利用を証明するわけではありません。これらは別個の問いであり、別個のレコードを必要とします。

なぜ AI チームにこれが必要なのか

学習データは経営レベルの問題になりました。モデルプロバイダーは、どのデータをいつ保有していたか、それがどこから来たのか、どのように処理されたのか、そしてどのデータセットが特定のモデルバージョンに供給されたのかを示す必要が生じる場合があります。相手は投資家・パートナー・顧客・規制当局・監査人・ライセンサー、あるいは訴訟かもしれません。

その一方で、企業はデータセットを公開できないことが少なくありません。データにはライセンス対象のコンテンツ・顧客データ・個人データ・専有的なソース・社内アノテーション・営業秘密・安全性評価・検索コーパス・合成データ、あるいは機微なフィルタリングルールが含まれている可能性があります。

存在証明はこの緊張関係を解消します。データセットを公開せずに、その状態とタイムラインにコミットできるからです。公開するのはフィンガープリントだけで、バイト列は手元に残ります。

何にコミットすべきか。生データかマニフェストか

生のバイト列だけではなく、マニフェストにコミットしてください。

データセットのマニフェストは、スナップショットを構造化された機械可読な形で記述します。記録できる項目は次のとおりです。

  • データセット名とスナップショット ID
  • 収集期間
  • ソースのカテゴリと権利メタデータ
  • ファイル単位・行単位のハッシュ
  • 重複排除とフィルタリングのバージョン
  • アノテーションおよび前処理パイプラインのバージョン
  • それを利用したモデルまたは学習実行
  • 保持ポリシーと社内の所有者

マニフェストは、機微な詳細を一切公に晒す必要がありません。企業の内部に完全に留めておけます。公開される証明がコミットするのは、そのハッシュだけ、あるいは多数のマニフェストエントリにまたがる Merkle ルートだけです。目的は狭く、そして耐久性があります。すなわち、既知の時点におけるデータセットの状態の証拠を凍結することです。

なぜファイルごとに 1 レコードではなく Merkle ルートを使うのか

データセットは大きく、ファイルや行ごとに 1 レコードを公開する方法はスケールしません。Merkle ルートがこれを解決します。多数のハッシュからなる順序付きリストを単一の 32 バイト値にコミットし、それを 1 つのトランザクションに記録するのです。

後から特定の 1 項目が含まれていたことを証明するには、次のものだけを開示します。

  • 項目またはそのハッシュ
  • 該当するマニフェストエントリ
  • Merkle 包含証明
  • Label 309 のトランザクション参照

検証ツールは、そのリーフからルートまでの経路を再計算し、ルートが特定の Cardano ブロック時刻に公開されたことを確認します。証明はバッチサイズの対数に従って増えるため、数百万のリーフがあっても小さく保たれます。重要なのは、ツリーの構築と証明の検証が完全にオフラインの計算だという点です。検証の時点では、サーバーもアカウントも、こちら側の協力も一切必要ありません。

これが選択的開示を可能にします。1 項目がコミット済みのスナップショットに属していたことを証明するために、データセット全体を明かす必要は一切ありません。

公開で実際に見えるのは何か

チェーン上の証明レコードだけです。公開の仕方によっては、そこにマニフェストハッシュ・Merkle ルート・リーフ数・トランザクション時刻・企業やシステムによる任意の署名、そして公開または暗号化された補足資料への任意のコンテンツアドレス指定 URI（ar://、ipfs://）が含まれ得ます。

公開で見えないのは、データセットのファイル・完全なリーフリスト・ソースメタデータ・顧客データ・ライセンスの詳細・アノテーション・社内メモです。これらは、特定の問いが開示を迫るまで、ご自分の証拠システムの内部に留まります。

後から、いつ、何を開示するのか

問いが必要とするものだけを開示してください。

  • あるファイルがデータセットに含まれていたか。 ファイルまたはそのハッシュ、マニフェストエントリ、そして包含証明を開示します。
  • あるソースカテゴリが含まれていたか。 該当するマニフェストのセクションと、それがコミット済みのスナップショットに属することの証明を開示します。
  • あるモデルバージョンが特定のスナップショットを使ったか。 モデルバージョンとデータセットルートを結びつける学習実行のマニフェストを開示します。
  • これは完全な監査か。 適切な機密保持プロセスのもとで、マニフェストとリーフリストの全体を開示します。

オンチェーンのルートはタイムラインを証明します。どこまでの詳細を、誰に対して示せるかは、ご自分の内部アーカイブが決めます。補足資料そのものを第三者へ渡す必要があるものの、非公開のまま保ちたいケースでは、公開する代わりに機密として共有することができます。

これは AI 規制とどう関係するのか

AI 規制は、より強い文書化と透明性の義務へと向かいつつあります。たとえば EU AI Act は、汎用 AI モデルに関する透明性および著作権関連のルールを定めており、欧州委員会は学習コンテンツの公開要約のためのテンプレートを公表しています。委員会自身の言葉によれば、これは公に提供されるべき情報の「最小限のベースライン」と位置づけられています。

非公開のデータセット証明は、その公開要約と同じものではありません。それは規制報告・法務レビュー・同意管理・ライセンス記録の代わりにはなりませんし、これらが特定のケースで役立つかどうかは、ご自分の法域と弁護士の判断によります。

それが支えになり得るのは、こうしたプロセスの背後にある証拠のレイヤーです。企業が後になって、自社が何を保有していたか、何を知っていたか、あるいは公開した要約がどのスナップショットに基づいていたかを示す必要が生じた場合、タイムスタンプ付きのマニフェストコミットメントは、時刻と完全性に関する具体的で第三者にアンカーされた証拠となります。

データセット証明は実際に何を証明するのか

それは、特定のデータセットコミットメントが公開ブロック時刻までに存在したことを証明します。保全した証拠に応じて、次のことを示す助けになり得ます。

  • あるファイルがデータセットスナップショットに含まれていたこと
  • あるマニフェストが紛争より前に存在していたこと
  • あるデータセットバージョンがモデルリリースより前に存在していたこと
  • ある学習実行が特定のスナップショットを参照していたこと
  • あるソースカテゴリが当時文書化されていたこと
  • ある前処理またはフィルタリングのパイプラインが記録されていたこと

レコードに署名がある場合、Label 309 はレコードレベルの任意の署名をサポートしているため、企業の鍵またはシステムの鍵がそのコミットメントを保証したことも示せます。署名は決して必須ではないため、署名のないコミットメントも同等に有効です。署名は、帰属可能な作成者を付け加えるだけです。

何を証明しないのか

ここは正直に語るべき部分です。なぜなら、欠けている点こそが重要だからです。

データセット証明は、そのデータが適法に利用できたことを証明しません。データを所有していたこと、同意のもとに収集されたこと、あるいはその著作権の状態を証明することもありません。データが実際に学習に使われたことも証明しません。ただし、学習パイプラインとモデルの記録自体がデータセットスナップショットに紐づいている場合は別です。そしてマニフェストが完全であることも証明しません。完全性に信頼性を与えられるのは、ご自分のプロセスと統制だけです。

存在証明は、タイムラインと完全性に関する証拠です。それは、まさにそのバイト列が公開された時点までに存在していたことを確立します。しかし、真実性・所有権・権利・コンプライアンスについては何も語りません。これらには追加のレコードと法的分析が必要です。境界がどこにあるかの全体像を知りたい場合は、証明が証明できること、できないことをご覧ください。

ワークフローをどう設計すべきか

今日ハッシュ化することだけでなく、後で答えると見込まれる問いに合わせて設計してください。

実用的な形は次のとおりです。

  1. 正規のデータセットマニフェスト形式を定義します。
  2. すべてのデータセット項目またはマニフェストエントリをハッシュ化します。
  3. スナップショットの Merkle ルートを構築します。
  4. Label 309 レコードを公開します。帰属可能な作成者が必要であれば署名します。
  5. マニフェスト・リーフリスト・包含証明の材料を保存します。
  6. モデルの学習実行をデータセットルートへとリンクします。
  7. 法務またはコンプライアンスの受信者向けに、機微な証拠パッケージを封印します。
  8. データセットが変わったら、それを置き換えるスナップショットを記録します。

難しいのは、暗号の部分であることはまれです。難しいのは、数か月後、あるいは数年後に誰かが尋ねてきたとき、どの証拠が意味を持つのかを判断することです。

どのくらいの頻度でスナップショットをコミットすべきか

データセットが意味のある形で変わるたびにコミットしてください。典型的には、新たな取り込みのあと、学習実行の前、重複排除やフィルタリングのあと、ラベリングのあと、モデルリリースの前、ガバナンスのチェックポイントで、あるいはパートナーとデータセットを共有する前です。

その頻度は、答えると見込まれる問いに合わせるべきです。年に 1 回しかコミットしなければ、途中のどのスナップショットが存在したかを証明できないかもしれません。些細な変更のたびにコミットすれば、運用上のノイズが生じます。Merkle バッチ処理は、1 つのルートでスナップショット全体を代表させられるため、対象がどれだけ多くのファイルに及んでも 1 トランザクションで済みます。コミットあたりのコストはおおむね一定に保たれるので、価格に左右される頻度ではなく、必要な証拠に合った頻度を選べます。

封印ストレージはどう関わるのか

ハッシュ化だけでは足りないことがあります。フィンガープリントだけでなく、証拠そのものを保全したい場合です。

封印付き PoE がそれを可能にします。公開レコードは、通常の証明とまったく同じように、平文のハッシュにコミットします。機微なペイロードは暗号化されてコンテンツアドレス指定 URI に保存され、コンテンツ暗号化鍵は 1 つ以上の受信者の鍵に対してラップされます。権限を持つ受信者は後からそれを復号し、復元した平文がオンチェーンのコミットメントと一致することを、ハッシュを再計算して確認できます。

チェーンが平文を運ぶことは決してなく、受信者が誰であるかを明かすこともありません。チェーンが示すのは、ある封印されたコミットメントが時刻 T に行われたという事実だけです。これは、元のマニフェストを失うことで証明が弱まる場合に意味を持ちます。ハッシュのみのレコードは、ファイルを依然として保有している限り存在を証明します。封印付きレコードは、暗号化されたファイル自体を保全できるため、証拠とコミットメントが一緒に移動します。

明確に述べておくべき限界が 1 つあります。封印は、選ばれた鍵の保持者を除く全員からコンテンツを非公開に保ちますが、誰かを匿名にするわけではなく、受信者は復号したあとでいつでも平文を漏らせます。封印が制御するのは「誰が読めるか」であって、その後に何をするかではありません。

誰がプロセスを所有すべきか

データセット証明のプロセスは、所有者のいないエンジニアリングのスクリプトであってはなりません。それは法務・セキュリティ・データガバナンス・コンプライアンス・モデル開発にまたがります。良いプロセスは境界を明示します。すなわち、誰がスナップショットを作成できるか、誰がコミットメントに署名できるか、マニフェストをどこに保存するか、誰が封印されたパッケージを復号できるか、包含証明をどう生成するか、モデルの実行をどうルートにリンクするか、置き換えられたスナップショットをどう扱うか、そして監査や紛争の際に証拠をどう作成するか、です。

証明は暗号によるものです。ガバナンスは組織によるものです。両方が必要です。

まとめ

学習データを公開せずに証明するには、データセットではなくスナップショットにコミットしてください。マニフェストを作成し、その各エントリをハッシュ化し、Merkle ルートを Label 309 レコードとして公開し、リーフリストと包含証明を保管します。失うことで証明が弱まる機微な補足ファイルは封印します。そのうえで、各問いが実際に必要とする証拠だけを開示してください。

これにより、事前の保有と時刻について、耐久性があり第三者にアンカーされた証明が得られます。それ自体が、所有権・適法な利用・コンプライアンスを証明するわけではありません。そして、それがそのうちのどれを証明し、どれを証明しないのかを明確にしているときに、最も役立ちます。

さらに読む

aidatasetsproof-of-existence