メインコンテンツへスキップ

Claude Code と Codex の選び方:コスト、上限、遅い応答

17 分で読めますAI 開発ツール

月額だけで Claude Code と Codex を比べてはいけません。token 予算、応答速度、review 速度、上限到達後の復帰を分けて判断します。

Claude Code と Codex をコスト、上限、速度、token 予算、context 引き継ぎ、安定性、コード品質で比較する判断ボード

Claude Code の token 予算、Claude Code と Codex の上限差、または Claude Code の応答が遅いことが問題なら、最初に「どちらが強いか」と聞かないほうが安全です。まず詰まっているものを分けます。token 予算なのか、対話の遅延なのか、自律実行の完了速度なのか、review 速度なのか、上限に当たった後の復帰なのかで答えは変わります。

2026年7月8日時点の実用的な結論はこうです。月20ドルで迷うなら、幅広い Codex surface と見える利用枠を試せる Codex Plus から始めます。ただし、日常の中心がローカルの長い探索、権限ルール、細かい会話であれば Claude Pro と Claude Code のほうが合います。月100ドルや200ドルでは、Claude Max と Codex Pro をブランドで比べず、Claude Code の長い対話が多いのか、Codex の委任、cloud task、review が多いのかで分けてください。

切り替え時の context もまだ重要です。Codex と Claude Code を切り替えても作業を失いたくないなら、会話全文を次の agent に渡すのは避けます。渡すべきなのは、repo のルール、今回の task、触った file、実行した command、失敗した証拠、決めたこと、次にやるべきことです。コードの事実は Git に置き、長く残すルールは AGENTS.mdCLAUDE.md に置きます。

すぐ使える選び分け

状況最初の候補理由
途中で二つのツールを切り替える先に handoff packet次の agent が長い transcript から判断を推測する状態を避ける。
月20ドルで広く試したいCodexPlus で web、CLI、IDE、iOS、cloud integration、review を試せる。
月20ドルでローカル作業が中心Claude Code長い対話、ローカル状態、権限ルールに向く。
月100ドルで Claude セッションが重いClaude Max 5xClaude の作業容量を増やす選択。
月100ドルで Codex task と review が多いCodex Pro 5xCodex の五時間窓と作業カテゴリを増やす選択。
月200ドルで並列作業が多い役割で併用Max 20x は大きい Claude セッション、Codex Pro 20x は委任向き。
チームで両方使うrouting ruleツール統一より作業の分流が重要。

Context 引き継ぎ:切り替えても作業を失わない

信頼できる context は、片方のチャット履歴ではなく、両方のツールが読み直せる場所に置きます。Codex は AGENTS.md の project guidance を読みます。Claude Code は AGENTS.md ではなく CLAUDE.md を主に読みます。すでに AGENTS.md がある repo では、CLAUDE.md から @AGENTS.md を import し、Claude 専用の注意だけを下に足すのが安全です。

Context の層置き場所引き継ぎルール
repo の長期ルールAGENTS.md と、それを import する CLAUDE.md同じルールを二重管理しない。
今回の task 状態issue、PR note、HANDOFF.md目的、進捗、失敗、次の行動を書く。transcript 全文は不要。
コードの事実Git diff、branch、test output、log次の tool は file と検証結果から始める。
権限と安全task packet の許可/禁止範囲API key、token、private log は貼らない。
長期記憶繰り返すルールだけ一回限りの作業ノイズを policy にしない。

最小の packet はこれで十分です。

md
## Agent handoff packet Goal: Current state: Files touched: Commands/tests run: Known failures: Decisions already made: Do not redo: Next best action: Safety/permissions:

良い handoff は「上の続き」ではありません。どの test が落ちているか、どの file を触ったか、何を変更してはいけないか、次にどの command を走らせるかを書きます。これなら Claude Code の探索を Codex が implementation task として受け取れますし、Codex の diff を Claude Code がローカル文脈で説明できます。

