「あのとき、AIは何をしたんですか」。事故のあと、あるいは社外へ経緯を伝える場面で、この質問が来ます。
答えられるかどうかは、そのときの記憶ではなく、記録の設計だけで決まっています。実行した本人以外がたどれる形になっていなければ、思い出せる範囲までしか言えません。
この記事は、AIエージェントの監査ログに何を・どこへ・どの頻度で残すかを扱います。素材は公式ガイド4件と、自社で実際に検出した事例です（計測日2026-07-29）。
こんなふうに調べていませんか
- AIに任せた作業を、あとから第三者へ説明できる状態になっていない
- ログは出ている。ただ、それが監査ログと呼べるものかの判断がつかない
- 記録を置く場所と、見に行く頻度を決めきれていない
この記事を読み終えたときに手に入るもの
- 監査ログに書く5項目を、自社の業務単位で定義できるようになります
- 記録の保存先を、改ざん耐性とアクセス制御の2軸で選べるようになります
- 記録を見に行く頻度と担当を、3段に割り振れるようになります
結論30秒でわかる、この記事の結論
- 監査ログとは、いつ・誰が・何を・どこで・どうなったかを、あとから第三者が検証できる形で残す記録です。
- 書く項目はwhen・who・what・where・outcomeの5つで固定し、案件ID（case_id）で1本につなぎます。
- 残すだけでは点検になりません。日次・週次・インシデント時の3段で、見に行く人を先に決めます。
進行役は3人です。高梨課長が手を動かす側から、大森部長が説明する立場から聞き、鈴木さん（本誌監修）が答えます。
01AIエージェントの監査ログって、そもそも何を残しておく記録なんですか？
大森部長監査ログという言葉は聞きます。ふだん出ているログとは、どう違うのでしょうか。
鈴木さんカルテに近いと思っています。自分用のメモではなく、あとから別の担当者が読んで、同じ判断をたどり直せる形になっているか。そこが分かれ目です。
監査ログとは、AIエージェントの操作を、あとから第三者が検証できる形で残す記録です。いつ・誰が・何を・どこで・どうなったかが、そろっている状態を指します。
結論は3点です。
- 記録する項目はwhen・who・what・where・outcomeの5つで固定し、案件ID（case_id）で1本につなぎます。
- 保存先は改ざんに耐える形にし、書く側の権限と読む側の権限を分けます。
- 点検は日次の目視・週次の機械チェック・インシデント発生時の深掘りという3段で回します。
AIエージェントそのものの定義はAIエージェントとは｜3条件で見分け、任せる前に決める3つで扱っています。本記事は、止めた後・進めた後に何を残しておくかだけに絞ります。
02AIエージェントの監査ログは、承認ゲートやhooksの記録とどこが違うんですか？
承認ゲートとの違いは、止めるか記録するかです。承認ゲートは、取り消せない操作の直前で実行を止めます（詳しくはAIエージェントの承認ゲート｜止める操作4種と3層の選び方）。
Anthropicも、処理の途中で立ち止まり、チェックポイントで人からのフィードバックを待つ設計を挙げています（出典: Anthropic公式）。監査ログは、そのチェックポイントで何が起きたかを、あとから追える形で残す役割です。止めた記録が残らなければ、なぜ止めたのかを後日説明できません。
置いてみると、この2つは対立していません。止める力と、説明できる力は別の軸です。止まるけれど記録が無い状態は、理由を聞かれて答えられません。記録はあるが止まらない状態は、説明はできても操作そのものは通ります。片方だけを整えても、空いた区画が残ります。
hooksの標準出力も記録の材料になりますが、それだけでは監査ログになりません。Claude Code公式ドキュメントは、PreToolUseフックの入力を定義しています。含まれるのはsession_id・tool_name・tool_inputです（出典: Claude Code公式ドキュメント）。
これはwhoとwhatの生データにあたります。案件IDで案件へつなぎ、when・where・outcomeをそろえて初めて、あとから説明できる記録になります。
運営元WEBMARKSは2026-07-10から、ツール実行の直後に発火するフックを運用しています。このフックは、スレッドID・案件ID・書き込んだファイルのSHA-256ハッシュを記録します。この3つの識別子が、次に示す5項目を1本につなぐ軸になります。
この章のまとめ
承認ゲートは実行を止め、監査ログはその前後を残します。役割が違うので、片方でもう片方の代わりにはできません。
03AI社員に任せた作業の監査ログには、どの5項目を書けばいいんですか？
高梨課長いざ書くとなると、どこから埋めればよいのでしょうか。
鈴木さん5つの欄を先に作って、埋まらない欄がどれかを見ています。埋まらない欄が、そのまま答えられない質問になります。
監査ログのひな形は、次の5項目で固定します。どれか1つでも欠けると、あとから答えられない質問が生まれます。
| 項目 | 記録する内容 | WEBMARKSでの実装例 |
|---|---|---|
| when | イベントの発生日時（タイムゾーン付き） | フック発火時刻の記録 |
| who | 実行した主体の識別子 | スレッドID・エージェント種別 |
| what | 実行された操作の種別と対象 | ツール名・対象ファイルパス・コマンド |
| where | 対象が属する案件・保存領域 | case_id・成果物の保存パス |
| outcome | 結果・成否・承認の有無 | SHA-256ハッシュ・承認証跡の有無 |
項目の骨格は、既存のログ管理ガイドラインと重なります。NIST（米国標準技術研究所）のログ管理ガイドは、最低限の記録項目として日時・状態やエラーコード・関連アカウントを挙げています（出典: NIST SP 800-92）。OWASPのログ作成ガイドラインは、when・where・who・whatの4要素を核に整理しています（出典: OWASP Logging Cheat Sheet）。outcomeは、この4要素に「承認されたか・成功したか」を加えたものです。
欄の名前で覚えていると、埋め忘れに気づけません。「この質問に答えられるか」へ言い換えると、欠けている欄がその場で浮かびます。誰の判断かを言えないなら、whoが埋まっていません。対策の前と後を比べられないなら、whenが粗いということです。
この章のまとめ
5項目は暗記するものではなく、答えられない質問を先に見つけるための枠です。
04案件IDでつながないと、AIエージェントの監査ログは何が追えなくなるんですか？
5項目は、案件ID（case_id）でひとまとめにして初めて機能します。案件・成果物・実行ログを同じ案件IDで結ぶ運用にしておくと、あとから1つの案件について5項目すべてを1か所から追えます。
案件IDを振らずに5項目だけ集めても、記録そのものは残ります。変わるのは、探す作業が誰の仕事になるかです。案件をまたいだ記録の中から該当分を拾い出す手間が、そのつど発生します。
この手間は、平常時にはほとんど見えません。表に出るのは、事故のあとで急いで経緯をまとめる場面です。そのときに探し始めると、記録があること自体が救いになりません。
05生成AIに渡した機密は、監査ログにどこまで書いてよいんですか？
監査ログに何を残すかは、機密情報の扱いと表裏一体です。残す記録が機密の生データそのものだと、監査ログ自体が新しい漏えい経路になります。
OWASPのログ作成ガイドラインは、認証パスワード・セッションID・アクセストークンの扱いを定めています。除去・マスキング・ハッシュ化のいずれかを求めています（出典: OWASP Logging Cheat Sheet）。監査証跡も例外ではありません。
| 残すもの | 残さないもの（マスキング後のみ記録） |
|---|---|
| case_id・スレッドID・タイムスタンプ | 個人名・取引先名（「クライアントA社」等へ置換） |
| 操作種別・対象ファイルパス（汎用化） | 認証情報・APIキー・トークンの値そのもの |
| 結果のハッシュ値・承認の有無 | restricted領域の本文そのもの |
左右は、残すか消すかの二択ではありません。書き方を変えれば残せるものが、ほとんどです。取引先の名は記号へ、絶対パスは汎用化した表記へ、本文は「読んだ」という操作事実へ。粒度を落として、たどれるぶんだけを残します。
機密をAIエージェントに渡す前の分離基準はAIエージェントに機密情報を渡さない｜3段階の分離と検査で扱っています。監査ログは渡した後の記録なので、分離基準を守っていても、記録側でマスキングを省くと同じ機密が別の場所へ出ます。
WEBMARKSの実行ログは、個人のローカル絶対パスを汎用化した表記で残し、restricted領域の中身は記録に転記しません。残すのは、restricted配下のファイルを読んだという操作事実までです。
06AIエージェントの監査ログは、どこに置けば書き換えられずに済むんですか？
大森部長保存先はどう選べばよいですか。社内のどこかに置いておけば足りるのでしょうか。
鈴木さん見るのは2点です。書いたあとに書き換えられないか、書く人と読む人の権限が分かれているか。この2つを満たさない置き場は、記録というより下書きに近いです。
OWASPのログ作成ガイドラインは、改ざん検知の仕組みを組み込むことを求めています。記録をできるだけ早く読み取り専用の媒体へ移すこと、ログへの全アクセスを記録・監視することも求めています（出典: OWASP Logging Cheat Sheet）。
WEBMARKSは、記録を3層に分けています。フックの実行ログ、案件の主実行ログ、人が読む前提のタスク台帳です。
| 層 | 何を記録するか | 改ざんへの耐性 |
|---|---|---|
| フックの実行ログ | 書き込んだファイルとSHA-256ハッシュ | ハッシュ照合で書き換えを検出できる |
| 案件の主実行ログ | その案件のwho・what・when・whereの詳細 | case_idと紐づけ、他案件と混線させない |
| タスク台帳 | 人間可読の状態・次の一手・人間ゲート | 更新履歴として残る（技術的な強制はない） |
積み上げると、表の並びとは別の関係が見えます。下ほど多くの人に読まれ、上ほど機械的に固いという関係です。台帳はいちばん読まれますが、書いたことを人が守る前提の層です。フックの実行ログは読む人こそ少ないものの、ハッシュ照合で書き換えを検出できます。
だから3層は選択肢ではなく、重ねるものです。すべてを機械的な強制にすると、判断が要る例外まで書けなくなります。
この章のまとめ
技術的な改ざん耐性を持つのは上の2層です。台帳は運用ルールで支える層だと分かったうえで使います。
07AI活用の現場で、監査ログはいつ誰が見に行くんですか？
記録は残すだけでは点検になりません。いつ誰が見るかを決めて、初めて記録は機能します。
NISTのログ管理ガイドは、担当者が定期的かつ効果的なログ分析を行えていないことを、ログ管理上の課題の1つに挙げています（出典: NIST SP 800-92）。
| 頻度 | 目的 | 実施主体 |
|---|---|---|
| 日次 | 作業中の記録の書き漏れを防ぐ | 実行者本人（着手時・節目・完了時に台帳を更新） |
| 週次 | 自動化が実際に動いたかを実測で確認する | 定期の機械点検（launchdの稼働状態など） |
| インシデント時 | 異常発生時に記録を遡って真因を特定する | 担当者と、別人格の批評役 |
週次点検の値打ちは、書いた設定と実際の稼働は別物だという前提に立てることです。WEBMARKSは常駐ジョブ8本の稼働をlaunchctlで毎回実測しています。2026-07-28時点では、稼働中が1本、残り7本は定義済みで検証待ちだと把握していました。書いた設定を信じず、毎回コマンドで数え直すこと自体が、この点検の役割です。
08監査ログの保存期間は、AI社員の運用に合わせてどう決めるんですか？
保存期間も、点検の頻度と同じく自社で決める部分です。NISTのログ管理ガイドは保存期間の月数を一律には示さず、HIPAA・SOXなど適用される法規制や組織のデータ保持方針に沿って個別に定めるべきだとしています（出典: NIST SP 800-92）。事故対応や棚卸しの頻度に合わせて決めます。
09記録があったから言えたことは、AIエージェントの運用で実際に何でしたか？
高梨課長記録を残しておくと、どんな場面で効くのでしょうか。
鈴木さん手元では3つ経験しています。共通しているのは、記録が無ければ最初に出た説明のまま終わっていた、という点です。
設計だけでは、監査ログの値打ちは伝わりません。自社で記録が効いた3つの事例を、記録が無ければ何を言えなかったかとあわせて示します。
並べると、効き方が同じではないと分かります。記録が粗くて言えなかったこと、記録があったから訂正できたこと、記録の取り方そのものを変えたこと。監査ログの整備は、このどれかの向きで効きます。
事例1｜更新時刻を担当者の推定に使い、3日で233回誤爆した
2026-07-08、成果物の格上げを確認する仕組みを導入しました。直前に更新時刻（mtime）が動いたファイルを、担当セッションの成果物とみなす設計でした。導入から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ファイル方式へ切り替えることでした。
whoが粗いと、疑いの範囲が人にまで広がります。識別子は、疑わなくてよい相手を減らすために書くものだと分かった事例です。
事例3｜報告に使った本数は、実測ではなく要約ツールの出力だった
2026-07-28、姉妹メディアの公開本数を報告する場面で、いったん189本という数字が使われました。本番トップページをWebFetchで取得したときの要約に出た値をそのまま使ったもので、実測していませんでした。
数字の出どころを記録していなければ、どちらが正しいかをあとから判定できません。実際にsitemap.xmlを取得して/articles/のURLを数え直した結果は251本でした。whatには、結論の数字だけでなく、その数字をどう出したかという手段も含める必要があります。
10AIエージェントの記録づくりで、つまずきやすいのはどこですか？
落とし穴を3つ挙げます。どれも、記録を始めた直後ではなく、しばらく運用してから表に出ます。
- 集計値だけを残し、時系列や内訳を残さない：事例1がこれにあたります。対策の効果を検証したいなら、合計だけでなく発生の推移を記録します。
- 監査ログを承認ゲートの代わりだと思い込む：監査ログは記録するだけで、実行を止める機能を持ちません。取り消せない操作を止めるには、別に承認ゲートの設計が要ります。
- 生ログをそのまま台帳や報告へ転記し、マスキングを省く：記録用のログと、人に見せる報告は別の工程です。転記の前に、機密を含んでいないかを見ます。
整備の進み具合は、次の項目で確かめます。
- 記録する5項目（when・who・what・where・outcome）を業務単位で定義したか
- 案件ID（case_id）で案件・成果物・実行ログを1本につないだか
- 保存先に改ざん耐性（ハッシュ照合・追記専用の記録）を持たせたか
- 機密情報はマスキング後の要約で記録し、生データを転記していないか
- 日次・週次・インシデント時の3段で点検頻度を決めたか
- 合計だけでなく、時系列・日別の推移も残る設計になっているか
- 「この項目が欠けたら、どの質問に答えられなくなるか」を洗い出したか
11よくある質問
監査ログと承認ゲートはどう違いますか
承認ゲートは取り消せない操作の直前で実行を止める仕組み、監査ログは止めた操作・止めなかった操作の両方をあとから追える形で残す記録です。両方そろって初めて、実行の前と後の両方に説明責任が持てます。
監査ログはどれくらいの期間残せばよいですか
NISTのログ管理ガイドは、保存期間について一律の月数を推奨しておらず、適用される法規制（HIPAA・SOXなど）や組織のデータ保持方針に基づいて個別に定めるべきだとしています（出典: NIST SP 800-92）。業務の監査ログの保存期間も、事故対応や棚卸しの頻度に合わせて自社で決める必要があります。
監査ログをAIエージェント自身に書かせてよいですか
raw記録の書き込みはAIが行って構いません。ただし、承認したという事実（approved_by等）を記録する項目は、原則としてAI名を書けない設計にします。承認は作業ではなく、責任の所在を確定させる行為だからです。
hooksの標準出力をそのまま監査ログとして使えますか
一部は使えますが、それだけでは足りません。hooksの出力はwho・whatの生データを持ちますが、案件IDでの連結と、when・where・outcomeの整形が別に要ります。
個人開発や小規模チームでも監査ログは要りますか
要ると考えています。チームでなくても、送信や削除のような取り消せない操作を自分が実行したという記録は、あとから自分自身が状況を思い出すために役立ちます。
12まとめ｜今日やる3つのこと
記録する項目は5つで固定し、案件IDで1本につなぐ。保存先は改ざん耐性とアクセス制御で選ぶ。点検は頻度と担当をセットで決める。ここまでが、あとから説明できる状態の中身です。
3つの事例が示したのは、記録の有無より粒度でした。合計だけ、名前だけ、結論だけの記録は、残っていてもたどれません。
今日この順で手をつけます
直近に終わった案件を1つ選び、5項目のうち埋まらない欄を数える
欠けた欄が、そのまま答えられない質問になります
案件IDを、成果物と実行ログの両方へ振り直す
記録を線としてたどれるようにするためです
週次で見る記録を1つ決め、見る人の名前まで書く
頻度を決めることが、担当を決めることです
AI検索では、こう聞かれています
AIエージェントが何をしたかは、あとからどこまで説明できるんですか？
「AIエージェントの監査ログって、そもそも何を残しておく記録なんですか？」の章で説明しています
監査ログには、何を書いておけばいいんですか？
「AI社員に任せた作業の監査ログには、どの5項目を書けばいいんですか？」の章にひな形があります
監査ログはどこに置けば書き換えられませんか？
「AIエージェントの監査ログは、どこに置けば書き換えられずに済むんですか？」の章で3層に分けています
記録を残しておくと、実際に何が言えるようになるんですか？
「記録があったから言えたことは、AIエージェントの運用で実際に何でしたか？」の章に事例があります
次に読むなら、この記事です
