CodexでCodexをレビューする：独立セッションで作るセカンドパス¶

Codex CLI 完全ガイド

対象 / ポイント

対象: Codex CLIを主作業エージェントとして使い、計画レビューや実装後レビューの型を作りたい中級〜上級開発者

ポイント:

同じCodexでも、別セッションにdiffや計画だけを渡すレビューには意味がある
価値は「完全な客観性」ではなく、作業中の会話履歴から切り離したセカンドパスにある
実務では、生のcodex execより先にレビュー用Skillを入口にする

Codexで実装していると、最後にもう一度「これは本当に大丈夫か」を見たくなる。ここでClaudeやGeminiなど別モデルに投げる方法はわかりやすい。モデルが違えば、失敗パターンも違う可能性がある。

ただし、別モデルであることだけがレビューの価値ではない。Codexを主作業エージェントにしている場合でも、別のCodexセッションにdiffや計画だけを読ませることで、作業中の会話履歴から距離を置いたレビューを作れる。

この記事の問いは、CodexからCodexレビューを呼ぶことに実務上の意味があるのか、である。

結論：完全な客観性ではなく、独立性の高いセカンドパス¶

同じモデルにレビューさせる限り、「完全に客観的」とは言えない。モデル特性、リポジトリの規約、渡したプロンプトが同じなら、似た判断に寄る可能性は残る。

それでも、レビューの独立性は上げられる。

作業セッションは、実装中の判断、途中で捨てた案、ユーザーとのやり取り、修正の自己正当化を抱えている。レビュー側にその全文脈を渡さず、git diff、計画、受入条件、テスト結果だけを渡せば、レビュアーは成果物に近い形で判断できる。

これは人間のレビューでも同じだ。実装者本人がコードを見直すより、PR差分だけを読む別レビュアーのほうが、前提を疑いやすい。Codex内レビューの狙いは、別人格を作ることではない。入力を分けて、役割を分けることである。

因果の流れは単純である。実装セッションで判断の理由が積み上がる → その理由に引っ張られてdiffを甘く見る → fresh sessionに計画やdiffだけを渡す → 履歴がない状態で成果物を読む → 仕様、テスト、リスクの穴を拾いやすくなる。

ただし、これは効果保証ではない。同じモデル、同じプロンプト、同じdiffなら、同じ盲点に寄る可能性は残る。だからこそ、独立セッションは「証拠のない安心材料」ではなく、テスト結果や受入条件と組み合わせて使う。

3つのレビュー方式は何が違うのか¶

このセクションが答える問い：レビュー方式ごとに、何を分離しているのか。

Codex周辺のレビューは、少なくとも3種類に分けて考えたほうがよい。

方式	何を分離するか	強い場面	弱い場面
別モデルレビュー	モデル特性	設計判断、リスクの見落とし	ツールや文脈の再接続が必要
別Codexセッション	会話履歴と役割	Skill経由の計画レビュー、diffレビュー、冷却確認	同じモデル由来の癖は残る
Codex subagent	観点と並列性	セキュリティ、テスト、保守性の分担	token消費と制御が重くなる

GitHub Agent HQのように、Copilot、Claude、Codexを同じissueやPRに割り当てて結果を比較する方法は、主に「別モデル・別エージェントの比較」である。 GitHubは、複数エージェントを同じタスクに割り当て、 tradeoffやedge caseを早く浮かび上がらせる使い方を説明している¹。

一方、この記事で扱うのはもう少し狭い。Codexの中で、実装セッションとは別のセッションやsubagentにレビューを任せる。目的はモデル差ではなく、文脈汚染を減らすことだ。

実務の入口はレビュー用Skillにする¶

このセクションが答える問い：人間が直接codex execを打たずに済ませるには、どこを入口にするのか。

