Impact Scenario

C³ Self-Verification / ECHO-VERIFY インパクト・シナリオ

なぜ今か

AIが何かを主張する時、いま私たちが頼っているのは、ほとんど「誰が言ったか」だ。有名な研究機関、大手企業、権威ある人物。その肩書きを信じるか、信じないか、しかない。

しかしAI時代では、主張の数が人間の検証能力を桁違いに超える。「誰が言ったか」だけでは、もう判断材料として機能しなくなる。

栄養成分表示が義務化された時、人々が手に入れたのは「健康な食品」ではなかった。
自分で判断できる材料だった。
メーカーが「健康だ」と言うことを信じる必要はなくなった。表示を見て、自分で判断すればよくなった。

ECHO-VERIFYが目指すのも同じ構造だ。
主張に「検証キット」を添える。Evidence・Spec・Auditor Prompt・Manifest・Signature。読者は、自分のAIで再現確認できる。
「信じてください」から「検証してください」へ。

しかしこれは個人の検証の話だけではない。

複式簿記は最初、商人が自分の商売のために発明した記録形式だった。それが普及することで、税制・株式市場・近代金融という社会インフラの礎になった。
個別企業の業務記録の形式が、社会的信頼の基盤に昇格した。

エンタープライズはいま、AI運用の監査に巨額の工数費用をかけている。内部監査人を雇い、ログ整備に投資し、外部監査法人に支払う。しかしこの工数費用は、その会社の中でしか機能していない。

ECHO-VERIFYが普及した社会では、エンタープライズが業務遂行のために整備した検証キットが、そのまま公共的な透明性インフラの一部になり得る。
監査のために作った材料が、社外の誰でも・国でも・自治体でも、同じ形式で検証できる。

これは真実保証ではない。しかし、孤立した内部コストだった監査工数が、公共信認の礎へと接続される可能性がある。
それが、ECHO-VERIFYが「制度として」設計される所以だ。

Status

workflow_status: public_draft_v0.2
basis_status: SPEC_DEFINED
reference_status: claim_checked_partial
evidence_pack_status: mixed_pass_with_holds
page_review_status: PASS_PENDING_V0_1_REVIEW

このページは、C³ Self-Verification / ECHO-VERIFY が仕様どおりに実装・運用・検証された場合に、どのような社会的意味を持ち得るかを整理するインパクト・シナリオです。本ページは、真実保証、安全保証、第三者認証、外部標準準拠、改ざん不能保証、完全検証、または特定成果の達成を主張するものではありません。

このページの位置づけ

ECHO-VERIFY は、C³を「信じてください」と求める仕組みではなく、C³が出す判断・ログ・メトリクス・文書・検証結果を、第三者や利用者が外側から再確認しやすくするための検証レイヤである、という考え方を整理するページです。

一行要約

Self-Verification は、C³の出力を信頼してもらうための宣言ではなく、確認材料、境界、HOLD条件、レビュー履歴を外側から見えるようにするための公開ドラフトです。

Self-Verification によって何が変わり得るか

「信じてください」から「検証してください」へ

社会的意味: Self-Verification は、C³の説明をそのまま受け入れてもらう発想から、C³が提示する材料を読者や第三者が確認できる形へ移す可能性があります。
実装された場合に何が変わり得るか: 判断、ログ、メトリクス、文書、検証結果をまとめた公開面を持つことで、読者は主張そのものだけでなく、その根拠や限界を確認しやすくなり得ます。
ロジックを支える外部参照: NIST AIRC / TEVV、AI RMF Playbook、National Academies の再現性に関する整理を、評価・文書化・再確認の比較軸として参照します。
現在の位置・言わないこと: 外部機関がC³を検証したこと、またはC³の判断が真実であることを主張するものではありません。

Verification Kit

社会的意味: Verification Kit は、第三者や利用者が確認に使う最小材料をひとまとまりにする設計として考えられます。
実装された場合に何が変わり得るか: 対象文書、manifest、hash、signature、reference status、auditor prompt、replay手順を分けて提示することで、確認作業の入口を明確にできる可能性があります。
ロジックを支える外部参照: Sigstore Bundle、in-toto Attestation、DSSE、RO-Crate、FAIR principles を、検証材料の束ね方や再利用可能性の比較軸として参照します。
現在の位置・言わないこと: Verification Kit が完全な検証を提供する、またはC³がこれらの外部仕様を実装しているとは主張しません。

関連するC³要素：ECHO-VERIFY GVD BridgeVerification Kit

Manifest / Hash / Signature

社会的意味: Manifest、hash、signature は、どの版の何を、いつ、誰が対象にしたかを確認するための材料になり得ます。
実装された場合に何が変わり得るか: 対象物、版、署名対象、payloadType、timestamp を分けて示すことで、確認対象の取り違えや更新履歴の不透明さを減らす方向に働き得ます。
ロジックを支える外部参照: Sigstore Rekor、Sigstore Bundle、DSSE、SLSA Provenance を、署名対象、型、検証材料、由来情報を分ける比較軸として参照します。
現在の位置・言わないこと: 署名やhashが意味内容の正しさ、安全性、改ざん不能性を示すとは主張しません。

関連するC³要素：ECHO-VERIFY GVD Bridge

Transparency Log

社会的意味: Transparency Log は、署名やメタデータを後から監査しやすい場所に置く考え方として参考になります。
実装された場合に何が変わり得るか: 記録が公開監査可能な形で残ると、後日の検証、監視、変更履歴の確認がしやすくなる可能性があります。
ロジックを支える外部参照: Sigstore Rekor と Sigstore Bundle を、公開監査性、ログ監視、検証材料の保持に関する比較軸として参照します。
現在の位置・言わないこと: ログに記録されていることが、内容の正しさ、安全性、完全性、または外部承認を示すとは主張しません。

