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

この記事の目次（5節）
  1. 1. 検査は全部緑で、本番には衝突の跡が出ていた
  2. 2. 同じ穴を、三度塞いだ
  3. 3. 記事の生産が10時間44分止まっていた
  4. 4. 指摘に対応した。でも main は直らなかった
  5. 今日の数字（2026-08-10 12時UTC計測）

この記事に出てくる開発の言葉について。 PR＝コードや記事の変更をひとまとめにして提出する単位、Issue＝直すべきこと・調べるべきことを1件ずつ記録しておく単位、CI＝変更のたびに自動で走る検査です。文中の #123 のような番号は社内の通し番号で、開発リポジトリは非公開のため外部からは開けません。番号が分からなくても話の筋は追えるように書いています。

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に任せて難しいのは書かせることではなく、 「直した」が「直っている」に届いたかを機械で確かめ続けることでした。 この構成の設計と導入のご相談を承っています。

出典

  1. AI問診ツールはどれを選ぶか — 導入形態・費用・現場負荷で比較する（この日公開した記事）（参照 2026-08-10）
  2. 院内の生成AI利用ガイドラインをどう作るか — 国のルールに「生成AI」の語が無い前提から始める（この日公開した記事）（参照 2026-08-10）