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

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

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

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

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

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

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

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

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

直したのは規則の側だ。人間だけが編集する事実台帳（content/AUTHOR_EXPERIENCE.md）を新設し、 そこに無い経験は書けないことにした。同時に一次情報を義務から外した （03ba26e）。 台帳には「前職が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に任せる難所は、書かせることではなく、 出力が本当に届いたか・本当に事実かを機械で確かめ続けることでした。 この構成の設計と導入のご相談を承っています。