チームで使うなら、handoff packet に三つの項目を追加します。まず Git status を明記し、committed、dirty、untracked、agent が作った一時 file を分けます。次に「やり直さないこと」を書きます。たとえば auth flow を再設計しない、重い migration を再実行しない、reviewer が受け入れた file を触らない、という禁止です。最後に、二つ目の tool の責任を狭くします。Codex は reviewable diff と検証 command を返す。Claude Code はローカル失敗、permission boundary、曖昧な設計判断を説明する。ここまで書くと、切り替えは会話の持ち越しではなく、レビュー可能な工程になります。

上限、token、実作業時間の見方

開発者向けの比較では「Claude Code 100 hours vs Codex 20 hours」や「5-hour limit」のような言い方が出てきます。これはユーザーの痛みを表しますが、そのまま計算式にはできません。実作業時間は、再送される context、選ぶ model、local か cloud か、最後に人間が review する時間で変わります。

Codex は容量を帳簿にしやすいです。OpenAI の現行 Codex pricing は、local messages と cloud tasks が五時間窓を共有し、追加の weekly limits もあり得ると説明します。同じ message でも、model、repo の大きさ、複雑さ、実行面によって重さが変わります。残りパーセントだけでなく、完了 task、accepted diff、失敗 branch、review 時間を記録してください。

Claude Code は一つの session を操縦しやすい一方で、session が伸びるほど消費も伸びます。Anthropic の説明では、各 turn がこれまでの会話、project context、新しい prompt を送ります。読んだ file、作った diff、議論した判断が後続 turn に乗ります。'/clear'、'/compact'、model choice、不要な tool の停止は、実作業時間を伸ばすための操作です。

比べるべき指標は「1ドルあたり何時間」ではなく、「limit に当たる前に何個の受け入れ可能な作業単位を得たか」です。Claude Code が難しい原因調査を二つ片付け、Codex が六つの branch を返すなら、どちらも価値があります。自分の workflow で復旧しやすい limit を選んでください。

実測するときは、task の目的、agent が読んだ・変更した範囲、人間の review 時間、main branch に入ったかどうかを同じ表に残します。Claude Code の価値は、迷いを減らして正しい方向へ早く寄せることに出やすいです。Codex の価値は、task を queue に積み、失敗 branch を捨てやすいことに出やすいです。この二つは単純な時間割り算だけでは比べられません。

もう一つ見るべきなのは中断コストです。Claude Code で limit に当たると、ローカル調査の流れをもう一度作り直す必要があります。Codex の失敗は branch を捨てれば済む場合もありますが、setup や review の待ち時間は残ります。limit hit の回数だけでなく、作業へ戻るまでの時間も記録してください。

Claude Code と Codex の上限、token 消費、実作業時間をそろえて比較するルーター

利用枠:一つの数字にまとめない

Codex の現行ドキュメントは、利用枠をかなり細かく分けて見せています。OpenAI の Codex pricing では Plus が月20ドルで、週に数回の集中した開発 session 向けと説明されています。含まれるのは web、CLI、IDE extension、iOS、automatic code review や Slack などの cloud integration、そして GPT-5.5、GPT-5.4、GPT-5.4 mini です。

大事なのは、Codex の上限が local messages、cloud tasks、code reviews、model choice に分かれることです。フォーラムで「Codex は上限が多い」「すぐ切れる」と言われても、どのモデル、どの作業カテゴリ、どの時間窓なのかを見ないと判断できません。

Claude Code は別の読み方になります。Claude Code usage のドキュメントは、まずサインイン方法で metering が変わると言います。Enterprise seat は組織プラン内の使用量、API key は token 課金です。また、長い会話は context window を消費し、品質にも影響します。'/clear' は別タスクに移るとき、'/compact' は長い作業を続けるときに使うべき操作です。

Anthropic は 2026年5月6日に Claude Code の五時間 rate limit を Pro、Max、Team、seat-based Enterprise で倍増し、Pro と Max の peak-hours reduction も取り除きました。古い limit 体験をそのまま現在に当てはめるのは危険です。ただし、増えた上限は無制限ではありません。

コスト:表示価格だけでは足りない

価格表だけを見ると似ています。Claude Pro は月20ドル、Max 5x は月100ドル、Max 20x は月200ドル。Codex Plus は月20ドル、Codex Pro は月100ドルからで、Plus より大きい制限が用意されています。