実務では、毎回この場でcodex execの長いコマンドを組み立てるより、レビュー用Skillを入口にしたほうがよい。 Claude CodeからCodex CLIを呼ぶレビューループと同じで、使う側は「レビューして」と呼び出す。 Skill側が、差分の取得、read-only実行、判定形式、再レビュー回数を固定する。

たとえば、このリポジトリでは次の2つを分けている。

codex-review: 実装前の計画をCodex CLIにレビューさせる
codex-impl-review: コミット前の差分をCodex CLIにレビューさせる

Codexを主作業エージェントにしている場合でも、実装前ならcodex-reviewで計画だけを別セッションに読ませられる。実装後ならcodex-impl-reviewで現在のgit diffをレビュー対象にし、必要ならプランとの差分も照合できる。つまり「CodexからCodexを呼ぶ」構成ではあるが、読者が直接扱うべき単位は生コマンドではなく、レビューSkillである。

内部的には、次のような流れで処理が進む。ここでのUUID生成や一時ファイル作成は、人間が手で実行する手順ではなく、Skill側がレビュー実行を安全に分離するための実装詳細である。

flowchart TD
    A[ユーザーが計画レビューまたは実装レビューを依頼] --> B{どのSkillか}
    B -->|計画レビュー| C[codex-reviewが計画を取得]
    B -->|差分レビュー| D[codex-impl-reviewが必要に応じて計画を取得]
    D --> E[現在のgit diffを取得]
    C --> F[一意なレビューIDを生成]
    E --> F
    F --> G[Codex CLIをread-onlyで起動]
    G --> H[Codexが計画、diff、テスト、リスクをレビュー]
    H --> I{判定}
    I -->|APPROVED| J[承認とレビュー範囲を報告]
    I -->|REVISE| K[計画または実装を修正]
    K --> L[計画またはdiffを更新]
    L --> M[同じレビューセッションで再確認]
    M --> I

OpenAIの非対話モードのドキュメントでは、codex execをCIやpre-merge checkなどの自動化に使えるものとして説明している²。また、前回の実行を続けたい場合はcodex exec resumeを使える²。つまり、resumeするレビューと、あえて新規実行にするレビューを使い分けられる。

この使い分けが重要だ。

計画レビュー: 実装前のプランだけを、実装セッションとは別に点検する
追跡レビュー: 前回の指摘が直ったかを見る段階では、Skillが同じレビューセッションを継続する
独立レビュー: 作業中の文脈から切り離す段階では、Skillが新しいレビューセッションを作る
最終監査: ループ後に1回だけ新規セッションで全体を読む

レビューの目的が違えば、セッション継続の正解も変わる。修正追跡にはresumeが効く。思い込みの切断にはfresh sessionが効く。

subagentで観点を分ける¶

このセクションが答える問い：fresh sessionより細かい粒度で独立性を作るには、何を分けるのか。

Codexにはsubagent workflowもある。公式ドキュメントでは、複雑で並列化しやすいタスクに対して、専門化したエージェントを並列に起動し、結果を集約できると説明している³。

レビューでは、この仕組みがそのまま使える。

このPRをmainとの差分でレビューしてください。
観点ごとにsubagentを分け、最後に統合してください。

1. correctness と回帰
2. security と権限境界
3. missing tests とテストの弱さ
4. maintainability と将来の変更容易性

Codex公式ドキュメントの例でも、PR reviewをpr_explorer、reviewer、docs_researcherのような複数custom agentに分けるパターンが紹介されている³。さらに、custom agentにはmodel、model_reasoning_effort、sandbox_modeなどを設定できる³。

ここでの利点は、別モデルではなく別観点である。1つのレビューに全部を詰め込むと、出力は網羅的に見えても浅くなりやすい。観点ごとに分けると、「セキュリティだけ厳しく見る」「テスト不足だけ拾う」といったレビューを作れる。

OpenAI自身の運用も「agent-to-agent review」に寄っている¶

