AIレビューだけでは足りない理由｜仕様・テスト・期待動作をquality gateにする

AIレビューだけではなぜ足りないのか

AIが生成したコードをAIにレビューさせると、どちらも同じ曖昧な仕様から推測してしまうことがあります。仕様がなければ、レビューはコードがコード自身に合っているかを見るだけになりがちです。

例：seoTitleが空だと記事タイトルが消える

これは架空のサンプルで受け入れ条件を組み立てる例です。article.titleが「記事A」、seoTitleが空白、descriptionが「説明A」、pathが「/articles/sample/」のとき、空白のseoTitleを採用せずtitleを使い、descriptionとcanonicalも入力どおりに出す要件を先に書きます。canonicalのoriginは例示用の https://example.com とし、URL末尾にはslashを一つ付ける方針にします。

`getMetadata(input)`の結果を同じ関数から作った期待値と比較する、修正後にsnapshotを更新してテストを通す、といった方法では自己充足になり得ます。期待値は「記事A」のように仕様から独立して固定し、生成されたHTMLと実際の表示を別に確認します。変更前の出力を残し、同じ入力で修正前の失敗と修正後の通過を比べてください。

要件を通してから、差分と表示を確認する

• ビルド：既存のビルドを実行し、生成物を更新できたか記録する。
• 要件確認：事前に書いた入力・期待値・境界条件を確認し、それぞれの証拠を残す。
• 独立した差分・表示確認：生成HTML、実際の表示、変更範囲、既存ページへの副作用を人が確認する。AIの説明だけで表示確認を済ませない。
• AIレビュー：最後に、要件確認で判定できない設計、保守性、アクセシビリティ、性能の懸念を尋ね、指摘ごとに根拠を確認する。AIレビューは失敗した要件確認を合格に変えない。

## 受け入れ確認カード

- 変更・issue: [ ]
- 変更前のcommitと確認した挙動: [ ]
- 入力: [ ]
- 期待する結果: [ ]
- 境界条件: [ ]
- 禁止する副作用: [ ]
- ビルドの実行内容と結果: [PASS / FAIL / BLOCKED / NOT RUN + 証拠]
- 要件確認と期待値: [ ]
- 変更前に失敗した証拠: [ファイル / 出力 / 画面記録]
- 同じ入力で変更後に通った証拠: [ ]
- 独立した差分確認と目視結果: [ ]
- 残る設計上の疑問に対するAIレビュー: [ ]
- 全体の状態: [PASS / FAIL / BLOCKED / NOT RUN]
- 未確認の項目と担当者: [ ]