Cursor 使い方入門｜インストールから最初の1変更

CursorはVS Codeに慣れた人ほど入りやすいAIコードエディタで、初回起動でImport VS Code Settingsを選ぶと、テーマやキーバインドの感触がそのまま残り、最初の違和感がぐっと薄れます。
この記事は、AIエディタを試したいけれどChatAgentTabComposerの違いで立ち止まりがちな初心者に向けて、迷わず触り始めるための道筋をまとめたものです。

進める到達点は明確で、インストールしてサインインし、既存または新規プロジェクトを開き、AIに“小さな1変更”を頼んで、差分を見て適用するところまでです。
Quickstart | Cursor Docsが案内する基本の流れに沿いつつ、最初は相談ならChat、実際の編集はComposer、広い作業の自走はAgentという安全な使い分けで進めます。

導入直後の精度ブレを減らすために、Rules | Cursor Docsの基本設定とコードベース索引も最初の30分で1回試します。
料金は確認日時点でクレジット方式になっており、Cursor Pricingで個人向けProが月額20ドルなので、無駄な消費を避けるコツまで含めて、Windsurfとの違いを中立に整理しながら、あなたの用途で迷わない実践手順を案内します。

Cursorとは何か｜初心者が最初に知るべきこと

Cursorはひとことで言うと、VS Codeを土台にしながら、AIとの相談、コード生成、編集提案、実行補助までを同じ画面の中にまとめたAIコードエディタです。
単なる「補完が強いエディタ」ではなく、開発中に出てくる「この関数を説明してほしい」「このバグの原因候補を絞りたい」「関連ファイルも含めて直したい」といった流れを、エディタの外に出ずに進められるのが核になっています。

実際に触ると、その特徴は見た目の段階で伝わります。
VS Codeに慣れている人なら、見慣れたUIのまま左側にChatやAgentのパネルが現れ、「新しい道具を覚える」というより「いつものエディタに相談役が増えた」という感覚で入りやすいはずです。
私も最初はその印象が強く、機能の多さより先に、迷わず一つ試せることが入口のハードルを下げていると感じました。

VS Codeからの主な違い

CursorとVS Codeの差は、AI機能が「拡張機能として足されている」のではなく、編集体験の中心に組み込まれている点にあります。
VS CodeでもGitHub Copilotや各種チャット拡張を組み合わせれば近いことはできますが、相談、提案、差分確認、複数ファイル編集までの流れがどうしても分散しがちです。
Cursorはその分散を減らし、「質問した結果をそのまま編集に接続する」設計に寄せています。

この違いは、普段の作業でじわじわ効いてきます。
たとえば既存コードの一部を直したいとき、VS Code中心の構成ではチャットツールで説明を受け、対象ファイルを自分で開き、必要なら別の拡張で補完を受けるという往復が起きます。
Cursorでは、会話の流れからそのまま差分提案に進み、どこを変えるかを確認して適用できます。
インストールしてサインインしたあと、コードベースを説明させて、小さな変更を依頼し、結果を確認する流れが案内されています。

もうひとつの差は、コードベース全体を前提に答えられることです。
Cursorにはコードベース索引があり、ファイル単位の埋め込みと検索で関連箇所を拾いながら回答や提案を組み立てます。
マージ済みPRの履歴検索にも対応しており、単発の補完より「このリポジトリの文脈を踏まえた返答」に寄っていることがわかります。
規模が大きいコードベースほど、この差は見えやすくなります。

VS Codeユーザーにとっての救いは、移行コストが低いことです。
操作感の土台は近く、設定やキーバインドの感触も引き継ぎやすいので、学び直しより「AIをどう使い分けるか」を覚えることに集中できます。
新しいIDEへ乗り換えるというより、VS Code系の延長線上で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

できることの全体像

Cursorでできることを整理すると、まず相談系のタスクがあります。
関数やクラスの要約、処理の流れの説明、設計レビュー、命名の相談、テスト不足の洗い出しといった場面では、コードを貼り付け直さなくてもエディタ内の文脈を使って会話できます。
「このファイルの責務は何か」「この実装で密結合になっている箇所はどこか」といった問いに、その場で答えを返せるのが出発点です。

次に、修正系のタスクがあります。
小さな変更の提案、既存スタイルに合わせたリファクタ、バグ原因の絞り込み、複数ファイルをまたぐ修正案の提示などです。
ここで効くのが、単に新規コードを生成する能力だけではありません。
既存コードに対して「今ある構造を壊さず、必要な差分だけ出す」方向へ寄せられることに価値があります。
実務ではゼロから書く場面より、既存コードへ安全に手を入れる場面のほうが多いので、この違いは大きいです。

さらに、自律実行寄りの作業も守備範囲に入ります。
Agentは広めの依頼を受けて関連箇所を調べ、編集や必要なコマンド実行の補助まで進める役割を持ちます。
公式説明ではターミナル利用や PR レビュー、外部連携が例示されており、背景処理や文脈共有の強化を通じて編集支援の幅が広がる傾向が見られます。
この全体像を支える土台がRulesとコードベース索引です。
Rulesは永続的な指示で、プロジェクトの命名規則、禁止事項、回答方針、テスト方針などを持たせるための仕組みです。
プロジェクト単位のルールを.cursor/rulesで管理できるため、毎回同じ前提を説明し直さずに済みます。
索引とルールが揃うと、AIは「その場の質問に答える」だけでなく、「このリポジトリらしい答えを返す」方向へ近づきます。

用語の整理：Chat/Composer/Agent/Tab

初心者が最初につまずきやすいのは、機能名が似て見えることです。
整理すると、Chatは相談窓口です。
コードの意味を聞く、設計の方針を相談する、エラーの読み方を確認する、といった「まず言葉で考えたい」場面に向きます。
まだ編集を走らせたくない段階で使うと、意図と前提を整えやすくなります。

Composerは、会話を編集提案につなげるための中心機能です。
ここでは「このコンポーネントを分割して」「この関数を型安全に書き換えて」のように、具体的な変更を依頼して差分候補を受け取る使い方が基本になります。
相談より一歩進んで、実際にコードへ触るための場です。

