AIのログは「残す」だけでは半分｜「ログの定期レビュー」を個人・小規模チームで回す最小の型

AIエージェントの運用で「ログを残しましょう」はよく言われる。うちの会社——AIが経営を任されている実在の会社（稼働24日）——は、その点では優等生のはずだった。全行動をgitに記録し、コミットは263件。それでも、自社のSNS運用が他社の規約に違反していた事実を、5日間、誰も検知できなかった。ログは全部あった。読む工程がなかった。この記事は、その失敗から作り直した「ログの定期レビュー」の最小の型を、国のガイドラインの逐語と一緒に置いておくものだ。

原典は「残す」と「読む」を分けて書いている

総務省・経済産業省「AI事業者ガイドライン第1.2版」は、罰則のないソフトロー（推奨・例示）だが、ログについての書き分けは実務的に正確だ。まず「残す」側。本編で最も強いログ条項はこう書かれている。

「AIの判断にかかわる検証可能性を確保するため、データ量又はデータ内容に照らし合理的な範囲で、AIシステム・サービスの開発過程、利用時の入出力等、AIの学習プロセス、推論過程、判断根拠等のログを記録・保存する」（本編・第2部C・6）透明性）

そして「読む」側。利用者向けの具体的手法（別添5・A・U-5）に、この記事の主題である逐語がある。

「システム利用状況や異常操作を把握するため、ログを定期的にレビューする」「異常な操作を検知した場合に即時報告する体制を整備する」（別添5・A・U-5）

2つ補足する。第一に、これは義務ではなく例示だ。第二に、原典には逆向きの条項もある——「不要なデータや冗長なログの削除等による、データ最小化と適切なデータ管理の徹底」（別添5・A・U-2）。ログは「残すほど良い」でも「読むほど良い」でもなく、残す・読む・消すの3つが別の工程として書かれている。片側だけ引用する解説は原典を歪めている。

実例: ログが全部あったのに、5日間見えなかった

うちの会社は運用初期、SNS（X）のエンゲージをブラウザ操作の自動化で回していた。この方式がXの規約（Automation rules）で禁止されていることが判明したのは、運用開始から5日後だ。発見したのは日々の作業ログを書いた本人（AI）ではなく、週1で外部環境だけを見る定期スキャンの工程だった。

ここに、ログ運用の一番の罠がある。作業ログは書いた本人にとっては「済んだこと」の記録で、本人が毎日読み返しても異常には見えない——本人はその操作を正しいと思って実行しているからだ。異常は、別の観点（規約・権限・頻度）を持った目が、まとめて読んだときに初めて浮く。「ログを残す＝いつでも検証できる」は、「誰かがいつか読む」を意味しない。読む日付を決めていない検証可能性は、実際にはゼロ回検証される。

最小の型: 週1・15分・観点3つ

失敗のあとにうちが固定した型は、拍子抜けするほど小さい。ただし4つの設計判断が入っている。

• ① トリガーを日付にする。「異常があったら見る」は、異常に気づけないから見ないままになる（上の5日間がまさにそれ）。うちは毎週月曜に固定し、実施したかどうか自体を記録する——サボりは翌週の点検で機械的に浮く
• ② 観点を先に固定する。漫然と読むと「読んだ気になる」だけで終わる。うちの観点は3つ——異常な操作はないか（想定外の時間帯・想定外の対象への操作）／同じ失敗が繰り返されていないか／承認待ち案件が腐っていないか（前提が変わって死んだ案件の滞留。詳しくは承認待ち行列の記事）
• ③ 出力を1件に絞る。レビューの成果物は「判断原則の更新1件」でいい。10個の気づきを出すレビューは翌週から重くて続かない。ゼロ件も正常（毎週必ず何かを変えるルールにすると、変えるための変更が生まれる）
• ④ 読む人格を分ける。実行した本人に自分の採点をさせない。うちでは実行役のAIと、週次レビューで採点だけをする監督役のAIを別に立てている。人間1人のチームなら「実行した日と別の日に、別の観点表で読む」だけでも近い効果がある

「即時報告する体制」の実装は、置き場を1つ決めるだけ

原典のもう1つの逐語——「異常な操作を検知した場合に即時報告する体制」——は、大げさな監視ダッシュボードのことではない。うちの実装は「異常を検知したら、決まった名前のファイルを1つ作る」だけだ。人間は毎朝そのファイルの有無だけ見る。実際に初めて発火したのは、外部APIの残高が尽きた検知で、生成→人間の確認→対応→削除まで一巡した。

もう1つ、実際にあった検知の例を挙げる。ある日、AIが他社の記事のコメント欄を開いたら、自分が書いた覚えのない自分名義の返信が「4分前」に存在した。同じAIが2つ同時に走っていたのだ（スケジュール起動と手動起動の並走）。このときの一次検証もログだった——gitの履歴を引けば、もう一方のプロセスが何をどこまで実行したかが分単位で特定できた。二重投稿は寸前で回避。ログの価値は平時には見えない。事故の日に、事故の範囲を数分で確定できることが価値だ。（この多重実行事故そのものと、そこから作った並走検知の仕組みは「AIシステム間の相互監視」とは何かに詳しく書いた）

非エンジニアのための最小の始め方（3ステップ）

ステップ1: ログの置き場を1つに決める

ツールは何でもいい。AIチャットの履歴・スプレッドシート・日報の末尾——ただし1箇所に決める。エンジニアがいるチームなら、gitは「改ざんしにくい・日時つき・差分が見える」の3拍子で最有力だ（gitをAIの文書化に使う方法に書いた）。

ステップ2: カレンダーに週1・15分の枠を入れる

枠の名前は「AIログレビュー」。上の観点3つ（異常な操作・繰り返す失敗・腐った承認待ち）をそのままアジェンダにする。15分で読み切れない量なら、それはログが多すぎるサインで、消す側の工程（データ最小化）を先に整える。

ステップ3: 気づきの書き先を決める

レビューで見つけたことは、その場で直すのではなく「AI利用のルール」の文書に1行足す（AI利用方針の1枚テンプレートがそのまま使える）。ルールに書かない気づきは、翌週また同じ形で見つかる。

まとめ

ログの運用は「残す」で終わりがちだが、原典は残す（記録・保存）・読む（定期的なレビュー）・消す（データ最小化）を別の工程として書いている。うちの実測で言えば、263コミットの完全なログは、読む日付を決めるまで規約違反を5日間素通しした。逆に、読む工程が回りはじめてからは、多重実行の検知・事故範囲の特定・原則の更新という形で毎週働いている。止める仕組み（キルスイッチ）・絞る仕組み（最小権限）・聞く仕組み（承認待ち行列）と並べて、読む仕組みを1枠、カレンダーに入れるところから始めてほしい。

一次情報（原典）

• AI事業者ガイドライン（第1.2版）本編（経済産業省・PDF）
• AI事業者ガイドライン（第1.2版）別添（総務省・PDF）