AIのレビュー指摘を上流から直す。要件・テスト・PRを1本で追跡する方法

AIのコードレビューで「権限確認が足りない」「この条件では別の値になる」と指摘されたとき、該当行だけを直して終わらせていないでしょうか。コードは直っても、要件定義や仕様書が古いままなら、次の改修で同じ不整合が戻ります。テストがなければ、指摘を本当に解消したかも後から確かめられません。

弊社では、AIのレビュー指摘を既存PRで受け、要件・仕様・テスト・実装・証跡・返信まで同じIDで追う仕組みを設計しました。大切なのは、AIに修正を任せ切ることではありません。どの根拠から何を変え、誰が確かめたかを1本の線にすることです。

AIコードレビューの指摘は、なぜコードだけ直してはいけないのか

AIコードレビューとは、変更差分やリポジトリの情報をAIが調べ、問題点や修正案を示す仕組みです。見落としを減らす助けにはなりますが、指摘そのものを正解として扱うことはできません。

AIの指摘にも見落としと誤りがある

GitHubはCopilot code reviewについて、PRの問題を見つけて修正案を提示する機能だと説明しています。一方で、すべての問題を見つける保証はなく、誤る場合もあるため、指摘を慎重に検証し、人のレビューで補うよう明記しています。これは2026年7月30日にGitHub公式ドキュメント「Validating Copilot code reviews」で確認した内容です。

AIが「ここを直すべき」と提案しても、その前提になった業務ルールが正しいとは限りません。レビュー対象のコードには現れない契約条件や運用上の例外を、AIが参照できていない可能性もあります。まず指摘を事実、解釈、提案に分け、根拠を確かめる必要があります。

コードだけ直すと上流文書が古いまま残る

たとえば、承認条件が「10万円以上」から「20万円以上」へ変わったとします。実装だけを20万円へ直し、要件定義と仕様書に10万円が残れば、どれを正とするか分かりません。後日の担当者や別のAIは、古い文書に合わせてコードを戻すかもしれません。

レビュー指摘が要件の不足を示しているなら、修正の出発点はコードではなく要件です。仕様の表現が曖昧なら、仕様を先に確定します。コード修正は、上流で決めた内容を反映する工程として扱います。

テストと返信がなければ「直した」を説明できない

差分が小さくても、変更前に問題が再現し、変更後に解消した証拠がなければ、修正の妥当性は確認できません。また、PRのスレッドに根拠を残さず解決済みにすると、レビュアーは何を確認して閉じたのか追えません。

必要なのは、指摘、判断根拠、再現テスト、実装差分、検証結果、PR返信の対応関係です。この関係を後からたどれる状態を「レビュー修正のトレーサビリティ」と呼びます。

レビュー修正のトレーサビリティはどう作るのか

レビュー修正のトレーサビリティとは、1件の指摘に識別子を付け、上流文書からPRでの解決までを対応づけることです。高価な専用製品から始める必要はなく、小さな台帳でも構築できます。

指摘ごとにRF-IDを付ける

弊社の実装では、各指摘を RF-001 のようなIDへ正規化します。対象は未解決のレビュースレッド、インラインコメント、変更要求、失敗したチェックです。同じ問題が複数のコメントに分かれている場合は、根拠を確認して1件にまとめます。

IDを付ける目的は、管理番号を増やすことではありません。「このテストはどの指摘を再現するのか」「この差分は何を解消するのか」を短く示すためです。コミット数やコメント数を成果にせず、指摘が検証可能な単位になっているかを重視します。

指摘の入口を既存のOPEN PRに絞る

同じ修正依頼がチャット、課題管理、口頭、PRへ散らばると、どこまで対応したか分からなくなります。弊社の設計では、レビュー指摘の受付を既存のOPEN PRに限定しました。課題管理のコメントは要件確認、本文は確定した要件と対応結果の記録に使い分けます。