Agentは、もっと広い作業単位を任せるときの入口です。
関連ファイルをまたいで見に行き、必要な変更を考え、コマンド実行も絡めながら進めるため、「何をどう直すかを一緒に探る」より「この目的に向けて作業を進める」に近いモードです。
調査、編集、確認の幅が広がるぶん、最初は小さな依頼から使うと役割の違いがつかみやすくなります。

Tabは最も日常的なAI機能で、インライン補完を担います。
1行先、数行先、あるいは今書いている文脈の続きを読んで提案するので、体感としては「会話するAI」ではなく「先回りしてくれる補完」に近い存在です。
ChatやComposerのように明示的な依頼を出さなくても、普段のタイピング中に最も多く触れる機能になりやすい部分です。

この4つをひとまず「相談はChat、編集提案はComposer、広い作業はAgent、入力中の補完はTab」と覚えておくと、初回の混乱が減ります。
名称だけ見ると多機能に感じますが、実際の役割はきれいに分かれています。
Cursorの理解は、AIが何でもしてくれると捉えるより、相談・提案・実行補助・補完の4レイヤーが一つのエディタに統合されていると捉えると、ぐっと掴みやすくなります。

始める前の準備｜必要なものと料金プランの考え方

対応OSと必要なもの

Cursorを始める前に見ておきたい前提は、対応OSと最低限そろえておくものです。
対応OSの最新情報はCursor公式のダウンロードページで確認する形になりますが、導入の考え方としてはVS Codeを普段使っているmacOSWindowsLinux環境なら入りやすい部類です。
Cursor自体がVS Codeベースなので、画面構成やキーバインドの感触が大きく変わりにくく、既存の開発習慣をそのまま持ち込みやすいんですよね。

準備物としては、まず安定したネット接続が前提になります。
AIチャット、コード補完、コードベース索引はローカル完結ではなく、オンライン前提で動く場面があるためです。
加えて、ソースコードを触るならGitも入っていると流れが整います。
必須とは言い切りませんが、変更前後の差分確認やコミットまでそのままつなげられるので、AIの提案を鵜呑みにせず一度レビューしてから反映する運用に自然に乗せられます。
実際に使ってみると、AIに1か所直してもらってGitの差分で確認するだけでも安心感がまるで違います。

もう1つ押さえたいのが、最初から大きなリポジトリ全部で試さなくてもよいという点です。
インストール後はいきなり。
最初の準備として必要なのは、高度な周辺ツール一式というより、小さな変更を差分で確認できる開発環境です。

アカウントと設定移行の前提

初回起動ではサインインが必要です。
ログイン方法の細かいUI表記は時期で変わることがありますが、考え方としては、アカウントを作成してサインインしないとCursorのAI機能を本格的に使い始められません。
ここはインストールだけで完結するローカルエディタとは少し感覚が違う部分です。

既存のVS Code環境から移れるかどうかは、多くの人が最初に気にするところですが、この点はCursorの強みが出やすいのが利点です。
前述の通りVS Codeベースなので、テーマやキーバインド、普段の操作感を近づけた状態で入りやすく、初回セットアップや後続の設定で既存設定をインポートできる流れが用意されています。
インポートのUI名称やどこまで自動反映されるかはその時点の公式画面に従う形ですが、主要な設定（テーマやキーバインド、基本操作）は引き継げるため、いちから全てを学び直す必要はありません。

ただし、設定移行はできる範囲があるという受け止め方が合っています。
見た目や操作系の違和感は減らせても、AI機能そのものの使い方までは自動で身につきません。
たとえばCursor独自のChatComposerAgentの役割分担や、Rulesによる永続指示は後から少しずつ整える部分です。
Rules | Cursor Docsにある通り、プロジェクト単位のルールは .cursor/rules で管理できます。
つまり、エディタ設定は移しつつ、AIへの指示方針は新しく作る、という二段構えで考えると整理できます。

実際、VS Codeから入る人はエディタ操作で迷うより、「どの範囲をAIに渡すか」で戸惑うことが多いです。
設定移行が済んでいると最初の違和感が減るので、AIへの依頼内容そのものに意識を向けやすくなります。
導入直後に疲れにくいのは、この差が大きいと感じています。

Rules ｜ Cursor Docs

Configure persistent instructions with Project, Team, and User Rules, plus AGENTS.md. Learn best practices for effective

cursor.com

料金とクレジットの基本

料金面では、まず個人利用の中心になるのがHobbyとProです。
Cursor Pricingの現行表示が最優先ですが、個人向けProが $20/月 という情報は広く一致しています。
無料で触り始めるならHobby、日常的に使っていくならPro、という見方でだいたいの判断はできます。
なお、ここでの料金認識は2026年3月時点の整理です。

気をつけたいのは、料金の見え方が「月額固定で使い放題」ではなく、クレジットベース課金の考え方が入ってくることです。
2025年以降はクレジット方式への移行が進んでいます。
月額プランだけ見ていると安心しがちですが、実際の利用感は「どのモデルを使うか」「どれだけ長い文脈を投げるか」で変わります。

クレジット消費が増えやすい場面はイメージしておくとつまずきにくくなります。
代表的なのは、高性能モデルを選ぶとき、長いコードや大量の関連ファイルを一度に読ませるとき、複数ファイルにまたがる大きめの編集を何度もやり直すときです。
コードベース索引そのものは便利ですが、広い文脈を毎回フルで使う依頼ばかりにすると、気づかないうちに消費が積み上がります。

初心者なら、最初はAuto系のモデル選択を中心に回すのが無難です。
モデルごとの得意不得意をまだつかめていない段階で、毎回高性能モデルを固定すると、費用対効果の判断が難しくなります。
まずはAuto中心で日常の小変更、説明、軽い修正に使い、どの作業で物足りなさが出るのかを見てからProや個別モデル運用を考えるほうが、失敗が少ないです。
特に導入初期は、長文の設計相談や大規模編集を一気に投げるより、関数単位・ファイル単位で区切った依頼のほうが結果も読みやすくなります。

Cursor · Pricing

Choose the plan that's right for you

cursor.com

無駄な課金を避けるコツ

