「毎週月曜にAIが状況レビューをしてくれる」という自動化を組んだ。便利だが、1つ弱点がある。そのレビュー自体が止まったとき、それに気づく仕組みが無い。人間が偶然気づくまで、誰も気づかない。この穴を、別の曜日に動く別のAIに埋めさせた話。
「自己監視は自分が壊れたら意味がない」という単純だが見落としやすい弱点と、月曜Claude×木曜Codexが互いの出力ファイルの存在を確認し合う、最小構成の交差監視の設計。
個人開発の副業ポートフォリオを毎週チェックするタスクを、AIに自動実行させている。期限が近い作業、収益目標との差、更新が止まっている情報——それらを毎週月曜の朝にレポートしてもらう仕組みだ。動き始めてしばらくは快適だった。
だが気づいてしまった。このレビュータスク自体がサイレントに止まったら、誰がそれに気づくのか。レビューが「異常なし」と報告するのは簡単だが、レビューそのものが実行されなかった場合、「異常なし」の報告すら出てこない。沈黙は正常にも見えるし、停止にも見える。自分で自分を見張る仕組みは、見張る側が壊れた瞬間に無力になる。
1つの自動化では自分の停止を検知できない。だから2つ目の自動化を、別のタイミングで走らせる。
状況把握用のスキルを読み取り専用で実行し、チャットレポートに加えて_dashboard/reviews/YYYY-MM-DD-claude.mdへ全文を保存する。さらにjournal.mdへ5行以内のエントリを追記する。「ファイルとして残る」ことが、生存確認の対象そのものになる。
月曜のClaudeレビューとは別のAI・別のツール（Codexアプリ）で、publish稼働・queue補充・facts/journalの整合を確認し、同じ命名規則で_dashboard/reviews/YYYY-MM-DD-codex.mdを出力する。このとき同時に、直近の月曜分の-claude.mdが存在するかも確認する——これが番犬の役目。
月曜のClaude側は、その回のレビューで直近木曜の-codex.mdが生成されているかを確認する。一方通行の監視ではなく、互いが互いのファイルの有無を見る対にすることで、どちらか一方だけが止まっても、もう一方の次回実行で必ず検知できる。
ここが核心。監視を強くしたいなら、監視ロジックを複雑にするのではなく、独立した別の実行主体を、時間差でもう1つ用意する。片方が沈黙しても、もう片方の周期でその沈黙自体が観測される。
このパターンの良いところは、専用の監視サーバーもWebhookも要らないことだ。「決まった命名規則のファイルが、決まった曜日に増えているか」を見るだけで成立する。_dashboard/reviews/2026-07-13-claude.mdのように日付とagent名をファイル名に埋め込む規約さえ守れば、確認は「そのファイルが存在するか」というほぼ最小のチェックに落ちる。
もう一つの利点は、監視する側自身が毎回違う視点を持ち込むことだ。同じAI・同じプロンプトが自分の前回出力を確認するのではなく、別のAI・別のモデル・別の担当曜日が、相手の仕事の痕跡を確認する。これにより「昨日と同じことを書いて済ませる」ような自己監視の形骸化も起きにくい。
個人開発の小さな自動化でも、同じ穴は起こりうる。