このサイトには.cursorrules を CLAUDE.md に変換するガイドが既にあります。あれはファイルフォーマットの移行をカバーするものです。このガイドは別の問題を扱います。
CursorからClaude Codeへの移行で難しい部分は、設定ファイルの変換ではありません。Cursorを何ヶ月も使って積み上げた習慣や筋肉記憶を作り直すことです——キーボードショートカット、ワークフローのリズム、リクエストの言い方、AIを使うべき場面と自分でタイプした方が速い場面のメンタルモデル。これらは設定ファイルより移行に時間がかかりますが、誰も話題にしません。
このガイドはその部分に焦点を当てます。
まず：完全に切り替える必要があるか？
率直に言うと：たぶん必要ありません。少なくとも一気には。
多くのチームが行き着いた最も生産的なセットアップは「CursorかClaude Codeか」ではなく「編集にCursor、複雑なタスクにClaude Code」です。Cursorはオートコンプリート、タブ補完、クイックインライン編集を非常によく処理します。Claude Codeの強み——1Mトークンコンテキスト、ターミナルネイティブ操作、サブエージェントサポート——は、アーキテクチャ的に複雑な作業（大規模なリファクタリング、クロスファイルのバグ追跡、引き継いだコードベースの理解、ゼロからの機能スキャフォールディング）をする際に最も価値を発揮します。
両方を使うことは妥協ではなく、合理的な専門化です。Claude CodeはCursorの統合ターミナル内で問題なく動作します（Ctrl+`` で開き、claudeでセッション開始）。差分はCursorのエディタにレンダリングされます。両方が使えます。
Claude Codeをより深く使いたい場合、またはフルターミナルファーストにしたい場合は続きをどうぞ。
メンタルモデルの転換
Cursorはエディタファーストです。ファイルを開き、コードを選択し、やりたいことを記述し、提案を受け入れるか却下するかします。AIはすでにやっていることに重ねられた提案エンジンです。
Claude Codeはカンバセーションファーストです。自然言語でタスクを記述すると、Claudeが必要なものを読み、必要なものを実行し、作業を行います。コードを選択してClaudeに変更を依頼するのではなく、Claudeに何かを達成するように依頼し、Claudeがどのファイルが関連しているか、どんな変更が必要か、結果をどう検証するかを判断します。
この転換は微妙に聞こえますが、リクエストの言い方が変わります。Cursorでは関数を選択して「early returnを使うようにリファクタリングして」と書くかもしれません。Claude Codeでの同等のリクエストはもっとこう書きます：「src/orders/processor.ts の processOrder 関数は深くネストされた条件文があります。early returnを使うようにリファクタリングして、ハッピーパスを説明するコメントを追加してください。」
Claude Codeには選択ではなく目的地を伝えます。Claudeがそこまでナビゲートします。
もうひとつのメンタルモデルの転換：Claudeが実行するツールを信頼してください。 Claude Codeはbashコマンドを実行し、ファイルを読み、ファイルを書き、テストを実行します。選択したテキストだけに作用するAIに慣れていると、これを見ることは不安を感じさせるかもしれません。初めて本当のタスクに使う最初の数回、本能的に介入したくなります。実行させてください。何かおかしく見えたら Ctrl+C で中断しますが、引き戻す前に複数のファイルとステップにまたがるタスクを完了させてみましょう。
Cursorに近い環境の設定
キーバインディング
Cursorユーザーには長年のVS Codeキーバインディングが染みついています。Claude Codeのデフォルトはターミナルネイティブで、重度のターミナルユーザーでなければ違和感があります。
朗報：Claude Codeのキーバインディングシステムは完全にカスタマイズできます。~/.claude/keybindings.json を編集して何でも再マップできます。Cursorユーザーがよく変更するデフォルト：
{
"submit": "ctrl+enter",
"new_session": "ctrl+n",
"interrupt": "ctrl+c",
"toggle_plan_mode": "shift+tab",
"open_in_editor": "ctrl+g"
}Enterが改行を追加するCursorの動作に慣れている場合、送信に ctrl+enter を設定するのは一般的な好みです。ctrl+g で現在の差分をエディタ（Cursor、VS Code、または $EDITOR に設定されているもの）で開くと、受け入れる前に見慣れたコンテキストでClaudeの変更をレビューできます。
プランモード
Claude Codeの最も便利な機能の1つには、Cursorに相当するものがありません。タスクを記述する前に Shift+Tab を押すと、Claudeがプランモードに入ります——変更を検討し、何をするか説明し、ファイルに触れる前に承認を待ちます。
取り消しにくいことをしようとしているとき、プランモードを使いましょう：大規模なリファクタリング、データベーススキーマの変更、認証に触れるもの、正確に記述する方法が確信できないタスク。オーバーヘッドは確認ステップが1つ増えるだけです。利点は、15ファイルに組み込まれる前に誤った前提を捕捉することです。
VS Code / Cursor統合
ターミナルファーストにしつつ、差分をCursorでレンダリングしたい場合：
# シェル設定に追加
export EDITOR="cursor --wait"これを設定すると、Claude Codeがレビューのためにファイルを開く際（/edit、/view）、Cursorで開きます。レビューし、保存し、タブを閉じると、Claudeが続行します。ワークフローは：ターミナルでClaude、Cursorでレビュー、ターミナルに戻る、という流れになります。
MCP：Cursorの拡張機能に相当するもの
Cursorには豊富な拡張機能エコシステムがあります。Claude Codeのツール統合に相当するものがMCP（Model Context Protocol）です。
MCPを使うと、Claude Codeが外部データソースやサービスに接続できます。手動で説明する必要はありません。CursorユーザーがFigmaプラグインやJira統合をインストールするように、Claude CodeユーザーはMCPサーバーを設定します。
プロジェクトルートに .mcp.json を作成（プロジェクトスコープ、リポジトリにコミット）するか、~/.claude/.mcp.json（グローバル、全プロジェクト）に設定します：
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["@modelcontextprotocol/server-github"],
"env": {
"GITHUB_TOKEN": "${GITHUB_TOKEN}"
}
},
"filesystem": {
"command": "npx",
"args": ["@modelcontextprotocol/server-filesystem", "/path/to/project"]
}
}
}Cursorから移行するチームがまず設定すべき高価値のMCP統合：
- GitHub MCP — ペーストする代わりにClaudeがPR、Issue、コメントを直接読める
- LinearまたはJira MCP — コピー&ペーストなしのタスクコンテキスト
- Filesystem MCP — 大きなモノレポへの拡張ファイルアクセス
MCPエコシステムは急速に成長しています。利用可能なサーバーをカテゴリ別に一覧しているMCPサーバーレジストリが良い出発点です。
Gitワークフロー
ここでClaude Codeのターミナルネイティブな性質がCursorに対して本当の優位性を持ちます。
Cursorでは、gitは主にVS CodeのSource Controlパネルで処理されます——ファイルを視覚的にステージし、コミットメッセージを書き、UIでプッシュします。Claude Codeはターミナルでgitと直接連携するため、次のようなワークフローが可能になります：
タスクスコープのコミット。 タスク完了後、diffに基づいてコミットメッセージを書くようにClaudeに依頼します。現在のdiffを読んで、何が変わったかを正確に説明するメッセージを書きます。疲れているときに誰もが書くプレースホルダーメッセージではなく、将来の自分が本当に助かるメッセージを。
> Write a commit message for the current changes（現在の変更のコミットメッセージを書いて）コミット前レビュー。 コミット前に、意図しないものがないかdiffをレビューするようにClaudeに依頼します——残ったデバッグログ、ハードコードされたテストデータ、Issueにすべきだったコメント。
ブランチとワークツリーの管理。 複数の機能に取り組んでいる場合、Claude Codeはgitワークツリーとうまく連携します。各ワークツリーは別のClaude Codeセッションを実行し、それらはリポジトリの同じAuto Memoryを共有します。あるターミナルでClaude Codeが機能ブランチで作業している間、別のターミナルでPRをレビューできます——完全に独立したコンテキスト、セッション状態の汚染なし。
日次ワークフローパターン
Claude Codeを最も活用しているチームは、他のすべてと並行して常時起動しているよりも、集中したバーストで使う傾向があります。
典型的なパターン：
朝のコンテキスト設定。 Claude Codeセッションを開始し、現在のタスクかレビュー中のPRをペーストします。Claudeに関連ファイルを読ませて、何を理解しているか説明させます。飛び込む前に誤解を修正します。2〜3分かかりますが、多くの引き返しを防ぎます。
タスクサイズのセッション。 意味のある作業単位ごとに1セッション——機能、バグ修正、リファクタリング。完了してコミットしたら、次のタスクのためにフレッシュに始めます。Claude Codeのコンテキストは、1つのタスクにフォーカスしているときに最も価値があります。6時間動き続けて40の異なるファイルに触れたセッションは、1つのタスクにスコープされたクリーンなセッションよりClaudeにとって推論が難しくなります。
自然な区切りで /compact を使う。 タスクのフェーズを終えたとき（実装を書いた、次はテストを書く）、/compact を実行してセッション履歴を圧縮します。実装フェーズのClaudeのサマリーが、テストフェーズのコンテキストになります。これにより長い作業セッションを通じて品質が維持されます。
その日の終わりの引き継ぎ。 停止する前に、MEMORY.md を達成したこと、行った決定、残っていることで更新するようにClaudeに依頼します。翌朝戻ってきたとき、コンテキストはすでに設定されています。
正直なトレードオフ
Claude CodeはCursorよりすべてにおいて優れているわけではありません。
オートコンプリートはそこにありません。 大半の時間をボイラープレートの記述に使って、現在の行や関数をAIに補完させたい場合、Cursorのタブ補完の方が優れています。Claude Codeはそのユースケース向けに設計されていません。
デフォルトではビジュアルdiffプレビューがありません。 Cursorは受け入れる前に提案された変更をインラインで、追加と削除をハイライトして表示します。Claude Codeのデフォルトはターミナルで変更を表示することです。$EDITOR をCursorまたはVS Codeに設定した場合は、より豊かなdiffビューが得られますが——追加のステップが必要です。
学習曲線は本物です。 Claude Codeをうまく使えるようになることは、良いタスク記述を書けるようになることを意味します——Claudeが正しいことをするくらい具体的で、あらかじめ計画した解決策を実行するだけでなく問題を解決できるくらい広い。そのスキルを開発するには数週間かかります。Cursorの選択して記述するワークフローのフロアの方が低いです。
コストモデルが違います。 Cursorは定額サブスクリプションで課金します。Claude CodeのAPI使用量は、APIプランではトークンごとに課金され、Max/Team/Enterpriseプランでは使用量制限にカウントされます。ヘビーユーザーは完全に切り替える前にこれをモデル化すべきです。
乗り換えのtipping point
最も成功した切り替えをするチームには、特定のトリガーがある傾向があります：Cursorが対応できない問題にぶつかったとき。Cursorのコンテキストに収まらないほど大きなコードベース。多すぎるファイルにまたがるリファクタリング。あまりにも多くの相互作用するシステムの理解が必要なデバッグセッション。
Claude Codeはそういった問題をうまく解決します。本当に難しいことに使って、1Mコンテキスト＋エージェント実行が何を生み出すか見てしまえば、「切り替えるべきか？」という疑問は自然と答えが出ます。
Cursorの横にターミナルを開いて始めましょう。CursorでイライラするタスクにはClaude Codeを使います。Claude Codeがそれらをよりうまく処理したとき、そこから広げていきましょう。