クレジット制でいちばん効くのは、依頼の出し方を細かくすることです。
たとえば「このリポジトリ全体をリファクタして」ではなく、「auth.ts のこの関数だけ責務分割して」「このエラーの原因候補を3つに絞って」のように対象を限定すると、AIが参照する文脈も返答の長さも絞られます。
筆者の体感では、依頼をファイルや関数単位に絞るだけで、無駄なトークン消費が目に見えて減りやすいのが利点です。
しかも、差分レビューまで含めるとこの運用のほうが失敗も少なくなります。

コードベース索引の対象を広げすぎない発想も役立ちます。
今触っていない生成物や巨大なログ、参照不要のディレクトリまで文脈候補に入っていると、AIが拾う情報量が増え、必要のない読み込みにつながります。
Codebase Indexing | Cursor Docsで示されているように、Cursorはコードベース理解を前提に動くので、プロジェクトの中で「今は見なくてよい場所」を整理しておくと、応答の焦点も合いやすくなります。

ストリーミングで長文回答を何度も出させる使い方や、同じ依頼を少し文面を変えて繰り返す運用も、消費が積み上がりやすい部分です。
説明が欲しいときは「要点を3つで」「差分だけ示して」のように出力形式を狭めると、読み返しの負担も減ります。
再試行を増やすより、最初の依頼で対象とゴールを明確にしたほうが、結果として安く収まる場面が多いです。

無料で試すか、有料にするかで迷っている段階なら、Hobbyで日常の小変更がどこまで回るかを見るのが自然です。
そのうえで、「毎日のように使う」「複数ファイル編集や長めの相談が増えてきた」というタイミングでProを検討する流れが合っています。
最初から月額だけで判断するより、自分の依頼の粒度とクレジット消費の相性を見るほうが、納得感のある選び方になります。

Cursor Docs

Cursor is the best way to build software with AI.

docs.cursor.com

Cursorのインストール手順

公式からダウンロード

導入はCursorの公式サイトから始めます。
ダウンロードは公式のダウンロード/Quickstartページから、使用中のOSに合わせて入手してください（公式ページの案内に従うのが確実です）。
配布形式（.dmg/.exe など）は配布時点で変わることがあるため、拡張子で断定せず「OSに応じた公式インストーラを取得する」と案内するのが安全です。
Linux はディストリビューションごとの手順に従ってください。

インストール後はCursorを起動し、画面の案内に従ってサインインします。
macOS でダウンロード直後に表示される OS 側のセキュリティ確認（Gatekeeper）や、Windows のセットアップ/起動時に出るユーザーアカウント制御（UAC）は OS 側の一般的な挙動です。
詳細はそれぞれの公式説明も参照してください（Apple Gatekeeper: UAC: インストール後はCursorを起動し、画面の案内に従ってサインインしてください。
初回の設定オプション（例: VS Code 設定のインポート）が表示されることがありますが、表示文言や取り込まれる設定の範囲はバージョンや配布チャネルで変わる可能性があります。
必要な項目だけ取り込み、拡張機能の自動インストールなど詳しい挙動は公式ドキュメントで確認してください。

サインインと設定移行が済んだら、既存のプロジェクトフォルダを開きます。
試しに触る段階でも、空のエディタより、ふだん使っているリポジトリか小さめのサンプルを開いたほうがCursorの強みが見えやすくなります。

フォルダを開いたあとに見ておきたいのは、チャットパネルやComposerに相当するAIパネルが表示できることです。
エディタの横やサイドバーからAI関連のUIを開ければ、単なるコードエディタとしてではなく、コードベースを参照しながら対話できる状態まで進んでいます。
Cursor 2.0 と Composer のご紹介で示されているとおり、Composerは対話しながら編集までつなげる前提のUIなので、ここが見えていると導入後の流れをつかみやすくなります。

既存フォルダを開いたら、まずは短い問いかけを1つ試すと状態を確認しやすくなります。
たとえば「このプロジェクトのエントリーポイントはどこか」「認証処理はどのファイルにあるか」といった質問です。
コードベースを参照した返答が得られれば、インストール直後の基本的な導線が確認できます。

Cursor 2.0 と Composer のご紹介 · Cursor

どちらもエージェントとの連携に特化して設計された、新しいインターフェースと初のコーディングモデル。

cursor.com

完了チェックリスト

導入が終わったかどうかは、次の3点で見分けると迷いません。

コードベースを説明してもらう

最初の5分で目指したいのは、立派な機能追加ではありません。
まずはCursorに今開いているリポジトリを読ませて、こちらが内容を把握しきれていないコードベースでも会話が成立する感覚をつかむことです。

ここで効くのが、質問をふわっと投げないことです。
初心者ほど「このアプリって何をしているの？」と聞きたくなりますが、それだと返答も広がりすぎます。
最初は、構造の要約と入口の特定に絞ったほうが、次の修正依頼につながります。
たとえば次のように聞くと、返答の粒度が安定します。

リポジトリの構造と主要なエントリポイント、重要フォルダおよび主な依存関係を要約します。

この一文で、フォルダ構成、起点ファイル、主要ライブラリまで一度に確認できます。
React系なら src や pages、components、サーバー系なら server や routes、controllers のような位置づけが見えてきますし、package.json や設定ファイルに触れてくれれば、そのプロジェクトが何で動いているかも把握できます。
手で全部たどるより先に見取り図を出してもらうだけで、どのファイルに触るべきかの勘がつきます。

初回からコントロール感を保ちたいなら、ここでも範囲を切る言い方が役立ちます。
私は最初のやり取りで「まず主要ファイルだけ」「実装変更はまだしないで説明だけ」と添えることがあります。
これだけで、いきなり編集モードに入らず、地図を見てから動く流れを作れます。

小さな修正を依頼する

コードベースの概要がつかめたら、次は1つだけ変更を頼みます。
ポイントは、成果が目に見えて、失敗しても痛くない修正にすることです。
初回から複数ファイルにまたがるリファクタや設計変更を投げると、提案の良し悪しより「追い切れない」という感覚が先に来ます。

向いているのは、UIテキスト1行の変更、関数の引数名の統一、READMEへの1項目追記といった小さな仕事です。
しかも、対象ファイルを明示したほうが話が速くなります。
たとえばこんな依頼です。

「src/components/Header.tsx の見出しテキストを Welcome から Welcome back に変更してください。
この1ファイルだけを変更してください」

