【2026年最新】CodexとClaude Code｜使い分けと連携7パターン

「Codexって結局Claude Codeと何が違うの？どっち使えばいいの？」

AIを日常的にガチで使っていると、これを聞かれる頻度がめちゃくちゃ高い。自分もしばらくは「なんとなくClaude Codeメインでたまにコデックス」みたいな雑な使い分けをしていたんですが、実際に両者を連携させてみてから完全に考え方が変わりました。

「どっちを使うか」ではなく「どうオーケストレーションするか」が正解だったんです。

この記事では、両者の技術的な差分を整理した上で、実際に試して動いた7つの連携パターンをコード付きで紹介します。動作環境は Claude Code（claude CLI v1.x、2026年5月時点） と Codex CLI（v0.128.0、homebrew / npm 導入） です。

CodexとClaude Codeを徹底比較する前に：どちらもエンジン1個のCLIエージェント

まず前提の整理から。両者とも「ターミナルで動くAIコーディングエージェント」というカテゴリに属しますが、内部の設計思想がかなり異なります。

Codex（codex-cli）は OpenAI 製。バイナリ名は codex で、homebrew（brew install codex）または npm（npm install -g @openai/codex）で導入できます。モデルは GPT-5.2 / GPT-5.2-codex 世代。

重要なのは、「Codex」はエンジン1個で、複数のモードを持つという点です：

• codex（対話モード）：ターミナルで対話的にコーディングする、いわゆるメインの使い方
• codex exec "質問"：ヘッドレス1ショット。codex exec resume --last "続き" で前の会話を継続できる
• codex mcp-server：Codex自身をMCPサーバーとして公開。他のツール（Claude Codeを含む）から呼べるようになる
• codex app-server：デスクトップGUIアプリが内部で使うプロトコルを直接叩く、stdio直結モード。codex://threads/<id> で個別スレッドにアクセスできる
• Codex.app（GUI）：同じcodexエンジンにGUI皮をかぶせたもの

Claude Codeは Anthropic 製。claude CLI で動き、モデルは Opus 4.8 / Sonnet 4.6 / Haiku 4.5 世代が選択可能。認証は両者とも OAuth（サブスクリプション枠） が基本で、APIキーを直接叩く従量課金モードとは別物です。これが後述する連携コスト計算でかなり重要になります。

機能比較表：Codex vs Claude Code（2026年5月時点）

比較軸	Codex（codex-cli）	Claude Code（claude CLI）
提供元	OpenAI	Anthropic
既定モデル	GPT-5.2 / GPT-5.2-codex	Opus 4.8 / Sonnet 4.6 / Haiku 4.5
認証方式	OAuthサブスク枠（codex login）	OAuthサブスク枠（claude auth login）
サンドボックス	read-only / workspace-write / danger-full-access の3段階	permissionモード（都度確認 or autoApprove）
承認ポリシー	untrusted / on-failure / on-request / never	ツール別パーミッション設定
MCPサポート	MCPサーバーとして公開可（mcp-serverモード）	MCPクライアント（.mcp.json / mcpServers）
サブエージェント	なし（単体実行が基本）	あり（.claude/agents/、並列起動可）
エコシステム	Codex.app GUI、app-serverプロトコル	Skills / Hooks / Plan mode / サブエージェント
ヘッドレスモード	codex exec "質問"（1ショット）	claude -p "..." --output-format json（printモード）
強み	GPTエコシステム連携・GUI記録・sandbox設計	エコシステムの深さ・並列エージェント・MCP消費
弱み	エコシステムがシンプル（サブエージェントなし）	Codex.appのような統合GUI記録機能なし

この表を見ると、「どちらが優れているか」ではなく「何を重視するかで選ぶ」がわかります。CodexはGUIとの統合・サンドボックス設計が得意、Claude Codeはエコシステムの深さと並列エージェント構成が得意、というポジショニングです。

詳細な仕様については公式ドキュメントを参照してください（code.claude.com/docs、developers.openai.com）。

