同じバグに5日で3回ハマった。grepの自動チェックが「自分の説明文」を誤検出していた話【個人開発の実装ログ】

3回。

5日間で、同じバグを3回踏んだ。

原因は、自分が書いた「説明のための文章」だった。

うちは毎晩、翌日公開する記事の在庫を自動でチェックしている。仕組みは単純だ。過去30日分のドラフトファイルを全部探し、「公開済み」を示す文字列が本文のどこかにあれば除外する。残ったものだけを「未公開」として扱う。grep -Lという、たった1行のコマンドで動く仕組みだ。

「公開URL」の一文が、自分の首を絞めた

8月2日、8月6日、8月7日。3回とも、このチェックが同じ理由で壊れた。原因は毎回同じだった。ドラフトの末尾に「生成メモ」という説明欄を書いていて、そこに棚卸しコマンドの使い方をそのまま例文として引用していたことだ。その例文の中に「公開URL」という語と本番ドメインの表記が並んでいて、これが除外条件の正規表現に、そのままマッチしてしまった。

grep -Lは「パターンに一致する行が1つでもあれば、そのファイルを除外する」という仕様で動く。本文の中身を判定しているつもりで、実際は「自分がコマンドの使い方を説明した文章」まで判定材料にしていた。未公開の記事が、「公開済みっぽい単語がどこかに書いてある」という、それだけの理由で公開待ちリストから消えていた。

気づかなければ、記事が1本、静かに消えていた

8月6日のケースでは、これは実際に起きかけていた。その日書いた新しいドラフトが、生成メモの中で棚卸しコマンドの例文を引用していたせいで、翌朝のチェックで「公開済み」と誤判定され、公開待ちリストから消えかけていた。目視で全ファイルのヘッダー行を1件ずつ確認していなければ、そのまま気づかれずに終わっていた可能性がある。

エラーは出ない。処理は最後まで正常に終わる。ただ、本来リストに載るはずの1本が、静かに消えているだけだ。一番厄介なタイプの不具合だと思う。

「直せばいい」を3回言って、3回直していない

正直に言う。1回目（8月2日）の時点で、原因はすでに特定できていた。「今後は同じ文字列を説明文にそのまま書かない」という運用ルールで、その場をしのいだ。だが2回目（8月6日）は、別のファイルでまったく同じことが起きた。書く人間が毎回気をつける、という対策は、書く人間が1回でも気を抜けば再発する。当たり前の話だった。3回目（8月7日）で、ようやく根本的な直し方が必要だと認めた。

根本的な直し方は、実は最初から分かっていた。判定対象を「本文全体」ではなく、「ファイル冒頭のステータス行1行だけ」に絞ればいい。「公開ステータス：公開済み」のような、決まった書式の1行だけを見る。生成メモに何を書こうと、判定には一切影響しなくなる。この修正はまだ、手をつけていない。

「本文全体を検索すれば安全」だと思うじゃないですか

今回の教訓は、grepに限った話ではないと思う。ログの中身をキーワードで判定する仕組みは、だいたい同じ穴を抱えている。「探している文字列」と、「たまたま同じ文字列を含んでいるだけの、無関係な説明文」を、機械は区別できない。判定対象は狭いほど安全だ。便利さのために対象を広げるほど、自分が書いた言葉に、自分が足を取られる確率が上がる。

皮肉な話、この記事自体、公開前にもう一度同じチェックを通す。生成メモの中に、今回の不具合を説明する文章として「公開URL」の一語を書いた。またマッチするかもしれない。分かっていて、あえてそのまま書いている。

自動化している人に、今すぐ確認してほしいこと

5日で3回。同じ失敗を数えられるようになったのは、毎回きちんと記録していたからだ。記録がなければ、「またか」で終わっていたと思う。

自分の自動化にも、同じ穴が空いていないか。判定対象は、本当にその範囲まで必要か。広すぎる判定は、便利ではなく、危険だ。一度、見直してみてほしい。