AIの証跡は、いつから「証明可能」になるのか Decision Trace LedgerとUnanchored Evidence Window

Books: Runtime AI Governance 実践ガイド: Knowledge Flow・Trust Engine・Decision Traceによる動的AIガバナンス設計

はじめに

AIエージェントが現実の業務を実行するようになると、「AIが何をしたのか」を記録するだけでは不十分になります。

なぜ、その行動を選択したのか。

その時点で、どのような状況を認識していたのか。

どのPolicyやRuleを適用したのか。

どの程度のTrustが与えられていたのか。

そして、その行動は許可されたAutonomyの範囲内だったのか。

これらを後から検証できる形で残す仕組みが、Decision Traceです。

しかし、Decision TraceをLedgerへ保存したからといって、その証跡が直ちに独立して証明可能になるとは限りません。

Ledgerへ記録されてから、外部の検証基盤へ暗号学的に固定されるまでには、時間的な空白が存在するからです。

本記事では、この空白を次のように呼びます。

Unanchored Evidence Window

日本語では、「未アンカー証跡期間」と表現できます。

この概念は、私がLinkedInでDecision Trace Ledgerの設計について意見交換していた際、SITA OSのFounder & CTOであるDaniela Wildさんから受けた問題提起をきっかけに生まれました。

Daniela Wildさんからの問題提起

私は、AIエージェントの実行権限と、実行証跡を保存・検証する仕組みを分離する必要があると考えています。

具体的には、AIエージェントは、限定された追記専用インターフェースを通じて実行記録を提出できます。

しかし、Ledgerの過去記録を変更したり、削除したり、Ledger自体を管理したりする権限は持ちません。

さらに、証跡の検証機構も、行動したAIエージェントだけでなく、その行動を許可したTrust Engineからも独立させます。

この考え方を検証するため、私は軽量なオープンソース実装として、Decision Trace Ledger Coreの開発を始めました。

また、Ledgerに保存されたすべての証跡をブロックチェーンへ書き込むのではなく、LedgerのハッシュやMerkle Rootだけを定期的に外部へアンカリングする構成を検討しています。

この方法であれば、完全なオンチェーン保存に伴うコストや遅延を抑えながら、後からLedgerの改ざんを検出できます。

この設計に対して、Danielaさんは、エージェントとTrust Engineの双方から独立した検証境界を設けることで、証跡の信頼性に関する重要なギャップを解消できると評価してくださいました。

その一方で、非常に重要な問いを提示されました。

アンカリングの頻度をどのように設計するのか。
間隔が長すぎると、侵害されたプロセスが、まだアンカリングされていない記録を書き換えられる時間が広がるのではないか。

この問題提起によって明確になったのは、証跡の信頼性には「保存場所」や「暗号方式」だけでなく、時間の問題が存在するということです。

そこから導かれた設計概念が、Unanchored Evidence Windowです。

Unanchored Evidence Windowとは何か

Unanchored Evidence Windowとは、Decision TraceがLedgerに受理されてから、そのTraceを含む暗号学的コミットメントが外部の独立した基盤へアンカリングされ、確認されるまでの期間です。

数式では、次のように表せます。

[
UEW = T_{\text{anchor confirmed}} – T_{\text{trace accepted}}
]

ここで重要なのは、アンカーを外部へ「送信した時刻」ではなく、外部基盤で「確認された時刻」を終点とすることです。

例えば、午前10時にAIエージェントが重要な契約を承認し、そのDecision TraceがLedgerへ記録されたとします。

そのTraceを含むMerkle Rootが外部基盤へアンカリングされ、午前10時15分に確認された場合、Unanchored Evidence Windowは15分です。

この15分間、証跡は内部Ledgerには存在しています。

ハッシュチェーンやデジタル署名によって保護されているかもしれません。

しかし、外部の独立した基準によって固定された状態には、まだ到達していません。

「記録済み」と「証明可能」は同じではない