認証・課金の構造：「OAuthサブスク枠」を正確に理解する

ここ、めちゃくちゃ重要なのに意外と誤解されています。

Codexは codex login（OpenAI OAuthログイン） で認証します。このとき使われるのはOpenAIの サブスクリプション枠（ChatGPT Pro / Team などのプランに付随）であって、APIキーによる従量課金ではありません。同様にClaude Codeも claude auth login でAnthropicアカウントのサブスク枠を使います。

つまり、後述するMCP連携などで「Claude CodeからCodexを呼ぶ」場合でも、OpenAIのAPIキーに課金されるわけではなく、CodexのOAuthサブスク枠から消費されるという構造です。連携コストを試算するときに、この点を見落とすと全く違う数字が出てきます。

# ❌ 間違い：APIキーをセットしてCodex MCPを使う（従量課金になる）
export OPENAI_API_KEY="sk-proj-..."  # これがある状態でcodex mcp-serverを起動しない

# ✅ 正解：codex loginで認証済みのOAuth枠を使う
codex login  # ブラウザでOpenAI認証
codex mcp-server  # OAuthトークンで動作

Codex MCPを使う前に ps aux | grep codex でゾンビプロセスが残っていないか確認する癖もつけておきましょう。複数の codex exec を並列で走らせると認証トークンが競合して無言ハングします（実体験：3件のゾンビが数日滞留していた）。

連携パターン7選：実際に動いた組み合わせをすべて公開

ここが記事の核心です。「どっちを使うか」ではなく「どう組み合わせるか」の7パターンを、実際に試した順番で紹介します。

パターン1：Codex MCP（最も楽な連携・推奨）

Claude CodeのMCPクライアント機能を使って、codex mcp-server を登録します。これが全パターンの中で最もセットアップが楽で、安定して動きます。

# Step 1: .mcp.json にCodexをMCPサーバーとして登録
# ~/.claude/mcp.json（またはプロジェクト直下の.mcp.json）
{
  "mcpServers": {
    "codex": {
      "command": "codex",
      "args": ["mcp-server"],
      "env": {}
    }
  }
}

# Step 2: Claude Code起動後、会話中でツール呼び出し
# Claude Codeのセッション内で自動的に mcp__codex__codex ツールが使える状態になる

# 使用例（Claude Codeのプロンプト内で）
"Codexに聞いてみて：この実装のセキュリティ上の懸念点は？"
# → mcp__codex__codex ツールが自動で呼び出される

このパターンの最大のメリットは、Claude Codeの会話コンテキストを保ったままGPTモデルの視点でクロスチェックできる点です。特に設計判断の場面で「Claudeがこう言ったけど、GPTモデルはどう見る？」というセカンドオピニオンが実用的です。

パターン2：codex exec をシェルから叩く

Claude CodeのHooks機能やカスタムスクリプトから codex exec をサブプロセスとして呼び出すパターンです。

#!/bin/bash
# scripts/codex-review.sh
# Claude Codeが生成したコードをCodexにレビューさせる

CODE_FILE=$1
REVIEW=$(codex exec "以下のコードのセキュリティ・パフォーマンス上の問題点を3点以内で指摘してください：$(cat $CODE_FILE)")

echo "=== Codex Review ==="
echo "$REVIEW"

Claude CodeのHooksで PostToolUse に紐づけると、コード編集後に自動でCodexレビューが走ります。

# .claude/settings.json（Hooksの設定例）
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "command": "bash ~/.claude/scripts/codex-review.sh"
      }
    ]
  }
}

パターン3：Claude CodeからCodexへ・逆方向も試す

Codexはworkspacewriteまたはdangerfullaccess サンドボックスで動作している場合、claude -p "..." をサブプロセスとして呼び出せます。これがパターン1の逆方向です。

# Codexのセッション内でClaudeを呼ぶ（Codexのスクリプト実行権限が必要）
# workspace-write以上のサンドボックスが必要

CLAUDE_RESPONSE=$(claude -p "この関数の意図を1行で説明して" --output-format json 2>/dev/null | jq -r '.result')
echo "Claude says: $CLAUDE_RESPONSE"

