監査ログの量ではエージェント操作を再現できない

「監査できるログ」という言葉だけでは、必要な証拠を決められません。第一の問いは、誰がどの操作を承認したか。第二は、どのツール、対象、操作が実行され、外部システムの正式な記録で何が変わったか。第三は、どの文章、画像、送信物そのものが争点になったかです。三つは似ていますが、承認システム、業務システム、保護された内容保管庫という別々の正式な記録を使います。

NIST SP 800-53のAU-2は、事後調査に足りるイベント種類を選び、その理由を示すよう求めます。AU-3は何が、いつ、どこで、どこから、どんな結果になったかと、関係する人や対象を監査記録の基本内容に挙げます。同時に、入力や利用パターンが個人情報を露出し得ること、保持は組織・法的・監査・運用目的に依存することも認めています。[1] したがって、最小とは短いログではなく、定義した問いに必要十分であることです。

低リスクの要約処理に、高額送金と同じ必要な証拠の決め方を課す必要はありません。逆に、外部システムの状態を変える処理でモデルが返した「成功」だけを保存しても足りません。対象業務ごとに必要な確認段階を選び、満たせない段階を既知の制約として明示的に承認するか、その操作を自動化対象から外します。

• 段階1：承認者、AIの実行主体、対象、操作、制約、期限を承認記録へ結ぶ
• 段階2：試行、ツール、対象、前後状態、外部取引、取消、補償処理を一つの操作へ結ぶ
• 段階3：内容自体が争点になる場合だけ、原文または送信物を保護して保存する

段階1では、承認記録IDから、権限を委ねた人、AIエージェントまたは自動処理の実行主体、承認対象のツール・対象・操作・送信先・上限・期限、方針の版、許可／拒否／期限切れ／失効の判断を引けるようにします。ただし、実行主体の名称と許可結果だけで、本人が正確な操作を理解して承認したことまでは証明できません。承認画面と実行内容のひも付けは、権限委任側の記事が扱う事前統制です。

段階2では、操作記録ID、関連付けID、試行、再試行、重複防止キー、待ち行列／メッセージID、接続先への要求IDをつなぎます。時刻は発生時刻と記録時刻を分け、ツール呼び出しの受付、外部システムの確定、失敗、不明、補償処理（取消・やり直し）を同じ結果へ潰しません。ローカルで200応答を得たことと、顧客レコードが正式な記録として更新されたことは別の事象です。

最終的な証拠は、可能なら外部システムの取引ID、変更後の版、業務イベントへ到達させます。変更前後のハッシュ値（ダイジェスト）は同一性の照合には役立ちますが、意味や因果を証明せず、原文が必要な争いを置き換えません。再試行が二重実行になったのか、後から取消されたのか、補償処理が失敗したのかまで別イベントとして残してこそ、状態変更を再現できます。

W3Cの分散追跡規格「Trace Context Level 1」は、追跡ID（trace-id）と親処理の識別子（parent-id）をサービス間で伝え、異なる提供者の追跡記録を結合する共通形式を定めます。一方で、記録の間引きや構成要素ごとの記録判断で追跡記録が分断され得ること、記録対象フラグが実際の記録を保証しないことも明記します。追跡情報ヘッダーと追跡状態ヘッダーへ個人情報や機微情報を入れてはならず、ランダムIDでも取引の相関からプライバシー上の危険が生じます。[4]

OpenTelemetry 1.61.0は、追跡ID、処理単位のID、発生時刻、記録時刻、対象、イベント名、内容、属性を共通の項目として扱えます。ただし、多くの項目は任意で、処理単位の「成功」は外部取引の確定を意味しません。安定版という文書状態も、監査の完全性、法的十分性、ログの真正性を認証するものではありません。[5]

そこで、運用監視の追跡記録と、欠落を許さない監査イベントを同一視しません。必須の監査イベントが記録の間引き、転送機能停止、待ち行列での引き継ぎ、記録形式変更で消えないかを意図的な障害試験で試し、欠落時は明示的な不明を残します。関連付けIDは経路を探す入口であり、正式な承認記録、外部システムの正式な状態記録、改変防止、時刻品質を組み合わせて初めて、調査に使える鎖になります。

通常記録は、主体、認可判断、ツール、対象の分類、統一した表記の操作名、試行、時刻、結果、状態の版、関連付けIDだけを構造化します。対象名や引数が個人名、患者番号、秘密のファイル名を含む場合は、保護された参照IDへ置き換えます。資格情報、秘密鍵、アクセストークンを平文で残さず、通常の追跡用ヘッダーへ原文を流しません。

ただし、原文を一律に捨てるのも危険です。本稿の仮想例では、顧客が「この文面を送っていない」と争う、悪意ある取得文書がツールへの指示内容を変えた、規制対象の通信を保存する必要がある、といった場面の内容を、Catalysphereの段階3分類で証拠として扱います。NIST SP 800-61 Rev.3は、事故記録の機密性・完全性・アクセスを保護し、必要に応じて取得元と証拠の扱い方を保つ一方、全事故に正式な証拠の受渡し記録や全文保存を求めてはいません。[2]