しかし実コストは下の層で変わります。Claude Code は subscription でも使えますが、API key で動かすと token 消費に応じた課金になります。Anthropic の cost docs は、Pro と Max の subscriber は使用量が subscription に含まれ、'/usage' の dollar figure は請求額ではないと説明しています。企業利用では、active developer day あたり約13ドル、月150から250ドルという目安も出ていますが、model、codebase size、複数 instance、automation、context が大きく左右します。

Codex は個人にとって入り口が単純です。Plus と Pro に Codex が含まれます。ただし、GPT-5.5 local messages、cloud tasks、review は有限の作業枠を使います。API 請求ではなくても、scarce capacity を使っている点は変わりません。

最初は一か月だけ20ドルで試し、実測メモを残してください。どの作業で上限に近づいたか、どの diff が review しやすかったか、どのツールが無駄な修正を少なくしたか。この記録なしに100ドルへ上げると、改善ではなく期待を買うことになります。

速度:遅い応答はアップグレード前に切り分ける

速度は一種類ではありません。Claude Code は、曖昧な local 調査を一つの terminal session で進めるときに速く感じます。権限、repo 状態、連続した修正指示、人間の判断が同じ場に残るからです。Codex は、task が明確で branch、cloud task、review として返せるときに速くなります。遅い応答は、plan 不足ではなく context、model、effort、tool 負荷、task 粒度の問題かもしれません。

症状最初に見るもの次の動き
Claude Code の長い session が遅くなった会話履歴、読んだ file、生成した diff、Opus/Fable/high effort、MCP/tool の数/usage を見て、同じ task なら /compact、別 task なら /clear。routine work は Sonnet や Haiku に下げる。
Claude Code の token 予算が早く減る貼り付けた log、広すぎる CLAUDE.md、不要な tool、巨大 contextfile 参照に変え、log を削り、不要な MCP を止め、task を小さくしてから upgrade を考える。
Codex task が遅いtask scope、cloud setup、model choice、review 待ち、AGENTS 指示の長さ小さい acceptance unit に分け、repo 指示を短く保ち、routine work は軽い model を使う。
Fast mode を使いたいOpenAI は対応 model が速くなる一方で credit 消費も上がると説明しているlatency そのものが blocker の時だけ使い、全 prompt の標準にしない。
両方遅いstatus incident、account rate limit、model capacity公式 status を見て、低リスク task や別 route に切り替える。

Claude Code では、遅い応答と token 予算は同じ根から出ることが多いです。context が長いほど後続 turn は重くなり、effort が高いほど丁寧になる代わりに遅くなります。Codex では、速度は throughput に近いです。五時間窓や週上限の前に、どれだけ review 可能な branch、fix、review を返せるかを見ます。

アップグレード前には、少なくとも三つのログを残します。Claude Code の session がどの時点で遅くなったか、Codex の task が prompt から reviewable diff まで何分かかったか、limit hit 後に作業へ戻るまで何分かかったかです。三つのログが同じ bottleneck を指しているなら plan 変更を検討し、ばらばらなら task 分割、context 削減、model 選択を先に直します。

さらに、結果の速さと説明の速さを分けて見ます。Claude Code が早く方針を説明しても、test を通すまで何度も戻るなら実作業は速くありません。Codex が返答まで待たせても、branch が小さく、test が通り、review comment が少ないなら全体は速いことがあります。会話の体感ではなく、merge 可能な単位で測ることが重要です。

安定性:印象ではなく status を読む

安定性とコード品質の判断ボード

2026年7月8日、OpenAI の status は FedRAMP workspace の問題を表示し、Codex と隣接する workspace/admin surface に影響がある状態でした。一方で、Codex の April-July 2026 の aggregate uptime は約 99.96% と出ています。これは矛盾ではありません。全体の uptime が高くても、今日必要な surface が痛むことはあります。

同じ日に Claude の status は Claude Code operational で、7月8日の incident は表示していませんでした。ただし 7月7日と7月6日には model、Claude.ai、login に関係する resolved incidents がありました。Claude が長い reasoning に強いことと、最近の障害がないことは同じ意味ではありません。

