Cursor × Claude Code 連携設定と使い分け

Claude Codeをローカルに入れて、Cursorで開いている既存リポジトリに /ide を打ち、承認ダイアログを通して編集がその場で反映されるところまでつながると、IDE連携の全体像は一気に腹落ちします。
この記事は、Node.js 18 以上を前提に、最短手順だけを知りたい人と、候補に出ない・VSIX 手動導入が必要・WSL 周りで止まるといった詰まりどころまで先回りして潰したい人の両方に向けた内容です。

そのうえで、接続できた先に何が広がるのかも曖昧にしません。
MCP 経由でCursorからClaude Codeを呼ぶ発展形まで見渡しつつ、実務では 0→1 の骨組みをClaude Code、1→100 の磨き込みをCursorに 맡せると、役割が競合せず、むしろ作業の切り分けがきれいに決まります。

CursorとClaude Codeを連携する前に理解しておきたい違い

IDE一体型とCLI/エージェント型の本質的な差

CursorとClaude Codeは、どちらも「AIでコードを書く」道具に見えますが、作業の中心が置かれている場所が違います。
CursorはVS CodeベースのAIエディタで、補完、編集、差分確認、チャットまでをIDEの中で回していく設計です。
ファイルを開いたまま細部を詰めたり、変更内容を見比べながら整えたりする流れと相性が合います。
一方のClaude Codeはターミナル中心のagenticなアシスタントです。
コードベース全体を読んで複数ファイルをまたぎ、必要ならコマンド実行やGit操作まで進められます。

この差を先に押さえておくと、連携手順そのものも理解しやすくなります。
IDE統合でやっていることは、Cursorの編集画面を活かしたまま、Claude Codeの広い文脈理解と自律的な作業能力をつなぐことです。
実際の流れはシンプルで、Claude Codeをインストールして、作業中のリポジトリをCursorで開き、同じリポジトリでClaude Codeを起動し、/ide を実行します。
その場で候補一覧にCursorが出てくれば、IDE統合の入口までは通っています。
接続時にはセキュリティ確認画面が出るので、そこで許可してはじめて編集反映まで進みます。

私自身、同じリポジトリで両者を並行して使うと役割がきれいに分かれると感じます。
設計の相談や広い変更範囲を含む実装のたたき台はClaude Codeに任せたほうが前に進む速度が出ます。
そのあとでコンポーネントの見た目、文言、差分の収まりを詰める段階に入ると、Cursorの画面上で確認しながら直すほうが手数が少なく済みます。
連携の狙いは、どちらかで統一することではなく、この得意分野の違いを同じ開発面の上で往復できるようにすることです。

3つの連携パターンを混同しないための整理

CursorとClaude Codeの「連携」は、実際には3つの別パターンが混ざって語られがちです。
ここが曖昧なままだと、手順を追っているのに話が急に噛み合わなくなります。

1. IDE統合

本稿の基本手順です。
Cursorで開いているリポジトリに対してClaude Code側で/ideを実行し、Cursorが候補に現れることを確認して接続します。
承認ダイアログを通すと、Claude Codeの提案や編集がIDE側に反映されます。
最短で体験したいなら、まずここだけを見れば十分です。

1. MCPでの拡張接続

これは発展形です。
CursorからClaude CodeをMCPサーバーとして呼び出す構成で、単なるIDE接続よりも「外部能力をプロトコル経由でつなぐ」意味合いが強くなります。
設定の理解が一段増えるので、最初の成功体験を作る段階では分けて考えたほうが迷いません。

1. Cursor内ターミナルでClaude Codeをそのまま使う

これも便利ですが、IDE統合とは別物です。
CursorのターミナルでClaude Codeを起動して使うだけなら、見た目は同じ画面内でも、/ideでIDEと接続した状態とは役割が違います。
単に同じウィンドウ内でCLIを動かしているだけ、という理解が正確です。

この3つを分けて考えると、最短ルートがぶれません。
今やるべきことは、作業中リポジトリをCursorで開き、そのディレクトリでClaude Codeを起動し、/ideを打ってCursorが候補として見えるところまで進めることです。
ここで候補が出れば、「統合のための検出」は成功しています。
続いて表示されるセキュリティ確認画面は、ファイル編集やコマンド実行の権限を扱うための段階で、接続後に何が許可されるのかを明示する役割があります。

なお、IDEとCLIの境界そのものは少しずつ薄くなっています。
CursorではBackground Agentのような機能追加が進み、CLIも提供されるようになってきました。
ただ、導入手順を追う段階では、いま目の前で行っているのがIDE統合なのか、MCP接続なのか、単なるターミナル利用なのかを切り分けたほうが詰まりどころを特定しやすくなります。

MCPの1行説明と使い所

MCPは、AIと外部ツールやデータをつなぐための共通規格です。
『M通り、異なるアプリやサービスのあいだで「どう接続し、どう能力を呼ぶか」をそろえるための土台と考えるとつかみやすくなります。
Anthropicが2024年11月に公開したオープンプロトコルとして広がっており、本稿では後半でCursorからClaude CodeをMCPサーバーとして呼ぶ構成を扱います。

