公開後に見つかった穴が3つ。1つは自分で入れた自動チェックが止め、2つはAIが見つけました

転職用のポートフォリオとして、個人でWebアプリ「Hubpin」を作っています。
制作の経緯は「Hubpin 開発記録」に時系列でまとめています。
設計と判断は自分で行い、実装も原則自分で書いています。AIには手順書・レビュー・調査を任せています。

公開したあとに、穴が3つ見つかりました。
1つは自分で入れた自動チェックが止め、2つはAIが見つけました。

1番目はAIが直し方を2案出し、直した跡が残る側を自分で選びました。
2・3番目も同じ考えで、その場で直して消える形ではなく、見張りが残る形にしました。

なぜ直すだけでは足りないと思ったか

直すだけだと、同じ場所をもう一度踏んでも誰も気づきません。

3番目が分かりやすいです。
URLの形式チェックを足す作業で、AIが「テストが全部通る」ことに気づきました。
通るのに、本番は壊れます。
テストが渡す値と、アプリが渡す値が違っていました。

ここで形式チェックだけ直すと、テストは緑のままです。
次に自分が同じ場所を触ったとき、また通ってしまいます。
だから、アプリが実際に渡す値を渡すテストを1本足す案を選びました。
本番のフォームで動くことも、自分で確かめました。

1番目: 自分で入れた自動チェックが、初めて止めた

本番前に自動で整形とチェックを走らせる仕組みを、少し前の工程で自分で入れていました。

この日、初めてそれが赤くなりました。
止めたのは、AIが打ったコミットでした。

落ちたのは、検索エンジンが発行したサイト所有権の確認ファイルでした。
差分は、末尾の改行1つです。

直し方は2つありました。

• 整形して通す（1コマンド）
• チェックの対象から外す（設定に1行）

後者にしました。
外部が発行したファイルの形を、こちらが決めてよいものではないからです。
いま整形しても壊れませんが、向こうが形式を変えたとき、自動整形が黙って書き換えます。

ここも、ファイル名では書きませんでした。
所有権の再確認でファイルが名前ごと差し替わることがあるので、その発行元で始まるファイルすべてを対象にしました。

赤いままのコミットも、消さずに残しました。
消すと「自動チェックが仕事をした」証拠まで消えます。
赤から緑へ、と履歴に並んでいるほうが、この仕組みを入れた意味が残ります。

穴を見つけた瞬間が、見張りを置ける唯一のタイミング

いちばん言いたいのはここです。

後から「どこに見張りを置くべきか」を考えるともう分かりませんが、見つけた直後なら失敗の形も通ってしまう理由も全部手元にあります。

そのときに置かないと、置く場所を忘れます。
忘れたころに、同じ場所を踏みます。
だから、見つけた側がAIでも、置くかどうかはその場で自分が決めるようにしています。

これは「テストを書け」という話ではない

2番目は、その検証手順に書いたコメント1行です。
1番目は、設定ファイルの1行です。
テストなのは3番目だけです。

形式は何でもいいと思っています。
「次に踏んだら誰かが気づく」ようになっていれば、それで足ります。