コンテンツにスキップ

Codex Reviewを自動化する：Claude Code × Codex レビューループ実装ガイド

対象: クロスモデルのコードレビュー自動化を検討している中級〜上級開発者

この記事のポイント

  • レベル1: SKILL.md 1ファイルで即開始

    /codex-reviewコマンドでCodexレビューループが自動実行される

  • レベル2: Stop Hookで自動発火

    タスク完了時にCodexレビューが自動起動、レビュー漏れを排除

  • レベル3: パイプラインでチーム統制

    工程全体をゲート管理し、品質基準をチーム全体で強制

前回の記事では、ベンチマーク特性の違いから「Claude Codeで実装→Codexでレビュー」というクロスモデル分業が合理的であることを検証した。

しかし、この分業を手動で回すのは現実的ではない。Claude Codeで実装が終わるたびにCodex CLIを別ターミナルで立ち上げ、計画やdiffをコピペし、レビュー結果を手動で戻す——この往復を繰り返せば、クロスモデルの品質向上分を人間の手間が相殺する。

2026年2月末時点で、このレビューループを自動化するアプローチが複数の開発者から独立して公開されている。本稿ではそれらを導入コスト順に整理し、「最短で動くもの」から「チーム運用に耐えるもの」までの3段階で解説する。

前提知識：Claude CodeからCodex CLIを呼ぶ際の制約

自動化の実装に入る前に、1つの技術的制約を押さえておく必要がある。

Claude Codeのbash環境は非対話型（non-interactive）である。そのため、Codex CLIを呼び出す際はcodex execサブコマンド（非対話モード）を使うのが定石となる。codex execではTUI（対話UI）を前提とした操作——セッションピッカーやインタラクティブな承認ダイアログ——は利用できないが、-a（承認ポリシー）や-m（モデル選択）、-s（サンドボックス）などのグローバルフラグはcodex execにも伝播する1。なお、グローバルフラグはサブコマンドの後ろに配置する（例: codex exec -m gpt-5.3-codex ...）。

# レビュー用（read-only sandbox）
codex exec -m gpt-5.3-codex -s read-only \
  "Review the plan in /tmp/plan.md. End with VERDICT: APPROVED or VERDICT: REVISE"

# セッション継続（前回の文脈を保持）
codex exec resume <session-id> "Re-review the updated plan"

# stdinからプロンプトを渡す（PROMPTに - を指定）
cat /tmp/plan.md | codex exec -m gpt-5.3-codex -s read-only -

重要なのはcodex exec resumeで前回のセッションを再開できる点である。これにより、Codexは前回の指摘を覚えたまま再レビューを行い、修正が実際に反映されたかを検証できる。ただし、resumeでは-o（ファイル出力）フラグが使えないため、stdoutをキャプチャする必要がある2。

なお、codex execには--output-schemaオプションがあり、最終出力のJSON構造をスキーマで制約できる1。現時点ではVERDICT:の文字列マッチで停止条件を判定するのが主流だが、スキーマを使えば「判定＋指摘リスト＋重大度」などの構造化出力が可能になり、後述のレベル⅔の自動化への接続が容易になる。

Windows環境の注意: Codex CLIはWindowsでもPowerShellからネイティブ実行でき、Windows sandbox機能も提供されている。WSLでの運用も選択可能で、好みに応じて使い分けられる1。

レベル1：SKILL.mdを1ファイル置くだけ——/codex-review

最も導入コストが低いアプローチは、Aseem Shrey氏が公開したSKILL.md方式である2。

仕組み

.claude/skills/codex-review/SKILL.mdという1つのMarkdownファイルをプロジェクトルートに配置するだけで、Claude Codeが/codex-reviewスラッシュコマンドを認識する。起動すると以下のループが自動実行される。

  1. 計画の書き出し: Claudeが現在のコンテキストにある計画を一時ファイル（/tmp/claude-plan-<uuid>.md）に出力
  2. 初回レビュー: codex execでCodexをread-onlyサンドボックスで起動し、計画をレビューさせる
  3. 判定: CodexがVERDICT: REVISEを返した場合、Claudeが計画を修正し、codex exec resumeで同一セッションを再開
  4. 収束: VERDICT: APPROVEDが返るか、最大5ラウンドに達するまで繰り返す