従来の監査ログでは、記録が保存されていれば「証跡がある」と考えられがちです。

しかし、自律的なAIエージェントを対象とする場合、少なくとも次の状態を区別する必要があります。

1. TraceがLedgerに受理された
2. 前後の記録とハッシュで連結された
3. Merkle Treeに含まれ、バッチが封印された
4. Merkle Rootが外部基盤へ送信された
5. 外部基盤でアンカーが確認された
6. 第三者が独立して検証できる状態になった

状態遷移として表すと、次のようになります。

ACCEPTED
    ↓
INTERNALLY_CHAINED
    ↓
BATCH_SEALED
    ↓
ANCHOR_SUBMITTED
    ↓
ANCHOR_CONFIRMED
    ↓
EXTERNALLY_VERIFIABLE

この区別によって、「Ledgerには記録されているが、まだ外部から独立して証明できない」という中間状態を明示的に扱えるようになります。

つまり、問うべきなのは次の二つです。

証跡は残っているか。

そして、

その証跡は、いつから独立して検証可能になったのか。

Unanchored Evidence Windowは、この二つの問いの間に存在する時間的なギャップです。

なぜ内部ハッシュだけでは十分ではないのか

各Decision Traceを前の記録のハッシュと連結すれば、途中の記録が変更された場合、それ以降のハッシュとの整合性が失われます。

これは改ざん検出の重要な仕組みです。

しかし、Ledger全体を管理できる強い権限が侵害された場合、攻撃者が過去の記録だけでなく、それ以降のハッシュも再計算する可能性があります。

同じシステムの内部に、記録、ハッシュ、署名、検証基準のすべてが存在していると、そのシステム全体が侵害された場合の独立した比較対象がありません。

そこで必要になるのが、外部アンカーです。

ある時点のMerkle Rootをブロックチェーン、外部タイムスタンプサービス、独立した監査基盤などへ記録しておけば、その後に内部Ledgerを再構築しても、外部に残されたRootと一致しなくなります。

内部ハッシュチェーンは、Ledger内部の整合性を保護します。

外部アンカーは、その整合性をシステムの外部から検証可能にします。

この二つは競合する仕組みではなく、異なる脅威に対応する補完的な仕組みです。

アンカリング頻度のトレードオフ

すべてのDecision Traceを発生直後にブロックチェーンへ保存すれば、Unanchored Evidence Windowを短縮できます。

しかし、実際には次のような問題があります。

• トランザクションコストが増える
• 外部ネットワークの遅延を受ける
• 大量のTraceを処理しにくい
• 外部基盤の障害がAIの実行を妨げる
• 機密情報やメタデータの扱いが複雑になる

一方、複数のTraceをまとめ、1時間ごとや1日ごとにMerkle Rootをアンカリングすれば、コストと処理量は抑えられます。

しかし、アンカリング間隔が長くなるほど、まだ外部固定されていない証跡が増えます。

Danielaさんの問題提起は、まさにこのトレードオフを指摘するものでした。

重要なのは、アンカリング頻度を単なるインフラ設定として決めないことです。

それは、証跡の保証水準を決めるセキュリティPolicyとして設計される必要があります。

Risk-Based Anchoring

すべてのDecision Traceに同じアンカリング頻度を適用する必要はありません。

情報検索の記録と、高額送金の記録では、求められる証跡保証の水準が異なるからです。

そこで、行動のリスクに応じてUnanchored Evidence Windowの上限を変える、Risk-Based Anchoringが考えられます。

リスク	行動例	UEWの目標例	アンカリング方法
Critical	送金、権限変更、安全機能の解除	60秒以内	即時または準リアルタイム
High	契約承認、重要データの変更	5分以内	高頻度マイクロバッチ
Medium	顧客対応、一般的な業務処理	30分以内	定期バッチ
Low	情報検索、提案、要約	数時間以内	集約バッチ

ここで示した時間は一例です。

