minormonitoring-gapunverifiedcollected
「人に確認してもらう」と保留した変更15件が、受け手のいないまま積もっていた（未検証の報告）
Claude Codeの定時タスクが自動化の仕組みを少しずつ変え、変更を台帳に記録していた。数えてみると15件すべてが「判定待ち」で、いちばん古いものは判定の期限を5週間過ぎていた。実行ログには、確認した記録が毎回残っていた。
原因
無人の確認役は「自分の変更を自分で採点しない」として、判定を毎回、週次の振り返りに回していた。ところが振り返りの手順にはこの台帳への言及が1件もなく、送る側の手順にも台帳をどこへ渡すかの配線がなかった。送る側は「回した」と記録し、受け手は自分が受け手だと知らなかった。
結果
15件のうち9件は判断のやり方そのものを変えた変更で、本来は翌週に残すか戻すかを決めるはずだった。悪化の確認はほぼ毎回していて悪化は見つかっていなかったが、効果の確定と残すか戻すかの判断が止まっていた。1件は、判定するはずの定時タスクが期限の2日前に別のタスクへ統合されて無くなり、確認は0回だった。別の台帳の同じ種類の確認待ちも42日間止まっていた。
対策
筆者は「無人の側は自分で採点しない」という制約を残したまま、2つを変える直し方を示し、小さな再現で確かめた。回すときに受け手の側に受け取り口があるかを確かめ、無ければ失敗として止まる。保留に期限を付け、判定期限から14日を超えたものは警告として出す。あわせて、保留の数といちばん古い保留の日数を定期的に数え、自動化を廃止・統合するときはそのタスクを名指ししている台帳を検索する、を挙げている。
何が起きたか
筆者はClaude Codeの定時タスクに、自分の自動化の仕組みを少しずつ調整させて いた。変えた内容は台帳に1行ずつ書き、決めた日が来たら良くなったか悪く なったかを確かめる。判断のやり方を変えたものには、悪くなっていたら自動で 元に戻す決まりも付けていた。ある日その台帳を数えると、15件すべてが 「判定待ち」だった。いちばん古いものは、判定の期限を5週間過ぎていた。
現場の混乱
実行ログには確認した記録がきちんと残っていた。ほとんどの回は「無人の 実行は自分の変更を自分で採点しない。確定は週次の振り返りに回す」という 趣旨で保留していた。15件のうち9件は判断のやり方そのものを変えた変更で、 翌週には残すか戻すかを決めるはずだった。悪化の確認はほぼ毎回していて、 悪化は見つかっていなかった。止まっていたのは、効果を確定して残すか戻すかを 決める判断の方である。さらに1件は、判定する予定だった定時タスクが期限の 2日前に別のタスクへ統合されて無くなり、確認は0回のまま期限が過ぎていた。 別の台帳で同じ種類の漂流を扱う確認待ちの項目も、42日間止まっていた。
原因
週次の振り返りの手順を全文検索すると、この台帳への言及は1件もなかった。 送る側の手順にも、台帳をどこへ渡すかの配線はなかった。送る側は「回した」と 毎回記録し（途中で送る役のタスク自体も別のタスクに引き継がれていた）、 受け手は自分が受け手だと知らなかった。筆者によれば、1回ごとの保留はどれも 正しく見え、片側だけを読むと相手側で扱っているように見える。受け手が統合で 消えても、その役目を名指ししていた台帳の行はだれにも直されなかった。
対策
筆者は、無人の側が自分で採点しないという制約はそのまま残し、2つを変える 直し方を示した。回すときに、受け手の手順に受け取り口が書かれているかを 確かめ、無ければ黙って保留せず失敗として止まる。保留に期限を付け、判定期限 から14日を超えたものは「保留が積もっている」という別の問題として警告する。 受け手の側にも同じ日に受け取り口を書き、期限の古いものから並べて出す。 筆者はこれを小さな再現で流し、受け取り口の無い受け手へは回せずに止まること、 保留が受け手の画面に古い順で並ぶことを確かめている。再発防止として、保留の 数といちばん古い保留の日数を定期的に数えること、自動化を廃止・統合する ときはそのタスクを名指ししている台帳を検索すること、も挙げている。
「人に回す」は正しい制約でも、回した先に受け取り口が無ければ判断は いつまでも下りない。委譲は送る側と受け手の両方に書き、1件ずつのログでは なく積もった数で見る。