「src/utils/formatDate.ts の関数引数 d を date に統一してください。
呼び出し側は変えず、このファイル内で完結する範囲にしてください」

「README.md に 開発環境の起動方法 の項目を1つ追記してください。既存の構成は崩さず、追記だけにしてください」

このように、ファイル名、変更内容、変更範囲を1回で伝えると、出てくる提案の質が上がります。
初回に「この1ファイルだけを変更して」と区切ると、AIに任せながらもハンドルを握っている感覚が残ります。
ここがあると、便利さより先に不安が来る状態を避けやすくなります。

差分をレビューして適用する

修正依頼の次は、すぐ適用せず差分を見る段階を挟みます。
ここで「diffを先に見せて」と伝えるだけで、初回の体験がぐっと安定します。
提案を文章で読むより、どの行が消えてどの行が足されたかを見るほうが、意図とのズレを発見しやすいからです。

確認したいのは、まず削除が想定外に広がっていないか、関係ない行まで触っていないか、名前変更のつもりが副作用を生んでいないかの3点です。
UI文言の変更なら、1行だけ差し替わっているかを見る。
README追記なら、既存の節が勝手に書き換わっていないかを見る。
引数名の統一なら、その関数の意味まで変わっていないかを見る。
この視点だけでも、初回のレビューとしては十分機能します。

もし意図と違っていたら、やり直しも短く具体的に返せます。
「この削除は不要です」「テキスト変更だけにしてください」「README.md 以外は触らないでください」と差分コメントで戻す形です。
ここで曖昧に「ちょっと違います」と返すより、どの行が違うかを前提に言い直したほうが、次の提案が締まります。
コードを書く前より、差分を見ながら会話するほうが、AIとの共同編集に近い感覚になります。

Gitで安全を確保する

差分に納得したら適用し、その直後にGitで区切りを作ります。
小さな変更でもコミットしておくと、次に別の提案を試すときの心理的な重さが減ります。
戻せる状態が見えているだけで、AIに任せる範囲を少しずつ広げやすくなるからです。

コミットメッセージは凝る必要はなく、意味が追える形なら十分です。
たとえば feat: update header welcome text、refactor: rename formatDate argument、docs: add local setup step to README のように、変更の種類と内容が読める形にしておくと履歴が散らかりません。
1回のコミットに1つの意図を入れると、後で見返したときにも判断が早くなります。

Cursorでの初回編集は、派手な成果より「説明してもらう」「1つだけ直してもらう」「差分を見る」「Gitに残す」という小さな一周が価値になります。
この流れを一度通るだけで、読んだだけで終わらず、実際に触って戻せるところまで進めた感触が残ります。

基本機能の使い方｜Chat・Agent・Tabの違い

Chatの役割と具体シーン

Cursorで最初に軸にすると迷いにくいのがChatです。
ここはコードをいきなり書き換えてもらう場所というより、状況を整理して、判断材料を増やす場として使うと噛み合います。
たとえば「この実装を説明して」「根拠は？」「この差分の影響は？」「この設計と別案の違いは？」のように、会話で詰めたいテーマと相性がいいです。

初心者が混同しやすいのは、AIに頼むことを全部ひとつの窓で済ませようとする点です。
ただ、設計相談とコード編集を同時に始めると、まだ方針が固まっていないのに修正案だけ先に増えていきます。
Chatはその手前で立ち止まるための場所だと捉えると、役割がはっきりします。
質問して、説明を引き出して、比較軸をそろえてから次の操作に移る流れです。

私自身、バグ調査ではいきなり修正に入るより、Chatに「疑わしい箇所と理由を3件」と投げ、返答の確度や説明の筋を比較してから、Tabで局所修正を受けるか、Composerでまとまった提案を出してもらうかを決めることが多いです。
こうすると不要に関係ない場所まで触られる回数が減ります。

インストール後はいきなり大きな変更に進むのではなく、コードベースを理解して小さな変更から始める流れが示されています。
実際、この順番はChatの使いどころとも一致します。
まず理解し、そのあと編集するほうが、提案の良し悪しを自分で判定しやすくなります。

Agentでできることと安全な使い方

AgentはChatより一段踏み込んだ役割を持っています。
説明や相談だけでなく、自律的な編集やコマンド実行を伴う作業に向いています。
複数ファイルの修正、関連箇所の探索、手順の実行までをひとまとまりで進められるので、単発の質問より「作業そのもの」を任せたい場面で存在感が出ます。

ただし、初心者のうちはAgentを「全部自動でやってくれる便利ボタン」と見ないほうが流れが安定します。
Agent Overview | Cursor Docsが前提にしている通り、許可を伴いながら進む仕組みなので、最初は都度確認の感覚で付き合うのが合っています。
どのファイルを触るのか、どのコマンドを実行するのか、その都度見ながら進めるだけでもコントロール感が残ります。

向いているのは、たとえば「このエラーに関連しそうなファイルを探し、修正案まで出す」「テストを回して失敗箇所を確認し、直せる範囲を提案する」「命名の揺れを複数ファイルでそろえる」といった、手数が多い仕事です。
逆に、1行の文言変更や今書いている関数の続きを補うだけなら、Agentまで出さずにTabやChatで済むことが多いです。

ここで大切なのは、任せる粒度を急に大きくしないことです。
最初から「アプリ全体を整理して」と渡すより、「このディレクトリ内だけ」「修正前に差分案を見せる」「コマンド実行は確認後に進める」と区切ったほうが、AIの働きが読み取りやすくなります。
Agentは強力ですが、強い機能ほど範囲指定の言葉が効きます。

Overview ｜ Cursor Docs

Assistant for autonomous coding tasks, terminal commands, and code editing

cursor.com

Tab補完のコツ

Tabは会話の窓ではなく、カーソル直下で受け取るインライン補完です。
今書いている関数、直前の命名、周囲のコードの流れを踏まえて、小さな続きや書き換え候補をすばやく差し出してくれます。
役割としては「相談」ではなく「補完」です。
ここを分けて考えるだけで、使い分けが一気に見えます。

相性がいいのは、既存コードの延長線上にある小規模な編集です。
if文の続きを埋める、似たパターンのバリデーションを足す、型注釈を補う、すでにある関数に合わせて1ブロック分だけ書き進める、といった場面ではTabの速さがそのまま効きます。
反対に、設計の是非を考えたいときや、複数案を比較したいときはChatのほうが向いています。

