「Claude CodeとCodex、結局どっちをメインにすればいいの？」
この質問、実測比較の記事を公開してからDMやリプで何度もらったかわかりません。
正直に言います。playparkはClaude Codeヘビーユーザーです。 CLAUDE.mdを育て、Skillsを100以上作り、日常開発のほぼすべてをClaude Codeに任せている。Codexを本格運用してきたわけではありません。
でも、「Claude Code vs Codex」で止まっている議論がもったいないと感じていたのも事実。得意領域が違うなら、戦わせるより組ませたほうが強いんじゃないか？ その仮説を調べて、できる範囲で試してみた——というのがこの記事です。
「3ヶ月ガチ併用しました！」とは言えません。でも、Skills統一管理のsymlink共有は実際にやっているし、Codexの動作検証もした。調査と小規模検証ベースで「こう使い分けると良さそう」がわかった範囲を、誇張なしでまとめます。
この記事で学べること
- プロジェクト特性に応じたClaude Code / Codex選定マトリクス（一般的なフレームワークとして）
- 両ツールが衝突しないワークフロー設計の考え方
- Skills統一管理の実践テクニック（symlinkフラット共有は実際にやっている話）
- Claude Codeメインのチームが「Codex併用」を検討するときの判断材料
前提条件
- Claude Code（Maxプラン推奨）とCodex（ChatGPTアカウント。Plus以上推奨、期間限定でFreeプランでも利用可）
- Claude Code vs Codex 実測比較の基礎知識があると理解しやすい
- Skills統一管理のsymlink共有を理解しているとベスト（未読でもOK）
なぜ「vs」ではなく「×」なのか
比較記事で検証した通り、Claude CodeとCodexは得意領域が明確に違います 。
| 得意領域 | Claude Code | Codex |
|---|---|---|
| コンテキスト把握 | ◎（長いコンテキスト） | ○ |
| 日常コーディング | ◎（設定を育てた場合） | ○ |
| 大規模一括変更 | ○ | ◎（Cloud並列実行） |
| GitHub自動化 | ◎（Skills + gh CLI） | ◎（@codex） |
| カスタマイズ深度 | ◎（settings.json + Skills + hooks） | ○（SKILL.md + AGENTS.md + config.toml） |
得意領域が重ならないなら、戦わせるより組ませたほうが強い 。格ゲーでいうチーム戦です（キャラ被りは弱い）。
...と、ここまでは比較記事を読んでくれた方なら「そうだよね」という話。「で、具体的にどう組み合わせればいいの？」と思いませんか？ 私たちも同じことを考えました。
プロジェクト別ツール選定マトリクス
「で、うちのプロジェクトではどっちをどれくらい使えばいいの？」
調査と検証を通じて、判断に使えそうな4軸のフレームワークが見えてきました。
4軸評価
| 評価軸 | Claude Code有利 | Codex有利 |
|---|---|---|
| コンテキスト依存度 | 独自規約が多い、長い歴史 | 標準的な構成、新規プロジェクト |
| 変更の並列度 | 依存関係の多い変更 | 独立したファイル群の変更 |
| カスタマイズ要求 | 細かい挙動制御が必要 | デフォルト動作で十分 |
| 実行環境 | ローカル（対話的な開発向き） | Cloud sandbox（非同期バッチ処理向き） |
配分パターン
評価結果に応じて、おおまかに3つのパターンに分類できそうです。
| パターン | Claude Code : Codex | 典型的なプロジェクト |
|---|---|---|
| Claude Codeメイン | 8:2 | 既存コードベースの継続開発、独自フレームワーク |
| バランス型 | 5:5 | 中規模のWebアプリ開発、定期的なリファクタリングあり |
| Codexメイン | 2:8 | OSS開発、非同期バッチ処理中心、Cloud sandbox活用 |
playparkのコーポレートサイト（Next.js 16 + 独自Skills + MDXブログ）は、構造的に見るとClaude Codeメイン型 に該当します。CLAUDE.mdやSkillsでカスタマイズを積み重ねてきた歴史が長いので、日常の開発はClaude Codeのほうが圧倒的に文脈を理解してくれる。Codexの出番があるとすれば、SEO施策の一括メタデータ更新とか、記事の内部リンクを一気に修正するような「量が多いけど各タスクが独立している」作業でしょう。
統合ワークフロー：衝突しない仕組みの考え方
「2つのAIが同じコードベースを触って大丈夫？」——ここが一番の不安ポイントですよね。
調べてみると、解決策はブランチ + git worktreeで物理的に作業ディレクトリを分ける こと。ブランチを分けるだけでは同じディレクトリ上で作業することになり、一方がファイルを変更中にもう一方が同じファイルを触る——という衝突が起きます。git worktreeを使えば、同じリポジトリの異なるブランチを別々のディレクトリでチェックアウト できるので、真の並列作業が可能になります。
基本原則：worktreeで作業ディレクトリを分離する
最も重要なルールは 「同じワーキングディレクトリで同時作業しない」 こと。ブランチ命名で論理的に分け、worktreeで物理的に分ける——この2つを組み合わせることで、衝突を構造的に防げます。
# メインのワーキングディレクトリ（Claude Code用）
# ~/project/ → feature/add-blog-tag-filter ブランチで作業
# Codex用に別ディレクトリを作成
git worktree add ../project-codex codex/refactor-import-paths
# それぞれ独立したディレクトリで並列作業
# ~/project/ → Claude Code が feature/ で作業
# ~/project-codex/ → Codex が codex/ で作業
# 両方 → dev にマージ
💡 Codex（Cloud sandbox）の場合 : Codexはサーバーサイドのsandbox環境で動くため、ローカルのワーキングディレクトリとは物理的に別環境です。この場合worktreeは不要で、ブランチの分離だけで十分。worktreeが特に重要なのは、ローカルで2つのAIツールを同時に走らせるケース （例：Claude Code × Aider、Claude Code × Cursor）です。
タスク振り分けの考え方
両ツールの特性を踏まえると、こういう振り分けが自然です。
Claude Codeに向いているタスク:
- 新機能の実装（コンテキスト把握が必要）
- バグ修正（原因調査 → 修正のフローが得意）
- Skillsの作成・改善（メタ的にSkilledなツール）
- コードレビューの指摘対応（差分の文脈理解が必要）
Codexに向いているタスク:
- 大規模リファクタリング（ファイル数が多い変更）
- テストコードの一括生成
- Cloud sandbox での非同期バッチ処理
- 定型的なメタデータ更新（SEO対策の一括変更など）
どちらでもよさそうなタスク（その日の気分で）:
- ドキュメント作成
- 小規模なリファクタリング（5ファイル以下）
- 設定ファイルの更新
playparkの場合、上の「Claude Codeに向いているタスク」は日常的にClaude Codeでやっています。「Codexに向いているタスク」は...正直まだCodexに本格的に任せたことはありません。理論的にはCodexが得意な領域なのだろう という整理です（今後試したら追記します）。
Skills統一管理：実際にやっている話
ここからは実体験ベースです。Skills統一管理の基本は別記事で紹介しましたが、Claude CodeとCodexの共存で実際に効いているのがこの仕組み。
フラット構成 + symlink で共有する
playparkのSkillsリポジトリはフラット構成 です。100以上のSkillが同一階層にフラットに並んでいます。
skills-repo/ # 共有リポジトリ（SSOT）
├── _lib/ # 共通ライブラリ・ユーティリティ
├── _shared/ # 共通リファレンス
├── blog-publish/ # ブログ公開フロー
│ └── SKILL.md
├── code-audit-team/ # コード監査
│ └── SKILL.md
├── dev-flow/ # 開発フロー
│ └── SKILL.md
├── git-commit/ # コミット管理
│ └── SKILL.md
├── sns-announce/ # SNS告知
│ └── SKILL.md
└── ... # 100+ skills がフラットに並ぶ
ツール別にサブディレクトリを分ける方式（shared/ claude-code/ codex/ のようなもの）も考えましたが、やめました。フラットのほうがシンプルで管理がラク 。全Skillが一覧できるのは正義です（100超えてくるとディレクトリ階層はかえって迷子になる）。
Claude CodeもCodexも同じディレクトリをsymlinkで参照するだけ。
# 全ツールが同じSkillsリポジトリを参照
ln -s ~/skills-repo/* ~/.claude/skills/
ln -s ~/skills-repo/* ~/.codex/skills/
「ツール固有の挙動」が必要なケースは、SKILL.md内の条件分岐（Claude Codeの場合は... Codexの場合は...）で対応するか、ツール固有の設定ファイル（CLAUDE.md / AGENTS.md）に書きます。
ツール間のルール同期：CLAUDE.md ↔ AGENTS.md の橋渡し
もうひとつ考えておくべきなのが、CLAUDE.mdとAGENTS.mdの同期です。
プロジェクトルール（パス規約、コーディングスタイル、禁止操作など）は両方のツールに教えたい。でもフォーマットが違うから単純コピーでは動かない。
考えられる解決策は 「ルール定義ファイル」を1つ作り、両方の設定から参照する方式 。
project-root/
├── .ai-rules.md # ← ルール定義（SSOT）
├── CLAUDE.md # → .ai-rules.md を参照
├── AGENTS.md # → .ai-rules.md を参照
└── ...
<!-- .ai-rules.md -->
# プロジェクトルール
## パス規約
- 絶対パス `@/` を使用
- コンポーネントは `components/` 直下
## コーディングスタイル
- Biome でフォーマット
- CSS は Tailwind CSS 4
## 禁止操作
- git push --force 禁止
- main ブランチへの直接コミット禁止
<!-- CLAUDE.md -->
プロジェクトルールは .ai-rules.md を参照すること。
（Claude Code固有の設定をここに追加）
<!-- AGENTS.md -->
プロジェクトルールは .ai-rules.md を参照すること。
（Codex固有の設定をここに追加）
playparkでは現状CLAUDE.mdに全部書いていてAGENTS.mdは最小限ですが、本格併用する場合はこの分離が効くはず。「同じことを2回書く」を消すだけで、片方だけルールが古い事故を構造的に防げる のが狙いです。
Skill.md互換性のポイント
Skill.mdの書き方でも触れていますが、統合運用で特に注意が必要な互換性のポイントをまとめます。
| 要素 | Claude Code | Codex | 互換性 |
|---|---|---|---|
| SKILL.md本文 | ✅ | ✅ | 完全互換 |
| フロントマター（name, description） | ✅ | ✅ | 完全互換 |
| allowed-tools | ✅ | ❌ | Claude Code固有 |
| Skill連鎖（Skill内からSkill呼び出し） | ✅ | ❌ | Claude Code固有 |
| scripts/ ディレクトリ | ✅ | ✅ | 完全互換 |
| Skillsカタログ共有 | ❌ | ✅（openai/skills） | Codex固有 |
共有Skillsを書くときは、allowed-tools やSkill連鎖に依存しない設計にするのがコツです。Claude Code固有の高度な機能を使いたい場合は、SKILL.md内で条件分岐するか、そのSkill自体をClaude Code専用と割り切る。
検証してみてわかったこと
ここからは正直ベースの所感です。「3ヶ月使い込んだ結果」ではなく、調査と動作検証を通じて見えたこと 。
Skills共有は「やって損なし」
これは実際にやっていて断言できます。symlinkのフラット共有はセットアップが簡単で、メンテナンスもほぼゼロ 。Skillsリポジトリを更新すれば全ツールに反映される。Claude Codeだけを使っている人でも、将来Codexや他ツールを試すときにスムーズに移行できるので、やっておいて損はありません。
「頭脳労働はClaude Code、腕力仕事はCodex」は説得力がある
実際に両ツールを触ってみると、得意領域の違いは体感できます。Claude Codeはプロジェクトの文脈を掴んで「こうすべき」を考えてくれる。Codexは「この作業を50ファイル分やって」みたいな並列タスクに強い。使い分けの方向性としては間違っていないと思います 。
ただし、「どれくらい速くなるか」は正直わかりません。本格併用していないので定量データは出せない。「理論的にはこういう組み合わせが効率的だろう」という仮説の段階です。
注意点：コンテキストの伝搬
これはCodexの動作確認中に実感したこと。Claude Codeで調査した結果をCodexに引き継ぐとき、暗黙の文脈が落ちる 。「さっき調べた結果を踏まえて...」は通じません（当たり前だけど、ワンオペでClaude Codeに慣れていると忘れがち）。
対策としては、調査結果をMarkdownファイルに書き出してからCodexに渡すのが良さそう。手間は増えるけど、指示の明確化にもなるので、結果的にプラスに働くパターンです。
もうひとつの注意点：料金体系の違い
Claude CodeはMaxプラン（月額固定）、CodexはChatGPTプランに含まれる形（Plus $20/月〜）で、API利用時のみ従量課金です。両方サブスクリプションではあるものの、本格併用すると 「今月のAIツール費用いくら？」が把握しにくくなる のは想像がつく。片方に寄せているうちは問題ないけど、50:50で使い始めたら月末の請求が読みにくくなりそうです（家計簿アプリならぬAI費簿が欲しい）。
統合運用を始めるためのステップ
もし「試してみようかな」と思った方向けに、段階的なステップを整理します。
Phase 1：準備（1日）
- Claude Code と Codex 両方のアカウント準備
- Skills共有リポジトリの作成（手順はこちら）
-
.ai-rules.mdにプロジェクトルールを集約 - CLAUDE.md / AGENTS.md からルールファイルを参照
Phase 2：小さく試す（1週間）
- 日常タスクはClaude Codeのまま、Codexに1つだけタスクを振ってみる
- ブランチ命名規則の策定（
feature/vscodex/） - うまくいったケース・困ったケースをメモ
Phase 3：使い分けルールの明確化
- 自分のプロジェクトでの4軸評価を実施
- タスク振り分けの基準をチーム内で共有
- 月次の設定棚卸しを習慣化（ルールのドリフト防止）
いきなり50:50にする必要はありません。Claude Codeメインのまま、Codexが得意そうなタスクを1つ見つけて投げてみる ところから始めるのが現実的です。
まとめ
Claude CodeとCodexの「vs（どっちが強い？）」から「×（どう組み合わせる？）」へ。その可能性を調査・検証してみたレポートでした。
正直なところ、playparkの実態はClaude Code 95：Codex 5 くらい。Codexの本格運用はまだこれからです。でも、Skillsのsymlink共有は先に仕組みを作っておいたことでいつでもCodexを本格投入できる準備 が整っている。この「準備ができている状態」自体に価値があると感じています。
プロジェクト特性の4軸評価、ブランチによる住み分け、Skillsのフラット共有——この3つの考え方があれば、「とりあえず片方だけ」から「必要なときに両方使える」へのステップアップは難しくないはずです。
まずはSkillsの共有リポジトリだけでも作っておくと、未来の自分が「やっておいてよかった」と言ってくれる と思います（symlinkひとつの手間ですし）。