ここでのポイントは、MCPが最初に触るべき接続方法ではなく、連携の守備範囲を広げる仕組みだということです。
IDE統合は「Cursorで見ているコード編集面にClaude Codeをつなぐ」話ですが、MCPは「Cursorから外部能力としてClaude Codeを呼ぶ」話です。
似て見えても、目的が違います。
前者はまず編集反映まで通すための経路、後者はあとから拡張性を載せるための経路です。

そのため、導入の順番としてはIDE統合を先に済ませるほうが筋が通ります。
Claude Codeをローカルに入れ、作業中のリポジトリをCursorで開き、そのリポジトリ上でClaude Codeを起動し、/ideを実行してCursorが選択肢に現れることを確認する。
ここで承認ダイアログを通して編集が返ってくる状態になっていれば、最低限の連携は成立です。
MCPはその先で、「IDEから別の実行経路として呼びたい」「外部ツール接続の構成をそろえたい」という場面で効いてきます。

Model Context Protocol（MCP）とは？生成 AI の可能性を広げる新しい標準

zenn.dev

前提条件と準備するもの

アカウント・プランと料金の考え方

このセクションで先に揃えておきたいのは、Cursorがすでに導入・サインイン済みであることと、Claude Codeを使えるアカウント条件が満たされていることです。
Cursor側はCursor Quickstartの流れまで終わっていれば十分で、この記事の後半ではその上にClaude CodeのIDE接続を重ねていきます。

このセクションで先に揃えておきたいのは、Cursorがすでに導入・サインイン済みであることと、Claude Codeを使えるアカウント条件が満たされていることです。
Cursor側はCursor Quickstartの流れまで終わっていれば十分で、この記事の後半ではその上にClaude CodeのIDE接続を重ねていきます。

外部比較記事（参照元: 複数の比較記事、確認日: 2026-03-18）を参考にすると、個人向けの開始価格が両者とも「約 $20/月」として並べられる例が見られます。
チーム向けプランの比較では Cursor Teams が約 $40/ユーザー/月、Claude Code の上位席が約 $125/ユーザー/月とする記事もありますが、座席種別・地域・通貨・確認日時により金額は変動します。

Claude Codeの導入前提として、Node.jsは18以上が必要です。
加えて、コミット作成や差分確認、PRまわりまで任せる運用を考えるなら、Gitは2.23以上が入っていると流れが途切れません。
CLI前提の扱いになっているので、ここはエディタの準備とは別に、ターミナル側の足場を整える感覚で見るのが合っています。

確認は難しくありません。ターミナルで次のコマンドを順番に打つと、前提が揃っているかを短時間で切り分けられます。

node -v
git --version
cursor --version
claude --version

node -v で18未満なら、まずNode.jsの更新が先です。
git --version が通らない場合は、Git連携を使う段階で止まりやすくなります。
cursor --version は、CursorコマンドがPATHに通っているかを見るための確認です。
GUIではCursorを起動できても、ターミナルから cursor が見つからない状態だと、CLI連携や一部の接続確認で話が噛み合わなくなります。
claude --version が返れば、Claude Codeの実行ファイル自体はシェルから認識されています。

この4つを先に打っておくと、後のトラブルが「認証」「IDE統合」「OS固有の権限」のどこにあるか分けやすくなります。
実際にやってみると、接続できない原因が /ide そのものではなく、単に cursor や claude がPATHに載っていないだけ、ということが珍しくありません。
見た目は同じ「起動しない」でも、ここでの失敗は1行のエラー表示で拾えます。

Gitについては必須条件ではない場面もありますが、Claude Codeはリポジトリ全体を見ながら編集やコマンド実行をまたいで進める前提なので、Gitが入っていると作業のまとまりが一段よくなります。
あとからGitまわりだけ足すより、この段階でバージョン確認まで済ませておいたほうが流れが切れません。

Quickstart ｜ Cursor Docs

Go from install to your first useful change in Cursor. Sign in, ask Cursor to explain your codebase, make a small edit,

cursor.com

OS別注意点

OSごとの差は、インストールの可否よりも接続時の権限・パス・ネットワークの挙動に出ます。
CursorとClaude Codeはどちらも一般的な開発環境で動かせますが、最初に引っかかる場所はOSごとに少し違います。

Windowsでは、パスの表記とWSLの扱いが最初の山です。
特にCursorをWindows側に入れて、claude はWSL側で動かす跨ぎ構成にすると、/ide の接続で止まりやすくなります。
筆者もこの組み合わせで候補検出が噛み合わず、原因の切り分けに時間を使いましたが、CursorとClaude Codeを同じ側に揃えると話が早く進みました。
Windowsで完結させるか、WSL側に寄せるかを先に決めるだけで、IDE統合の詰まり方が変わります。
加えて、Windows Defender Firewall がローカル接続の検出に影響する場面もあり、GUIでの初期切り分けなら数分で終わる一方、WSLのネットワーク設定まで絡むと手順が増えます。

macOSでは、Gatekeeperによる初回起動ブロックが出ることがあります。
Appleの仕組み上、未署名または公証まわりで警告が出たアプリは、そのままでは起動できません。
こういうときはシステム設定のセキュリティ画面から個別に許可する流れになります。
実際の操作は長くても1分前後で終わることが多く、初回だけひと手間入るイメージです。
Finderで開けるのにCLI連携で止まる、というより、そもそもの起動許可で足止めされるのがmacOSらしい詰まり方です。

