「修正したつもり」を防ぐ、再現シナリオ駆動の修正フロー

なぜ書いたか

バグ修正のあと「動くはずです」とAIが言い切ってきたコードが、ユーザー操作の流れで普通に再現したことがあります。原因は、AIが 修正対象のコードだけ見て、再現シナリオ全体を見ていなかった こと。修正の検証単位を変えました。

やったこと

修正のループを「再現シナリオ単位」に固定しました。

1. 再現手順を固定化する: 「左3桁に 196、右4桁に 0013、そのまま設定ボタン」のように、操作シーケンスを文字に落とす
2. 修正前に再現を確認: 同じ手順でバグが出ることを確認
3. 修正後、同じ手順で再実行: 通ればOK
4. 周辺シナリオも横断確認: 「Tabで次へ」「別欄をクリック」のような近いパターンも一緒に試す

ポイントは4番目です。1つのシナリオで直っても、似たシナリオで再現するケースがあります（Tab/blur依存の罠 で踏みました）。

具体例

郵便番号入力のバグを直したときは、こんな再現テーブルを作りました。

シナリオ	操作	期待	修正前	修正後
1	入力 → Tab → 設定	反映	エラー	OK
2	入力 → 別欄クリック → 設定	反映	エラー	OK
3	入力 → そのまま設定	反映	エラー	OK

最初は3だけ見ていたので、1と2で「Codexの推論では通るはず」と判断して終わらせかけました。実際に手で試したら1も2も再現したので、ちゃんと修正範囲を広げました。

わかったこと

• AIに「修正できました」と言われたら、シナリオを通して自分で確認する までが修正です
• 再現シナリオを文字に落としておくと、修正前後の比較が機械的にできる。AIに「次のシナリオで動作確認して」と渡しやすい
• 周辺シナリオを2〜3個並べるだけで、隠れたバグが拾える率が大きく上がります

再現シナリオを書くコツ

• 操作のシーケンス を時系列で書く。「Tabを押した、そのあと別欄をクリックした、その次に…」
• 入力値も具体に書く。「196 と 0013 を入れた」のように、後から再現できる粒度で
• 期待値も明示。「エラーにならず住所が反映される」のように、判定基準が明確になるように
• 環境 も書く（モード、ロール、データ状態）。同じ操作でもモードが違うと挙動が変わるので

次にやること / 未解決の問題

• 再現シナリオを単体テスト化したいが、Blazorのコンポーネントテストはまだ整備中。最低限E2Eで押さえるラインを決めたい
• 「周辺シナリオ」をAIに列挙させるプロンプトの精度がまだ甘い。明らかに似たパターンを取りこぼすことがある