Round 1: Claude writes plan → Codex reviews → VERDICT: REVISE (8 issues)
Round 2: Claude revises   → Codex re-reviews (resume) → VERDICT: REVISE (6 issues)
Round 3: Claude revises   → Codex re-reviews (resume) → VERDICT: APPROVED ✅

設計上のポイント

セッションIDによる並行安全性。 各レビューセッションにUUIDを生成し、一時ファイルパスとCodexセッションIDを紐づける。--lastフラグ（直近セッションを自動取得）は複数のClaude Codeインスタンスが同時にレビューを実行した場合に誤ったセッションを掴むため、明示的なセッションIDで管理する設計になっている2。

read-onlyサンドボックス。 Codexはコードベースを読み取ってレビューに文脈を反映できるが、ファイルの変更はできない。レビュアーが実装に手を出さないという原則が技術的に担保される。

Claudeによる「能動的な修正」。 SKILL.mdの指示には「Claude should make real improvements」と明記されている。Codexのフィードバックを単にパススルーするのではなく、Claude自身が計画を書き換えてからCodexに再提出する。これが単なるメッセージリレーとレビューループの本質的な違いである。

実績

Shrey氏の報告では、3ラウンドで14件の問題を検出した。内訳は認証モデルの欠如、シェルスクリプトのクォーティングバグ、スキーマフィールドの矛盾（statusとcolumnの状態ドリフト）、並行処理の欠如など。手動レビューゼロで仕様品質がプロダクションレベルに到達したとしている2。

導入手順

# 1. Codex CLIがなければインストール
npm install -g @openai/codex

# 2. SKILL.mdをプロジェクトに配置
mkdir -p .claude/skills/codex-review
# Gistからダウンロード、またはSKILL.mdの内容をコピー

# 3. Claude Codeで起動
/codex-review

SKILL.mdは以下のGistで公開されている。

https://gist.github.com/LuD1161/84102959a9375961ad9252e4d16ed592

なお、SKILL.md内のモデル名はgpt-5.3-codexだが、Codex CLI公式リファレンスの例ではgpt-5-codexが使われている。利用可能なモデル名は環境やサブスクリプションによって異なるため、実行時に確認が必要である。

適用場面

認証、データモデル、並行処理など、実装に数日かかる計画のレビューに向いている。バグ修正や小規模な変更には過剰であり、速度を優先するタスクにはスキップすべきとShrey氏自身が述べている2。

レベル1.5：最終監査レビューの追加——「修正ループ＋fresh session」

レベル1のSKILL.md方式には1つの構造的な弱点がある。Codexがセッションを通じて蓄積した文脈に引きずられる可能性だ。

ここで、クロスモデルレビュー自動化には2つの設計流派があることを整理しておきたい。

  • resume流派（Aseem Shrey方式）: セッションを継続し、Codexに前回の指摘を覚えさせることで「修正が実際に反映されたか」を検証する。修正の追跡性が高い反面、Codexが一度「些細」と判断した問題を再度取り上げにくくなるバイアスが生じうる2。
  • fresh session流派（Kim Major方式）: 毎回新規セッションで独立性を担保し、レビュアーが前回のコンテキストに引きずられない設計。ただし修正の追跡は人間側の責任になる。Major氏は「独立レビューは、許容するコンテキストの範囲を定義して初めて意味がある」という原則を提示している3。

本稿が提案するのは、この2流派のハイブリッドである。修正ループ中はresumeで追跡性を確保し、ループ収束後にfresh sessionで最終監査を走らせる。修正の検証と全体俯瞰の独立性を両立させる設計意図である。

これを補う方法はシンプルで、修正ループが収束した後にfresh session（新規セッション）で最終監査レビューを1回だけ走らせる。

実装

SKILL.mdのStep 7（最終結果の提示）の前に、以下のステップを挟む。

# 修正ループ完了後、新規セッションで最終監査
codex exec \
  -m gpt-5.3-codex \
  -s read-only \
  -o /tmp/codex-audit-${REVIEW_ID}.md \
  "You are performing a FINAL AUDIT of an implementation plan.
This plan has already been through iterative review. Your job is NOT to repeat prior feedback,
but to check for:
1. Systemic issues that incremental reviews might miss
2. Consistency across the entire plan (naming, error handling patterns, state management)
3. Anything that only becomes visible when reading the plan as a whole

