イベントソーシングはAIエージェントの意思決定に関する監査証跡をどのように保持するのか？
イベントソーシングは、変更可能な1つの現在状態を上書きするのではなく、承認された各判断と状態変更を順序付けられたイベントとして記録することで、AIエージェントの監査証跡を保持します。
ホームサーバーでは、これにより多段階の自動化を再構築できるようになります。ワークフローの完了後でも、オペレーターは提案、承認、ツール呼び出し、失敗、再試行、補償処理、最終状態を追跡できます。
イベントソーシングは状態変更を主要な記録として保存する
イベントソーシングでは、最新の変更可能な行だけを唯一の信頼できる情報源とみなすのではなく、承認された各状態変更をイベントとして記録します。現在の状態は、順序付けられた履歴から導出されます。
Martin Fowlerは、イベントソーシングを、アプリケーションの状態に対するすべての変更を一連のイベントとして保存する仕組みと定義しています。その履歴により、システムがどのように現在の状態へ至ったのかが保持されます。Martin Fowlerは、状態変更を一連のイベントとして保存するという考え方を軸にイベントソーシングを説明しており、これはMartin Fowlerのイベントソーシング解説で扱われている主要な記録という考え方につながります。
ホームAIエージェントでは、ProposalCreated、ApprovalGranted、ToolCallStarted、ToolCallFailed、CompensationCompletedを、1つのステータスフィールドにまとめず、個別の事実として保持できます。
エージェントの各判断が時系列の事実になる
イベントには、すでに発生した事実を記述し、後から解釈できる十分なコンテキストを含める必要があります。たとえば、ワークフローID、ツール、パラメータのハッシュ、ポリシーの判定結果、判断結果、必要に応じたタイムスタンプなどです。
Fowlerは、イベントソーシングではイベントストアが主要な信頼できる情報源となり、リプレイによって状態を再構築できると説明しています。この順序付けられた連続は、因果関係を追跡できる監査経路を作ります。Microsoft Azureは、イベントがアプリケーション状態の変更を表す追記専用イベントストアについて説明しており、これはAzureのイベントソーシングパターンで扱われる、時系列の判断事実を支えます。
有用な監査対象は、非公開の隠れた推論ではなく、観測可能な判断の成果物です。つまり、どのアクションが提案され、どのポリシーが評価し、どの結果が返され、実際にどの副作用が発生したのかという情報です。
プロジェクションがイベントログを現在のビューに変える
すべての画面やエージェントからのリクエストに対して履歴全体を毎回リプレイするのは非効率です。
イベントソーシングシステムでは、現在のワークフロー状態、保留中の承認、最近の失敗などのプロジェクションを構築します。
イベントソーシングでは、記録されたイベントから現在のアプリケーション状態を再構築できます。そのため、ロジックやデータベースが変更されても、プロジェクションを再構築できます。AWSのガイダンスは、永続化されたイベントから現在の状態を導出する方法を説明しており、基盤となる履歴を置き換えずにプロジェクションで読み取り用ビューを構築する仕組みを、AWSのイベントソーシングに関するガイダンスで示しています。
小規模なサーバーでは、スナップショットによってリプレイ時間を短縮できますが、イベントは引き続き権威ある記録として残ります。スナップショットは性能上の近道であり、イベントの連続が履歴そのものです。
相関IDが多段階の処理を1つの判断履歴に結び付ける
1つのリクエストから、情報取得、計画立案、承認、複数のツール呼び出し、再試行、補償処理が発生することがあります。
相関IDは、これらのイベントを1つの一貫した処理としてまとめます。
これは、単にログを別の場所へ保存することとは異なります。ZimaSpaceの外部監査ログ分離では、アプリが侵害されても証拠を保持する方法を説明しています。一方、イベントソーシングは、ワークフローの状態そのものを順序付けられた履歴にします。Kurrentは、順序付けられたイベントストリームと識別子を重視しており、関連するステップを追跡可能な1つの判断履歴に結び付ける仕組みを、Kurrentのイベントソーシング概念で支えています。
両方を組み合わせることもできます。イベントレコードで運用上のリプレイを行いながら、より強固な証拠保持のために、追記指向のコピーを別のログ境界へエクスポートできます。
訂正は履歴を書き換えず、新しいイベントとして追記する
エージェントの判断が後から誤りだと判明した場合、イベントソーシング設計では、元のイベントを消して書き換えるのではなく、補償イベントまたは訂正イベントを記録します。
Fowlerの二時点モデルに関する説明は、後から得られた知識によって以前の前提が訂正された場合でも、記録の履歴を追記専用に保てるという、より広い考え方を示しています。Martenはイベントを追記専用の履歴として保持し、そこから集約状態を再構築します。これは、以前の事実を黙って書き換えるのではなく、訂正を追記できる理由を示すものであり、Martenのイベントストアドキュメントで説明されています。
これは、ポリシーやプロンプトが変更された場合に役立ちます。オペレーターは、あるポリシーバージョンの下でアクションが承認され、後から取り消されたことを確認できます。修正後の最終状態だけが表示されるわけではありません。
イベントソーシングだけでは証拠が改ざん不能になるわけではない
イベント履歴の信頼性は、イベントの作成、保存、アクセス、時刻、削除を取り巻く管理策に左右されます。
ストアを書き換えられるプロセスが存在すれば、そのプロセスは自らの履歴を破壊できます。
Fowlerは、イベントログが権威ある情報ストアとして維持される場合の監査上および過去の状態を照会できる利点を強調しています。耐久性と追記制御は、別個の運用上の課題として残ります。近年の研究では、自律エージェントの活動に構造化された追記専用イベント履歴を適用していますが、アプリケーションロジックを追記専用にすることと、改ざん不能なストレージを実現することは同じではない点も明確にしています。詳しくは自律エージェントのイベントソーシングを参照してください。
ZimaSpaceの読み取り専用優先のエージェント設計は、危険なアクションが実行される前にリスクを減らします。イベントソーシングは、実際に発生した判断とアクションを保持します。
おすすめ商品
テック＆AIハブ
もっと読む
ホームカメラはクラウドの時刻サービスなしでイベントを同期できますか？
クラウドを使わないカメラ時刻の仕組みを優先した説明、共有リソースに伴うトレードオフ、クエリのファンアウトに関する3つのFAQ、そして実践的な検証手順。
ローカルAIサービスは推論前に破損したモデルレイヤーを検出できますか？
破損したモデル層の検出について、メカニズムを優先して説明し、共有リソースのトレードオフ、クエリのファンアウトに関する3つのFAQ、実践的な検証プロトコルを取り上げます。
すべての埋め込みを再生成せずにRAGシステムを復元できますか？
再埋め込みなしでRAGを復元する仕組み優先の説明、共有リソースのトレードオフ、クエリファンアウトに関する3つのFAQ、そして実践的な検証プロトコル。
