Cursor拡張機能おすすめ10選｜重複なしで最小構成

Cursorは『VS Code』互換の資産を活かせる一方で、AIは最初から統合されているので、拡張機能をそのまま大量移行するとむしろ作業が鈍ります。
実際、私も移行直後に補完が二重に出て編集のリズムが崩れ、いったん最小構成まで戻して『Prettier』と『ESLint』を起点に組み直したところ、ようやく安定しました。
この記事は、これからCursorを使い始める人や、『VS Code』から乗り換えたものの拡張選びで止まっている人に向けて、最初に入れる3つ、用途別に足す7つ、そしてCursorでは不要になりやすい拡張を10個以内に絞って整理します。
導入はExtensionsパネルから行え、確認できます。
2026年以降は『VS Code』互換の拡張とCursor Marketplace公開で広がったプラグイン、さらにMCPの役割を分けて理解するのが迷わないコツです。
最初から全部入りを目指すより、重複を避けた“最小構成”で始め、必要になった機能だけを足すほうが、補完も整形も安定してCursorの標準AIを素直に活かせます。

Cursorで拡張機能を選ぶ前に知っておきたい前提

Cursor標準AIと外部AI拡張の役割分担

Cursorで拡張機能を選ぶときに先に押さえておきたいのは、標準で入っているAIと、あとから足す拡張の役割がそもそも違うという点です。
Cursorは『VS Code』ベースなので、従来の『VS Code』拡張をそのまま持ち込みやすい一方、AI補完・チャット・エージェント機能は最初から統合されています。
つまり、編集体験の中核は標準AIが担い、拡張機能はその周辺を補強するものとして考えたほうが整理しやすくなります。

この前提を外すと、たとえばGitHub CopilotやCodeiumのようなAI補完系を惰性で残したまま使い始めて、補完候補が二重に出る状態になりがちです。
私も移行直後にCopilotを残したままCursorのAI補完を有効にしていた時期があり、候補が重なって視線の往復が増え、編集のテンポが崩れました。
そこでCopilotをいったん無効化してCursor標準だけに寄せると、カーソル位置や直前の編集意図に追従する感触が揃い、提案の読み分けに使っていた意識をコードそのものに戻せました。
AIは多ければ得ではなく、主役を1つに決めたほうが精度の体感が上がりやすいというのが実務での結論です。

このあと紹介する10個も、基本はこの考え方で見ていきます。
正式名称でいえばPrettier – Code formatterや『ESLint』はコード整形と静的解析が役割で、Cursor標準AIとは重複しません。
用途が明確で、向いている人もはっきりしていて、入れる優先度は高めです。
一方でRoo CodeやOpenAI CodexのようなAI支援系は、構造化された対話や別系統のエージェント運用をしたい人には向きますが、Cursor標準のチャットやエージェントと重なる場面が多く、優先度は低めから中位に下がります。
読者目線では、「何ができるか」より先に「Cursor標準で既に何ができるか」を見たほうが選定の失敗が減ります。

VS Code拡張 vs Cursor Marketplace vs MCP

2026年のCursorは、拡張の入口が1つではありません。
従来からある『VS Code』互換の拡張に加えて、2026年2月に公開されたCursor Marketplace公開以降は独自プラグインの流れが生まれました。
さらにCursor MCPドキュメントで案内されているMCPによって外部ツール接続も公式に扱えるようになりました。
この3系統を同じ「拡張機能」とひとまとめにすると、何をどこで足すべきかが一気に見えにくくなります。

整理の軸はシンプルです。
まず『VS Code』拡張は、エディタそのものの基礎体力を上げるためのものです。
Japanese Language Pack for Visual Studio Codeで日本語化する、『Python』で補完やデバッグを整える、Prettier – Code formatterで保存時整形を通す、『ESLint』でルール違反を即座に出す、GitLens — Git superchargedで履歴を読みやすくする、といった具合です。
ここで見るべき項目は、正式名称、用途、向いている人、Cursor標準機能との重複有無、入れる優先度の5つです。
たとえば『Python』はPythonを書く人向けで、用途は言語サポートとデバッグ、Cursor標準AIとは非重複、優先度はPython案件なら高です。
GitLens — Git superchargedはGit履歴の可視化が主用途で、レビューや履歴追跡を頻繁に行う人に向き、標準AIとは直接重なりにくいので中〜高で考えられます。

一方でCursor MarketplaceやMCPは、エディタ内部の便利機能というより、外部サービスや社内知識を作業文脈に引き込むための入口です。
AtlassianDatadogGitLabのようなサービス連携は、コード補完そのものを増やすというより、チケット、監視、リポジトリ情報を開発フローに接続する方向です。
ここは初心者が最初に触る領域というより、エディタ内の基本作業が固まったあとに効いてきます。
順番としては、先に『VS Code』拡張で土台を作り、その後にMarketplaceやMCPで外部連携を足すほうが、何が便利になったのかを切り分けやすくなります。

この役割分担を踏まえると、ここで紹介する10個の見え方も変わります。
たとえばDockerはコンテナ運用の人には有力ですが、用途はローカルのコンテナ管理やDockerfile支援であり、MarketplaceやMCPの外部接続とは別枠です。
Roo CodeはAIエージェント用途なので、向いているのはCursor標準エージェントに加えて別の対話設計を試したい人です。
ただし重複はあります。
OpenAI Codexも同様で、クラウド側のCodexワークフローをIDEに持ち込みたい人には意味がありますが、Cursor標準のAIチャットやエージェントと競合する場面があるため、優先度は最初から高くは置きません。
こうして系統ごとに分けると、「便利そうだから入れる」ではなく「役割が空いているから入れる」に変わります。

入れすぎ・重複・安全性リスクの整理

拡張を増やしすぎると、単に一覧が長くなるだけでは済みません。
まず起きやすいのがパフォーマンス低下です。
サイドバー項目が増え、保存時処理が重なり、補完や診断の待ち時間が発生すると、エディタ全体のテンポが落ちます。
次に厄介なのがキーバインド衝突で、同じショートカットに別機能が割り当たると、思った操作が出なくなります。
さらにCursorではAI補完の二重化が起きやすく、標準AIと外部AI拡張の両方が前に出ると、良い提案が増えるどころか選別コストが増えます。

