「CursorとClaude Code、どっちを使うべきか」という問いの立て方が間違っている。

毎週のようにX（旧Twitter）やRedditに「Xを捨ててYに乗り換えた。後悔ゼロ」という投稿が流れてくる。どれも一定の賛同を集めるが、共通して見落としていることがある。

2026年に最も生産性の高い開発者はどちらか一方を選んでいない。両方を、明確な役割分担で使っている。

ただし「なんとなく両方使う」ではダメだ。それをやると混乱が生じる。どちらのAIにもプロジェクトの文脈を説明し直す羽目になり、コンテキストがズレて、精神的なオーバーヘッドが増える。うまく機能するハイブリッドワークフローには構造がある。各ツールに具体的な役割を割り当て、ツール間のコンテキストをクリーンに保ち、設定ファイルで両ツールがプロジェクトを一貫して理解できるようにする。

この記事はそのプレイブックだ。各ツールが何に最適化されているか、7つの具体的なワークフローパターン、.cursorrulesとCLAUDE.mdの共存設定法、実タスクでのベンチマーク比較、そしてハイブリッドワークフローを壊す典型的な失敗パターンを網羅する。

「どちらか選べ」という誤った前提

なぜ「どちらか選べ」論が広まったかを整理しておく。

Cursorが登場した当初、Claude Codeとは明確に異なるカテゴリーのツールだった。CursorはIDE。Claude Codeはターミナルで動くエージェンティックツール。用途がほとんど重ならなかったため、既存のワークフローにフィットする方を選んでそのまま使い続けるのが自然だった。

この境界線が今はかなり曖昧になっている。Cursorにはエディタ操作なしで複数ファイルのリファクタリングを実行するバックグラウンドエージェントが加わった。Claude CodeにはVS CodeとJetBrainsのネイティブ拡張機能が追加された。技術的には、どちらもほとんどのタスクをこなせる。

だが「技術的にできる」と「アーキテクチャ的に最適化されている」は別の話だ。ドライバーでネジを回すことはできる。でもプラスドライバーの方がうまい。2026年の問いは「どちらのツールがこのタスクをこなせるか」ではなく「どちらの設計思想がこの仕事により合っているか」だ。

その設計思想は、実際に大きく違う。

Cursorはエディタを中心に設計されている。コンテキストモデルはスクリーン上の可視部分から始まり、参照ファイル、そして@codebaseインデックスによる広範なコードベースへと広がる。主要なフィードバックループはdiff。変更内容を適用前に確認し、ハンク単位で承認・却下できる。全体の体験は、フロー状態を維持しながら高速にインライン編集を続けることに最適化されている。

Claude Codeはシェルを中心に設計されている。コンテキストモデルはタスクの説明から始まり、モデルが自分で判断して必要なファイルを読んでいく。Bashコマンドの実行、ファイルの読み取り、Webフェッチなどのツールを使って、コードベースの理解を自力で構築する。主要なフィードバックループは会話。意図を説明し、実行してもらい、結果を評価し、改善を求める。全体の体験は、コードを書く前にまず問題を深く考える必要がある複雑なマルチステップタスクに最適化されている。

この設計の違いが、それぞれの強みを生む。

Cursorが得意なこと

インライン編集と即時フィードバック

CursorのCmd+Kによるインライン編集は、ローカルで明確にスコープされた変更に対して右に出るものがない。範囲を選択し、自然言語で変更を記述し、diffを受け取り、承認または却下する。1ラウンドトリップは数秒で完了する。ファイルの中で繰り返し改善を加えていく作業、ロジックの整理、型の調整、関数内のリネームなど、こういった作業にはこの短いループが最適だ。

Claude Codeで同じ編集をエージェントモードで依頼することもできるが、不要なコンテキストを読み込み、想定外のファイルに触れる可能性があり、フィードバックループも長くなる。

コードベースを学習するTab補完

