AIコード生成に5段階レビュー 設計書起点の仕組みをai-codingで公開

この仕組みの出発点は、AIが「実装しました」「テストが通りました」と報告しても、実際には関数が無い、テストが何も確かめていない、という事態が起きることにある。そこで要件・実装・テストの対応表を使い、implementedはimplementsのファイルと関数が実在すること、provenはproofsのテストが実在しアサーションがあることを条件にしている。状態を上げても条件を満たしていなければ、CIのspec-trace checkが失敗する。

設計書のハッシュ（source_sha256）を記録し、設計書があとから書き換わるとハッシュが合わなくなり検知される。差分を見て影響する要件をpendingに戻す運用だ。品質ゲートはD1〜D11の決定論的なチェックをマージ前に全部通すことを必須とし、N1〜N6のAIレビューは補助に留める。チェックのこじ開けを防ぐため、テストの期待値を実装に合わせる書き換えやアサーションの削除、@Disabledでの無効化などを禁止し、指示とCIの両方に入れている。

この仕組みが機能するかは、設計書にパラメータファイル名やメッセージID、テーブル名といったAIが必要とする情報を書き込めるかにかかっているとみられる。ルールの正をguidelines/の1か所に集約し、エージェントには「ここに書いていないルールを作らない。迷ったら推測せず確認事項として人に返す」と指示している点が、属人的な運用を避ける鍵になる。