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にまとめてあります。

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

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

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

指示ファイルは1つに寄せられる — AGENTS.mdとCLAUDE.mdの読み分け

両CLIは指示ファイルも設定ファイルも別建てです。まず設定ファイルの対応を並べます。

以前は「CLAUDE.mdとAGENTS.mdの両方に同じルールを書く」のが定石でした。今のClaude CodeはAGENTS.mdを直接読めるため、この前提が変わっています。読み分けは次のとおりです。

落とし穴は2行目です。AGENTS.mdがある環境で個人用にCLAUDE.local.mdを1枚足すと、Claude CodeはAGENTS.mdを読まなくなります。AGENTS.mdの直接読み込みはv2.1.277以降の機能で、それ以前のバージョンではCLAUDE.mdしか読みません。Amazon Bedrock経由やテレメトリを無効にしたセッションでは、v2.1.281より前はCLAUDE.md系だけを読みます。

表のCodex側にあるAGENTS.override.mdは、Claude Codeには読まれません。AGENTS.local.mdや.agents/以下のファイルも同じです。

@AGENTS.md
 
## Claude Code
 
変更が src/billing/ に及ぶときはplanモードで始める。

Claude Code専用の指示が要らなければ、ln -s AGENTS.md CLAUDE.mdのシンボリックリンクでも同じ内容を読めます。ただしClaude CodeのEditツールとWriteツールはシンボリックリンクの先へ書き込めず、リンク先のAGENTS.mdを編集するよう案内します。Windowsでシンボリックリンクを作るには管理者権限か開発者モードが必要で、Gitがリンクを平文ファイルとして展開する場合もあります。Windowsを使う人がいるチームでは@AGENTS.mdの取り込みが無難です。

Claude Codeの個人設定には、Git管理から外れる.claude/settings.local.jsonという専用の置き場所があります。Claude Codeがこのファイルを作るときは、グローバルのgit除外にも自動で登録します。手で作った場合は自分で.gitignoreに足します。Codex CLIで個人設定をリポジトリ内に置くなら、.codex/config.tomlを自分の.gitignoreで除外します。--profileで切り替えるプロファイルに逃がす方法もあります。

MCPサーバー設定は2回書く

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

Claude Code側はclaude mcp add --scope projectで.mcp.jsonが作れます。v2.1.287で空の一時ディレクトリ(HOMEとCLAUDE_CONFIG_DIRも空に差し替え)に実行した結果は次のとおりです。

claude mcp add --scope project context7 -- npx -y @upstash/context7-mcp

Added stdio MCP server context7 with command: npx -y @upstash/context7-mcp to project config
File modified: <作業ディレクトリ>/.mcp.json

できあがった.mcp.jsonは、手書きの最小形にtypeと空のenvが補われた形です。

{
  "mcpServers": {
    "context7": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp"],
      "env": {}
    }
  }
}

チームの誰かが.mcp.jsonをコミットしても、各メンバーのClaude Codeは最初の起動時に承認を求めます。承認前のサーバーはclaude mcp listでPending approvalと表示され、接続も行われません。承認の選択を取り消したいときはclaude mcp reset-project-choicesを使います。

Codex CLI側は.codex/config.tomlに同じサーバーを書きます。codex mcp addコマンドで書き込むこともできます。

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

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

権限モードの初期値は、どちらも「最初から止まらない」

両CLIとも「どこまで自動で実行を許すか」を制御する仕組みを持っていますが、用語が違います。Claude Codeは権限モード(--permission-mode)で制御します。Codex CLIはサンドボックスモードと承認ポリシー(--sandbox / --ask-for-approval)の組み合わせです。

Codex CLIはread-onlyとon-requestの組み合わせでも、サンドボックスの範囲で動くコマンドは承認なしで走り、編集やサンドボックス外の操作で承認を求めます。

「Claude Codeは初期状態が読み取りのみ」という通説は、今は当てはまりません。v2.1.283以降、ターミナルとVS Code拡張で新しいセッションを開くと、既定の開始モードはautoです。

体感は近く、Claude Codeでautoが使える環境なら、どちらも初めて動かすとファイル編集が確認なしで進みます。