Cursorのタブ補完（タイピング中に表示されるゴーストテキスト）は、インデックス層経由でコードベース上で学習されている。数時間使い込むと、あなたのパターンに特化した補完が出始める。変数命名規則、importスタイル、よく使うエラーハンドリングのイディオムまで。これはモードを切り替えずプロンプトを書かずに得られる環境的な加速だ。

Claude Codeに相当機能はない。カーソル位置を意識した補完向けには設計されていない。

複数ファイルのリファクタリングとビジュアルdiff

Cursorのエージェントモードが5ファイルにまたがるリファクタリングを処理すると、ファイルが保存される前にすべてのdiffが確認できる。ファイル間をナビゲートし、個々のハンクを却下し、全体の変更を承認できる。このビジュアルレビューレイヤーは、コミット前に各ファイルを人間がチェックしたいリファクタリングで本当に使いやすい。

@参照によるコードベースチャット

Cursorのチャットインターフェースと@codebase、@file、@symbol参照は、既存コードについて正確なコンテキストコントロールで素早く質問する手段として優れている。「@UserAuthService.refreshTokenが実際に何をして、どこで呼ばれているか教えて」という問いに、Cursorはちょうど必要なコードをコンテキストに引き込んで答えてくれる。

Claude Codeが得意なこと

エージェンティックなマルチステップ実行

Claude Codeの設計は、本物のエージェンシーが必要なタスク向けに作られている。リサーチ、計画、実行、検証、エラーハンドリング、継続。「このRailsアプリに適切なマイグレーションシステムを構築し、ハードコードされたスキーマ変更をすべてバージョン管理されたマイグレーションに移行し、直接スキーマ変更がコミットされたらCIが落ちるようにしてくれ」と渡せば、体系的に進めてくれる。既存コードを読み、計画を書き、変更を加え、テストスイートを走らせ、失敗を読み、調整し、完了を伝えてくれる。

CursorもエージェントモードでこのようなことはできるがClaude Codeのツール使用、特に任意のbashコマンドを実行してその出力を反復できる能力が、フルエージェンティックループにおいてより強力だ。

長期的な計画タスク

コードを1行書く前に多くのソースから情報を統合する必要があるタスクは、Claude Codeの本領だ。アーキテクチャの決定。モノリスの分割方法。新機能のデータモデル設計。Claude Codeは20ファイルを読み、DBスキーマに対してクエリを実行し、テストカバレッジを確認し、構造化された提案を出せる。会話形式なので、コードを書く前に提案を繰り返し改善できる。

大規模コードベースへのバッチ操作

「deprecated v2/auth エンドポイントをすべて見つけて v3/auth に移行してくれ。レスポンス形状の違いも考慮して」というようなタスクは、CursorのエージェントモードよりClaude Codeが得意だ。主な理由は、中間ステップとしてシェルスクリプトを書いて実行できること。grepで全箇所を見つけ、マイグレーションスクリプトを書き、実行し、出力を確認し、エッジケースを修正し、テストスイートを走らせる、というのをすべて1セッションの中で行える。

大規模なコンテキスト管理

Claude Codeの1Mトークンのコンテキストウィンドウは、大規模なコードベースで実質的な優位性になる。サブシステム全体をパイプインして、モデルがその全体を横断的に推論できる。Cursorのコンテキストは本質的にエディタスコープ。インデックスされたコードベースを持つが、それは検索システムであり検索の限界がある、フルコンテキストシステムとは異なる。

外部統合

Claude Codeのシェルアクセスは、CLIを持つ任意のものと統合できることを意味する。データベースへのクエリ、linterの実行、APIのヘルスチェック、Vaultからの読み取り、そしてそれらの情報を推論に取り込むことができる。Cursorのサンドボックスはエディタ。Claude Codeのサンドボックスはマシン全体だ。

7つのハイブリッドワークフローパターン