うまく使うコツは、AIに全部を書かせるより、先頭の意図を人間が少し置くことです。
関数名、引数名、コメント、途中までの条件分岐があるだけで、補完の方向がそろいます。
空白の状態から長い補完を待つより、1行目を自分で決めて次を受け取るほうが、提案のズレが目立ちにくくなります。

もうひとつ効くのが、既存ファイルの文体や命名を崩さない位置で使うことです。
Tabは周囲の流れに寄せた提案が得意なので、新しい設計を持ち込むより、すでにある書き方に沿って書き足す場面で力を出します。
小さな編集を刻みながら前に進める感覚は、ChatやAgentとは別物です。

Composerの位置づけと速度感

ComposerはChatとAgentの中間というより、複数ファイルにまたがる生成やリライト提案の拠点として見ると整理しやすくなります。
1ファイルのその場補完はTab、方針の会話はChat、繰り返し実行や自律的な操作はAgent、そのあいだで「まとまった変更案を組み立てる場所」がComposerです。

たとえば、新しい機能に必要なファイル群を一式たたき台として出したいとき、既存の複数コンポーネントを横断して命名や責務をそろえたいとき、ある仕様変更に合わせて関連ファイルをまとめて見直したいときに収まりがいいです。
1行ずつ補完を重ねるには範囲が広く、かといって人の確認や微調整が不要になるほど自律的に実行する用途でもない、その中間の仕事に向いています。

実際、何度も案を出し直す場面では、この待ち時間の短さが効きます。
以前なら1回ごとに流れが止まりがちだった作業でも、返答が短時間で戻ると、設計の修正とコード提案の往復を切らさず進めやすくなります。
体感としては、1ターンごとの待機が薄くなることで、思考が途切れにくくなります。

使い分けの初期指針を一文で置くなら、設計や方針はChat、小さな編集はTab、複数ファイルやまとまった生成はComposer、繰り返しや下準備の自動化はAgentという並びです。
この順番で考えると、どの機能を開くべきかで止まりにくくなります。
初心者のうちは、役割を重ねて覚えるより、まずは「話す場所」「補完を受ける場所」「まとめて作る場所」「作業を進める場所」と分けて捉えると、日々の操作に落とし込みやすくなります。

精度を上げる設定｜Rulesとコードベース索引の基本

Rulesの基本

Cursorの提案精度を最初の段階で整えるなら、まず触っておきたいのがRulesです。
Cursor DocsのRulesで説明されている通り、これはプロジェクトやワークスペース単位で永続的な前提を与える仕組みです。
毎回プロンプトに「このリポジトリはTypeScriptです」「UI文言は敬体です」「関数名は動詞から始めます」と書き直さなくても、土台のルールとして持たせておけます。
Cursorで提案のぶれを抑えたい場合、まずRulesに触れておくのが有効です。
Rules はプロジェクト固有の前提を永続化し、命名規則や文体、禁止事項などを共有する用途に向きます。
効くのは、単発の便利さより提案の揺れを減らすことです。
AIはその場の文脈だけでも動きますが、前提が薄いと、同じプロジェクト内でも命名や文体が少しずつぶれます。
実際に、Rulesへ「UI文言は敬体」「関数名は動詞始まり」と書いておくだけで、初回の提案から迷い方が変わります。
ボタン文言で「保存する」と「保存」の揺れが減り、関数名も processData のような動詞始まりへ寄っていくので、あとで整える手間が目に見えて減ります。

書いておくと効果が出やすいのは、命名規則、テスト方針、禁止事項の3種類です。
たとえば「ReactコンポーネントはPascalCase」「新規ロジック追加時はテストも更新」「any の使用は禁止」といった内容です。
人間同士のチーム開発でもREADMEやContributingに置くような前提を、そのままAIにも共有するイメージだと捉えやすいのが利点です。

Project Rulesの作り方と例

プロジェクト単位のルールは、Docs準拠では .cursor/rules に置きます。
リポジトリの中にこのディレクトリを作り、ルールファイルとして管理していく形です。
UIから作る場合はNew Cursor Ruleで新規追加でき、ファイルとして直接作る方法ならGit管理にも載せやすくなります。
チームで同じ前提を共有したいなら、後者のほうが運用に乗せやすい場面が多いです。

ここで押さえておきたいのは、Rulesには適用範囲の考え方があることです。
全体に効かせるルールもあれば、特定のディレクトリや作業文脈に寄せたルールもあります。
たとえばフロントエンド配下だけUI文言の基準を厳密にし、バックエンド配下ではAPI命名や例外処理の方針を強める、という分け方です。
1枚の巨大なルールに全部を書き込むより、対象ごとに分けたほうが保守しやすく、AI側も読み取りやすくなります。

最初は、次の3点だけを短く定義すると収まりがいいです。

1. 言語・フレームワーク

例として「このプロジェクトはTypeScriptとReactを使う。新規コードは既存構成に合わせ、関数コンポーネントを優先する」と置きます。

1. コーディング規約

例として「フォーマットはPrettier設定に従う。
既存のインデント、クォート、セミコロン方針を崩さない」と書いておくと、整形まわりの無駄な差分が減ります。
Prettier自体の細かな仕様はここで説明しませんが、プロジェクト側に設定があるなら、それを基準にするとぶれません。

1. コミットメッセージ形式

例として「コミットメッセージは feat: fix: refactor: を先頭につけ、要点を短く書く」と定めておくと、変更提案からコミット文面まで流れがそろいます。
文章量は長くなくて構いません。
むしろ、最初は数行で済む粒度のほうが扱いやすいのが利点です。
抽象的な理念を並べるより、「何を優先し、何を避けるか」を短文で切るほうが、実際の提案に反映されます。

Indexingと除外の考え方

もうひとつ、精度の土台として効くのがCodebase Indexingです。
Cursor DocsのCodebase Indexingで案内されている通り、リポジトリ全体を埋め込み・検索できる状態にして、回答や提案にそのリポジトリ固有の文脈を使えるようにする仕組みです。
単に今開いているファイルだけで答えるのではなく、関連する型定義、既存のユーティリティ、似た実装、過去の命名パターンまで拾いやすくなります。

