以前、月曜と木曜で別のAIに互いの生存を確認させる「番犬設計」を組んだ。2ヶ月運用した今回、実際に長い沈黙が発生した。だが番犬が捕まえたのは、その沈黙のごく一部だけだった。設計が見ている範囲と、見ていない範囲の境界が、実地で初めてはっきりした話。
相互監視の番犬設計を実際に3ヶ月近く動かして起きた、「監視対象そのものが監視範囲の外にあった」「番犬自身の実行タイミングは誰も確認していなかった」という2つの死角と、その埋め方。
以前の記事で、週次レビューという自動化自体が止まったときに気づけない問題に対し、月曜にClaudeが状況レビューを行い、木曜に別のAI（Codex）が「月曜分のレビューファイルが存在するか」を確認し合う——という交差監視を組んだ。狙いは単純で、片方が沈黙しても、もう片方の周期でその沈黙自体が観測される設計にすることだった。
2026-09-26、木曜チェックの記録を見ると、直近のClaude週次レビューは09-14止まりで、09-21分が保存されていなかった。番犬は仕事をした——のだが、同じタイミングで別の場所でも沈黙が起きていた。X運用（ポストとリプライの自動実行）を担当する自動化が、09-20 15:44を最後に、09-21から09-25までの5日間、ジャーナルに実行記録そのものが一切残っていなかった。ブロック報告すらない、完全な空白だった。
番犬が確認していたのは、片方の穴だけだった。週次レビューの沈黙には気づけたが、5日間の完全な空白が起きていたのはX運用というそもそも番犬の監視対象に入っていない自動化だった。そちらは番犬の周期ではなく、当人（X運用タスク）が久しぶりに動いて自己申告するまで、誰にも観測されていなかった。
相互監視の設計そのものは正しく機能した。だが「監視している」という感覚が、無関係な自動化にまで安心感を広げてしまっていた。
月曜Claude×木曜Codexの往復が確認しているのは、_dashboard/reviews/配下に決まった命名規則のファイルが増えているかどうかだけ。これは週次レビューという1つの自動化ペアのための設計であって、ポートフォリオ全体の自動化を包括的に見張る仕組みではない。作った本人も、いつの間にか後者のつもりで安心していた。
X運用の自動化は、ブラウザ拡張の接続断という別系統の障害要因を抱えており、09-07〜09-15の間だけで累積7回のブロックが記録されていた。傾向としてはすでに悪化していたのに、それを見張る番犬はどこにも配置されていなかった。1つの監視ペアを作ったことで、他の自動化まで見張られている気になっていたのが実際の失敗だった。
これが実地で分かったこと。相互監視は「その監視が明示的に対象にした自動化」にしか効かない。ポートフォリオ内の自動化が増えるほど、「この番犬は何を見ていて、何を見ていないか」を一覧できるリストが要る——番犬そのものより、番犬の守備範囲を管理する方が実は難しい。
木曜チェックは毎週木曜9:30に動く設計だった。だが09-26付けの出力を見ると、直前の09-24（木）に対応する実行の痕跡が見当たらず、チェック自体が09-26（土）に生成されている。チェックを行った当人（Codex）自身が、その回のレビューの中で「オートメーションはACTIVE表示なので、実行履歴側の確認が必要」と書き残しており、自分がいつ動いたのかを、自分の外側の証拠なしには断言できていない。
これは前回記事で書いた「ファイルの有無」という最小チェックの弱点でもある。reviews/2026-09-26-codex.mdというファイルが存在すること自体は確認できても、それが本来の予定日（木曜）に生成されたのか、遅れて生成されたのかは、ファイルの有無だけからは分からない。ファイル名に日付を埋め込んでいても、それは「レビュー対象の週」を表しているだけで、「実際にいつ実行されたか」の証拠にはならなかった。
存在確認だけでは足りない場合がある。「決まった場所に決まった頻度で何かが増えているか」という最小チェックは、片方が完全に沈黙した状況には強い。だが「遅れて動いた」という中間状態には気づけない。番犬の実行タイムスタンプそのものを、スケジューラ側の履歴と突き合わせる一段階が別途要る。
前回の設計記事: 自動化は黙って死ぬ——AI同士に見張らせる番犬設計