Claude Codeに「最初は読み取り専用」を期待している場合は、claude --permission-mode manualで起動します。v2.1.287のclaude --helpでは、--permission-modeの選択肢にdefaultではなくmanualが並びます。公式docsには両方使えるとあります。manualの指定はv2.1.200以降で使えます。開始モードが変わらない例外もあります。

• 設定ファイルでdisableAutoModeが"disable"になっていると、開始モードはdefaultになります
• autoを選んでいても、そのセッションでautoが使えない場合は、開始モードがManualになります
• ~/.claude/settings.jsonがauto以外のdefaultModeを持っていると、その設定が優先されます
• .claude/settings.jsonに書いたautoとbypassPermissionsは効きません。ユーザー設定か--permission-modeで指定します

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

併用で見落としやすいのがコストの二重取りです。両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つです。両CLIの料金を項目別に突き合わせたい場合はClaude CodeとCodex CLIの料金比較ガイドも参考になります。

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

Codex CLI側は、CODEX_API_KEYを必要なcodex exec呼び出しにだけ渡す運用が案内されています。リポジトリのコードを実行するジョブ全体にOPENAI_API_KEYやCODEX_API_KEYをジョブ単位の環境変数として置かないよう案内されています。ビルドスクリプト、テスト、依存パッケージのライフサイクルフックから鍵が読めてしまうためです。GitHub Actionsでは、APIキーのプロキシを立てるopenai/codex-actionを使う形が案内されています。

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

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

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

Claude Code側の落とし穴はClaude Code Worktree実践ガイドにまとめてあり、要点は併用でも同じです。--worktreeを対話で初めて使うディレクトリでは、先にclaudeを1回起動してワークスペースの信頼ダイアログを承認しておく必要があります。

Claude Codeの~/.claude/settings.jsonやCodex CLIの~/.codex/config.tomlは、ホームディレクトリに紐づくユーザー設定です。worktreeでディレクトリを分けても、両方にそのまま適用されます。

push先のブランチも分けます。両方のエージェントに同じブランチへの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エラーだけを機械的に修正して"

Claude Codeの-pは、フラグで指定しない場合の開始モードが環境で変わります。機能フラグを取得するセッションではdefault、取得しない環境(サードパーティプロバイダ経由やテレメトリ無効)ではv2.1.285以降でautoです。無人実行では、モードを明示するのが確実です。

dontAskは、承認を求められる操作をすべて拒否するモードです。ワークスペース内の読み取りは通るので、上のレビュー用ジョブは動きます。ファイルを書き換えるジョブでは、--allowedToolsで許可する操作を並べるか、acceptEditsを指定します。acceptEditsが自動承認するのは、編集とmkdir・mv・cpのような基本的なファイル操作までです。組み込みの読み取り専用コマンドを除き、それ以外のシェルコマンドは--allowedToolsかpermissions.allowに書いたものだけが通ります。

claude -p "lintエラーを修正して" --permission-mode acceptEdits \
  --allowedTools "Bash(npm run lint *)"

Codex CLI側のcodex execは既定で読み取り専用サンドボックスなので、ファイルを書き換えるジョブでは--sandbox workspace-writeの明示が必須です。逆にレビューや要約のような読み取りだけのジョブは、既定のままの方が誤操作のリスクを抑えられます。

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

よくあるつまずき

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

AGENTS.mdが効いていないように見えるときは、リポジトリにCLAUDE.mdかCLAUDE.local.mdが残っていないかを確認します。残っていれば、Claude Codeは既定でAGENTS.mdを読みません。/configのProject instructionsをclaude-md-and-agents-mdにすると、両方を読ませられます。

よくある質問

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

使用量次第です。片方をAPIキーの従量課金で使って使用量を計測し、月あたりの利用が定額プランの元を取る水準に達してから切り替える進め方があります。

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

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

まとめ

併用が崩れやすいのは、設定ファイルの二重管理と既定モードの違いです。どちらを主に据えるかは契約状況で決まるため、役割の線引きを先に済ませると、あとの設定で迷いません。

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