使いどころとしては、Codexがコードを書いた後に「Claude視点の意図確認」を自動で走らせる、といった品質ゲートに向いています。ただし、Claude Codeのprintモード（claude -p）は比較的待ち時間が長いので、頻繁に呼ぶよりも「最終確認」用途が現実的です。

パターン4：codex app-server 直結でGUI記録と連動

Codex.appの内部プロトコルを直接叩くstdio直結モードです。セットアップはやや玄人向けですが、Codex.appのGUI履歴にスレッドとして残るのが独自の強みです。

# codex app-server を stdio 起動する Python ラッパー（概念例）
import subprocess, json

proc = subprocess.Popen(
    ["codex", "app-server"],
    stdin=subprocess.PIPE,
    stdout=subprocess.PIPE,
    stderr=subprocess.PIPE
)

# initialize リクエスト
init_msg = json.dumps({"jsonrpc":"2.0","id":1,"method":"initialize","params":{}}) + "\n"
proc.stdin.write(init_msg.encode())
proc.stdin.flush()

response = proc.stdout.readline()
print("init response:", json.loads(response))

このパターンを使うと、codex://threads/<id> でClaude Codeが生成したスレッドをGUIから参照できます。「コードはターミナルで書いたけど、そのやりとりをチームに共有したい」というシーンで活きます。

パターン5：往復メールボックス方式（DIYパターン）

これは 公式の製品メニューにはないDIYパターン であることを最初に断っておきます。1つのファイルを両者が読み書きする「ブラックボード方式」の応用です。

仕組みは以下のとおりです：

1. 共有ファイル（例：/tmp/mailbox.json）を用意し、NEXT フィールド（次に喋る番）と processed_ids リスト（処理済みメッセージID）を持たせる
2. Claude CodeとCodexが交互にファイルを読み書きする
3. エコー無限ループ防止のため、processed_ids に既処理IDを記録
4. 交互に動かすには「ドライバー（司会役）」が必要（人 / 別セッション / fswatchループ）

# /tmp/mailbox.json の構造例
{
  "NEXT": "claude",
  "messages": [
    {
      "id": "msg-001",
      "from": "codex",
      "content": "この認証ロジック、JWTの有効期限チェックが抜けてます",
      "timestamp": "2026-05-30T10:00:00Z"
    }
  ],
  "processed_ids": []
}

#!/bin/bash
# driver.sh：fswatchを使った往復ドライバーの例（概念コード）

MAILBOX="/tmp/mailbox.json"

fswatch -1 "$MAILBOX" | while read event; do
  NEXT=$(jq -r '.NEXT' "$MAILBOX")

  if [ "$NEXT" = "claude" ]; then
    LAST_MSG=$(jq -r '.messages[-1].content' "$MAILBOX")
    REPLY=$(claude -p "返信してください：$LAST_MSG" --output-format json | jq -r '.result')
    # mailboxにclaudeの返信を書き込み、NEXTをcodexに切り替え
    jq --arg reply "$REPLY" '.messages += [{"id": "msg-\(.messages|length)","from":"claude","content":$reply}] | .NEXT = "codex"' "$MAILBOX" > /tmp/mb_tmp && mv /tmp/mb_tmp "$MAILBOX"
  fi
done

実用的な用途は「コードレビューの往復討論」「アーキテクチャ設計の二者間ブレスト」です。正直、まだ実験的なパターンで、エラーハンドリングやタイムアウト設計は自前で組む必要があります。「面白いけど本番投入はもう少し先」という感じです（笑）。

パターン6：Claude Codeのサブエージェントとして並列実行

Claude CodeはCodexをMCPツールとして呼びながら、同時に複数のサブエージェント（.claude/agents/）を並列実行できます。これが「Claude Codeのオーケストレーター + Codexの特化エージェント」という組み合わせで最も威力を発揮するパターンです。

