Codexでコードレビューする方法｜確認と修正を分ける

Codexのレビューは、変更によって問題が起きる可能性を調べるために使います。対象の差分と期待する動作を伝え、指摘を確認してから修正すると、確認作業が進めやすくなります。

レビューと修正を分けて進める

1. 1差分を選ぶ
2. 2/review
3. 3指摘を再現
4. 4修正・再確認

ローカルのレビューと連携によるレビュー

手元のコードを見てもらう方法と、GitHubなどの連携を利用したプルリクエストのレビューは分けて考えます。公式のCode Review機能は、説明・変更ファイル・コメント・チェックを確認する入口を提供します。利用条件は公式のCode reviewとGitHub連携で確認してください。

この記事では、まずローカルの変更を対象にした、レビューの依頼と確認の方法を扱います。

CLIで/reviewを使う手順

1. 対象のGitリポジトリでgit statusを実行し、どの変更があるか確認します。
2. 同じフォルダでcodexを起動します。
3. 入力欄へ/reviewと入力します。
4. 未コミットの変更、基準ブランチとの差分など、調べたい範囲を選びます。
5. 指摘のファイル・行・発生条件を読み、再現確認へ進みます。

組み込みのレビューは、選んだ差分を調査して指摘を返す操作です。修正やマージまで自動で済ませる意味ではありません。GitHub上のPRを扱うCode Reviewプラグインとは入口が異なります。公式のレビュー手順

git status
git diff
codex

git diffは作業ツリーの変更を見る基本的な確認です。ステージ済みの変更はgit diff --cachedなどで分けて確認し、レビュー対象が意図した差分か把握してください。

教材例：空欄と「0」を取り違える変更

const quantity = Number(input);
if (!quantity) return "未入力です";

この例は、数量0を有効な入力として扱う仕様なら問題になります。「空欄を止める」という目的に対し、0まで未入力と判断するためです。レビューではinput = "0"という再現条件と、仕様上0を許可するかをセットで確認します。実際の修正方法は、そのフォームの入力仕様に合わせて決めます。

最初に伝える情報

• 何を直すための変更なのか。
• 変更前と変更後に期待する動作。
• 調べてほしいファイルや差分の範囲。
• 実施済みのテストと、確認できていない条件。
• レビューだけを頼むか、修正まで進めるか。

コードの見た目だけでなく、利用者の行動と結果を伝えると、影響を調べやすくなります。

レビューを依頼する指示例

今回の検索フォームの変更をレビューしてください。
期待する動作：空欄なら全記事を表示し、キーワードがあれば絞り込む。
対象：検索フォームと記事一覧の差分。
まだ修正はしないでください。

指摘には次を含めてください。
- 問題が起きる入力・操作
- 影響するファイルと箇所
- 期待する結果と、実際に起きると考えられる結果
- 実行して確認したか、コードからの推測か

これは編集部が作った教材例です。実行していない挙動を、再現済みの問題と混ぜないことを重視しています。

指摘が返ってきたら、再現条件を確かめる

AIの指摘には、前提の取り違いや不要な変更提案が含まれることがあります。すべてを自動で採用せず、今回の目的と再現条件に照らして判断します。

再現できる教材：入力仕様からテストを作る

先ほどの数量フォームを、実行して確かめられる例へ広げます。ここでは「半角数字で0〜999の整数を受け付ける」「前後の空白は除く」「空欄・負数・小数・数字以外は受け付けない」と仕様を決めます。実際の商品で同じ仕様が正しいとは限りません。

最初に期待する結果を表へ書きます。修正コードを見てから都合のよいテストを作るのではなく、利用者の入力と期待値を先に固定するのがポイントです。

修正例と、その適用範囲

この仕様に限ったJavaScriptの修正例です。HTMLの入力欄から文字列を受け取る関数として示しています。

function parseQuantity(input) {
  if (typeof input !== "string") {
    return { ok: false, reason: "文字列を指定してください" };
  }
  const text = input.trim();
  if (text === "") {
    return { ok: false, reason: "未入力です" };
  }
  if (!/^[0-9]+$/.test(text)) {
    return { ok: false, reason: "半角の整数を指定してください" };
  }
  const value = Number(text);
  if (!Number.isInteger(value) || value > 999) {
    return { ok: false, reason: "0〜999で指定してください" };
  }
  return { ok: true, value };
}

ここでは、空欄の判定と数値0の判定を分けています。元の例を単にquantity === 0へ書き換えるだけでは、空欄も0へ変換されるため問題が残ります。入力を数値にする前の文字列も調べる必要があります。

この修正例とテストは練習用ZIPから取得できます。Node.jsが使える環境で、展開先からnode quantity.test.mjsを実行すると、この関数の入力条件を確認できます。編集部は同梱のテストをNode.jsで実行して期待値との一致を確認しました。ブラウザのフォーム送信や、実際の業務画面での動作検証は含みません。

仕様が違えば、指摘の採否も変わる

もし「注文数量は1以上」という仕様なら、0を拒否すること自体は正しい判断です。ただし「未入力です」という説明が適切かは、別の検討になります。AIが0の扱いを指摘したときは、コードだけで結論を出さず、許容範囲とエラーメッセージの意味を確認してください。

同様に、全角数字を許可するフォームなら上の実装は不十分です。教材のコードをそのまま採用するのではなく、自分の仕様で入力表を作り直してから修正します。

レビュー範囲を間違えないための選び方

Codexの組み込みレビューは、未コミットの変更、基準ブランチとの差分、特定コミットなどから対象を選びます。未コミットの変更には、自分や別の作業が加えた差分も含まれます。公式：レビューの範囲

レビュー前に差分を片付けるため、他人の変更を削除したり、無関係なファイルをまとめてコミットしたりする必要はありません。対象を切り分け、混在している状態をレビュアーへ伝えます。

指摘は、再現・採否・再確認まで一組で残す

指摘：数量0が未入力扱いになる
対象：quantity.mjs の入力判定
前提：仕様で0を許可する
再現入力："0"
期待結果：ok=true, value=0
変更前の結果：未入力として拒否
採否：採用
修正：文字列の空欄判定と数値範囲判定を分離
確認：同じ入力と周辺の境界値で再実行
未確認：ブラウザからの送信・サーバー側の保存

「修正済み」とだけ記録すると、後から何が確認できたのか分からなくなります。コードからの推測である指摘はそのまま推測として残し、実行したものは入力と結果を記載します。採用しなかった指摘にも、仕様上の理由を短く残すと、同じ議論を繰り返しにくくなります。

修正後は、同じ条件で再確認する

1. 採用した指摘と修正内容を対応させる。
2. 問題を確認したときと同じ操作を試す。
3. 周辺の正常な操作も壊れていないか確認する。
4. テストできなかった条件を残す。

検索フォームの例なら、「空欄」「一致する語」「一致しない語」「日本語・英数字」を使って確認します。修正前後で条件が違うと、改善したか判断しにくくなります。

繰り返すレビューのルールを残す

プロジェクトごとの確認事項はAGENTS.mdへ、毎回のレビュー手順はSkillsへまとめます。「見た目の好み」と「動作上の不具合」を分けるルールも役立ちます。

よくある質問

レビューで指摘がなければ安全ですか？

指摘がないことは、すべての条件で問題がない証明ではありません。レビュー範囲、実施したテスト、確認できなかった条件を一緒に判断します。

自動でマージまで進めてもらえますか？

レビュー、修正、マージ、本番反映は別の操作です。会社やプロジェクトの権限・確認手順に合わせて進めます。この記事の確認例には、外部へのマージや公開は含めていません。