公開日: 2026.08.21 　|　更新日: 2026.08.21

Claude CodeからCodexをサブエージェントとして使う方法

今回は、Claude Codeのサブエージェント機能を使って、実装作業をOpenAIのCodex CLIに委託する方法を紹介します。Claude Codeが計画とレビューを担当し、コードを書く作業だけをCodex（GPT-5.6 Luna、reasoning effort max）に渡す構成です。私はこの構成を7月末から実際のプロジェクトで運用しており、手順と注意点はその実体験に基づいています。

利用環境

macOS 26.3.1（MacBook Air M4）
Claude Desktop（プラン：MAX 5x）
ChatGPT（プラン：ChatGPT Plus）

この記事のターゲット

Claude CodeとCodex CLIの両方を契約していて、組み合わせて使いたい方
エージェントが書いたコードを、別のAIにレビューさせたい方
数十分かかる実装タスクを非同期で回したい方

この構成でできること

先に、何のためにやるのかを整理しておきます。

1つ目は、実装とレビューの分離です。同じモデルに実装とレビューの両方をさせると、自分の答案を自分で採点する形になり、同じ見落としを同じように見落とします。実装をCodex、レビューをClaudeに分けると、レビューが別の会社のモデルによる独立した視点になります。

2つ目は、契約枠の分散です。実装は重い推論を長時間回すので、枠の消費が大きい作業です。これをChatGPT Plus側の枠に逃がすと、Claude MAX側の枠はレビューと計画に使えます。リスクの高い変更に対してOpusのレビューを4ラウンド重ねたことがありますが、これは実装で枠を使っていないからできることです。

はっきり言って、現状のClaudeのSonnet5、Opus5、ましてやFableで実装を行う場合のトークン効率は悪く、私の運用では、MAX 5xの枠をわずか２〜３日で使い切ってしまう状態でした。対してChatGPT Plusのプランではgpt-5.6-luna（effort MAX）のトークンあたりの料金が値下げされたのも相まって、私がやりたい実装の程度であれば十分実行力があったので、今回の作業分担に至った、という経緯があります。

3つ目は、待ち時間の解放です。Codexへの委託は1本あたり10〜40分かかりますが、バックグラウンドで走らせている間、Claude Code側では次のタスクの計画やレビューを進められます。

なお、この分担は「Codexの方が実装が上手いから」ではありません。両者の実装力を比較する計測はしていないので、そこは根拠を持って言えません。目的はあくまで独立性と枠の分散です。

1. Codex側にプロファイルを作る

まず、実装役として呼び出すときの設定をCodex CLIのプロファイルとして固定します。

ポイントは2つあります。sandbox_mode は workspace-write にして、danger-full-access は使いません。対象プロジェクトのディレクトリだけ書き換えられれば十分です。approval_policy = "never" は、実行中の承認プロンプトで止まらないための設定です。数十分の非同期実行が前提なので、途中で人間の承認を待つ構成にはしません。

あわせて ~/.codex/AGENTS.md に、コーディング規約や「勝手にコミットしない」といった恒常的な指示を書いておきます。実装役のCodexが毎回読む唯一の指示書になります。

2. Claude Code側にサブエージェント定義を置く

次に、.claude/agents/ にCodexを呼び出すためのサブエージェント定義を作ります。

実装指示を受け取ったら、以下の形式でCodexを起動する。自分ではファイルを編集しない。sed -i、ヒアドキュメント、teeによるシェル経由の編集も禁止。

見慣れないのは disallowedTools: Write, Edit だと思います。これは、このサブエージェント自身からファイル編集の権限を剥奪する設定です。

なぜ委託役から編集権を奪うのかというと、奪わないと守られないからです。「実装はCodexに任せる」と規約に書いても、作業が詰まってくると、Claudeが「これくらい自分で直した方が早いのでは」、と考えて実装を始めてしまう場合があります。権限ごと外しておけば、ファイルを変更できるのはCodexのプロセスだけ、という状態が心がけではなくツールの仕組みで保たれます。

レビュー用には、読み取り専用（read-only）のサブエージェントを別に定義します。標準レビューはSonnet、リスクの高い変更向けにはOpusを指定した深掘り版、という2段構えにしておくと、変更の重さでレビューの厚さを変えられます。

3. 発注プロンプトを書く

委託の質は、Codexに渡す指示文でほぼ決まります。私は事故のたびに項目を増やして、いまは次の内容を必ず含めています。

作業ディレクトリの絶対パスとブランチ名
コミットはしないこと（コミットの権限はClaude Code側が持つ）
触ってはいけないファイル・モジュールの列挙
検証コマンドと期待値（基準となるテスト数、スキップ数まで書く）
設計を変えるような曖昧さに当たったら、進めずに止まって報告すること
参照させる列挙型（enum）や関数名は、発注前にgrepで実在を確認しておくこと

最後の項目は失敗が由来です。存在しない列挙型の名前を指示に書いてしまい、Codexは指示どおり探して、見つからないと報告して止まりました。この場合、悪いのはCodexではなく指示を書いた側です。発注書のミスによる停止は、実装の失敗として数えないようにしています。

4. 実行して、完了を確認する

codex exec は体感10〜40分かかるため、フォアグラウンドで待つとClaude Codeのコマンドタイムアウトに引っかかります。バックグラウンドで起動してログをファイルに逃がし、プロセスの終了を待ってから結果を見に行く形にします。

ここで大事なのは、プロセスの終了を完了と見なさないことです。何度か、プロセスが消えて完了だと思って差分をを確認させても成果物がゼロだったことがあります。終了後は必ず git status で成果物の存在を確かめ、指定した検証コマンドをClaude Code側で実行し直します。「テストが通りました」というCodexの報告だけで先に進まない、が原則です。

ちなみに、codex exec の出力の先頭には model: と reasoning effort: が表示されます。プロファイルが効かないまま実行して事故ることがあるので、毎回ここを目視で確認するのがおすすめです。

注意点

運用してみて分かった注意点を挙げておきます。

サンドボックス内では、ネットワークやファイル書き込みが必要なテストが権限エラーで落ちます。これは実装の失敗ではないので、検証はサンドボックスの外で実行し直した結果を正とします
テストが通っていても、画面まわりは壊れていることがあります。私の場合、テスト全通過のUI変更を実際にブラウザで操作したら、不具合が3つ見つかりました。UI変更だけは自分の目で確認してから完了にしています
Codexのサンドボックスは書き込みと通信を遮断できますが、ローカルファイルの読み取りは止められません。読まれて困るものがある環境では、委託の対象から外す判断が必要です
CodexをMCPサーバーとして接続する方法もありますが、管理側のMCP設定が動的なサーバー定義をブロックする環境では使えません。私の環境がまさにそれで、この記事のCLI方式はそのフォールバックでもあります

設定するファイルは、Codexのプロファイル、AGENTS.md、サブエージェント定義の3つだけで、構成そのものは小さくまとまります。実装を任せている間に計画とレビューを進める感覚は、一度体験すると戻れないものがあります。ぜひ試してみてください。