上記の構造的な優位性に基づいて実際に機能するパターンを紹介する。各パターンにはツール間の明確なハンドオフポイントがある。

パターン1: スペック駆動開発（CCが設計、Cursorが実装）

使いどころ: 複雑さが十分あって事前設計が価値を持つ機能。2〜3ファイル以上、公開APIサーフェス、DBスキーマに触れるもの。

進め方:

Claude Codeをタスクの説明から始め、設計作業をさせる:

claude "ユーザーサービスにWebhookシステムを追加したい。
ユーザーがエンドポイントを登録でき、account_created、password_changed、
plan_upgradedのイベントをfireできるようにする。
何も書く前に完全な実装設計をしてくれ:
- DBスキーマ（どのテーブル、どのインデックス）
- APIエンドポイント（パス、リクエスト/レスポンス形状、認証）
- キューアーキテクチャ（配信失敗の処理）
- 作成/修正が必要なファイル
設計ドキュメントをdocs/webhooks-design.mdに書いて、承認を待て。"

docs/webhooks-design.mdをレビューする。同意できない箇所は修正を求める。設計が固まったらCursorを開く。設計ドキュメントをコンテキストとしてインポートする:

@docs/webhooks-design.md

この設計からDBマイグレーションを実装してくれ。
マイグレーションファイルをdb/migrations/[timestamp]_add_webhooks.sqlに作成。
スキーマは設計通り正確に。

設計ドキュメントを権威あるスペックとして、Cursorで機能を1つずつ実装していく。設計ドキュメントがカバーしていない実装上の決断が必要になったら、続ける前にClaude Codeに戻って解決する。

なぜうまくいくか: Claude Codeはアーキテクチャ決定が得意。「これはすぐにコードになる」というプレッシャーなしに推論できるからだ。Cursorは実装が速い。インライン編集とdiffレビューがあるから。設計ドキュメントがクリーンなハンドオフポイントになる。

パターン2: CCでバッチリファクタ、Cursorでレビュー

使いどころ: コードベース横断の変更。モジュールのリネーム。APIバージョンの移行。deprecated依存関係の削除。エラーハンドリングの標準化。

進め方:

Claude Codeにフルのリファクタタスクを与える。まずdry-runで確認:

claude "legacy `useLegacyAuth` フラグをコードベース全体から削除する。
1. まず: 変更せずすべての箇所をgrepしてリストアップ。
2. リスト全体と気づいたパターンを見せてくれ。
3. 確認後に移行を実行:
   - 全コンポーネントからフラグを削除
   - 条件分岐を削除（常に新しい認証パスを使う）
   - 設定ファイルとテストからもフラグを削除
   - ファイルカテゴリ毎にテストスイートを実行
auth.tsとauth.test.tsには触るな — そこは自分でやる。"

Claude Codeが完了してテストスイートがパスしたら、git diffで変更を確認する。Cursorを開き、Cursorのdiffビューでファイルを1件ずつレビューする。Claude Codeが見落としたか、うまく処理できなかったエッジケースはCmd+Kで修正する。

なぜうまくいくか: Claude Codeのバッチ実行と中間検証は、同じリファクタを手動でファイルごとにやるより良い。でも人間のレビューには、ターミナルでgit diffの壁を読むより、Cursorのdiffビューの方が使いやすい。CCからCursorへのハンドオフはレビューの段階で起きる。

パターン3: Cursorでインライン反復、CCで統合テスト

使いどころ: 現在進行形で開発中の新しいエンドポイント、コンポーネント、関数。

進め方:

積極的なコーディングはCursorで行う。インライン編集にCmd+K、補完にTab、素早い質問にChatを使う。動く実装ができたら、Claude Codeに統合テストのバトンを渡す:

claude "/api/webhooks/register エンドポイントを実装したところ。
実装はsrc/api/webhooks/register.ts。
既存のテストはsrc/api/webhooks/__tests__/register.test.tsにあるが
ハッピーパスしかカバーしていない。

