「Claude CodeとCursor、結局どっちを使えばいいの？」——答えは**『両方を同一リポジトリで併用する』**でした。
本記事では、Claude Code（ターミナルベースのAIエージェント）とCursor（AI搭載エディタ）を同じプロジェクトで使い分ける方法を解説します。タスク種別ごとの判断基準、セットアップ手順、そして10タスクでの定量比較まで、実践で得た知見をすべて共有します。
1. なぜ併用なのか：それぞれの得意領域を30秒で整理
まず結論から。どちらか一方では、カバーできない領域があるからです。
| 観点 | Claude Code | Cursor |
|---|---|---|
| 操作環境 | ターミナル（CLI） | エディタ（GUI） |
| コンテキスト範囲 | リポジトリ全体を自律的に探索 | 開いているファイル＋指定ファイル中心 |
| 得意な粒度 | 大規模な横断的変更 | 局所的な編集・微調整 |
| 自律性 | 高い（ファイル作成・コマンド実行まで一気通貫） | 中程度（提案→承認のループ） |
| 視覚的フィードバック | 弱い（差分はターミナル表示） | 強い（インライン差分・プレビュー） |
| 操作の即時性 | バッチ的（指示→実行→結果確認） | インタラクティブ（リアルタイム編集） |
要するに、「大きく作る」のはClaude Code、「細かく磨く」のはCursorが向いています。この特性差を活かすのが併用戦略です。
2. 判断基準マトリクス：タスク種別×ファイル規模×コンテキスト量で選ぶ
「どちらを使うか」を毎回悩まないために、判断フローを整理しました。
タスク種別ごとの推奨ツール
| タスク種別 | 推奨 | 理由 |
|---|---|---|
| 新規機能実装 | 🟣 Claude Code | 複数ファイル作成・テスト・設定変更を一気通貫 |
| リファクタリング | 🟣 Claude Code | 影響範囲を自律探索して安全に変更 |
| UI レイアウト微調整 | 🔵 Cursor | 見た目を確認しながらCSS/JSXを調整 |
| テスト追加 | 🟣 Claude Code | 既存実装を読み込み→テスト生成→実行→修正が得意 |
| ドキュメント作成 | どちらでも可 | 量が多ければClaude Code、部分修正ならCursor |
| バグ修正（原因不明） | 🟣 Claude Code | ログ確認・コード探索・仮説検証の自律ループ |
| バグ修正（原因特定済み） | 🔵 Cursor | 該当ファイルを開いてピンポイント修正 |
| 設定ファイル編集 | 🔵 Cursor | 1ファイル完結の小さな変更 |
3. 実践セットアップ：.cursorrules と CLAUDE.md を同一リポで共存させる
併用するうえで最も重要なのが、両ツールのプロジェクト設定を共存させることです。
ディレクトリ構成
my-project/
├── CLAUDE.md # Claude Code用プロジェクト指示
├── .cursorrules # Cursor用プロジェクトルール
├── .cursorignore # Cursorのインデックス除外設定
├── .claude/
│ └── settings.json # Claude Codeの権限設定
├── .cursor/
│ └── rules/ # Cursor追加ルール（ディレクトリ形式）
│ └── coding-style.mdc
├── src/
├── tests/
└── ...
CLAUDE.md の書き方（ポイント）
# CLAUDE.md
## プロジェクト概要
TypeScript + React + Prisma のWebアプリケーション。
## ビルド・テストコマンド
- `npm run build` — ビルド
- `npm run test` — 全テスト実行
- `npm run test -- --testPathPattern=<ファイル名>` — 単体テスト
## コーディング規約
- 関数コンポーネントのみ使用（クラスコンポーネント禁止）
- エラーハンドリングは Result 型パターンを使用
- コミットメッセージは Conventional Commits 形式
## 注意事項
- .env ファイルは絶対に読み取らないこと
- Cursorとの併用環境のため、変更後は必ず git status で差分を確認すること
.cursorrules の書き方（ポイント）
# Cursor Project Rules
## 言語・フレームワーク
TypeScript, React 18, Prisma ORM
## コーディングスタイル
- 関数コンポーネント + hooks のみ
- CSS Modules を使用（Tailwind不使用）
- エラーは Result 型パターンで処理
## Claude Codeとの併用時の注意
- 大規模変更はClaude Codeで実施済みの場合があるため、
作業開始前に最新の git log を確認すること
- コンフリクトが発生した場合は git stash で退避してから再度取り込む
共通ルールの一元管理（推奨）
コーディング規約の重複を避けるために、共通ルールを別ファイルに切り出す方法が有効です。
CLAUDE.md には docs/coding-standards.md を必ず参照すること と書けば、Claude Codeは自律的にそのファイルを読みに行きます。.cursorrules にはそのファイルの要点を転記しつつ、詳細は同ファイルを参照するよう促します。
4. 実務ケーススタディ
Case 1：新規API + 画面追加 → Claude Code 主導
タスク内容： ユーザープロフィール編集機能の追加（API・DB変更・画面・テスト）
# Claude Codeへの指示例
ユーザープロフィール編集機能を実装してください。
- Prisma スキーマに bio, avatarUrl カラムを追加
- PATCH /api/users/:id エンドポイントを作成
- src/pages/profile/edit.tsx に編集画面を作成
- 対応するテストも作成
- マイグレーションを生成して適用
結果： Claude Codeが8ファイルを作成・修正。Prismaマイグレーション生成→テスト実行→失敗→修正のループを自律的に3回転して完了。所要時間は約12分。
この後のCursorの出番： 生成された編集画面のレイアウト微調整、フォームのバリデーションメッセージの文言修正をCursorで実施。差分を見ながら約5分で完了。
Case 2：CSSレイアウト崩れ修正 → Cursor 主導
タスク内容： レスポンシブ対応時にサイドバーが画面外にはみ出すバグの修正
Cursorで該当コンポーネントを開き、インラインでCSSを修正。プレビューを確認しながらflex-shrinkとoverflowの値を調整。3分で完了。
このタスクにClaude Codeを使うと、まずコードベースの探索から始まるため、却ってオーバーヘッドが発生します。
Case 3：複合パターン（Claude Code → Cursor リレー）
実務で最も多いのが、このリレー方式です。
5. 計測結果：併用前後のタスク完了時間を10タスクで定量比較
個人開発プロジェクト（TypeScript + React + Node.js、約15,000行）で10タスクを計測しました。
| # | タスク内容 | Claude Code単体 | Cursor単体 | 併用 | 短縮率 |
|---|---|---|---|---|---|
| 1 | 新規CRUDエンドポイント追加 | 15分 | 28分 | 14分（CC主導） | 7% |
| 2 | フォームUI微調整 | 12分 | 4分 | 4分（Cu主導） | 67% |
| 3 | 全テストケース追加 | 10分 | 22分 | 9分（CC主導） | 10% |
| 4 | リファクタ（関数分割） | 18分 | 25分 | 13分（CC→Cu） | 28% |
| 5 | バグ修正（原因不明） | 8分 | 20分 | 8分（CC主導） | 0% |
| 6 | バグ修正（原因特定済） | 7分 | 3分 | 3分（Cu主導） | 57% |
| 7 | DB スキーマ変更＋マイグレ | 12分 | 18分 | 11分（CC主導） | 8% |
| 8 | CSS アニメーション実装 | 15分 | 6分 | 6分（Cu主導） | 60% |
| 9 | README 大幅更新 | 8分 | 10分 | 7分（CC主導） | 13% |
| 10 | 認証フロー新規実装 | 25分 | 40分 | 18分（CC→Cu） | 28% |
| 合計 | 130分 | 176分 | 93分 | 約1.8倍高速 |
注意： これは筆者個人の環境・スキルレベルでの計測であり、再現性を保証するものではありません。タスクの性質やプロジェクト規模によって結果は変動します。
最大の効果が出たポイントは、「Claude Code単体でも速いが、Cursorが圧倒的に速いタスクをCursorに回す」ことで、全体の合計時間が大きく短縮された点です。単一ツールではどちらを選んでも苦手なタスクで時間を浪費していました。
6. 落とし穴と対策
落とし穴①：同時編集によるコンフリクト
症状： Claude Codeがファイルを書き換えている最中に、Cursorで同じファイルを編集してしまう。
対策：
- 同時に同一ファイルを操作しない（基本原則）
- Claude Codeの作業中はCursorでは別ファイル or 読み取り専用で確認
- Claude Codeの作業完了後にgit diffで差分を確認してからCursorへ移行
落とし穴②：コンテキスト汚染
症状： Claude Codeに渡した指示の文脈がCursorに共有されない（逆も然り）。結果、各ツールが「相手が何をしたか知らない」状態で作業し、一貫性のないコードが生成される。
対策：
- gitのコミット履歴を中継地点として使う。Claude Codeでの変更後はコミットし、Cursorはその差分を読んでから作業開始
-
CLAUDE.mdと.cursorrulesに共通規約を揃えておく（セクション3参照）
落とし穴③：コスト二重課金
症状： Claude CodeはAnthropicのAPI（またはClaude Max/Proプラン）、CursorはCursor Proの月額が発生。両方使うとコストが増える。
対策：
- Cursorの無料枠（月500回のリクエスト等）で足りるならCursor無料プランで運用
- Claude Codeの利用頻度が高ければClaude Max（月額定額）を検討
- チームで共有する場合は、タスク種別ごとにどちらを使うかガイドラインを設け、不要な重複利用を防ぐ
まとめ
- Claude Codeは「大きく作る・横断的に直す」、Cursorは「細かく磨く・視覚的に確認する」。得意領域が異なるからこそ併用が効く
-
同一リポジトリでの共存は
CLAUDE.mdと.cursorrulesを整備するだけで実現可能。共通規約を一元管理するとメンテコストも抑えられる - 「どちらを使うか」の判断基準をチームで共有することで、迷いと手戻りが消える。フローチャートやマトリクスを壁に貼っておくくらいがちょうどいい