3行まとめ
種類。
順序。
確認。
返信。
レビューコメントは、修正対象と会話対象を分けてから扱います。
- PRレビューコメントは、blocking、question、nit、follow-up、out-of-scopeに分けてからCodexへ渡します。
- Codexには、コメント本文だけでなく、対象diff、修正範囲、確認するtest、返信方針をセットで渡します。
- すべてのコメントを同じPRで直さず、仕様確認や別Issueへ分ける判断を残すと、レビューが追いやすくなります。
AIエージェントがPRを作るようになると、PRレビューコメントの扱いが地味に難しくなります。人間が書いたコメント、AI reviewerが出した指摘、maintainerの質問、軽いnit、今回のPRとは別の改善提案が同じ画面に並ぶからです。
そこでCodexへ「全部対応して」と頼むと、差分が膨らみます。質問に対して実装で答えてしまう。軽い表記修正と設計変更が混ざる。別Issueで扱うべき提案まで同じPRへ入る。結果として、最初のPRよりレビューしづらい差分になります。
この記事では、2026年6月1日時点のOpenAI公式Codex docsをもとに、PRコメントを修正キューへ変える前の整理を扱います。PR本文そのものの型は、公開済み記事のAIエージェントPRテンプレートの作り方で扱っています。ここでは、PRについたコメントへどう返すかに絞ります。
この記事でわかること
5種類。
順序。
テスト。
再レビュー。
コメント対応を、場当たり的な修正ではなく小さな運用にします。
- PRコメントを5種類に分類する方法
- blockingコメントから処理する理由
- questionを勝手に実装しないための戻し方
- nitを小さくまとめて直す考え方
- follow-upを別Issueへ分ける判断
- Codexに渡すfix queueの形
- reviewerへ返す返信と再レビューのそろえ方
PRコメント対応は、実装作業であると同時に会話の整理です。コメントを読んだ人が、どの指摘を直し、どの指摘を確認中にし、どの指摘を別タスクへ移したのかを追える必要があります。
前提知識
| 項目 | 内容 | 見方 |
|---|---|---|
| Use Cases | PR review。 | |
| Features | 作業入口。 | |
| Worktrees | 差分分離。 | |
| Permissions | 権限。 | |
| AGENTS.md | 返信型。 |
PRコメント対応では、修正範囲と報告形式を先に決めます。
OpenAI公式のCodex Use Casesでは、GitHub pull requestのcode review、bug triage、large codebase理解、verified operationsなどが用途として示されています。Codex app features、worktrees、permissions、AGENTS.md docsは、作業単位、変更範囲、権限、報告形式を決める時に関係します。
PRコメント対応では、Codexに必要以上の権限を渡す必要はありません。最初はコメントの分類、対象diffの確認、修正案の整理だけを任せます。実際にファイルを書く段階では、直すコメントを選び、修正範囲を狭め、test commandを固定します。
PR本文とコメント対応は別物
PR本文は、作業者が先に出す説明です。Summary、Scope、Tests run、Risks、Not runなどをまとめます。
PRコメント対応は、reviewerから返ってきた入力を扱う作業です。コメントには、必須修正、質問、表記の好み、将来改善、誤読、重複指摘が混ざります。PR本文がよく書けていても、コメント対応には別の整理が必要です。
AI reviewと人間reviewを同じ列に置く
AI reviewerのコメントも、人間reviewerのコメントも、最初は同じ分類表に入れます。ただし、採用判断は同じではありません。
人間reviewerがmergeを止めている指摘は、優先度が高いです。AI reviewerの指摘は、根拠があるか、再現できるか、既存仕様と合っているかを確認します。どちらも、コメント本文だけでなく対象diffと根拠を見ます。
コメントを5種類に分ける
| 項目 | 内容 | 見方 |
|---|---|---|
| Blocking | 必須。 | |
| Question | 確認。 | |
| Nit | 軽微。 | |
| Follow-up | 別件。 | |
| Out | 対象外。 |
分類がないコメント対応は、差分が広がりやすくなります。
PRコメントは、blocking、question、nit、follow-up、out-of-scopeに分けます。この5種類に分けるだけで、Codexへ頼む作業がかなり扱いやすくなります。
blockingは、merge前に直す必要がある指摘です。bug、security、data loss、breaking change、test failure、仕様違反などです。
questionは、reviewerが意図や仕様を確認しているコメントです。質問に見えるものをすぐ実装で返すと、reviewerの意図とずれることがあります。
nitは、命名、表記、format、軽い読みやすさの指摘です。小さいですが、まとめ方を間違えると無関係な整形が広がります。
follow-upは、良い提案だが今回のPRに入れないほうがよいものです。関連はあるが別Issueで扱うほうが、レビューしやすい場合があります。
out-of-scopeは、今回のPRでは扱わない指摘です。誤読、既存仕様、別チームの責任範囲、すでに別PRで対応済みのものが入ります。
分類表を先に作る
Codexには、まず修正させず、コメントの分類表を作らせます。
| comment | class | target | suggested action | test | reply |
|---|---|---|---|---|---|
| reviewer Aの指摘 | blocking | file X | 最小修正 | unit test | fixed |
| reviewer Bの質問 | question | spec | owner確認 | なし | ask |
| AI reviewerの提案 | follow-up | broader refactor | Issue化 | なし | split |
この表ができると、Codexに「blockingだけ直して」「nitだけ別commit相当の小差分で直して」「questionは返信案だけ作って」と頼めます。
コメントの重複をまとめる
同じ原因を指しているコメントは、1つの修正単位にまとめます。別々に直すと、同じfileを何度も触り、reviewerが追いにくくなります。
たとえば、1つのvalidation漏れに対して、UI表示、API response、test不足の3コメントが付くことがあります。この場合は、原因を1つにまとめ、修正とtestを対応させます。
blockingから先に扱う
- 1根拠
指摘箇所。
- 2影響
壊れる範囲。
- 3修正
最小差分。
- 4確認
テスト。
mergeを止める指摘は、根拠と確認方法をセットで扱います。
blockingは、merge前に解消するコメントです。Codexへ渡す時は、コメント本文だけでなく、なぜblockingなのか、どの差分が対象なのか、直ったことをどう確認するのかをセットにします。
blocking対応で避けたいのは、指摘を広げすぎることです。securityやdata lossの指摘があると、周辺を全部直したくなります。しかし、PRレビュー中のblocking対応では、まず今回の差分で生まれた問題を閉じることが大事です。
blockingの入力
Codexへ渡す入力は、短いほうがよいです。
- 対象コメント
- 対象diff
- 関連する既存テスト
- 期待される挙動
- 変更してよいfile
- 実行するtest command
この6つがあると、Codexは修正の方向を外しにくくなります。
直す前に根拠を確認する
blockingコメントでも、根拠を確認します。reviewerが正しいとは限らない、という意味ではありません。コメントが指している具体的な壊れ方を確認するためです。
Codexには、修正前に「この指摘はどの入力で再現するか」「どの既存挙動を壊しているか」「どのtestで確認できるか」を短く出させます。根拠が曖昧なら、先に質問へ戻します。
修正後の返信
blockingを直したら、返信には修正内容とtestを入れます。
例:
Fixed by keeping the existing empty-state branch and adding a regression test for the no-result case.
Ran: npm test -- search-panel返信は長くしません。reviewerが見るべき差分と確認結果が分かれば十分です。
questionを仕様確認へ戻す
仕様。
回答者。
決定。
記録。
質問コメントは、すぐ修正せず意思決定へ戻すことがあります。
questionコメントは、実装依頼とは限りません。「この挙動は意図的ですか」「ここは既存仕様と違いますか」「このcaseは考えていますか」というコメントは、まず意思決定へ戻します。
Codexが質問を修正と誤解すると、勝手に仕様を変えることがあります。特に、product仕様、権限、料金、通知、削除、公開範囲に関わる質問は、すぐにコードへ反映しません。
questionの出力
Codexには、questionを次の形へ整理させます。
| 項目 | 内容 |
|---|---|
| question | reviewerの質問 |
| likely decision | 選択肢 |
| owner | 誰が答えるか |
| needed evidence | 仕様、ログ、既存挙動 |
| reply draft | 返信案 |
この形にすると、PR上で会話を止めずに進められます。
回答が出るまで変更しない
質問への回答が出るまで、関連コードを変えないほうが安全です。特に、仕様が2択以上ある場合は、どちらを選ぶかでtestも変わります。
Codexには、questionを「pending decision」として残させます。修正キューには入れず、返信案と確認先だけを作らせます。
仕様が決まったら小さく直す
ownerが答えたら、その回答を修正キューへ戻します。ここで初めて、対象file、変更内容、test、返信を決めます。
PR上では、「質問への回答に基づいて、このcaseだけ直した」と分かるように返信します。
nitをまとめて小さく直す
表記。
命名。
整形。
まとめ。
nitはまとめて直しつつ、機能変更と混ぜないようにします。
nitは軽い指摘ですが、扱いを間違えるとPRが汚れます。命名、表記、format、コメント文言、import順のような小さい指摘は、まとめて直してよい一方で、機能変更と混ぜると追いにくくなります。
Codexにnitを直させる時は、「nitだけ」「対象コメントだけ」「format全体は触らない」と明記します。
nitはbatchにする
小さいコメントが10件ある時、1件ずつCodexに直させると、同じfileを何度も変更することがあります。まずnitだけを集め、同じfile内でまとめて直します。
ただし、formatterを全体にかけるかどうかは別判断です。既存PRが小さい差分なら、全体formatは避けます。formatter必須のrepoなら、format差分が出ることを返信で説明します。
命名変更は軽く見ない
命名のnitは、見た目より影響が大きいことがあります。export名、URL parameter、translation key、CSS class、test id、public API名は、軽い変更ではありません。
Codexには、命名変更が外部公開面に出るかを確認させます。内部変数なら直しやすいですが、外から参照される名前ならblockingやquestionに分類し直すことがあります。
nitだけの返信
nitを直した返信は、短くてよいです。
Thanks, updated the variable name and copy in the two commented spots.testが不要な文言修正でも、必要なら「no behavior change」と添えます。テスト不要と未検証は違います。
follow-upを別Issueへ逃がす
- 1Scope
対象外。
- 2Issue
作成。
- 3Link
紐付け。
- 4Close
返信。
よい提案でも、今回のPRで直すとは限りません。
follow-upは、今回のPRでやらないほうがよい改善提案です。良い指摘でも、同じPRへ入れると差分が大きくなり、mergeが遅くなります。
たとえば、今回のPRがbugfixなのに、reviewerが「この周辺をhookへ分けたい」「古いAPIも整理したい」「E2Eを全面的に増やしたい」とコメントすることがあります。重要でも、今回の修正に必須でないなら別Issueへ逃がします。
follow-up化の条件
follow-upにする条件は、先に決めておきます。
- 今回のbugfixに必須ではない
- 既存挙動を変える可能性がある
- 影響範囲が広い
- 別ownerの判断が必要
- 追加testや移行作業が大きい
この条件に当てはまるものは、CodexにIssue本文へ変換させます。
Issue本文へ変える
Codexには、コメントを次の形へ変えさせます。
背景:
PRレビューで指摘された改善。
対象:
- file/path
- 関連する挙動
やること:
- 小さな調査
- 修正案
- 必要なtest
今回のPRでやらない理由:
- scope外
- mergeを遅らせないためこれなら、reviewerにも「無視した」のではなく「別タスクにした」と伝わります。
PR上の返信
follow-upへ逃がす場合は、IssueやタスクのURLを返信します。
Good point. I split this into a follow-up because it changes the broader data-loading path.
Tracked here: <issue URL>URLがまだない場合は、作成予定ではなく、先にIssueを作ってから返信します。未来URLや未作成記事へのリンクと同じで、実体がない参照は追跡性を落とします。
Codexに渡す修正キュー
| 項目 | 内容 | 見方 |
|---|---|---|
| Comment | 引用。 | |
| Class | 分類。 | |
| Patch | 範囲。 | |
| Test | 確認。 | |
| Reply | 返答。 |
修正キューは、コメントと差分とテストを対応させます。
分類が終わったら、Codexへfix queueを渡します。fix queueは、コメント、分類、対象、作業、test、返信を1行で持つ表です。
この表を作る目的は、Codexの作業を制限することです。「レビューコメントを全部見て適当に直す」のではなく、「この3件だけ直す」「questionは返信案だけ」「follow-upはIssue本文だけ」のように分けます。
fix queueの例
| id | class | target | action | test | reply |
|---|---|---|---|---|---|
| C1 | blocking | SearchPanel.tsx | empty stateを戻す | unit | fixed |
| C2 | question | product spec | ownerへ確認 | none | ask |
| C3 | nit | copy text | 文言だけ修正 | none | fixed |
| C4 | follow-up | data hook | Issue化 | none | split |
Codexには、id単位で作業させます。C1とC3を同時に直す場合でも、返信では別々に対応が分かるようにします。
変更してよい範囲を明記する
fix queueには、変更してよいfileも入れます。
Handle C1 and C3 only.
Allowed files:
- src/search/SearchPanel.tsx
- src/search/SearchPanel.test.tsx
Do not refactor data fetching.
Do not change public copy except the commented text.ここまで書くと、Codexが良かれと思って周辺を整理する余地が減ります。
testと未検証を分ける
test欄には、実行するcommandを書きます。test不要なら、その理由を書きます。
未検証を隠さないことも大事です。CIが重くて回せない、E2E環境がない、owner回答待ち、外部API依存で確認できない。こうしたことは、PR返信やsummaryへ残します。
1回で扱う件数
1回のCodex作業で扱うコメントは、少なくします。blockingを2件、nitを数件、questionは返信案だけ、のように分けると、差分と返信の対応が崩れにくくなります。
コメント数が多い場合は、最初に全件分類だけを行い、次の作業でP0/P1だけを直します。分類と修正を同時に広げると、Codexの報告を人間が確認しにくくなります。
返信と再レビューをそろえる
| 項目 | 内容 | 見方 |
|---|---|---|
| Fixed | 修正済み。 | |
| Tested | 確認済み。 | |
| Asked | 質問中。 | |
| Split | 別Issue。 |
返信は、修正した事実と残した判断を短く示します。
PRコメント対応では、修正そのものだけでなく返信が大事です。reviewerは、どのコメントが解消され、どれが確認中で、どれが別Issueになったのかを知りたいからです。
Codexには、修正後の返信案も作らせます。ただし、返信は事実に合わせて人間が確認します。実行していないtestを「Ran」と書かせてはいけません。
返信の型
返信は4種類に分けます。
| 状態 | 返信に入れること |
|---|---|
| fixed | 何を変えたか、どのtestを回したか |
| asked | 誰に何を確認しているか |
| split | どのIssueへ分けたか、なぜ今回入れないか |
| declined | なぜ対応しないか、根拠は何か |
declinedも必要です。すべてのコメントへ対応することが、良いレビューではありません。既存仕様と合わない提案や、今回のPRと無関係な提案は、根拠を付けて見送ります。
再レビュー依頼を小さくする
修正後に再レビューを頼む時は、reviewerに見てほしい範囲を示します。
Ready for re-review.
Please focus on C1 empty-state behavior and C3 copy change.
C2 is pending product confirmation, and C4 was split to a follow-up issue.これにより、reviewerはPR全体をもう一度最初から読まなくても、注目点をつかめます。
Codexの最終報告
Codexの作業報告にも、コメント対応表を残します。
- Fixed: C1, C3
- Asked: C2
- Split: C4
- Tests run:
npm test -- search - Not run: E2E
- Risk: owner回答待ちの仕様は未反映
この形なら、PR本文の更新にも使えます。
よくある失敗
大差分。
追えない。
誤読。
確認不可。
コメント対応は、速さより追跡できることを優先します。
PRコメント対応で多い失敗は、全部対応、無言修正、質問の実装化、testなし、scope拡大です。
全部対応は、reviewerの提案をすべて同じPRへ入れることです。良い提案でも、今回のPRに必要とは限りません。
無言修正は、コメントには反応せず、差分だけ更新することです。reviewerは、どのコメントがどう解消されたのか追えません。
質問の実装化は、questionを仕様決定と誤読することです。質問は、選択肢を明らかにしてownerへ戻します。
testなしは、直ったかどうかが分からない状態です。文言修正や型だけの変更ならtest不要の場合もありますが、その場合も理由を残します。
scope拡大は、コメント対応のついでに周辺をリファクタリングすることです。レビューコメント対応では、reviewerが指摘した範囲と、今回直す範囲を対応させます。
AI reviewerの指摘を信じすぎる
AI reviewerの指摘は便利ですが、誤検知や過剰提案が混ざります。CodexにAI reviewerコメントを直させる場合も、根拠、再現性、仕様との整合を確認します。
「AIが指摘し、AIが直した」状態を人間が追えないなら、レビューの意味が薄くなります。分類表と返信で、人間が判断できる形へ戻します。
reviewerを待たずに広げる
reviewerが質問している時に、広い修正を入れると会話がずれます。質問には、質問として返す。回答が出てから修正する。単純ですが、AIに任せる時ほど大事です。
コメント対応をPR本文へ戻さない
コメント対応でtestを追加したり、scopeを変えたり、未検証項目が増えたりしたら、PR本文も更新します。PR本文とコメント返信が食い違うと、最後のmerge判断が難しくなります。
FAQ
| 項目 | 内容 | 見方 |
|---|---|---|
| 大量? | P0/P1から。 | |
| nit? | 分ける。 | |
| 反論? | 根拠付き。 | |
| 再レビュー? | 差分だけ。 |
迷ったら、reviewerが再確認しやすい単位へ戻します。
コメントが多すぎる時はどうする?
まずP0/P1、またはblockingだけに絞ります。Codexには、全コメントを分類させたうえで、今回の修正対象を3件程度に絞らせます。
nitは全部直すべき?
原則として、簡単に直せて差分が小さいものは直します。ただし、外部公開名、翻訳key、test id、API名などはnitに見えても影響が大きい場合があります。
reviewerの指摘に反対してよい?
よいです。ただし、根拠を添えます。既存仕様、互換性、別Issue、今回のscope外など、判断理由を短く書きます。
Codexにコメント返信まで任せてよい?
返信案を作らせるのは便利です。ただし、実行していないtest、未確認のowner回答、存在しないIssue URLを書いていないかは人間が確認します。
再レビューはPR全体を頼むべき?
大きく変わった場合は全体再レビューが必要です。小さいコメント対応なら、変更したコメントIDと対象fileを示し、注目点を狭めます。
参照した主な情報源
- Codex Use Cases – OpenAI Developers
- Codex app features – OpenAI Developers
- Worktrees – Codex app – OpenAI Developers
- Permissions – Codex – OpenAI Developers
- Custom instructions with AGENTS.md – Codex – OpenAI Developers
次に読むなら
更新履歴
- 2026.06.01
初版。
CodexのPR review周辺の使い方は、導入時に公式docsで見直します。
- 2026年6月1日: OpenAI公式Codex docsのUse Cases、app features、Worktrees、Permissions、AGENTS.md guideを確認し、初版を作成しました。