以下をカバーする統合テストを書いてくれ:
1. 必須フィールドの欠落（個別に、組み合わせで）
2. 無効なURLフォーマット（localhost、IP、非HTTPSのエッジケースを含む）
3. 重複登録（同じユーザー、同じURL）
4. レート制限（ユーザーあたり10エンドポイント以上）
5. 認証失敗

テストを書いた後にテストスイートを実行して、失敗があれば修正してくれ。"

Claude Codeが書いたテストをレビューし、テストが明らかにした問題をCursorに戻って修正する。

なぜうまくいくか: Cursorの速度優位はコードを書くことにある。統合テストを書くことは、速度よりも失敗のモードを体系的に考えることについてであり、これはClaude Codeが得意な計画タスクだ。組み合わせると、どちらか1つのツールでやるより良いカバレッジが得られる。

パターン4: CCでデバッグ、Cursorで修正

使いどころ: 本番バグや再現しにくい問題。

進め方:

エラー、ログ、関連コンテキストをClaude Codeに渡す:

claude "本番エラー — チェックアウトでユーザーの約2%に発生。

スタックトレース:
TypeError: Cannot read properties of undefined (reading 'amount')
  at calculateTax (src/checkout/tax.ts:47)
  at processOrder (src/checkout/processor.ts:112)

関連ログを見ると以下の場合に発生:
- カートに複数アイテムがある
- 少なくとも1つのアイテムにクーポンが適用されている
- クーポンが2025-01-01より前に作成されている

調査対象:
- src/checkout/tax.ts
- src/checkout/processor.ts
- src/checkout/coupon.ts

根本原因を見つけて、明確に説明してくれ。まだ修正は書かないで。"

Claude Codeがファイルを読み、コードパスを推論し、診断を出す。診断に同意したら、Cursorで該当ファイルを開き、Cmd+Kでエディタのフルコンテキストを使って修正を適用する。

なぜうまくいくか: 診断は推論タスクであり、Claude Codeのフルコンテキストアクセスと体系的なツール使用が活きる。何が問題かが分かれば、修正は正確なインライン編集であり、Cursorの得意領域だ。

パターン5: CCでコンテキストプライミング、Cursorで日常作業

使いどころ: 初めて触るコードベースの部分での作業開始。

進め方:

Cursorで関連ファイルを開く前に、Claude Codeセッションを走らせて自分のメンタルモデルを構築する:

claude "初めて課金サブシステムを触る。
関連ファイルを読んで以下を教えてくれ:
1. 主要コンポーネントの地図とそれらがどう相互作用するか
2. 主要なデータフロー（サブスクリプションの作成、更新、キャンセル）
3. 知っておくべき非自明な不変条件（破ったらバグになること）
4. テストカバレッジの状況
5. 知っておくべきtech debtや既知の問題

コードは書かないで。システムを理解するのを助けてくれ。"

出力を注意深く読む。それからそのメンタルモデルをすでに持った状態でCursorを開く。システムを理解しているので、Cursorへのプロンプトがより正確になり、不変条件を知っているのでミスが減る。

なぜうまくいくか: 「触る前に理解する」はコードを出力しない計画タスクだ。会話形式なら本当に理解できるまでフォローアップ質問ができるので、Claude Codeでやる価値がある。Cursorのフィードバックループはコードを中心に設計されているので、これには向かない。

パターン6: 並行ワークストリーム（CCをバックグラウンドで、Cursorをフォアグラウンドで）

使いどころ: ブロックされたくない長時間タスク。

進め方:

tmuxペインまたは別ターミナルでClaude Codeセッションを長時間タスクで開始する:

# ターミナル1 — バックグラウンドで動くClaude Code
claude "paymentsモジュール全体に包括的なテストカバレッジを生成してくれ。
src/payments/の各ファイルについて、対応するテストをsrc/payments/__tests__/に書いてくれ。
まず既存のテストを実行してカバレッジを把握し、
カバーされていないケースの新しいテストを書いてくれ。
進捗を随時報告して。これは時間がかかる — 私は並行して別の作業をする。"