The plan: $(cat /tmp/claude-plan-${REVIEW_ID}.md)

End with: AUDIT: PASS or AUDIT: CONCERNS (with specific items)"

ポイントは3つある。

プロンプトの役割を変える。 修正ループのCodexは「個別の問題を指摘するレビュアー」だが、最終監査のCodexは「計画全体の一貫性を確認する監査役」として機能させる。プロンプトで「incremental reviewsが見落とす全体像」を明示的に要求する。

新規セッションであること自体が価値。 resumeではなくfresh sessionを使うことで、Codexは計画を白紙の状態から読む。修正ループ中に徐々に形成された「これは許容範囲」というバイアスが排除される。

判定を変える。 修正ループのVERDICT: APPROVED/REVISEと最終監査のAUDIT: PASS/CONCERNSを意図的に分けることで、Claudeが処理フローを明確に区別できる。

Major氏の知見として、exit conditionが曖昧だとループが終わらないという実運用上の問題がある3。最終監査は1回限り（ループしない）とし、CONCERNSが出た場合は人間に判断を委ねる設計が安定する。

レベル2：Stop Hookで自動発火——claude-review-loopプラグイン

レベル1は「ユーザーが/codex-reviewを明示的に起動する」必要がある。つまり、レビューを忘れればスキップされる。

Hamel Husain氏が公開したclaude-review-loopプラグインは、Claude CodeのStop Hookを利用して、この問題を解消している4。

仕組み

Stop Hookとは、Claude Codeがタスクを完了してセッションを終了（stop）しようとするタイミングで割り込む仕組みである。ブロック方法は2系統ある9。

  • (A) exit code 2方式: hookスクリプトがexit code 2を返すと、Claude Codeの終了が強制的にブロックされる。この場合、stdoutやJSON出力は無視され、stderrの内容がClaudeへのフィードバックとして渡される。
  • (B) JSON decision方式: exit code 0で終了し、stdoutに{"decision":"block","reason":"..."}を返す。構造化された制御が可能で、reasonフィールドの内容がClaudeへのフィードバックになる。

claude-review-loopは(B)のJSON decision方式を採用しており、stop-hook.shが{"decision":"block", ...}をstdoutに出力してexit 0で制御している4。

1. /review-loop でタスクフェーズを開始
2. Claudeがタスクを完了 → セッション終了を試みる
3. Stop Hookがインターセプト → Codexを自動起動
4. Codexが最大4つの並列サブエージェントでレビュー
5. レビュー結果を reviews/review-<id>.md に書き出し
6. Claudeにフィードバックを戻し、修正フェーズへ移行

レベル1との違い

起動が自動。 /review-loopでタスクフェーズを開始すれば、以降のレビューはClaude Codeが「作業完了」と判断するたびに自動で走る。「レビューを忘れる」という人的エラーが排除される。

並列レビュー。 プロジェクトの種類に応じて最大4つのCodexサブエージェントが並列で走る。セキュリティ、パフォーマンス、設計整合性など、異なる観点を同時にカバーできる。

状態管理の永続化。 レビューの状態は.claude/review-loop.local.mdで追跡され、レビュー結果はreviews/review-<id>.mdに保存される。タイムスタンプ、Codexのexit code、経過時間がログに記録される4。

導入手順

# Claude Codeプラグインとしてインストール
claude plugin marketplace add hamelsmu/claude-review-loop
claude plugin install review-loop@hamel-review

# タスク開始
/review-loop

# キャンセルする場合
/cancel-review

留意点

デフォルトの権限設定に注意。 claude-review-loopのデフォルト設定では、Codexの実行フラグに--dangerously-bypass-approvals-and-sandboxが使われている4。これはサンドボックスと承認プロセスの両方をスキップするフラグであり、Codex公式でも「外部で隔離された環境でのみ使用すべき」と強い注意書きがある1。本番環境やチーム共有のリポジトリで使う場合は、環境変数REVIEW_LOOP_CODEX_FLAGSを--sandbox read-onlyまたは--sandbox workspace-writeに上書きすることを推奨する。どうしてもフルアクセスが必要な場合は、使い捨てコンテナやCI/CDの隔離ランナー上で実行すべきである。