フォーマット系でも重複は起こります。
Prettier – Code formatterと『ESLint』は併用自体に意味がありますが、役割を分けて設定しないと保存のたびに整形結果が揺れます。
実務では『Prettier』をデフォルトフォーマッタにして保存時整形を担当させ、『ESLint』は静的解析と自動修正に寄せる構成のほうが安定します。
ここで見るべきなのは、チーム規約に沿うかどうかです。
プロジェクトに整形ルールがあり、CIでも『ESLint』が走るなら、個人の好みだけで別のフォーマッタを足す意味はほぼありません。
逆に、規約が既に固まっているなら『Prettier』と『ESLint』の優先度は一気に上がります。

安全性の観点も見逃せません。
拡張は便利な反面、コードや設定、場合によっては環境変数や外部サービス認証と接点を持ちます。
一般論として、拡張由来の情報窃取事例はブラウザ拡張の世界でも起きており、仕組みが違っても「追加コンポーネントに権限を渡す」という構図は同じです。
とくに外部AI系や外部連携系は、APIキーや通信先の設計まで含めて見る必要があります。
Roo CodeやOpenAI Codexのように外部モデルやクラウド処理を前提にするものは、用途が明確な人には刺さりますが、Cursor標準機能で足りる段階なら優先度を上げないほうが全体の管理が軽くなります。

判断基準は4つに絞ると迷いません。
標準機能で代替できるか、いまのプロジェクトに必須か、チーム規約に合うか、保守が続いているかです。
たとえばJapanese Language Pack for Visual Studio Codeは用途が日本語化で、向いている人は設定項目を日本語で把握したい人、Cursor標準機能との重複はなく、優先度は高です。
『Python』はPython案件なら必須寄り、Dockerはコンテナ開発なら高、それ以外では上げすぎなくて構いません。
GitLens — Git superchargedは履歴確認が多い人に向き、重複は少ないものの、最初の1本目ではなく中位です。
Roo CodeやOpenAI Codexは正式名称と用途を理解したうえで、Cursor標準AIとの重複がある前提で見ると、必要な人だけが選ぶ枠に落ち着きます。
こうして優先度を付けておくと、紹介する10個を「全部入れる候補」ではなく「用途別の採用候補」として読めるようになります。

Cursorで拡張機能をインストールする手順

ショートカットと検索の基本

Cursorで拡張機能を入れる入口は、左側のアクティビティバーにある Extensions です。
キーボードから開くなら、Windows / Linux は Ctrl+Shift+X、Mac は Cmd+Shift+X を使います。
まずこのショートカットを覚えておくと、設定画面を探して迷う時間が減ります。
実際に使ってみると、拡張の追加も削除もこの画面が起点になるので、最初に手になじませておく価値があります。

パネルを開いたら、上部の検索欄に拡張名をそのまま入れます。
たとえば日本語化ならJapanese Language Pack for Visual Studio Code、Python開発なら『Python』、コード整形ならPrettier – Code formatterという流れです。
候補が出たら目的の拡張をクリックし、詳細画面の Install を押します。
依存する拡張がある場合は追加インストールの案内が出ることがあり、そのまま進めれば問題ありません。
初回は権限や再読み込みの案内が表示されることもありますが、表示に従って進めれば導入は完了します。

なお、2026年以降のCursorにはCursor Marketplaceという独自のプラグイン導線もありますが、ここで扱っているのはまず VS Code互換の拡張機能 です。
初心者が最初に触るのは従来どおりExtensionsパネルから入れる言語拡張や整形系拡張で十分です。
日本語化、言語サポート、フォーマッタの3つから入ると、作業環境の土台が整います。

VS Codeからの移行時のコツ

Cursorは『VS Code』ベースなので、既存の拡張資産を引き継ぎやすい構成です。
初回起動時に Import の案内が出た場合は、そこで『VS Code』の設定やテーマ、拡張機能を取り込めます。
ゼロから入れ直すより早く環境を再現できるので、すでに『VS Code』で開発していた人にはこの流れが合います。

ただし、全部をそのまま持ってくれば快適になるわけではありません。
前のセクションで触れた通り、CursorはAI機能を標準搭載しているため、GitHub CopilotのようなAI補完系や、役割が近いAIチャット系拡張は重複しやすいからです。
移行直後は「入っているけれど一旦無効化」という状態にしておくと、補完の二重表示やショートカット競合を切り分けやすくなります。
実際に移してみると、テーマや言語拡張はそのまま活きる一方で、AI系だけ整理したほうが画面も動作も落ち着くことが多いです。

移行後に見直し候補になりやすいのは、用途が明確な拡張です。
たとえば『Python』や『ESLint』は開くファイル種別がはっきりしているので残しやすく、GitLens — Git superchargedやDockerは担当業務があるときだけ有効、という整理ができます。
反対に、何となく入れていた補助拡張は、このタイミングで整理すると構成が読み取りやすくなります。
『VS Code』で積み上がった環境をそのまま再現するより、Cursorで本当に使うものを残す意識のほうが失敗しません。

有効化と動作確認のチェックポイント

インストールが終わっても、そこで確認を止めると「入れたのに動かない」でつまずきます。
拡張の詳細画面、またはExtensions一覧で状態が Enabled になっているかを見るところまでが1セットです。
Disabled なら無効のままなので、必要に応じて Enable を選びます。
拡張によっては Reload を求められるため、その表示が出たら反映まで進めます。

言語拡張は、対応するファイルを1つ開いて反応を見ると判別しやすいのが利点です。
たとえば『Python』を入れたあとに .py ファイルを開き、補完や定義ジャンプ、ステータスバー上の言語サーバー関連の表示が出ていれば、少なくとも基本部分は動いています。
『ESLint』なら警告表示や修正候補、Prettier – Code formatterなら保存時の整形が起きるかを見ると状態をつかめます。
画面上で何が変わるかを1つ確認するだけで、導入ミスなのか設定不足なのかを切り分けやすくなります。