その間、メインウィンドウでは無関係の作業にCursorを使う。Claude Codeは進捗を報告し、あいまいな点があれば質問してくる。返答しながらCursorの作業を続ける。

このパターンはClaude Codeの/ide統合と特によく機能する。エディタとのやり取りをブロックせずに直接エディタに変更をプッシュできる。

なぜうまくいくか: Claude Codeは自律的に動き、最小限の介入で長いタスクを処理できる。Cursorはアクティブな関与を必要とする。2つのストリームを同時に進めるスループットが得られる。

パターン7: CCでドキュメント生成、Cursorでコード近傍のレビュー

使いどころ: 複雑なシステムのドキュメント、APIドキュメント生成、詳細なコメントの記述。

進め方:

ドキュメントはシステム全体の理解と明確な合成が必要だ。Claude Codeにスコープを渡す:

claude "公開REST APIの完全なAPIドキュメントを生成してくれ。
src/api/のすべてのルートファイルを読んで、以下の構造でdocs/api/にドキュメントを作成してくれ:
- リソースごとに1つのマークダウンファイル（users.md、webhooks.md等）
- 各エンドポイントについて: メソッド、パス、認証要件、リクエスト形状、レスポンス形状、エラーコード
- 各エンドポイントのcurlの例を含める
- 不整合または不完全に見えるエンドポイントにはフラグを立てる

docs/api/の既存の部分的なドキュメントを先に読んで、重複せずにギャップを埋めてくれ。"

ドラフトができたら、Cursorのチャットを使って実際のコードと並べてセクションをレビュー・改善する:

@src/api/webhooks.ts @docs/api/webhooks.md

ドキュメントにはユーザーあたり10エンドポイントまでと書いてあるが、
コードでその制限が強制されているのが見当たらない。
これを整合させてくれ。

なぜうまくいくか: ドキュメントのドラフト作成はClaude Codeが強いタスク（多くのファイルを統合し、構造化された出力を書く）。実際のコードとのドキュメントのレビューはCursorが強いタスク（ドキュメントと実装を同じコンテキストウィンドウで比較する）。

設定ファイルの構成

ハイブリッドワークフローがクリーンに機能するには、両ツールがプロジェクトを一貫して理解している必要がある。共有設定なしでは、Cursorにはすでにクラウドコードで教えた規約を再説明する羽目になる。

原則: 単一の真実の源、2つのコンシューマー

同じプロジェクトの規約を2回書かない。正規の記述を1箇所に置き、両設定から参照する。

実際の分担:

• CLAUDE.md: 完全なプロジェクトコンテキスト。コマンド、規約、アーキテクチャ、特別な指示、Claude Codeが複雑なタスクに必要なもの。
• .cursorrules: Cursor固有のルール。コードスタイル、補完の好み、コンテキストヒント。CLAUDE.mdのサブセット、エディタレベルのインタラクション用にフォーマットされたもの。

CLAUDE.mdが全文書。.cursorrulesはエディタレベルのインタラクション用のターゲットサマリー。

ハイブリッドプロジェクト向けCLAUDE.mdの構造

# CLAUDE.md

## プロジェクト概要
[1段落。このプロジェクトが何で、何をするか、技術スタック。]

## アーキテクチャ
[主要コンポーネントとそれらの関係。図があれば参照。]