Linuxでは、ファイル権限とセキュリティ機構の影響を見ておくと切り分けが早くなります。
標準的な権限不足なら実行ビットや所有者の確認で済みますが、SELinuxやAppArmorが有効な環境では、ローカルソケットやファイルアクセスが制限されて接続確認に影響することがあります。
こういう場面は、アプリの不具合というよりOS側の保護機構が動いている状態です。
特にRed Hat系ではSELinux、Ubuntu系ではAppArmorが前提に入っていることが多いので、通常のパス確認だけで説明できないときに候補に入ります。

この段階で押さえておきたいのは、WindowsはWSLの境界、macOSは起動許可、Linuxは権限とポリシーという分け方です。
接続で止まったときにOSごとの典型パターンを先に知っていると、同じ「繋がらない」でも見る場所を間違えません。

Claude CodeをCursorで使う基本連携手順

インストールと初期化

最短でつなぐなら、先にClaude Codeをローカルへ入れて、ターミナルから起動できる状態まで持っていきます。
導入手順は『Claude Code の概要』に沿って進めるのが確実で、インストール後はその場で claude --version を返せるところまで確認しておくと、その後の切り分けが止まりません。
前のセクションで触れた通り、ここでコマンドが見えない状態だと、IDE統合の問題なのか、単にCLIが入っていないのかが混ざります。

Node.js はClaude Codeの前提として18以上が必要です。
加えて、Git も入っているとリポジトリ操作まで一連で進めやすくなります。
すでに node -v と git --version を確認済みなら、この段階では claude --version が通ることを見れば十分です。
インストール直後にバージョン表示まで確認しておくと、「入れたつもり」で終わらず、次の /ide まで一直線で進めます。

そのうえで、作業中のリポジトリをCursorで開きます。
新規フォルダではなく、実際に手を入れるリポジトリをOpen FolderまたはOpen Workspaceで開いている状態にしておくのが判断材料になります。
ここでClaude Codeを起動するシェルと、Cursorで開いているプロジェクトが同じ場所を指していないと、接続できても「どのファイルを編集しているのか」が噛み合いません。
実際には、同じユーザープロファイルでCursorを開いておくと、候補検出から承認までの流れが素直に進みます。

Claude Code の概要 - Claude Code Docs

Claude Code は agentic coding ツールで、コードベースを読み取り、ファイルを編集し、コマンドを実行し、開発ツールと統合します。ターミナル、IDE、デスクトップアプリ、ブラウザで利用できます。

code.claude.com

/ideでCursorを選択

リポジトリをCursorで開いたら、そのリポジトリ直下のターミナルで claude を起動し、対話画面で /ide を実行します。
ここでやることは単純で、IDE候補の一覧にCursorが出てくるかを見るだけです。
表示された候補からCursorを選べれば、基本連携の山は越えています。

初回は /ide を打った直後に即座に候補が出ないことがあります。
少し待つと一覧が現れることがあり、筆者の手元でも最初は一呼吸置いてからCursorが見えました。
逆に、待っても候補が出ないときはこの場で深追いするより、次の章で扱うチェックポイントに切り替えたほうが早いです。
ここで確認したいのは、IDE候補としてCursorが認識されているかどうかであって、原因調査を始めることではありません。

接続の途中でセキュリティ確認ダイアログが出ることもあります。
初回はIDEとの接続許可を求められる流れになりやすく、画面上ではAllowとDeclineの2択として出ることがあります。
内容を読んだうえで承認すると接続が進みます。
もし誤ってDeclineを押しても、そのまま詰みにはならず、/ide をもう一度実行すると再表示されたので、そこでやり直せました。
最初の許可確認は「接続できるかどうか」の手前にある関門として見ておくと混乱しません。

変更の反映をクイックテスト

接続が通ったら、動作確認は小さな変更で済ませるのが効率的です。
たとえば既存の関数名をひとつだけリネームする、コメント文を1行整える、使っていない変数名をより明確なものに変える、といった差分の小さい指示をClaude Codeに投げます。
ここで狙うのは機能追加ではなく、Cursor側で差分プレビューやファイル変更がその場で見えることの確認です。

この段階で編集結果がCursorに反映されれば、CLIからIDEへの橋渡しは成立しています。
反映の見え方としては、開いているファイルに変更が入る、差分表示が出る、保存前の編集状態がCursor上で追える、といった形になります。
大きな修正を最初に投げると、接続テストなのか実装作業なのかが混ざるので、まずは1ファイル・1変更で確認したほうが状態を読み違えません。

筆者は最初のテストで、命名だけを変える軽い修正を流して、変更がCursorに戻ってくることを見てから本作業に入りました。
この順番にしておくと、「接続済みだが編集権限で止まっている」のか、「そもそもIDE連携が未成立なのか」をその場で分けられます。
連携に成功している状態は、派手な機能よりも、まず小さな差分が素直に往復することで判断できます。

連携できないときの対処法

認識されない時のチェックリスト

