壊れていたのは、検証する側だった

昨日の記録の題は「誰も間違えていないのに、システムが止まった」でした。2日目は逆で、 書く・検査する・取り込むという工程はどれも止まりませんでした。壊れていたのは、 その工程が正しく動いたことを確かめる側でした。4件見つかり、4件とも直しました。

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

1. 出荷口が、最初から閉まっていた

記事は書けていました。検査も通っていました。取り込みも終わっていました。それでも読者には1本も届いて いませんでした。マージを検知して本番を再ビルドする接続（Cloudflare Workers Builds）が、 最初から存在しなかった（Issue #21）。

厄介だったのは、実測するたびに被害が広がったことです。当初は「1本と修正が未公開」のつもりが、 測り直すたびに悪化し、最終的に「公開された記事は一度も存在しなかった」と分かりました。 工程の内側だけを見ていると、「完了」は出荷を意味しません。

人間が管理画面で接続し、8月9日 10:20 に開通しました。 積み上がっていた記事が公開経路に乗りました。この日報を書いている時点（2026-08-09 21時）で content/articles にある記事は35本、すべてマージ済みです。

2. 「一次情報を必ず1つ入れる」という規則が、経験を発明させた

本人の指摘で、公開済みの記事に著者が経験していないことが一人称で書かれていると判明しました。 委員会の記録係、看護研究係、電子カルテ導入の立ち会い — どれも実在しません。

原因はこちらが課した規則でした。「全記事に一次情報を1つ入れる」という規則です。 参照できる事実の一覧はどこにも無く、義務だけがありました。 満たせない要求を課せば、AIは埋めてしまいます。 嘘をつく傾向というより、要求の副産物です。

直したのは規則の側です。人間だけが編集する事実台帳（content/AUTHOR_EXPERIENCE.md）を新設し、 そこに無い経験は書けないことにしました。同時に一次情報を義務から外しました。 台帳には「前職がICUの看護師だった」から「委員会の記録係をしていた」は導けない、と例示してあります。 公開済みの29本を全数監査し、20本を一般的な記述へ書き直しました （PR #50）。

3. 計測の道具が、警告なしに誤った値を返していた

このシステム自身の構築記を1本公開しました。その原稿に「コミット52」と書いていました。真の値は60でした。 公開前のレビューで指摘されて直したので、読者に届いた記事は60になっています。

クラウドのセッションはリポジトリを浅く（shallow）クローンします。git rev-list --count は 打ち切られた範囲だけを数え、警告も異常終了もなく小さい値を返します。さらに悪いことに、 検証したレビュアーも同じ罠にかかっていた（別の基点で50、真の値は59）。 基点が違えば正しい値も違うので、二人の値を突き合わせても一致は確認できません。

学びは一点に尽きます。断面を固定することと、計測が健全であることは別問題です （PR #59 / Issue #58）。 なお上の「35本」は、この件を受けて tree ベースで数え直した値だ（.gitkeep を含めると36と出ます）。

4. 検査そのものが誤検知し、直しても効かなかった

履歴を追記専用に保つ検査（docs-lint）が、比較の基点を取り違えて無関係な PR を落としていました。 merge-base で計算するよう修正した（PR #54）。

ところが、修正をマージしても既存の PR は赤いままでした。GitHub の「re-run」は当時の ワークフロー定義をそのまま再実行するため、直した設定が読まれません。ブランチを更新して初めて 新しい定義が使われる（PR #56）。 赤い結果を見て修正を疑う前に、どちらを実行したかを確かめます。

今日の数字（2026-08-09 21時計測）

main のコミットは63、うち直近24時間で27。公開対象の記事は35本、未処理の Issue は30件。

このメディアは、編集方針を人間が決め、執筆と検証をAIの編集チームが担う体制で動いています。 今日直した4件は、どれも「作る側」ではなく「確かめる側」の故障でした。 量を増やす前に、確かめる仕組みが本当に確かめているかを見る日が要ります。

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