事故のあとに聞かれるのは「何が起きたのか」で、AIエージェントが関わっていれば「どこまで任せていたのか」が加わります。そのとき出せるものは、事故が起きてからでは作れません。
消せるログは、消される
アプリケーションと同じ権限で書いているログは、同じ権限で消せます。侵入した側が最初に手を付けるのがログの掃除である以上、消せる記録は無かったことにできる記録でしかありません。
攻撃でなくても同じことは起きます。ローテーションの設定が短く、原因を追いたい時刻の行だけが残っていない、という事態は珍しくありません。
書き足すことしかできない形にする
既存の行を書き換えず、状態が変わったら新しい行を足します。現在の状態は、行を最初から再生して組み立てます。イベントソーシングと呼ばれる考え方で、会計や在庫のように「経緯が残っていないと困る」領域では以前から使われてきました。
再生できるということは、過去のどの時点の状態も再現できるということでもあります。「この判断をしたとき、エージェントには何が見えていたのか」に答えられるようになります。
静かに書き換えられないようにする
追記専用にしても、ファイルごと差し替えられれば意味がありません。手当ては三つあります。
- ハッシュチェーン: 各行に前の行のハッシュを含めます。途中を書き換えると、以降が全部合わなくなります
- 書き換え不可の保管: オブジェクトストレージのロック機能など、保持期間中は削除も上書きもできない置き場へ流します
- 署名: 書いた主体を後から確かめられるようにします
全部を揃える必要はありません。ハッシュチェーンだけでも、痕跡を残さず書き換える手は塞げます。
何を書くか
誰が、いつ、何に対して、どの権限で、結果はどうなったか。この五つがあれば、たいていの問いには答えられます。
忘れられがちなのは、失敗と拒否の記録です。止めた操作こそ境界が効いた証拠になります。「読もうとして拒否された」が残っていれば、権限設計が働いた記録として読めます。成功だけを書いたログは、何も起きなかったことしか証明できません。
消せないことと、消す義務
個人情報の削除要求と、記録を消せない設計は正面からぶつかります。実務では、記録そのものを消さずに済む形に寄せることになります。
本文に個人情報を置かず識別子だけを書き、識別子と実体の対応表は別に持って、そちらを消す。あるいは暗号化して保管し、鍵を捨てて読めなくする。保持期間を先に決めることも含めて、これは設計時に決める事柄で、運用に入ってからでは動かしにくくなります。
説明のときに効く
監査やインシデント対応はもちろん、導入前の説明で効きます。AI事業者ガイドラインでもISO/IEC 42001でも、問われるのは方針の有無より「守られたと後から示せるか」です。記録の形が、その問いへの答えになります。
Aid-Onが公開しているportaでは、エージェントの通信の試行を一件ずつ追記で残しています。許可された通信も、拒否された通信も、同じ列に並びます。任せた範囲が実際にどう使われたかは、この列を読めば分かる形です。
導入済みの仕組みについては、記録が上書きできる場所にないか、拒否された操作も残っているか、この二点から確認できます。