必要時の原文保存は、目的、対象項目、期間、申請者、承認者、保管先、閲覧者、期限、保留条件を先に決めてから有効化します。短期動作確認、事故調査、規制記録、法的請求は同じ例外名にまとめません。内容を保存した瞬間に通常の監視ログ保管庫から分離し、アクセス自体も監査します。必要なときだけ保存するとは、まったく保存しないことでも、無期限に残すことでもありません。

• 通常：関連付けと状態変更に必要な決まった項目で残す補助情報
• 例外：争点を判断するために必要な範囲だけの保護された原文・送信物
• 禁止：復元できる資格情報、秘密鍵、アクセストークン、目的のない機密性の高い内容

ログに個人データが含まれGDPRが適用される場合、Article 5は目的、必要性、保存期間、完全性・機密性を、Article 6は適法な根拠を求めます。Article 25は量、処理範囲、保存期間、アクセス可能性を既定で必要な範囲へ抑える設計を求め、Article 32はリスクに応じた保護と定期的な試験を挙げます。[3] しかし、これらから万能な保存日数やAIエージェント共通記録形式は導けません。

Article 17には消去事由がある一方、法的義務、公共の任務、法的請求などの例外もあります。公表した個人データを消去する場合のArticle 17(2)は、技術と費用を考慮した他管理者への合理的措置を定める狭い場面で、すべての内部索引やバックアップを即時物理削除する一般命令ではありません。[3] Catalysphereの運用契約では、通常期限を止める保留に根拠、範囲、権限者、再確認日、解除手順を持たせます。

ハッシュ値や仮名へ置き換えても、結合可能性や再識別可能性が残れば自動的に匿名になるわけではありません。[3][4] 主保管先、検索索引、一時保存、データ保管基盤、書き出し、バックアップ、変更できない複製ごとに、削除、鍵の破棄、アクセス制限、残存期間を記録します。すべて消せると約束するのではなく、何がいつ消え、何がどの根拠で残り、誰が閲覧できるかを説明できる状態を受け入れます。

第一の証拠の確認では、既知の仮想事例を投入します。一つの承認から複数試行が生じ、待ち行列で遅延し、外部システムの状態が一度だけ確定され、別イベントで補償されたケースを、承認から最終状態まで再現します。発生時刻と記録時刻が逆転するケース、転送機能が停止するケース、接続先IDが欠けるケースも試し、欠落を「成功」に置き換えないことを確認します。

第二の集めすぎを防ぐ確認では、項目ごとの目的、個人情報／機密情報の区分、適法根拠が必要な場合の判断、通常保存期間、閲覧できる人、例外保留、削除先を検査します。一般の開発者が段階3内容を読めないこと、期限後に主な保管先と派生した索引の状態が変わること、保留解除後に通常処理へ戻ること、保持中の記録を現行ツールで読めることを試します。

二つの確認は互いの代用品ではありません。全文を残しても認可判断や接続先での確定が欠ければ証拠の確認は不合格です。反対に、美しく構造化された一連の記録でも、目的のない個人データを広い読者へ無期限に開けば集めすぎを防ぐ確認は不合格です。どちらかが落ちた場合、影響が大きい操作を停止・縮小し、記録形式または収集条件を直して再試験します。

契約票には記録形式／版、記録元、正式な記録の責任者、権限を委ねた人、AIエージェント／自動処理、認可判断、ツール／対象／操作、状態／結果、関連付けID、収集区分、機密度、閲覧できる人、保存期間、削除／保留、既知の記録できない範囲を記録します。空欄をゼロで埋めず、未収集、非該当、提供者側で取得不可を分けます。項目数の多さではなく、確認段階ごとの正式な記録と責任者が明確かを見ます。

基盤責任者は記録形式と収集経路、事故対応責任者はあとから確かめる問い、プライバシー／データ責任者は目的・アクセス・保持、セキュリティ責任者は完全性と秘密検出、ツール責任者は操作と状態の意味、運用担当は取出しと削除処理を持ちます。法務／記録管理責任者は、適用される規制保持や法的請求に関する例外がある場合だけ参加します。内部監査はこの契約と試験結果を独立に評価し、通常の共同設計者にはしません。

過剰収集が見つかったら、原文の収集を止め、対象データを隔離し、アクセスを縮小し、資格情報の露出を調べ、承認された権限で複製と索引を処理します。過少収集なら、失われた履歴を生成で補わず、影響が大きい自動実行を止めるか人へ戻し、記録形式を直して再現試験をやり直します。本番承認は「ログが多い」でも「保存が少ない」でもなく、定義した操作をあとからたどることができ、その証拠自体を統制できる場合に限ります。

• 責任者：記録形式、あとから確かめる問い、プライバシー、セキュリティ、ツール操作の意味、運用を分担する
• 再確認のきっかけ：新しいツール・対象・データ分類・保存先、記録形式の変更、試験失敗、事故で再審査する
• 例外：目的、範囲、権限者、保管先、開始、期限、解除を持つ
• 停止・縮小：過剰収集は停止・隔離・アクセス縮小、過少収集は自動実行の停止・縮小で対処する
• 本番判断：証拠の確認と集めすぎを防ぐ確認の両方が通るまで影響が大きい操作を本番化しない