AIの報告を止める前に、外部監視を配線する──朝の6本を1通に束ねた報告規約

これは「エージェント経営の現場ログ」──僕ら自身のAIエージェント運用の中身を、手順書ではなく設計判断の側から記録するシリーズだ。

今回の題材は、AIからの報告そのものである。

エージェントを増やしていくと、どこかで報告が読みきれなくなる。僕の環境でそれが起きたのが2026年8月12日で、その日のうちに報告規約を作って全ループに適用した。書いておきたいのは規約の条文よりも、通知を減らす作業には順序があるという一点だ。順序を間違えると、静かで、死んでいることに気づけない自動化ができあがる。

きっかけ: 36時間で27通

秘書役のSlackチャンネルを遡って数えた。36時間で27通。そのうち半分は「差分なし」「notify 0」「滞留なし」「何もしません」の類だった。

さらに、同じ内容がまるごと毎朝2通届いているループが1本あった。cron側の自動アナウンス配信と、スクリプト自身のSlack投稿が両方走っていたためだ（2026-08-11から12にかけての実障害）。

問題は二重投稿そのものより、誰もそれに気づいていなかったことだ。毎朝同じ文面が2通並んでいて、僕は気づかずスクロールしていた。no-op報告を読み飛ばす訓練が、いつのまにか完成していたということになる。安心のための壁紙は、本当に大事な報告まで一緒に隠す。

「黙らせる」と「見えなくする」は紙一重

じゃあno-op報告を全部止めればいいのかというと、そう単純ではない。

no-op報告には副作用としての効能がある。「何もしません」が届いている間、そのループは生きている。毎朝の「差分なし」は、人間にとっては無駄な通知だが、生存確認としては機能してしまっている。これを止めた瞬間、ループが死んでも人間の側には何も起きない。静かに止まった自動化は、数週間後に「そういえばあれ、いつから来ていない?」で発見される。

だから僕は、no-op廃止を単独では実行しない、と決めた。沈黙する権利は、外部監視とセットでのみ与える。

先に配線したのは「成果物をディスクで数える第三者」

順序としての一手目は、報告を減らすことではなく、報告の外側に監視を置くことだった。

これは幸い先に存在していた。cron-output-assert という決定論スクリプトで、毎朝、各ジョブの成果物が実際にディスク上にあるかを見に行く。現在17ジョブぶんの検証エントリが入っている。

作った理由が実に現場的で、7月14日にニュース生成パイプラインがAPIエラーで途中死したのに、cronの記録上は「成功」だった。僕の環境のcronは、LLMのセッションが終了した時点でそのジョブを成功として記録する。中で何が落ちていても関係ない。その日は記事mdが生成されないまま配信が落ちた。ジョブの自己申告を信じるのをやめて、ディスク上の成果物を第三者的に見に行くようにしたのがこのスクリプトだ。

この土台があるので、no-op報告の役目を機械側に移せる。生存証明はruns.jsonl（機械が読むログ）に毎周1行残し、人間のチャンネルからは撤去する。規約の第1条にはこの条件をそのまま書いた──R1を適用してよいのは、runs.jsonlへの毎周1行と監視エントリが配線済みのループだけ。未配線のまま黙らせない。

ついでに、連載が完結しているのに毎日起動して「何もしません」と報告し続けていたループを1本見つけて引退させた。no-op報告を洗い出す作業は、そのまま不要なループの棚卸しになる。

朝の報告は「書く側の都合」で別便になっていた

no-opを消しても、意味のある報告はまだ複数便で届く。僕の環境の朝はこうなっていた。

• 06:50 予定と天気のブリーフィング
• 07:20 メールのトリアージ結果
• 07:30 公募ウォッチ
• 07:35 漫画配布の検収待ち
• 07:40 note承認待ち
• （前夜3:00に走ったLinear整理の結果も朝に読む）

書く側から見れば、それぞれが独立したループで、それぞれ完結した報告を出している。まったく正しい設計だ。ところが読む側から見ると、朝に6回通知が鳴って、6回スクロールする。ここで僕は「ブリーフィングにまとめられないか」と言った。読む側のUXから逆算すれば、当然の要求だと思う。

やったことは単純で、各ループはSlackに投げるのをやめ、共有ディレクトリにファイルを1枚書くようにした。ファイル規約は3行だけ。

• ファイル名 <NN>-<name>.md のNNが表示順
• 1行目 = 親メッセージに載る1行サマリー（先頭がNOOPなら「動きなし」に畳まれる）
• 3行目以降 = スレッド返信に載る本文

そして07:50に決定論スクリプト（LLMは使わない）が、その日のファイルを集めて親1通＋スレッド返信の形で投稿する。親を10秒読んで全体を把握し、気になるセクションだけスレッドを開く。

最初に通した実行の記録がこれだ。

posted=5,sections=4,noop=2,missing=0

その日は6セクションのうち4本に中身があり、2本は「動きなし」の1行に畳まれた。Slackに出たメッセージは親1通＋スレッド4本の計5通。通知として鳴るのは、親の1回だけになった。

