Claude CodeとCodex CLIの併用ワークフロー実践ガイド

Claude CodeとCodex CLIを併用する場面とは

Claude CodeとCodex CLIはどちらもターミナルで動く自律型のコーディングエージェントです。片方をもう片方の代わりに選ぶという比較記事は既にありますが、実際の開発現場では「普段はClaude Codeで、特定の作業だけCodex CLIに振る」という併用が起きやすい構成です。

併用が発生する典型的な理由は2つあります。1つはチームの一部がChatGPTのサブスクリプションを、別の一部がClaudeのサブスクリプションを既に契約しているケース。もう1つは、CI環境や特定のタスク種別で、片方のCLIの挙動(サンドボックスのデフォルトや承認モデル)がより合う場合です。

この記事が扱うのは「どちらを選ぶか」ではなく、両方を同じリポジトリで安全に動かす構成です。ツール単体の選定基準はClaude Code vs Cursor vs Codex CLIにまとめてあります。

役割分担の基本形 — どちらに何を任せるか

併用を破綻させないコツは、同じタスクに両方を同時に当てないことです。役割の境界を先に決めておくと、後述の設定衝突や二重承認の問題が起きにくくなります。

この表は固定ルールではなく出発点です。実際にはチームの契約状況(誰がどちらのサブスクリプションを持っているか)が、技術的な向き不向きより優先されることも珍しくありません。

同じリポジトリで設定ファイルを衝突させない構成

両CLIは指示ファイルも設定ファイルも別建てです。同じ役割の設定を別ファイルに二重管理するという前提を最初に共有しておかないと、「Claude Codeにだけ伝えたルールがCodexに伝わっていない」という食い違いが起きます。

CLAUDE.mdとAGENTS.mdは同じリポジトリに共存できます。ファイル名が違うため、片方のCLIがもう片方の指示ファイルを誤読することはありません。ただし中身は自動で同期されないので、「テストはnpm run test:unitを使う」のような運用ルールは両方のファイルに書く必要があります。片方だけ更新して放置すると、CLIによって違う手順を踏むエージェントが混在します。

非対称な点もあります。Claude Codeには個人用でGit管理から外れる.claude/settings.local.jsonという専用の置き場所があります。Codex CLI側には同じ役割のファイル名が用意されていません。個人設定をリポジトリ直下に置きたい場合は、.codex/config.tomlを自分の.gitignoreで除外するか、--profileで切り替えるプロファイルに逃がす形になります。

MCPサーバーの接続も同様です。Claude Codeはプロジェクト共有スコープを.mcp.jsonに、Codex CLIは.codex/config.tomlに保存する設計で、フォーマットも記法も異なります。同じMCPサーバーを両方から使いたいなら、設定は2回書くことになります。

// .mcp.json (Claude Code側、プロジェクト共有スコープ)
{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp"]
    }
  }
}

# .codex/config.toml (Codex CLI側、信頼済みプロジェクトでのみ読み込み)
[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]

Codex CLIはcodex mcp addコマンドでも同じ設定を書き込めます。手で書くよりコマンド経由の方が構文ミスを防げます。

codex mcp add context7 -- npx -y @upstash/context7-mcp

権限モードとサンドボックスの対応関係をそろえる

両CLIとも「どこまで自動で実行を許すか」を制御する仕組みを持っていますが、用語も既定値も異なります。両方を素の初期状態のまま使うと、実は片方が最初から編集を自動承認しているという取り違えが起きやすいので、対応表を頭に入れておくと安全です。

ここで見落としやすいのが既定値の非対称性です。Claude Codeを何もオプションを付けずに対話起動すると、初期モードはdefault(Manual)で読み取りのみに制限されます。一方Codex CLIを対話起動した場合は、追加のフラグを付けなくてもAutoプリセット(workspace-write+on-request)で動きます。ワークスペース内のファイル編集は確認なしで進み、ネットワークアクセスやワークスペース外への書き込みだけが承認待ちになる設計です。なお非対話実行のcodex execはこれとは別に既定が読み取り専用に切り替わります。詳しくはCI節で扱います。

