「直した」と「直っている」のあいだ

3日目に直したものは、どれも「すでに直したはずのもの」だった。

1. 検査は全部緑で、本番には衝突の跡が出ていた

トップページの本文に >>>>>>> origin/main という行がそのまま表示されていた。 Git のマージ衝突を解消し損ねたときに残る印である。前のPRでの解消が不完全なまま、 公開経路に乗っていた。

厄介なのは、型検査も144件のテストも文書検査も、そのあいだずっと緑だったことだ。 どの検査も、配信されるHTMLの中身を一度も読んでいなかった。 気づいたのは機械ではなく、サイトを開いた人間だった。

配信HTMLに衝突マーカー・TODO・undefined・[object Object]・NaN が混ざっていないかを見る検査を足し、 わざと壊して本当に検出されることを確かめた（PR #101）。 検査があることと、見ていることは違う。

2. 同じ穴を、三度塞いだ

ところが同じマージで、文書側（docs/SEARCH_CONSOLE_SETUP.md）にも同じマーカーが入っていた。 #101 が見ているのはサイトの配信物だけなので、文書側は残ったまま main に載り続けた。 文書検査に、追跡下のテキストファイルを見る検査を足した （PR #106）。

その検査にもまだ穴があった。対象を拡張子の列挙で書いていたため5ファイルが素通りし、 うち2つ（禁止語の一覧と、push 前に働くフック）は安全弁そのものだった。 列挙をやめて既定を反転させ、走査対象は139から144になった （PR #115）。

ひとつの事故に、塞ぐ作業が3回要った。「塞いだ」は「その形の穴を全部塞いだ」を意味しない。

3. 記事の生産が10時間44分止まっていた

記事が1本も増えない時間帯があった。原因は、記事5本を含むPRが15時間20分 open のまま 誰にもレビューされていなかったこと。記事を量産する側には「前回のまとめが open のうちは 新しいまとめを作らない」という規則があるので、1本の滞留がパイプライン全体を止める。

同じ構造は前日に Issue #71 として 既に指摘されていた（そのときは12時間）。指摘はあったが機械的な検知が無かったので、再発した。 2時間おきに滞留を見つけて印を付ける仕組みを入れた （PR #107）。

4. 指摘に対応した。でも main は直らなかった

その滞留検知のPRを、レビュー側が BLOCKER で止めた。本文の「24時間止まった」が実測と合わない、と。 実測は10時間44分。作成時刻をUTC、マージ時刻をJSTとして引いた結果で、同じPRの中に 正しく引いた行と混ぜて引いた行が同居していた。

止めた理由は誤差の大きさではなく、行き先だった。この数字は追記専用の仕様書に入り、 さらに今後すべての滞留PRへ自動コメントとして投稿され続ける予定だった。

書いた側は指摘を自分で測り直し、正しいと確認してから修正をコミットした（10:36:44Z）。 ところがその1分51秒前の 10:34:53Z に、PRは古い版のままマージされていた。 修正はマージ済みのブランチの上に積まれ、main には永久に入らない場所に残った。 誤った数字のほうが本番に入っていた。

基点を取り直し、修正だけを別のPRとして出し直して main を直した （PR #113）。 同時に、この日いちばん高くついた一文を作業規約に書いた。

「レビュー指摘に対応した」ことと「main が直った」ことは別の事実である。

CHANGES_REQUESTED のPRがマージされるのを機械的に止める仕組みは、まだ無い。 穴として Issue #114 に残してある（未対応）。

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

直近24時間で main に入ったPRは23本、main のコミットは累計92。 content/articles にある記事は45本（別に運営日報が2本）。テストは12ファイル・147件が緑。 未処理の Issue は57件で、うち16件はこの日に起票された「まだ塞げていない穴」の記録である。

このメディアは、編集方針を人間が決め、執筆と検証をAIの編集チームが担う体制で運営している。 3日目に見えたのは、自律で回る仕組みの弱点が生産側ではないということだった。 弱いのは、直したことをどう確かめるかの側にある。

同じ仕組みが欲しい方へ — AIに任せて難しいのは書かせることではなく、 「直した」が「直っている」に届いたかを機械で確かめ続けることでした。 この構成の設計と導入のご相談を承っています。