# .claude/agents/codex-security-reviewer.md
---
name: codex-security-reviewer
description: "セキュリティレビューをCodex MCPに投げて回答をまとめるエージェント"
tools: mcp__codex__codex, Read, Glob
---

以下のファイルを読み込み、Codex MCPに「セキュリティ上の懸念点を列挙してください」と投げてください。
回答をJSON形式でまとめること。

# Claude Codeのプロンプト例
# 複数エージェントを並列起動して結果を統合

"以下の3つを並列で実行して：
1. codex-security-reviewerでauth.tsのセキュリティ確認
2. 通常エージェントでコードスタイルチェック
3. Codex MCPでパフォーマンスアドバイス
結果をまとめて報告して"

Claude Code単体でのマルチエージェント並列実行については、Claude Codeサブエージェント並列開発実践ガイドで詳しく解説しています。

パターン7：codex exec resume で長い調査タスクを継続

長い調査や実装タスクを分割して継続できる codex exec resume --last は、Claude Codeのセッション管理と組み合わせると強力です。

# 最初のタスク
codex exec "このコードベースのAPIレイヤーを分析して、認証フローを説明して"
# → 会話IDが生成される

# 別セッションで継続（Claude Codeがプロンプトを生成→Codexに渡す）
NEXT_PROMPT=$(claude -p "前回の認証フロー分析の続きとして、次に確認すべき点を1文で" --output-format json | jq -r '.result')
codex exec resume --last "$NEXT_PROMPT"

使い分けの判断基準：状況別チートシート

7パターンを覚えるのが大変な人向けに、「この状況ならこのパターン」をまとめます。

状況	推奨パターン	理由
対話中のリアルタイムクロスチェック	パターン1（Codex MCP）	セットアップ最小・コンテキスト保持
編集後の自動レビュー	パターン2（codex exec + Hooks）	PostToolUseフックで自動化できる
GUI履歴に残したい	パターン4（app-server）	Codex.appのGUI記録が残る
アーキテクチャ討論	パターン5（往復メールボックス）	二者間の往復議論に最適（ただし実験的）
本格的な並列実装	パターン6（サブエージェント + MCP）	Claude Codeのオーケストレーション機能を活用
長い調査タスクの継続	パターン7（exec resume）	会話を跨いで調査を継続できる

MCPとサブエージェントを組み合わせた高度な実装については、Claude CodeのMCP実践ガイドも参照してください。

サンドボックス・承認ポリシーの違い：本番環境で使う前に必ず把握

この差は特に「自動化パイプラインに組み込む」場面で重要になります。

Codexのサンドボックスは3段階：

• --sandbox read-only：ファイル読み取りのみ（最も安全）
• --sandbox workspace-write：ワークスペース内への書き込みは許可
• --sandbox danger-full-access：フルアクセス（CI環境など制御されたコンテナ内のみ推奨）

承認ポリシーも4段階（--approval-policy untrusted/on-failure/on-request/never）があり、パイプライン用途では --approval-policy never と組み合わせて完全自動化できます。

# 本番パイプラインでの安全な使用例
codex exec \
  --sandbox workspace-write \
  --approval-policy on-failure \
  "テストを実行してエラーがあれば修正案を提示して"

Claude Codeの場合は --dangerously-skip-permissions フラグや settings.json での allowedTools 設定でコントロールします。CI環境で使う場合は .claude/settings.json に適切な allowedTools を明示することが推奨されています（公式ドキュメント参照）。

【要注意】よくある失敗パターンと回避策

❌ 失敗1：APIキーをセットしたままCodex MCPを使う

環境変数に OPENAI_API_KEY が設定された状態でCodex MCPを起動すると、OAuthサブスク枠でなくAPIキーの従量課金に流れる可能性があります。

⭕ 回避策：codex login での認証状態を確認し、APIキー環境変数をunsetしてから起動する。codex login status で認証状態を確認できます。

❌ 失敗2：codex execを複数並列起動する

複数の codex exec を同時に走らせると、内部の認証トークン/セッションが競合して無言ハングします。見た目は動いているように見えるのにタイムアウトする、という症状が出ます。実際に3件のゾンビプロセスが数日滞留した経験があります。