関連するC³要素：ECHO-VERIFY GVD Bridge Supporter Registry

Provenance

社会的意味: Provenance は、証拠や文書がどこから来て、誰のどの活動を通じて作られたかを説明する材料になり得ます。
実装された場合に何が変わり得るか: 由来、活動、関与者、版、生成過程を分けて示すことで、読者は判断の根拠と限界を確認しやすくなり得ます。
ロジックを支える外部参照: W3C PROV と SLSA Provenance を、由来情報、活動、関与者、機械可読な生成情報を扱う比較軸として参照します。
現在の位置・言わないこと: Provenance が真実性、価値判断、一般妥当性、またはC³の正しさを示すとは主張しません。

関連するC³要素：GVD Bridge Verified Web

TEVV

社会的意味: TEVV は、testing、evaluation、verification、validation を分けて扱うための比較軸になります。
実装された場合に何が変わり得るか: 単発の確認ではなく、設計、評価、文書化、配備後の観測を継続的に扱うことで、何を確認済みで何が未確認かを整理しやすくなり得ます。
ロジックを支える外部参照: NIST AIRC / TEVV、NIST GenAI Profile、自動ベンチマーク実務、配備済みAI監視の課題を比較軸として参照します。
現在の位置・言わないこと: TEVV への参照によりC³がNISTに承認された、外部標準に適合した、またはAI安全性を示したとは主張しません。

Auditor Prompt / Replay

社会的意味: Auditor Prompt と Replay は、検証者が同じ手順や入力で確認を試みるための材料として考えられます。
実装された場合に何が変わり得るか: 確認手順、入力、期待される確認範囲、HOLD条件を示すことで、レビュー作業を反復しやすくし、どこまで再確認できたかを残しやすくなり得ます。
ロジックを支える外部参照: National Academies の再現性・再現可能性の整理、RO-Crate、FAIR principles を、再確認可能な材料の比較軸として参照します。
現在の位置・言わないこと: Replay が成功したことが、一般妥当性、真実性、またはすべての環境での正しさを示すとは主張しません。

HOLD as safe-side state

社会的意味: 材料が不足している、確認できない、または境界が不明な場合に、HOLDを通常の安全側状態として扱う考え方です。
実装された場合に何が変わり得るか: 不足している材料や未確認の条件を明示し、公開・再利用・外部判断の前に止めることで、検証不能を無理にPASSへ変換しない運用に近づき得ます。
ロジックを支える外部参照: AI RMF Playbook、配備済みAI監視の課題、National Academies の不確実性整理を、HOLD条件と再確認の比較軸として参照します。
現在の位置・言わないこと: HOLD が常に被害を避ける、または自動的に正しい判断を返すとは主張しません。

関連するC³要素：ITS Topological GatekeeperHOLD / Fail-Closed

「信じてください」から「検証してください」へ

ECHO-VERIFY は、C³を「信じてください」と求める仕組みではなく、C³が出す判断・ログ・メトリクス・文書・検証結果を、第三者や利用者が外側から再確認しやすくするための検証レイヤです。読者は、主張そのものだけでなく、どの材料があり、どの材料がなく、どの範囲まで確認できるのかを見られるようになります。

Verification Kit：第三者が確認するための最小材料

Verification Kit は、対象文書、manifest、hash、signature、reference status、auditor prompt、replay手順などを分けて束ねる内部設計として想定しています。重要なのは、証拠、主張、署名ラッパー、確認手順を混ぜずに扱い、読者が確認できる材料と未確認の材料を区別できるようにすることです。

Manifest / Hash / Signature

Manifest、hash、signature は、確認対象の版、署名対象、署名時点、署名者、関連メタデータを整理するための材料になり得ます。ただし、署名は意味内容の正しさを示すものではありません。ECHO-VERIFY では、暗号的な材料と意味内容の判断を分けて扱うことが重要です。

Transparency Log

Transparency Log は、後から検証材料を探し、監査し、変更履歴を追いやすくする比較軸です。ログは公開監査性を高め得ますが、記録されていること自体が安全性や正しさを示すものではありません。ログ監視や確認手順と組み合わせて初めて、レビュー材料として使いやすくなります。

Provenance

Provenance は、何が、誰によって、どの活動を通じて作られたかを記述する材料です。ECHO-VERIFY では、由来情報を真理判定器としてではなく、判断・証拠・版・関与者を分けて見るための材料として扱います。今回の公開ページでは、HOLD中のC2PA / NCSC参照は引用支援に使いません。

TEVV

TEVV は、testing、evaluation、verification、validation を継続的に扱うための比較軸です。ECHO-VERIFY は単発の正解判定ではなく、評価、検証、文書化、配備後の観測をどのように読者へ示すかを考えるためのレイヤとして整理します。

Auditor Prompt / Replay

Auditor Prompt と Replay は、第三者が同じ手順や入力で確認を試みるための材料です。再確認できることは重要ですが、同じ結果が得られたことと、一般妥当性や真実性が示されたことは別です。この違いをページ内で明示することが、ECHO-VERIFY の境界になります。

HOLDは検証不能を安全側に扱う状態である

HOLD は、確認に失敗したという意味だけではありません。source availability が確認できない、manifest が不足している、署名対象が曖昧、claim boundary が不十分といった場合に、通常の安全側状態として扱うための区分です。

失敗パターンと安全装置

ECHO-VERIFY で避けるべき失敗には、署名を真実性と混同すること、ログ登録を安全性と混同すること、provenance を外部承認のように扱うこと、replay 成功を一般妥当性と扱うことがあります。これらを避けるため、not_allowed_claim、HOLD、page review、route review を組み合わせます。