GitHub PRレビューコメントの見方
レビューコメントは、全てを同じ扱いにせず、修正するもの、質問するもの、今回は保留するものに分けると進めやすくなります。
このページでわかること
- コメントの対象行と意図を読む
- 修正、質問、保留を分ける
- resolvedにする前に差分と動作を確認する
まず確認すること
- requested changesの範囲を確認する
- Codexへ渡す時は対象コメントを明確にする
- 返信文には対応内容と残した理由を書く
やってはいけないこと
- 指摘を見落としたままcloseする
- 無関係な大改造で返す
- 確認せずにresolved扱いにする
安全寄りに進める手順
- 対象のrepo、branch、PR、Actions runを確認する。
- Secrets、APIキー、token、.env、個人情報が差分やログに出ていないか見る。
- 必要な場合は値を停止または再発行し、影響範囲を整理する。
- 変更は小さなbranchとPRに分け、CIとreviewで確認する。
CodexやAI作業時の注意
AIに作業を渡す時は、対象ファイル、触らないファイル、確認項目を明記します。認証情報や実際のキー値は本文、Issue、PR説明、ログ、レポートに残さないようにします。
公式情報で確認する領域
Actions、Secrets、PR、repository visibility、workflow permissionsは仕様が変わることがあります。実作業前にはGitHub Docsで最新の説明を確認してください。
レビューコメントは「会話つきの差分確認」
PRのレビューコメントは、差分の特定の行に対して「ここはなぜこう変えたの？」「ここは戻してほしい」と、位置を指定して会話できる仕組みです。メールやチャットで「あのファイルのあの辺り」と説明する曖昧さがなくなり、指摘と修正の記録がPRに残るため、後から経緯を辿れます。1人運用でも、自分への申し送り（「ここは次回リファクタリング」等）を残す使い方ができます。
コメントの種類と対応の仕方
| 種類 | 意味 | 受けた時の対応 |
|---|---|---|
| Comment | 質問・感想・軽い指摘 | 返信して会話する。修正必須とは限らない |
| Request changes | 修正してほしいという明確な要求 | 修正をcommitして返信。対応済みならResolve |
| Approve | この内容でmergeしてよいという承認 | merge に進める |
コメントに対応する修正は、同じbranchに追加commitすれば自動でPRに反映されます。対応が終わった指摘は「Resolve conversation」で畳むと、残っている論点が一目で分かります。CodexやClaude CodeのPRに人間がレビューコメントを付け、AIに「レビューコメントに対応して」と指示する使い方も実務的で、この場合もResolveの操作で人間が「対応完了」を判定する形にすると、確認の主導権を保てます。