## 開発コマンド
```bash
npm run dev          # 開発サーバー（ポート3000）
npm run test         # Jest + Playwright
npm run test:unit    # Jestのみ
npm run lint         # ESLint + Prettierチェック
npm run build        # プロダクションビルド
npm run db:migrate   # 保留中のマイグレーションを実行
npm run db:seed      # 開発DBのシード

規約

コードスタイル

• TypeScript strictモード。any禁止。公開関数には明示的な戻り値型。
• 名前付きエクスポートのみ。デフォルトエクスポート禁止。
• エラーハンドリング: src/lib/result.tsのResult<T, E>パターンを常に使う。throwしない。
• ロギング: src/lib/logger.tsを使う。プロダクションコードでconsole.log禁止。

ファイル構成

• src/features/以下のフィーチャーベース構造
• 共有ユーティリティはsrc/lib/に
• APIルートはsrc/api/[resource]/[action].ts
• テストはco-located: src/features/auth/__tests__/login.test.ts

重要な不変条件

[破るとバグになる非自明なルール。新しい開発者が辛い経験で学ぶようなこと。]

• ユーザーIDは常にUUID v4。外部APIでは連番IDを使わない。
• タイムスタンプはすべてUTCで保存。変換は表示レイヤーでのみ行う。
• UserContextオブジェクトは認証後不変。リクエストの途中でミュートしない。

現在の状態

• v3 auth APIへの移行進行中 — docs/v3-auth-migration.md参照
• useLegacyPaymentsフラグが約10%のユーザーに対してアクティブ — まだ削除しない
• DBコネクションプーリング実装済み（PR #412）

### ハイブリッドプロジェクト向け.cursorrules構造

.cursorrules

スタック

TypeScript、Next.js 14（App Router）、Prisma、PostgreSQL、Jest + Playwright。

コードスタイルルール

• any型禁止。エクスポートされた全関数に明示的な戻り値型。
• 名前付きエクスポートのみ — デフォルトエクスポート禁止。
• src/lib/result.tsのResult<T, E>パターンを使う。エラーをthrowしない — returnする。
• ロギングにはsrc/lib/logger.tsを使う。console.log禁止。

補完の好み

• .then()チェーンよりasync/awaitを優先。
• 新しいAPIエンドポイント作成時はsrc/api/users/get.tsのパターンに従う。
• DBクエリにはsrc/lib/db.tsのPrismaクライアントを使う。
• 新しいReactコンポーネントはsrc/components/ui/Button.tsxのパターンを使う。

コンテキストヒント

• メインビジネスロジックはsrc/features/以下
• 共有型はsrc/types/以下
• 環境設定はsrc/config.ts（process.envを直接読まない）

避けること

• process.envを直接読むコードを生成しない。
• 連番数値IDを生成しない — UUIDを使う。
• UserContextオブジェクトをミュートしない。
• console.log文を追加しない。

参照

• プロジェクトの全コンテキスト: CLAUDE.md
• アーキテクチャ概要: docs/architecture.md
• APIリファレンス: docs/api/

### 同期を保つ方法

2つのファイルのメンテナンス問題はドリフトだ。新しい規約を追加してCLAUDE.mdを更新するが、`.cursorrules`を更新しない。1ヶ月後に矛盾が生じる。

これを防ぐ2つの実践:

**1. まずCLAUDE.mdに書く。** 新しい規約を追加するなら、CLAUDE.mdを正規の場所として先に追加する。次に`.cursorrules`に簡単な参照を追加する。後で更新が必要になったら、両方を更新する。

**2. 定期的にClaude Codeで同期する:**

```bash
claude ".cursorrules をCLAUDE.mdと照合してくれ。
CLAUDE.mdが正規のソースだ。
.cursorrules に欠けているCLAUDE.mdの規約を追加してくれ。
CLAUDE.mdと矛盾する.cursorrulesのものは削除してくれ。
CLAUDE.mdは変更しないで。"

これを月次メンテナンスの一部として実行する。聞くのに10秒、Claude Codeが実行するのに1分かかる。

実測ベンチマーク

これらは合成ベンチマークではなく実際のタスクからの測定値だ。モデルのレイテンシだけでなく、考える時間、プロンプトを書く時間、レビューを含む壁時計の時間を反映している。

