AI監査ログ・監査証跡とは
AI監査ログは、AIシステムの設定、入力、出力、その後の操作を検証するための記録です。監査証跡(audit trail)として利用するには、モデルのバージョン、適用したポリシー、ツールの呼び出し、人間による承認、実行結果、エラーや復旧を関連付ける必要があります。
目標は「どのシステムが、どの権限とルールの下で、この結果を生んだのか」を追跡できることです。すべてのプロンプトやモデル内部の処理を無条件に保存することではありません。何を記録するかを用途に応じて定義し、その範囲をテストします。
分けて確認する3つの問い:記録は変更されていないか。記録された出来事は実際に起きたか。その判断は妥当だったか。暗号技術による検証が直接扱うのは、主に最初の問いの一部です。残りには別の証拠や評価が必要です。
通常のログとの違い
| 記録の種類 | 主な目的 | 追加で確認する事項 |
|---|---|---|
| アプリケーションログ・エージェントのトレース | 遅延、エラー、実行経路の調査。 | 収集範囲、保存期間、アクセス管理。サンプリングによる欠落。 |
| 追記型・アクセス制御付きログ | 保存済み記録を変更できる主体の制限。 | 特権管理者、鍵管理、バックアップ、エクスポートに関する証拠。 |
| 暗号学的に検証可能な監査証跡 | 署名、記録間の整合性、生成主体の外部に固定した証拠の検証。 | 検証ポリシー、鍵の履歴、外部アンカー、収集境界に対する独立した評価。 |
これらは併用できます。障害調査用のトレースを維持しながら、重要な意思決定の境界に検証可能な記録を追加します。ダッシュボードの画面だけでなく、第三者が再検証できる記録と検証結果を用意することが重要です。
項目を選ぶ前に収集範囲を決める
送金を要求するAIエージェントなら、依頼の受信、ポリシー判定、承認、ツールへの要求、実行結果が一つの流れになります。アルゴリズム取引なら、シグナルから注文、約定までの関係が対象です。拒否、タイムアウト、失敗も流れの一部として記録します。
- イベントを洗い出す:生成元、キュー、ポリシーエンジン、外部ツール、人間の操作を特定します。
- 相関関係を決める:依頼・判断・操作・結果を安定した識別子で結び、再試行と新規操作を区別します。
- 障害時の動作を決める:収集失敗、バッファ中の記録、時計の不確かさ、復旧の扱いを定義します。
- 対象外を明記する:サンプリング対象、未対応の操作、第三者から取得できない記録を列挙します。
署名検証の成功だけで、すべての出来事が記録されたとは判断できません。最初から観測されなかった操作は、別の操作のハッシュから復元できません。
イベント項目の設計例
以下は設計を考えるための例であり、VAP・VCPの正式なデータ形式ではありません。実装時には、対象プロファイルの仕様とスキーマに従ってください。
{
"event_id": "example-event-0042",
"correlation_id": "example-request-0017",
"event_type": "tool_result",
"occurred_at": "2026-10-24T09:30:00Z",
"producer_id": "payment-agent-test",
"model_version": "model-release-7",
"policy_version": "approval-policy-3",
"action": "payment_request",
"outcome": "denied",
"reason_code": "human_approval_missing",
"payload_reference": "restricted-evidence-store/item-42"
}実際には、正規化方法、ハッシュ・署名の対象、鍵の識別子と有効性、時計の品質、順序、外部アンカーとの対応も必要です。この例には検証用の証拠を含めていないため、そのまま暗号学的検証を行うことはできません。
機微なデータの本体は、可能ならアクセス制御と保存期限を設定した別の保管場所で管理します。推測しやすい情報はハッシュから候補を照合できるため、氏名や口座番号をハッシュ化するだけで匿名化したことにはなりません。各項目について、参照情報・保護されたコミットメント・原文保存のどれが必要かを検討します。
証拠パッケージの検証手順
- 範囲とバージョンを特定する:対象システム、期間、ポリシー、プロファイル、仕様のバージョンを確認します。
- 記録を検証する:スキーマと正規化方法を確認し、ダイジェストを再計算して、署名、鍵の履歴、仕様が求める連結・順序の条件を検証します。
- 外部アンカーを独立に確認する:コミットされたバッチへの包含を検証し、適切な信頼経路でタイムスタンプや透明性ログの証拠を取得します。
- バッチの境界を確認する:束縛されたイベント数、先頭・末尾のイベントID、ポリシーIDを照合し、連続性と復旧の規則を適用します。
- 別の記録と照合する:ツールの受信側や取引の相手方など、取得できる独立した記録と比較します。
- 検証結果と限界を併記する:成功、失敗、証拠不足、対象外を分け、検証器のバージョンと入力を残します。
必須の証拠が不足している場合は明示的に結果へ反映し、未完了の検証を成功として扱わない設計にします。
VAP・VCPが提供する範囲
Verifiable AI Provenance Framework(VAP)は、分野別プロファイルに共通する記録の要件を定義します。VeritasChain Protocol(VCP)は、アルゴリズム取引・AI取引のための金融分野のプロファイルです。2026年10月24日時点で、VAPはv1.2.0 Draft 3、VCPはv1.2.0 General Availability(正式リリース)であり、別々の公開状況です。
VAPのINT-008は、アンカー済みバッチが宣言する範囲内で、アンカー後の記録省略を検出するための要件です。イベント数、先頭・末尾のイベントID、ポリシーIDを束縛します。バッチに一度も含まれなかった出来事を、それだけで発見できるわけではありません。その出来事の存在を示す別の記録が必要であり、一度も観測されなかった出来事は対象外です。
VAP・VCPは検証可能な記録の基礎を提供しますが、エージェントの権限制御、危険な操作の阻止、判断品質の保証、規制当局の承認を提供するものではありません。詳しくはVAP仕様の§§1.6・4.1・11.1とVCP v1.2.0仕様をご確認ください。
導入を評価するチェックリスト
- 生成元のダッシュボードを信頼しなくても、記録をエクスポートして検証できるか。
- モデル、ポリシー、生成元、人間の承認者について、識別情報とバージョンを残しているか。
- エラー、再試行、拒否、復旧を記録し、元の依頼と関連付けているか。
- 内容の改変、不正な署名、アンカー後の記録省略をテストで検出できるか。
- 鍵のローテーション、時刻の不確かさ、アンカー取得不能を明示的に扱っているか。
- プライバシーと保存期間の方針が、必要な検証と両立するか。
- 記録の完全性と、現実の正しさ・収集範囲の完全性を区別して報告しているか。
まずは重要な一つの業務を選び、合成データで試します。独立に作成した期待イベント列と記録結果を比較し、失敗時の動作を理解してから対象を広げます。
よくある質問
AI監査ログと説明可能性は同じですか。
異なります。監査証跡は記録された操作と文脈の関係を追跡します。説明可能性はモデルが出力を生成した理由を扱います。説明文を署名付きで保存しても、その説明がモデルの動作を忠実に表している証明にはなりません。
監査証跡にはブロックチェーンが必要ですか。
必須とは限りません。VAPはタイムスタンプ局、透明性ログ、公開ブロックチェーンなどの外部アンカーを扱います。対象プロファイル、信頼モデル、運用要件に合わせて方式を選択します。
VCPへの適合は法令遵守の証明になりますか。
なりません。プロトコル適合性と法令遵守は別の評価です。VeritasChain Certified(VC-Certified)はプログラムで定義する技術的範囲を扱い、組織による法務・規制上の評価を代替しません。