Codex CLI を用いたクロスモデルコードレビュー

codex バイナリを直接使用したクロスモデル検証。Claude がコードを書き、Codex がレビューします。異なるアーキテクチャ、異なるトレーニング分布、自己承認バイアスなし。

核心的な洞察: 単一モデルの自己レビューは体系的に偏っています。クロスモデルレビューは異なるバグクラスを検出します。なぜなら、レビュアーは著者とは根本的に異なるブラインドスポットを持つからです。

このスキルの読み方: 以下のパターンと判断木はガイドラインです。フィットしたものを選択し、必要に応じてブレンドしてください。⚠️ でマークされたルールは異なります。それらは手続的な儀式ではなく、実際の codex CLI の動作です。スコープフラグを省略すると本当にハングしますし、tail にパイプすると本当に出力が失われます。⚠️ ルールをツールに関する事実として扱い、ワークフローに関する意見としてではなく扱ってください。

前提条件: codex CLI がインストールされ、認証されている必要があります。codex --version で確認してください。ユーザーのデフォルト設定は ~/.codex/config.toml に格納されます。それらを尊重してください。

方向: Claude → Codex のみ。双方向スキル (Codex → Claude も処理し、yield_time_ms と可変長フラグの claude -p の落とし穴を含む) については、代わりに /hyperskills:cross-model-review を使用してください。

---

⚠️ 交渉の余地がないルール: 常に codex review にスコープフラグを渡す

スコープなしの裸の codex review は失敗の #1 の原因です。ハングするか、100KB 以上のブロブ出力を生成します。正確に 1 つのスコープフラグを指定してください:

レビュー対象	コマンド
main 以降のブランチ	codex review --base main
単一コミット	codex review --commit <SHA>
ワーキングツリー (未ステージ)	codex review --uncommitted

このトリオ以外のもの (仕様書、単一ファイル、カスタムペルソナ、焦点を絞ったパス) については、裸の codex review ではなく、明示的なスコープをプロンプトに含める codex exec "PROMPT" を使用してください。

出力が約 100KB を超える場合、差分は 1 回のパスには大きすぎます。コミットごとに分割するか、より狭いプロンプト ("エラーハンドリングのみをレビュー") で codex exec を使用してください。

---

⚠️ 出力をファイルにキャプチャ: tail にパイプしない

レビューを | tail -N にパイプしないでください。3 つの失敗モード:

1. パイプは EOF まで バッファリングします。 tail はパイプ全体を読み込んでから出力を生成するため、codex が終了するかタイムアウトするまでエージェントは何も受け取りません。進行状況信号がありません。
2. レビューは判定を上部ではなく下部に置きます。 調査結果は重大度でソートされます (BLOCKER が最初)。そのため tail -300 はちょうど必要な部分をカットします。
3. ファイルなら人間がリアルタイムで進行状況を監視できます。 別のターミナルで tail -f /tmp/review.txt を実行すると、エージェント呼び出しと完全に独立してリアルタイムでレビューをストリーミングできます。

正しいパターン: 競合しないファイル名を選択し、リダイレクト、その後それを読み戻します。

# mktemp なので、並列/反復レビューが互いに上書きしません。
# スコープをスラッグに焼き込みます。tail -f で自己説明的になります。
out=$(mktemp -t codex-review-pre-pr.XXXXXX) && echo "$out"

codex review --base main > "$out" 2>&1
codex exec --sandbox read-only "PROMPT" > "$out" 2>&1

mktemp が手元にない場合: out=/tmp/codex-review-$$-$(date +%s).txt。リダイレクト前にパスをエコーします。人間が tail -f を実行するときどこを見るか知るために。終了後、ファイルを Read (または cat) します。ターンをまたいで永続化し、再実行する代わりに再度読むことができます。

---

Codex を呼び出す 2 つの方法

モード	コマンド	最適な用途
codex review	優先度付けされた調査結果を持つ構造化された差分レビュー	PR 前レビュー、コミットレビュー、WIP チェック
codex exec	完全なプロンプト制御を備えた自由形式の非インタラクティブな深掘り	セキュリティ監査、アーキテクチャ、焦点を絞った調査、仕様書

スコープフラグ (codex review のみ)

フラグ	目的
--base <BRANCH>	ベースブランチに対して差分を取得
--commit <SHA>	特定のコミットをレビュー
--uncommitted	ワーキングツリーの変更をレビュー

サンドボックス & 使いやすさフラグ (両モード)

フラグ	時期
--sandbox read-only	レビュー作業のデフォルト、書き込みなし
--sandbox workspace-write	レビュー + 提案された修正を適用
--full-auto	--ask-for-approval never --sandbox workspace-write の別名
--dangerously-bypass-approvals-and-sandbox	最後の手段。明示的なユーザーリクエストのみ
-C <DIR> / --cd <DIR>	cd なしで別のワークツリーで実行
--skip-git-repo-check	リポジトリディレクトリ以外から実行
--add-dir <DIR>	別のパスへの読み込みアクセスを拡張
--ephemeral	ワンショットセッション、永続化なし
--json / --output-last-message <FILE>	構造化された出力をファイルにキャプチャ
-c model_reasoning_effort="xhigh"	仕様書/RFC レビューのみ (努力ポリシーを参照)