この区分は、チャットや課題管理を使わないという意味ではありません。レビューとして処理する内容をPRへ集め、要件の質問と確定事項を別の場所で混ぜないための境界です。新しいPRへ作り直さず、指摘が出たPRをそのまま修正します。

「変更しない」という判断にも根拠を残す

すべての指摘が要件変更につながるわけではありません。既存要件で十分な場合や、AIの指摘が誤っている場合もあります。そのときは空欄にせず、「どの根拠を確認し、なぜ変更不要と判断したか」を台帳へ残します。

変更箇所だけを追う台帳では、何も変えなかった工程が未確認なのか、確認済みなのか区別できません。変更不要の理由まで記録すると、人のレビュアーが判断過程を再確認できます。

AIにレビュー指摘を直させる手順はどう組むのか

安全に進める順番は、指摘の収集からコードへ直行するのではなく、要件、仕様、テストを経て実装へ降りる形です。修正後は同じ経路を逆向きに確認し、PRへ結果を戻します。

先に対象と指摘を固定する

最初に既存PR、対象ブランチ、ベースブランチ、関連する課題を再取得します。古い画面や手元の記憶を使わず、現在の未解決スレッドと失敗チェックを集めます。その後、各指摘へRF-IDを割り当て、重複と依存関係を整理します。

この段階で、対象PRを一意に決められない、要件の解釈が複数ある、依存先の変更が未反映といった問題が見つかれば停止します。AIに推測させて先へ進めると、速く間違った場所へ到着するだけです。

要件、仕様、テスト、実装の順に更新する

1件の指摘は、次の順序で処理します。

指摘の事実と根拠を確認する
必要なら課題管理上の要件・受入条件を更新する
リポジトリ内の要件定義を合わせる
仕様書・設計書を要件に合わせる
現象を再現するテストと回帰テストを追加する
可能なら修正前の失敗を確認する
最小差分で実装する
テスト、型検査、ビルドなどを再実行する

先にテストを置くのは、AIが提案した実装を正当化するためではありません。指摘が何を問題としており、どの状態なら解消と判定するかを固定するためです。修正前に再現できない場合は、再現できない理由と代替の確認方法を残します。

最後に証跡とPRの状態を同期する

実装後は、RF-IDごとに変更ファイル、テストケース、実行コマンド、結果の要点を記録します。画面変更なら同じ条件の変更前後を対で残し、画面変更でなければ画像が不要な理由を書きます。

そのうえでコードとセキュリティの再レビューを行い、対応必須の指摘が残っていないことを確認します。PRのスレッドには判断根拠と検証結果を返信し、人が内容を確認してから解決します。台帳だけ、PRだけが更新された状態を完成とは扱いません。

最小の追跡台帳には何を記録すればよいか

追跡台帳は、情報を集める倉庫ではなく、工程間の矛盾を見つけるためのチェックポイントです。最小構成でも、指摘から解決までの各欄をRF-IDに結びます。

8つの欄を同じIDで結ぶ

欄	記録する内容
指摘	PR上のコメント、スレッド、失敗チェックへの参照
要件	根拠、変更箇所、または変更不要の理由
仕様	要件と一致する変更箇所、または変更不要の理由
実装	変更ファイルと、その差分が必要な理由
テスト	対応するテストケース、修正前後の結果
証跡	画面の変更前後、または証跡不要の理由
再確認	実行コマンド、合否、ログの要点
解決	PRへの返信とスレッドの状態

形式はJSONでも表でも構いません。ただし、自由記述だけにすると未入力を機械的に検出しにくくなります。必須欄と状態を決め、未確認、確認中、合格、差し戻しを区別できる形が扱いやすいです。

GREENだけでなくREDの意味を記録する

テストが通ったという結果だけでは、そのテストが指摘を捉えているか分かりません。可能な場合は修正前に失敗することを確認し、失敗理由が指摘と一致するかを見ます。修正後は同じテストが通り、関連する回帰テストも壊れていないことを確かめます。

