AIに「本当に合っていますか」と聞くと回答が変わる――コードレビューで同調を防ぐ検証方法
AIにコードレビューを依頼したあと、結果に疑問を感じて次のように聞き返したことはないでしょうか。
本当に合っていますか？
私が十数回試した範囲では、AIはこのような問い返しに対して、ほぼ確実に最初の回答を変更しました。
もちろん、最初の誤りを正しく訂正した場合もあります。しかし、最初の回答が正しかったにもかかわらず、質問者の疑いへ同調して、誤った方向へ結論を変えた場合もありました。
重要なのは、次の違いです。
回答が変わったことと、回答が正しくなったことは別です。
この記事では、AIによるコードレビューで質問者への同調を抑え、仕様・コード・データ・テスト結果を基準に判定させる方法を整理します。
「本当に合っていますか」は検証にならない
例えば、AIが次のように回答したとします。
この処理には不具合があります。条件分岐を変更してください。
そこで利用者が「本当に不具合ですか。現在の処理が正しいのではありませんか」と聞き返します。
AIが次のように回答を変えても、検証が完了したとはいえません。
おっしゃる通りです。現在の処理が正しく、先ほどの回答は誤りでした。
新しい説明にも筋が通っているように見えるため、訂正されたと感じます。しかし、実際には次の確認が抜けています。
- 最初の回答は、どの仕様を根拠にしたのか
- 反対意見は、どのコードやデータを根拠にしたのか
- 両方を同じ条件で比較したのか
- 判断に必要な情報は本当にそろっているのか
- 変更によって既存機能へ何が影響するのか
質問者の言い方に合わせて結論だけが変わったのであれば、会話は成立していても、コードレビューとしては成立していません。
コードを書けることと、仕様を守り続けることは別
私はAIを使ってアプリを開発しています。コードの作成だけでなく、コードレビューやテストコードの作成にもAIを使用しています。
開発中に「ここはおかしいのでは」と指摘すると、AIは問題を認めて修正案を出します。指摘が正しければ修正すべきです。
しかし、利用者の疑問が思い込みだった場合でも、AIがそれに同調して、正常に動いていた処理を変更することがあります。
その結果、次のような修正ループが起こります。
- AIがコードを作成する
- 利用者が疑問を示す
- AIが疑問へ同調してコードを変更する
- 別の機能が壊れる
- 壊れた箇所をAIが再修正する
- さらに別の箇所へ影響が出る
AIがコードを書けることと、既存仕様を守りながら安全に変更し続けられることは同じではありません。
コード生成の速さだけを見て変更を重ねると、最初は正常だった機能まで修正対象になります。
先に固定すべき判定基準
AIへ再確認する前に、何をもって正しいと判断するのかを固定します。
アプリ開発では、少なくとも次の情報が必要です。
| 判定対象 | 確認するもの |
|---|---|
| 期待する動作 | 仕様書、画面要件、業務ルール |
| 現在の動作 | 対象コード、実行結果、画面操作 |
| 入出力 | リクエスト、レスポンス、DBデータ |
| 発生原因 | ログ、例外、条件分岐、呼び出し元 |
| 変更範囲 | 修正対象ファイル、関数、SQL、画面 |
| 既存機能への影響 | 関連処理、回帰テスト、変更前の正常結果 |
| 合格条件 | 期待値が明記されたテスト結果 |
判定基準がなければ、AIは会話の流れに合わせて、もっともらしい回答を作り直し続けます。
反対意見を出すときの検証プロンプト
単に「違うのでは」と聞く代わりに、最初の回答を維持する可能性も含めて比較させます。
私の反対意見へ同調しないでください。
最初の回答と私の反対意見を、同じ判定基準で比較してください。
次の順番で確認してください。
1. 最初の回答の結論と根拠
2. 私の反対意見の結論と根拠
3. 根拠となる仕様、コード、データ、ログ、テスト結果
4. 両者が矛盾する箇所
5. どちらが正しいかの判定
6. 判定に必要な材料が不足している場合は、その不足内容
質問者の言い方や期待ではなく、確認できた証拠だけで判定してください。
判断できない場合は、推測で補わず「判断不能」と回答してください。
この指示でも、AIが必ず正しくなるわけではありません。ただし「利用者が反対したから回答を変える」という流れは抑えやすくなります。
修正前にAIへ出させる内容
コードの変更を依頼する場合は、いきなり修正させず、先に次の内容を出させます。
まだコードを変更しないでください。
変更前に次の項目を提示してください。
- 問題が発生している正確な位置
- 現在の処理が行っていること
- 仕様上の期待動作
- 現在の処理と仕様が異なる根拠
- 修正が必要な最小範囲
- 変更によって影響を受ける可能性がある処理
- 修正しないという選択肢が成立するか
- 判断材料が不足している項目
ここで根拠が示せなければ、修正へ進むべきではありません。
「判断不能」で止めることも必要
AIは、材料が不足していても何かを答えようとします。
そのため、次の回答を明示的に許可する必要があります。
- 該当なし
- 判断不能
- 確認材料不足
- 再現できない
- 仕様が不明確
情報が不足している場面では、もっともらしい推測よりも、判断できないまま止まる方が安全です。
特に、次の状態でコードを変更すると危険です。
- 対象の仕様書を確認していない
- 関連コードを読み切っていない
- エラーを再現できていない
- DBの実データを確認していない
- 変更前に成功していたテストを把握していない
- 変更後の終了状態を決めていない
AIの回答を人間が検証できることが前提
判定基準を決めても、それだけでは十分ではありません。
その基準を使って、コードや仕様を読める人間が最終的に判断できることが前提です。
AIが判定基準を作り、AIがコードを書き、AIがテストを作り、AIが合格を判定するだけでは、誤りを同じAIの説明で正当化する閉じた構造になります。
少なくとも人間側で、次を確認できる必要があります。
- AIが示したコード位置は正しいか
- 引用した仕様は実在するか
- テストの期待値は仕様と一致しているか
- テストが本当に対象処理を通っているか
- 修正前に正常だった機能が維持されているか
- AIが確認していない範囲を確認済みのように扱っていないか
コードを読めなければ、AIが出した基準もAIが出した答えも検証できません。
実際に運用する手順
AIコードレビューでは、次の順序にすると修正ループを抑えやすくなります。
- 不具合または疑問を再現する
- 仕様と期待結果を明示する
- AIへ対象コードと根拠を示させる
- 最初の回答と反対意見を同じ基準で比較させる
- 材料不足なら変更せずに止める
- 修正範囲と影響範囲を確定する
- 対象を最小範囲で修正する
- 対象テストを1件だけ実行する
- 成功後に関連する回帰テストを実行する
- 変更前に正常だった機能が維持されていることを確認する
重要なのは、AIへ何度も問い返すことではありません。
回答を採用する条件と、変更を止める条件を先に決めることです。
まとめ
AIへ「本当に合っていますか」と聞き返し、回答が変わっても、それは正しく訂正された証拠にはなりません。
AIコードレビューでは、次の点が重要です。
- 最初の回答と反対意見を同じ基準で比較する
- 仕様・コード・データ・ログ・テスト結果を根拠にする
- 判断材料が足りなければ「判断不能」で止める
- 修正前に変更範囲と影響範囲を確定する
- AIが作った判定基準とテストを人間が検証する
AIに必要なのは、自信のある言い方ではありません。
確認できた根拠と、確認できなかった範囲を分けて出すことです。
そして人間に必要なのは、「本当に合っていますか」と問い続けることではありません。
何をもって正しいと判断するのかを、先に決めておくことです。!