VS CodeからCursorへ乗り換える前に確認すること:拡張機能・設定・チームの足並み

確認できた公式情報(2026年10月29日時点)

以下は同日に閲覧した公式ページの内容です。更新される可能性があります。

• 設定のインポート:Cursorの設定(Cmd/Ctrl + Shift + J)で「General > Account」を開き、「VS Code Import」からインポートします。拡張機能、テーマ、設定、キーバインドが転送対象です(Migrate from VS Code)。
• 手動での移行:VS Codeでプロファイルを書き出し、Cursorで読み込めます。コマンドパレットの「Preferences: Open Profiles (UI)」から操作します。保存先はローカルファイルかGitHub Gistです(VS Codeからの移行)。
• 拡張機能:Open VSXを使います。人気の拡張機能の多くはありますが、Microsoft Marketplaceの拡張機能がすべて載っているわけではありません。同じ名前でも発行者やコードが異なることがあります。Cursorが代替(Anysphere製)を出している拡張機能もあり、審査を通らない拡張機能はブロックされると説明されています(Extensions)。
• ルール:プロジェクトのルールは.cursor/rules内の.mdcファイルに置き、適用条件を設定してGitで管理します。プロジェクト直下のAGENTS.mdも使えます。チームルールはTeam/Enterpriseプランの機能です(Rules)。
• Privacy Mode:有効なときは、コードがCursorやモデル提供元の学習に使われないと説明されています。チームでは管理者が組織全体で強制できます。自分のAPIキーを使う場合は、ゼロデータ保持(ZDR)の対象外になる旨の記述があります(Privacy and data)。

移行前に確認する項目表

下の表は編集上の整理です。「確認方法」の列を、自分の環境で埋めてください。

• 拡張機能の有無、壊れやすい理由：レジストリがOpen VSXで、Microsoft Marketplaceと一致しない、確認方法：VS Codeの拡張機能一覧を書き出し、Cursorで1件ずつ検索する、合格の目安：必須の拡張機能がすべて入る。代替が必要なものは把握できている
• 同名の別物、壊れやすい理由：同じ発行者.名前でも発行者やコードが異なる場合がある、確認方法：発行者名とバージョンを両方で見比べる、合格の目安：発行者が同じか、違いを説明できる
• 言語サポート・フォーマッタ・リンタ、壊れやすい理由：日々の編集の質に直結する、確認方法：実際のファイルで保存時整形、補完、エラー表示を試す、合格の目安：VS Codeと同じ整形結果になる
• キーバインド・テーマ、壊れやすい理由：インポート対象だが、競合は人が見るしかない、確認方法：よく使う操作を10個ほど押してみる、合格の目安：迷わず操作できる
• デバッグ・タスク設定、壊れやすい理由：.vscode/launch.jsonやtasks.jsonに依存しがち、確認方法：既存のデバッグ構成を実行する、合格の目安：ブレークポイントで止まる。タスクが走る
• リモート開発・Dev Container、壊れやすい理由：拡張機能への依存が大きい、確認方法：普段の接続先に実際に入る、合格の目安：接続でき、必要な拡張機能が動く
• AIへの指示の置き場所、壊れやすい理由：個人設定だと共有されない、確認方法：.cursor/rulesかAGENTS.mdにまとめる、合格の目安：レビューでき、Gitで追える
• Privacy Mode、壊れやすい理由：個人の設定漏れで扱いが分かれる、確認方法：各自の設定画面、チームなら管理画面を確認する、合格の目安：方針どおりに全員がオンになっている

並行利用できるかの確認

公式ヘルプは、両アプリを別アプリとして同じプロジェクトで使えるとしています。ただし、今回確認した公式資料には、同時編集時の保存衝突や.vscode設定の読み込み挙動の説明はありません。並行利用できるという回答だけで、これらも同じ挙動になるとは判断できません。次の点は、破棄できる検証用のコピーで確認してください。

• 同じファイルを両方で開いたまま編集しても、保存の衝突が出ないか。
• .vscode/の設定を両方が読んだとき、同じ挙動になるか。
• Git操作を両方から行って、差分が意図せず増えないか。

確認が済むまでは、同じフォルダでの同時編集を避けます。普段の作業フォルダはVS Code用に残し、別フォルダに複製した検証用リポジトリをCursorで開きます。比較するときは同じコミットから始め、両方のアプリでデバッグ・タスク・整形を実行して結果を記録します。

半日でできる小さな検証手順

以下は未実行の手順案です。結果はあなたの環境で記録してください。

1. 準備(15分)

