AIエージェントの監査ログ｜あとから説明できる項目のひな形

AIエージェントが何をしたかを、実行した本人以外があとから説明できるかは、記録の設計だけで決まります。本記事は、監査ログに何を・どこへ・どの頻度で記録するかを、5項目のひな形と自社で実際に検出した3つの事例から示します。根拠は公式ガイド4件と自社の実測です（計測日2026-07-29）。

01結論：AIエージェントの監査ログは、あとから説明できる記録のひな形

結論は3点です。

1. 記録する項目はwhen・who・what・where・outcomeの5つで固定し、case_id（案件ID）で1本につなぎます。
2. 保存先は改ざんに耐える形にし、書く側の権限と読む側の権限を分けます。
3. 点検は日次の目視・週次の機械チェック・インシデント発生時の深掘りという3段で回します。

AIエージェントそのものの定義は『AIエージェントとは｜そう呼べる3条件と、呼べない境界』で扱っています。取り消せない操作を止める仕組みは『AIエージェントの承認ゲート｜送信・公開・削除で止める仕組み』で扱っています。本記事は、止めた後・進めた後に「何を記録しておくか」だけに絞ります。

02監査ログとは何か｜承認ゲート・hooksの記録と何が違うか

監査ログとは、AIエージェントの操作を、あとから第三者が検証できる形で残す記録です。

承認ゲートとの違いは、止めるか記録するかです。承認ゲートは取り消せない操作の直前で実行を止めます（詳しくは『AIエージェントの承認ゲート｜送信・公開・削除で止める仕組み』）。Anthropicも、処理の途中で立ち止まり、チェックポイントで人からのフィードバックを待つ設計を挙げています（出典: Anthropic公式）。

監査ログは、そのチェックポイントで何が起きたかを、あとから追える形で残す役割です。止めた記録が残らなければ、なぜ止めたのかを後日説明できません。

hooksの標準出力も記録の材料になりますが、それだけでは監査ログにはなりません。Claude Code公式ドキュメントは、PreToolUseフックの入力を定義しています。含まれるのはsession_id・tool_name・tool_inputです（出典: Claude Code公式ドキュメント）。

これは「who」と「what」の生データです。case_idで案件へつなぎ、when・where・outcomeを揃えて初めて、あとから説明できる記録になります。

WEBMARKSは2026-07-10から、ツール実行の直後に発火するフックを運用しています。このフックは、スレッドID・案件ID・書き込んだファイルのSHA-256ハッシュを記録します（詳しくは『AI運用の障害切り分け｜更新時刻を犯人にしない4段の手順』）。この3つの識別子が、次で示す5項目を1本につなぐ軸になります。

03AIエージェントの監査ログに記録する5項目｜who・what・when・where・outcomeのひな形

監査ログのひな形は、次の5項目で固定します。どれか1つでも欠けると、あとから答えられない質問が生まれます。

項目の骨格は、既存のログ管理ガイドラインと重なります。NIST（米国標準技術研究所）のログ管理ガイドは、最低限の記録項目として日時・状態やエラーコード・関連アカウントを挙げています（出典: NIST SP 800-92）。OWASPのログ作成ガイドラインは、when・where・who・whatの4要素を核に整理しています（出典: OWASP Logging Cheat Sheet）。監査ログのoutcomeは、この4要素に「承認されたか・成功したか」を加えたものです。

5項目は、case_id（案件ID）でひとまとめにして初めて機能します。案件・成果物・実行ログを同じcase_idで結ぶ運用にしておくと、あとから1つの案件について5項目すべてを1か所から追えます。case_idを振らずに5項目だけ集めても、案件をまたいだ記録の中から該当分を探す作業が別途発生します。

04監査証跡として残すもの・残さないもの｜機密マスキングの基準

監査ログに何を残すかは、機密情報の扱いと表裏一体です。残す記録が機密の生データそのものだと、監査ログ自体が新しい漏えい経路になります。

OWASPのログ作成ガイドラインは、認証パスワード・セッションID・アクセストークンの扱いを定めています。除去・マスキング・ハッシュ化のいずれかを求めています（出典: OWASP Logging Cheat Sheet）。監査証跡も例外ではありません。

機密情報をAIエージェントに渡す前の分離基準は『機密をAIエージェントに渡さない｜gitignoreとフォルダ構成』で扱っています。監査ログは渡した後に何が起きたかの記録なので、分離基準を守っていても、記録側でマスキングを省くと同じ機密が別の場所に漏れます。

WEBMARKSの実行ログは、個人のローカル絶対パスを汎用化した表記で残し、restricted領域の中身は記録に転記しません。記録に残すのは「restricted配下のファイルを読んだ」という操作事実までで、読んだ中身そのものは残しません。

05監査ログの保存先はどこにすべきか｜改ざん耐性とアクセス制御

保存先を決めるときの軸は2つです。書いた後に改ざんできないか、書く権限と読む権限が分かれているかです。

OWASPのログ作成ガイドラインは、改ざん検知の仕組みを組み込むことを求めています。記録をできるだけ早く読み取り専用の媒体へ移すこと、ログへの全アクセスを記録・監視することも求めています（出典: OWASP Logging Cheat Sheet）。