設定系の拡張で見落としやすいのが、インストールしただけでは既定動作にならない 点です。
Prettier – Code formatterを入れた直後に保存しても整形されず、最初は拡張が壊れているように見えることがあります。
筆者もこの状態に一度引っかかりましたが、Settings で Editor: Default Formatter を esbenp.prettier-vscode に切り替え、あわせて Editor: Format On Save を有効にしたら、その場で保存時整形が動きました。
こうした拡張は「Installで終わり」ではなく、「既定の担当に割り当てる」ところまで見ないと本来の動きになりません。

Cursor Quickstartの流れでも基本操作は確認できますが、拡張まわりは「入ったか」ではなく「役割を引き受けたか」で判断すると迷いません。
拡張一覧の状態表示、対象ファイルを開いたときの反応、必要なら Default Formatter の指定まで見ておくと、導入直後の詰まりどころをほぼ避けられます。

Cursor おすすめ拡張機能10選

この10個は、まず土台を整えるものから順に並べています。
選定の軸は3つです。
ひとつはCursor標準のAIと役割がぶつからないこと、もうひとつは入れた直後から効き目が見えること、そして2026年にCursor MarketplaceやMCPの選択肢が増えたあとも無駄になりにくい汎用拡張であることです。
Cursor Marketplace公開でも拡張の導線は広がっていますが、最初に効くのはあくまで日本語化、言語サポート、整形、静的解析、Git補助といった基本装備です。

導入の操作は全て共通で、Extensionsパネルを Ctrl+Shift+X（Macは Cmd+Shift+X）で開き、拡張名を検索してInstallを押します。
『VS Code』から移行した場合は、前述の通りテーマや言語拡張は引き継げることが多く、再セットアップの手間を減らせます。
入れたあとに一覧で Enabled になっているか、必要なら Reload が済んでいるかまで見れば、導入で止まりません。

Japanese Language Pack for Visual Studio Code

正式名称はJapanese Language Pack for Visual Studio Codeです。
用途はそのまま日本語化で、設定画面やメニュー、通知の意味をすぐ読める状態に変えてくれます。
向いている人は、まず英語UIで止まりたくない初心者と、設定項目の意味を日本語で把握したい人です。
Cursor標準機能との重複はありません。
優先度は最優先です。

特に初期設定では、AI機能より先にUIの意味を理解できるかどうかが作業速度を左右します。
英語のままでも使えますが、フォーマッタやLintの設定に入った瞬間、項目名の読み違いで止まりやすくなります。
日本語化を入れておくと、設定変更の迷いどころが減ります。
日本語化拡張はインストール数が約812万という規模感もあり、定番としての安心感があります。

導入後は、コマンドパレットや設定画面のラベルが日本語になっていれば有効化できています。
もし表示が変わらなければ、言語切り替えや再読み込みがまだ反映されていない状態です。

Python

正式名称は『Python』で、提供元はMicrosoftです。
用途はPython向けの補完、デバッグ、Lint、フォーマット、テスト、Jupyter連携、仮想環境の扱いまで含む総合拡張です。
向いている人は、.py を書く人全員で、学習用のスクリプトから業務コードまで守備範囲が広いです。
Cursor標準AIとは役割が別で、重複はほぼありません。
AIは提案しますが、言語サーバーやデバッグ機能そのものは置き換えません。
優先度は高です。

CursorはAI補完が強いので、Python拡張なしでも少しは書けます。
ただ、補完の精度、定義ジャンプ、実行環境の切り替え、デバッグ体験は『Python』拡張が入ってからが本番です。
とくに仮想環境を切り替えながら作業する人は、ステータスバーでインタプリタを見られるだけでも事故が減ります。

導入後の確認は明快で、.py ファイルを開いたときに補完が効くか、インタプリタ選択が出るか、定義ジャンプやデバッグ設定が動くかを見ます。
PylanceやPython Debuggerなどの関連拡張が案内された場合は、その流れで入れると機能が揃います。

Python - Visual Studio Marketplace

Extension for Visual Studio Code - Python language support with extension ac

marketplace.visualstudio.com

Prettier - Code formatter

正式名称は『Prettier - Code formatter』です。
用途はコード整形で、JavaScript、TypeScript、JSON、CSS、HTML、Markdownなどの書式を保存時に揃えます。
向いている人は、フロントエンド開発者はもちろん、JSONやMarkdownを触る人にも広く当てはまります。
Cursor標準機能との重複は限定的で、AIがコードを書いても書式の最終統一は別物です。
優先度は高です。

この拡張は、インストールだけでは終わらず、Editor: Default Formatter を esbenp.prettier-vscode に設定し、Editor: Format On Save を有効にしたところから効き始めます。
ここまで入ると、AIが出したコードのインデントや改行のばらつきが保存時に整い、差分が余計に膨らみません。
実務では『ESLint』と組み合わせたあと、PRで見る差分が本当に必要な変更だけに寄って、レビュー時間が短くなりました。
人が整形を直す時間より、ロジックを見る時間を確保できます。

有効化確認は、対応ファイルを保存した瞬間に整形が走るかどうかです。動かなければ、既定フォーマッタが別の拡張になっていることが多いです。

ESLint

正式名称は『ESLint』です。
用途はJavaScriptやTypeScriptの静的解析で、危ない書き方やチームルール違反をエディタ上で見つけ、自動修正できる部分は保存時に直します。
向いている人は、JavaScript系のプロジェクトを触る人全員です。
Cursor標準AIとの重複はほぼありません。
AIは候補を出せても、プロジェクト固有ルールに沿って継続的に赤線を出す役は『ESLint』です。
優先度は高です。