1. VS Codeの設定ファイル(settings.json)、キーバインド、拡張機能の一覧を控えます。プロファイルを書き出しておくと、元に戻す材料にもなります。
2. 検証用リポジトリを選びます。社外秘のコードが入っていない小さなもの、または公開できる別リポジトリが向いています。
3. 検証用ブランチを切ります。

2. インポートと拡張機能の突き合わせ(30分)

1. Cursorを初めて使う場合は「VS Code Import」を実行し、インポート後の設定とキーバインドを控えた内容と比較します。既にCursor側に設定がある場合、今回確認した移行ガイドには競合・上書き時の扱いが説明されていないため、そのまま一括インポートせず、既存の設定を控えてから、手動のプロファイル移行で新しいプロファイルを読み込み、切り替えて試します。
2. 控えた拡張機能一覧と、Cursor側の一覧を突き合わせ、次の3つに分けます。

入った / 入らない(代替あり) / 入らない(代替なし)

1. 「入らない(代替なし)」に、業務で必須のものが1つでもあれば、そこで一旦止めます。そのまま移行すると仕事が止まる可能性があります。

3. 日常作業の再現(60分)

次の5つを、VS Codeでの結果と並べて確認します。

1. ビルドまたはテストの実行
2. デバッグの開始
3. フォーマッタとリンタの動作
4. Git操作(差分、ステージ、コミット)
5. いつも使うターミナル操作

差が出たら、設定の差か拡張機能の差かを切り分けて表に書きます。

4. AIに任せる範囲を試す(60分)

AI機能を使う前に、Privacy Modeと社内の利用方針を確認します。検証ブランチで、小さな変更を1件だけ依頼します。依頼文は次のようにします(説明用の例です)。

このリポジトリの utils/date.ts に、ISO形式の文字列を
「YYYY年M月D日」に変換する関数を追加してください。
- 既存の関数の命名規則とテストの書き方に合わせる
- 追加するテストは2件まで。対応するテストファイルに書く
- utils/date.tsとそのテストファイル以外は変更しない
変更したファイルと、実行したテストコマンドを最後に一覧で出してください。

人が確認する点は、次のとおりです。

• 変更が指定ファイルの範囲に収まっているか。
• テストを自分で実行し、結果を見たか。AIの報告を鵜呑みにしません。
• 差分をレビューして、意図しない変更がないか。

5. ルールを1つだけ置く(30分)

AIへの共通指示を、プロジェクト直下のAGENTS.mdに短く書きます(説明用の例です)。.cursor/rulesを使う場合は、公式資料に従い、適用条件を設定した.mdcファイルを作ります。

# 開発ルール
- テストは変更箇所の近くに追加する
- 公開関数には型を明示する
- 依存パッケージは追加しない。必要なら提案だけ出す

置いたあと、検証用の変更だけを戻してルール追加前と同じコードの状態にし、新しいチャットで同じ依頼を出して、ルールに沿った変更になるかを見ます。プロジェクトルールはGitで管理する前提です。レビューを通してチームに共有してください。

チームで足並みを揃える

個人の乗り換えと違い、チームでは次の3点を先に決めておくと混乱が減ります。

• Privacy Mode:「学習に使われない」ことと「社外に出ない・秘密が守られる」ことは別の話です。Cursorはプロンプトとコードの文脈をモデル提供元に送る旨を説明しています。社内の情報の扱いは、自社の規程と契約で判断してください。自分のAPIキーを使う場合はZDRの対象外になる旨の記述もあるため、使い方も揃えます。
• 拡張機能の標準セット:必須の拡張機能と、代替の有無を一覧にして共有します。.vscode/extensions.jsonを使っているチームは、Cursorで同じ推奨が機能するかを確認してください。
• ルールの置き場所:個人設定ではなく、リポジトリのファイルに置きます。チームルールの機能はTeam/Enterpriseプランの記述なので、契約中のプランで使えるかを確認します。

移行後に確認する項目

1週間試したら、次の問いに答えます。

• 必須の拡張機能がすべて動いたか、はい/いいえ：
• VS Codeに戻る回数は減ったか、はい/いいえ：
• AIが出した変更をレビューする時間は許容範囲か、はい/いいえ：
• チーム全員のPrivacy Modeの状態を確認できたか、はい/いいえ：
• ルールをGitで共有できたか、はい/いいえ：

「いいえ」が拡張機能に集中するなら、並行利用を続けて、足りない部分だけVS Codeで補う選択もあります。乗り換えは全員で一斉に行う必要はありません。