/ide を実行してもCursorが候補に出ないときは、IDE側の不具合と決めつけるより、まず前提が揃っているかを切り分けるほうが早く進みます。
詰まりやすいのは、claude コマンド自体は動いていても、IDE検出に必要な条件が1つ欠けているケースです。
ここではまず前提（Node.js、PATH、同一ユーザー/同一マシン、ファイアウォール）を順に確認してください。

もうひとつ見落としやすいのがファイアウォールです。
Claude Codeの公式トラブルシューティングでも、WSL2 や Windows 側のネットワーク設定が IDE 検出を妨げるケースに触れています。
Microsoft Defender Firewallは通常のローカル利用では意識しにくいのですが、受信・送信ルールや WSL2 の NAT 構成が絡むと /ide 接続で止まることがあります。
GUI での初期切り分けなら数分で終わるので、Windows セキュリティの「ファイアウォールとネットワーク保護」から許可状態を確認するだけでも手掛かりになります。

VSIXからの手動インストール手順

チェックポイントを見てもCursorが候補に出ないなら、claude-code.vsix を使った手動導入が回避策になります。
これはClaude Codeの拡張をローカルの VSIX ファイルとして入れ直す方法で、認識不良の場面で効くことがあります。

流れはシンプルです。
まずローカルで claude-code.vsix を入手します。
入手元が複数ある状態だと、どの版を入れたのか後から追えなくなるので、ファイルの取得元と、その時点のClaude Codeのバージョンは一緒に控えておくと混乱しません。
VSIX は中身と本体の整合が崩れると切り分けに時間を取られるので、ここは記録を残しておくと後が楽です。

そのうえでCursorを開き、左サイドバーのExtensionsに入ります。
続いて右上の⋯メニューからInstall from VSIX...を選び、保存しておいた claude-code.vsix を指定します。
通常の拡張検索で入れるのではなく、ローカルファイルを明示して追加する形です。
インストールが終わったら、そのまま使い始めずにCursorを再起動します。
拡張の読み込みが途中状態のままだと、入ったように見えても /ide 側の候補に反映されません。

筆者の環境では、この VSIX 導入のあとに即座に /ide の候補へCursorが出るようになったことがありました。
通常の検出で足踏みしていたのに、手動導入後は動きが変わったので、拡張の認識経路がうまく揃っていなかったのだと思います。
このとき実感したのは、VSIX そのものよりも どのバージョンをどこから入れたか が後の切り分けで効くという点です。
ファイル名だけでは追えないので、手元メモに一行残しておくだけでも十分役に立ちます。

再起動・再実行とログの確認

VSIX を入れたあと、あるいは設定を見直したあとにやることは、再起動してから /ide を再実行することです。
順番としては、Cursorを閉じて起動し直し、対象リポジトリを開き、同じ場所のターミナルで claude を起動して /ide を打ちます。
ここでCursorが候補に現れれば、問題は拡張の読み込みか初期認識で止まっていたと判断できます。

それでも出ない場合は、感覚ではなくログで追う段階に入ります。
Claude Code側の実行ログ、ターミナルに出るエラーメッセージ、Cursorの拡張関連ログや開発者ツール上の出力をまとめて採っておくと、何が見えていて何が見えていないのかを整理できます。
ファイアウォールや権限制御が疑わしい場合は、OS 側のログも合わせると筋道が立ちます。
Windows ならMicrosoft Defender Firewallの監視やイベントログを確認するとよいでしょう。
Linux ならSELinuxの /var/log/audit/audit.log や ausearch、Ubuntu 系ならAppArmorの aa-status や syslog・dmesg に痕跡が残ることがあります。
macOS で未許可の実行物が絡むなら、Gatekeeperの判断を spctl -a -vvv で見て、公証や許可状態を切り分ける方法もあります。

ログを集めたうえで報告する場合は、公式ドキュメントのトラブルシューティングと、公式・コミュニティの Issue テンプレートに沿って、OS、claude --version、node -v、Cursorのバージョン、再現手順、VSIX 手動導入の有無を書き分けると通りがよくなります。
単に「出ない」だけでは再現条件が不足しますが、/ide 実行後に何が表示され、どこで止まり、再起動後も変わらなかったかまで並べると、受け手が状況を追えます。

連携がその場で復旧しないときでも、作業自体は止めなくて構いません。
Cursorの統合ターミナルでClaude Codeを直接使い、編集対象のファイルはCursor側で確認する運用なら、その日の作業は進められます。
これはあくまで CLI を同じ画面内で使う一時回避で、IDE統合の候補表示や直接接続とは別物です。
そこを分けておくと、「使えてはいるのに /ide だけ通らない」という状態を落ち着いて扱えます。

CursorからClaude CodeをMCPサーバーとして使う発展設定

MCPの要点

MCPは、AI と外部ツールやデータソースをつなぐための共通規格です。
ここで押さえたいのは、前のセクションで扱ったClaude Codeの IDE 統合とは役割が違うという点です。
IDE 統合はClaude CodeがCursorを直接見つけて接続し、/ide からエディタ操作に入る流れでした。
一方で MCP は、Cursor側からClaude Codeの機能に接続する構成です。
見た目は近くても、主導権がどちらにあるかが異なります。