注意したいのは、拡張だけで完結せず、プロジェクト側に eslint パッケージが必要なことです。
『Prettier』と一緒に使うなら、eslint-config-prettier などで競合ルールを避ける構成にすると保存時の挙動が安定します。
私の手元でも、『Prettier』と『ESLint』を揃えてからは、AIが吐いたコードの表記ゆれや細かなルール違反が保存時に整い、PRの差分が最小限になりました。
スタイルの議論が減るので、レビューでは仕様や例外処理に集中できます。

有効化確認は、.js や .ts を開いたときに警告が表示されるか、保存時に修正可能な項目が直るかを見るのが早いです。

ESLint - Visual Studio Marketplace

Extension for Visual Studio Code - Integrates ESLint JavaScript into VS Code

marketplace.visualstudio.com

Docker

正式名称はDocker系のContainer Tools拡張です。
用途はコンテナ、イメージ、ボリューム、Compose、Dockerfileの支援で、エディタ内からコンテナ資産を見たり、Dockerfileの補完や検証をしたりできます。
向いている人は、ローカル開発でコンテナを使う人、バックエンドやインフラ寄りの作業がある人です。
Cursor標準AIとの重複はありません。
優先度は中です。

AIに docker-compose.yml を書かせることはできますが、コンテナ一覧を見たり、ビルドや状態確認をしたりする運用面は別です。
Docker DesktopやDocker CLIが動いている状態なら、エディタ側でも見通しが良くなります。
逆に、コンテナを使わない人にはまだ不要です。

導入後はサイドバーにコンテナ関連のビューが出るか、Dockerfileで補完が効くかを見れば状態を把握できます。
仕事でコンテナを触る頻度があるなら早めに入れる価値がありますが、静的サイトや学習段階なら後回しでも困りません。

GitLens — Git supercharged

正式名称はGitLens — Git superchargedです。
用途はGit履歴の可視化で、inline blame、コミット履歴、差分比較、ファイル単位の履歴追跡を強化します。
向いている人は、チーム開発をしている人、既存コードを読む時間が長い人、AIが触った変更の追跡を早くしたい人です。
Cursor標準AIとの重複は少ないです。
AIは変更案を出せても、履歴の読み解きはGitLensのほうが得意です。
優先度は中〜高です。

この拡張は、コードを書く量そのものより、変更の背景を読む量が増えたときに効きます。
特にAI生成コードのレビューでは、blameと履歴があるだけで「どこをAIが直したのか」を把握する速度が上がります。
私も差分検証ではGitLensの履歴をよく開きますが、修正箇所の前後関係や、以前の実装意図がすぐ見えるので、ただの色付き差分だけを見るより判断が速く進みます。

Community版の範囲でも十分役に立ちます。
導入後は、行ごとの blame 表示やファイル履歴の表示が出れば基本機能は動いています。
サイドバーが込み合うと感じたら、不要なビューだけオフにすると落ち着きます。

RooCode

正式名称はRoo Codeです。
用途はAIエージェント型のコーディング補助で、複数LLMとの連携やモード切り替えを前提にした作業をエディタ内で進めます。
向いている人は、Cursor標準AIだけでは足りず、別系統のエージェント運用も試したい人です。
Cursor標準AIとの重複は大きいです。
優先度は低〜中です。

ここは扱いを慎重に分けたほうがよくて、最初の一手としては勧めません。
理由は単純で、Cursor自体にチャット、Composer、Agentがあるからです。
標準機能で足りない場面が見えてから足すほうが、役割の切り分けが崩れません。
Roo Code自体は拡張として無料で使えますが、外部LLMとの連携やAPIキー管理を含むため、ただ入れるだけの拡張より設定の意味が重くなります。

導入するなら補助候補としての位置づけが合っています。
拡張一覧で Enabled になっていて、コマンドやサイドバー項目が現れれば導入自体はできていますが、初心者の最初の環境としては後段に置くのが自然です。

OpenAI Codex（表記の明確化）

ここで触れている「Codex」系の拡張は、主に OpenAI が提供する Codex 系モデルや、それを利用するサードパーティ拡張を指します。
導入には OpenAI アカウントと API キーが必要です。
用途は AI コーディング支援やコード生成・レビュー補助で、Cursor の標準AIと機能が重複することが多いため、優先度は一般的に低です。

正式名称は特定の1本ではなく、theme検索で見つかる各種テーマ拡張です。
用途は配色の調整で、長時間作業時の視認性や、どこに注意を向けるかを整えます。
向いている人は、標準テーマのままだとコードの区切りが見えにくい人、VS Code時代の見た目をそのまま持ってきたい人です。
Cursor標準機能との重複はありません。
優先度は中です。

テーマは飾りに見えて、意外と疲労感と読み間違いに直結します。
シンタックスカラーが合うテーマに変えるだけで、コメント、型、文字列、警告色の判別が安定します。
『VS Code』からの引き継ぎでも再現しやすい項目なので、移行直後に違和感があるなら最初期に戻しておくと作業リズムが崩れません。

有効化確認は、テーマを切り替えた瞬間に画面全体の配色が変わるかどうかです。好みの問題ではなく、誤読が減る配色かどうかで見ると選びやすくなります。

言語別拡張

正式名称は使う言語ごとに変わります。
たとえばGoRustPHPC/C++JavaYAMLのような言語拡張が該当します。
用途は、その言語に必要な補完、構文解析、Lint、デバッグ、実行補助を足すことです。
向いている人は、利用言語がはっきりしている人です。
Cursor標準AIとの重複は少ないです。
AIが文法候補を出しても、言語サーバーや診断までは担いません。
優先度は高です。

初心者が迷いやすいのは、便利そうな拡張を先に探してしまう点です。
実際には、使う言語の拡張を先に入れるだけで、赤線、補完、定義ジャンプ、実行体験が揃います。
ここが抜けたままAI補助を増やしても、土台が弱いままです。
『Python』を個別に挙げたのは利用者が多く導入効果が見えやすいからで、考え方自体は他言語でも同じです。

導入後は、その言語のファイルを1つ開くだけで違いが出ます。
補完候補、エラー表示、定義ジャンプ、関連コマンドが増えていれば有効化できています。
Cursor標準AIとぶつからず、しかも将来MarketplaceやMCPを足しても土台として残るので、この枠は息の長い投資になります。

