委任した作業のログに「◯件更新完了」と書いてあっても、それだけでは検品にならない。実際にあった一括更新作業を例に、ログを読むだけの検品がなぜ機能しないか、そしてどう三段階で実物を確認するかを書く。
ログ → ローカル実物 → 本番実物の3段階検品プロセスと、成功だけでなく失敗・部分完了も正直に書かせるログ設計の考え方。
AIエージェントに一括作業を委任すると、最後に作業ログが返ってくる。「◯件更新しました」「エラーはありません」と書かれていれば、つい安心してそのまま次の作業に進みたくなる。だが、そのログ自体もAIが書いたものだ。ログを読むだけの検品は、ログの中身が正しいかどうかを検証していない。
実際に運用しているルールは単純で、委任・自動化した作業は、成果物ログを読むだけでなく、実物を検証してから完了とするというものだ。「実物」とは、ローカルのファイルをコマンドで数えることであり、公開後の本番URLに実際にアクセスして確認することを指す。
複数のHTMLファイルに同じ変更を一括で入れる作業を例に、実際に踏んだ3段階を書く。
まず作業ログの件数・対象ファイル一覧・スキップ/エラーの有無を読む。ここでは「公開済み記事◯件＋予約投稿キュー◯件＋テンプレート◯件、合計◯件」のように、対象範囲が数字で宣言されているかを確認する。数字がなければこの時点で差し戻す。
ログの数字を鵜呑みにせず、grepや検索コマンドで対象ファイル内に変更が実際に入っているかを自分で数える。さらに、同じスクリプトをもう一度 --dry-run で流し、全件が「既にマーカーあり＝skip」になるかを確認する。2回目に何か1件でも「未適用」と出たら、初回の適用が漏れていた証拠になる。
ローカルのファイルが正しくても、公開処理（アップロード・デプロイ）が別工程である以上、そこでも失敗しうる。実際に公開URLへHTTPアクセスし、狙った変更（表示文言・リンク・価格表記など）が反映されているかを目視・機械的に確認して、初めて完了とする。
ここが核心。ログは「AIが何をしたと申告しているか」でしかない。grepと本番HTTPアクセスは、申告と実物の間にズレがないかを確認する、唯一の第三者チェックだ。
検品する側の努力だけでは限界がある。委任する側のログ形式にも、失敗・部分完了を隠せない構造を仕込んでおくと、検品の負担がぐっと減る。実際に効いているのは次の2つだ。
「成功だけ書かれたログ」が生まれるのは、多くの場合ログの形式そのものが成功しか書く欄を用意していないからだ。失敗を書く欄を先に用意しておけば、埋まっていないこと自体が異常のサインになる。
大規模なチーム開発でなくても、個人開発でAIに一括作業を任せる場面ならそのまま使える。