既存不具合を環境上再現できないこともあります。その場合に無理にREDを作ると、実装に合わせた見せかけのテストになりかねません。再現不能の事実、試した条件、代替確認を残し、人の判断へ戻します。

台帳を成果物と取り違えない

RF-IDや記録項目が増えても、品質が自動的に上がるわけではありません。台帳の役割は、未確認の工程や文書間の矛盾を見えるようにすることです。小さな修正へ過剰な記録を求めれば、更新されない台帳が新しい負債になります。

業務影響、変更範囲、事故時の損失に応じて、必要な証跡の深さを変えます。ただし、根拠、判定方法、人の確認という3点は省かない方が安全です。

AIレビュー修正を自動化するとき、どこで人が止めるべきか

AIへ任せやすいのは、情報の収集、ID付与、文書間の差分抽出、テスト実行、結果の整理です。要件の最終決定、例外の承認、誤検知の判定、スレッドの解決は、人が責任を持つ境界として残します。

曖昧さと矛盾が見つかったら停止する

要件と仕様が矛盾する、PRの対象が不明、テスト環境が本番条件を再現できないといった状況では、AIが自然に見える方を選んではいけません。質問を作り、根拠と選択肢を示して作業を止めます。

停止は自動化の失敗ではありません。間違った修正を静かに完了させないための機能です。1チケットを自律で処理するループの実装記録でも、速く進むことより止まるべき場所を決める重要性を紹介しています。

AIの自己レビューだけで解決済みにしない

実装したAIが自分の差分を確認するだけでは、同じ前提の見落としが残ります。別の観点によるコード・セキュリティレビューと、人による業務要件の確認を組み合わせます。GitHub公式も、人のレビューでAIのフィードバックを補うよう案内しています。

役割分離を詳しく知りたい場合は、Claude Codeで11人編成のマルチエージェント開発チームを構築した記録も参考になります。人数を増やすこと自体ではなく、実施者とレビュアーの責務を分ける考え方が今回の設計にもつながっています。

実装済みと実運用済みを分けて伝える

今回参照した弊社の実装記録は、スキル形式の検証、implement関連16件、scheduled runnerの既存回帰20件、一時環境でのinstaller検証に合格しています。いずれも2026年7月28日時点の記録です。ただし、当時のCodex実行環境は書き込み制約があり、実runtimeへの新規シンボリックリンク作成は完了していませんでした。

この結果から言えるのは、Git管理元の実装とテストが完了したことまでです。実runtimeへ反映され、さまざまな実PRで運用成果が出たとは言えません。自動化の記事では、検証できた範囲と未検証の範囲を分けることもトレーサビリティの一部です。

まとめ：修正速度より、判断をたどれることを優先する

AIのレビュー指摘は、該当行だけを直す作業ではありません。指摘が要件や仕様の不足を示すなら、上流から順に整え、テストで判定条件を固定し、PRへ根拠を戻す必要があります。

まず1件をRF-IDで追ってみる

最初から全PRへ大きな仕組みを導入する必要はありません。影響の大きい指摘を1件選び、指摘、要件、仕様、テスト、実装、証跡、再確認、解決を同じIDで結んでみてください。途中で空欄になる場所が、現在の開発工程で情報が切れている場所です。

自動化の完成条件を人の確認まで含める

AIがコードを生成し、テストが通っただけでは、レビュー修正は終わりません。根拠が最新の文書へ反映され、人が判断を確認し、PRの指摘へ説明が戻って初めて、次の担当者がたどれる状態になります。

自社の開発フローへ合わせたAIレビュー運用や、既存システムの改修工程を整理したい場合は、現在の文書・テスト・PRのつながりから確認します。自動化する範囲と、人が判断する境界を小さく設計するところからご相談いただけます。

AIを使った開発・レビュー運用のご相談

要件・仕様・テスト・PRの現状を確認し、安全に自動化できる範囲と人が判断する境界を整理します。

/contact/