Claude Code vs Codex、結局どっちがいい？──両方使い倒して見えた「選び方」の正解

正直に書く。僕は最初、Claude Code一本で開発を回すつもりだった。ところが実際に数ヶ月使い込むうちに、「これはCodexに投げたほうが早いな」と感じる場面が明らかに出てきた。逆に、Codexに任せたら微妙なコードが返ってきて、結局Claude Codeでやり直す──そんなことも何度もあった。

この記事は、両方のツールを実プロジェクトで使い比べた上で、「この場面ではこっち」と言い切れるところまで踏み込んだ内容にしている。ベンチマークの数字、実際の料金感覚、そして公式ドキュメント通りにいかなかった泥臭いトラブルと回避策まで、具体的に書いた。

そもそも何が違うのか──設計思想が根本的に異なる

まず前提を揃えておきたい。Claude CodeとCodexは、同じ「ターミナルAIコーディングツール」でも、作り手が目指しているものがまるで違う。

Claude Codeは「一緒に考える相棒」型だ。 プランモードでまず手順を提示し、こちらが承認してから実行に移る。エス・エム・エスのエンジニアテックブログ（参照）では、このプランモードを「エージェントに考えさせるが手は動かさせないモード」と表現していて、これが思考の質を上げるという指摘は実感と一致する。調査→設計→実装の3フェーズを踏ませ、フェーズ間に人間のレビューを挟む。この「ゲート」があるから、大きく的を外した実装が出にくい（Claude Code公式ベストプラクティス）。

Codexは「投げたら勝手にやる職人」型だ。 特にCodexアプリ（chatgpt.com/codex）は、タスクを自然言語で投げると、クラウド上の独立したサンドボックスでGitHubリポジトリをクローンし、作業を終えたらPRを作ってくれる。しかもこのタスクは並列実行できる。あるQiitaユーザーは、Codex WebとCLIを組み合わせて2日間で約80本のPRを作成したと報告している（Qiita: Codexをフル活用して2日間で80個近くのプルリクエストを作った話）。「エンジニアを束ねるマネージャーになった感覚」という表現は、Codexの本質をよく捉えていると思う。

この設計思想の違いが、あらゆる場面での使用感の差に直結している。

ベンチマーク──数字で見る実力差

「どっちが賢いか」を語るなら、まず数字を見るべきだ。ただし、ベンチマークの数字をそのまま鵜呑みにするのは危険なので、それぞれ何を測っているのかも併せて書いておく。

SWE-bench Verified：Claude Codeが80.8%

SWE-bench Verifiedは、実際のGitHubリポジトリから抽出された実世界のバグ修正タスクをどれだけ解けるかを測るベンチマークだ。Claude Code（Opus 4.6ベース）は80.8%を記録しており、これは個人開発者が利用できるツールとしては最高水準にある（Epoch AI: SWE-bench Verified、NxCode: Best AI Coding Tools 2026）。

一方で、Gemini 3.1 ProがSWE-bench Verifiedで80.6%とほぼ同等のスコアを叩き出しながら、トークン単価が半分以下という事実も見逃せない（NxCode: Cursor vs Claude Code vs GitHub Copilot 2026）。スコアだけ見てClaude Codeが「最強」と結論づけるのは早計だ。

Terminal-Bench 2.0：Codexが77.3%

Terminal-Bench 2.0は、ターミナル上でのマルチステップ操作──コマンド実行、デバッグ、ファイル操作を自律的にこなす能力を測るベンチマークだ。GPT-5.3-Codexは77.3%を記録し、前世代のGPT-5.2-Codexの64.0%から大幅に向上した（SmartScope: GPT-5.3-Codex Complete Guide、Epoch AI: Terminal-Bench 2.0）。

ここで見えてくるのは、Claude Codeは「コードの正しさ」で勝り、Codexは「ターミナル操作の速さと自律性」で勝るという棲み分けだ。プロジェクトの性質によってどちらが効くかが変わる、という話になる。

僕の所感

ベンチマークは「きれいな問題」を解かせているに過ぎない。現場では「仕様が曖昧」「既存コードが汚い」「依存関係が壊れている」といったカオスが日常だ。その中で使った実感としては、Claude Codeのほうが「なぜこの実装にしたか」を説明してくれる分、コードレビューが楽になる。Codexは黙々と動くが、意図が読めないコードが出てくることがある。チームで使うならClaude Codeのほうが結果的に時間を節約できる場面が多い。

