Claude CodeとCodex CLIを3週間、生産ラインとして並用した。specはClaude Code側で握り、プログラムはすべてCodex CLIに書かせる。

聞こえはきれいだが、実際にやると隙間だらけ。

最初の1週間は手慣れていないだけだと思う。2週目になると、同じ種類の落とし穴に何度もぶつかっていると分かる。Anthropicの公式文書はClaude Codeを語り、OpenAIの公式文書はCodex CLIを語る。どちらも単体では完全。2つを一緒にどう回すかは、ユーザーのterminal履歴に住んでいて、誰も書いていない。

以下は蓄積したメモから、最重要の6点を整理したもの。すでにClaude Codeで分身を開いていて、Codex CLIを実行役として加えたい人は、午後1-2回分を節約できる。記事には具体的なコマンドは載せない（両ツールのflagはバージョンで変わる）。概念だけを扱う。実際に再現するときは、その時点の公式文書で細部を合わせるのが最も安定する。

なぜこの分担に価値があるのか

先に結論：Claude Codeを指揮役、Codex CLIを実行役にするのが、2つのツールにとって最も気持ちよい使い方。

Claude Codeの強みは計画、審査、specがずれないように握ること、何を「完了」と呼ぶかを決めること。反応スタイルもこの層に向いており、分身を開いて別のものを見に行けるので、意思決定層に合う。

Codex CLIの強みは実行：コードを書く、refactorする、長時間連続編集する、テストを走らせる。sandbox設計のおかげで、単独で走らせやすい。

2つを重ねる：Claude Codeが上でspecを持ち、仕事を小片に切ってCodex CLIに投げる。Codexが書く → Claudeが分身でcross-family review → 通ればmerge。このループは、どちらか1つに全部任せるよりかなり安定する。

以下の6点が、この3週間で学ぶのに最も時間がかかったこと。

1. 「自動モード」は「完全に聞かない」ではない

初めてCodexに無人の自動タスクを走らせると、戻ってきたとき何も動いていないことがよくある。

logを見ると、「このファイルを修正するが、承認する？」という確認画面で止まっていた。誰も押さないので20分固まったまま。

多くの自動化ツールには似た設計がある。いわゆる「自動モード」は、実際には「必要なときはまだ聞く」という意味の場合がある。ファイル修正や特定パスへの書き込みなど敏感な操作では確認が出る。本当に無人で走らせるには、『聞かずにそのまま実行する』設定をもう一層足す必要がある。

安全境界はsandboxで守り、確認画面で守らない。確認画面が引っかかるとsession全体が止まり、半日動かない。割に合わない。

確認画面で凍りついたCodexロボットを見ているこぺんぎん

2. sandboxはデフォルトでネットワークなし

2つ目の落とし穴：Codexに新しいパッケージをインストールさせる指示を書くと、しばらくしてインストールできないと言われる。

本当の原因はパッケージマネージャーではない。Codex sandboxはデフォルトでネットワークがオフ。

理由は単純で、安全のため。ただし日常開発ではネットワークが必要なタスクが多い：パッケージのインストール、git push、第三者API呼び出し。ネットワークが必要なら明示的に開く必要があり、defaultでは使えない。

sandboxを丸ごと切って走らせれば回避もできるが、それはガードレールを外すのと同じ。安定した習慣は、各タスクの冒頭で1秒だけ「このタスクにネットワークが必要か」を考えること。必要なら開くべきflagを開く。不要ならdefaultを保つ。ガードレールを抜くより、1秒考えるほうが安全。

金色の鍵を持ち、sandbox上のネットワーク門を開けようとするこぺんぎん

3. 成功判断は複数シグナルを見る。stdout最後の一行ではない

Codexが終わった後、stdout最後の一行「OK looks good」だけを見てmergeし、何度か痛い目を見た後、複数シグナルを交差させる必要があると学ぶ。

最低限：

  1. 終了コードが0（プログラムが正常終了）
  2. 実行記録に「全ラウンド完了」イベントがある（途中で切れていない）
  3. 期待したファイルが実際にディスクへ落ちている

どれか1つでも欠けたら成功ではない。stdout最後の一行は、出力途中でbufferから押し出された最後の文字列かもしれない。「終了時のメッセージ」に見えて、実際には「見えている最後の断片」にすぎないことがある。

これらのシグナルをどう接続するかは、ツールごとのflagやバージョンで違うので、当時点の公式文書を見る。重要なのは概念：シグナルは交差させ、1本だけを見ない。

終了コード0、全ラウンド完了フラグ、ファイル書き込みの3つの成功シグナルを、こぺんぎんが虫眼鏡で確認している

4. 単発タスクには時間上限がある。超えると死ぬ

この条は最も痛かった。

大きなrefactorをCodexに投げ、指示は細かく書き、40分ほど走る見込みだった。戻るとsessionが死んでいて、logには「圧縮タスクタイムアウト」とあった。

会話が上限に近づくと、Codexは内部圧縮機構を自動起動する。処理済み部分を要約に圧縮し、新しい回合に空間を作る。問題は、圧縮自体に時間がかかること。一度タイムアウトすると、session全体が死ぬ。 resumeでも救えない。次に接続しても、固まったsessionを受け取るだけ。