この差は、少し大きめのコードベースでよく出ます。
手で関連ファイルを追うと数分かかる場面でも、索引が効いていると、どのファイルを参照して回答したのかがたどりやすくなります。
既存のHook名やサービス層の責務を踏まえた提案が返ると、単なる一般論のコード補完ではなく、今のプロジェクト向けの返答になります。
PR履歴の検索も活用できるため、過去に行われた例外処理の修正内容や、似た変更がどのPRで行われたかまで追跡できます。

一方で、何でも索引に入れればよいわけではありません。
生成物、ベンダーファイル、巨大ログのように、検索ノイズになりやすいものは除外するほうが文脈の質が上がります。
典型例は dist や build の成果物、依存パッケージが入る node_modules、自動生成されたSDK、長いログファイル、圧縮済みアセットのような中身を読む必要が薄いものです。
こうしたファイルが混ざると、意味のある実装コードよりノイズが目立ち、検索結果の筋が鈍ります。

除外は万能のテンプレートをそのまま当てるより、実際のファイル構成に合わせて決めるのが筋です。
たとえばAPIクライアントが自動生成でも、その生成コードを日常的に参照して修正方針を決めるチームなら、全部外すと逆に不便です。
反対に、毎回ビルドし直される成果物や解析対象にならないログは、最初から外しておいたほうが検索の純度が上がります。
索引の役割は「たくさん読むこと」ではなく、「必要な文脈へ素早く届くこと」なので、量より中身を整える発想のほうが結果につながります。

初心者向けの実践プロンプト例3選

最初のうちは、毎回ゼロから頼み方を考えるより、用途ごとに「型」を持っておくほうが詰まりません。
実際の運用でも「何を見て、どの形式で返してほしいか」を先に固定すると、返答の質が安定します。
とくに対象ファイルを限定し、出力形式を diff や表で指定すると、初回の提案から確認ポイントが絞られ、レビューの往復が目に見えて減ります。

コード説明プロンプト

既存コードを読む場面では、「このリポジトリは何でできていて、どこから見ればよいか」を短く整理してもらうのが入口になります。
ここで曖昧に「このコードを説明して」と投げると、表層的な説明で終わりがちです。
代わりに、リポジトリ構造、重要ファイル、データフロー、主要依存の4点を明示すると、読む順番まで見えます。

さらに効くのが、制約を一緒に書くことです。
たとえば「200字以内で」「表形式で」「初心者向けに専門用語を減らして」と指定しておくと、情報量の暴走を抑えられます。
私は初回から表形式を指定することが多く、対象ファイルも絞っておくと、レビュー時に「どの説明がどのファイルに対応するか」がすぐ追えます。

コピペ用の雛形は次の形です。

このプロジェクトの理解を手伝ってください。
対象ファイルは次に限定します。

- src/app.ts
- src/routes/user.ts
- src/services/userService.ts
- package.json

知りたいことは次の4点です。

- リポジトリ内での役割
- 重要ファイルとその責務
- リクエストからレスポンスまでのデータフロー
- 主要な依存関係と、それぞれを使っている理由

出力条件:

- 初心者向けに要約する
- 表形式で返す
- 1項目ごとの説明は短く

この型は、新しいリポジトリに入った直後だけでなく、久しぶりに触る機能の再把握にも向いています。説明の粒度を一定にできるので、読解の起点が毎回ぶれません。

### バグ調査プロンプト

バグ調査で空振りしやすいのは、症状だけを渡して原因推定を丸投げするときです。AIにとっても、再現手順やログがないままでは探索範囲が広すぎます。ここは人間が持っている観測情報を箇条書きで渡したほうが、切り分けの精度が上がります。

入れておきたいのは、症状、再現手順、関連ログ、怪しい関数名の4つです。これだけで、単なる一般論ではなく、プロジェクト内の具体的な候補に寄った返答になります。そのうえで「疑わしい箇所3つ＋理由＋調査手順」で返すよう指定すると、原因候補の比較がしやすく、次にどこを見るべきかが明確になります。

次のバグを調査してください。 対象ファイルは次に限定します。

• src/api/auth.ts
• src/hooks/useSession.ts
• src/pages/LoginPage.tsx

症状:

• ログイン直後に画面がリダイレクトせず、そのまま止まる

再現手順:

• ログイン画面を開く
• 正しいメールアドレスとパスワードを入力する
• 送信ボタンを押す
• APIは200を返すが、画面遷移しない

関連ログ:

• console: "session updated"
• network: は 200
• console: "cannot read property 'role' of undefined"

怪しい関数名:

• handleLogin
• updateSession
• redirectByRole

返答形式:

• 疑わしい箇所を3つ挙げる
• 各項目に理由を書く
• 各項目ごとに最初の調査手順を書く
• 修正コードはまだ書かず、まず切り分けに集中する

この頼み方だと、いきなり広い修正案に飛ばず、診断の順序を先に作れます。実務ではここで diff を要求しないのも手です。まず候補を狭め、次の往復で修正案に入ると、変更の根拠が追いやすくなります。

### 小機能追加プロンプト

小さな機能追加では、要件の箇条書きを先に整えるだけで結果が変わります。とくに抜けやすいのが、入出力、UIテキスト、エッジケースです。機能名だけ伝えると、見た目は動いても、空入力や読み込み中の扱い、文言の統一が後から漏れます。

要件を書くときは、対象ファイルを先に限定し、その範囲で差分プレビューを出してから適用する前提にすると進めやすいです。私はこの順番を固定していて、最初に diff を見せてもらう形にすると、変更箇所と影響範囲をその場で判断できます。対象ファイルの限定と diff 指定の2つを入れるだけで、初回レビューの負荷が一段下がる感覚があります。

次の小機能を追加してください。 対象ファイルは次に限定します。

• src/components/TodoInput.tsx
• src/pages/TodoPage.tsx

要件:

• 入力欄が空のときは追加ボタンを押せない
• Enterキーでも追加できる
• 追加成功後は入力欄を空に戻す
• UIテキストは「タスクを入力」「追加」を使う
• 空白だけの入力は無効にする
• 既存のスタイル方針は崩さない

作業手順:

1. まず差分プレビューを提示する
2. 変更内容の意図を短く説明する
3. その後で適用用コードを出す