まず入れるべき3つと、あとから追加でよいもの

最初に入れるべき3つ

Cursorへ移った直後は、拡張を増やすより「まず開発を再開できる状態」を作るほうが先です。
私自身、環境移行の初日はJapanese Language Pack for Visual Studio Codeと利用言語の拡張、それに『Prettier - Code formatter』の3点だけ入れて作業を始めました。
その時点で設定画面の読み違いが減り、コードには赤線と補完が戻り、保存時の整形まで揃ったので、普段の開発はその日のうちに再開できました。
2日目に『ESLint』やGitLensを足しても混線せずに済んだのは、土台を先に固めていたからです。

1つ目はJapanese Language Pack for Visual Studio Codeです。
拡張や設定の名前は英語のままでも使えますが、乗り換え直後は項目名の意味を追うだけで集中が削られます。
Japanese Language Packはインストール数が約812万とされる定番で、設定画面やコマンドの理解速度を底上げしてくれます。
UIで迷う時間を減らせるので、初心者ほど最初に入れる意味があります。

2つ目は、いま書く言語の言語拡張です。
ここは便利機能ではなく、エディタとしての土台です。
赤線によるエラー表示、補完、定義ジャンプ、シンボル検索は、AI補助より先に必要になる場面が多くあります。
たとえば『Python』拡張はMicrosoft提供で、補完、デバッグ、リンティング、フォーマット、テスト統合まで含む開発基盤として機能します。
AIが候補を出してくれても、言語サーバー由来の診断やジャンプがないと、修正の確信が持てません。

3つ目は『Prettier - Code formatter』または『ESLint』です。
ここはチームの運用に寄せて選ぶのが自然です。
個人開発や、まず見た目の揃ったコードを早く得たいなら『Prettier』を先に入れると収まりがいいです。
『Prettier』は保存時整形との相性がよく、editor.defaultFormatter を esbenp.prettier-vscodeにして editor.formatOnSave を有効にすると、保存だけで整形が走る構成にできます。
JavaScriptやTypeScriptの現場で、ルール違反の検出も初日から欲しいなら『ESLint』を先に置く判断もあります。
ただし『ESLint』はプロジェクト側の eslint 本体を参照する前提があるので、導入直後の軽さでは『Prettier』が一歩先です。

あとから追加して効く拡張

初期装備が整ったあとに足すと効果を感じやすいのが、GitLensのような履歴可視化系です。
誰がどこを変更したか、いつ壊れたか、どのコミットに戻るべきかが見え始めると、レビューや調査の速度が上がります。
GitLensは無料のCommunityでもインラインブレーム注釈や基本的な履歴探索が使えるので、Gitの情報をエディタ内で見たい人には相性がいいです。
ただ、サイドバーや表示項目が増えるので、移行初日に入れると画面の密度だけ先に上がります。
2日目以降に足しても遅くありません。

Docker系の拡張は、必要な人だけで十分です。
コンテナで開発する案件なら価値がありますが、ローカル実行だけで進む学習用途や小規模プロジェクトでは、初日から背負うものではありません。
Container ToolsはDocker DesktopやDocker CLIが前提で、コンテナ一覧やイメージ操作、Dockerfile補助まで扱えます。
逆に言うと、コンテナを使わない段階で入れても、サイドバーの情報が増えるだけになりやすいのが利点です。

テーマ拡張も後回しで構いません。
見た目の話に見えて、実際は識別の話ですが、まずは標準テーマで1日触ってから不足を感じた箇所を埋めるほうが選定がぶれません。
コメントと文字列の差が見えにくい、警告色が埋もれる、VS Code時代の配色のほうが読み取りやすかった、という不満が出てから足すと、単なる気分転換ではなく作業上の調整になります。

AI補助系は基本的に後回しで問題ありません。
Cursorは標準でチャット、Composer、Agent を備えているため、まずはそれらで不足が明確になってから外部の AI 拡張を追加する流れが、設定や運用の手戻りを減らします。

言語ごとの優先順位を見ると、まず入れるべきものはさらに整理できます。
『Python』とTypeScriptは、最初に言語拡張を入れる判断がもっとも素直です。
『Python』ではMicrosoftの『Python』拡張が補完、デバッグ、テスト統合まで担うので、ここがないとエディタの基礎機能が不足します。
TypeScript系でも、言語サポートがある前提で赤線や補完の精度が安定します。
フロントエンドでは、言語拡張に加えて『ESLint』と『Prettier』の役割分担を早めに決めておくと安定します。
見た目の整形は『Prettier』、ルール違反の検出と自動修正は『ESLint』が担うという分担です。
これらを併用する場合は、プロジェクト側で eslint-config-prettier などを導入して競合ルールを回避する構成をおすすめします。
フロントエンドは少し考え方が違って、言語拡張に加えて『ESLint』と『Prettier』の役割分担を早めに決めたほうが安定します。
見た目の整形は『Prettier』、ルール違反の検出と自動修正は『ESLint』という分担です。
この2つを一緒に使うなら、プロジェクト側で eslint-config-prettier を入れて競合ルールを止めておく構成が定番です。
保存時に『Prettier』で整え、修正可能なルールは『ESLint』で詰める流れにすると、ローカルとレビュー時の差分が増えにくくなります。

このあたりを言い換えると、初心者が最初に見るべきなのは「便利そうな拡張一覧」ではなく、「自分の言語にとって土台になる拡張は何か」です。
CursorはAIが強いぶん、補助機能に目が向きやすいのですが、実際に作業を止めずに進める鍵は、日本語化、言語サポート、整形かLintの3点に集約されます。
そこが固まっていれば、履歴可視化やテーマ、Docker、追加のAI補助はあとから無理なく積み上げられます。

逆にCursorでは不要になりやすい拡張機能

競合しやすいAI補完・チャットの整理

