自分用のツールで、SQLiteのDB構造を変更するMigrationを作ったときの話。
実装後のテストは111件全部通った。実際に使っているDBにも意図しない変更は入っていなかった。
ここまで確認できたので、かなり安心していた。
ところが、そのあと別AIも入れてレビューしたら、修正した方がいい箇所が3つ出てきた。本番DBへの適用はいったん止めて、その3点だけ直すことになった。
この記事の文章もAIの力を借りています。構成や推敲はChatGPTとClaudeを使っています。本文に出てくるテスト件数、レビュー結果、修正内容は、実際の開発記録を見ながら確認しています。
テストは111件全部通っていた
このとき作っていたのは、SQLiteのschemaを更新するMigrationだった。
DBまわりは失敗すると面倒なので、テストはかなり増やしていた。結果は111/111成功。実際に使っているDBも変わっていないことを確認した。
僕はソフトウェア開発を本職にしているわけではないので、ここまで通れば一人でコードを眺め続けるより、別のAIにも見せた方がいいと思った。
そこで、実装を進めていたChatGPTとは別にGeminiにもレビューを頼んだ。
Geminiの返事はかなり速かった。
速さにはちょっと驚いたけど、見るべきなのは中身。返ってきた指摘をChatGPT側へ戻して、1件ずつ確認した。
その結果、本番DBへ進める前に3点を直すことになった。
出てきたのはHigh 2件、Medium 1件
後続レビューで修正対象になったのは次の3点だった。
- fresh bootstrapの整合
- revision snapshotのCHECK
- WALを使っているDBのbackup安全性
判定はHighが2件、Mediumが1件。
111件テストが通ったあとだったので、これは結構印象に残った。
111件のテストで既存の挙動を壊していないことはかなり確認できた。でも、設計上の前提やバックアップ時の扱いまで全部見終わった、ということではなかった。
3件とも、元のコードと前提をもう一度確認してから修正対象にした。指摘が出たから直す、ではなく、どこまで直すかを絞ってから手を入れた。
レビュー結果も、もう一度レビューする
この件以降、AIにコードレビューを頼むときは、あとから検証しやすい形で返してもらうようにしている。
たとえばこんな感じ。
この変更をコードレビューしてください。
各指摘について、次を分けて書いてください。
- 重大度
- 問題があると判断した根拠
- 該当箇所
- 実際に起きる不具合
- 修正案
- 読み違いの可能性がある前提
推測だけの指摘は、その旨も書いてください。
返ってきたレビューも、別のAIへそのまま渡して再確認する。
このレビュー結果を再確認してください。
各指摘を、採用 / 要確認 / 不採用 に分けてください。
コード上の根拠が弱いものは、
そう判断した理由も書いてください。
AIが2つとも同じことを言っても、それだけで安心はできない。両方とも同じ前提を勘違いしていることはあり得るし、片方だけの指摘が正しいこともある。
最後はテスト結果や実際の挙動を見て決める。
今はChatGPTとClaudeを中心に使っている
このときはChatGPTとGeminiの組み合わせだった。
今はChatGPTとClaudeを中心に使っていて、Geminiは画像や高速レビューなど、合う場面で使っている。
レビュー役は用途で変えている。
結局やっていることは地味で、実装したAIとは別のAIにも見せる。そこで出た指摘をもう一回疑って、最後はテストで確認する。
特にMigrationやbackupのように、失敗したときにデータへ影響する処理では、AIからOKが出ただけでは進めないようにしている。
111件のテストが通ったあとに止めたことが一度あるので、ここだけは今も気をつけている。