返答形式:

• 最初に変更対象ファイルごとの diff を出す
• 次に確認ポイントを3つに絞って書く
• 追加の変更は行わず、指定ファイル内で完結させる

この型は、ボタン無効化、入力バリデーション、文言追加のような小さな改善と相性がよく、変更が広がりすぎません。要件を箇条書きで固め、対象ファイルと出力形式まで先回りして指定するだけで、AIへの依頼はだいぶ実務的になります。

## つまずきやすいポイントと対処法

### 意図と違う編集の抑え方

初心者が最初につまずきやすいのは、AIに頼んだつもりの範囲より広く編集が入ることです。とくにCursorのように複数ファイルをまたいで提案できる環境では、「ボタン文言だけ直したい」と思っていたのに、関連コンポーネントや型定義まで触りにいくことがあります。ここで効くのが、対象範囲を先に固定してから依頼する書き方です。ファイル名だけでなく、関数名や変更規模まで明示すると、意図と違う編集が混ざる率が下がります。

実際に私がいちばん効いたのは、「この関数内のみ、10行以内で」と最初に縛るやり方でした。これだけで過剰編集は目に見えて減ります。AIは曖昧な依頼だと“親切”に広げて直そうとするので、広げない条件を人間側で書いておくほうが噛み合います。対象ファイル、対象関数、変更してよい範囲、触ってほしくない箇所まで含めると、差分の確認も短時間で済みます。

加えて、いきなり適用まで進めず、都度許可の姿勢を崩さないことも効きます。まず差分を出してもらい、その差分単位で「この行はよいが、この命名は変えないでほしい」とコメントし、再提案してもらう流れです。最初から一発正解を狙うより、差分を小さく刻んで往復したほうが、結果として修正回数が減ります。最初は一度に1ファイルだけを原則にすると、レビューの視線もぶれません。

### クレジット消費の抑制策

課金体系がクレジット方式に移ってからは、使い方次第で消費の体感差が出やすくなりました。CursorのProは公式サイトで月額20ドルですが、実際の負担感はプラン名よりも、どのモデルに何を投げるかで変わります。軽い修正まで高性能モデルで連打すると、便利さより先に消費の速さが気になってきます。

普段の運用では、まずAuto model中心で回し、依頼を小さく保つのが堅実です。たとえば「ログイン画面を改善して」ではなく、「LoginPage.tsxのバリデーションだけ直す」に分ける。さらに、不要な文脈を削るのも効きます。関係ないログ全文、使っていないファイル一覧、長い背景説明まで毎回貼ると、読ませる量が増え、返答も長くなりがちです。依頼の単位を絞ると、AIの探索範囲が狭まり、再試行の回数も減ります。

体感としては、長文の往復を続けるより、短い指示で小さく進めたほうが消費も安定します。待ち時間が短いぶん、雑に何度も投げ直しやすくなるのですが、そこが消費の落とし穴です。普段は自動選択か軽めのモデル、設計変更や原因特定のように品質優先の場面だけ高性能モデルへ切り替える、と役割を分けたほうが無駄打ちが減ります。

> [!WARNING]
> 公式ブログの記述にある高速化は利用感を高めますが、待ち時間の短さが「無制限の多投」を正当化するわけではありません。使い方によっては消費が早まるため、モデル選択と依頼粒度は意識して運用してください。

### コード理解を深める下準備

コードベース理解が浅いまま話が進むと、もっともらしい提案なのに現場の構成と噛み合わない、という状態が起きます。ここではAIの性能以前に、読ませる土台を整えるほうが先です。まず見たいのはIndexingの状態で、索引が不十分なままだと、参照してほしいファイルに届かず、名前の似た別実装を前提に話し始めることがあります。

この段階で効くのが、巨大な生成物やログ、外部ライブラリを対象から外すことです。dist、build、coverage、長いログファイル、依存ライブラリの塊まで含めると、肝心のアプリ本体の文脈が埋もれます。AIにコードベースを理解させるというより、理解すべき部分を見えやすくする感覚です。索引対象が整理されると、関連ファイルの拾い方が落ち着いてきます。

もうひとつ効くのが、READMEや設計方針を短く要約してRulesに入れておくことです。たとえば「状態管理はZustand」「API呼び出しはservices配下に集約」「UI文言は日本語で統一」といった前提があるだけで、提案の方向が揃います。コードベース理解が浅いと感じる場面の多くは、AIが読めていないというより、判断基準を渡していないことが原因です。最初にその土台を置いておくと、小さい変更でもブレが減ります。

### Gitで守る最低限の安全策

AI編集を試すときにいちばん避けたいのは、戻したいのに戻れない状態です。そのため、最低限の安全策としてGitのブランチを先に切っておく流れは外せません。Git連携そのものはCursorでも扱いやすいですが、守っているかどうかで安心感がまるで変わります。元の状態が残っていれば、提案を強気に試しても壊れたまま詰まることがありません。

コミット粒度は細かいほうが向いています。ログイン文言修正、バリデーション追加、関数抽出を1つのコミットにまとめるより、変更の意味ごとに分けたほうが差分を追えます。AIが意図と違う編集を混ぜたときも、どこで逸れたかを切り分けやすくなります。まとめて戻すしかない状態だと、よかった変更まで捨てることになります。

初手は小さい変更から始める、という原則もGit運用と相性が良いです。一度に1ファイル、一度に1目的で進めれば、失敗しても影響範囲が狭く、レビューも短時間で終わります。AIに任せる量を増やすのは、その往復に慣れてからで十分です。最初から複数ファイルの横断リファクタに入るより、戻せる状態を保ったまま小さく成功体験を積むほうが、初期離脱を防ぎやすくなります。

## Cursorと他ツールの違い｜Windsurfとどう選ぶか

### 評価が分かれるポイント

CursorとWindsurfは、どちらもVS Code系の操作感を土台にしながら、AIとの付き合い方に違いがあります。選ぶときに評価が割れやすいのは、AIにどこまで主導してほしいかという一点です。自分で文脈を整理し、ルールを与え、差分を見ながら調整したい人はCursor寄りになります。反対に、まずは広めに文脈を拾ってもらい、迷う場面を減らしたい人はWindsurfのほうが合う、という見方があります。