料金──「安い」の定義が人によって違う

料金比較は単純な表にしても意味がない。使い方によってコストの出方がまるで違うからだ。

Claude Codeの料金構造

Anthropicの公式料金ページ（Claude API Pricing）と、AI総合研究所の分析記事（Claude Codeの料金体系ガイド）から具体的な数字を引く。

サブスクリプション： Proプランが月額$20（年払いで$17/月）、MaxプランがProの5倍枠で月額$100、20倍枠で月額$200。MaxプランでないとOpus 4.6モデルにはアクセスできない。

API従量課金： Opus 4.6は入力$5/百万トークン、出力$25/百万トークン。Sonnet 4.6は入力$3/百万トークン、出力$15/百万トークン。Anthropicの公開データによると、平均的な開発者のClaude Code利用額は1日あたり約$6、90%のユーザーが$12/日以下に収まっている（LaoZhang AI: Claude Code Pricing Guide 2026、Uravation: Claude Code料金プラン完全比較）。

ここで気をつけたいのは、Proプラン（$20/月）でOpusを常用しようとすると、あっという間に利用上限に達するという点だ。ある開発者ブログでは「全部Opusでいい。月$200でモデル選びから解放される」という割り切った運用が紹介されており（ゆろぐ: Claude MAX Opus脳死法）、ヘビーユーザーにとっては$200/月が実質的な「本気プラン」になっている現実がある。

Codexの料金構造

ChatGPT Plus（月額$20）にCodexアプリの利用枠が含まれているのが最大の強みだ。つまり既にPlus会員なら追加コストゼロで始められる（OpenAI Help Center: ChatGPTプランでCodexを使う、AI総合研究所: Codexとは？）。

API従量課金では、codex-mini-latestが入力$1.50/百万トークン、出力$6.00/百万トークン。Claude Sonnet 4.6と比較すると、入力で半額、出力で4割安い。同じリファクタリングタスクをClaude CodeとCodexで回すと、Codexのほうがトークン消費が3〜4分の1で済むケースが多いという検証結果もある（playpark: Claude Code vs Codex 料金・性能実測比較、playpark: AIコーディングツール料金比較）。

結局コスパはどうなのか

ここは正直に書くと、「安さで選ぶならCodex一択」だ。ただし安さとコード品質はトレードオフの関係にある。Codexで出てきたコードを自分でレビュー・修正する時間を時給換算すると、最初からClaude Codeに高品質なコードを出させたほうが安くつく──そういうケースは珍しくない。

僕の感覚では、ソロ開発で「まず動くもの」を量産するフェーズならCodexのコスパが光る。チーム開発でPRの品質を一定水準に保ちたいならClaude Codeの$100〜$200/月は十分ペイする。

現場でのつまづき──ドキュメントには書いていない地雷

ここからが本題だ。公式ドキュメントを読んで「よし、使おう」と思った瞬間から、想定外のトラブルが始まる。

Claude Code：サーバー障害が「3日に1回」の現実

2026年3月時点で、Claudeの過去90日間の稼働率は99.04%。数字だけ見ると悪くないが、実際にはこの期間に91件のインシデントが記録されている。3月だけでも3/2、3/11、3/26〜27と大規模障害が3回発生した（エラー大全集: Claude Code大規模障害、Uravation: Claude障害の確認方法と対策完全ガイド）。

2026年3月2日の障害では、HTTP 500（システム処理不能）とHTTP 529（過負荷）が同時に発生し、Webインターフェース・モバイルアプリ・APIアクセスの全経路が一時的にダウンした。Business Insider Japanの報道では、ある開発者が「原始人のように自分でコードを書くしかなかった」とコメントしている（Business Insider Japan: Claudeの障害で開発者はAIへの依存を痛感、did2memo.net: Claude will return soonエラー）。

障害の根本原因について、WildCardの分析記事ではChatGPTからの大量乗り換えとApp Store 1位による爆発的なユーザー増加を挙げており、無料ユーザー数が1月比で60%超増加した「成功の代償」だと指摘している（WildCard: Claudeの障害が多すぎる原因と対処法、Codebook: AnthropicのClaudeが世界的な障害でダウン）。

これは笑い話ではなく、ビジネスにおけるリスクだ。Claude Code一本に依存している開発チームは、障害のたびに作業が完全に止まる。

