AI に毎週の見回りを任せた — 読み取り専用・ログに追記・疑ったらまず裏取り

2026-06-11 ／ 第20号 ／ 公開時点では下書き

前号で、サイトマップに 31 本載せているのにインデックスは 1 本だけだった、という話を書いた。あの問題に気づけたのは、たまたま Search Console を開いたからだった。
「たまたま開いたから気づいた」は、運用としてはかなり危うい。そこで 6 月に入って、AI のスケジュール実行（決まった曜日・時刻に AI が勝手に動く仕組み）で、毎週の「見回り」を 3 本走らせ始めた。

毎週 3 本の見回り

今走っているのはこの 3 本：

どれも、やること自体は難しくない。難しいのは毎週欠かさずやることで、私はこれが続かない側の人間だった。Search Console は気が向いたときしか開かないし、PC のセキュリティ画面は「何かあったとき」しか見ない。何かあってから見るのでは遅い、というのが前号の教訓だった。

設計原則は 3 つに絞った

1) 読み取り専用。見回りは直さない。リンク切れを見つけても、設定の不備を見つけても、ログに書くだけ。直すのは、私がログを読んで依頼した時だけ。
AI を信用していないからではなくて、「見回りのついでに直す」を許すと、何がいつ変わったのか追えなくなるから。巡回と変更を同じ仕組みに混ぜない。

2) ログに追記。毎回新しいレポートを作るのではなく、毎回同じ Markdown ファイルの末尾に足していく。3 ヶ月後にそのファイルを開けば、12 週分の推移が上から順に読める。AI への指示も「前回までの記録を読んでから、今回の結果を追記して」で済む。

3) 既知の状態を教えておく。意図的にやった設定変更——たとえば起動を速くするために止めた常駐サービス——は、「これは意図的」と AI のメモリに入れておく。そうしないと、見回りのたびに「サービスが無効になっています」と毎週同じ警告が上がってきて、ログがノイズで埋まる。正常の定義を先に渡しておくのが、誤検知を減らすのに一番効いた。

初回でさっそく誤報を出した

とはいえ、それでも誤報は出た。正直に書く。

初回の PC 監査で、AI は「未署名ツールの実行がブロックされ続けている。除外設定の検討が必要」とフラグを立てた。セキュリティ機能が、私が先日入れた開発ツールを止めている、という報告だった。

でも私は、そのツールを前日も普通に使っていた。「それ、動いているはずだけど」と指摘して掘り直してもらったら、真相はこうだった：

・そのブロックは導入直後の数時間だけ起きる一過性のもの（新しい実行ファイルの評価が定まるまでの、設計どおりの挙動）
・実際、ブロックの記録は導入当日の数時間に集中していて、それ以降はゼロ
・AI は管理画面の過去 30 日分のレポートに残っていた古い記録を「現在も継続中」と誤読していた

レポートに載っている＝今も起きている、ではない。人間でもやる誤読だが、AI も同じ誤読をする。
以後、見回りのルールに 1 行足した：フラグを立てる前に、①記録の日時が新しいかを確認する、②実機で再現するかを確認する。今回で言えば、ツールを実際に実行してみれば 5 秒で「動く」と分かる話だった。

学び：「異常の検出」より「正常の記録」

回し始めてまだ 2 週間足らずだが、価値の重心が当初の想定とずれていることには、もう気づいた。

始める前は「異常を早く見つけてくれる仕組み」だと思っていた。実際に効いているのは、毎週「変化なし」と書かれたログが溜まっていくことのほう。

「変化なし」が 10 週並んだログでは、11 週目に何かが変わったとき、その 1 行が際立つ。逆に記録がなければ、「これっていつからこうだっけ？」に誰も答えられない。今回の誤報騒ぎも、ログに日時が残っていたから「一過性で解消済み」と確定できた。正常の記録は、異常が起きた日のための布石だった。

人間の仕事は月 1 回の流し読み

では私は何をするのか。月に 1 回、ログを流し読みする。それだけ。

全行は読まない。「変化なし」が並んでいる区間は飛ばして、「要対応」「注意」の印が付いた行と、前の週と書きぶりが変わった行だけ拾う。気になった行があれば、そこで初めて AI に「この行、深掘りして」と依頼する。直すかどうかを決めるのも、直す依頼を出すのも、この時。

毎週の巡回は AI、月 1 回の判断は私。見回りと判断を分けたら、どちらも続く形になった。続かなかったのは私の根気の問題ではなくて、巡回と判断を同じ人間が同じタイミングでやろうとしていた設計の問題だった——ということにしておく。