Cursorでは、AIまわりの拡張を足すほど便利になるとは限りません。
むしろ最初に整理したいのは、「標準で入っているAI」と「あとから足すAI」の役割が重なっていないかです。
Cursorはチャット、コード補完、Composer、Agentまで最初から統合されているので、AIのUIを増やすだけの拡張は優先度が下がります。
『Cursor Quickstart』の内容を見ても、導入直後に触る中心は標準機能側です。
まずここで作業の流れを固めたほうが、どこが不足なのかを判断できます。

実際に不要になりやすい拡張を、用途ごとに整理すると次の10個です。
ここでの「不要」は機能が悪いという意味ではなく、Cursor標準機能と重なりやすく、移行初期の優先度が低いという意味です。

この一覧で共通しているのは、コード補完、チャット、編集提案、エージェント操作のどこかがCursor標準機能とぶつかる点です。
特にGitHub CopilotとCodeiumのような補完系は、候補の出し方そのものが近いので、同じタイミングで提案が出ると視線の置き場が増えます。
私もGitHub CopilotとCursor AIを同時に動かしたことがありますが、補完候補が交互に現れて、文章を書いているのか提案をさばいているのかわからなくなりました。
片方を無効化したら、入力のリズムが戻って作業が落ち着きました。
機能の足し算というより、判断回数の足し算になっていたわけです。

補完だけでなく、ショートカットの衝突も見落としにくい判断材料になります。
チャット呼び出し、インライン編集、コード生成の起点が複数あると、「どのAIに何を頼むか」を毎回選ぶことになります。
これが積み重なると、便利さより切り替えコストのほうが前に出ます。
Cursor Proは『Cursor料金プラン』で月額20ドルと案内されていますが、すでに標準AIへ投資している状態なら、同系統のAI拡張をさらに重ねる理由は、明確な運用目的がある場合に限られます。

一方で、AIと関係がない拡張まで外す必要はありません。
前述の『Python』『Prettier』『ESLint』のように、言語サポートや整形、Lintはエディタの土台を作る拡張です。
不要になりやすいのは、あくまでCursorがすでに持っているAIレイヤーと正面から競合するものです。

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

例外ケースと安全な共存手順

とはいえ、AI拡張を入れないのが常に正解というわけでもありません。
例外として残るのは、ツールの性能差ではなく、ワークフロー上の理由があるケースです。
たとえば企業ライセンスの都合でGitHub Copilotの利用が前提になっているチーム、レビュー文やプロンプト資産がCodexやClaude系の運用に寄っている現場、あるいはRoo Codeのように複数LLMを切り替えながら設計と実装を分けている人は、共存の意味があります。

その場合でも、同時に全部を前面へ出す構成は避けたほうがまとまります。
安全に共存させるなら、役割を先に固定するのが近道です。
たとえばCursor標準のChatとComposer、Agentを主軸に置き、GitHub Copilotは企業規約対応の補完専用に限定する、あるいはRoo Codeを長い手順の自動化専用にして、日常の質問や修正はCursor側へ寄せる、という切り分けです。
機能名ではなく、「どの場面で呼ぶか」を決めると混線が減ります。

設定面では、次の3段階で整理すると破綻しにくくなります。

1. 補完を担う拡張は1つに絞る
2. チャット窓は主役を1系統に決める
3. ショートカットが重なる機能は片方を無効化する

この順番にすると、まず入力中の提案が安定し、そのあと会話導線を整理でき、仕上げに操作ミスが減ります。
とくにGitHub CopilotやCodeiumのような補完型は、残すなら補完担当、外すなら補完機能をオフにする、のどちらかに寄せたほうが迷いません。
チャットだけ使いたいのに補完まで出てくる状態が、いちばん散らかります。

Roo CodeやCodex系を共存させる場面では、機能重複よりも接続先の違いが価値になります。
Cursor標準AIでは足りないモデル運用や既存プロンプト資産の再利用が目的なら、追加する理由が立ちます。
逆に、単に「AIの入口をもう1つ増やす」だけなら、画面内の選択肢が増えるだけで、作業の芯は強くなりません。
『Cursor新プラグイン追加』のとおり、拡張の受け皿は広がっていますが、移行初期に効くのは数を増やすことではなく、標準のChat、Composer、Agentで自分の流れを一本通すことです。

30 以上の新しいプラグインが Cursor Marketplace に登場 · Cursor

マーケットプレイスで提供される構築済みの機能で Cursor を拡張できます。

cursor.com

拡張機能が動かないときの対処法

再起動・再読込・有効化で直るケース

拡張機能の不調は、設定を掘り始める前に基本の3つを試すだけで収まることがよくあります。
まず効くのがウィンドウの再読込か、アプリ自体の再起動です。
Cursorは『VS Code』系の拡張資産を引き継げる一方、拡張の読み込みタイミングやワークスペース状態が一度崩れると、インストール済みなのに反応しない、サイドバーには出るのに中身が空、保存時の処理だけ走らない、といった止まり方をします。
こういうときは、設定を増やすより読み込み状態をいったん立て直したほうが早く戻ります。

次に効くのが、対象の拡張をいったん無効化してから有効化し直す手順です。
拡張の内部状態が不安定になっているだけなら、再インストールまで進まなくてもこれで戻ることがあります。
更新直後に不安定になった拡張でも、この切り替えで起動フックが入り直して復旧する場面があります。
あわせて最新版への更新も見ておくと、既知の不具合が解消されていることがあります。

私がよく見るのは『Prettier』が動かない場面ですが、実際には拡張そのものが壊れているより、既定フォーマッタが未設定のまま止まっているケースがいちばん多いです。
『Prettier』を既定フォーマッタに切り替えて、保存時整形が一度でも走れば、拡張本体ではなく設定の線が当たりだったと判断できます。
保存しても何も変わらない状態と、保存で整形が入る状態の差ははっきりしているので、切り分けの入口として使えます。

競合の見つけ方