タスク1: 12本のAPIエンドポイントへの入力バリデーション追加

コンテキスト: 中規模のNext.js API。エンドポイントに一貫した入力バリデーションがなかった。タスク: 12エンドポイント全体にZodバリデーションスキーマを追加し、すでに持っている1エンドポイントの既存パターンに合わせる。

備考: Claude Codeはdiffレビューで止まることなくバッチマイグレーションを実行できたため、単体ツールとして最速だった。ハイブリッドアプローチが最速だったのは、実行にClaude Codeを使い、12ファイル全体を効率的にレビューするためにCursorのdiffビューを使ったから。

タスク2: 認証のレースコンディションのデバッグ

コンテキスト: 有効なセッションにも関わらず、ユーザーが散発的に401エラーを受け取る。再現が難しく、2人の開発者がそれぞれ30分見ていた。

備考: Claude Codeはauthモジュール、セッションストア、ミドルウェアチェーン全体を同時に読み、それら全体を横断的に推論できたため、根本原因の特定が速かった。診断が明確になれば、Cursorでの修正は4分（主にナビゲーションと実際の編集）。

タスク3: Payments API（8エンドポイント）のドキュメント作成

コンテキスト: 既存のドキュメントなし。タスク: 8エンドポイント全体の完全なマークダウンドキュメントを生成する。

タスク4: 新機能実装（Webhook登録システム）

コンテキスト: グリーンフィールド機能。5つの新規ファイルと3つの既存ファイルの変更で約400行。

備考: ハイブリッドアプローチは最速でかつレビュー問題が最少だった。設計ファースト段階で他のアプローチでは手戻りが必要だった2つの問題を事前に捕捉した。実装でのCursorの速度優位は本物だった。Claude Codeに会話で400行全体を書かせるより速かった。

失敗パターン

失敗1: コンテキストドリフト

Claude Codeとの会話で「v3 auth APIを使うことにした」というコンテキストを確立した。次にCursorを開くが、Cursorはこれを知らない。補完は古いパターンを提案する。

対策: Claude Codeで重要なコンテキスト更新があったら、CLAUDE.mdを更新する。Cursorは次の会話で更新されたルールを取り込む。緊急な場合は、.cursorrulesにも直接追加する。

失敗2: 競合する編集

Cursorでauth.tsを作業中。Claude Codeもエージェントセッションでauth.tsに変更を加えている。どちらかが後から保存して、もう一方を上書きする。

対策: 並行作業を始める前にファイルの所有権を明確に割り当てる。Claude Codeがファイルを処理中は、セッションが完了して結果をコミットするまでCursorでそのファイルを編集しない。

失敗3: 同じタスクの二重プロンプト

Cursorに何かを頼む。30秒かかって合理的だが不完全な結果が出る。焦れてClaude Codeを開き、同じことを頼む。今や同じ機能の2つの異なる半完成の実装がある。

対策: 始める前にどちらのツールがタスクを所有するかを決める。最初のツールが遅いからといって途中で切り替えない。アプローチを比較したいなら、意図的に行い、一方の結果を捨てる。

失敗4: Claude Codeセッションを使い捨てにする

長いClaude Codeセッションは、読んだもの、下した決断、タスクの現在の状態という多くのコンテキストを積み上げる。作業をコミットせず状態をメモせずにセッションを閉じると、そのコンテキストは消える。

対策: Claude Codeセッションを終了する前に、何をしたか、何が完了か、何が保留か、どんな決断を下したかをまとめさせる。それをタスクノートやdocs/wip/ファイルに保存する。

失敗5: 単純な編集にClaude Codeを使う

Claude Codeは強力だが、オーバーヘッドがある。ファイルの読み取り、計画立案、ツールコール。10行の編集なら、これはすべて無駄だ。