この発想はローカルの小技ではない。 OpenAIのHarness Engineering記事では、Codexに自分の変更をローカルでレビューさせ、追加のagent reviewを依頼し、フィードバックに応答しながら全レビュアーが満足するまでループする運用が説明されている⁴。

同記事では、人間のレビュー負荷をほぼagent-to-agent reviewへ寄せていったとも述べている⁴。これは「同じ名前のCodexだからレビューに意味がない」という見方とは逆である。重要なのは、作業を分解し、検証可能にし、レビューをシステムに埋め込むことだ。

ただし、OpenAIの例は強いハーネスが前提である。この制約は、使いどころを決めるうえで重要になる。

レビュー用Skillの導入方法¶

このセクションが答える問い：Claude Code版と同じ導入手順を、Codex側ではどこに置き換えるのか。

ここで導入するのは、Codex CLI本体ではなくレビュー用Skillである。計画レビュー、差分の取得方法、read-only実行、再レビュー回数、判定形式までをチームで固定するにはSkillとして置いたほうが扱いやすい。

導入の考え方は、Claude Code × Codexレビューループ記事のレベル1と同じでよい。違いは、Claude Codeでは.claude/skills/...に置くのに対し、 Codexで使う場合はリポジトリ共有のSkill置き場である.agents/skills/...に置く点である⁵。

つまり、対応関係は次のようになる。

使う環境	置き場所	起動例
Claude CodeからCodexを呼ぶ	`.claude/skills/codex-review/SKILL.md`	`/codex-review`
CodexからCodexレビューを呼ぶ	`.agents/skills/codex-review/SKILL.md`	`/codex-review`またはSkill名指定

現行のCodex CLIには、codex skill install ...という名前のCLIサブコマンドは確認できない。一方、公式ドキュメントには、ローカル利用向けに$skill-installerでcurated skillや他リポジトリのSkillを入れる方法が説明されている⁵。この記事で扱うのはチームでgit管理するリポジトリ内Skillなので、既存記事と同じく「ディレクトリを作る → SKILL.mdを置く」という手順に寄せる。

2026-05-09時点の確認

.agents/skillsはCodex公式のリポジトリ内Skill置き場として説明されています⁵。 codex exec resumeも非対話モードの継続手段として公式に説明されています²。手元のCodex CLIではcodex reviewサブコマンドを確認できますが、公式CLIリファレンスの安定コマンド一覧には主要コマンドとして載っていないため、本記事の導入手順はcodex reviewに依存させません⁷。

npm install -g @openai/codex
mkdir -p .agents/skills/codex-review
curl -L \
  https://gist.githubusercontent.com/LuD1161/84102959a9375961ad9252e4d16ed592/raw \
  -o /tmp/codex-review.claude.SKILL.md
cp /tmp/codex-review.claude.SKILL.md .agents/skills/codex-review/SKILL.md
$EDITOR .agents/skills/codex-review/SKILL.md
/codex-review

Aseem Shrey氏のGistは、もともとClaude CodeからCodex CLIを呼ぶためのSKILL.mdである⁶。したがって、Codex内で使う場合に重要なのは「公開されているSkill本文をそのまま魔法のように入れる」ことではない。同じ導入手順で配置し、実行主体をCodexに合わせて文言、対象、停止条件を調整することだ。

最低限、次の箇所は確認する。

Claude / Claude Codeを前提にした文言を、作業側Codexとレビュー側Codexの役割分担に直す
一時ファイル名が/tmp/claude-plan-...になっている場合は、Codex用の名前に直す
-m gpt-5.3-codexのようなモデル指定は、手元で使えるモデル名に合わせるか、設定ファイルのデフォルトに任せる
resumeで追跡するラウンドと、fresh sessionで最終監査するラウンドを分ける
VERDICT: APPROVED / VERDICT: REVISEなど、終了条件を文字列として固定する

実装前の計画レビューだけなら、codex-reviewだけで始められる。コミット前の差分レビューも同じ入口にしたい場合は、同じ手順でcodex-impl-reviewを追加する。

