Claude Code ↔ Cursor 切り替えガイド — 作業中に迷わない判断フローと両刀ワークフロー
Claude CodeとCursorを実際に使い分けるための判断フローチャートと具体的なハイブリッドワークフロー。Plan Mode・Sub-agents・インライン補完・.cursorrules設定共存まで、実測データ付きで解説。
エンジニアのゆとです。
Claude CodeとCursorを両方使ってる人が増えてきた。その分「で、今これはどっちでやるべきなんだっけ？」という瞬間も増えてきた。
既存の比較記事は「どっちを選ぶか」という買い物相談が多い。でもすでに両方持ってる人には、それより「今の作業中にどっちを使うか、どう切り替えるか」の話の方が役立つ。
この記事はそこに特化する。判断フローチャート、実測データ、設定ファイルの共存方法、実際のハイブリッドワークフロー。「両刀使い」として日常的に回すための実践ガイド。
なお「CursorとClaude Codeどっちがいいか」という選択の話は別記事で書いた。
なぜ2つ使い分けるのか
結論から言うと、この2つは「競合ツール」じゃなくて「異なるレイヤーのツール」だから。
Claude Codeは「作業を委任するツール」。タスクを伝えたら自律的に実行してくれる。ファイルを読んで、コードを書いて、テストを走らせて、gitにコミットするまで全部やる。人間は最初の指示と最後の確認だけ。
CursorはVS Codeベースの「コーディング補助ツール」。コードを書く手元の作業にAIが溶け込んでいる。Tab補完、インライン編集、即時のdiff確認。人間が手を動かしながら、AIにアシストしてもらう。
これは「タクシーとロードバイク」みたいな関係に近い。目的地が決まっていて遠ければタクシー（Claude Code）。近所をちょっと移動するなら自分で漕いだ方が速い（Cursor）。どちらが優れているかではなく、場面によって使うものが変わる。
問題は、その「場面の境界線」が実際の作業中にはっきりしないこと。「これはCC案件か、Cursor案件か」と迷って、結果的に微妙な方を選んで後悔する。このガイドは、その迷いをゼロにするための判断軸を提供する。
Claude Code が強いケース
Plan Mode で設計を丸投げする
Claude Codeの--planモードは、実装前に「何をするか」のプランを提示して承認を取る仕組み。複雑な機能追加や大規模な変更前には必ず使う。
claude --plan "Stripe Webhookを実装したい。受け取れるイベント種別、
エラーハンドリング、冪等性の担保方法、テスト方法まで設計してほしい"出てきたプランを確認して、「ここはこうしてほしい」と修正を入れてから実行に移す。Cursorにはこの「設計フェーズで止まる」機能がない。
Sub-agents で並列実行する
Claude Code 2026年2月〜のSub-agents機能は、独立したタスクを並列で走らせる。
# メインセッションから別エージェントを起動
claude "フロントエンドのコンポーネントテストを全部修正してほしい。
バックエンドのAPIテストは別エージェントに任せて並列で進める。
完了したら報告して"「フロントのテスト修正」と「バックのAPIテスト」を同時に走らせる。CursorでもBackground Agentで並列化はできるが、VM上で動くため環境の温度が違う。ローカル環境で直接実行できるClaude Codeの方が、ローカル依存がある作業には向いている。
大規模リファクタリング
ファイル数が多いリファクタリングはClaude Codeの独壇場。1Mトークンのコンテキストで、プロジェクト全体を「視野に入れた」状態でリファクタが進む。
claude "srcディレクトリ配下のAPIクライアントを全部確認して、
axios直呼びになってる箇所をfetchラッパーに統一してほしい。
型定義も合わせて修正すること"CursorだとCopilotの作業単位が「ファイル単位」になりがちで、全体の一貫性を保ちにくい。Claude Codeは「プロジェクト横断」で整合性を取りながら変更できる。
実測してみた。同じリファクタタスクをCCとCursorで比較。
| タスク | Claude Code | Cursor | 所要時間 |
|---|---|---|---|
| API呼び出し統一（23ファイル） | 約8分（自律実行） | 約35分（手動確認含む） | CC 4.4倍速 |
| 型定義の整理（15ファイル） | 約5分 | 約20分 | CC 4倍速 |
| エラーハンドリング統一（18ファイル） | 約7分 | 約28分 | CC 4倍速 |
Cursorの時間には「変更をdiffで確認→Accept/Reject」の工数が含まれている。CCは「完了報告を確認してgit diffで一括確認」する分、中間確認を省略できる。
ターミナル連携が必要な作業
Docker操作、AWS CLIコマンド、DBマイグレーション、CI/CD設定——これらはClaude Codeが圧倒的に楽。ターミナルと直結しているので、コマンドを書いて実行して結果を見てまた書く、のループが自動で回る。
claude "既存のDockerfileをmulti-stageビルドに変更して、
本番用とdev用を分けてほしい。docker-compose.ymlも合わせて修正して。
最後に本番イメージのビルドを試して問題なければコミットして"Cursorにはターミナル統合があるが、「ターミナルで結果を見てコードを修正する」サイクルを自律的に回す機能はない。
Cursor が強いケース
Tab補完でコードを書く「書き書きフェーズ」
ロジックが決まっていて、とにかくコードを書く時間に入ったらCursor。Tab補完のレスポンス速度と精度は、Claude Codeのインタラクティブセッションより圧倒的に速い。
書いている最中にリアルタイムで候補が出て、Tabで確定する流れは「思考の速度でコードが出てくる」感覚がある。CCだと指示→待機→確認のサイクルが入るため、細かい実装をちょこちょこ書く場面では逆にストレスになる。
インライン編集でUIを調整する
CSSの微調整、コンポーネントのレイアウト変更、スタイルの統一——視覚的なフィードバックが重要な作業はCursorが快適。
Cursorのインライン編集（Cmd+K）は、カーソルのある行をその場で書き換える。「このborderをroundedにして」「このflex方向を逆にして」という微調整を視覚的に確認しながら進められる。
Claude Codeにもeditツールがあるが、ファイルを保存してブラウザで確認するサイクルになる。「見ながら調整」はCursorに分がある。
変更を1行ずつ確認したい時
CCが生成したコードをレビューする時も、Cursorが便利。
CCで生成→Cursorで開いてdiff確認→疑問点はCursorのChat（Cmd+L）で質問→修正はそのままCursorで。
この動線が実はよく使う。CCで大量に変更してからCursorで一通り確認する、という分業。
複数モデルを試したい時
「このバグはGPT-5.4に聞いてみよう」「Gemini 3.1 Proのコード生成を試してみたい」という時はCursor。ワンクリックで35以上のモデルに切り替えられる。
Claude Codeは当然Claudeモデルのみ。比較したいなら、Cursorを使う方が手間がない。
切り替え判断フローチャート
今の作業が「CCかCursorか」を即断するためのフロー。
今から何をするか？
│
├── 「これやっといて」と丸投げしたい
│ └── → Claude Code
│
├── 自分で書いていく
│ ├── ロジックが決まっている（とにかく書く）
│ │ └── → Cursor（Tab補完快適）
│ └── 何を書くか考えながら進める
│ └── → Claude Code（Plan Modeで設計→Cursorで実装）
│
├── ファイルを横断する変更か？
│ ├── 5ファイル以上またがる → Claude Code
│ └── 1-3ファイル、局所的 → Cursor
│
├── ターミナルコマンドを伴うか？
│ ├── Yes → Claude Code
│ └── No → Cursorでも対応可
│
├── AIが暴走した時に即ロールバックしたいか？
│ ├── Yes → Cursor（diff確認→個別Accept/Reject）
│ └── No（CCのcheckpointで十分）→ Claude Code
│
└── 複数モデルを試したいか？
├── Yes → Cursor
└── No → Claude Code「5ファイル以上またがる」を目安にするのが実用的。それ以下なら手で追えるのでCursorで十分。それ以上になるとコンテキスト管理でCCの方が有利になる。
ハイブリッドワークフロー実例
実際の開発フローで、どう組み合わせているかを具体的に書く。
パターン1: 新機能追加
- CCでPlan Mode → 設計と構成案を確認
- CC（—yolo不使用）で基礎構造を生成 → ディレクトリ作成・型定義・スケルトン
- Cursorに切り替えて細部の実装 → ビジネスロジックはTab補完で書く
- CCでテスト生成・実行 → 「テスト書いて全部通してコミットして」
- Cursorでコードレビュー → 気になった点はChat（Cmd+L）で質問
1時間の作業だとすると、CC:Cursor = 20分:40分くらい。
設計と後処理をCCに任せて、書いてる時間はCursorにいる。パターン2: バグ修正
- CCで調査 → 「このエラーの原因を調べて、関連ファイルを全部見て」
- CCが原因を特定・修正案を提示
- ここで判断:
- 変更が1-2ファイルかつ自分で確認したい → Cursorに切り替えて手動修正
- 変更が広範囲 → CCにそのまま任せる
- Cursorで変更を確認→テスト
バグ調査はCCに任せると速い。
修正を「自分で理解しながらやりたい」時だけCursorに切り替える。パターン3: リファクタリング
- CCで対象の特定 → 「統一できていないパターンを全ファイルからリストアップして」
- CCでリスト確認・方針合意
- CCで一括修正実行
- Cursorでdiff確認 → 各ファイルの変更を目視確認
このパターンが一番CCの恩恵を受けやすい。
調査→修正はCC、確認はCursorという分担が綺麗に決まる。パターン4: ドキュメント整備
- CCにREADME/コメントの追加・更新を丸投げ
- Cursorで細部を手直し
ドキュメントは間違いが少ないし人間が確認しやすいので、
CCで全部やっちゃってCursorでちょこっと直す運用が楽。設定ファイルの共存（CLAUDE.md + .cursorrules）
両方使う場合、CLAUDE.mdと.cursorrulesを二重管理する必要がある。これが面倒に見えて、実は整理すると大した手間じゃない。
役割分担の考え方
CLAUDE.md → 「CCが自律実行する時の判断基準」
.cursorrules → 「Cursorが補完・生成する時のスタイルガイド」CCは「何をするか」の指針が必要で、Cursorは「どう書くか」のスタイルが重要。ここを混在させないと管理が楽になる。
CLAUDE.md の役割（CCが守るべきルール）
# プロジェクト概要
TypeScript + Next.js 15 + Prisma構成。
デプロイ先: Vercel。環境変数は .env.local 参照。
# 鉄の掟
- node_modules/ を直接触らない
- .env.local をgitに含めない
- 既存のAPIシグネチャを勝手に変えない
# 作業前に必ずやること
- 既存コードのパターンを確認してから書く
- テストを変更したコードに対して必ず書く
- 変更前にcheckpointを作っておく
# テスト
- vitest使用（npm run test）
- __tests__/ 配下に配置
- カバレッジ目標: 80%以上
# コミット規約
feat: 新機能
fix: バグ修正
refactor: リファクタリング
docs: ドキュメントのみ.cursorrules の役割（コードスタイル）
# コーディングスタイル
- TypeScriptの型は明示する（anyを使わない）
- Reactコンポーネントはアロー関数で書く
- Props型はinterfaceで定義する（typeではなく）
- CSS-in-JSではなくTailwindを使う
- インポートは絶対パスを使う（@/ エイリアス）
# 命名規則
- コンポーネント: PascalCase
- 関数・変数: camelCase
- 定数: UPPER_SNAKE_CASE
- ファイル名: kebab-case
# Prismaモデル操作
- トランザクションは prisma.$transaction() を使う
- N+1問題を意識してincludeを適切に使う共通部分の重複を減らす
両方に書かなくていいものはどちらか一方にまとめる。
「テスト方針」はCCが実行する判断なのでCLAUDE.mdに書く。「関数の書き方スタイル」はCursorが補完する時のガイドなので.cursorrulesに書く。
重複して書いてあっても害はないが、メンテナンスが2倍になる。「誰が使う情報か」で仕分けると管理しやすい。
実測データ
3ヶ月間（2026年2月〜4月）、日常の開発作業をCCとCursorに振り分けた記録から。
| タスク種別 | 使用ツール | 平均時間 | 体感満足度（5段階） |
|---|---|---|---|
| 新機能の設計・骨格生成 | Claude Code | 12分 | ★★★★★ |
| 大規模リファクタ（10ファイル以上） | Claude Code | 15分 | ★★★★★ |
| バグ原因調査 | Claude Code | 6分 | ★★★★☆ |
| テスト生成・修正 | Claude Code | 8分 | ★★★★★ |
| CI/CD設定変更 | Claude Code | 10分 | ★★★★★ |
| ビジネスロジック実装（自分で書く） | Cursor | 25分 | ★★★★☆ |
| UIコンポーネント作成 | Cursor | 20分 | ★★★★☆ |
| CSS・スタイル調整 | Cursor | 10分 | ★★★★★ |
| コードレビュー確認 | Cursor | 15分 | ★★★★☆ |
| 局所的なバグ修正（1-2ファイル） | Cursor | 8分 | ★★★★☆ |
体感として、CCに向いているタスクをCursorでやると2-4倍の時間がかかる。逆もあって、「ちょっとした修正」をCCに投げると、確認フローで逆に時間がかかることがある。ツールの選択ミスのコストは思ったより大きい。
コスト面では、Cursor Pro $20 + CC Pro $20 = 月$40 で回している。CCをヘビーに使う週はMax 5xに一時的に上げることがあるが、月$100を超えたことはない。Cursor一本$60（Pro+）よりコスパは良い。
ハマりどころ
CCのコンテキストがリセットされるタイミングを忘れる
CCは長いセッションでコンテキストが溢れると、前半の指示を忘れる。「さっき決めた方針で」が通じなくなる瞬間がある。
対策: 重要な方針はCLAUDE.mdに書く。セッションが長くなったら--resumeでサマリーを読み直させるか、新しいセッションを開始してCLAUDE.mdを読ませる。
CursorのRulesとCLAUDE.mdが矛盾する
例えば.cursorrulesで「コメントは英語で」と書いておいて、CLAUDE.mdで「コメントは日本語で」と書くと、作業ごとにスタイルがバラバラになる。
対策: 最初にRulesとCLAUDE.mdを並べて矛盾がないか確認する。変更する時は両方を同時に更新する習慣をつける。
CCがやりすぎる（over-engineering）
「テスト修正して」と頼んだら、テストだけでなく実装コードまで書き換えてきた——という経験、たぶんある。
対策: CCへの指示は「範囲」を明示する。「srcディレクトリ内の__tests__ファイルのみ修正して、実装ファイルは触らないで」のように。
Cursorが大きいコードベースで迷子になる
ファイル数が増えてくると、Cursorが「他のファイルとの整合性」を見失う。型エラーが連鎖したり、importパスが間違えたりする。
対策: ファイル数が50を超えてきたらCCを多用するシグナルと思う。大きな変更はCCに任せて、Cursorは局所的な作業に絞る。
CCの「確認フロー」で時間を取られる
CCはデフォルトで危険な操作（ファイル削除、大量変更）の前に確認を求める。慣れてくると「またか」となる。
対策: 信頼しているプロジェクトでは.claude/settings.jsonでpermissionsを設定して確認を省略する。ただしやりすぎると本当に危険な変更も素通りするので、削除・破壊系だけは残しておく。
{
"permissions": {
"allow": [
"Bash(git commit:*)",
"Bash(npm run test:*)",
"Bash(npm run build:*)",
"Write(src/**)"
]
}
}まとめ
「CCかCursorか」という二択は終わった。今は「どっちを今使うか」という判断の話。
判断の軸を3つに絞ると:
- 丸投げ or 手を動かすか: 丸投げ→CC、手を動かす→Cursor
- 横断規模: 5ファイル以上→CC、局所→Cursor
- ターミナルが要るか: Yes→CC、No→どちらでも
この3軸で大半の判断はつく。迷ったらCCに投げた方が速い、というのが正直な経験則。CCが「いやそれ自分でやった方が速かったな」となるケースより、Cursorで頑張ってCCに任せれば良かったと思うケースの方が多い。
CLAUDE.mdと.cursorrulesの共存は、最初だけちゃんと設計すれば後の管理は大した手間じゃない。「CCが判断する情報」と「Cursorが参照するスタイル」を分けて書くだけ。
両刀の効果は、慣れてくるほど上がる。最初は「これCC案件かな？」と迷っていたのが、3ヶ月経つと条件反射になる。作業の性質を見た瞬間に「CC」「Cursor」が決まる感覚。
Claude Codeの初期設定をまだやっていない場合は、こちらも参考に。
