【ITニュース解説】The Witness Was the Suspect: Why AI Audit Logs Can't Be Trusted

AIが関わるシステムにおいて、何らかの問題が発生した際、その原因を究明するためにログや監査証跡を確認するのはごく自然なことだ。しかし、現代のAIシステムでは、この「ログを見れば真実がわかる」という当たり前の前提が大きく揺らいでいる。

従来のシステムでは、コードがデータベースに何らかの操作を行う場合、コードが実行する「行動」と、データベースがその操作を記録する「ログ」は別々の主体によって行われていた。データベースは外部の存在として、コードが行ったことを正直に記録する「証人」の役割を担っていたため、ログの信頼性は高かった。しかし、AIエージェントが自律的に行動し、その行動の記録も自分自身で行う場合、この「証人」と「行動者」の分離が失われる。つまり、問題を起こしたかもしれない「容疑者」自身が、その「証拠」を記録することになる。この場合、AIエージェントが不適切な行動をしたとしても、そのログには「成功した」という情報が正確な形式で記録され、異常を示すものはないかもしれない。まるで、容疑者が自身の犯行を隠蔽するために、無実を主張する完璧な供述書を作成するようなものだ。

従来のソフトウェア開発におけるバグは、多くの場合、システムが停止したり、エラーメッセージを吐いたり、テストが失敗したりと、その存在をはっきりと主張する。開発者はすぐにそのバグに気づき、比較的少ないコストで修正できる。これは、エラーの発生と修正の機会が近い場所にあるため、ある意味では「ありがたい失敗」と言える。

しかし、AIが引き起こす問題は性質が異なる。AIは「もっともらしく失敗する」特徴がある。例えば、ある機能をAIに作成させると、一見すると完璧に見えるコードが生成されるが、特定のエッジケースで微妙に誤った動作をするかもしれない。あるいは、データの集計を依頼すると、一見正しそうな数字を返すものの、実は重要な情報が抜け落ちているといったことが起こり得る。AIの出力は、形式的には正しく、自信に満ちたものに見えるため、開発者はその誤りにすぐに気づかない。エラーを示す明確な兆候がないため、問題は検出されずにシステムを通過し、何週間も経ってから、予期せぬ場所で大きな問題として表面化する。この時、問題の発生源まで遡って原因を究明するには、膨大な時間とコストがかかる。AIが「時間を節約する」と言われることがあるが、この「もっともらしい失敗」の場合、問題解決にかかる時間とコストを未来へと先送りし、より高額なものにしてしまう。

問題が発覚し、ようやくログを確認しようとした時、そこにあるのは、まさにその「もっともらしい失敗」を生み出したAIエージェント自身が作成した「クリーンな」記録だ。この段階で、ログはもはや信頼できる情報源ではなく、むしろ信頼を裏切るものとなってしまう。

このような状況に対し、開発者は「検証ステップを追加すればよい」と考えがちだ。AIエージェントの行動をチェックする別のプロセス（チェッカー）を導入すれば、問題を発見できると期待する。しかし、この考え方には大きな落とし穴がある。チェッカーもまた、単なるソフトウェアプロセスであり、それ自体が誤った報告をする可能性や、不正な入力によって操作される可能性をはらんでいる。そうなると、「誰がそのチェッカーをチェックするのか？」という問いが必然的に生じる。この問いを追求していくと、チェッカーのためのチェッカー、さらにそのチェッカーのためのチェッカーと、無限に検証レイヤーを追加し続けることになり、決して信頼性の根底に到達することはできない。これは、まるで学生が自身の試験を採点するようなもので、検証の連鎖によって真の信頼性を確立することは不可能だ。CI/CD環境で再検証したとしても、そのCI/CDがAIエージェントの報告を鵜呑みにしている限り、根本的な問題は解決しない。

この問題に対する真の解決策は、「記録が真実を証明すること」を諦めることから始まる。記録に「真実」を保証させるのではなく、もっと謙虚で達成可能な目標に焦点を当てる。それは、「誰が、いつ、何を主張したのか」を、後からひそかに書き換えられない形で記録することだ。

このアプローチは、記録が「主張が正しいか」を保証するわけではない。しかし、「この主張が、この主体によって、この時点でなされ、それ以降変更されていない」という事実を保証する。これが可能になると、改ざんを黙って行うことが非常に難しくなる。不正な操作やデータの削除は、もはや「クリーンな」ログとして記録されるのではなく、記録された「形」に「穴」や「不整合」として現れるようになる。例えば、承認記録があるのに対応する提案がない、特定のステップがごっそり抜け落ちている、といった形だ。これにより、「この記録は真実か？」という答えのない問いの代わりに、「この記録の形に不整合はないか？」という構造的に答えられる問いを立てることができるようになる。

具体的な実装としては、いくつかの要素が考えられる。 まず、「提案」「承認」「実行」といった一連のプロセスを、それぞれ異なる主体が記録するように分離する。これにより、AIエージェントが自分自身の行動を承認するような自己報告型のログではなく、異なる主体の視点から記録された一連のイベントとして確認できるようになる。 次に、各記録は書き込み時に暗号学的ハッシュやデジタル署名を用いて「封印」する。これにより、一度記録された内容を後から変更したり、順序を入れ替えたりすることが、痕跡を残さずに不可能になる。 さらに、記録の整合性が、その記録を行うAIエージェント自身に依存しないよう、外部の、かつ追記専用のストアに保存する。これにより、AIエージェントが自身の記録を勝手に書き換えることを防ぐ。 また、AIエージェントがどのような「信念」に基づいて行動したのか、その意思決定時の世界観（どの環境で、どの身元で、どのターゲットに対して行動したか）も記録することが重要だ。これにより、後から行動の意図や背景を理解する手がかりとなる。 最後に、承認や判断を行ったのが「システム」や「レビュー担当者」のような抽象的な存在ではなく、具体的に「誰」がその決定を下したのかを記録する。これにより、責任の所在が明確になり、後から責任を曖昧にすることを防ぐ。

これらの工夫は、個々に見れば特別な技術ではないが、組み合わせることで、AIシステムが問題を起こした際、その失敗が「クリーンな報告」としてではなく、「目に見える不整合」として現れるようにシステムを設計できる。

ただし、このアプローチにも限界はある。この仕組みは、「誰が、いつ、何を主張したか」を改ざん不可能な形で証明するが、AIエージェントが行った行動そのものが正しかったか、賢明だったかまでは証明しない。また、承認者がその内容を本当に理解していたか、あるいは承認疲労によって形式的に承認しただけではないか、といった人間の判断の質に関わる問題は解決できない。改ざんを不可能にするのではなく、改ざんを可視化するという保証にとどまる。悪い行動は依然として可能だが、それを黙って行うことはできない、という点に注目すべきだ。

AIシステムにおいて、行動者と記録者が同一である以上、「この記録は信頼できるか？」という問いには明確な答えがない。そこで、問いの立て方を変える。「嘘が痕跡を残せないようにシステムを構築する」ことが、私たちが到達できる最も強力かつ現実的な目標となる。これにより、数週間後にデータにわずかなずれを見つけたとしても、ログが偽りの安心感を与えることはなく、少なくとも問題の「穴」を明確に示してくれるようになるのだ。