AIで作った変更をPRへ渡す｜再現手順・差分・確認結果を残す

依頼文を問題の説明へ書き直す

「AIに検索を直してもらった」という説明では、確認者は何を見ればよいか分かりません。どの入力で、どの画面やAPIに、どんな誤った結果が出るかを記載します。期待する動作の根拠も、仕様や既存の利用例と対応させてください。最初の依頼から作業範囲が変わった場合は、古い依頼文を貼るだけで終えず、最終的に直した問題へ説明を更新します。会話の長さより、再現できる条件を優先します。

差分を目的ごとに説明する

変更ファイルを並べるだけでなく、入力判定、表示、保存など、動作上の役割を短く説明します。無関係な整形や依存更新が混ざった場合は、必要性を説明できるかを確認し、独立した作業へ分けられるものは分けます。生成されたファイルも、どの入力から作ったかを記録してください。見た目の差分が小さいから安全と判断せず、共有関数や設定がどの利用箇所へ影響するかを確認します。

同じ条件で修正前後を確かめる

不具合の確認では、修正前に問題が起き、修正後に期待通りになる同じ条件を使います。結果を貼る時は、実行したコマンド、対象環境、確認したコミットを残します。テストを書いたことと、そのテストを実行して通ったことは別です。型検査が成功しただけで、保存や外部接続まで確認したようには記載しません。確認できなかった境界があれば、未確認の理由と次に必要な操作を具体的に残してください。

画面の変更は操作を含めて示す

画面を変えた場合は、初期表示の画像だけでなく、入力、送信、結果、エラーからの復帰など、今回影響する操作を確認します。狭い幅や長い名前が関係する変更なら、その条件も含めます。画像に個人情報や認証情報を残さず、共有可能な見本データを使ってください。確認対象と無関係な画面を大量に貼るより、読者が変更後の動作を判断できる一例と、確認条件の説明を添える方が役立ちます。

AIの説明と実装を照合する

生成された要約は、実際には変更していない処理を直したと説明することがあります。PRを書く前に、差分と確認結果を見て文章を照合します。存在しないテスト名、実行していないコマンド、確認していない性能改善を取り除いてください。依頼時に考えた方針を最終実装へ無理に当てはめず、実装した動作を説明します。判断に迷う箇所は断定を弱めるだけでなく、コードや実行結果へ戻って解消します。

残るリスクと復帰方法を書く

公開設定、データ変更、外部APIに影響する場合は、失敗時に何を戻すかを説明します。以前のコードへ戻すだけではデータ変更が戻らないこともあるため、コードとデータの復帰を区別してください。利用者への影響が限定的な修正でも、まだ確認していない条件は残します。架空の「問題なし」という結論より、今回の範囲と確認の限界が具体的な方が、公開する担当者が適切に判断できます。

会話を読まずに確認できれば引き継げる

最後に、PR本文だけで別の担当者が問題を再現し、変更理由を理解し、確認手順を実行できるかを見ます。架空の検索修正なら、部署あり・なしの見本、期待する件数、使うコマンドを渡す形です。担当者が追加で質問した情報は、次回のために本文や保守資料へ反映します。レビューの承認、マージ、公開はそれぞれ別の操作なので、どこまで終えたかを正確に記載し、確認依頼を公開完了として報告しないでください。

• AIコードレビューの指摘を整理する｜重要度・誤検知・採用理由
• AIでユニットテストを作る｜正解の根拠と境界値を確認する
• AI開発で仕様とコードを揃える｜文書の陳腐化を防ぐ更新手順