信頼できる鉄則：単発タスクを長くしすぎない。 実測では25分以内がsweet spot。長いなら分割する。各段落が終わったら小さな要約（「Xをした、残りY、次はZから」）を書き、次の段落はその要約を冒頭にして新sessionで続ける。死んだsessionは捨てる。

分割の副作用は良い。各段落が短く、token消費も見積もりやすく、エラーの場所も特定しやすい。

こぺんぎんが木槌で長いタスクを25分の小段に切り、右端の小段が雷で砕けている

5. Code reviewは必ず別の家へ

Codexにcodeを書かせ、その後Codex自身に審査させると、いくつかは拾うが、漏れも多い。

書くモデルと審査するモデルが同源だと、思考の底が同じになる。自分が直前に書いたものへの許容度は、他人のものを審査するときよりかなり高い。reviewに見えて、実際はrubber stampになりやすい。

だからこの構成は「Claude Codeが上、Codexが下」になる。Codexが書いた後、diffをCodex自身には渡さず、Claudeの分身に審査させる。違うモデル家族、違うエラーパターン、違う盲点。Cross-family reviewはself-reviewよりかなり多く拾う。

安定フローは：Codexが書く → Claude Codeがdiffを取る → Claude分身でreview → 問題があればCodexに戻して修正、なければmerge。この追加review層は、肉眼で軽く見ても分からないsilent bugをよく拾う。

木のロボットがdiffを眼鏡をかけたフクロウreviewerに渡し、後ろでこぺんぎんがうなずいている

6. 3並行がsweet spot。4本目は壁に当たる

最後の1つは有料プランの利用枠に関係する。

Codexの有料プランにはrolling credit windowがある。一定時間ごとに一定の計算量が与えられる。複数worktreeを並行で走らせる（各worktreeで独立したCodex sessionを開く）と、消費量は積み上がる。

4本並行は理論上速そうだが、実際には途中で利用枠が壁に当たり、全sessionが同時に遅くなり、最後の1本はそのまま止められる。

3本がsweet spot。 有料プランでは3本並行なら30-50分のsprintをおおむね維持できる。それ以上は利用枠の回復を待つ必要がある。タスクを投げる前に「このタスクは本当に4本並行が必要か？」と問う。たいてい答えは不要。3本 + 1本を順番待ちにするだけで足りる。

3体のロボットがそれぞれ楽しく作業し、右端の4体目が倒れていて、左でこぺんぎんが心配そうに見ている

これを自分のplaybookにまとめる

この6点は自用のノート庫に整理した。各落とし穴を「いつ出会うか、なぜ起きるか、概念上どう回避するか」という形にし、さらにいくつかのテンプレート（タスク振り分け形式、cross-family reviewフロー、長いタスクの分割記録など）を添えて、将来自分が毎回考え直さなくていいようにする。

使い方は2つ：

  • 概念をそのまま使う：今詰まっている問題を見つけ、該当段落に飛んで、そのまま実行する。
  • 構造をそのまま使う：ノート庫全体をstarter kitとしてcloneし、自分の作業目録に置き、ツールバージョンに合わせて微調整する。

今後、この内容もより体系的なガイドとして順次整理し、同じように2つのツールを併用している人と失敗経験を蓄積していく。

結語

AnthropicとOpenAIは、「2社のツールを一緒に使う」チュートリアルを書いてくれない。この層は永遠にユーザー自身が触って見つける場所。見つけたものは共有できる。全員がそれぞれ一度転ぶ必要はない。

関連記事

こぺんぎんの体験談

主力workflowはClaude Code（上）+ Codex CLI（下）+ Claude分身によるcross-family review。実戦で最も効いた2つは、第一にCodex sandboxのnetwork defaultがオフなので、ネットワークが必要なタスクでは毎回開くことを覚えておく必要があること。第二に、長いタスクは本当に内部圧縮機構のタイムアウトで殺されるため、素直に分割するほうが最速だということ。OpenClaw上のmulti-agent構成は、この分担に沿って走っている。

よくある質問

Q: Claude CodeとCodex CLIをなぜ一緒に使う？1つ選べばよいのでは？

1つを選んでもよいが、分担のsweet spotは明確。Claude Codeは計画、審査、specを握り続けることが得意。Codex CLIはコーディング、refactor、長時間の連続編集が得意。上位で意思決定するものと下位で実行するものを分けるほうが、1つのツールに両方をさせるよりかなり滑らか。

Q: Codexの長いタスクは本当に死ぬ？

死ぬ。会話が長くなりすぎると、Codexは内部圧縮機構を自動起動して古い内容を収束する。この圧縮自体に時間がかかり、タイムアウトするとsession全体が死ぬ。resumeでも救えない。実務では単発タスクを25分以内に切るのが最も安定する。

Q: なぜ別のAIにcode reviewさせる必要がある？

Codexに自分が書いたcodeを審査させると、盲点が自分のpriorsに覆われる。別のモデル家族、たとえばClaudeに審査させると、訓練の土台とエラーパターンが違うため、別種の問題を拾える。このcross-family reviewはself-reviewよりsilent bugをかなり多く拾う。

— Penchan