WEBMARKSは、記録を3層に分けています。1つ目は、ツール実行の直後に発火するフックが書き込む案件別の実行ログです。書き込んだファイルのSHA-256ハッシュを含み、記録者自身が後から書き換えても、ハッシュ照合で検出できます。2つ目は、その案件専用の主実行ログ、3つ目は人が読む前提のタスク台帳で、状態と次の一手を人間の言葉で書き足していきます。

3層のうち、技術的な改ざん耐性を持つのは上の2層です。台帳は運用ルールで支える層で、書いたことを人が守る前提です。承認ゲートの実装層を分けた考え方（『AIエージェントの承認ゲート｜送信・公開・削除で止める仕組み』）と同じです。すべてを機械的な強制にすると、判断が要る例外まで書けなくなります。

06監査ログの点検頻度｜日次・週次・インシデント時の3段

記録は残すだけでは点検になりません。いつ誰が見るかを決めて初めて、記録は機能します。

NISTのログ管理ガイドは、担当者が定期的かつ効果的なログ分析を行えていないことを、ログ管理上の課題の1つに挙げています（出典: NIST SP 800-92）。同じ文書は保存期間について月数を一律には示さず、HIPAA・SOXなど適用される法規制や組織のデータ保持方針に沿って個別に定めるべきだとしています（出典: NIST SP 800-92）。業務の監査ログの保存期間も、事故対応や棚卸しの頻度に合わせて自社で決める必要があります。

週次点検の価値は、書いた設定と実際の稼働が別物だという前提に立つことです。WEBMARKSは常駐ジョブ8本の稼働をlaunchctlで毎回実測しています。2026-07-28時点で稼働中は1本、残り7本は定義済みで検証待ちだと把握しています。書いた設定を信じず、毎回コマンドで実測し直すこと自体が、この点検の役割です。

07監査ログが実際に検出した3つの事例｜記録が無ければ言えなかったこと

設計だけでは、監査ログの価値は伝わりません。自社で実際に記録が効いた3つの事例を、記録が無ければ何を言えなかったかとあわせて示します。

事例1｜更新時刻（mtime）を担当者の推定に使った結果、3日で233回誤爆した

2026-07-08、WEBMARKSは成果物の格上げを確認する仕組みを導入しました。この仕組みは、直前に更新時刻が動いたファイルを担当セッションの成果物とみなす設計でした。導入から3日間で、この確認メッセージは233回発火しました（出典: 社内タスク台帳、2026-07-10記録）。

記録に残っているのは発火回数の合計と真因（mtimeによる誤帰属）までです。日別の内訳は記録されていません。記録が無ければ言えなかったことは、対策後に発火回数がどう減ったかです。

合計値は残っていても、時系列を記録していなければ効果検証はできない、という教訓がここにあります。原因切り分けの経緯は『AI運用の障害切り分け｜更新時刻を犯人にしない4段の手順』で扱っています。

事例2｜記事を同時に上書きしたのは、人間ではなく2つのAIだった

2026-07-24 22:07〜22:27、姉妹メディアの記事3本が上書きされる事故が起きました。当事者は、自動復旧の監視プロセスと本体セッションの実働レーンで、どちらもAIでした。

記録を確認するまでは、AIと人間の衝突という誤った説明が一度使われました。監視プロセスの識別子（who）が記録に残っていたからこそ、当事者が両方AIだったと訂正できています。対策は、着手前に担当範囲を宣言するWRITER_CLAIMファイル方式へ切り替えることでした。

事例3｜「189本」という数字は、実測ではなく要約ツールの出力だった

2026-07-28、姉妹メディアの公開本数を報告する場面で、いったん189本という数字が使われました。この数字は、本番トップページをWebFetchで取得した際の要約に出た値をそのまま使ったもので、実測していませんでした。

数字の出どころ（要約ツールの出力か、sitemap.xmlの実カウントか）を記録していなければ、どちらが正しいかをあとから判定できません。実際にsitemap.xmlを取得して/articles/のURLを数え直した結果は251本でした。監査ログのwhatには、結論の数字だけでなく、その数字をどう出したかという手段も含める必要があります。

08監査ログ運用でつまずきやすい3つの落とし穴

1. 集計値だけを残し、時系列や内訳を残さない：事例1（233回誤爆）がそうでした。対策の効果を検証したいなら、合計だけでなく発生の推移を記録します。
2. 監査ログを承認ゲートの代わりだと思い込む：監査ログは記録するだけで、実行を止める機能を持ちません。取り消せない操作を止めるには、別途『AIエージェントの承認ゲート｜送信・公開・削除で止める仕組み』の設計が要ります。
3. 生ログをそのまま台帳や報告に転記し、機密のマスキングを省略する：記録用のログと、人に見せる報告は別工程です。転記の前に、機密情報を含んでいないかを確認します。

09監査ログを整備するチェックリスト

• 記録する5項目（when・who・what・where・outcome）を業務単位で定義したか
• case_idで案件・成果物・実行ログを1本につないだか
• 保存先に改ざん耐性（ハッシュ照合・追記専用の記録）を持たせたか
• 機密情報はマスキング後の要約で記録し、生データを転記していないか
• 日次・週次・インシデント時の3段で点検頻度を決めたか
• 合計値だけでなく、時系列・日別の推移も残る設計になっているか
• 「この項目が欠けたら、どの質問に答えられなくなるか」を洗い出したか

10FAQ