不具合の原因が見えにくいときは、問題が出ている拡張以外を一時的に止めて、衝突相手を絞るのが近道です。
特にCursorでは、AI補完、整形、Lint、Git表示のように、同じ画面や保存処理に複数の拡張が関わるため、単体では正常でも組み合わせで崩れることがあります。

切り分けは、まず対象の拡張だけ残して症状が消えるかを見るところから始めます。
そこで直るなら競合です。
次は無効化した拡張を半分ずつ戻していく二分探索の形にすると、数が多くても衝突元を追いやすくなります。
ひとつずつ戻す方法でもたどり着けますが、拡張が増えている環境では時間がかかります。

AI補完が二重に出る問題は、最初にAI系を1つへ絞ると整理しやすくなります。
Cursor標準の補完に加えてGitHub CopilotやCodeiumの候補が同時に出ると、故障ではなく競合であることが多いです。
補完がちらつく、候補が交互に出る、Tabキーで意図しない提案が入るといった挙動は、まず同種のAI拡張を減らしたほうが原因を読み取りやすくなります。
前のセクションでも触れた通り、AIは足し算より役割分担で見たほうが安定します。

『Prettier』と『ESLint』も競合の定番です。
保存時に整形と自動修正の順番が噛み合わないと、保存のたびに差分が揺れたり、期待した整形だけ入らなかったりします。
プロジェクト側でeslint-config-prettierや plugin:prettier/recommended を使って役割を分ける構成にすると、フォーマットは『Prettier』、静的解析と修正は『ESLint』と整理しやすくなります。

言語拡張・設定不足の典型パターン

拡張が入っているのに補完や赤線が出ない場合、そもそもその言語の拡張が不足していることがあります。
たとえば『Python』を書いているのに『Python』拡張を入れていなければ、言語サーバーが立ち上がらず、補完、フォーマット、診断、定義ジャンプが揃って沈黙します。
見た目はただのテキストファイルに近い状態なので、エディタは開けても開発体験は別物です。

Microsoft提供の『Python』拡張は、補完やシンボル検索、デバッグ、Lint、フォーマット、テスト連携まで含む土台です。
さらにPylanceなどの言語サーバー連携が入って初めて、コード解析が前に出てきます。
Pythonで補完が出ないときに設定ファイルばかり追いかけていると空振りになりやすく、まず言語拡張が入っているかを見たほうが話が早いです。

設定不足では、『Prettier』と『ESLint』に典型例があります。
『Prettier』は拡張を入れただけでは止まったままのことがあり、editor.defaultFormatter に esbenp.prettier-vscode を入れて、editor.formatOnSave を有効にして初めて保存時整形が動きます。
私自身、この組み合わせを入れた直後に保存でコードがそろったら、原因は拡張ではなく既定フォーマッタ未指定だったと判断しています。

『ESLint』は拡張だけで完結しません。
エディタ側に『ESLint』拡張があっても、ワークスペースに eslint 本体が入っていないと、期待した診断や自動修正が出ません。
JavaScriptやTypeScriptのプロジェクトで『ESLint』が静かなときは、開発依存関係に eslint が追加されているかで説明がつくことが多いです。
拡張は橋渡し役で、解析の本体はプロジェクト側にある、と考えると噛み合います。

特定拡張の表示不具合チェックリスト

表示系の不具合は、拡張そのものより前提条件が抜けているケースが目立ちます。
Dockerビューが出ない、または開いても空のままなら、Docker Desktopが起動していないことがあります。
Docker系の拡張はローカルのDocker DesktopやDocker CLIと連動して情報を引いてくるため、エディタだけ再起動しても直らず、基盤側が止まっているとビューは埋まりません。
Docker Desktopの再起動後に拡張を再読込すると戻ることがあります。

GitLensのViewが空のときは、対象フォルダがGitリポジトリかどうかで説明できることが多いです。
単なる作業フォルダを開いているだけでは、履歴もブレームも出せません。
.git を持つルートを開いていない、あるいは親子ディレクトリのどこを開いているかがずれているだけで、サイドバーは見えても中身は空になります。
私はGitLensが静かなとき、表示設定より先に「今開いているのは本当にリポジトリの根か」を見ます。
ここが外れていると、拡張を触っても前へ進きません。

短く整理すると、表示不具合は次の順で当たりをつけると迷いにくくなります。

• Dockerビューが出ない、空のまま

Docker Desktopが起動しているか、拡張の再読込で復帰するかを見る

• GitLensのViewが空

開いているフォルダがGitリポジトリで、ルート位置がずれていないかを見る

• 『Prettier』が保存時に動かない

既定フォーマッタが『Prettier』になっているか、保存時整形が有効かを見る

• 『ESLint』が警告を出さない

ワークスペースに eslint が入っているか、対象ファイル種別で拡張が動いているかを見る

このあたりは、拡張の再インストールへ飛ぶ前に見るだけで、空振りを減らせます。
Cursor Quickstartの基本操作が見える『Cursor Quickstart』を一度なぞっておくと、エディタ側の読み込みとワークスペースの前提を切り分けやすくなります。

2026年以降は拡張機能だけでなくMarketplaceとMCPも見る

Marketplaceの位置づけと代表例

Cursorの拡張手段は、2026年から見方を少し変えたほうが実態に合います。
これまでは『VS Code』互換の拡張を入れる発想が中心でしたが、2026年2月17日に『Cursor Marketplace』が公開されてからは、AIが外部サービスとどうつながるかまで含めて設計できるようになりました。
この仕組みが単なる見た目の追加ではなく、外部ツール連携の入口として位置づけられています。

私自身はGitLab系のプラグインを入れたときに、この差を実感しました。
マージリクエストやパイプラインの状態をAIが拾えるようになると、レビューコメントが単なるコードの見た目チェックで終わらず、「この変更はCIの失敗原因とつながっている」「既存のMR議論と整合しているか」という方向まで踏み込みます。
コード単体しか見えていないときより、指摘の重心がレビュー実務に寄ってきた感触がありました。

MCPでできることと導入の難易度感

