RAGソース認証

AIエージェントは、応答中に典拠を明示する習慣を身につけました。「社内規程第3条第2項により」「国税庁通達X号によれば」「契約書第7条には」──このような引用は、応答の説得力を支え、業務利用の前提条件にもなっています。

しかし応答を受け取る側には、その引用が真正かを検証する手段がありません。応答テキストだけを見ても、次の3つを区別できないからです：

• 実在する原本から正しく引用されたもの
• 実在する原本に近いが、文言が微妙に異なるもの（パラフレーズ）
• 完全に存在しない引用（ハルシネーション）

加えて構造的な問題があります：

• 応答テキスト中の引用箇所が、retrieve された具体的なチャンクのどこと対応しているか、暗号的に証明されていません
• retrieve されたチャンクが、そもそも原本と一致しているかも、別レイヤで担保されない限り曖昧です
• RAGインデックスが時間とともに再構築されれば、過去の応答が当時参照していたチャンクは消えていきます

法務、税務、医療、金融、コンサルティング──いずれも、誤った引用に基づく判断は重大な責任問題に発展する領域です。応答の事後検証可能性は、運用上のオプションではなく、業務継続性の前提です。

大手税理士法人のAIエージェントは、税法・通達・過去の事例を参照しながら、顧客企業に税務ガイダンスを提供しています。AIは「国税庁通達X号第3項により、当該支出は損金算入可能」のように、典拠を明示して回答します。

2026年8月、ある法人顧客がAIの回答を前提に会計処理を進めます。決算後の税務調査で「その通達にそのような規定はない」と指摘されます。法人は税理士法人に説明を求めます。

税理士法人はAI応答ログを確認します。ログには応答テキストと「通達X号より」という典拠表示が残っているだけ。AIが応答時点で実際に retrieve したチャンクが、通達X号の原本と一致していたか、応答テキストがそのチャンクから正確に引用されたか──いずれも事後検証できません。RAGインデックスはその後の通達追加で再構築されており、当時の状態は再現不能です。

Lemmaが導入されていれば、応答の生成時点で次が同時に封じられています：

• AIエージェントの識別子と応答時刻
• retrieve されたチャンク群のハッシュ
• そのチャンクと原本（RAGコンテンツ来歴で固定化済み）の暗号的束縛
• 応答テキスト中の引用区間と、該当チャンクの暗号的紐付け

顧客と税理士法人は、独立に検証できます──「2026年8月18日のAI応答で引用された通達X号第3項は、当時の原本のこの箇所であり、応答テキストはそこから一字一句正確に引用された」ことを。あるいはその逆──「ログ上の引用は、当時の原本に存在しない」ことが暗号的に明らかになる場合もあります。

責任の所在が、推測ではなく証明で決まります。

Lemmaの4つの暗号レイヤが、AI応答のライフサイクルに対応します。

1. ENCRYPT ─ 応答生成時の引用要素の密封

AIエージェントが応答を生成する瞬間、retrieve したチャンク群、生成された応答テキスト、応答内の引用区間を、AES-GCMで暗号化します。要素間の対応関係は、原本を平文化することなく記録できます。

2. PROVE ─ 引用の暗号的束縛

ZKサーキット上で、(a) AIエージェント識別子、(b) retrieve されたチャンクのハッシュ、(c) 原本のdocHash（RAGコンテンツ来歴側で既に固定化されている前提）、(d) 応答テキスト中の引用区間── これら4要素の整合性を証明として封じます。「AIが何を見て、どこから引用したか」が一気通貫で証明されます。

3. DISCLOSE ─ 文脈別の選択的開示

応答受け手の権限に応じて開示範囲を制御します。顧客には引用箇所と原本の存在証明、規制当局には完全なチャンクと retrieve 履歴、第三者監査には引用整合性の証明のみ──といった階層的開示が、発行者署名付きで実行できます。

4. PROVENANCE ─ 応答そのものの永続記録

応答時刻、AIエージェント識別子、引用元のdocHash、応答ハッシュをオンチェーンに刻みます。RAGインデックスが再構築されても、AIエージェントが入れ替わっても、過去応答の引用整合性は永続的に検証可能です。

┌──────────────────────────────────────────────────────────┐
│  AIエージェント応答生成                                    │
│  クエリ → retrieve → チャンク選択 → 応答テキスト生成         │
└───────────────────────┬──────────────────────────────────┘
                        │ 応答 + 引用区間 + retrieveチャンク
                        ▼
┌──────────────────────────────────────────────────────────┐
│  ENCRYPT (AES-GCM)                                       │
│  ・retrieve チャンク群を暗号化                              │
│  ・応答テキスト中の引用区間を封印                             │
│  → 要素間の対応関係を原本平文化なしで記録                     │
└───────────────────────┬──────────────────────────────────┘
                        │ 暗号化済み引用要素
                        ▼
