AIへコードレビューを頼むときは、コードだけでなく、期待する動作と変更の範囲を渡します。何を守る修正かが分からないと、見た目の整理ばかり進み、入力条件や既存の仕様が変わってしまうことがあります。
まず人が説明できる仕様を用意し、その仕様に対してAIが指摘する問題を、一つずつ確かめます。指摘がもっともらしいことと、修正が必要なことは別です。
レビュー対象と守る動作を示す
以下は説明用のPython関数です。数量に単価を掛けますが、入力条件を検査していません。
def total_price(quantity, unit_price):
return quantity * unit_price
この関数だけを渡しても、小数や負数を認める業務なのかは判断できません。「数量と単価は0以上の整数」「真偽値は受け付けない」「税計算は別の処理」という条件を加えると、確認すべき箇所が明確になります。
次の関数をレビューしてください。
期待する動作:
- 数量と単価は0以上の整数。
- True / False、文字列、小数、負数はエラーにする。
- 税や割引の計算は追加しない。
依頼する内容:
1. 仕様と違う可能性がある箇所
2. 問題が起きる具体的な入力
3. 指摘を確かめるテスト
4. 最小限の修正案
制約:
実行していないテストを「成功」と書かない。
仕様が足りない点は推測せず質問として分ける。
対象コード:
{変更した関数と必要な呼び出し元}
OpenAIのプロンプト設計資料にある、条件、文脈、期待する出力を分ける考え方を使っています。秘密情報や業務データを除き、必要な範囲だけを渡します。
指摘ごとに再現例を確認する
たとえばTrueはPythonでは整数の性質を持つため、単純な整数判定の方法によっては受け入れてしまいます。仕様が真偽値を認めないなら、その入力をテストへ含めます。これはこの関数の条件に対する判断であり、すべての業務で真偽値を拒否すべきという意味ではありません。
修正案の一例は次の形です。AIが生成して実行した結果ではなく、上の仕様に合わせた説明用コードです。
def total_price(quantity, unit_price):
values = (quantity, unit_price)
if any(type(value) is not int or value < 0 for value in values):
raise ValueError("数量と単価は0以上の整数で指定してください")
return quantity * unit_price
通常の入力だけでなく、0、負数、文字列、小数、真偽値を確かめます。外部への書込や送信があるコードは、実サービスへ接続せずに検証できる部分から試し、必要な権限と試験環境を別に用意します。
修正する前に差分を読む
AIの修正案をまとめて取り込まず、変更した条件、戻り値、例外、外部への作用を確認します。関係のない関数名や構造まで変わっていたら、レビューしやすい単位へ戻します。
ライブラリの使い方を変える指摘は、利用中の版の公式資料で確認します。存在しないAPI、古い引数、現在の環境で使えない構文が混ざる可能性を考え、説明文だけで採用を決めません。
指摘と検証結果を分けて残す
記録には、対象の版、指摘、再現入力、期待する結果、実行した試験、採否と理由を残します。「AIが問題ないと言った」は、テスト結果の代わりになりません。
OpenAIの評価の指針も、目的と評価データを決めて確認することを重視しています。コードレビューでも、実際に守りたい動作を基準にします。
Pythonの実行環境はPythonの始め方、処理を小さく分ける考え方はGASのコードを分割する方法も参考になります。