実際の値は、行動の影響、規制要件、業務上の重要性、攻撃可能性、コスト、復旧要件などをもとに決定します。

また、リスクレベルだけでなく、次の要素もアンカリングPolicyへ反映できます。

• AIエージェントの現在のTrust Score
• 行動に与えられたAuthority
• 対象データの機密性
• 金銭的・社会的な影響
• 人間の承認の有無
• 実行環境の脅威レベル
• 規制や契約で求められる保証水準

これにより、アンカリングは固定周期のバックグラウンド処理ではなく、AIの実行Contextに応じて変化する動的な保証機構になります。

Unanchored Evidence Windowをどう保護するか

Unanchored Evidence Windowを完全にゼロにすることが難しいとしても、その期間を無防備にしてよいわけではありません。

外部アンカーが確定するまで、次のような防御を組み合わせる必要があります。

• 各Traceを前のTraceのハッシュと連結する
• 追記専用ストレージへ書き込む
• Trace受理時にデジタル署名を付与する
• 短い間隔でMerkle Treeのバッチを封印する
• 署名鍵をLedger本体から分離したKMSやHSMで管理する
• Ledgerの書き込み権限と管理権限を分離する
• 複数の独立した保存先へRootを複製する
• アンカー失敗や遅延を継続的に監視する
• 許容時間を超えた未アンカーTraceを自動検出する

さらに、Traceを受理した直後に署名付きのReceiptを発行し、そのReceiptを実行主体とは別の場所へ送信する方法も考えられます。

これにより、外部アンカーがまだ確定していない期間でも、ある時点で特定のTraceが存在していたことを示す補助的な証拠を残せます。

ただし、これらは外部アンカーを完全に代替するものではありません。

重要なのは、複数の独立した証拠を重ね、単一の侵害によってすべての証跡が失われたり再構築されたりしないようにすることです。

セキュリティ指標としてのUEW

Unanchored Evidence Windowは、設計上の概念にとどまりません。

測定可能なセキュリティ指標として運用できます。

例えば、次の値を継続的に計測します。

• 現在の最古未アンカーTraceの経過時間
• 未アンカーTraceの総数
• 平均UEW
• 最大UEW
• リスクレベル別のUEW
• 目標時間内にアンカーされた割合
• アンカー送信の失敗回数
• 送信から確認までの外部遅延
• Policy違反状態にあるTraceの件数

SLOとしては、次のような定義が考えられます。

Criticalに分類されたDecision Traceの99.9％を、Ledger受理後60秒以内に外部アンカーへ含める。

これにより、「改ざんされにくい設計です」という曖昧な説明ではなく、証跡が独立して検証可能になるまでの時間を定量的に示せます。

アンカー障害とAutonomyの縮小

さらに重要なのは、アンカリング障害を単なる監視アラートで終わらせないことです。

証跡を独立して保証できない状態が続くなら、AIへ与えるAutonomyも縮小すべきです。

例えば、次のようなPolicyが考えられます。

IF action.risk = CRITICAL
AND oldest_unanchored_age > 60 seconds
THEN require_human_approval

IF oldest_unanchored_age > 15 minutes
THEN suspend_high_impact_actions

IF anchor_verification = unavailable
AND action.requires_external_evidence = true
THEN deny_execution

つまり、証跡基盤の健全性をTrust Engineの評価要素へ組み込みます。

外部アンカーが正常であり、Unanchored Evidence Windowが許容範囲内なら、通常のAutonomyを維持できます。

遅延が拡大した場合は、高リスク操作をHuman Gateへ戻します。

さらに悪化した場合は、重要な自律実行を停止します。

この仕組みによって、AIのAutonomyと証跡の保証水準が連動します。

証明できない行動を、AIにそのまま続けさせない。

これが、Decision Trace LedgerとRuntime Autonomy Controlをつなぐ重要な設計原則になります。

Decision Traceに保持すべき情報

Unanchored Evidence Windowを管理するためには、各Traceとアンカーの関係を明示的に記録する必要があります。