┌──────────────────────────────────────────────────────────┐
│  PROVE (ZK Circuit)                                      │
│  束縛：(a) AIエージェント識別子 (b) チャンクハッシュ         │
│        (c) 原本docHash（来歴で固定化済み）                    │
│        (d) 応答テキスト中の引用区間                          │
│  → 「AIが何を見て、どこから引用したか」を一気通貫で証明        │
└───────────────────────┬──────────────────────────────────┘
                        │ ZK証明 + 引用束縛
                        ▼
┌──────────────────────────────────────────────────────────┐
│  DISCLOSE (選択的開示)                                     │
│  顧客 → 引用箇所 + 原本の存在証明                           │
│  規制当局 → 完全なチャンク + retrieve履歴                    │
│  第三者監査 → 引用整合性の証明のみ                           │
└───────────────────────┬──────────────────────────────────┘
                        │ 開示済み属性
                        ▼
┌──────────────────────────────────────────────────────────┐
│  PROVENANCE (On-chain)                                   │
│  応答時刻 / AI識別子 / 引用元docHash / 応答ハッシュ         │
│  → RAG再構築・エージェント入れ替え後も引用整合性は不変         │
└──────────────────────────────────────────────────────────┘

LemmaのCitation Proverによって生成される引用proofは、以下の事実を暗号学的に確立します：

1. 引用時点の文書ハッシュ

• ソース文書の正確な SHA-256 ハッシュ（引用が生成された時点でのもの）。
• このハッシュは、文書の論理名やストレージパスだけでなく、文書バージョンを一意に識別します。
• proofは、ハッシュが後続または以前のバージョンではなく、AIが実際に検索した文書コンテンツと一致することを保証します。

2. 文書バージョン / コンテンツ識別子 (CID)

• 不変ストレージ内の正確な文書バージョンを特定するCID（IPFSスタイルのコンテンツアドレス識別子）。
• proofは、文書ハッシュをこのCIDにバインドし、元の文書ストアがなくなった場合でも、コンテンツアドレスネットワークから引用コンテンツを取得できることを保証します。
• 文書が可変システム（SharePoint、Google Drive、S3）に保存されている場合、Lemmaは取り込み時にハッシュ‑CIDペアをアンカーします；後続の変更は新しいハッシュ‑CIDペアを生成します。

3. 引用‑ソースバインディング

• AIによって引用された特定のテキストセグメントがハッシュで識別される文書の部分文字列であること。
• proofは、引用テキストが文書内の特定の文字オフセット（または段落/文の位置）に現れることを示します。
• バインディングは、使用されるZKスキームに応じて、コミットメント包含証明または部分文字列チェック回路を介して検証されます。

4. 発行者の署名

• 文書の承認された発行者（例：法務部門、コンプライアンス担当者、文書所有者）からのデジタル署名。
• 署名は文書ハッシュ（およびオプションのメタデータ）に対して行われ、文書が信頼できるソースから発行されたことを証明します。
• proofは、署名者の秘密鍵を明らかにすることなく、署名の有効性を検証します。

5. タイムスタンプ

• 引用が生成された壁時計時間（UTC、マイクロ秒精度）。
• タイムスタンプはproofに埋め込まれ、オンチェーンにアンカーされ、引用イベントのグローバルに一貫した順序付けを提供します。
• Lemmaはブロックチェーンのコンセンサス時間（ブロックタイムスタンプ）をトラストレスなクロックとして使用します；proofのタイムスタンプは、proof digestが記録されたブロックより早くならないことが保証されます。

6. RAGインデックスライフサイクルからの独立

• proofは、RAGインデックス、ベクトルエンベディング、または検索パイプラインの変更に関係なく有効なままです。
• proofがベクトルエンベディングやインデックスメタデータではなく、文書ハッシュとCIDにコミットするため、以下の影響を受けません：
  • RAGインデックスの再構築
  • エンベディングモデルのアップグレード
  • ベクトルデータベースの移行
  • チャンキングや前処理ロジックの変更
• 検証者はRAGシステムの内部状態ではなく、オンチェーンハッシュレジストリのみを信頼すればよいです。

7. 引用コンテキストの否認防止

• proofには、引用を生成したクエリコンテキスト（ユーザーの質問、セッションID、AIモデルバージョンなど）のハッシュが含まれます。
• これにより、発行者が後で「AIは異なるクエリを引用した」または「引用が文脈から外れている」と主張することを防ぎます。
• コンテキストハッシュはAIサービス（または委任された証明鍵）によって署名され、proofの一部として検証されます。

検証手順