同じ「初期状態で試してみる」でも、Claude Codeは様子見の実行に、Codex CLIはある程度踏み込んだ実行になります。両方を初めて併用するときは、この非対称性を知らずに「Codexの方が最初から編集してきて驚いた」という感想を持つ人が実際にいます。

コスト配分を契約単位で設計する

併用で最も見落とされがちなのがコストの二重取りです。両CLIとも認証方式が「サブスクリプションに紐づける」か「APIキーの従量課金にするか」の二択になっている点は共通しています。

• Claude Code: /loginでClaudeのPro / Max / Team / Enterprise契約に紐づけるか、Anthropic APIキーで従量課金にするか
• Codex CLI: codex loginでChatGPTのサブスクリプションに紐づけるか、CODEX_API_KEY(またはOPENAI_API_KEY)で従量課金にするか

Claude Code側の具体的な料金体系・プラン選びはClaude Codeの料金ガイドに譲りますが、併用設計を左右する原則は次の2つです。

1. 定額契約は日常使いの主戦場側にまとめる。長時間・多段階のセッションを回す方をサブスクリプション契約にし、もう一方は従量課金のAPIキーで必要な分だけ使う構成にすると、2つの定額プランを同時に持て余すリスクを避けられます。
2. CIやバッチ処理は従量課金側に寄せる。定額プランは個人の利用枠に紐づくことが多く、CIランナーのような無人実行を大量に走らせると枠を圧迫します。CI専用にAPIキーを発行し、月次のコストを可視化しておくと予算超過に気づきやすくなります。

Codex CLI側では、CODEX_API_KEYをジョブ単位の環境変数として渡す運用が公式に案内されています。リポジトリのコードを実行するジョブ全体にOPENAI_API_KEYやCODEX_API_KEYを置くと、同じジョブ内の他のステップからも鍵が読めます。ビルドスクリプトやテスト、依存パッケージのライフサイクルフックも例外ではありません。単発のcodex exec呼び出しにだけ環境変数を絞るか、公式のcodex-actionのようなプロキシ経由の実行に寄せるのが安全な形です。

同時に走らせるときの衝突をworktreeで避ける

同じリポジトリでClaude CodeとCodex CLIを並行して動かすと、両方が同じファイルを同時に編集して競合するリスクがあります。原因はツール固有のバグではなく、同じ作業ディレクトリを複数のエージェントが共有すること自体にあります。解決策も両CLI共通のGitの機能です。

git worktreeで作業ツリーを分けると、同じリポジトリの履歴を共有しながら物理的に別ディレクトリで作業できます。Claude Code側の落とし穴はClaude Code Worktree実践ガイドにまとめてあり、要点は併用でも同じです。

git worktree add -b feature/claude-side ../repo-claude
git worktree add -b feature/codex-side ../repo-codex

それぞれのディレクトリで別のCLIを起動すれば、ファイルシステム上の衝突は原理的に起きません。Claude Codeの~/.claude/settings.jsonやCodex CLIの~/.codex/config.tomlは、ホームディレクトリに紐づくユーザー設定です。worktreeでディレクトリを分けても、両方にそのまま適用されます。

worktreeでディレクトリを分けても、ブランチを分けなければ意味がありません。両方のエージェントに同じブランチへのpushを許可すると、Git上のコンフリクトという形で問題が表面化するだけです。ブランチも分け、最後は人間かどちらか一方のエージェントがマージする一本化ポイントを決めておきます。

CI・自動化パイプラインへの組み込み方

両CLIとも非対話モードを持っているため、GitHub Actions等のパイプラインに個別に組み込めます。併用パイプラインを組むなら、1つのワークフロー内で役割を明確に分けるのが安全です。

# .github/workflows/auto-fix.yml (抜粋、疑似コード)
jobs:
  claude-review:
    steps:
      - run: claude -p --permission-mode dontAsk "このPRの差分をレビューしてMustだけ列挙して"
  codex-autofix:
    needs: claude-review
    steps:
      - run: codex exec --sandbox workspace-write "lintエラーだけを機械的に修正して"