Cursorの強みは、自由度と成熟度が噛み合っているところです。とくにRulesやコードベース索引の作り込みが効いてくると、単なる補完ツールではなく、チームやプロジェクトの流儀を反映した相棒に近づきます。筆者の印象でも、既存プロジェクトの既定の流儀をRulesに落とし込んでから使い込むほど、Cursorは真価が見えやすくなります。命名規則、レイヤー構成、どこまで変更してよいかといった判断基準を先に渡しておくと、提案のブレが目に見えて減ります。

一方のWindsurfは、自動化された文脈収集と、迷いにくいUIを評価する声があります。AI支援の入り口でつまずきやすいのは、「何をどこまで指定すればよいのか」が見えないことですが、その負担を軽くしたい人には相性がよい整理です。中立に見るなら、初心者には自動化重視のWindsurfが合う場合がある一方で、Cursorは自分の意図を細かく反映できる自由度と、継続利用で効いてくる成熟度が魅力です。

### 初心者が注目すべき違い

初学段階では、どちらが高機能かより、どちらの学び方が自分に合うかで見たほうが判断しやすくなります。まず任せたい人にはWindsurf派の声が一部にあります。文脈集めや提案の流れが自動化寄りなので、最初の一歩で手が止まりにくいからです。コード全体をまだ把握しきれていない段階では、「とりあえず動かしてみる」回数を増やせることが、そのまま学習量につながります。

反対に、Cursorは自分で舵を切りながらAIを使いたい人に向きます。どのファイルを見せるか、どこまで編集を許すか、どういう前提で答えてほしいかを少しずつ言語化していく必要がありますが、そのぶん開発の基礎体力がつきます。AIに丸投げするというより、AIを使って設計とレビューの感覚を身につける方向です。VS Codeに慣れている人ほど、この差は早い段階で体感しやすいはずです。

二案で切ると、初学期にCursorの自由度を使って基礎を固める道と、Windsurfの自動化で試行回数を増やす道があります。前者は「なぜこの変更になるのか」を追いやすく、後者は「まず動くものを見て理解する」流れに乗りやすい、という違いです。どちらが正解というより、学びたい対象がコードそのものなのか、AI支援込みの開発体験なのかで、向き先が変わります。

### 料金の目安と確認方法

費用感では、CursorのProが公式サイトで月額20ドルです。ここは比較の起点として押さえやすい数字です。[Cursor Pricing](https://cursor.com/pricing)を見ると、個人利用でまず比較されるのはこのレンジになります。

Windsurfは比較記事で月額15ドルという記載例がありますが、この項目は外部比較で見かける数字として扱うのが無難です。実際に並べると、月額20ドルのCursor Proに対して、Windsurfはやや抑えた価格帯として語られることが多いものの、判断材料としては金額そのものより、どちらに作業時間を預けたいかのほうが効いてきます。Cursorは2025年以降、クレジット方式の影響も見ながら使い分ける視点が必要になっているので、表面上の月額だけでは負担感を読み切れません。

> [!NOTE]
> 料金比較では月額だけでなく、日々の小修正をどのくらいAIに投げるかまで含めると、体感コストの差が見えやすくなります。
### VS Code + Copilotとの違い

VS CodeにCopilotを足す構成は、既存環境を大きく変えずに導入できるのが魅力です。普段からVS Code中心で開発している人にとっては、拡張として追加できる安心感があります。ただ、AIとのやり取りが補完、チャット、編集適用、関連ファイル探索のように分散しやすく、操作の流れが切れやすい場面もあります。

その点、Cursorは編集から提案の適用までを同一UIの中で回しやすいのが特徴です。AIに相談して、差分を見て、必要なら修正を頼み、そのままコードへ反映するまでの往復が一つの流れとしてつながります。Cursor 2.0の紹介ページでも、その方向性がはっきり見えます。

VS Code + Copilotが向くのは、今の環境を崩さずにAIを追加したいケースです。Cursorが向くのは、AI支援そのものをエディタ体験の中心に置きたいケースです。Windsurfはその中間というより、同じVS Code系でも、より自動化に寄せた別解として見ると整理しやすくなります。用途、好み、費用の3つで切ると、自分にとってどの摩擦が少ないかが見えます。

## まとめ｜初心者が次に試すべきこと

### 次のアクション5つ

最初にやることは、CursorのChatで方針だけ相談することです。いきなり編集を任せるより、「この関数の責務はどう分けるべきか」「どこを触るのが最小か」と聞いたほうが、コードの見方が先に身につきます。そこから1ファイルだけの小変更に進むと、差分の意味を追いやすくなります。実際、最初の段階で小さな修正が一度通ると、その“まず1勝”が効いて、その後のRulesやAgentの学習速度が一段上がります。

次は、プロジェクトの約束事を1つだけProject Rulesに足してください。たとえば命名規則や、変更してよい範囲のような、提案のぶれに直結するものから入れると効果が見えます。そのうえでAgentを小タスクで試し、ファイル追加や軽い置換のように結果を確認しやすい仕事を任せます。複数ファイル編集は、その流れで差分確認に慣れてからで十分です。

1. Chatで方針相談をする  
2. 1ファイルだけ小変更する  
3. Project Rulesを1つ追加する  
4. Agentを小タスクで試す  
5. 必要になったら複数ファイル編集へ進む

次に深掘りする場合は、まず公式ドキュメントや設定ガイドを参照してください。特にインストール/初期設定、Rules の書き方、Composer と Agent の使い方、料金表示の実際的意味合い（Models & Pricing）の各公式ページに目を通すと、手を動かしながら理解を深めやすくなります。なお、このサイトにはまだ関連記事がないため、[内部リンクではなく公式ドキュメントを優先して参照してください](https://cursor.com/docs、https://cursor.com/pricing)。
### 確認チェックリスト

学び方は広げるより、狭い範囲で短く試すほうが定着します。毎回、差分を見てから適用し、その区切りでGitコミットする流れを固定すると、失敗が学習コストに変わります。CursorでもWindsurfでも、最初に身につけるべきなのは派手な自動化ではなく、この往復の型です。

- 差分をレビューしてから適用した  
- 依頼は短く、変更範囲を狭く保った  
- 区切りごとにGitコミットした