例えば、次のような情報です。

{
  "trace_id": "dt_01...",
  "accepted_at": "2026-07-28T01:00:00Z",
  "risk_level": "high",
  "anchor_policy": "high-risk-5m",
  "batch_id": "batch_01...",
  "merkle_root": "sha256:...",
  "anchor_provider": "external-ledger",
  "anchor_submitted_at": "2026-07-28T01:03:00Z",
  "anchor_confirmed_at": "2026-07-28T01:03:18Z",
  "anchor_reference": "tx-or-timestamp-id",
  "unanchored_window_ms": 198000,
  "verification_status": "externally_verifiable"
}

この情報があれば、後日の監査で、単にTraceの内容を確認するだけでなく、次の点を検証できます。

• Traceがいつ受理されたか
• どのバッチに含まれたか
• どのMerkle Rootによって保護されたか
• どの外部基盤へアンカリングされたか
• いつ独立検証可能になったか
• 規定されたUEWを満たしていたか

Trust EngineとDecision Trace Ledgerの役割

Trust EngineとDecision Trace Ledgerは、異なる時間軸の問いに答えます。

Trust Engineが答えるのは、実行時の問いです。

このAIに、今、この状況で、この行動を許可してよいか。

Decision Trace Ledgerが答えるのは、実行後の問いです。

その時点で、どのようなTrust、Context、Policy、Authorityに基づいて行動が許可され、実際の行動がその範囲内にあったことを証明できるか。

そして、Unanchored Evidence Windowは、さらにもう一つの問いを加えます。

その証跡は、いつからシステムの外部でも独立して検証可能になったのか。

この三つの問いによって、実行前のAuthorization、実行時のDecision、実行後のEvidenceが接続されます。

対話から設計概念が生まれる

Unanchored Evidence Windowという概念は、最初からDecision Trace Ledgerの設計用語として存在していたわけではありません。

AIエージェントの権限境界とEvidence Planeを分離し、Merkle Rootを外部へアンカリングするという設計案に対して、Daniela Wildさんが「アンカリングされるまでの時間的なリスク」を指摘してくださったことから生まれました。

これは、技術設計における対話の価値を示す例でもあります。

ある設計が構造的に正しく見えても、別の視点から問いを投げかけることで、まだ名前の付いていなかったリスクが見えてきます。

名前が与えられると、そのリスクは測定できます。

Policyとして定義できます。

監視できます。

テストできます。

そして、システムのAutonomy制御へ接続できます。

Danielaさんの問題提起は、外部アンカリングの「頻度」という実装上の論点を、証跡保証における「時間的なセキュリティ境界」へと発展させるきっかけになりました。

まとめ

Decision TraceをLedgerへ保存するだけでは、その証跡が直ちに独立して証明可能になるわけではありません。

Traceが受理されてから、外部アンカーが確認されるまでには、Unanchored Evidence Windowが存在します。

この期間を明示的に扱うことで、Decision Trace Ledgerの設計は次の段階へ進みます。

• 「記録済み」と「外部検証可能」を区別する
• アンカリング頻度をリスクベースで決定する
• UEWを測定可能なセキュリティ指標にする
• 許容時間をSLOとして定義する
• アンカー障害時にAIのAutonomyを縮小する
• Trust EngineとEvidence Planeを動的に接続する

AI時代の監査で問われるのは、単にログが存在するかどうかではありません。

そのログが、誰の権限から独立しているのか。

いつ外部から検証可能になったのか。

そして、証跡を保証できない状態で、AIの行動をどこまで許可したのか。

これらを設計しなければなりません。

Evidence is not trustworthy merely because it was recorded.

It becomes independently verifiable when it is externally committed—and the time before that commitment must be governed.

証跡は、記録されたというだけでは十分ではありません。

外部へ暗号学的に固定されて初めて、独立した検証が可能になります。

そして、その固定までの時間もまた、AIガバナンスの対象なのです。