最短で通すなら、まずClaude Codeをインストールしておき、作業中のリポジトリをCursorで開きます。
その状態で統合ターミナルか同じ作業ディレクトリのターミナルから claude を起動し、/ide を実行します。
ここで候補にCursorが出ることを確認できれば、IDE 側との接続経路は生きています。
MCP 設定に入る前にこの確認を済ませておくと、問題がClaude Code本体なのか、Cursorの MCP 設定なのかを分けて見られます。
途中でセキュリティ確認画面が出ることもあり、その承認を通して初回接続が成立します。

Claude Code の概要やClaude Code の仕組みを見ると、ツール実行と外部接続が前提に置かれていることがわかります。
Claude Codeはターミナル中心の操作が本筋ですが、MCP サーバーとして扱うとCursorのチャットから必要な機能だけを呼び出せるようになります。
実際、この経路にすると「この操作だけClaude Codeへ渡したい」という場面で手数が減ります。
その代わり、どの機能をどの権限で公開しているのかを設定で追う必要があり、導入後の見通しは IDE 統合単体より一段複雑になります。
私の環境でも、MCP 経由にした途端に便利さは増えたものの、mcp.json の差分レビューを飛ばせなくなりました。
チーム導入では PR のレビュー対象に mcp.json を含める運用にして、誰がどのサーバーを追加したのかを必ず残すようにしました。

~/.cursor/mcp.jsonの設定例

Cursorでは設定画面から MCP を追加する方法もありますが、構成を明示して残すなら ~/.cursor/mcp.json を編集するのが早いです。
Cursor Quickstartにある基本操作どおりCursorで対象リポジトリを開いたうえで、claude コマンドが通る状態を先に作っておくと、その後の登録で詰まりません。
Claude Codeの前提として Node.js は 18 以上が必要なので、そこが満たされていないとサーバー起動前で止まります。

設定ファイルの形はシンプルで、stdio 型の MCP サーバーとしてClaude Codeを登録します。たとえば次のような形です。