Stop Hookの発火タイミング。 Stop Hookのタイムアウトは900秒（15分）に設定されている。Codexのレビューが長引く場合はhooks/hooks.jsonで調整が必要である4。

Nick Tune氏の分析が指摘するように、Stop Hookは必ずしも理想的なタイミングで発火するわけではない5。Claudeが要件の確認のために一時停止した場合にもHookが走る可能性があり、未完成の状態でレビューが始まるケースがある。Claudeがコミットしてからstopした場合は、レビュー対象の差分が不明確になる。Tune氏は「CodeReadyForReviewのような、開発ワークフローのセマンティクスに合ったHookが欲しい」と述べている5。

無限ループ対策。 Stop hookの入力にはstop_hook_activeフラグが含まれる9。hookスクリプト内でこのフラグを確認し、すでにhookが実行中の場合は再帰的にブロックしないガードを入れるべきである。これを怠ると、レビュー→ブロック→レビュー→ブロックの無限ループに陥る可能性がある。

レベル3：マルチAIパイプライン——チーム運用と統制

レベル1〜2は「個人開発者が自分のワークフローに組み込む」ことを想定している。チームで運用し、レビュー基準を統一し、工程を強制する場合は、パイプライン化が必要になる。

claude-codexプラグイン（Z-M-Huang氏）

Claude（planner + coder）とCodex（reviewer）の分業をパイプラインとして実装したもの6。requirements-gatherer → planner → plan-reviewer → implementer → code-reviewerという工程をスクリプトで管理し、全レビュアーが承認するまでループする。

チーム運用の観点からの評価：

強みは工程の標準化と強制力にある。レビューを「個人の習慣」から「パイプラインのゲート」に昇格させることで、チーム全員が同じ品質基準を通過する。

一方でライセンスに注意が必要である。GPL-3.0に加えて帰属表示（Attribution）の追加条項が冒頭に記載されている6。企業の法務部門が許容するかは事前確認が必須だろう。また、エージェントを順次実行するため、単純なタスクでもパイプライン全体が走る。前回の記事で検証したように、タスクの複雑性がオーケストレーションコストを上回らない場合、このアプローチは過剰になる。

Claude-Code-Workflow（catlog22氏）

JSON駆動のマルチエージェントフレームワークで、Codex・Gemini・Qwenなど複数のCLIツールを統合的にオーケストレーションする7。READMEでは/workflow:lite-plan、/workflow:plan、/workflow:brainstormなどのスキル群と、ccwコマンドによる導入が定義されている。タスクの複雑性に応じてスキルを選択する設計で、単純なタスクから複雑なマルチロール協調まで対応する。

Codex単独のレビューにとどまらず「GeminiとCodexで協調レビュー」「利用可能な全CLIでアーキテクチャ分析」といったマルチモデルの並列実行をサポートしている点が特徴的である。

GitHub Agent HQ

2026年2月にGitHubが公開したAgent HQは、プラットフォームレベルでのクロスモデル統合を実現している8。リポジトリ内でCopilot・Claude・Codexの3エージェントを直接起動でき、同一issueに対して複数のエージェントを割り当てて結果を比較できる。PRコメントで@Claudeや@Codexをメンションするだけで、フォローアップ作業を指示できる。

ローカルのCLI自動化とは異なり、GitHub上のCI/CDやコードレビューワークフローにネイティブに統合される点で、チーム運用との親和性が最も高い。ただし、Copilot Pro+またはCopilot Enterpriseサブスクリプションが必要であり、現時点ではパブリックプレビュー段階にある。

3段階の選択基準

レベル1: SKILL.mdレベル2: Plugin + Hookレベル3: パイプライン
導入コストファイル1つプラグインインストールフレームワーク導入
自動化度手動起動 / ループは自動タスク完了時に自動発火工程全体を自動管理
並列レビューなし（逐次）最大4サブエージェントモデル・観点の並列化
チーム統制なし（個人の習慣）ログ永続化ゲート強制・基準統一
適用規模個人 / 小規模チーム個人 / 中規模チーム中〜大規模チーム
トークンコスト低〜中中高

