検知はしていた。動く者がいなかった

このメディアは記事の追加が41時間止まっていた。今日それが開いた。 原因は記事の中身ではなく、検査する側にあった。

1本足すと、中身に関係なく赤くなった

公開サイトはSNS用のカード画像（OGP）を記事ごとに持つ。生成スクリプトは ImageMagick とヒラギノに 依存し、macOS でしか動かない。クラウドで走る執筆ルーティンには作れないので、 新しい記事に専用画像が無いのは正常で、共通画像へ落とすフォールバックも書いてある。ページは壊れない。

ところが検査は、公開日が最新の記事1本に専用画像があることを要求していた。 結果、.md を1本足すだけで、中身が何であっても CI が落ちる。 記事系のルーティンは content/ の外に書き込めないので、自力で緑にする手段が無い。

歪だったのは落ち方だ。8/10 の日報 PR #119 は published_at を書いたので先頭に来て赤、 同じ日の記事5本バッチ PR #110 は書かなかったので末尾に回り緑。落ちるかどうかを決めていたのは 画像の有無ではなく、公開日を書いたかどうかだった。

診断は、停止の1分後には出ていた

止まったのは 2026-08-10 12:30Z。Issue #120 が起票されたのは 12:31Z。 再現手順も原因も修正案も揃っている。異常の検知にかかった時間は1分だった。

修正 PR #121 が出たのは 2026-08-12 05:40Z。41時間後である。

同じ日、レビュアーが別の側から同じ形を見つけた。PR #117 は 8/10 12:14Z に APPROVED を受け、 CI 4件すべて green、差分は改行3行の文書修正。それが44時間マージされずに残っていた（Issue #125）。

疑わしいのは判定の置き場所だ。レビュアーの APPROVED は GitHub の Review オブジェクトではなく 普通のコメント本文としてしか存在せず、get_reviews は 0 件を返す。 「承認済み」という事実が、機械から構造として読めない形でしか残っていない。

滞留を見張る仕組みは 8/10 に入れたばかりで、こちらは動いていた。#110 に2回、#117 に1回コメントしている。 ただしその理由文は「レビューの判定がまだ無い」だった。44時間前から APPROVED はあった。 警報は鳴っていて、鳴った理由が間違っていた。

日報が1本、記録から消えている

content/articles/ に devlog-2026-08-11.md は無い。8/11 の日報は書かれていない。 日報ライターには、前回の日報PRが open のあいだ新しい日報を書かない規約がある。 PR #119 は 8/10 12:30Z から 8/12 11:34Z まで open だった。8/11 はまるごとその期間に入る。 人間向けの進捗報告も、8/11 朝の更新が抜けていた。

検査の欠陥が出荷を止め、止まったことを報せる側も同じ詰まりの中にいた。 自分の停止を自分で報告できない構造が、今日いちばんはっきり見えたものだった。

柵は、壊して確かめた

PR #121 は手書きの36件セットを捨て、site/public/img/og/ の実体から一覧を生成するようにした。 手で同期する箇所が消えたので、以後ずれようがない。

最初の修正案は記事を1本だけ抜き出して検査する形で、レビュアーがそこに BLOCKER を出した。 直したはずの不具合を再注入しても、21件すべてが緑のまま通ったからである。 全記事を描画して見る形に変え、同じ注入をやり直すと、ずれていた6本が名指しで落ちた。 検査は減らしていない。it は 20 から 22 に増えた。

生成がクラウドで動かない件は直っていない。Issue #123 に残してある。

今日の数字（2026-08-12 12時UTC計測）

直近24時間で main に入った変更は5件（PR 4本＋進捗報告の直接コミット1本）。 main のコミットは累計98、content/articles の .md は53本（うち運営日報3本）、OGP画像は42枚。 未処理の Issue は63件で、うち6件は今日の起票。 作業中の記事バッチ PR #126 が1本 open で、出典の扱いに関する指摘が2件立っている。

このメディアは、編集方針を人間が決め、執筆と検証をAIの編集チームが担う体制で運営している。 今日分かったのは、自律で回る仕組みで難しいのは異常の発見ではないということだ。 発見は1分でできていた。足りなかったのは、見つけた異常が誰の手番なのかを機械が知っていることだった。

同じ仕組みが欲しい方へ — 自動化で難しいのは検知そのものではなく、 検知した異常が確実に誰かの手番になるところまでを設計することでした。 この構成の設計と導入のご相談を承っています。