Cursor vs Codex 2026年版：ワークフロー、料金、利用上限、On-Demand Usageを比較
IDEの中でコードを読み、編集し、差分を細かく確認しながら進めるならCursorが向いています。完了条件を定義したタスクをローカルまたはクラウドのエージェントに委任するならCodexが向いています。本記事では、2026年時点のワークフロー、料金、利用上限、権限、チーム管理、カスタムAPIの違いを整理します。
目次
実務上の結論から言うと、 作業の大半をIDE内で行い、コードを読みながら小さく修正し、差分をその都度確認したいならCursorが向いています。完了条件を明確にしたタスクを渡し、エージェントにリポジトリ調査、ファイル編集、テスト実行まで任せ、あとで結果をレビューしたいならCodexが向いています。
現在の比較は、単純な「エディタ対コマンドライン」ではありません。CursorにはAgent、CLI、Cloud Agents、projects、バックグラウンドワークフローがあります。CodexもCLI、IDE拡張、デスクトップアプリ、Web、クラウド環境から利用できます。本当の違いは、エージェントと並走してコーディングするか、それともひとまとまりの仕事をエージェントに委任するかです。
本記事の料金と利用条件は2026年9月18日に確認しました。プラン、モデル、上限は変更される可能性があります。契約前にCursorのmodels and pricingとCodex公式料金ページで最新条件を確認してください。
CursorとCodexの早見表
| 比較項目 | Cursor | Codex |
|---|---|---|
| 基本ワークフロー | エディタ内でエージェントと共同作業し、変更を逐次レビューする | ローカルまたはクラウドのエージェントに成果物ベースのタスクを委任する |
| 主な利用画面 | Editor、Agent、CLI、Cloud Agents、projects | CLI、IDE拡張、デスクトップアプリ、Web、cloud |
| コンテキスト | 開いているファイル、選択範囲、project rules、codebase search | 作業ディレクトリ、リポジトリ、AGENTS.md、IDE context、cloud environment |
| 編集スタイル | inline edit、Tab、visual diff、反復的な複数ファイル編集 | モジュール横断タスク、テスト、script実行、長時間処理、PR中心の作業 |
| バックグラウンド処理 | Cloud Agents、automations、parallel agents | local runs、cloud tasks、parallel delegation、code review |
| 権限管理 | command approval、rules、ignored files、team controls | sandbox、approval policy、network access、workspace policy |
| モデル | Cursorモデルと外部モデル。プラン内のusage poolで管理 | ChatGPTプラン内のモデルとcloud機能、またはAPI keyによる別課金 |
| 料金の考え方 | プラン内利用枠＋任意のon-demand課金 | ChatGPT利用枠、追加credits、またはAPI token課金 |
| 向いている人 | IDEに長時間滞在し、変更を対話的にレビューする開発者 | issue、terminal、自動化、受け入れ条件を軸に仕事を進める開発者やtech lead |
最大の違いはモデルではなく、仕事の進め方
Cursorは人間をコードの近くに置く
Cursorの自然な流れは、対象ファイルを開き、コードを選択し、Agentに変更を依頼し、diffを見てaccept、reject、refineするというものです。特に次のような場面に向いています。
- レガシーコードを読みながら小さな修正を重ねる。
- 複数ファイルをrefactorするが、各段階で止めて確認したい。
- Tab、Inline Edit、visual diffを頻繁に使う。
- UIを作り、プレビューを見ながら細かく調整する。
- Cursor rules、Skills、MCP server、チーム内規約をすでに整備している。
Cursorの強みは、エージェントが常に「より賢い」ことではありません。コード、terminal、context、reviewが同じ画面にあり、人間が途中介入しやすいことです。この近さが、密度の高いhuman-in-the-loopの作業に向いています。
Codexは定義済みの成果から始める
Codexが強いのは、作業を検証可能な依頼として表現できる場合です。たとえば次のような仕事です。
- 初めて見るリポジトリを調べ、ログインcallbackのidempotency bugを特定する。
- 複数ファイルを変更し、既存テストを実行する。
codex exec、script、CIから同じ処理を再実行する。- 隔離環境で長いタスクを動かし、あとで結果を確認する。
- issueを受け取り、実装、検証、変更要約、clean diffまで返す。
Codexは、委任内容が具体的であるほど力を発揮します。変更可能な範囲、やってはいけないこと、完了条件、検証方法を明確にすると結果が安定します。複数タスクを同時に管理するarchitectやtech leadにとっては、IDEで各編集を監督するより効率的な場合があります。
CursorとCodexの料金比較
「どちらも月額20ドル」という見出しだけで判断すると誤解が生まれます。両者はプラン内利用量の数え方が異なり、選ぶモデル、contextの大きさ、バックグラウンド処理、超過課金によって実際の費用が大きく変わります。
2026年9月時点の個人向けプラン
| 製品・プラン | 表示価格 | 利用枠の仕組み | 主な対象 |
|---|---|---|---|
| Cursor Hobby | 無料 | Agentの利用は限定的 | 試用、低頻度利用 |
| Cursor Pro | 月額$20 | Cursor ModelsとOther Modelsの別々のpoolを含む | 通常のAgent利用 |
| Cursor Pro+ | 月額$60 | Proより多いAgent利用枠 | 日常的にAgentを多用する人 |
| Cursor Ultra | 月額$200 | 高負荷・並列エージェント作業向け | power user、自動化 |
| Codex Free | 月額$0 | 小規模タスク向けの限定利用 | 評価、軽い作業 |
| Codex Go | 月額$8 | 軽量なcoding利用 | 利用頻度が低い人 |
| Codex Plus | 月額$20 | plan limit内でlocal、IDE、web、cloudを利用 | 週に数回の集中作業 |
| Codex Pro | 月額$100から | PlusのCodex利用枠のおよそ5倍または20倍 | 頻繁な作業、長時間タスク |
| API keyでCodexを利用 | 固定月額なし | 選択モデルのAPI料金で実使用tokenを課金 | CI、自動化、原価管理 |
Codexの「5時間上限」は何を意味するか
OpenAIは5時間ごとに処理できるlocal message数の目安を公開しています。ただし、固定されたmessage quotaではありません。大きなリポジトリ、長いsession、tool use、reasoning、retrieval、cacheされていないcontextは、1回の依頼でも多くの枠を消費します。
本記事確認時点で、GPT-5.6 Solの公式目安は次の通りでした。
| プラン | 5時間あたりのlocal message目安 |
|---|---|
| Plus | 10–100 |
| Pro 5x | 50–500 |
| Pro 20x | 200–2,000 |
Cloud chatはlocal messageより多くの枠を使う場合があり、週単位の上限も適用されることがあります。「100 messages」を「100個のタスクが完了する」と読み替えてはいけません。自分の代表的な作業を何度か実行し、usage dashboardで実測するのが最も確実です。
同じ月額$20でも体感が違う理由
Cursor Proの価値は、editor、Tab、Agent、visual review、一体化された作業体験に集中しています。Codex Plusは各種Codex画面を利用でき、対応するChatGPT planのlimitsを共有します。すでにChatGPT Plusを契約している人は、Codexを追加費用なしに近い感覚で使える場合があります。ただし、外部API keyだけでCursorのすべての体験を再現することはできません。
CursorのOn-Demand Usageとは
On-Demand Usageは、プランに含まれる月間利用枠を使い切った後も、従量課金でモデル利用を継続できる仕組みです。 リクエストが自動で遅いqueueや低品質tierに切り替わるわけではありません。対象モデルのAPI rateで処理が続き、追加利用分として請求に反映されます。
現在のCursor公式ドキュメントでは、月間利用枠を次の2つのpoolで説明しています。
- Cursor Models — Cursorが指定するモデル向けのpool。
- Other Models — 外部モデル向けのpool。各モデルのAPI価格を基準に使用量を計算。
古い記事ではFast Requests、Slow Pool、固定request数といった表現がよく見られます。これらは以前のrequest-based pricingの用語です。現在のアカウントでは、dashboardに表示される2つのpoolとon-demandの明細を基準にしてください。
On-Demand Usageの想定外請求を防ぐ方法
- CursorのWeb dashboardでSpendingを開き、2つのpool、残り枠、on-demand利用額を確認する。
- 含まれる利用枠を超えて継続したくない場合は、on-demandを無効にしておく。
- 有効にする場合は、個人またはチームプランで提供されるmonthly spend limitを設定する。
- 費用を予測しやすくしたいなら、すべてをAutoにせずモデルを手動選択する。
- 大きなAgentタスクは対象範囲を絞り、無関係なフォルダ走査、不要ファイル生成、全テストの反復実行を避ける。
- Cloud Agentとautomationの予算は別に確認する。バックグラウンド活動は見落としやすい。
画面上の名称はプランやclient versionで変わる場合があります。重要なのは、SpendingまたはBilling画面で、含まれる利用枠を超えた処理が許可されているかどうかです。
Cursorを選ぶべきケース
次の多くが当てはまるなら、Cursorが第一候補です。
- 1日の多くを1つのIDEでコードの読解と編集に使う。
- context、inline suggestion、partial diffをすぐ確認したい。
- UI開発、探索的実装、段階的なrefactorが多い。
- タスクに応じてモデルを切り替える。
- 小さな変更ごとに完全なtask specificationを書くのは面倒だと感じる。
- チームでeditor rules、plugins、MCP、Skills、privacy settingsを共有したい。
簡単な判断方法があります。AIが止まった直後、自分でキーボードを使って編集を続けますか。そうならCursorの方が自然に感じる可能性が高いです。
Codexを選ぶべきケース
次を重視するなら、Codexが第一候補です。
- 入力、境界、acceptance criteriaを明確にした依頼を書く。
- エージェントにリポジトリ調査、ファイル編集、command実行を任せる。
- CLI、script、SDK、CIから同じworkflowを再利用する。
- 長いタスクをisolated environmentで実行し、あとでレビューする。
- issue、failing test、pull request、technical debt queueから作業を始める。
- tech leadやarchitectとして複数タスクを並行管理する。
別の判断方法もあります。各行がどう変わったかより、タスクが完了し、検証されていることを優先しますか。そうならCodexの委任型workflowが向いています。
両方を使うなら、役割を分ける
現実的な分担例は次の通りです。
- Cursor：コード探索、UI実装、ローカル編集、即時diff review。
- Codex：長いtest run、モジュール横断refactor、一括修正、再実行可能な自動化。
2つの契約が有効なのは、役割が明確に異なる場合だけです。両方に同じ小さな編集をさせると、context switchingが増え、費用の帰属も分かりにくくなります。
CursorでBetterTokenのカスタムAPIを設定する
外部モデル向けのプラン内利用枠が足りない場合や、モデル費用を別管理したい場合、カスタムモデル設定を表示できるCursorアカウントとclient versionでは、OpenAI互換Base URLを利用できます。
外部API keyがカバーするのは、Cursorがbring-your-own-keyで対応している標準モデルフローです。Tab Completion、Cursor独自モデル、Cloud Agents、すべてのサブスクリプション機能を置き換えるものではありません。BetterTokenは独立したサービスで、CursorまたはOpenAIとは提携していません。
設定手順
Cursor Settings → Modelsを開く。API Keysまでスクロールする。Override OpenAI Base URLを有効にする。- 次のBase URLを入力する。
https://www.bettertoken.ai/v1- BetterTokenのkeyを
OpenAI API Keyに貼り付け、有効にする。 - モデル一覧を更新し、catalogに存在する完全なmodel IDを有効にする。例：
gpt-6-astra- chatに戻り、
Autoを無効にしてモデルを手動選択する。 - 大きな作業の前に小さなテストを送り、認証、モデル選択、usage recordを確認する。
現在の画面とトラブルシューティングはBetterTokenのCursor設定ガイドで確認できます。
重要な制約
Override OpenAI Base URLはglobal settingです。有効にすると、Cursorに設定済みの他のOpenAI、Anthropic、built-in model keyにも影響する場合があります。内蔵モデルが動かなくなったらoverrideを無効にして再確認してください。また、Cursorはモデルごとに別のBase URLを設定する仕組みを現時点では提供していません。
Codexのcustom providerには別のprotocol要件があります。Chat CompletionsだけでなくResponses APIをサポートする必要があります。互換設定ではwire_api = "responses"を使います。設定前にBetterTokenのCodex設定ガイドを確認してください。
同じタスクで両方を比較する
CursorとCodexに別々のpromptを与えてはいけません。小さなリポジトリを1つ選び、まったく同じ依頼を実行させます。次の例は、意図的に範囲を絞り、検証できる形にしています。
目標：ログインcallbackが重複して処理される問題を修正する。
変更可能な範囲：callbackのidempotency logicと、それに直接関係するtestsのみ変更する。
やってはいけないこと：ログインmodule全体をrefactorしない。依存関係をupgradeしない。他のauthentication methodを変更しない。
完了条件：同じcallbackが複数回届いても処理は1回だけ実行され、通常callbackの挙動は変わらない。
検証方法：ログインcallbackに関係するtestsだけを実行する。passしたら停止し、無関係なfull test suiteは実行しない。
編集前にリポジトリを調査し、変更予定のファイルを説明する。すぐにコードを変更しない。各実行で次を記録します。
- 正しいファイルを見つけるまでの時間。
- contextを追加した回数。
- 無関係なファイルが変更されたか。
- diffのレビューとrevertのしやすさ。
- 指定したtestsを実際に実行し、passしたか。
- commandまたはnetwork approvalを何回求められたか。
- dashboardに表示された利用枠またはAPI cost。
- 中断後、説明を最初から繰り返さずにresumeできたか。
一般的なランキングより、この方法の方が自分のworkflowに合うかを正確に判断できます。
チームではコード品質以外も比較する
チーム導入では次も確認してください。
- 管理者がユーザー別・モデル別の利用量を見られるか。
- budget設定とon-demand billingの無効化ができるか。
- model、privacy、network、command permissionを集中管理できるか。
- repository accessの付与、監査、取り消しをどう行うか。
- background taskの結果、PR review、logsがどこに保存されるか。
- custom API keyが個人secretなのか、組織管理credentialなのか。
Cursor Teamsは、集中請求、editor policy、共有workflowに強みがあります。Codexのteam controlは、ChatGPT workspace、利用する画面、API key利用の有無によって異なります。API keyだけではworkspace governanceの代わりになりません。
よくある質問
CursorとCodexはどちらが優れていますか？
すべてのケースで一方が優れているわけではありません。live code inspection、inline editing、段階的なdiff reviewにはCursorが自然です。明確なタスクを委任し、testsを実行して検証済み結果を受け取るならCodexが自然です。
Codexの料金はいくらですか？
2026年9月時点で、CodexはFree、Go、Plus、Pro、Business、Enterprise、またはAPI keyで利用できます。Plusは月額$20、Proは月額$100からで、Plusのおよそ5倍または20倍のCodex利用枠を選べます。API key利用はtoken数とモデル価格で課金されます。
CursorのOn-Demand Usageとは何ですか？
プランに含まれる月間利用枠を使い切った後の従量課金です。有効にすると対象モデルのAPI価格で処理が継続するため、Spending画面の確認とbudget設定が重要です。
CursorのOn-Demand Usageは無効にできますか？
はい。CursorのWeb dashboardでSpendingまたはBillingを開き、含まれる利用枠を超えた使用を許可する設定を無効にします。チーム管理者はmonthly spend limitも設定してください。画面名は製品更新により変わる場合があります。
CodexはCursorを完全に置き換えられますか？
CLI、IDE拡張、cloud task中心で、CursorのTabや独自機能に依存しない人なら可能です。手作業で継続的にコードを編集する人にとっては、完全な代替にならないことが多いです。
カスタムAPI keyですべてのCursor機能を使えますか？
いいえ。主に対応する標準モデルrequestをカバーします。Tab Completion、Cursor独自モデル、一部のAgentまたはcloud機能は、引き続きCursorのサービスとプラン利用枠を使う場合があります。
CursorとCodexを併用できますか？
できます。Cursorは対話的な編集とlocal review、Codexは長い委任作業、自動化、tests、一括変更というように役割を分けると効果的です。費用は別々に記録してください。
最終的な選び方
- Cursorを選ぶ：1日の多くをIDEで過ごし、即時context、inline支援、visual diffを重視する。
- Codexを選ぶ：仕事を明確な依頼として書き、エージェントに独立した実行と検証を任せたい。
- 両方を使う：一方がlive collaboration、もう一方がbackground delegationを担当する場合だけ。
- 費用を管理する：月額だけでなく、モデル、タスク長、含まれる利用枠、on-demand課金、追加credits、API billingを見る。
最も確実な決め方は、同じリポジトリ、同じタスク、同じ受け入れ条件で、両方を一度ずつ実行することです。