任意の当事者は、以下の手順でこれらの事実を検証できます：

1. proofを取得する – AIレスポンスに添付されている、または検証可能な資格証明に保存されているものを取得。
2. オンチェーンアンカーを取得する – 記録されたブロックでLemmaRegistryからproof digestとメタデータを取得。
3. 文書ハッシュレジストリをチェックする – 文書ハッシュが登録され、主張されたCIDにリンクされていることを確認。
4. ZK proofを検証する – 公開パラメータを使用して検証アルゴリズムを実行。
5. 発行者署名を検証する – 発行者の公開鍵（オンチェーンまたはDID文書で公開されているもの）を使用。
6. タイムスタンプの整合性を確認する – proofのタイムスタンプがオンチェーンブロックタイムスタンプと一致することを確認（許容範囲内）。
7. コンテキストハッシュを再計算する – 必要に応じて、クエリコンテキストをハッシュし、コミットされた値と比較。

すべての手順が通過すれば、検証者は元の文書ストア、RAGインデックス、内部ログにアクセスすることなく、上記の7つの事実を確信できます。

1. AI Audit Log Proof (P2)

論題: 「ログされる ≠ 不変である。」

関連性の理由

両方のユースケースは、AIシステム出力の検証可能性に対処します。rag‑source‑attestation は特定の引用がソース文書と一致することを証明する一方、ai‑audit‑log‑proof は、クエリ、レスポンス、モデルバージョン、推論パラメータを含むAI決定の監査証跡全体が改ざん検知可能であり、オンチェーンにアンカーされることを保証します。

補完的な焦点

• 引用レベル証明 vs. ログレベル証明。
• RAG‑source‑attestation は細粒度の引用ごとのバインディングを提供します；AI‑audit‑log‑proof は、インタラクションログ全体の粗粒度の全体的な完全性を提供します。
• 両者を組み合わせることで、エンドツーエンドの検証可能性を実現できます：ユーザークエリから、AIの推論を経て、引用された正確な文書フラグメントまで。

技術的重複

• 両方ともZK証明とオンチェーンアンカー（LemmaRegistry）を使用します。
• 両方とも発行者署名とタイムスタンプの不変性を必要とします。
• 両方とも、基盤となるAIインフラストラクチャの可変状態から独立するように設計されています。

2. RAG Content Provenance (P1)

論題: 「インデックス化される ≠ 信頼できる。」

関連性の理由

RAG‑source‑attestation は、引用される文書が既に検証可能なprovenanceを持っていることを前提としています。RAG‑content‑provenance はその基盤を提供します：RAGインデックスに取り込まれる各文書が、そのソース、発行者、取り込みタイムスタンプに暗号学的にバインドされていることを保証します。

上流/下流関係

• 上流: RAG‑content‑provenance は、インデックスに入る文書が既知の信頼できる起源を持つことを保証します。
• 下流: RAG‑source‑attestation は、インデックスから引き出された引用がそれらの検証済み文書を参照することを保証します。

階層的保証

取り込み時のprovenanceがなければ、引用は未知または悪意のある起源の文書にバインドされる可能性があります。両方のレイヤーを持つことで：

1. 取り込み時証明: 文書Xが法務部門から発行され、時間T₁に署名されたこと。
2. 引用時証明: 段落YのAIの引用が時間T₂の文書Xのハッシュにバインドされていること。
3. 信頼の連鎖: 引用は参照する文書のprovenanceを継承します。

クロスユースケースシナリオ

シナリオA: AI駆動のポリシーアドバイスのコンプライアンス監査

• RAG‑content‑provenance は、インデックス内のポリシー文書が真正かつ最新であることを保証します。
• RAG‑source‑attestation は、各アドバイスが正しいポリシーバージョンを引用していることを証明します。
• AI‑audit‑log‑proof は、どの従業員がいつどの質問をし、AIが何と回答したかの不変記録を提供します。

シナリオB: 訴訟ディスカバリー

• 裁判所は、AIのレスポンスが特定の規制文書のバージョンに依存していたという証拠を要求します。
• RAG‑source‑attestation が引用proofを提供します。
• RAG‑content‑provenance が、規制文書が権限のある当局によって発行されたというproofを提供します。
• AI‑audit‑log‑proof が、クエリとレスポンスが後から改ざんされていないというproofを提供します。

シナリオC: サプライチェーン適正調査

• AIがサプライヤー認証をレビューし、非準拠サプライヤーにフラグを立てます。
• RAG‑content‑provenance が認証文書の真正性を検証します。
• RAG‑source‑attestation が、AIの「非準拠」判定が違反された正確な条項を引用していることを検証します。
• AI‑audit‑log‑proof が適正調査プロセスの改ざん検知可能な記録を保持します。