このページでわかること
PRレビューコメントを分類し、修正、返信、再確認へ進める流れがわかります。
結論
CodexにGitHub実務を任せる時は、対象repo、branch、差分、Secrets、CI、PR本文を分けて確認します。main直push、危険操作、検証を飛ばす操作、private repoなら安全という考え方は避けます。
対象読者
CodexでGitHubのIssue、PR、レビュー、CI、branch、private repo、READMEやrelease noteを扱いたい人向けです。
Codexに任せやすいこと
コメント分類、修正対象の抽出、差分確認、返信文の下書き、未解決項目の整理。
人間が確認すべきこと
レビュー意図を誤読していないか、指摘範囲を越えて広げていないか、修正後に再確認したか。
GitHub作業での注意点
未解決コメント、Requested changes、inline comment、質問コメントを分け、指摘箇所から外れた変更を混ぜないようにします。
やってはいけないこと
危険コマンド、履歴に強く影響するpush操作の安易な推奨、検証を飛ばす操作、Secretsやtokenのログ出力、社内コードや顧客情報の入力推奨は避けます。
STOP条件
レビューコメントの意図が不明、広範囲の設計変更が必要、秘密情報を含む差分が見つかった場合。
FAQ
レビューコメントは全部同じ扱いですか？
違います。修正必須、質問、確認だけ、メモを分けます。
Codexに返信文も作れますか？
下書きは作れます。最終的な返信は人間が確認します。
ついでに他の修正もしてよいですか？
避けます。レビュー対応では指摘箇所を中心にします。
解決済みコメントも見ますか？
必要なら見ますが、未解決コメントを優先します。
Codex実践ログ・ケーススタディ 第12波
静的HTML修正、Search Consoleロングテール、AdSense低価値、スマホ表示、内部リンク404、タグ棚卸し、PRレビュー、報告書から次オーダーへの作業例です。