{
 "mcpServers": {
 "claude-code": {
 "transport": "stdio",
 "command": "claude",
 "args": []
 }

この登録を入れたあと、Cursorを再起動して MCP サーバー一覧にclaude-codeが見える状態にします。
command にフルパスを書きたい場合は、which claude で確認した実体パスを入れておくと PATH 依存の取りこぼしを避けられます。
Node.js を複数系統で切り替えている環境では、claude が想定外の場所を向いていることがあるので、ここを明示すると切り分けが速くなります。

接続確認は二段階で見ると整理しやすくなります。
ひとつはCursor側で MCP サーバーが起動しているか。
もうひとつは、同じリポジトリで claude を立ち上げて /ide を実行したときにCursorが候補へ出るかです。
後者が通るなら IDE 接続の土台はできています。
そこからCursorのチャットや MCP 呼び出しでClaude Codeの機能が見えれば、MCP 側の接続も成立したと判断できます。
初回はここでもセキュリティ確認画面が出ることがあり、許可を与えるまで利用可能な状態になりません。

少し発展させるなら、サーバー名を用途別に分ける方法もあります。
たとえば実験用と本番用で名前を分けると、チームで画面共有しながら設定を読むときに迷いません。
MCP は共通規格なので追加先が増えやすく、名前が曖昧だと「どのサーバーがどの権限で何を触るのか」が設定ファイルだけで追えなくなります。
私自身、最初は一つの名前にまとめていましたが、後からレビューすると意図が読み取りにくく、結局サーバー名を役割ベースで切り分けたほうが運用が安定しました。

権限・ログ・審査の設計

MCP は便利ですが、第三者サーバーをつなぐ構成では権限設計が中心課題になります。
Claude Codeを MCP サーバーとして使う場合でも、「どのディレクトリに触れるのか」「認証情報を読む可能性があるのか」「ファイル編集やコマンド実行をどこまで許可するのか」を先に切り出しておくと、あとで設定を読み返したときに迷いません。
権限を広く取るほど初回の設定は楽になりますが、レビュー対象が増え、承認の意味が薄れます。
必要な操作だけ通す構成にしておくと、セキュリティ確認画面が出たときも判断材料が明確になります。

ログ設計も同じくらい効きます。
MCP サーバーが起動しないときは、Cursorの MCP 関連ログと claude の標準出力・標準エラーを対で見ると、設定ミスか起動失敗かを切り分けられます。
接続そのものではなく OS 側の制御が止めている場合は、前のセクションで触れたログ確認がそのまま役立ちます。
Windows ならMicrosoft Defender Firewall、Linux ならSELinuxやAppArmor、macOS ならGatekeeperの痕跡を追う流れです。
特にローカルソケットやローカルプロセス実行に制約が入ると、MCP 側では「サーバーが見えない」ように見えても、原因は OS の拒否にあります。

チームで回すなら、審査の単位を設定ファイルまで広げると事故が減ります。
コードだけを見ていると、MCP サーバーの追加や command の差し替えは抜けやすいからです。
私の現場では、MCP 経由でClaude Codeの機能をピンポイントに呼べるようになって作業の流れは良くなりましたが、その反面、設定レビューの手間は確実に増えました。
そのため PR では ~/.cursor/mcp.json の変更を必ずレビュー対象に含め、サーバー名、起動コマンド、引数、意図した権限範囲をセットで確認する運用に寄せました。
MCP は導入した瞬間から便利になるものの、運用設計まで含めて初めて安定します。

実務での使い分け: CursorとClaude Codeの役割分担

0→1はClaude Code、1→100はCursor

実務では、Claude CodeとCursorを競合ツールとして見るより、工程ごとに担当を分けたほうが早く進みます。
基本パターンははっきりしていて、設計の骨組みづくり、要件整理、変更範囲の見立て、テスト観点の洗い出しはClaude Codeに寄せ、実装を詰める段階、UI 調整、差分確認、微修正、逐次レビューはCursorで回す構成が噛み合います。
Claude Codeはターミナル起点で複数ファイルをまたぐ作業や大枠の提案に強く、Cursorはエディタ上で今見ているコードを少しずつ直しながら確かめる流れに乗せやすい、という役割差があるからです。
Claude Code の概要とCursor Quickstartを見比べると、前者が CLI 中心、後者が IDE 中心で設計されていることがそのまま表れています。
この役割分担を一言でまとめるなら、骨組みを作る段階はClaude Code、仕上げる段階はCursorです。
新機能の土台を作る、ディレクトリをまたいで構成を変える、既存コードを読みながら実験的に別案を試す、といった広い変更はClaude Codeに渡したほうが流れが止まりません。
反対に、生成されたコードを読んで命名を詰める、1 ファイルずつ整える、画面を見ながら余白や文言を調整する、差分を見てレビューコメントに応じる、といった仕上げ工程ではCursorのほうが自然です。

私の手元では、朝にClaude Codeで「今日どの設計変更を触るか」「どんなテスト観点が抜けそうか」を先に洗い出しておき、その後はCursorで小さく実装して都度検証する流れに落ち着きました。
個人開発では頭の切り替えが減りますし、チームでも「午前中に設計を揃え、午後は差分を細かく進める」というテンポが作れます。
設計会話と実装会話を同じ場所で混ぜないぶん、判断の粒度が揃います。

連携の入り口もこの分担に合わせると迷いません。
まずClaude Codeをローカルに入れ、作業中のリポジトリをCursorで開きます。
その同じリポジトリでターミナルからClaude Codeを起動し、/ide を実行します。
ここで接続先の候補にCursorが出てくれば、IDE 統合の土台は整っています。
初回はセキュリティ確認画面が表示されることがあり、許可を与えると編集や接続が反映されます。
この確認が通ると、「大枠はClaude Code、目の前の編集はCursor」という分担をそのまま作業フローに持ち込めます。

シーン別ハンドオーバー例

未知のコードベースに入る初日は、この分担がもっとも効きます。
いきなりCursorでファイルを追い始めると、見えている範囲だけを直して終わりがちです。
そこで先にClaude Codeへリポジトリ全体を読ませ、アーキテクチャの要点、依存関係、変更時に壊れそうな箇所、最低限見るべきテストを整理します。
そのあとCursorで実ファイルを開き、提案内容を一つずつ検証しながら編集すると、読み込みと実装が分断されません。
初日に欲しいのは「全部理解した感覚」ではなく、「どこから触ると事故が少ないか」という地図で、その地図づくりはClaude Codeが向いています。

バグ再現の調査では、再現条件の洗い出しをClaude Code、局所修正をCursorに分けると手数が減ります。
たとえばフォーム送信の不具合なら、Claude Codeに関連ログ、入力バリデーション、状態管理、API 呼び出し、失敗時の分岐を横断して整理させます。
原因候補が絞れたら、Cursorで該当箇所を開き、ブレークポイントやログを足しながら最小差分で修正します。
調査の段階では広く見渡す力が要りますが、修正段階では「この if 文をどう直すか」「この型をどこまで変えるか」といった細部の判断が中心になるためです。
既存関数のリファクタリングでも流れは同じです。
Claude Codeに「責務が混ざっている箇所」「分割候補」「副作用のある処理」「テストを先に足すべきポイント」を挙げてもらうと、どこまで切ってよいかの見取り図ができます。
そこからCursorで関数抽出、名前変更、型の整備、不要コードの除去を進めると、差分レビューも追いやすくなります。
リファクタリングは設計と編集が交互に出てくる作業ですが、設計の判断を先にまとめておくと、エディタ上で迷走しません。

PR 前の最終仕上げでは、役割を逆転させないほうが安定します。
この段階でClaude Codeに大きな再設計を求めると、差分が広がってレビューの負荷が跳ね上がります。
ここではCursorで差分を読み、コメントを反映し、UI の崩れや文言の違和感を詰めるほうが収まりがよいです。
必要ならClaude Codeに「この差分でテスト観点が漏れていないか」「レビュー観点で危ない箇所はどこか」を壁打ちし、その返答をもとにCursorで最後の修正だけを入れる形が合います。
つまり、設計相談の主導権はClaude Codeに残しつつ、最終編集の主導権はCursorに置くわけです。

CLAUDE.mdとCursor Rulesの使い分け（筆者の運用提案）

テンプレートや具体例をそのまま採用する場合は「筆者提案」である旨をリポジトリ内に明示し、必要に応じて社内ガイドラインや公式ドキュメントと照合してください。
そのうえで、連携フロー自体は単純に保つのが得策です。
Claude Codeをインストールし、作業対象のリポジトリをCursorで開き、同じ場所でClaude Codeを起動して /ide を実行し、Cursorが候補に出ることを確認する。
最初のセキュリティ確認画面を通したあとに、CLAUDE.md と Rules の役割分担まで揃えると、設計から仕上げまでの受け渡しが滑らかになります。
IDE 統合そのものは接続できれば終わりですが、実務で効いてくるのは「どの場面でどちらに任せるか」が決まっている状態です。

安全に運用するための注意点

ここで触れる CLAUDE.md や Cursor Rules の運用例は、筆者が実務で有効だった「運用提案／ベストプラクティス」として紹介しています。
公式仕様や必須ルールではないため、チームでの採用時は検証・調整を行ってください。

Claude CodeやCursorを既存リポジトリで動かすときに最初の境界線になるのは、アプリ本体よりもリポジトリ内の設定です。
未知のリポジトリでは、.claude/、.vscode/、.cursor/ を先に見るだけで、事故の芽を早い段階で拾えます。
ここにタスク実行時のルール、拡張機能の推奨設定、フック、外部コマンド呼び出しが入っていると、AI エージェントが「普通に作業しているつもり」で想定外のスクリプトや権限を踏むことがあるからです。
MCP を使い始めると便利さの中心は外部連携に移りますが、同時に信頼境界も広がります。
第三者の MCP サーバーを足す場合は、そのサーバーが読めるデータ、実行できる操作、保持する資格情報を最小限に絞るのが基本です。
MCP サーバーはただのプラグインではなく、リポジトリ、ローカルファイル、外部 API、社内ドキュメントに触れる入口になり得るためです。

ここで避けたいのは、認証情報をプロジェクト設定へ直書きする運用です。
API キーや個人トークンを .mcp.json、settings.json、共有されるルールファイルに埋め込むと、その瞬間に漏えい経路が一気に増えます。
資格情報は .env や OS のキーチェーンに隔離し、リポジトリには参照名だけを残す形のほうが安全です。
設定ファイルの diff は多くの人が目にしますが、OS 側の保管領域やローカル環境変数までそのまま露出するわけではありません。
漏れたときの影響範囲がまるで違います。

権限の考え方も同じで、最初から「全部読める」「全部書ける」にしないほうが安定します。
たとえば、設計相談だけに使う MCP サーバーに対して、リポジトリ書き込み権限や本番系の API 資格情報まで渡す理由はありません。
接続先ごとに役割を限定し、ログ閲覧用、検索用、編集補助用を分けておくと、ひとつの誤設定がそのまま全面事故につながる流れを断てます。
MCP の導入数が増えるチームほど、「便利だからまとめる」より「役割で分ける」ほうが後から効きます。

承認・ログ・更新運用の基本

Claude Codeには副作用のある操作に承認を求めるフローがあり、『Claude Code の仕組み』でもツール実行の前提が説明されています。
ただし、承認ダイアログがあることと、運用上の安全が自動で担保されることは同じではありません。
許可ルールがプロジェクトに残る、IDE 側の表示が分かりにくい、設定変更で実行範囲が広がる、といった余地は残ります。
ファイル編集、Git 操作、Bash 実行のように戻しにくい操作は、承認を「一度許したから継続」ではなく、危険コマンドごとに都度確認する形のほうが実務では破綻しません。
合わせて、何を実行したかを後から追える状態にしておく必要があります。
AI エージェントまわりのトラブルは、失敗そのものより「なぜそう動いたのかが追えない」ことのほうが後を引きます。
承認対象のコマンド、設定変更の差分、MCP サーバー追加や更新の履歴をログとして残しておくと、問題発生時に人間が復元できます。
レビューの単位をコードだけに限定せず、設定変更、権限変更、接続先追加も同じレーンに乗せる運用のほうが、実際のリスク構造に合っています。

近年は AI エージェント周辺でも、設定ファイル、フック、自動起動、外部サーバー連携を起点にした脆弱性や運用事故が繰り返し話題になっています。
だから更新運用も「本体だけ上げれば終わり」では足りません。
Claude Code の概要で把握できる更新情報に加えて、依存する MCP サーバー、拡張、関連スクリプトまで含めて見直す必要があります。
設定や依存のアップデート方針、レビュー体制、差分確認をコードレビュー同等に扱うチームは、導入初期の勢いに流されにくく、事故が起きても止血が早いです。

Claude Code の仕組み - Claude Code Docs

agentic ループ、組み込みツール、Claude Code がプロジェクトとどのように相互作用するかを理解します。

code.claude.com

よくある質問

単体運用と併用の境界

よく聞かれるのが、「Cursor単体で十分ではないか」「Claude Codeだけでも回るのではないか」という線引きです。
実務感でいうと、IDE内で見えている範囲を整えながら進める仕事はCursor単体で成立しやすく、リポジトリ全体を横断して骨組みから組み立てる仕事はClaude Codeを足したほうが流れがよくなります。

Cursor単体で向いているのは、既存ファイルの微修正、差分確認、補完を受けながらの実装、画面を見てその場で UI を詰める作業です。
編集結果をすぐ目で追えますし、どこを書き換えたかも IDE の文脈で把握できます。
フロントエンドの文言調整やコンポーネントの見た目の微修正、既存テストを壊さない範囲での小さな改修なら、ここで完結する場面は少なくありません。

一方で、Claude Codeが光るのは、要件から複数ファイルにまたがる実装方針を組み立てたり、テストや Git 操作まで含めて一連で進めたりするときです。
ターミナル中心のため、実装だけでなく、探索、編集、実行、検証までをひとつの流れで扱えます。
0 から機能の骨組みを起こす、設定ファイルやバックエンドをまたぐ変更をまとめて進める、といった仕事ではこちらのほうが自然です。

ではClaude Codeだけでよいかというと、そこも半分正解で半分不足があります。
CLI だけでも進められますが、差分を目で追いながらの微調整や、UI を触っては直す反復はCursorのほうが速く回る場面が目立ちます。
実際には、Claude Codeで大枠を作り、Cursorで差分確認と仕上げをする、という分担がいちばん破綻しにくい印象です。
片方に寄せ切るより、役割で切るほうが迷いません。

MCPはいつ導入すべきか

MCP も必須項目だと受け取られがちですが、導入順としてはそこまで前に置かなくて構いません。
最初の接続に必要なのはClaude Codeの IDE 統合で、まず試すべきは /ide です。
MCP はその先で外部ツールや追加能力をつなぐ拡張施策として考えると整理しやすくなります。

この順番を崩さないほうがよい理由は単純で、MCP を足すと設定の読み解き対象が増え、権限管理や監査のコストも一段上がるからです。
どのサーバーが何を読めるか、どのプロセスが起動するか、どこに接続するかまで追う必要が出てきます。
前述の通り、ここはコードと同じ粒度で見るべき領域なので、連携の入口としては少し重いです。

Windows と WSL で詰まりやすいのも、たいていは MCP 以前の層です。
私自身、Windows 環境で /ide の候補が出ずに止まったことがあります。
そのときはCursorだけ Windows 側、Claude Codeだけ WSL 側という分かれ方になっていて、接続の前提が揃っていませんでした。
そこで両方を WSL 側に寄せ、拡張を VSIX で入れ直して再起動したところ、ようやく認識が通りました。
こういう詰まり方は珍しくなく、まず見るべきは IDE とエージェントが同じ側で動いているかです。
Windows 側でそろえるのか、WSL 側でそろえるのかを先に決めると、PATH、権限、接続先の整理が一気に進みます。

それでもつながらない場合は、Node.js が 18 以上になっているか、Git が入っているかを確かめたうえで、Windows ファイアウォールのルールも疑ったほうが早いです。
Claude Code WSL2 とファイアウォールが IDE 検出を妨げるケースに触れていますし、Microsoftのサポート文書にもアプリ単位で許可ルールを管理する手順があります。
GUI の確認だけなら数分で済むので、MCP の設定ファイルを掘るより前に切り分けたほうが筋が通ります。
Claude Code DocsとMicrosoft Support。

Troubleshooting - Claude Code Docs

Discover solutions to common issues with Claude Code installation and usage.

code.claude.com

料金・制限・確認日の付記

料金感は判断材料になりますが、ここで示す数値は外部比較記事に基づく参考値です（参照元: 複数の比較記事、確認日: 2026-03-18）。
組織向けプランや座席種別で価格や利用制限は変わり得ます。

まとめと次にやること

この記事で到達すべき地点

この記事の到達点は、Claude Codeをローカルに導入し、Cursorで開いている既存リポジトリから /ide を実行して、接続確認まで通すことです。
ここまでできれば、IDE と CLI をまたぐ連携の土台はできています。
以降は機能を足す段階であって、まず必要なのは「つながること」を再現できる状態です。

チェックリスト

接続が通らなかったときは、拡張の再導入と再起動、再実行までをひとまとまりで試すのが近道です。
Cursor側の拡張が不安定なときは VSIX の手動導入まで戻すと、意外なほど素直に復旧することがあります。
そこでも詰まるなら、前述の通り OS 側のそろえ方を見直すほうが先です。
MCP は最初から盛り込まず、必要な役割が見えてから最小構成で足すほうが、権限の棚卸しも運用ルール作りも崩れません。

• Claude Codeをローカル導入し、Cursorから /ide で接続確認できた
• 失敗時に VSIX 手動導入、再起動、再実行まで試した
• MCP を入れる前に、必要な用途と許可範囲を言語化できている

Next Actions

次は小さな既存リポジトリで実際に使い分けを試す段階です。
筆者は接続確認の直後に「コードベースの説明」と「関数リファクタ」の二つだけを同じリポジトリで比べることで、CursorとClaude Codeの得意領域が明確になった経験があります。
ここが見えると、どちらに何を任せるかが自然に固まり、チームでも個人でも迷いが減ります。

追記: 本記事内の料金や利用制限に関する数値・記述は外部比較記事に基づく暫定情報です。
座席種別や時期で制限や価格が変わる可能性があるため、導入前には各サービスの公式 pricing/quota/terms ドキュメント（確認日と URL を明記）で最新情報を必ず確認してください。