Claude Code：コンテキスト肥大化による性能低下

もう一つ、使い込むほどハマるのがコンテキストウィンドウの肥大化問題だ。Claude Codeはプロジェクトのファイルを読み込んでコンテキストに積んでいくが、セッションが長くなるとレスポンスが目に見えて遅くなる。あるnote記事では、「1ヶ月かけてようやく原因を突き止めた」として、claude-mem（メモリ機能）との併用時にフリーズが頻発するケースが詳しく報告されている（note: Claude Codeが急に遅くなる原因、SIOS Tech Lab: Claude Codeが遅い？毎回検索をやめて実行速度を劇的改善）。

公式のトラブルシューティングページにも、コンテキスト管理の重要性は記載されているが（Claude Code Docs: トラブルシューティング）、「タスクが変わったら/clearしろ」「CLAUDE.mdに必要な情報を静的ファイルとして書いておけ」という対処法は、正直なところ事前に知らないと気づけない。

Codex CLI：macOSの「サンドボックスの罠」

Codex CLIで最初にぶつかる壁は、サンドボックスのネットワーク制限だ。デフォルトのworkspace-writeモードではネットワークアクセスが無効になっていて、npm installすら動かない。「え、なんで？」と思って~/.codex/config.tomlに設定を追加する──ここまでは公式ドキュメント通りだ（OpenAI Developers: Sandboxing、OpenAI Developers: Configuration Reference）。

[sandbox_workspace_write]
network_access = true

ところがmacOSではこの設定が効かない。これはGitHubのIssue #10390として報告されている既知の問題で、macOSのSeatbelt Sandboxがconfig.tomlの設定に関係なくOSレベルでネットワークをブロックしてしまう（GitHub Issue #10390: macOS seatbelt sandbox ignores network_access、SmartScope: Fix Codex CLI Network Access Restricted）。

イシューの報告者によると、mainブランチのソースコード上ではネットワーク許可の処理が正しく実装されているが、リリースバイナリに反映されていない可能性があるとのこと。つまり「コードは直っているのにバイナリが古い」というバージョン不一致が原因かもしれない、という厄介な状態だ。

Codexアプリ：クラウドサンドボックスの「見えない壁」

Codexアプリのクラウド実行環境には、もう一つ致命的な制約がある。外部インターネットへのアクセスが一切できない。 リポジトリ内のコードと事前定義された依存関係だけで処理が完結する設計になっている（OpenAI: Introducing the Codex app、eesel AI: GitHubとのOpenAI Codex統合）。

つまり外部APIを叩くテストコードは実行できないし、ランタイムで外部サービスに接続するコードの動作検証もできない。ローカルファイルだけの利用もNGで、GitHub連携が必須だ。並列実行の効率が注目されがちだが、この制約を理解していないと「なぜかタスクが失敗する」と頭を抱えることになる。

独自の工夫点──現場で編み出したワークアラウンド

Claude Codeの障害対策：「二刀流」運用

僕がたどり着いた結論は、Claude CodeとCodexを「メインとバックアップ」で持つことだ。Claude Codeの障害は事前に予測できないが、Anthropicのステータスページを確認すれば全体障害かどうかは数分でわかる。全体障害ならCodexに切り替え、復旧したら戻る。このフローを最初から組んでおけば、業務が完全に止まることはない（Uravation: Claude障害の確認方法と対策完全ガイド、did2memo.net: 公式の障害情報を確認する方法）。

Claude Codeの性能維持：CLAUDE.mdとコンテキスト管理

コンテキスト肥大化への対策は、以下の3つを徹底することで大幅に改善した。

1. タスクの切り替え時に/clearを実行する。 認証機能→検索機能のように作業対象が変わったら、必ずコンテキストをリセットする。これだけでレスポンス速度が明確に回復する（Qiita: Claude Codeの基本を10分でマスター、Zenn: "あの頃"の強かったClaude Codeを少しでも取り戻す方法）。

2. CLAUDE.mdにプロジェクト情報を静的に書いておく。 毎回WebSearchで情報を取りに行かせるのではなく、プロジェクトの構成・ルール・ワークフローをファイルとして用意しておく。エス・エム・エスのテックブログではこの手法を体系的に紹介しており、「Why（なぜこのシステムか）」「Map（どこに何があるか）」「Rules（何をして良い/ダメか）」「Workflows（どうやって作業するか）」の4要素を記述することを推奨している（エス・エム・エステックブログ: Claude Codeの性能を引き出すワークフロー設計、Qiita: Claude Codeの設定はどう作る？）。