MCPはModel Context Protocolの略で、AI が外部ツールやナレッジへアクセスするための共通規格です。
詳しくは Cursor の公式ドキュメントを参照してください。
社内ドキュメントや限定公開のナレッジを安全に渡す用途で有効であり、接続先と権限の設計が必要になる点に注意してください。
違いをひと言で分けるなら、『VS Code』拡張はエディタ機能の拡張、Marketplaceは外部サービス連携の追加、MCPはその連携を作るためのプロトコルです。
この3つは似て見えても、担当範囲が重なっていません。
『Prettier』や『ESLint』で整えるのは編集体験、GitLabやDatadogのプラグインで増えるのは業務文脈、MCPで開くのは自社固有の接続先です。

導入のハードルも同じではありません。
Marketplaceは公開済みの連携先を選ぶ形なので、比較的入り口が見えやすいのが利点です。
対してMCPは、何をAIに見せるか、どこまで操作を許すか、誰が接続設定を持つかまで設計が要ります。
拡張を1本追加する感覚で始めるというより、チームの情報流通を1段増やす作業に近いです。
個人で試すこともできますが、真価が出るのは社内データや業務フローを持っている場面です。

個人とチームでの選び方

個人開発なら、まずは従来の『VS Code』拡張で十分という判断で外しません。
日本語化、言語拡張、整形、Lintのような土台が整っていれば、Cursor標準のチャットやエージェント機能だけでも作業は前へ進みます。
AI機能が最初から統合されているので、個人用途でいきなり外部連携を増やすより、ローカル編集の流れを詰まらせない構成のほうが収まりがいいです。

一方、チームや業務利用では話が変わります。
Issue管理がAtlassian、コードレビューとCIがGitLab、運用監視がDatadog、社内検索がGleanというように、実際の判断材料がコード外へ散っているからです。
こういう現場では、AIがリポジトリだけ見えていても答えが薄くなります。
Marketplaceで既存SaaSとの接続を足し、さらに自社独自の情報源があるならMCPで埋める、という二段構えのほうが自然です。

コスト感も個人とチームで受け止め方が違います。
Cursor料金プランでは、2026年3月時点のCursor Proは公式サイトで月額20ドルです。
個人なら「AI統合IDEに払う料金」として判断しやすい水準ですが、人数分をそろえるチームでは、外部連携でレビューや調査の往復がどれだけ減るかまで見ないと合いません。
比較対象としてWindsurfは公式比較ページで月額15ドルなので、エディタ単体の価格差だけ見るとそちらが目に入ります。
ただ、チーム導入では数ドル差より、既存の『VS Code』資産を流用できるか、業務システムとの接続をどこまで深く持てるかのほうが効いてきます。

読者別に切り分けるなら、個人開発者は『VS Code』拡張を中心に整え、AI機能の重複追加を避ける構成が合います。
チーム開発者や情報システム寄りの立場なら、Marketplaceで既製連携を取り込み、MCPで社内固有の文脈までAIへ渡す構成が候補に入ります。
2026年以降のCursorは、拡張機能を選ぶだけでなく、AIにどの業務文脈を読ませるかまで含めて考えるIDEになってきています。

読み終えたらやること

Step1

まず入れるのは、日本語化拡張と、今まさに書く言語の拡張を1つだけです。
たとえば『Python』を書くなら、Microsoft提供の『Python』拡張を入れる。
この段階では、JavaScriptもGoもDockerもまとめて足さないほうが流れが安定します。
設定画面や通知の意味が日本語で追えるだけで、最初のつまずきが減りますし、言語拡張が1本あるだけで補完、定義ジャンプ、エラー表示の土台が整います。

私はここで欲張って拡張を並べるより、まず「今日使う1言語だけ」に絞ったほうが結局早いと感じています。
この順序だと、あとから「やっぱり不要だった」と外す作業がほとんど発生しません。
土台を崩さずに少しずつ足せるので、環境を安定させたまま強化できます。
『Python』拡張はVisual Studio Marketplaceで無料提供されており、補完やデバッグ、Lint連携まで一通りそろっています。
『Python』拡張

Step2

次に足すのは、品質系の拡張を1つだけです。
最初の1本としては『Prettier』が扱いやすく、保存した瞬間に整形がそろう状態まで持っていくと、見た目の差分で消耗しません。
設定は『Prettier』を既定のフォーマッタにして、保存時フォーマットを有効化するだけで十分です。
手で整える回数が減るので、CursorのAI補助とも役割がぶつかりません。

設定の要点はシンプルで、editor.defaultFormatter を esbenp.prettier-vscode にし、editor.formatOnSave を true にする形です。
これで保存時に『Prettier』が走るので、書いて保存するたびに表記ゆれが揃います。
私も最初は『ESLint』まで同時に入れたくなりましたが、品質系を一度に増やすと「どれが直したのか」が見えにくくなります。
まずは整形だけ通して、必要が出たらLintを足すほうが、設定の原因追跡がずっと楽です。
『Prettier』

Step3

AI系拡張は、Cursor標準で足りない部分が見えてから追加するのが順当です。
たとえば、複数LLMを自分で切り替えたい、別系統のエージェント運用を試したい、といった目的があるならRoo Codeのような選択肢が候補になります。
ただ、チャットや補完のためだけにAI拡張を重ねると、標準機能と役割が重なり、判断の起点が増えるだけになりがちです。

外部サービスとの連携が必要になったら、拡張を探し回るよりCursor MarketplaceやMCPを検討する段階です。
Marketplaceは2026年2月に公開され、外部ツール接続の受け皿が広がりました。
コード編集そのものを良くしたいのか、レビュー、監視、社内ナレッジのような業務文脈をAIに渡したいのかで、選ぶ場所が変わります。
私はこの切り分けを先に持っておくと、AI拡張を入れては戻す往復がほぼ消えました。
Cursor標準で進め、詰まった機能だけ後付けするほうが、環境が静かなまま育っていきます。
『Cursor Marketplaceの発表』

Extend Cursor with plugins · Cursor

Discover and install pre-built capabilities on the Cursor Marketplace.

www.cursor.com