CASE · 中程度 · monitoring-gap
検証済み運営者の一次記録「毎週金曜更新」の号が出なかった。自動の工程は全部動き、下書きの工程だけ起動役がいなかった
このサイトは「毎週金曜更新」と告知している。2026年10月16日(金)、第3号(2026-W42)は出なかった。収集・採点は毎日成功し、選別も済んでいたが、下書きのブランチもプルリクエストも存在しなかった。運営者が10月19日(月)に「記事が増えていない気がする」と感じて調べるまで、何も知らせなかった。
約4分で読めます
- 発生日
- 分類
- monitoring-gap
- 影響範囲
- reputation, uptime
- 検知
- manual-observation
- タグ
- #weekly-issue #editorial-pipeline #github-actions #human-in-the-loop #missing-trigger #silent-failure #dogfooding
CH 1
原因
週の流れのうち、水曜の「Claudeが下書きする」工程だけ、起動する仕組みが無かった。設計書には曜日と担当が書いてあったが、実際には運営者がセッションを開いて頼んだときにしか動かない。その週は運営者がSEO修正と別製品の公開に追われ、頼む人がいなかった。後ろの照合と公開は、プルリクエストが「ある」ことをきっかけに動くため、「無い」ことには誰も反応しなかった。
CH 2
結果
金曜の号が3日以上遅れ、告知していた更新の約束を破った。サイトに最後に記事が増えたのは10月12日で、それから1週間、新しい記事が出なかった。選別した正式10件・短信24件・論点4件は、下書きされないまま残った。データは失われていない。
CH 3
対策
10月19日に遅れた号の下書きを作り、プルリクエストにした(正式3件・短信5件・論点1件)。再発防止は検討中で、案は2つある。下書きの工程を決まった時刻に起動すること、そして金曜を過ぎても号が公開されていなければ知らせること。人やAIに頼む工程にも、ほかの工程と同じく起動役と「起きなかったこと」を見張る役を置く。
LOG経過
- 発生
記録上の発生日(date_observed)
- 検知
発生から3日後 · 検知の経路:
manual-observation
記録された日付(date_observed・date_detected・date_resolved)だけで構成しています。
何が起きたか
Blackbox Blastは「毎週金曜更新」と告知している。2026年10月16日(金)、 その週の号(第3号、2026-W42)は出なかった。第1号は9月30日に下書きし、 第2号は10月9日(金)の夜に下書きしてその日のうちに公開していた。
止まった工程は一つだけだった。毎日の収集と採点はGitHub Actionsで成功し続け、 その週の候補は52件集まっていた。運営者は管理画面で46件を選別し、正式10件・ 短信24件・論点4件を選んでいた。ところが、それを記事にする下書きのブランチも プルリクエストも作られなかった。
気づいたのは10月19日(月)だった。運営者が「記事が増えていない気がする」と 感じて調べた。どの仕組みも、それより先には知らせなかった。
現場の混乱
調べると、自動の工程はどれも正常だった。収集は10月12日から19日まで毎日 成功し、選別を候補リストに書き戻す処理も選別のたびに成功していた。 事実確認、著者への連絡の下書き、検索エンジンへの通知の各ワークフローも 動いていた。失敗のログはどこにも無かった。
週の流れは設計書に次のように書いてある。毎日、収集と採点。火曜、運営者が 選別。水曜、Claudeが下書きしてプルリクエストを作る。木曜、自動の事実確認の 結果を運営者が読む。金曜、運営者がマージして公開する。
このうち水曜だけ、動かすものが無かった。過去の2号は、どちらも運営者が セッションを開いて「下書きを作って」と頼んだときに作られていた。 その週の運営者は、SEOの修正(プルリクエスト6本)と、別製品の紹介ページの 公開に追われていた。下書きを頼む場面は来なかった。
選別も遅れていた。設計では火曜の15分だが、W42は10月12日から18日まで 少しずつ進み、終わったのは金曜を過ぎた日曜だった。
原因
設計書の「水曜:Claudeが下書き」は、ほかの行と同じ書き方で並んでいた。 収集の行の裏には毎日のcronがあり、事実確認の行の裏にはプルリクエストで 起動するワークフローがある。下書きの行の裏には何も無かった。曜日と担当が 書いてあるだけで、誰が起動するかは書いていなかった。AIが担当する工程は、 人が頼まない限り始まらない。
二つ目の原因は、後ろの工程の起動条件にある。事実確認はプルリクエストが 作られたときに、公開はマージされたときに動く。どれも何かが「起きた」ことを きっかけに動き、何かが「起きなかった」ことには反応しない。下書きが無ければ 照合も公開も起きず、静かなまま金曜が過ぎた。
10月18日には、この2週間の運用を振り返るセッションも開いていた。だが 記録を検索した範囲では、号が出ていないことは話題になっていない。
対策
10月19日、遅れた号の下書きを作った。選別済みの中から正式3件・短信5件・ 論点1件に絞り、日英で書き、プルリクエストにした。この記事を書いた時点では、 自動の事実確認の結果を見直している途中で、まだ公開していない。
再発防止は検討中で、案は2つある。一つは、水曜の決まった時刻に下書きの 工程を起動すること。下書きには判断が多いので全自動にはせず、起動と プルリクエストの作成までを自動にする。もう一つは、金曜を過ぎても号の マージが無ければ知らせること。前者が止まっても後者が拾う。
運用する側の教訓:工程表に曜日と担当を書いただけでは、その工程は動かない。 人やAIに頼む工程にも、cronの工程と同じく起動役を置く。そして、 「起きたこと」に反応する仕組みとは別に、「起きるはずのことが起きなかった」 を見張る仕組みを置く。全部が成功しているときに起きる失敗は、ログには残らない。
出典
- 運営者自身が起こした事故の一次記録です。外部に公開された元記事はありません。
この記録をチームに回す