重要な作業では fallback を先に決めます。対話型の作業は中断が痛いので、小さい代替 task や別モデルを用意します。非同期 task は時間ロスが痛いので、捨てやすい branch と review checkpoint を使います。

コード品質:モデル名ではなく作業ループを見る

OpenAI は GPT-5.5 について、agent 型開発が強く、Codex tasks で少ない token で結果を出し、GPT-5.4 より開発評価が改善したと説明しています。Codex の強みは、明確な task を委任し、tool で確認し、reviewable diff にする場面で出やすいです。

Anthropic は Claude Opus 4.8、Sonnet 5、Fable 5 について、complex agentic coding、enterprise engineering、通常作業向けの選択肢を説明しています。Claude Code では model と effort の選び方が品質と速度の両方に影響します。難しい作業で深く考える設計は価値がありますが、routine work まで高 effort にすると、遅さと token 消費も増えます。

実務では四つのテストをしてください。既存テスト付きの bug、未コミット状態を含む refactor、明確な async implementation、危険な変更を拒否する review。勝つのは、もっとも自信満々の答えではなく、reviewable diff、少ない手戻り、よい検証、明確な不確実性を出すツールです。

権限と安全境界

Claude Code は permission vocabulary が細かいです。allow、ask、deny rules を設定でき、version control に入れて組織へ配布できます。mode には 'default'、'acceptEdits'、'plan'、'auto'、'dontAsk'、'bypassPermissions' があります。'bypassPermissions' は隔離環境向けです。

Codex は説明しやすい境界を持ちます。Codex cloud は OpenAI-managed container で動き、setup phase では依存関係を入れられ、agent phase はデフォルトで offline です。CLI と IDE は OS-level sandbox を使い、デフォルトでは network なし、書き込みは active workspace に限定されます。Auto preset は作業ディレクトリ内での read、edit、command を自動化し、外部書き込みや network は approval を求めます。

細かいローカル権限を組織で設計したいなら Claude Code。少ない preset と local/cloud の説明しやすさを優先するなら Codex です。

使い分けワークフロー

Claude Code と Codex のハイブリッド workflow と停止ルール

不確実な最初の一時間は Claude Code が向きます。repo を読み、失敗を見て、仮説を検証し、どこを変えるべきか決める。作業が明確になったら Codex に渡し、branch、review、test 付きの task として走らせます。

Claude Code を止めるべきなのは、context が膨らみすぎたとき、同じ案を繰り返すとき、task が十分に整理されたときです。Codex を止めるべきなのは、repo 固有の文脈を何度も落とすとき、途中 steering が必要すぎるとき、diff が review しにくいときです。

購入前の1週間テスト

最初の判断は、1回のデモではなく1週間の記録で行います。初日は低リスクのタスクだけにします。Codex には範囲が明確な修正を渡し、Claude Code にはよく知っているローカルリポジトリを読ませます。この段階で見るべきなのは「賢そうに話すか」ではありません。どの程度早く使える diff になるか、どの時点で利用枠に当たるか、文脈が長くなったときに出力が雑になるか、レビューしにくい巨大 diff を作らないかです。

2日目から4日目は、タスクを3つに分けて試します。ひとつ目は委任できる作業です。テスト追加、明確な bug 修正、設定移行、レビュー指摘の反映などは Codex に向きます。結果が branch、ログ、diff として戻ってくるため、失敗しても捨てやすいからです。ふたつ目は方向を見ながら進める作業です。歴史的な負債を読む、未コミット状態を含む修正を考える、失敗の根本原因を探す、といった作業は Claude Code のほうが自然です。三つ目は、まだ人間が問題を定義できていない作業です。これはどちらにも直接投げず、目的、失敗条件、実行コマンド、変更禁止範囲を先に書きます。

5日目以降はコストを見ます。月額だけでなく、使える成果ひとつ当たりのコストで比べます。20ドルのプランでも、毎週の機械的レビューを減らせるなら十分に価値があります。逆に100ドルのプランでも、返工が増えるだけなら高い買い物です。記録する項目は、使えた diff の数、全面的に書き直した数、limit や待ち時間に当たった回数、agent の出力が原因で余分に調査した回数です。この記録が、SNS の勝敗論よりもあなたのチームに近い答えになります。