⭕ 回避策：codex exec は1件ずつ順次実行。並列が必要な場合はCodex MCPをClaude Codeのサブエージェント経由で呼ぶ（パターン6）。点検コマンド：ps aux | grep "codex exec" | grep -v grep

❌ 失敗3：往復メールボックス方式にドライバーを置かない

Claude CodeとCodexの両者に「次に話しかける役」を任せると、どちらも待ち続けてデッドロックします。必ずドライバー（司会役）を1つ決めて、他方をツール扱いにする設計にしてください。

⭕ 回避策：「Claude Codeがオーケストレーター、Codexがワーカー」と明確に役割分担する。

❌ 失敗4：モデルの得意/不得意を無視して使い分ける

「Claude CodeはコードをAnthropicのモデルで、Codexは別の視点でチェック」という分業は合理的ですが、両者のモデルが得意な領域の違いを把握せずに使い分けるのは危険です。特にセキュリティアドバイスや複雑な推論タスクでは、どちらかの回答を鵜呑みにせず、必ず人間がレビューしてください。

⭕ 回避策：「AIは補助ツールであり、最終判断者ではない」原則を守る。セキュリティ・パフォーマンス・アーキテクチャの重要判断は人間が行う。

CIパイプラインへの組み込み：実践的なワークフロー例

GitHub ActionsでCodexとClaude Codeを連携させる構成例です。

# .github/workflows/ai-review.yml（概念例）
name: AI Code Review
on: [pull_request]

jobs:
  claude-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Claude Code Review
        run: |
          # Claude Code printモードでPR差分をレビュー
          git diff origin/main...HEAD > /tmp/pr_diff.txt
          claude -p "以下のdiffのバグ・セキュリティ問題を指摘して：$(cat /tmp/pr_diff.txt)" \
            --output-format json > /tmp/claude_review.json

      - name: Codex Cross-check
        run: |
          # Codex execで同じdiffをクロスチェック
          CLAUDE_FINDINGS=$(jq -r '.result' /tmp/claude_review.json)
          codex exec \
            --sandbox read-only \
            "Claudeのレビュー結果と追加で気づいた点を教えて：\n$CLAUDE_FINDINGS" \
            > /tmp/codex_review.txt

      - name: Comment on PR
        uses: actions/github-script@v7
        with:
          script: |
            const claudeReview = require('fs').readFileSync('/tmp/claude_review.json', 'utf8');
            const codexReview = require('fs').readFileSync('/tmp/codex_review.txt', 'utf8');
            // PRにコメントとして投稿
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: `## AI Review\n\n### Claude\n${JSON.parse(claudeReview).result}\n\n### Codex\n${codexReview}`
            })

CI/CDパイプラインへのClaude Code組み込みの詳細については、SaaS向けCI/CDパイプラインにClaude Codeを組み込む5ステップで実例を紹介しています。

MCPアーキテクチャから見た位置づけ：Codexは「MCPサーバー」になれる

MCP（Model Context Protocol）の観点から見ると、両者の関係が非常に面白い構造になっています。

Claude CodeはMCPクライアントとして動作します。.mcp.json や claude config add mcpServers でMCPサーバーを登録し、そのツールを会話中に呼び出せます。

CodexはMCPサーバーになれます。codex mcp-server を起動すると、mcp__codex__codex と mcp__codex__codex-reply というツールが生えて、Claude Codeから呼び出せる状態になります。

これは単なる「呼び合い」ではなく、Claude CodeがCodexをツール扱いできるという意味です。Claude Codeのオーケストレーション機能（サブエージェント、Hooks、Skills）の上で、Codexが「GPTモデルを使うツール」として機能する構造は、マルチモデルエージェントの実践例として非常に示唆的です。

FAQ：Codex vs Claude Code でよく聞かれること

Q1. CodexとClaude Codeはどちらが優れていますか？

優劣で比較するより役割分担で考えるのが実用的です。Codexはサンドボックス設計・GUI記録・GPTエコシステムとの連携が強み。Claude Codeはサブエージェント並列化・Skills/Hooks・MCPクライアント機能など深いエコシステムが強みです。両者をMCP経由で連携させるのが最も効果的な使い方です。

Q2. codexとClaude CodeはどちらもAPIキーが必要ですか？

どちらもAPIキー不要（OAuthサブスク枠）が基本です。codex login でOpenAIアカウント認証、Claude CodeはAnthropicアカウントで認証します。APIキーを環境変数に設定するとそちらが優先されて従量課金になるため注意してください。

Q3. Claude CodeからCodexを呼ぶ設定は複雑ですか？

比較的シンプルです。.mcp.jsonに codex mcp-server のエントリを追加してClaude Codeを再起動するだけで mcp__codex__codex ツールが使えるようになります。前提条件は codex login での認証と、codex コマンドがPATHに通っていることです。

Q4. 往復メールボックス方式は本番で使えますか？

現状は実験的なDIYパターンです。公式の製品機能ではないため、エラーハンドリング・タイムアウト・セッション管理を自前で実装する必要があります。「アーキテクチャ討論」「設計ブレスト」などの開発補助用途に適しています。

Q5. codex exec を並列で走らせてはいけない理由は？

内部の認証トークン・セッションが競合して無言ハングする問題があります。複数プロセスが同時にOAuthトークンをリフレッシュしようとすると状態が壊れ、長時間タイムアウトが発生します。並列実行が必要な場合はCodex MCPをClaude Codeのサブエージェント経由で呼ぶ方法が安全です。

Q6. CodexとClaude CodeでどちらがCI/CDに向いていますか？

それぞれ得意な役割があります。Codexはサンドボックス設定と承認ポリシーが細かく設定でき、CI環境での安全な自動実行に向いています。Claude Codeはprintモード（claude -p）でJSON出力でき、後続処理との連携が容易です。「Claudeが分析→Codexがクロスチェック」という構成がCI用途での推奨パターンです。

データプラットフォーム開発での実践例

実際の開発シーンでどう使われているか、想定シナリオで整理します（本記事は実装パターン解説です。以下は実際の開発現場で起こりうる典型的なシナリオに基づいています）。

SQLレビューを例に取ると、Claude Codeで書いたクエリをCodex MCPでクロスチェックするフローが自然に機能します。データプラットフォームへのClaude Code活用については、データプラットフォームのSQLレビューをClaude Codeで自動化する5ステップで詳しく解説しています。

まとめ：今日から始める3つのアクション

「Codex vs Claude Code」という問いの答えは「どちらも使う、そして連携させる」です。両者は競合ではなく、相補的な関係にあります。

1. 今日やること：codex login → .mcp.json にCodexを登録 → Claude Codeのセッションで mcp__codex__codex を一度呼んでみる（パターン1）
2. 今週中：Claude CodeのHooksに codex exec を組み込んで、コード編集後の自動クロスチェックを設定する（パターン2）
3. 今月中：CI/CDパイプラインに「Claude分析 + Codexクロスチェック」の二重レビューを組み込む（パターン6の応用）

---

次回予告：Claude CodeのMCPサーバー群を組み合わせた「オーケストレーション設計パターン」を掘り下げます。

---

参考・出典

• Claude Code 公式ドキュメント（Anthropic、2026年5月時点参照）
• Claude Code — Anthropic公式ページ（Anthropic、2026年5月時点参照）
• OpenAI Developers（OpenAI、2026年5月時点参照）

---

関連記事（自動）

• ▸ API仕様変更レビューをClaude Codeで標準化｜5手順
• ▸ Terraform変更レビューをClaude Codeで標準化｜5手順
• ▸ 【2026年最新】Claude Code法人導入セキュリティ完全チェックリスト
• ▸ 【2026年最新】Anthropic公式レポートで読むAIコーディング8トレンド
• ▸ 【2026年最新】Claude Codeサブエージェント並列開発入門