CodexでPRコメントを修正キューにする前に決めること

3行まとめ

Type

種類。

Priority

順序。

Tests

確認。

Reply

返信。

レビューコメントは、修正対象と会話対象を分けてから扱います。

• 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. 1根拠

   指摘箇所。

2. 2影響

   壊れる範囲。

3. 3修正

   最小差分。

4. 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を仕様確認へ戻す

Spec

仕様。

Owner

回答者。

Decision

決定。

Log

記録。

質問コメントは、すぐ修正せず意思決定へ戻すことがあります。

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をまとめて小さく直す

Style

表記。

Name

命名。

Format

整形。

Batch

まとめ。

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へ逃がす

1. 1Scope

   対象外。

2. 2Issue

   作成。

3. 3Link

   紐付け。

4. 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本文の更新にも使えます。

よくある失敗

全部対応

大差分。

無言修正

追えない。

質問を実装

誤読。

testなし

確認不可。

コメント対応は、速さより追跡できることを優先します。

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

次に読むなら

更新履歴

1. 2026.06.01

   初版。

CodexのPR review周辺の使い方は、導入時に公式docsで見直します。

• 2026年6月1日: OpenAI公式Codex docsのUse Cases、app features、Worktrees、Permissions、AGENTS.md guideを確認し、初版を作成しました。