いちばん効いたのは「未着⚠」

束ねる設計でいちばん効いたのは、実は畳む側ではなく来なかったものを出す側だった。

束ねるスクリプトは、期待するセクションの一覧を自分で持っている。だから当日ファイルが無いセクションは「まだ書かれていない」ではなく「上流が死んだ疑い」として扱える。親メッセージの末尾に、こう出る。

⚠ 未着: メール（mail-triage-morning 07:20）

上流のジョブ名と実行時刻まで書いてあるので、僕は親の1通を見た時点で「どのジョブを見に行けばいいか」まで分かる。全セクションが空の日は、ダイジェスト自体を投稿せず異常終了する（空の親メッセージが平常運転に見えるのを防ぐため）。

ここが今回の設計のいちばんの学びだ。報告を減らす作業は、観測性を下げるとは限らない。 減らすと下がるのは、報告そのものを生存確認に使っている場合だけだ。生存確認を機械の側（ログの鮮度＋成果物の実在＋期待セクションの欠落）に移してしまえば、人間のチャンネルは読了設計に専念できる。僕の環境では、通知の本数は減って、上流の異常は前より早く見えるようになった。

規約として正典に置く

一度きりの掃除で終わらせないために、規約をテキストファイルにして正典に置いた。全ランタイム・全ループ共通で、新しいループを作るときのチェックリストに含める。今は7条あるが、読了設計の核はこの5つだ。

1. no-opはチャンネルに出さない（stdoutと機械ログにだけ残す。ただし監視の配線が前提）
2. 成果物がある報告には、クリックで開ける直リンクを必ず付ける（サーバー内のローカルパスだけの報告は禁止。Webに実体が無いものはファイルごと添付する）
3. 1ループ1報告（cronの自動アナウンスとスクリプト内の投稿を併用しない＝二重投稿の禁止）
4. 同じ承認待ちの再掲は1日1回まで、「承認待ちN日目」を付ける（同文の連日再掲は読み飛ばしを学習させる）
5. 朝の定期報告は共有ディレクトリ経由で1通に束ねる（リアルタイム性が要る通知はこの対象外）

条文よりも大事なのは、2の「直リンク」と5の「対象外」だと思っている。前者は報告の意味を「読んで終わり」から「クリックして判断できる」に変える。後者が無いと、障害警告まで翌朝の1通に畳まれてしまう。

自分の環境で試せる最小レシピ

エージェントを2体以上動かしていて、報告が読みきれないと感じているなら、この順番で試せる。僕の環境では丸一日かからずに一巡した。

1. 数える。 報告チャンネルを直近48時間ぶん遡り、「本文に人間の判断材料が入っていない報告」の数を数える。僕はこれが半分を超えていたら、通知量ではなく設計を見直す目安にしている。
2. 黙らせる前に監視を置く。 各ループに、no-opでも毎周1行を追記する機械可読ログ（1行JSONで十分）を書かせる。そのうえで「ログの鮮度」と「成果物ファイルの実在」を毎朝チェックする決定論スクリプトを1本作る。LLMは使わない。
3. no-op報告を止める。 監視が配線できたループから順に、Slackへの「差分なし」投稿を消す。
4. 朝の報告をファイルに書かせる。 outbox/<日付>/<順序>-<名前>.md に、1行目=サマリー、3行目以降=本文で書かせるだけ。既存ループの投稿処理を1行差し替えるより軽い改修で済むことが多い。
5. 束ねるスクリプトを1本書く。 親1通＋スレッド返信で投稿する。期待するセクションの一覧をこのスクリプトに持たせて、無いものを「未着⚠」として親に出すのを忘れない。ここを省くと、ただ静かになっただけになる。
6. 規約をテキストで残す。 新しいループを作るときに読ませる。人間がレビューで毎回指摘するより、ファイル1枚を正典に置くほうが持続する。

効く範囲

この設計が効くのは、定期報告が複数本あり、かつ機械可読な実行ログを持てる環境だ。ループが1〜2本しかないなら束ねる価値はまだ小さいし、束ねる対象に即時性が要る通知を混ぜてはいけない（未返信の検知、問い合わせ、障害警告は従来どおり即時に出す）。

もう一つ、これは僕の環境で12時間ほど回した時点の記録だということも書いておく。数週間動かせば、束ねたことで逆に見落とすもの──たとえば親の1行サマリーの書き方が雑なセクション──が出てくるはずで、その時はまた直す。

まとめ

僕の運用では、報告を書く側の都合だけで設計していたら増え続けた。ループごとに独立して完結させるのが正しい設計だからで、各ループ単位では何も間違っていない。だが読む側から見れば、それは朝に6回鳴る通知でしかなかった。

だから通知は読む側のUX（朝1通、クリックで着地、例外だけ目立つ）から逆算する。そして減らす前に、生存確認の役割を機械の側へ移しておく。順序が逆だと、静かに死ぬ自動化ができあがる。

減らした報告の数より、「来なかったものが見えるようになったか」を成果として見るといい。