対策: 1つのファイルに収まり、明確にスコープされている変更にはCursorのCmd+Kを使う。経験則: 条件なしに1つの文で完全な変更を説明できるなら、Cursorが正しいツールだ。

失敗6: 設定レイヤーを無視する

両ツールを.cursorrulesとCLAUDE.mdの設定なしで実行すると、毎回の会話でプロジェクトの規約を再教示することになる。CursorはAIが規約に違反するパターンを提案する。Claude Codeはアーキテクチャと矛盾する決断を下す。

対策: ハイブリッドワークフローを採用する前に、良いCLAUDE.mdと.cursorrulesを書くために2時間かける。この投資はすぐに回収でき、時間とともに複利になる。

FAQ

Q: これを効果的に実行するためにCursor Pro + Claude Code Maxが必要ですか？

A: Cursor Pro（月$20）は無制限の高速リクエストと完全なエージェントモードを提供する。Claude Codeはトークンごとの課金（Sonnet 4.5でインプット$15/MTok）またはMaxサブスクリプション経由。ヘビーなハイブリッド使用には、Max + Cursor Proが現実的な設定。評価中なら、CursorのフリーティアとClaude Codeの従量制でコミットなしにパターンをテストできる。

Q: CursorのTab補完はどのくらいで自分のコードベースを学習しますか？

A: インデックスのビルドは最初のプロジェクト開設で数分かかる。コードベース固有の補完は通常、数時間のアクティブな使用後に改善が見え始める。大規模なコードベース（100k行以上）ではインデックスが完全にビルドされるまで最大30分かかることがある。

Q: CLAUDE.mdと.cursorrulesのルールが競合したらどうすればいいですか？

A: CLAUDE.mdを正規のソースとして扱う。競合が検出されたら、.cursorrulesをCLAUDE.mdに合わせて更新する。Claude Codeを使った定期的な同期を設定しておけば、この競合は稀になる。

Q: どのタスクにどちらのツールを使うか判断する方法は？

A: このヒューリスティックがほとんどのケースをカバーする:

• 1ファイル、明確にスコープされた変更 → Cursor
• 複数ファイル、明確にスコープされた変更 → Cursorエージェントまたはカラードコード
• 事前計画が必要なもの → まずClaude Code
• シェルコマンドの実行が必要なもの → Claude Code
• 不慣れなコードベースの理解 → Claude Code
• 書いているコードの反復的な改良 → Cursor
• 不明確な問題のデバッグ → 診断にClaude Code、修正にCursor

Q: CursorのターミナルパネルでClaude Codeを使えますか？

A: はい。多くの開発者がCursorの統合ターミナルでClaude Codeを実行しながら、Cursorのエディタをレビューに使っている。ウィンドウを切り替えずにClaude Codeのフル機能とCursorのエディタ機能を両立できる、最も自然なセットアップの1つだ。

まとめ

「どちらか選べ」というアドバイスは、これらのツールが本当に異なるカテゴリーにあった頃は理にかなっていた。2026年、CursorのエージェントモードとClaude Codeのエディタ統合で重複は増えたが、設計上の前提は変わっていない。CursorはIDE。Claude Codeはシェルベースのエージェント。この異なる設計の中心が、本当に補完的な強みを生む。

うまく機能するハイブリッドワークフローには2つの特性がある。習慣や慣れではなくアーキテクチャの適合性に基づいて各ツールに仕事を割り当て、設定レイヤーに投資して両ツールがプロジェクトの一貫したモデルを共有する。

この記事のパターンは出発点だ。あなたのコードベースには固有の特性がある。その規模、言語、アーキテクチャ、作業の性質が、バランスをシフトさせる。両ツールから最大限を引き出す開発者は、どの設計上の前提がどの問題に合うかの直感を育て、それに応じて作業をルーティングする人たちだ。

どちらのツールも優れている。意図的に組み合わせると、どちらか単独より優れている。

The Prompt Shelf 公開 — AIツールを使う開発者のための実践的リソース。