3. モデルを使い分ける。 複雑な設計判断はOpus、設計に納得したら実装はSonnet、単純な修正はHaiku。これでコストを抑えつつ品質を維持できる（Claude Code公式ベストプラクティス、cloudpack: Claudeの料金プラン完全ガイド）。

Codex CLIのmacOS問題：CLIフラグで強制突破

config.tomlが効かないmacOSでは、CLIフラグで直接サンドボックスを緩和するしかない。

codex --sandbox danger-full-access "your prompt"

日常的に使うなら、シェルにエイリアスを仕込んでおくと楽だ。

alias codex='CODEX_SANDBOX_NETWORK_DISABLED=0 codex --sandbox danger-full-access'

ただしdanger-full-accessはその名の通り、サンドボックスの保護を完全に外す。信頼できるリポジトリでしか使ってはいけない。未知のOSSリポジトリでこれをやるのは、sudoでrm -rfを走らせるのと同じくらい危険だ（GitHub Issue #10390、OpenAI Developers: Agent approvals & security）。

もう一つの選択肢として、Codexの組み込みweb_searchツールはプリキャッシュされたインデックスを使うため、network_accessの設定に関係なく動作する。外部情報が必要な場面ではこちらを活用すれば、サンドボックスを緩和せずに済むケースもある（Blake Crosley: Codex CLI: The Definitive Technical Reference、OpenAI Developers: Sandboxing）。

用途別おすすめ──「どっちがいいか」への最終回答

CARTA HOLDINGSのテックブログで紹介されている「Claude Code × Codex 機能開発フロー」は、実務での使い分けとして非常に参考になる（CARTA TECH BLOG: Claude Code と Codex を使った機能開発フローの紹介）。また、noteの1000時間検証レビューでは、フェーズごとの使い分けが体系的にまとめられている（note: Claude/Codexを使い分ける：1000時間検証して分かった用途別ベストプラクティス）。

これらの知見と自分の経験を合わせて、僕なりの使い分けはこうだ。

Claude Codeに任せる場面

複雑なリファクタリングや設計判断が絡むタスク。 Claude Codeはプランモードで「なぜそうするのか」を言語化してくれるので、設計ミスを事前に防ぎやすい。チームのPR品質を一定水準に保ちたいなら、実装フェーズの最終確認とドキュメント化はClaude Codeに任せるのが間違いない。

初めて触るコードベースの調査。 100万トークンのコンテキストウィンドウ（約25,000〜30,000行のコード）を一度に読み込めるのは、レガシーコードの全体把握で圧倒的なアドバンテージになる（NxCode: Claude AI 2026、Claude Code公式: 仕組み）。

Codexに任せる場面

大量のファイルを一括で変更するタスク。 マイグレーション、依存関係の更新、ボイラープレートの生成。Codexアプリの並列実行はこの手のタスクで真価を発揮する。先述の「2日間で80本のPR」はまさにこのパターンだ（Qiita: Codexをフル活用して2日間で80個近くのプルリクエストを作った話、note: OpenAI Codexで複数AIエージェントを並列稼働）。

コストを抑えたい定型作業。 トークン効率がClaude Codeの3〜4倍という検証結果を踏まえると、テストコードの追加や定型的なCRUD実装のような「考える」より「書く」が中心のタスクはCodexのほうが経済的だ（playpark: Claude Code vs Codex 料金・性能実測比較、fyve: Claude Code・Cursor・Codex 使い分け完全ガイド）。

個人的に推す「ハイブリッド運用」

最終的に一番効率が良いと感じているのは、調査・設計はClaude Codeのプランモード → 実装はCodex → レビュー・ドキュメント化はClaude Codeという流れだ。nozomu-techのSpeaker Deckでも同様のアプローチが紹介されている（Speaker Deck: Codexを使い倒して気づいた、Claude Codeの本当の強みと使いこなし術、CARTA TECH BLOG: Claude Code と Codex を使った機能開発フロー）。

一つのツールに固執する理由はもうない。Claude Codeの「深さ」とCodexの「速さ」を組み合わせたほうが、どちらか一方だけを使うより確実に生産性が上がる。それが数ヶ月間、両方を使い倒して出した僕の結論だ。