努力オーバーライドポリシー

レビュー対象	努力フラグ
コード (コミット / 差分 / PR / WIP)	なし, ~/.codex/config.toml に従う
仕様書 / RFC / 設計書	-c model_reasoning_effort="xhigh"

仕様書は差分よりも高リスクです。微妙なアーキテクチャのミスは最終的な実装全体に複合します。コード差分はより小さなスコープであり、ユーザーの設定された努力で十分です。

決して --model、-m、または -c model= でモデル自体をオーバーライドしないでください。ユーザー設定が権威です。

---

レビューパターン

パターン 1: PR 前フルレビュー (デフォルト)

PR を開く前の標準的なレビュー。重要でない変更でも使用します。

ステップ 1、構造化レビュー (正確性 + 一般的な問題をキャッチ):
  codex review --base main

ステップ 2、セキュリティ深掘り (コードが認証、入力処理、API に触れる場合):
  codex exec "<references/prompts.md からセキュリティプロンプト>"

ステップ 3、調査結果を修正、その後再度レビュー:
  codex review --base main

パターン 2: コミットレベルレビュー

各重要なコミット後のクイックチェック。

codex review --commit <SHA>

パターン 3: WIP チェック

開発の途中で未コミットの作業をレビュー。それらが組み込まれる前に問題をキャッチします。

codex review --uncommitted

パターン 4: 焦点を絞った調査

特定の懸念点 (エラーハンドリング、同時処理、データフロー) に対する手術的な深掘り。

codex exec --sandbox read-only \
  "あなたはシニア <DOMAIN> エンジニアです。main と HEAD の間の変更で <CONCERN> を分析してください。
   各問題について: ファイルと行番号を引用し、リスクを説明し、具体的な修正を提案してください。信頼度閾値: 0.7。"

パターン 5: 仕様書 / RFC レビュー

コードが書かれる前に、散文 (マークダウン設計書) をレビュー。

codex exec -c model_reasoning_effort="xhigh" --sandbox read-only \
  "あなたはシニアスタッフエンジニアであり、<PATH> の率直な実装前レビューを行っています。
   著者は鋭い、感情的でない分析を望んでいます。各調査結果について:
   重大度 (BLOCKER / HIGH / MEDIUM / LOW)、信頼度 (>= 0.7 のみ)、場所
   (ファイルパス + セクション見出し)、問題、具体的な修正。
   最後に 1 段落の go/no-go 判定で終わってください。"

パターン 6: 単一ファイル / 焦点を絞ったパスレビュー

完全な差分ではなく、1 つのファイルまたはディレクトリをレビュー。

codex exec --sandbox read-only \
  "<PATH> を <CONCERN> についてのみレビューしてください。スタイルと使いやすさはスキップしてください。
   実際の問題がない場合は PASS を返してください。そうでなければ、
   file:line 証拠を含む簡潔な FAIL 調査結果。"

パターン 7: Ralph ループ (実装 → レビュー → 修正)

反復的な品質強制。3 回の反復が実用的な上限です。それ以上は収益減少が始まり、実際のバグを修正するのではなく調査結果を再度論争し始めます。

イテレーション 1:
  Claude → 機能を実装
  codex review --base main → 調査結果
  Claude → 重大/高い調査結果を修正

イテレーション 2:
  codex review --base main → 修正を検証 + 残存するものをキャッチ
  Claude → 残存する問題を修正

イテレーション 3 (最終):
  codex review --base main → クリーンまたはトレードオフを受け入れ

---

マルチパス戦略

徹底的なレビューは 1 つのあいまいなパスではなく、複数の焦点を絞ったパスから恩恵を受けます。単一パスは次元全体に注意を散らし、それぞれで浅い調査結果を生成します。各パスは特定のペルソナと懸念領域を取得します。

パス	焦点	モード
正確性	バグ、ロジック、エッジケース、競争状態	codex review
セキュリティ	OWASP Top 10:2025、インジェクション、認証、シークレット	codex exec とセキュリティプロンプト
アーキテクチャ	結合、抽象化、API の一貫性	codex exec とアーキテクチャプロンプト
パフォーマンス	O(n²)、N+1 クエリ、メモリリーク	codex exec とパフォーマンスプロンプト

パスを順序立てて実行してください。パス間で重大な調査結果を修正し、ノイズの複合を避けてください。

変更サイズ	戦略
< 50 行、単一の懸念	単一 codex review
50-300 行、機能作業	codex review + セキュリティパス
300+ 行またはアーキテクチャ変更	フル 4 パス
セキュリティに敏感 (認証、支払い、暗号化)	常にセキュリティパスを含める

---

判断木: どのパターン?