アップグレード前の質問は単純です。足りないのは Claude Code の長いローカル会話なのか、それとも Codex の委任・レビュー枠なのか。前者なら Claude Max を検討し、後者なら Codex Pro を検討します。どちらを選んでも固定ではありません。作業の形が変われば、予算配分も変えるべきです。

チームでの導入メモ

チームでは、まずツール名ではなくタスク種別を決めます。local-investigation は Claude Code に寄せます。担当者がローカルでテスト、権限範囲、停止条件を見ながら進めるべき作業だからです。delegated-implementation は Codex に寄せます。目標ファイル、検証コマンド、変更禁止ディレクトリ、期待する diff の大きさを書ける作業だからです。review-only は Codex review または Claude Code の補助説明に使えますが、採用判断は人間が持ちます。blocked-human-decision は agent に渡しません。まだ問題の所有者が決まっていないためです。

安定性も抽象語で終わらせません。「不安定だった」ではなく、ログイン失敗、rate limit、クラウドタスク失敗、ローカル権限ブロック、出力品質低下、レビュー遅延、モデル切替後の変化として記録します。日付、プラン、モデル、作業種別、影響を残すと、数週間後にはどちらを標準化すべきかではなく、どの作業をどちらに流すべきかが見えてきます。

すでに両方を契約している場合も、同じタスクを二重に走らせて「見た目が良い方」を選ぶ使い方は避けます。主経路と検証経路を分けます。たとえば安全に関わる変更は Claude Code でローカル調査を行い、Codex に独立 review をさせる。依存関係の機械的更新は Codex で branch を作り、失敗した test の説明を Claude Code に求める。比較するのは全体の好みではなく、ひとつの検証質問だけです。

このルールは issue テンプレートにも入れられます。主経路、検証経路、検証する質問、停止する時間を先に書けば、二つの agent が同じ実装を競うのではなく、別々の責任を持つようになります。

検証経路が見つけた問題が実装ではなくタスク定義の曖昧さなら、次はモデルを強くするのではなく、人間が条件を分解し直します。

この判断を残すことで、次の選定も同じ基準で見直せます。

よくある質問

Claude Code は AGENTS.md を直接読めますか?

主入口としては読みません。Claude Code は CLAUDE.md を読みます。Codex 用に AGENTS.md がある repo では、CLAUDE.md@AGENTS.md を import して、共有ルールを一か所に寄せます。

Codex の transcript 全文を Claude Code に貼るべきですか?

貼るべきではありません。目的、file、command、failure、決定事項、繰り返してはいけないこと、次の action を handoff packet にします。残りの context は repo、diff、test、task packet に置きます。

月20ドルならどちらから始めるべきですか?

広く試すなら Codex Plus です。ローカルで長く操縦する仕事が中心なら Claude Pro と Claude Code が合います。

Claude Code はまだ limit に当たりますか?

当たります。5月の増枠は大きいですが、context、model、effort は引き続き消費を左右します。

コード品質はどちらが上ですか?

委任して review する作業は Codex、ローカルで深く操縦する作業は Claude Code が有利です。品質は model だけでなく、テスト、review、context hygiene、停止判断で決まります。

安定しているのはどちらですか?

重要作業前に status を見てください。2026年7月8日、OpenAI には Codex surface を含む FedRAMP workspace 問題がありました。Claude Code は同日 operational でしたが、7月7日と7月6日に resolved events がありました。重要なのはブランド名ではなく、login、model availability、cloud task、local CLI、review のどこが必要かです。

チームは一つに統一すべきですか?

多くの場合は統一しないほうがよいです。探索とローカル制御は Claude Code、明確な委任と review は Codex、という routing rule のほうが実用的です。

ビジュアルはルーティング補助であり、リアルタイムの価格表や上限表ではありません。この比較を予算に変える前に、日付付きの公式プラン、上限、速度、モデル、status ページを再確認してください。

#Claude Code#Codex#OpenAI#Anthropic#AI コーディング
Share: