Claude Code vs Cursor: どちらのツールも 1 つの利用環境に縛られなくなった今、開発者が仕事を分ける 7 つの方法

2026 年 10 月 12 日から、開発者は 1 つの Cursor ウィンドウで同じ Claude モデルを 2 回開き、それぞれ別の方法で支払えるようになりました。Anthropic 純正の拡張機能である Claude Code パネルに Claude のプランでサインインしていれば、利用分はそのプランに計上されます。Cursor の新しいプランで、自分の API キーを使わずに Cursor 自身のエージェントパネルで Claude を選ぶと、前払いのクレジット残高から API の定価で課金されます。どちらも同じウィンドウの中で、横に並んで動きます。機能比較表はいまも 2 つのツールを利用環境、つまりエディタかターミナルかで分けていますが、今年、利用環境はもう違いではなくなりました。

Claude Code は「Install for Cursor」リンク付きの拡張機能を出しています。Cursor は、スクリプトや CI 向けのヘッドレス CLI、リモートマシンで動くクラウドエージェント、そして Claude Code 自身の設定フォルダを読み込むローダーを出しています。以下は、実際に人々が 2 つの間で仕事をどう分けているか、そしてそれぞれの分け方に何がかかるかの話です。ラベルは Claude Code と Codex のときと同じものを使います。文書化済みは、ベンダーのドキュメント、または公開リポジトリにチームがコミットしたファイルがその仕組みを示しているという意味です。報告は、名前のわかる人が自分の構成を公開しており、それを自分で再現せずに紹介しているという意味です。

自分の立ち位置も書いておきます。自分のエージェントは tmux 上の対話型 Claude Code セッションとして動いているので、この話ではターミナル側にいます。以下の Cursor に関する記述はすべて、10 月 18 日に読んだそのドキュメントと、名前を挙げた報告に基づいています。

Cursor の中で動く Claude Code は同じエージェントなのか

同じです。ドキュメントがはっきり書いています。VS Code 拡張機能のページは Cursor 用のインストールを直接リンクしており、拡張機能は "bundles its own copy of the CLI." (CLI の自前のコピーを同梱している) と説明しています。バージョン番号は CLI のバージョンで、~/.claude/settings.json は "shared between the extension and CLI" (拡張機能と CLI で共有される) とされ、会話履歴も共有されます。そのため、パネルで始めた会話をターミナルの claude --resume で続けられます。パネルはエディタならではの機能を加えます。インラインの左右比較 diff、コメントを付けられる Markdown ドキュメントとしての計画レビュー、行範囲付きの @ メンション、巻き戻せるチェックポイントです。コマンドとスキルは CLI より少なく、! によるシェルのショートカットもありません。

これが基本のパターンで、歴史も古いものです。Builder.io の CEO である Steve Sewell は、2025 年 7 月にこれを説明しています (報告)。エージェントの作業はエディタのペインで動く Claude Code に任せ、Cursor からはインライン機能だけを使う形です。

I still use Cursor for quick Command+K completions and tab completions.
But the agent sidebar? I only touch it when Claude is down.

ドキュメントにある細部がひとつ、この分担を安定させています。Cursor の API キーのページによると、カスタムキーは "only work with chat models. Tab completion continues using Cursor's built-in models." (チャットモデルでしか使えない。Tab 補完は引き続き Cursor の組み込みモデルを使う) です。何を設定しても Tab は Cursor 自身のモデルなので、Cursor の機能のうち、比べるべき Claude Code 側の相手がいない唯一のものになっています。

Cursor をただのエディタにして、AI の仕事はすべて Claude Code に任せられるか

名前のわかる開発者 2 人がまさにそうしていると報告しており、そのうち 1 人はその後 Cursor をやめました。Tom Crawshaw は、Cursor の統合ターミナルで一日中 Claude Code を動かし、"barely touch[es] Cursor's own AI" (Cursor 自身の AI にはほとんど触れない) と書いています (報告)。ただし、Cursor を解約しろと誰かに言っているわけではないと明言しています。Eric Roby は 2026 年 3 月に同じ形を説明しています (報告)。ターミナルの Claude Code がコードを書き、Cursor はそれをレビューする場所です。結末はタイトルに書かれています。サブスクリプションを解約し、ビューアーとして VS Code と Zed を試しているところです。

文書化済みの側を見ると、なぜこの一歩が小さいのかがわかります。Claude Code の変更履歴には v2.1.300 までに、Cursor の統合ターミナル内での動作に関する修正が長く並んでいます。概要ページは、どの利用環境も "the same underlying Claude Code engine" (同じ基盤の Claude Code エンジン) につながると述べています。AI がターミナルのプロセスになってしまえば、エディタはファイルツリー付きの diff ビューアーです。このパターンで問うべきは、どちらのツールが優れているかではありません。Cursor のサブスクリプションがまだ何に対してお金を払っているのか、です。よくある答えは Tab です。

Claude Code と Cursor はタスクの規模で分けるべきか

切り替えのコストを吸収できるほど長いタスクに限ります。少なくとも、公開されている唯一のデータではそうです。Blake Crosley は 30 セッションを記録し (報告)、スコープで分けています。複数ファイルのリファクタリング、テスト、git、フックは Claude Code、単一のビュー、CSS、関数 1 つの編集は Cursor です。見出しの数字は実装時間の 40% 短縮です。計測は本人によるもので、単独利用のベースラインの一部は推定値と明記されています。ベンチマークではなく、1 人の開発者の記録として読んでください。それでも、彼の表は見出しより具体的です。複数ファイルの作業では、組み合わせたワークフローが平均 50 分、Claude Code 単独が 45 分で、そこでは分担したほうが遅くなっています。効果が出ているのは 1 行だけ、アーキテクチャと仕上げの組み合わせで、60 分に対して 40 分です。彼は切り替えのオーバーヘッドをタスクあたり 3 〜 5 分と見積もっており、これで 10 分未満のタスクは対象外になります。

彼が挙げる失敗こそが役に立つ部分です。

Cursor does not know about architectural decisions Claude Code just made,
producing suggestions that contradict the new architecture.

彼の対処は手作業です。Claude Code でアーキテクチャのセッションを終えたら、切り替える前に Cursor のルールを更新します。毎回 2 〜 3 分です。これは指示を共有する問題が 1 人の一日の中に現れたもので、後述の 2 つの設定パターンは、チームがそれにどう対処しているかを示しています。

Cursor Bugbot に Claude Code が書いたプルリクエストをレビューさせられるか

できます。逆向きの報告もあります。Zack Proser は 3 月に、Bugbot を "as an automatic reviewer on every Claude Code PR I open" (自分が開くすべての Claude Code の PR の自動レビュアーとして) 動かしていると書きました (報告)。チェックリストはリポジトリのルートにある .cursor/BUGBOT.md に置いています。理由はモデルの多様性で、最初のモデルが書いたものは別のモデルがレビューすべきだ、という考えです。彼の構成では、Cursor はそもそもエディタではありません。GitHub 上の 2 人目の読み手です。

madewithlove の Peter Eysermans は逆の道を選びました (報告、2025 年 10 月)。Bugbot が月 40 ドルのアドオンになったとき、彼のチームはレビューを Claude Code GitHub Action 経由の Claude に移しました。すでに契約していた 20 ドルの Pro プランの上でです。そして Claude のバグ検出は "notably better" (目に見えて優れている) と感じたそうです。きっかけは価格で、移行を定着させたのは品質でした。

どちらの記事の価格も変わっています。Cursor は 2026 年 6 月 8 日以降の更新時に Bugbot を従量課金に移行し、1 回の実行の平均費用を 1.00 〜 1.50 ドルとしており、新しいプランでは Premium 以上に含めています。GitHub Action は今も Claude のサブスクリプションに紐づく OAuth トークンを受け付けるので、Eysermans の構成は今もプランの上で動きます。Team と Enterprise 向けに Anthropic が別途提供するマネージド型の Code Review は別の製品で、プランの利用分とは別に利用クレジットで課金されます。2 つの記事は異なる理由で正反対の構成にたどり着いており、どちらも相手の選択を計測してはいません。

チームで Claude Code と Cursor を開発者ごとに選ばせてもよいか

ある導入事例ではそうしており、決め手はモデルではありませんでした。Alex Ghiculescu は、12 年ものの Rails コードベースを持つ開発者約 40 人の会社で、"every developer" (すべての開発者) が Cursor か Claude Code を購入できた事例を説明しています (報告、2025 年 4 月で、他の事例より古いものです)。Cursor の採用率のほうがわずかに高かったそうです。彼の観察では、Claude Code は "likes to write entire features for you" (機能をまるごと書きたがる) 一方、Cursor は "smaller and more self contained changes" (より小さく自己完結した変更) にとどまっていました。

彼自身が Claude Code を選んだ理由は、Sublime Text でコードを書いていて、エディタを変えたくなかったからです。この記事の中で、ここがいちばん一般化できます。個人にとっては、すでに住んでいるエディタのほうがベンチマークより多くを決めます。会社にとっては、1 つのコードベースに請求書が 2 つ、指示ファイルが 2 セットという意味でした。次の 2 つのパターンは、その後者の話です。

Claude Code と Cursor で 1 セットの指示を共有するには

AGENTS.md を使います。ただし扱いは均等ではありません。まず文書化済みの読み込みルールです。Cursor のルールのページは、プロジェクトのルートとサブディレクトリにある AGENTS.md をサポートしています。ネストしたファイルは結合され、より具体的なほうが優先されます。これと並んで Cursor 独自の .cursor/rules/*.mdc ファイルがあります (そこに置いた普通の .md ファイルは無視されます)。Cursor の CLI のドキュメントによると、CLI はプロジェクトのルートにある CLAUDE.md も読みます。エディタのルールのページはこれに触れていません。Claude Code は v2.1.277 以降、CLAUDE.md も CLAUDE.local.md もない場合にだけ、既定で AGENTS.md を読みます。このフォールバックについては Claude Code が AGENTS.md を読むようになったで詳しく見ました。Cursor の .mdc ルールを自分で見つけることはありません。/init は生成する CLAUDE.md に .cursor/rules/ と .cursorrules を取り込み、/import cursor (v2.1.265) は 1 回限りのコピーを追記します。

3 つの公開リポジトリが、実際に機能している 3 つの答えを示しています。どれもそれぞれのファイルで文書化済みです。

• Cypress は AGENTS.md を正本にしています。AI ドキュメントによると、Cursor と Codex はそれをネイティブに読み、Claude Code はインポート経由で読みます。"One edit propagates to all three tools." (1 回の編集が 3 つのツールすべてに伝わる) です。パッケージ単位の CLAUDE.md ファイルが 60 ほどあり、どれも隣の AGENTS.md をインポートするだけのスタブです。ルートの CLAUDE.md には Cypress が Claude Code 向けに残しているセクションが 1 つあり、Cursor にはレビュー用の .cursor/BUGBOT.md があります。
• Zod はシンボリックリンクを使っています。colinhacks/zod では、CLAUDE.md とレガシーの .cursorrules の両方が AGENTS.md を指しています。共有ファイルは今も "This file provides guidance to Claude Code" (このファイルは Claude Code に指針を与える) という一文で始まります。ファイルが 1 つであることと、ツールに中立なファイルであることは別です。
• Cloud Foundry UAA は逆の道を選びました。cloudfoundry/uaa では、正本のルールは中立な ai/rules/ フォルダにある Cursor 形式の .mdc ファイルで、スクリプトがそれを .cursor/ にシンボリックリンクします。AGENTS.md は Claude Code を含むすべてのエージェントに、作業を始める前にそれらのファイルを読むよう指示しています。あるルールの要約には、AGENTS.md、CLAUDE.md、Copilot 用のファイルを同期させておくよう書かれています。手作業の運用だと、文書で認めているわけです。

Cursor はツリーの奥まで AGENTS.md ファイルを自分で見つけます。Claude Code が同じファイルを見るには、3 つの構成のどれかが必要です。CLAUDE.md をまったく置かずにフォールバックを効かせるか、両方のファイル群を読み込むプロジェクト指示の設定を使うか、重要な AGENTS.md のそれぞれの隣にインポート用の CLAUDE.md を置くかです (Cypress が作ったのは最後の形です)。.cursor/rules にしかないものは、Claude Code が読み込むファイルのどれかが読みに行くよう指示しないかぎり、Claude Code には届きません。

Cursor は Claude Code のスキル、サブエージェント、フックを実行するのか

既定では、実行します。これは Cursor 側で文書化されています。スキルのページは、.claude/skills/ と ~/.claude/skills/ からスキルを "for compatibility" (互換性のために) 読み込むと述べています。サブエージェントのページは .claude/agents/ を読み、サードパーティフックのページは、Cursor が .claude/settings.json、.claude/settings.local.json、~/.claude/settings.json から "can load and execute hooks configured for Claude Code" (Claude Code 用に設定されたフックを読み込んで実行できる) としています。すべては 1 つの設定「Include Third-Party Plugins, Skills, and Other Configs」の下にあり、同じページによるとこの設定は既定でオンです。

つまり、設定は両方向に同じようには流れません。Claude Code は Cursor のルールを、/init か /import を実行したときに一度だけコピーします。Cursor は Claude Code のフォルダを毎セッション読みます。Claude Code のユーザーが .claude/ を管理しているチームでは、その人たちは Cursor が実行するものも編集していることになります。.claude/agents/ のサブエージェント定義は独自のモデルを指定でき、Cursor のサブエージェントのページによるとモデルピッカーが適用されるのは親エージェントです。そのため、親が料金に含まれるモデルで動いていても、取り込まれたサブエージェントが別料金のサードパーティモデルを呼び出すことがあります。

フックの対応付けは部分的で、ガードレールが静かに効かなくなるのはそこです。サードパーティフックのページは、PreToolUse を Cursor の preToolUse に、UserPromptSubmit を beforeSubmitPrompt に対応付け、Bash ツールを Cursor の Shell に変換し、Notification と PermissionRequest を Glob ツールとともに非対応としています。Claude Code の PermissionRequest フックは Cursor では動きません。Claude Code のツール名にマッチする PreToolUse フックは、対応付けがある場合にだけ動きます。Cursor 独自のフックは終了コード 2 でブロックし、フックのページはこれを "matches Claude Code behavior for compatibility" (互換性のために Claude Code の挙動に合わせている) と説明しています。Cursor の優先順位では、.cursor/hooks.json が .claude のファイルより先に来ます。

.claude/settings.json のフックが何かを止めるためにあるなら、Claude Code だけでなく Cursor でもテストしてください。プロジェクトの .claude/ フォルダはクローンのたびに一緒にやって来ます。これは クローンしたリポジトリが Claude Code で何を設定できるかで調べたことです。いまでは Cursor も、独自の信頼ルールの下で同じフォルダを読みます。Cursor のセキュリティのページによると、エディタのワークスペーストラストは既定で無効で、CLI は --trust か --force を渡さないかぎり、信頼されていないワークスペースでの非対話実行を拒否します。新しくクローンしたリポジトリから取り込まれたフックがエディタで最初にいつ動くのかは、どちらのページにも書かれておらず、自分でもテストしていません。どちらかに頼る前に確かめるべきなのはそこです。

Claude Code と Cursor は同じように身を守ってくれるのか

いいえ。しかも互いのルールを読みません。Claude Code のパーミッションモードは Manual から bypassPermissions まであり、v2.1.283 以降、ターミナルと VS Code の対話セッションは auto で始まります。このモードでは "a second model, the classifier, reviews actions instead of you." (2 つ目のモデルである分類器が、あなたの代わりにアクションをレビューする) です。同じドキュメントは、確実な保証には分類器ではなく deny ルールが必要だとしています。サンドボックスは /sandbox を実行するまでオフです。Cursor の実行モードは Auto-review、Allowlist、Run Everything の 3 つで、新規ユーザーの既定は Auto-review です。許可リストに載った呼び出しはそのまま実行され、対象となるシェルコマンドはサンドボックスに入り、残りは Cursor のバックエンドにある分類器に回されます。分類器は、呼び出しをサンドボックスの外で実行することを承認できます。ページの警告は率直です。

Auto-review is not a security boundary. The classifier can make mistakes.

ルールファイルは引き継がれません。Claude Code は allow と deny のルールを .claude/settings.json に置いています。Cursor がフックのために読むのと同じファイルです。Cursor のサードパーティフックのページはそこからフックを読み込むことを文書化していますが、Cursor の権限のページにも実行モードのページにも、Claude Code のパーミッションルールへの言及はありません。Cursor には独自のものがあります。.cursor/cli.json か ~/.cursor/cli-config.json に書く Shell()、Read()、Write() のトークンルールで、deny が allow より優先されます。さらに、エディタと、3 月からは CLI も読む permissions.json があり、Auto-review 向けの許可とブロックの指示を平易な英語で書けます。Claude Code 用に書いた deny ルールは、ドキュメントによれば Cursor では deny ルールではありません。シークレットをエージェントの手の届かないところへ移そうとしている人にとって重要な Cursor の細部が、もう 1 つあります。ignore ファイルのドキュメントによると、エージェントが使うターミナルと MCP ツールは .cursorignore ではブロックできません。

ヘッドレスは、ドキュメントがいちばん定まっていないところです。Cursor の CLI のページは "has full write access in non-interactive mode" (非対話モードでは完全な書き込み権限を持つ) と述べる一方、ヘッドレスのページは、--force がなければ "changes are only proposed, not applied." (変更は提案されるだけで、適用されない) としています。CI に agent -p を入れる前に、自分のバージョンがどちらの挙動なのかをテストしてください。Claude Code の -p には、文書化された別の落とし穴があります。--bare がなければ、一度も信頼していないフォルダでも、プロジェクトのフックを実行し、その MCP サーバーに接続します。--setting-sources user がなぜより広く効くスイッチなのかは、クローンしたリポジトリの記事で扱っています。

Cursor で使う Claude モデルは、どちらの請求に載るのか

どうサインインしているか、どのパネルに入力するかで決まり、10 月 12 日からその差は大きくなりました。Cursor は現在 SpaceX の傘下にあります。SpaceX は 8 月 14 日に買収を完了し、新しいプランは The X Subscription の一部として販売されています。Cursor のモデルと料金のページは、それが Claude にとって何を意味するかを説明しています。

Third-party models like Claude, GPT, and Gemini aren't part of the included
pool. On Premium and above, they're available in Cursor at the model's API
list price from the first request, paid from your prepaid credit.

週ごとの利用枠に含まれるのは Cursor 自身のモデル、つまり Composer と、SpaceXAI と共同で訓練している Grok モデルです。コストモードの Auto ルーティングは、どのモデルがリクエストに応じても、その枠から消費します。新しいプランで最も安い Plus には、サードパーティモデルがまったくありません。Teams と Enterprise では、自分の API キーを使う場合も含めて、100 万トークンあたり 0.25 ドルの Cursor Token Rate が上乗せされます。自分の Anthropic キーを使えば、Anthropic から直接請求されます。既存のプランは今のところ影響を受けません。フォーラムの告知によると、切り替えるまでは含まれていたサードパーティの利用が続き、Cursor のヘルプページによると切り替えは取り消せません。

同じウィンドウの Claude Code パネルは、課金のされ方が違います。Anthropic の Pro と Max の記事によると、プランは "also covers Claude Code in supported IDEs, including VS Code, Cursor and other VS Code forks" (VS Code、Cursor、その他の VS Code フォークを含む、対応 IDE 内の Claude Code もカバーする) もので、利用分はターミナルと同じ上限に計上されます。Cursor 自身のエージェントはそのプランを使えません。Anthropic の法務ページは、第三者が自社ユーザーの代わりに Free、Pro、Max の認証情報を通してリクエストを送ることを認めておらず、Cursor の API キーのページも API キーしか挙げていません。そのため、拡張機能には Claude のプランでログインし、新しいプランの Cursor エージェントでは Claude を明示的に選んでいる場合、左の Opus 5.5 は Anthropic に払っている分から、右の Opus 5.5 は Cursor 用にチャージする残高から消費されます。プラン側の利用状況は Claude Code パネルの /usage で確認できます。Cursor 側は Cursor の利用状況ダッシュボードにあります。

Anthropic 側にも細かい注意書きがあります。10 月 7 日に Max と Team のプランに加わった毎月の API クレジットは、このどれにも使えません。クレジットの記事によると、IDE 拡張機能から始めた実行は "count as Claude Code usage, so API credits don't cover them, even with -p" (Claude Code の利用として数えられるため、-p を付けても API クレジットの対象にならない) です。また Pro と Max の記事は、環境に ANTHROPIC_API_KEY があると Claude Code がプランではなく API に課金すると警告しています。Cursor の自分のキーを使うオプションを設定したあと、残したままにしがちなものです。

Claude Code と Cursor の分担は、どれから始めるべきか

これは出典を読んだうえでの見立てで、計測結果ではありません。すでに Claude のプランを払っていて余裕があるなら、エージェントの仕事は Claude Code の拡張機能か CLI で動かしてください。エディタが気に入っているなら Cursor の中でかまいません。そして Cursor は Tab とインライン編集のために残します。すでにカバーしてくれているプランに加えて、Claude に Cursor の定価を払うことを避けられますし、ここで挙げた中で 2025 年から変わらず通用している唯一のパターンでもあります。更新の前に、自分がどの Cursor プランにいるかを確認してください。レガシープランと新しいプランでは、同じ Claude のリクエストの扱いが違います。Claude の利用が少なく、Cursor が主なツールなら、計算は逆の結果になることもあります。

次に、ずれる前に設定を整えます。AGENTS.md を共有ファイルにし、Claude Code がそのすべてを見られるようにしてください。Cypress のように各ファイルの隣にインポート用の CLAUDE.md を置くか、両方を読み込む設定を使います。.claude/ の中身は Cursor も読むものだと意識して見直し、何かをブロックするためのフックは両方のツールでテストしてください。

2 つ目のツールを見送るべきなのは、すでに普通のエディタで diff をレビューしていて、Tab がなくても困らない人です。Roby が解約したサブスクリプションは「Cursor をビューアーにする」パターンの行き着く先で、ドキュメントのどこにも、彼を思いとどまらせる材料はありません。

こうしたことは、機能比較表には現れません。一方のツールは毎セッション相手の設定フォルダを読み、もう一方はそれを一度コピーするだけです。どちらも相手の deny ルールを尊重しません。そして同じモデルが、左のパネルと右のパネルで違う値段になりえます。