選択の指針はシンプルである。 まずレベル1のSKILL.mdで「クロスモデルレビューが自分のプロジェクトに効くか」を検証する。効果が確認できたらレベル2でレビュー漏れを排除する。チーム全体で品質基準を統一する段階になって初めてレベル3を検討する。

前回の記事で引用したMicrosoft Cloud Adoption Frameworkの原則——「単一エージェントで価値を証明してからマルチエージェント連携に投資すべき」——がここでもそのまま当てはまる。

現在地と今後

本稿で紹介した自動化アプローチのうち、SKILL.md方式とPluginは2026年2月時点で実用段階にある。パイプライン系は発展途上で、特にStop Hookの挙動の不安定さやチーム固有のレビュー基準の組み込みといった課題が残っている。

2026年3月30日、OpenAIが公式プラグイン codex-plugin-cc をリリースし、状況が変わった。スラッシュコマンド1つでCodexレビューを実行できるため、本稿のDIYアプローチよりも導入コストが低い。一方、レビューループの停止条件やカスタマイズ性では本稿の手法が優る。公式プラグインとの使い分けについては「OpenAIが公式でClaude Codeプラグインを公開 ― codex-plugin-ccが意味すること」を参照。

補足すると、codex-plugin-ccは本稿で紹介したAseem Shrey氏のSKILL.mdがそのまま公式化されたものではない。OpenAIが公開した別実装であり、Claude Code内からローカルのCodex CLI / Codex app serverを呼び出す公式プラグインである10。役割としてはレベル1の「手動起動レビュー」とレベル2の「Stop Hookによるreview gate」の一部を公式にカバーする。

なお、本稿はClaude Codeで実装し、Codexをレビュー役にするクロスモデル運用を扱っている。 Codexを主作業エージェントにし、別Codexセッションやsubagentでレビューする場合は、 CodexでCodexをレビューする：独立セッションで作るセカンドパスで整理している。

導入はClaude Code内で以下を実行する。

/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/reload-plugins
/codex:setup

通常レビューは/codex:review、設計判断やリスクを強めに疑うレビューは/codex:adversarial-reviewを使う。READMEでは、/codex:setup --enable-review-gateでStop Hookベースのreview gateを有効化できるが、長いClaude/Codexループになり利用上限を消費しやすいので、監視できるセッションでだけ使うよう注意されている10。

方向性は明確である。手動でエージェントを行き来させる段階は終わりつつあり、「計画→実装→レビュー→修正」のサイクル全体をエージェント間のプロトコルとして定義するアプローチが急速に整備されている。GitHub Agent HQのような上位プラットフォームの参入は、この流れをさらに加速させるだろう。

まずはSKILL.md 1ファイルから始めてみてほしい。

この記事をポスト リンクをコピー

関連記事

出典

  1. OpenAI Developers, "Codex CLI: Command Line Options"（グローバルフラグ、codex exec、--output-schema、Windows対応状況）; "Non-interactive Mode" ↩↩↩↩

  2. Aseem Shrey, "I Made Claude and Codex Argue Until My Code Plan Was Actually Good", February 20, 2026; SKILL.md on GitHub Gist ↩↩↩↩↩↩

  3. Kim Major, "AI-Assisted Coding: Automating Plan Reviews with Claude Code and Codex for Higher Quality Plans", January 18, 2026（Flow Specialty社） ↩↩

  4. Hamel Husain, "claude-review-loop"（Claude Code plugin: automated code review loop with Codex） ↩↩↩↩↩

  5. Nick Tune, "Auto-Reviewing Claude's Code", Medium, 2026（O'Reilly Radarでも紹介） ↩↩

  6. Z-M-Huang, "claude-codex"（Multi-AI orchestration plugin for Claude Code、GPL-3.0＋Attribution追加条項） ↩↩

  7. catlog22, "Claude-Code-Workflow"（JSON-driven multi-agent framework） ↩

  8. GitHub Blog, "Pick your agent: Use Claude and Codex on Agent HQ", February 2026 ↩

  9. Anthropic, "Hooks reference — Claude Code Docs"（Stop hook、exit code 2、JSON decision control、stop_hook_active） ↩↩

  10. OpenAI, "codex-plugin-cc"（Claude Code内からCodexを使う公式プラグイン。/codex:review、/codex:adversarial-review、review gate、ローカルCodex CLI認証の利用について説明） ↩↩