.agents/
└── skills/
    ├── codex-review/
    │   └── SKILL.md
    └── codex-impl-review/
        └── SKILL.md

mkdir -p .agents/skills/codex-impl-review
$EDITOR .agents/skills/codex-impl-review/SKILL.md

チームテンプレートがあるなら、codex-reviewと同じようにSKILL.mdを配置する。ない場合は、codex-reviewを複製して「対象をgit diff HEADにする」よう調整する。

使う側は、次のように呼び出す。

実装前の計画レビュー: 「/codex-reviewでこの実装計画をレビューして」
実装後の差分レビュー: 「/codex-impl-reviewで変更差分をレビューして」

CodexはSkillのdescriptionに合う依頼を受けたときに暗黙起動できる。 CLIやIDEでは/skillsや$による明示指定もできる⁵。追加したSkillが見えない場合は、Codexを再起動する。

どこで使うべきか¶

このセクションが答える問い：セカンドパスを足す価値が、待ち時間とtoken消費を上回るのはどこか。

証拠がなければレビューは感想に寄る

独立セッションだけを足しても、テスト、CI、ログ、UI検証、受入条件がなければレビューは感想に寄ります。セカンドパスの価値は「別セッションに聞いたこと」ではなく、成果物と証拠を狭い入力として渡すことにあります。

Codex内レビューは、すべての変更に必要ではない。小さなtypo修正やリンク修正に毎回走らせると、コストと待ち時間が上回る。

使いどころは、レビューの追加コストより見落としコストが高い変更である。

認証、権限、支払い、データ削除などの不可逆変更
設計方針を変えるリファクタリング
生成AIが広範囲に触った大きなdiff
テストは通るが、仕様との対応が不安な変更
人間レビュー前に論点を絞りたいPR

逆に、レビュー対象が曖昧なまま「全体を見て」と投げるのは避けたほうがよい。独立性は上がっても、焦点がなければ指摘は散る。レビュー対象、観点、判定形式、最大ラウンドを固定することで、セカンドパスは実務に乗る。

文脈汚染が起きやすい典型例は、次のような場面である。

実装中に採用理由を何度も説明し、その理由が会話履歴に残っている
ユーザーや作業側エージェントが「この方向でよい」と早い段階で合意している
大きなdiffで、作業側は意図を知っているが、成果物だけを見ると仕様との対応が薄い
テストが少なく、レビューが「たぶん動く」に寄りやすい

fresh sessionでも同じ盲点に寄ることはある。だから、独立レビューはlint、型検査、テスト、人間レビューの代替ではなく、それらの前に論点を絞るセカンドパスとして扱う。

既存のレビューループ記事との関係¶

Claude Code × Codexのレビューループでは、別モデルを使うことで観点差を作る。一方、Codex → Codexの独立レビューでは、同じモデルのまま文脈と役割を分ける。

両者は競合しない。

重要な変更では、まずCodex内でfresh sessionレビューを走らせ、次に別モデルやGitHub Agent HQで違う観点を当てる構成もあり得る¹。レビューは1回で終わらせるものではなく、リスクに応じて層を足すものだ。

この意味で、Codex内レビューは「自己レビュー」ではなく、作業セッションから独立したセカンドパスとして捉えるのがよい。

まとめ¶

CodexでCodexをレビューする価値は、別モデルの新鮮さではない。価値は、実装中の文脈を切り離し、成果物だけに近い入力で見直すところにある。

これは完全な客観性ではない。だが、レビューの独立性は上がる。

実務では、まずcodex-reviewやcodex-impl-reviewのようなSkillでレビュー手順を固定する。その内部でfresh session、resumeによる追跡レビュー、subagentによる観点分離を使い分ける。どの方式でも、read-only、対象diff、判定形式、終了条件を固定することが前提になる。

レビューを「もう一度聞く」ではなく、ハーネスの一部として設計することが、 Codex時代のセカンドパスである。