再発防止の1行が、同じ穴を掘っていた——数え方を書き写した日

歯止めとして足した1行が、次の事故の材料になることがある。
2026年8月9日、うちのサイトの台帳でそれが起きた。本番に出る前に見つけて直した。

何が起きたか

自社サイトには、実際に作ったものを並べたカードの列がある。その手前の見出しに、並んでいる数を書いていた。ところが見出しの数と、実際に並んでいるカードの枚数が合っていなかった。製品が増えたり、別のセクションへ移したりするたびに、見出しの数字だけが取り残されていたからだ。

同じ型の穴は以前にもあった。台帳に載っていた別の数字を裏付けようとしたとき、その根拠がどこにも見つからなかった。誰かが一度書いた数字が、出典を失ったまま生き延びていた。

そこで再発防止として、数ではなく数え方を登録することにした。台帳とソースコードの注釈に、正しい数え方として「この文字列を検索して数えろ」という1行を書いた。数が動いても、数え方さえ正しければ誰でも正しい数を出せる——そういう設計のつもりだった。

ところが、その注釈行そのものが、検索の対象となる文字列を含んでいた。 指示どおりに実行すると、注釈自身が1件として数えられ、実際より多い数が返る。書いてある手順どおりにやると、間違った答えが出る状態になっていた。

将来これを回した人は、返ってきた数を正としてカウンタを書き換える。つまり、最初に直したはずの食い違いを、歯止めのほうから掘り直すことになっていた。

工程分解表——「数字の裏付け」を分解する

機械にできるのは、決めた通りに数えることと、台帳と本文を突き合わせることだけだ。何を数えるかを決める工程は、いまも人間の側にある。

難しい側——自己参照は、書いた本人にいちばん見えない

この手のずれは、書いた本人には見えない。本人の頭の中では、注釈は「説明」であって「対象」ではないからだ。だが検索する側にその区別はない。ファイルの中に同じ文字列があれば、それが説明文の一部でも等しく1件として数える。

一般論として、検査の定義を検査対象と同じ場所に書くと、この自己参照はいつでも起こる。避ける方法は、数える目印に本文へは絶対に現れない形を選ぶことだ。今回は、カードの開きタグにしか出てこない属性名へ差し替えた。説明文の中に自然に紛れ込む余地がない文字列なら、注釈が増えても数は動かない。

もうひとつ、この日には別の教訓が出た。「1行だけの修正だから安全」ではなかった、という話だ。同じ直し方を別のファイルにも当てようとして、いったん実行し、そして戻している。理由は、そのファイルを未コミットのまま置くと、翌朝の無人ブログ工場が止まるからだ。ブログ工場は起動時にまず作業場が清潔かどうかを確かめ、身に覚えのない変更が残っていれば何もせず報告して終了する。前回の実行が公開途中で落ちた可能性を潰すための安全装置で、それ自体は正しく働いている。だが結果として、置いていった1行が翌朝の公開を止める。無人ルーチンが同じ作業場を共有している以上、コミットまで完了できない変更を置いていってはいけない。

自社の実例

うちのブログは2026年7月23日から、AI社員が書いた記事を機械検品にかけ、通過したものだけを無人で公開している。検品が見るのは、禁止表現と、台帳に無い数字と、規格崩れの3つだ。この記事もその検品を通っている。

裏を返せば、台帳が間違っていれば、検品は間違いをそのまま通す。だから今回のように「数え方の定義」が壊れていた場合、機械側では止まらない。止まるのは、実物を見に行った人間のところだけだ。失敗はぜんぶ、AIの能力ではなく、人間の設計の穴だった。

直したこと

数える目印を、説明文には現れない形に差し替えた。そして定義は1か所にだけ置き、他所へ書き写さないことにした。書き写した瞬間に、写した先が新しい対象として数に入るからだ。

導入までの手順

1. 公開している数字を1つ選び、その数の出し方を1行で書く（どこを、何で数えるか）
2. その1行を実際に実行し、返ってきた数が実物と一致するかを確かめる（書いた直後に必ず回す）
3. 同じ定義が2か所以上に書かれていないか探し、1か所に寄せる

この線は、会社ごとに引き直せる。どの数字を機械に数えさせ、どの定義を人間が持つのか——その線引きは実装設計図で一緒に引けるし、まず話だけ聞きたいなら無料相談から始められる。