タイトルでは分かりやすさのために「改ざんできない」という表現を使っています。しかし、技術的には改ざん検知可能（tamper-evident）、または改ざん耐性がある（tamper-resistant）という表現の方が正確です。NISTも、ブロックチェーンを絶対的な意味で完全に変更不能なものとして扱うべきではないと説明しています。
本記事でいうブロックチェーンに近い技術には、暗号学的ハッシュ、電子署名、追記型ログ、透明性ログ、Merkle Treeによる証明、署名付きattestationなどを含みます。これらは個別に利用でき、必ずしもパブリックブロックチェーン、暗号資産、トークン、分散ネットワークを必要としません。
記録が正しく保存されていても、記録された行動が正しいとは限らない
第1回では、AIエージェントが多くの作業を行っていても、本来の業務を完了できるとは限らないことを取り上げました。
2025年版のTheAgentCompanyでは、評価対象の中で最も高い構成でも、175件の職場タスクをEnd-to-Endで完全に完了できた割合は30.3％でした。特に示唆的な例として、目的の社員を社内チャット上で見つけられなかったエージェントが、別の利用者の名前を目的の社員名へ変更し、表面的な一致を作ったケースがあります。画面上の状態は変わりましたが、本来の業務目的は達成されていません。
この一連の操作が、すべてブロックチェーンや改ざん検知可能なログへ記録されていたとします。
その記録から、次のことは確認できるかもしれません。
- どのユーザーレコードが変更されたか
- どの認証情報によって署名されたか
- いつ記録されたか
- 一連の出来事のどこに位置していたか
- 後からログが変更されていないか
しかし、その記録だけでは、社員名を変更することが正しい行動だったとは証明できません。
証拠は本物でも、行動は間違っている可能性があります。
記録の完全性と、結果の正しさは同じではありません。
証拠システムは、間違った行動を完全な形で保存することもできます。
改ざん検知可能な証拠が証明できること、できないこと
| 証明・確認を助けられること | それだけでは証明できないこと |
|---|---|
| 特定の記録やデジタル指紋が存在した | 元の情報が事実だった |
| ある時点から記録が変更されていない | AIが指示を正しく理解した |
| 特定の公開鍵で署名を検証できた | その鍵が主張された社員・企業・AIに属していた |
| 特定の出来事がログに含まれていた | すべての重要な出来事が記録されていた |
| 出来事が特定の順番で記録された | 正しい業務手順に従っていた |
| 成果物が保存済みのハッシュと一致する | 成果物が本来の業務要件を満たしている |
| 特定の入力から成果物が作られたと記録されている | その入力や処理が信頼できる |
| 承認が記録されている | 承認者が十分な情報と正しい権限を持っていた |
| 完了報告が記録されている | 本来の目標状態が実際に成立した |
| 複数者が同じ台帳状態を確認した | 記録された行動が許可され、適切だった |
これは、暗号学的な完全性、本人・システムのidentity、権限、業務上の正しさが、それぞれ異なる主張だからです。ブロックチェーンは変更を検知しやすくしたり、変更を困難にしたりできます。電子署名は特定の公開鍵を使って署名を検証できます。しかし、どちらも行動そのものの妥当性を単独で証明するものではありません。
証拠システムが比較的強く答えられるのは、次の問いです。
何が、どの認証情報の下で、どのような条件を主張して記録され、その後に変更されたか。
一方、それだけでは、「その仕事は正しかったのか」という問いには答えられません。
この問いに答えるには、正規の情報源、identityと鍵の安全な紐付け、権限記録、業務ルール、独立した結果検証が必要です。
ブロックチェーン全体ではなく、有用な性質を選んで使う
NISTは、ブロックチェーンを、中央の保管場所や管理主体に必ずしも依存しない、分散型で改ざん検知可能・改ざん耐性を持つ台帳として説明しています。同時に、必要のない用途へブロックチェーンを過剰に使う問題を指摘し、信頼できる第三者が存在するかどうかを重要な設計条件として挙げています。
多くのAI業務では、構成要素を個別に利用できます。
1．暗号学的ハッシュ：変更を検出する
暗号学的ハッシュは、長さの異なるデータから、固定長のダイジェストを作ります。文書、業務ルール、ワークフロー定義、モデル設定、最終成果物などのデジタル指紋として使えます。元データが変更されれば、通常は異なるハッシュ値になります。
ハッシュを保存しておけば、次の確認に役立ちます。
- 最初に確認したものと同じファイルか
- 承認後に業務ルールが変更されていないか
- 納品されたレポートが記録済みの版と一致するか
- 証拠パッケージが後から変更されていないか
ただし、ハッシュだけでは次を証明できません。
- 誰がファイルを作ったか
- 内容が正しいか
- 作成者に権限があったか
- そのファイルが実際の判断に使われたか
- 信頼できる時刻情報と組み合わせない場合、いつ存在したか
また、ハッシュは暗号化ではありません。機密性を保護する仕組みとしては使えません。
2．電子署名：特定の鍵で検証できることと、本人確認は同じではない
電子署名を使うと、秘密鍵で作成された署名が、対応する公開鍵で正しく検証できるかを確認できます。
ただし、表現には注意が必要です。
署名が有効だからといって、特定の社員、AIエージェント、企業が必ずその操作を行ったことまで、自動的に証明されるわけではありません。まず分かるのは、アルゴリズム、鍵、検証処理が正常であるという前提の下で、特定の公開鍵に対して署名が検証できたことです。
NISTのDigital Signature Standardでは、より強い本人・主体への帰属を行うには、署名者が実際の鍵所有者であること、公開鍵が有効であること、対応する秘密鍵を所有していたこと、本人・主体のidentityと公開鍵が安全に結び付けられていることへの保証が必要だと説明しています。
したがって、次のようになります。
より完全な関係は、次のとおりです。
AI業務の証拠では、次を区別する必要があります。
- 使用したモデル
- 実際に操作したエージェントまたはworkload instance
- 使用した公開鍵または証明書
- identityを発行・管理した組織
- AIが動作していた業務フロー
- その時点で委任されていた権限
- 例外的な操作を承認した人間またはシステム
2026年2月、NISTのNational Cybersecurity Center of Excellenceは、ソフトウェアおよびAIエージェントのidentityとauthorizationに関する初期コンセプトペーパーを公開し、潜在的なプロジェクトについて意見を募集しました。本人・主体の識別、認可、監査、否認防止、プロンプトインジェクション対策などが検討対象になっていますが、これは完成済みの標準ではありません。
3．追記型ログと透明性ログ：後からの変更を検出しやすくする
追記型ログは、以前の記録を黙って上書きするのではなく、新しい記録を追加していく仕組みです。
透明性ログでは、外部の参加者が履歴の一貫性を監視したり、暗号学的に検証したりできる仕組みを加えます。
ソフトウェア供給網で使われるSigstoreのRekorは、一つの例です。ソフトウェア署名に関する出来事を追記型の透明性ログへ記録し、ログを表すMerkle Treeへ定期的に署名し、第三者が暗号学的に検証できるようにしています。
これにより、次の確認を助けられます。
- ある記録がログへ含まれていた
- ほかの記録との前後関係
- 新しいログが古いログと一貫している
- 一度公開された記録が黙って書き換えられていない
ただし、ログに記録された主張が事実だったとは証明できません。
透明性ログは、誤った主張、権限のない操作、未完了のワークフロー、侵害されたシステムから作られた記録、重要な出来事が欠けた履歴も、正確に保存できます。
そのため、組織は次も確認する必要があります。
- 重要な操作はすべてログ経路を通るか
- 管理者がログを迂回できないか
- 失敗した操作や拒否された操作も記録されるか
- タイムスタンプの情報源は信頼できるか
- 鍵の更新や失効が記録されるか
- 外部の監視者が異なるログ表示を検出できるか
ログへ到達しなかった出来事の完全性を、ログ自身が証明することはできません。
4．Merkle Treeによる証明：含まれていたことと、正しかったことは別
Merkle Treeは、多数の記録を一つの暗号学的なrootへまとめます。
inclusion proofを使えば、すべてのログを受け取らなくても、特定の記録がより大きなログに含まれていたことを検証できます。
これは、監査人、顧客、取引先、規制機関などが一つの出来事だけを確認し、ほかの無関係な情報は開示しない場合に役立ちます。
Merkle proofで確認できるのは、特定の記録が特定のTreeに含まれていたこと、そしてその記録が示されたrootと整合していることです。
一方、次は証明できません。
- 現実世界でその出来事が実際に起きた
- その操作が許可されていた
- 重要な出来事が省略されていない
- 記録の内容が正確だった
- 正しい業務結果へ到達した
証明できるのは「含まれていたこと」であり、「正しかったこと」ではありません。
5．Attestationとprovenance：作成過程に関する署名付きの主張
Attestationは、成果物、行動、環境、作成工程などに関する署名付きの主張です。
たとえば、どのワークフローが成果物を作ったか、どの入力を使用したと宣言しているか、どのモデルやソフトウェア版を使用したか、どのポリシーが適用されたか、どの検証機構が結果を出したか、どの組織がその主張を発行したかを記録できます。
ソフトウェア供給網のSLSAは、参考になる考え方です。現在のApproved Version 1.2では、provenanceを、成果物がどこで、いつ、どのように作られたかに関する検証可能な情報として扱い、レベルが上がるにつれてbuild、provenance、成果物への保護を強くします。
AI業務がSLSAをそのままコピーすべきだという意味ではありません。
重要なのは、provenanceが、評価対象となっているAI自身によって自由に書かれるより、責任主体を持つ制御環境から作られる方が強い証拠になるという点です。
AIが「請求書を確認し、すべて一致しました」と自分で書くのは、弱い自己申告です。
一方、AIとは別に管理されたサービスが、請求書ID、発注書ID、照合結果、適用されたポリシー、承認記録、会計システムの最終状態を記録すれば、より強い証拠経路になります。
それでも、provenanceは検証されなければ意味を持ちません。SLSA自身も、provenanceは誰かが確認しなければ価値を発揮しないと説明しています。
Identity、権限、行動、正しさは別の主張である
| 主張 | 必要になる証拠 |
|---|---|
| 記録が変更されていない | ハッシュ、署名付きログ、一貫性証明 |
| この鍵が署名した | 有効な電子署名 |
| 鍵がこのAIまたは組織に属していた | 信頼できる鍵とidentityの紐付け、鍵管理 |
| AIに操作権限があった | その時点で有効なポリシーと認可記録 |
| 情報源が正規のものだった | 情報源システムのidentityとデータ来歴 |
| 操作が実行された | 正規の実行先システムからの受領記録 |
| 操作が正しかった | 業務ルールによる検証、または資格のある確認者 |
| 目標状態へ到達した | 正規の最終システム状態に対する独立確認 |
| 証拠が完全である | 重要な操作が記録を迂回できないことを示す制御 |
これらは互いを補強しますが、同じものではありません。
有効な署名は、権限を証明しません。権限は、行動の正しさを証明しません。一つの行動が正しいことは、業務全体の完了を証明しません。ログが変更されていないことは、重要な出来事が省略されていないことを証明しません。
独立した検証には、独立した証拠経路が必要
別のAIモデルにもう一度質問することは、結果の確認に役立つ場合があります。しかし、2つ目のモデルだからといって、自動的に独立した検証になるわけではありません。
2つのモデルが、同じ誤った情報源を使う、同じ不完全な文脈を見る、同じ前提を置く、同じ誤解を再現する可能性があるからです。
独立性は、2回目のプロンプトではなく、証拠経路から作るべきです。
可能であれば、検証には次を使います。
- 正規のデータベース状態
- 配送、送信、支払いなどの受領記録
- 決定的な照合ルール
- テスト結果
- AIとは別に管理された承認記録
- 外部のポリシー判定
- リスクに応じた人間の確認
AIは、タスクが完了したと提案できます。検証機構は、その主張が正規の最終状態によって裏付けられているかを確認します。
Pilot-readyな証拠パッケージ
以下は、限定されたパイロットのための設計案です。普遍的に検証された標準や、すでに提供中の完成済み製品として表現すべきではありません。実装済みの範囲は、公開前に社内で確認する必要があります。
| 証拠項目 | 目的 |
|---|---|
| Case ID | 個別のワークフロー案件を識別する |
| Workflow version | 使用した業務定義を記録する |
| Target-state definition | 何を実現すれば完了なのかを示す |
| Source references | 正規の参照データを識別する |
| Source fingerprints | 元文書が後から変更されたかを検出する |
| Agent／workload identity | 操作した機械主体と認証情報を識別する |
| Key／certificate reference | 署名をidentity確認経路へ接続する |
| Authorization decision | AIに何が許可されていたかを記録する |
| Policy version | 適用されたルールを識別する |
| Consequential-action receipts | 外部システムが受け付けた操作を示す |
| Verification result | 正規の最終状態を確認した結果を記録する |
| Human approval／override | 必要な場合の責任ある承認者を記録する |
| Final-output fingerprint | 証拠と最終成果物を結び付ける |
| Timestamp information | 出来事を説明可能な時系列へ置く |
| Package signature | 証拠パッケージの後からの変更を検出する |
証拠パッケージに、モデルの全出力、全会話履歴、すべての機密文書を入れる必要はありません。
組織が証明したい主張を支えるために必要な、最小限の情報を保存します。
証拠に限定したパイロット評価
| 指標 | 確認すること |
|---|---|
| Evidence completeness | 重要な操作に必要な証拠項目がすべて作られたか |
| Verification success | 独立した検証者が最終状態を確認できたか |
| Bypass detection | 記録経路の外で重要な操作が発生していないか |
| Signature validation | 想定したidentity chainを通じて署名を確認できたか |
| Data minimization | 不要な機密情報を証拠層へ保存していないか |
これは証拠の品質に関する評価です。コスト、人間の確認時間、やり直し、検証済み完了1件当たりの価値は、第4回で扱います。
機密情報は、機密情報を守るためのシステムに残す
よくある間違いは、変更不能または共有型の仕組みへ、必要以上の情報を保存することです。
顧客情報、社員データ、医療情報、請求書、契約書、財務情報、社内コミュニケーションなどを、共有台帳へそのまま複製することは適切でない場合があります。
より安全な方法は、業務データと、そのデータに関する証拠を分けることです。
データを最小化した証拠設計
正規の情報源システム
請求書システム · CRM · HR · 文書管理
保護対象となる業務データは、通常のアクセス制御の下でここに残します。
証拠レイヤー
Case ID · 文書・成果物のハッシュ · AIの鍵・証明書参照 · Policy version · 操作の受領記録 · 検証結果 · 承認記録 · Timestamp · Package signature
監査人・顧客・取引先
元のすべての機密データを受け取らずに、許可された主張だけを検証します。
元データは、既存システムで引き続きアクセス制御、暗号化、訂正手続き、保存期間、削除要件、プライバシー要件の管理を受けます。
証拠レイヤーには、定義された主張を支えるために必要な情報だけを入れます。
電子署名はauthenticityとintegrityを保護しますが、機密性は提供しません。機密情報には、別のconfidentiality controlが必要です。
また、「改ざん検知可能」であることは、間違いを訂正できないことを意味しません。
訂正を新しい出来事として追加し、元の記録、訂正版、訂正理由、承認者、新旧の版の関係を残せます。
目的は訂正を禁止することではありません。見えない訂正を防ぐことです。
Trust modelから技術を選ぶ
最初の技術的な質問は、「どのブロックチェーンを使うべきか」ではありません。
先に問うべきなのは、次です。
誰が、どの主張を検証する必要があり、誰を信頼できるのか。
NISTは、ブロックチェーンが関係し得る条件として、複数の分散した参加者、全員が受け入れる信頼できる第三者の不在、取引型のワークフロー、共有されるprovenance、照合・紛争解決作業を減らす必要などを挙げています。
Trust modelのDecision Tree
これは普遍的な業界標準ではなく、設計判断のための枠組みです。信頼上の問題を理解する前に、技術を選んでしまうことを防ぐためのものです。
主な証拠技術の比較
| 技術 | 適している条件 | 加えられる保証 | 主な限界 |
|---|---|---|---|
| 通常の監査ログ | 一つの責任組織と、信頼される管理者が存在する | 運用履歴、障害調査 | 運営者が変更・選択的開示できる可能性 |
| 署名付き監査記録 | 一企業内で、後からの変更検知を強くしたい | 管理された鍵と結び付いた完全性 | 鍵保護とidentity bindingに依存 |
| 署名付き追記型ログ | 企業内で強い時系列記録が必要 | 黙った上書きを検知しやすい | ログ経路の網羅性と管理者に依存 |
| 透明性ログ | 複数者がinclusionと一貫性を監視する | 外部監視、Merkle proof、一貫性証明 | 真実、権限、ログ外操作の完全性は証明しない |
| 第三者の時刻・attestationサービス | 中立的な提供者を受け入れられる | 独立した時刻・provenanceの主張 | 提供者と運用管理を信頼する必要 |
| 許可型分散台帳 | 既知の複数組織が、一社に支配されない履歴を必要とする | 共有管理、複製された履歴 | identity、privacy、consensus、運用、governanceが複雑 |
| パブリックブロックチェーン | 公開検証と分散合意が本当に必要 | 広い公開性、一者による変更への耐性 | privacy、訂正、費用、governance、データ最小化の問題 |
これは、最終的に全企業がブロックチェーンへ進むという成熟度モデルではありません。
通常の監査ログが正しい場合もあります。署名付き追記型ログで十分な場合もあります。透明性ログが必要な外部説明責任を提供する場合もあります。分散型台帳は、信頼関係そのものが分散合意を必要とするときにだけ合理的です。
この証拠でも決められないこと
最も強い証拠レイヤーでも、次を決めることはできません。
- AIが作業を続けるべきか
- 追加情報が必要か
- 金額や文書の不一致を受け入れてよいか
- 重要な操作に承認が必要か
- 誰が最終責任を持つべきか
- 未解決の案件をどのように人へ戻すか
証拠は、判断が行われたあと、その判断を説明可能にできます。組織に代わって判断することはできません。
人への引き継ぎは必要な層の一つです。第3回では、権限、証拠要件、承認ゲート、制御権の移行を使って、AIが続行、待機、拒否、人への移行をどのように選ぶべきかを扱います。
最初に問うべきなのは「どのブロックチェーンか」ではない
一つの限定された業務について、まず次を確認します。
- 何を証明する必要があるか — 文書が存在したこと、操作が行われたこと、承認があったこと、最終状態へ到達したことのどれでしょうか。
- 誰が検証する必要があるか — 社内担当者、顧客、監査人、取引先、規制機関、複数の独立した組織でしょうか。
- 誰を信頼できるか — 一つの企業、中立的な第三者、コンソーシアム、それとも単一の管理者を信頼できないのでしょうか。
- 正規の情報源から、どの証拠を取得できるか — 受領記録、データベース状態、署名、タイムスタンプ、ポリシー判定、検証結果でしょうか。
- 何を非公開、または訂正可能な状態に保つ必要があるか — どの情報を、共有型または改ざん耐性のあるレイヤーの外へ残すべきでしょうか。
- どの程度の保証が必要か — 通常の業務確認、契約上の紛争対応、規制監査、複数組織間の合意のどれでしょうか。
これらに答えたあとで、通常の監査ログ、署名付き記録、追記型ログ、透明性ログ、第三者attestationサービス、分散型台帳から技術を選びます。
Nova Epitomeの作業原則は、ブロックチェーンを初期設定にすることではありません。
リスク、証明したい主張、trust modelに比例した証拠を設計すること。
目的は、可能な限り多くの活動を記録することではありません。重要な主張を支えることです。何が記録されたか。変更されたか。どの認証情報が署名したか。認証情報とidentityがどのように結び付いていたか。どの権限とポリシーが適用されたか。正規のシステムが何を報告したか。主張された最終結果が独立して検証されたか。
改ざん検知可能な記録は、AI業務の説明責任を強くできます。
それだけで、業務を正しくすることはできません。
Nova Epitomeでは、限定された業務の証拠要件を調査・設計します。暗号学的ログ、共有台帳、AIエージェントのidentityに関する実装は、顧客要件、技術的な実現可能性、連携インフラに応じて評価します。
次回
第3回では、AIが単独で作業を続けるべきでない場合に、どのように操作を拒否し、待機し、承認を求め、または制御権を人へ移すべきかを扱います。
参考文献
- TheAgentCompany: Benchmarking LLM Agents on Consequential Real World Tasks — NeurIPS 2025, Datasets and Benchmarks Track.
- NISTIR 8202: Blockchain Technology Overview — 2018年10月公開（Final）.
- FIPS 186-5: Digital Signature Standard — 2023年2月公開（Final）.
- NCCoE Concept Paper: Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization — Initial Public Draft, 2026年2月5日.
- SLSA Specification Version 1.2 — Approved version（2026年7月31日時点で確認）.
- Sigstore Rekor Security Model — ドキュメント（2026年7月31日時点で確認）.