digraph review_decision {
    rankdir=TB;
    node [shape=diamond];

    "成果物は?" -> "コード (差分)" [label="git 変更"];
    "成果物は?" -> "仕様書 (マークダウン)" [label="設計書"];
    "成果物は?" -> "単一ファイル/ディレクトリ" [label="焦点を絞った"];

    node [shape=box];
    "コード (差分)" -> "タイミングは?" [shape=diamond];
    "タイミングは?" -> "コミット前" [label="作成中"];
    "タイミングは?" -> "PR 前" [label="ブランチ準備完了"];
    "タイミングは?" -> "コミット後" [label="今コミットされたばかり"];
    "タイミングは?" -> "調査中" [label="特定の懸念"];

    "コミット前" -> "パターン 3: WIP チェック";
    "PR 前" -> "どのくらいの大きさ?" [shape=diamond];
    "コミット後" -> "パターン 2: コミットレビュー";
    "調査中" -> "パターン 4: 焦点を絞った調査";

    "どのくらいの大きさ?" -> "パターン 1: PR 前レビュー" [label="< 300 行"];
    "どのくらいの大きさ?" -> "フルマルチパス" [label=">= 300 行"];

    "仕様書 (マークダウン)" -> "パターン 5: 仕様書レビュー";
    "単一ファイル/ディレクトリ" -> "パターン 6: 焦点を絞ったパスレビュー";
}

---

プロンプトエンジニアリングヒューリスティック

これらはレビュー信号の品質を確実に向上させます:

1. ペルソナを割り当てます。 「セキュリティをレビュー」よりも「シニアセキュリティエンジニア」が優れています。
2. スキップすることを指定してください。 「フォーマット、ネーミングスタイル、わずかなドキュメントのギャップをスキップ」は自転車小屋を防ぎます。
3. 信頼度スコアを要求 し、>= 0.7 の調査結果にのみ対応します。
4. ファイル:行の引用を要求してください。 場所のない曖昧な調査結果は実行可能ではありません。
5. 具体的な修正を求めてください。 「これは問題です」ではなく「具体的な修正を提案してください」。
6. 1 つのドメインをパスごと。 セキュリティのみ、アーキテクチャのみ。
7. 判定を要求してください。 「判定: パッチは正しい / 正しくない」または「go / no-go」。

すぐに使えるプロンプトテンプレートは references/prompts.md にあります。

---

アンチパターン

アンチパターン	なぜ失敗するか	修正
裸の codex review (スコープフラグなし)	ハングするか、100KB 以上のブロブ出力を生成します。	常に --base <ref>、--commit <SHA>、または --uncommitted を渡します。
codex review 出力 > 100KB	差分が 1 つのパスには大きすぎます。	コミットごとに分割するか、より狭いプロンプトで codex exec を使用してください。
timeout 30 codex review	レビューは正当に 30 秒～5 分かかります。	タイムアウトなし、または timeout 300 最小。
codex exec "PROMPT" | tail -300 または codex review ... | tail -N	パイプは EOF まで バッファリング (進行状況なし); 要約/判定をカット (通常上部付近); フルレビューをエージェントコンテキストにダンプ	ファイルにリダイレクト: ... > /tmp/review.txt 2>&1、その後 head、rg severity、sed-by-range。人間は別途 tail -f できます。
「このコードをレビュー」 (具体性なし)	曖昧、自転車小屋を生成します。	ペルソナを持つ特定のドメインプロンプト。
すべてのための単一パス	コンテキスト散漫、すべての次元で浅い。	1 つの懸念を持つパスごとのマルチパス。
自己レビュー (Claude が Claude のコードをレビュー)	体系的なバイアス、モデルは自分のパターンを承認します。	クロスモデル: Claude が書き、Codex がレビュー。
信頼度閾値なし	ノイズが信号を泛濫させます、0.3 信頼度は時間を無駄にします。	>= 0.7 信頼度のみに対応。
レビューのスタイルコメント	LLM はデフォルトで自転車小屋をします。	「スキップ: フォーマット、ネーミング、マイナードキュメント」。
> 3 回のレビュー反復	収益減少、ノイズ増加、オーバーベーク。	3 で停止。トレードオフを受け入れます。
プロジェクトコンテキストなしでレビュー	コードベースから切り離された汎用アドバイス。	リポジトリルートから実行。
codex の周りの MCP ラッパー	CLI バイナリ上の不要な間接参照。	Bash 経由で codex を直接呼び出します。
--model / -m / -c model= のハードコード化	ユーザー設定をオーバーライド; 古いモデル名。	~/.codex/config.toml に従います。
ルーチンコードレビューの努力オーバーライド	トークンを無駄、ユーザーデフォルトを無視。	-c model_reasoning_effort="xhigh" は仕様書レビューのみ。
純粋なレビューのための --full-auto	レビューが必要としていない書き込みアクセスを付与。	レビューには --sandbox read-only; --full-auto は修正を適用するときのみ。

---

このスキルが何でないか

• 人間レビューの代替ではありません。 クロスモデルレビューはバグをキャッチしますが、製品方向や UX を評価することはできません。
• リンターではありません。 フォーマットやスタイルに Codex レビューを使用しないでください。
• 完全ではありません。 5～15% の誤検知率は正常です。調査結果をトリアージしてください。
• 自己承認用ではありません。 ポイント全体はクロスモデル検証です。Claude が Claude のコードをレビューするために使用しないでください。

参照

すぐに使えるプロンプトテンプレートについては、references/prompts.md を参照してください。