Codex CLI側のcodex execは既定で読み取り専用サンドボックスなので、ファイルを書き換えるジョブでは--sandbox workspace-writeの明示が必須です。逆にレビューや要約のような読み取りだけのジョブは、既定のままの方が誤操作のリスクを抑えられます。Claude Code側も同様に、書き込みを伴うジョブではdontAskのような非対話モードを明示し、defaultのまま無人実行してハングさせないようにします。

出力の受け渡しにはcodex exec --jsonやclaude -p --output-format jsonのような構造化出力を使うと、次のジョブへ結果を安全に渡せます。Codex CLIは--output-schemaでJSON Schemaに準拠した出力を直接要求できるのが強みです。後続ジョブが期待するフィールドの欠落を、実行時に検証させたい場合に向いています。

よくあるつまずき

CLAUDE.mdにルールを追記して満足し、AGENTS.mdが古いままというのが最も起きやすい食い違いです。指示ファイルは片方だけ更新して終わりがちです。運用ルールを変えたら、両方のファイルを同じコミットで更新する習慣をつけると防げます。

サンドボックスの既定値も取り違えやすいポイントです。前述の通りCodex CLIの初期設定はワークスペース内の編集を自動承認します。Claude Codeの「最初は読み取り専用」という感覚のまま使うと、意図しない編集が先に走っている状態に気づくのが遅れます。

APIキーの扱いも要注意です。OPENAI_API_KEYやANTHROPIC_API_KEYをワークフロー全体の環境変数に置くと、無関係なステップからも読み取れる状態になります。鍵を使う実行ステップだけにスコープを絞るのが、両CLI共通の安全な運用です。

worktreeで作業ディレクトリを分けても、pushの先が同じブランチなら競合は解消しません。ブランチも分けて、マージの一本化ポイントを決めておく必要があります。

.mcp.jsonに追加したMCPサーバーを.codex/config.tomlに反映し忘れると、片方のCLIだけがそのツールを使えない状態になります。新しいサーバーを追加したら、両方の設定ファイルを更新する運用をチェックリスト化しておくと漏れにくくなります。

よくある質問

Q. ClaudeとChatGPTの有料プランは両方契約する価値がありますか?

使用量次第です。試しに併用してみる段階では、片方はAPIキーの従量課金で使用量を計測し、実際に月あたりの利用が定額プランの元を取る水準に達してから契約を切り替えると、無駄な固定費を抱えずに済みます。

Q. AGENTS.mdとCLAUDE.mdの内容を1つのファイルにまとめられますか?

公式にはまとめる仕組みはありません。Codex CLIはproject_doc_fallback_filenamesでファイル名を追加登録できますが、これは別名のファイルもAGENTS.md相当として読む機能です。Claude CodeのCLAUDE.mdをCodex CLIに読ませる機能ではないため、運用ルールが同じなら内容をコピーして両方に置くのが確実です。

Q. 同じPull Requestに両方のCLIでコミットしても問題ありませんか?

技術的には可能ですが、レビューする人間から見て「どちらが何を書いたか」が追いにくくなります。コミットメッセージや変更範囲でどちらのエージェントの作業か分かるようにするか、そもそもPRを分けるほうが後から原因を追いやすい構成です。

Q. Codex CLIをClaude Codeのdefaultモード相当にできますか?

--sandbox read-only --ask-for-approval on-requestの組み合わせが最も近い挙動です。ファイルの読み取りと質問への回答はできますが、編集・コマンド実行・ネットワークアクセスにはすべて承認が必要になります。

まとめ

Claude CodeとCodex CLIの併用は「優劣を決めて1つに絞る」より、契約状況とタスクの性格で役割を分ける方が現実的な着地点になりやすい構成です。土台になるのは3点です。指示ファイル(CLAUDE.md / AGENTS.md)とMCP設定は二重管理が前提になること。サンドボックスの既定値は非対称であること。そしてworktreeでファイルシステムの衝突を物理的に避けることです。

MCPサーバー設定の詳細はClaude Code MCP設定ガイドに、CLAUDE.mdの書き方はCLAUDE.mdを実用に引き上げる10のパターンにまとめてあります。