Cursor入門ガイド｜初心者向けにCursorの基本から応用まで完全解説【2026年最新版】

Cursorとは

「Cursorって最近よく聞くけど、実際どう使えばいいの？」——この記事は、そんな疑問を持つ方に向けた完全ガイドです。

Cursorは、AIによるコード生成・編集・デバッグが組み込まれたコードエディタです。開発元はAnysphere社。
VS Codeという現在最も人気なエディタと、ほぼ同じ見た目・操作感でありながら、日本語で指示するだけでAIがコードを書いてくれるという体験を実現しています。

たとえば、チャット欄に「ユーザー登録ページを作って。メールアドレスの確認機能もつけて」と入力するだけで、AIが必要なファイルを作成し、コードを書いてくれます。コードを書くだけでなく、ターミナルでのコマンド実行、エラー調査と修正、テストの作成まで任せられます。GPT-4o・Claude・Geminiなど複数のAIモデルを切り替えて使える点も特徴です。

この記事で学べること

本記事では、Cursorのインストールから実践的な活用法までを一本の記事で体系的に解説します。

導入と基本操作——インストール、初期設定、AIとの対話方法、4つのモード（Agent / Ask / Plan / Debug）の使い分け
コード編集——Tab補完やブラウザ連携など、日常的に使うAI支援機能
カスタマイズ——Rules・Commands・Skills・MCPなど、AIの振る舞いを自分好みに調整する仕組み
CLI・自動化——ターミナルからのAI操作、GitHub Actionsとの組み合わせ
応用・チーム運用——Cloud Agents、Hooks、Plugins、Teamsプランでの組織導入

対象の読者（非エンジニアでも分かる入門書です）

Cursorはコードエディタなので、本記事の内容はソフトウェア開発を前提に構成しています。ただし、専門的なプログラミング知識がなくても読み進められるように書いています。

最近は、エンジニア以外の方がCursorを「AIが使えるメモ帳・作業環境」として日常業務に取り入れるケースも増えています。ドキュメント作成やデータ整理、ちょっとしたスクリプトの作成など、コードを書く仕事でなくてもCursorのAI機能は役に立ちます。そうした方にも無理なく読める内容になっていますので、安心して読み進めてください。

料金プラン

Cursorには複数の料金プランがあります（公式サイト）。

無料プラン

項目	利用可能量
プレミアムモデル	初期 2,000 リクエスト（GPT-4, Claude 3.5 Sonnet 等） ※ 登録時に1度だけ付与される枠。リセットされない
標準モデル	1日 2,000 リクエスト（Cursor Small, GPT-4o-mini 等）

無料プランのデメリットは次のとおりです。

高性能なモデルが使えない（プレミアムモデルの枠を使い切ると標準モデルのみ）
リクエスト数に上限がある

有料プラン

プラン	Pro	Pro Plus	Ultra
料金	$20/月	$60/月	$200/月

どのプランが向いているかは、利用頻度によって変わります。大まかな目安は以下のとおりです。

ライトユーザー: 無料 or $20（Pro）
エンジニアの普段使い: $60〜$100/月（Pro Plus）
パワーユーザー（並列実行・自動化）: $200以上（Ultra）

法人向けプラン

チーム向けプランは2種類あります。Teams（$40/ユーザー/月）と Enterprise（カスタム）です。

Teamsプランには次の追加機能が含まれます。

Privacy Modeの適用
利用統計付きの管理ダッシュボード
チームの請求の一元管理
SAML/OIDCによるSSO

法人アカウントの場合、自社で運用可能なお客様にはTeamsをおすすめします。優先サポート、使用量のプール、請求書払い、SCIM、または高度なセキュリティ制御が必要なお客様にはEnterpriseをおすすめします。

※ 料金は変更される場合があります。最新の料金は公式サイトで確認してください。

インストールと初期設定

Cursorを自分のPCにインストールし、すぐにコードを書き始められる状態にしましょう。VS Codeを使ったことがあれば、驚くほどスムーズに移行できます。

インストール

公式ダウンロードページから、自分のOSに合ったインストーラをダウンロードして実行します。macOS、Windows、Linuxに対応しています。

初回設定画面

Cursorを初めて起動すると、セットアップウィザードが表示されます。どの項目もあとから変更できるので、気軽に進めて問題ありません。

セットアップの流れ

アカウント作成 / ログイン 「Sign Up」または「Log In」を選択します。メールアドレス、Googleアカウント、GitHubアカウントのいずれかでサインアップできます。アカウントを作成すると、Proプランの全機能を試せる無料トライアルが始まります。
VS Code設定のインポート VS Codeを使っていた場合、拡張機能・テーマ・キーバインド・ユーザー設定をまとめてインポートできます。普段の環境をそのまま引き継げるので、インポートすることをおすすめします。
データ共有の確認 利用データの共有について確認が表示されます。この設定はあとからPrivacy Modeで細かく制御できるので、ここではそのまま進めます（詳しくはセクション2-5で解説します）。

日本語化の設定

CursorのUIを日本語にするには、「Japanese Language Pack for Visual Studio Code」という拡張機能をインストールします。VS Codeベースなので、VS Code用の言語パックがそのまま利用可能です。

拡張機能パネルを開く（Cmd+Shift+X / Ctrl+Shift+X）
検索バーに「Japanese Language Pack」と入力する
「Japanese Language Pack for Visual Studio Code」（発行者: Microsoft）の「Install」ボタンをクリックする
コマンドパレットを開く（Cmd+Shift+P / Ctrl+Shift+P）
「Configure Display Language」と入力して選択する
言語リストから「日本語（ja）」を選択する
再起動を促すダイアログが表示されるので「Restart」をクリックする

セキュリティ設定（Privacy Mode）

Cursorを使うと、自分のコードがクラウド上のAIモデルに送信されます。業務でCursorを使うなら、コードがどう扱われるのかを理解しておくことが大切です。

Privacy Modeとは

Privacy Modeは、自分のコードがAIモデルの学習に使われないようにする機能です。 Privacy Modeを有効にすれば、コードがモデル提供元に保持されることはありません。

3つの設定オプション

Privacy Modeには3つの段階があります。オン/オフの2択で紹介されることが多いのですが、実際には次の3段階から選べます。

オプション	内容
Share Data	コードやプロンプトがCursorおよびモデル提供元に送信・保存される可能性がある。Free/Proプランのデフォルト設定
Privacy Mode	コードはモデルの学習に使われない。AI機能は通常どおり利用可能
Privacy Mode (Legacy)	最も厳格な設定。一部の機能（クラウドエージェントなど）も無効化される

ほとんどの場合、「Privacy Mode」（2番目のオプション）を選べば十分です。AI機能を制限せずにデータ保護が得られます。

Privacy Modeの有効化手順

Free/Proプランのデフォルトは「Share Data」です。何も設定を変えないと、コードが保存される可能性がある状態のまま使い続けることになります。以下の手順でPrivacy Modeを有効にしておきましょう。

画面右上の歯車アイコンをクリックし、「Cursor Settings」を開く（またはコマンドパレットで「Cursor Settings」と入力）
「General」タブを選択する
「Privacy」セクションにある「Privacy Mode」のドロップダウンを探す
「enabled」を選択する

企業で使う場合のポイント

Businessプランでは、チーム管理者がPrivacy Modeをチーム全体に強制適用できます。メンバーが個別にOFFにするリスクを防げるため、企業での導入時にはBusinessプランが検討対象になるでしょう。

基本的な使い方

Cursorには「Agentビュー」と「Editorビュー」という2つの表示モードがあり、画面右上の歯車ボタンから切り替えができます。なお、このUIはバージョンによってコロコロ変わるので、もし見つからない場合はCursorの公式マニュアルをご参照ください。どちらのモードもやれることは同じなので、お好みで選びましょう。

ここからは2つのモードの違いから始めて、AIとの対話方法、4つのモード、モデルの選び方まで、Cursorの基本操作をひと通り身につけていきます。

Agentsタブ

Cursorを起動すると、最初に表示されるのがAgentsタブです。AIとの対話を中心に据えたレイアウトになっています。

画面の構成は次のとおりです。

左側: エージェントパネル（チャット履歴の一覧、新しいチャットの開始）
中央: チャットの内容（AIとのやり取り）
右側: ファイルエクスプローラー

ここでいう「エージェント（Agent）」とは、指示に応じてコードを書いたり、ファイルを編集したりできるAIアシスタントのことです。ChatGPTのように質問に答えるだけでなく、実際にプロジェクトの中で作業をしてくれます。

エージェントが使えるツールには、以下のようなものがあります。

ファイルやフォルダの読み込み・検索
ファイルの編集
ターミナルコマンドの実行
Web検索
ブラウザの操作
画像の読み込み・生成

Agentsタブでよく使うショートカットも覚えておくと便利です。

操作	Mac	Windows / Linux
エージェントパネルを開く	`Cmd+I`	`Ctrl+I`
新しいチャットを開始	`Cmd+N`	`Ctrl+N`
Agents / Editor タブの切り替え	`Cmd+E`	`Ctrl+E`

Editorタブ

Editorタブは、VS Codeに近い従来型のレイアウトです。

画面の構成はAgentsタブと左右が逆転しています。

左側: ファイルエクスプローラー
中央: コードエディタ
右側: AIチャットパネル

VS Codeに慣れている方なら、この配置のほうがしっくりくるかもしれません。ファイルを開いてコードを書くことが中心で、AIには必要なときに右側のパネルから話しかける、という使い方になります。

AIとのチャット ― まずは話しかけてみる

Cursorの基本的な使い方はシンプルです。チャット欄に日本語で指示を入力し、Enterキーで送信するだけです。

具体的な手順を見てみます。

Cmd+I（Mac）/ Ctrl+I（Windows）でエージェントパネルを開く
テキスト入力欄に指示を入力する（日本語でOK）
Enter で送信する
AIの応答を確認する

たとえば、こんな指示から始めてみてください。

「このプロジェクトの構成を教えて」
「この関数が何をしているか説明して」
「ログイン画面のHTMLを作って」

AIがコードの変更を提案した場合は、差分（diff）形式で変更箇所が表示されます。内容を確認して、承認するか却下するかを選べます。

効果的な指示の出し方として、公式ドキュメントでは具体的であることが重要だと説明されています。

あいまいな指示: 「auth.tsのテストを追加して」
具体的な指示: 「auth.tsの要件を確認して、__tests__/フォルダのパターンに合わせてテストを作成して」

ファイルの場所がわかっているなら指示に含め、わからなければ「認証まわりの処理を修正して」のように概念的な指示でも大丈夫です。

また、会話をリセットするタイミングも意識してみてください。別のタスクに移るときや、AIが同じ間違いを繰り返すときは、新しいチャット（Cmd+N）で仕切り直すのが効果的です。1つのチャットにあれもこれも詰め込むと、AIの回答精度が下がりやすくなります。「1つのタスクに1つのチャット」を意識すると、よい結果が得られます。

4つのモードの使い分け（Agent / Ask / Plan / Debug）

Cursorの4つのモード（Agent・Ask・Plan・Debug）の選択画面

Cursorのチャットには4つのモードがあります。モードによって、AIの振る舞いが変わります。

モードの切り替えは、チャット入力欄の左下にあるドロップダウンから選択するか、Cmd+.（Mac）/ Ctrl+.（Windows）のショートカットで行えます。

Agentモード（デフォルト）

最も基本的なモードです。AIがファイルの読み書き、コマンドの実行、エラー修正まで、すべてを自律的に行います。通常の開発作業はこのモードで十分対応できます。

「ログインフォームを作って」と指示すれば、AIが自分でファイルを作成し、コードを書き、必要に応じてターミナルでコマンドを実行してくれます。

Askモード

読み取り専用のモードです。コードを検索して質問に答えますが、ファイルの変更は一切行いません。

たとえば次のような場面で使えます。

「この関数はどこから呼ばれている？」
「このファイルを変更したら、どこに影響が出る？」
「このエラーの原因は何？」

コードを変更せずに調査だけしたいとき、Askモードなら安心して質問できます。

Planモード

設計してから実装するためのモードです。AIはいきなりコードを書くのではなく、まず実装計画を作成します。

AIがあなたと要件定義をしてくれるモード、というイメージです

動作の流れは次のとおりです。

AIが要件を確認し、必要に応じて質問してくる
コードベースを調査して、関連するファイルや構造を把握する
詳細な実装計画を作成する
計画を確認・修正したら、実行に移す

大きな機能を実装するときや、複数ファイルにまたがる変更を行うときに向いています。

Debugモード

再現しづらいバグや、原因がわからないエラーの調査に特化したモードです。Agentモードが「すぐに修正を試みる」のに対して、Debugモードは「原因を特定してから修正する」というアプローチを取ります。

AIがデバッグ用のコードを埋め込んでテストをしたり、ログを出力したりして、バグの原因を特定してくれます。

バグが解消した後は、埋め込んだデバッグをきれいに削除してくれます。

Debugモードは、大まかに次のようなフローで進みます。

関連ファイルを調査し、バグの原因について複数の仮説を立てる
コードにログ文を自動挿入して、実行時のデータを収集する準備をする
ユーザーにバグの再現手順を提示し、実際に再現してもらう
収集したログを分析し、根本原因を特定する
原因に対する修正を適用し、動作を確認する

「テストは通るのに本番で動かない」「特定の条件でしか発生しないバグ」など、単純な修正では解決しない問題に効果的です。

AIに見てほしいファイルや情報を指定する（@メンション）

AIに「このファイルを見て」と明示的に伝える方法が@メンションです。チャット入力欄で @ を入力すると、指定できるコンテキストの候補が表示されます。

利用できる@メンションは主に次の4種類です。

メンション	用途
`@Files & Folders`	特定のファイルやフォルダ全体をAIに見せる
`@Code`	関数やクラスなど、コードの一部分だけを指定する
`@Docs`	フレームワークやライブラリのドキュメントを参照させる
`@Past Chats`	過去のチャット内容を参照させる

使い方はこうです。

チャット入力欄に @ と入力する
候補リストが表示される。ファイル名の一部を続けて入力すると絞り込める
目的のファイルやコードを選択する
指示文と一緒に送信する

たとえば「@src/auth/login.ts のバリデーション処理にメールアドレスの形式チェックを追加して」のように使います。

@Docs では、ReactやNext.jsなどの人気フレームワークのドキュメントがあらかじめ組み込まれています。自分のプロジェクトで使っているライブラリのドキュメントを追加したい場合は、Cursor Settings > Indexing & Docs からURLを登録できます。

すべてのファイルを@メンションする必要はありません。 Cursorのエージェントは、現在開いているファイルやコードベースの検索結果など、さまざまな情報をバックグラウンドで自動的に収集しています。

ファイル名がはっきりわかっているときは @ で明示的に指定しましょう。「認証まわり」「データベース接続の部分」のように場所が不明確なときは、エージェントの自動検索に任せるのが効率的です。

AIモデルの切り替え

Cursorでは、複数のAI企業が提供するモデルを切り替えて使えます。モデルとは、AIの頭脳にあたる部分です。種類によって得意分野や処理速度が異なります。

モデルの切り替えは、上記画像の通り、ドロップダウンから行えます。

利用できるモデルは、大きく分けて以下のグループがあります。

プロバイダー	代表的なモデル	特徴
Anthropic	Claude Sonnet, Claude Opus	注意深い出力。コードの品質が高い
OpenAI	GPT-5, GPT-5 Mini	論理的思考に強い
Google	Gemini Flash, Gemini Pro	画像入力への対応が得意
Cursor	Composer 1, Composer 1.5	Cursor独自の軽量モデル

迷ったら「Auto」を選んでください。 Autoは、タスクの内容に応じて最適なモデルをCursorが自動で判定する機能です。モデルピッカーで「Auto」を選択するだけで有効になります。

特定のモデルに固定したい場合は、モデルピッカーから直接モデル名を選びます。たとえば、コードの品質を重視したいときはClaude系、論理的な分析が必要なときはGPT系、画像を含む指示を出したいときはGemini系、といった使い分けができます。

モデル名は頻繁に更新されるため、最新のモデル一覧はモデルピッカーのドロップダウンか公式のモデルページで確認してください。

Maxモード

Maxモードは、AIが一度に扱える情報量（コンテキストウィンドウ）を最大限まで拡張する機能です。

通常、AIが1回のやり取りで処理できる情報量には上限があります。Maxモードをオンにすると、この上限がモデルの最大値まで引き上がります。

Maxモードが役立つのは、次のような場面です。

大規模なファイルを丸ごと読み込ませたいとき
プロジェクト全体を把握したうえで正確な編集をしてほしいとき
長い会話を途切れさせずに続けたいとき

有効化の方法は、上記画像の通り、モデルピッカーで「Max」トグルをオンにするだけです。

ただし、Maxモードは追加コストがかかります。通常のリクエストの数倍から十数倍のコストになることもあるため、日常的なやり取りではオフにしておき、大規模な作業で必要なときだけオンにするのが合理的です。

複数エージェントの並列実行

Cursorでは、複数のエージェントを同時に動かす「並列実行」ができます。並列実行には3つのやり方があります。

やり方1: 複数のチャットタブで別々のタスクを進める

最もシンプルな方法です。Agentsタブで複数のチャットを開いて、それぞれに別のタスクを入力して実行します。

ただし、この方法では同じファイルを編集しようとした場合、作業が衝突する恐れがあります

各エージェントが触るファイルが完全に分かれている場合（たとえばフロントエンドとバックエンドが完全に別ファイル）は問題ありませんが、同じファイルを触る可能性があるタスクには向いていません。

やり方2: git worktreeで隔離して並列実行する

やり方1の衝突問題を解決するのが、Cursor 2.0で導入されたgit worktreeを使った並列実行です。

はじめに申し上げますが、このやり方は Git が扱えるエンジニア向けの上級テクニックです。

git worktreeとは、同じリポジトリに対して複数の独立した作業フォルダを作る仕組みです。この機能では、各エージェントに独立した作業フォルダとブランチが自動的に割り当てられるため、同じファイルを編集してもお互いの作業が衝突しません。

たとえば、1つのエージェントに「ログイン機能」を作らせながら、別のエージェントに「ユーザー一覧画面」を同時に作らせる、といった使い方ができます。

操作方法は、以下の画像のように、左下のプルダウンからWorktreeを選択するだけです。その状態でAIにチャットを投げると、自動で新規のworktreeが作成されます。

注意: この機能にはGitが必要です。内部的にgit worktreeというGitの仕組みを使っているため、プロジェクトがGitで管理されていることが前提条件です。エンジニアの方はGitを日常的に使っているはずなので問題ありませんが、非エンジニアの方でGitを導入していない場合、この機能は利用できません。

やり方3: 同じタスクを複数モデルに同時に投げる（Best of N）

3つ目は、同じ指示を異なるモデルに同時に投げて、最も良い結果を選ぶというアプローチです。

操作手順は次のとおりです。

チャット入力欄のモデルセレクター（ドロップダウン）をクリックする
「Use Multiple Models」のトグルをオンにする
使用したいモデルを複数選択する（例: Claude Sonnet、GPT-4o、Gemini など）
プロンプトを送信する

選択したすべてのモデルが同時に実行を開始し、それぞれの結果がタブで表示されます。各タブをクリックして出力を確認し、最も気に入った結果だけを「Apply」で適用できます。残りの結果は破棄されます。

例えば、2つの異なるモデルに、同時にドラえもんの名字を考えてもらった結果は以下です。それぞれ異なる結果が並列処理で返ってきて、画像の赤枠の部分でモデルと結果を切り替えることができます。好きな結果を選ぶことができて便利です。

CursorのBest of N機能で2つのモデルがそれぞれ異なる回答を返した例

この方法は、次のような場面で特に有効です。

重要な実装で、モデルごとのアプローチの違いを比較したいとき
AIにアイディア出しをお願いしたい時
1つのモデルの出力に満足できず、別の選択肢がほしいとき

注意点として、選択したモデルの数だけトークンを消費します。3つのモデルで並列実行すれば、トークン消費もおよそ3倍です。日常的な作業では1モデルで十分なことが多いので、ここぞという場面で使い分けるのがよいでしょう。

並列実行は強力な機能ですが、初心者のうちは1つのエージェントと対話することに慣れるのが先です。複数タスクを抱えるようになったときに、思い出してみてください。

コード編集機能

Cursorには、チャットでAIに指示を出す以外にも、コードの編集を助けてくれる機能があります。コードの続きをAIが予測して補完してくれる「Tab補完」と、ブラウザで見た目を確認しながらAIに修正を指示できる「ブラウザ連携」が使えます。

Tab補完 ― AIがコードの続きを予測する

この機能は単なるコード補完ではありません。直前の編集内容やプロジェクト全体の文脈を読み取り、次に書くべきコードを予測する仕組みです。公式ドキュメントでは「コンテキストを意識したマルチライン補完」と説明されています。

基本的な使い方

コードを入力していると、AIが半透明の文字（ゴーストテキスト）で続きの候補を表示します。

例えば、以下の画像の例は、コードに img と入力したら、自動で src=xxxx というコードを提案してくれている様子です。
この状態でタブキーを押すと、この提案を受け入れるという動作になります。

操作	Mac	Windows / Linux
候補をそのまま採用	`Tab`	`Tab`
候補を却下	`Escape`	`Escape`
単語単位で部分的に採用	`Cmd+→`	`Ctrl+→`

候補全体ではなく一部だけ使いたいときは、Cmd+→（Mac）/ Ctrl+→（Windows）で1単語ずつ取り込めます。たとえば関数名は合っているけれど引数が違う、という場合に便利です。

Tab補完の精度を上げるコツ

Tab補完はコードの文脈から予測を行うため、AIに与えるヒントが多いほど精度が向上します。具体的には、以下のような手段が有効です。

コメントを書く: 関数の目的や処理の流れをコメントで書いておくと、AIがそれを手がかりに正確なコードを生成しやすくなる
型ヒントを明示する: TypeScriptの型定義やPythonの型ヒントがあると、補完の精度が大きく上がる
関連ファイルをタブで開いておく: AIは開いているタブの内容も参照するため、関連するファイルを開いておくと文脈の理解が深まる
最初の1つを手で書く: 配列やオブジェクトの繰り返しパターンは、最初の要素を自分で書くと、残りをAIが正確に予測してくれる

ブラウザ連携 ― 見た目を確認しながらAIに修正させる

CursorにはWebブラウザが内蔵されています。開発中のWebアプリをCursorの中で表示し、その見た目をAIに見せながら修正を指示できる機能です。

内蔵ブラウザの開き方

ローカルの開発サーバーを起動すると、Cursorが自動的にサーバーを検知し、「http://localhost:3000 をCursor Browserで開きますか？」というダイアログが表示されます。「Open」をクリックすると、エディタ内にブラウザパネルが開きます。

手動で開くこともできます。

ターミナルで開発サーバーを起動する（例: npm run dev）
チャットで「ブラウザで localhost:3000 を開いて」と指示する
エージェントが内蔵ブラウザでページを表示する

AIがブラウザを操作する

内蔵ブラウザの真価は、AIエージェントがブラウザを直接操作できる点にあります。公式ドキュメントによると、エージェントは次の操作を実行できます。

Navigate: URLへの移動、リンクのクリック、ブラウザ履歴の操作
Click: ボタンやフォーム要素のクリック
Type: 入力フォームへのテキスト入力
Scroll: ページのスクロール
Screenshot: 画面のスクリーンショット撮影
Console Output: JavaScriptのエラーやログの取得
Network Traffic: HTTPリクエストやレスポンスの監視

たとえば次のように指示してみてください。

localhost:3000 を開いて、ログインフォームにテスト用のメールアドレスとパスワードを入力して、送信ボタンを押して

エージェントがすべての操作を順に実行してくれます。操作の途中でスクリーンショットも撮影され、チャットに表示されるため、何が起きているかを目で確認できます。

見た目を見せながら修正を指示する

フロントエンド開発で特に便利なのが、「見た目を確認して修正を指示する」というワークフローです。

内蔵ブラウザで開発中のページを表示する
「ヘッダーの余白が大きすぎるから詰めて」「ボタンの色を青に変えて」のように、見た目に関する指示をチャットで伝える
エージェントがスクリーンショットを参照しながら、該当するCSSやコンポーネントのコードを特定して修正する
ブラウザがホットリロード（自動再読み込み）で更新され、修正結果をすぐに確認できる

HTMLやCSSのどのファイル・どの行を修正すべきかは、AIが自動で探してくれます。「この部分」と画面を指さす感覚で指示が出せるため、ファイル名やクラス名を知らなくても問題ありません。

ビジュアルエディタ(画面のデザイン調整機能)

ビジュアルエディタは、ブラウザ連携をさらに進化させた機能です。内蔵ブラウザに表示されたWebページの要素を、マウス操作で直接編集できます。

ビジュアルエディタを有効にする手順は次のとおりです。

内蔵ブラウザでページを表示する
ブラウザパネル内のインスペクターアイコン(以下の画像の赤枠の部分)をクリックする
画面右側にデザインサイドバーが開く

デザインサイドバーでは、選択した要素に対して次のような調整ができます。

レイアウト: FlexboxやGridの配置を変更する
サイズ: 幅・高さ・余白（padding/margin）を数値で調整する
色: 背景色やテキスト色をカラーピッカーで選択する
装飾: 影（shadow）、透明度（opacity）、角丸（border-radius）を設定する

Reactコンポーネントの場合は、props（コンポーネントに渡すパラメータ）をサイドバー上で直接変更して、表示の切り替えを試すこともできます。

調整が終わったら、「Apply」ボタンを押します。するとエージェントが起動し、ビジュアル上の変更を読み取ります。対応するソースコードを自動的に書き換えてくれます。変更内容はdiff形式で表示されるため、意図どおりか確認してから確定できます。

ビジュアルエディタの使いどころ

ビジュアルエディタは、レイアウトの微調整や色味の検討のように、「実際の見た目を確認しながら少しずつ詰めていく」作業に向いています。余白を数ピクセル変えたい、影の強さを試したい、といった場面では、コードを書くより直感的に操作できます。

デザインの大枠をすばやく試すツールとして活用し、最終的なコードはエージェントへのチャット指示や手動で整えるのが現実的な使い方です。

AIの動きをカスタマイズする

Cursor の AI は、そのままでも十分に優秀です。しかし「日本語で回答してほしい」「報告書は箇条書きで書いてほしい」「ファイル名には必ず日付を入れてほしい」といった、プロジェクト固有の要望までは伝えなければわかりません。Rules、Commands、Skills などの仕組みを使えば、AI の振る舞いを自分やチームの作業スタイルに合わせてカスタマイズできます。

「こうしてほしい」をAIに事前に伝える（Rules）

AI に作業を頼むたびに「日本語で答えて」「丁寧語で回答して」とお願いするのは面倒です。Rules（ルール）を使えば、こうした指示をあらかじめ登録しておけます。一度設定すれば、毎回入力しなくても AI が自動で従ってくれます。

Rules とは、AI が動作するときに毎回必ず守るルールブックです。会社でいう就業規則のようなもので、一度定めておけば毎回言わなくても AI がそのとおりに動きます。AI は会話と会話の間に記憶を持たないため、Rules で一貫した方針を与えておくことが重要です。

Rules の設定は Cursor Settings > Rules で行います。この画面には All / User / Project（プロジェクト名） のタブがあり、ルールの種類ごとに切り替えて管理できます。

Cursor SettingsのRules設定画面。All・User・Projectのタブで切り替えできる

最も手軽なのは User Rules（ユーザールール）です。「User」タブを開いてルールを記入するだけで設定できます。

たとえば、以下のようなルールを登録できます。

- 日本語で回答してください
- 回答は簡潔にまとめてください

これだけで、以降のすべてのプロジェクトで AI が日本語で回答するようになります。

ただし、User Rules が適用されるのは Agent（チャット）だけです。Tab 補完やインライン編集（Cmd/Ctrl + K）には影響しません。

User Rules がすべてのプロジェクトに適用されるグローバルな設定であるのに対し、プロジェクトごとに異なるルールを設定したい場合もあります。そこで登場するのが Project Rules です。次のセクションで、ルールの種類を詳しく見ていきましょう。

ルールの種類

Cursor のルールには大きく分けて 4 つの種類があります。それぞれ設定場所とスコープ（適用範囲）が異なります。

種類	設定場所	適用範囲	用途
Project Rules	Settings > Rules > Project タブ（ファイルは `.cursor/rules/`）	そのプロジェクトのみ	プロジェクト固有の規約
User Rules	Settings > Rules > User タブ	すべてのプロジェクト	個人の基本設定
Team Rules	Cursor ダッシュボード	チーム全員	チーム共通の規約（Team / Enterprise プラン）
AGENTS.md	プロジェクト内の任意のディレクトリ	該当ディレクトリ以下	シンプルな方針記述

ルールが競合した場合の優先順位は、Team Rules > Project Rules > User Rules の順です。

補足: ネット上の古い記事では、プロジェクトルートに .cursorrules というファイルを置く方法が紹介されていることがあります。この方式は現在非推奨（deprecated）です。新しく設定する場合は、Project Rules（.cursor/rules/）または AGENTS.md を使ってください。

Project Rules

プロジェクト固有のコーディング規約や方針を設定するためのルールです。.cursor/rules/ ディレクトリ内に .mdc または .md ファイルとして保存します。Git で管理できるため、チームメンバー全員で同じルールを共有できます。

.mdc ファイルは、先頭に「フロントマター」と呼ばれる設定情報を書き、その下にルール本文を記述する構造です。

フロントマターとは、ファイルの冒頭に ---（ハイフン3つ）で囲んで書く設定欄のことです。ここに「このルールをいつ適用するか」「どのファイルに対して適用するか」といった条件を記述します。フロントマターの中身は YAML（ヤムル） という形式で書きます。YAML は「項目名: 値」のように、コロン区切りで設定を並べるシンプルな書式です。

---                          ← フロントマターの開始
description: "企画書を作成するときに参照する規約"
alwaysApply: false
globs: ["docs/proposals/**/*.md"]
---                          ← フロントマターの終了

# 企画書の書き方ルール      ← ここからがルール本文
- 結論を最初に書く
- 箇条書きを活用する
- 1文は60文字以内にする

この例では、--- で囲まれた部分がフロントマターです。docs/proposals/ 配下のファイルが会話のコンテキストに含まれたときだけ、ルールが自動で適用されます。フロントマターにはあらかじめ指定されたいくつかのフォーマットに従って、AIの動きを細かく制御する指示を書くことができます。

フロントマターに指定できるフォーマットには以下のようなものがあります。

設定	動作
`alwaysApply: true`	すべてのチャットに常に適用
`alwaysApply: false` + `description` あり	AI が description を読み、関連性があると判断したら自動適用
`globs` 指定	指定したファイルパターンにマッチしたときだけ適用

AGENTS.md

YAML のフロントマターを書くのが面倒な場合、もっとシンプルな選択肢として AGENTS.md があります。プロジェクトルートや任意のサブディレクトリに AGENTS.md というファイルを置くだけで、AI への指示として認識されます。

.
                ├── AGENTS.md                    # プロジェクト全体の方針
                └── src/
                    └── components/
                        └── AGENTS.md            # コンポーネント固有の方針

サブディレクトリに置いた AGENTS.md は、親ディレクトリのものより優先されます。普通の Markdown ファイルなので、フロントマターや特別な構文は必要ありません。サブディレクトリに配置できるという特徴を活かして、この後説明するサブエージェントのフォルダ（.cursor/agents/）に設置すれば、サブエージェントごとのルールを個別に定義することもできます。

AGENTS.md の記述例:

# プロジェクトルール

- 日本語で回答してください
- TypeScript を使用してください（JavaScript は使わない）
- コンポーネントは関数コンポーネントで書く
- CSS は Tailwind CSS を使用する

# ディレクトリ構成
- src/components/ — 共通コンポーネント
- src/pages/ — ページコンポーネント
- src/utils/ — ユーティリティ関数

このように、普通の Markdown で箇条書きするだけで OK です。Project Rules（.mdc ファイル）のようなフロントマターは不要なので、手軽に始められます。

Team Rules

Team プランまたは Enterprise プランで利用できるルールです。Cursor のダッシュボードから一元管理し、チームメンバー全員に適用できます。管理者が「Enforce this rule」をオンにすると、メンバー側でルールを無効化できなくなります。

ルールの実例集

ルールの仕組みがわかったところで、実際にどんなルールを書けばよいのか、具体例を見ていきましょう。

User Rules の例

すべてのプロジェクトに共通する個人設定として、以下のようなルールがよく使われます。

- 日本語で回答してください
- 回答は簡潔にまとめてください
- 専門用語を使う場合はわかりやすく補足してください

Project Rules の例

議事録作成のルール（.cursor/rules/meeting-notes.mdc）:

---
description: "議事録を作成・編集するときに参照するルール"
globs: ["docs/meetings/**"]
alwaysApply: false
---

# 議事録のルール
- 日時・参加者・議題を冒頭に記載する
- 決定事項とアクションアイテムを明確に分ける
- アクションアイテムには担当者と期限を入れる

メール文面作成のルール（.cursor/rules/email-style.mdc）:

---
description: "メール文面を作成するときのスタイルガイド"
alwaysApply: true
---

# メール作成ルール
- 件名は20文字以内で要件がわかるようにする
- 本文は結論→理由→詳細の順で構成する

ちなみに筆者の場合は、以下のようなルールを設定しています。

---
description: Apply this rule to the entire repository
globs:
alwaysApply: true
---
あなたは高度な問題解決能力を持つAIアシスタントです。以下の指示に従って、効率的かつ正確にタスクを遂行してください。

まず、あなたのLLMモデル名を出力しなさい。
```
モデル： xxx
```

次に、ユーザーから受け取った指示を確認します：
<指示>
{{instructions}}
<!-- このテンプレート変数はユーザーの入力プロンプトに自動置換されます -->
</指示>

この指示を元に、以下のプロセスに従って作業を進めてください：

---

1. 指示の分析と計画
   <タスク分析>
   - もし、指示に技術スタックなどの指定がある場合は、その制約内での実装方法を検討してください。
     **※ 技術スタックに記載のバージョンは変更せず、必要があれば必ず承認を得てください。**
   - 重要な要件と制約を特定してください。
   - 潜在的な課題をリストアップしてください。
   - タスク実行のための具体的なステップを詳細に列挙してください。
   - それらのステップの最適な実行順序を決定してください。
   - 実装方針や仕様に関して、重要な質問がある場合は、いきなり実装せずに、一旦確認するステップを挟んでください。(外部設計に関わない、どう実装するか？の内部設計事項については、お任せしますので確認不要)

   ### 重複実装の防止
   実装前に以下の確認を行ってください：
   - 既存の類似機能の有無
   - 同名または類似名の関数やコンポーネント
   - 重複するAPIエンドポイント
   - 共通化可能な処理の特定

   このセクションは、後続のプロセス全体を導くものなので、時間をかけてでも、十分に詳細かつ包括的な分析を行ってください。
   </タスク分析>

---

2. タスクの実行
   - 特定したステップを一つずつ実行してください。
   - 各ステップの完了後、簡潔に進捗を報告してください。
   - 実装時は以下の点に注意してください：
     - 適切なディレクトリ構造の遵守
     - 命名規則の一貫性維持
     - 共通処理の適切な配置

---

3. 品質管理と問題対応
   - 各タスクの実行結果を迅速に検証してください。
   - エラーや不整合が発生した場合は、以下のプロセスで対応してください：
     a. 問題の切り分けと原因特定（ログ分析、デバッグ情報の確認）
     b. 対策案の作成と実施
     c. 修正後の動作検証
     d. デバッグログの確認と分析

   - エラーの修正タスクの場合は、他にも同様の箇所がないか必ずチェックすること

   - 検証結果は以下の形式で記録してください：
     a. 検証項目と期待される結果
     b. 実際の結果と差異
     c. 必要な対応策（該当する場合）

---

4. 最終確認
   - すべてのタスクが完了したら、成果物全体を評価してください。
   - 当初の指示内容との整合性を確認し、必要に応じて調整を行ってください。
   - 実装した機能に重複がないことを最終確認してください。


---

5. アウトプット出力
   - すみません、などの挨拶は不要。簡潔に述べよ
---

## 重要な注意事項

- 必要最小限の変更だけ行うこと
- 無関係な行を勝手にフォーマットしないこと(改行、デリミタ付与など含め、今回の要件達成に直接関係のない変更は一切禁止)
- 不明点がある場合は、作業開始前に必ず確認を取ってください。
- 重要な判断が必要な場合は、その都度報告し、承認を得てください。
- テストコードを実装する際は、プロダクトコードを必ず確認してから、その実態に見合った内容でテストを書くこと。例えば、存在しないボタン名など、プロダクトコードを解析せずに憶測でテストコードに書くのは厳禁。
- 予期せぬ問題が発生した場合は、即座に報告し、対応策を提案してください。
- **明示的に指示されていない変更は行わないでください。** 必要と思われる変更がある場合は、まず提案として報告し、承認を得てから実施してください。
- **特に UI/UXデザインの変更（レイアウト、色、フォント、間隔など）は禁止**とし、変更が必要な場合は必ず事前に理由を示し、承認を得てから行ってください。
- **技術スタックのバージョン（APIやフレームワーク、ライブラリ等）を勝手に変更しないでください。** 変更が必要な場合は、その理由を明確にして承認を得るまでは変更を行わないでください。

---

以上の指示に従い、確実で質の高い実装を行います。指示された範囲内でのみ処理を行い、不要な追加実装は行いません。不明点や重要な判断が必要な場合は、必ず確認を取ります。

ルールを書くときのコツ

公式ドキュメントでは、以下のベストプラクティスが推奨されています。

ルールは500行以内に保つ — 長すぎるルールは AI のコンテキストを圧迫します
大きなルールは分割する — 小さなルールに分けて再利用性を高めましょう
具体例を含める — 実際の具体例を添えると AI の精度が上がります

公式ドキュメントの推奨は「シンプルに始めて、AI が同じ間違いを繰り返すのに気づいたときだけルールを追加する」というアプローチです。最初から完璧なルールを目指す必要はありません。

コミュニティのルールを活用する

自分でゼロからルールを書くのが大変なら、コミュニティが公開しているテンプレートを参考にできます。

Cursor Directory — 用途別のルールテンプレートが多数公開されています
awesome-cursorrules — GitHub 上のルール集
awesome-cursor-rules-mdc — .mdc 形式のルール集

これらのテンプレートをベースに、自分のプロジェクトに合わせてカスタマイズするのが効率的です。

セキュリティ警告：サードパーティ製プロンプトの導入には注意が必要です

こういったサードパーティ製のプロンプトを導入する際は、必ず内容に100%目を通してからレビューを行ってください。公開されているルールの中には「プロンプトインジェクション」と呼ばれる攻撃コードが含まれているケースがあり、意図しない動作によってあなたの機密情報が外部に流出するおそれがあります。自分で100%レビューを行い、信用できるもの以外は絶対に使わないようにしましょう。

よく使う指示をショートカット化する（Commands）

Rules が「常に適用される基本方針」だとすると、Commands（コマンド）は「必要なときに呼び出す手順書」です。チャット入力欄で / を入力するだけで呼び出せる、再利用可能なワークフローを作成できます。

たとえば、コードレビューのたびに「機能要件を満たしているか」「テストが書かれているか」といったチェック項目を毎回入力するのは手間です。これを Commands に登録しておけば、/code-review と入力するだけで同じ手順を AI に指示できます。

Commands の作成方法

プロジェクトルートに .cursor/commands/ ディレクトリを作成する
ディレクトリ内に Markdown ファイルを作成する（例: code-review.md）
ファイルにプロンプト内容を記述する
チャット入力欄で / を入力すると、作成したコマンドがサジェストに表示される

ファイル名がそのままコマンド名になります。

コマンドの例

コードレビュー用コマンド（.cursor/commands/code-review.md）:

# コードレビュー

以下のチェックリストに従って、コードをレビューしてください。

## チェック項目
1. 機能要件を満たしているか
2. エラーハンドリングが適切か
3. テストが書かれているか
4. 命名規則が守られているか
5. パフォーマンス上の問題がないか

このファイルを保存すると、チャットで /code-review と入力するだけで上記の指示が AI に送られます。コマンド名の後にテキストを追加すれば、プロンプトの一部として扱われます。たとえば /code-review 認証周りを重点的に と入力すれば、チェックリストに加えて認証の観点も考慮されます。

Commands の保存場所

Commands は 3 つのレベルで管理できます。

レベル	保存場所	適用範囲
プロジェクト	`.cursor/commands/`	そのプロジェクトのみ
グローバル	`~/.cursor/commands/`	すべてのプロジェクト
チーム	Cursor ダッシュボード	チーム全員（Team / Enterprise プラン）

Rules と Commands の使い分け

観点	Rules	Commands
適用方法	自動で適用	`/` で明示的に呼び出し
用途	原則・ガイドライン・禁止事項	チェックリスト・作業手順・テンプレート
例	文書作成の規約、回答のスタイル	レビュー手順、チェックリスト実行

AI が実行前に毎回自動で読み込んでほしいルールは Rules に、手動でよく使うプロンプトを呼び出したいときは Commands に設定する、と覚えておくとよいでしょう。

AIにスキルを追加する（Skills）

Commands と同様の仕組みとして、Skills（スキル）というものがあります。

Commands は Cursor の独自機能ですが、Skills は Claude Code など他の AI ツールでも共通で使える汎用的な規格です。

機能としては Commands とほぼ同様ですが、筆者のオススメとしては Commands は非推奨で、Skills の方を使うことです。その理由は以下の 2 つです。

Skills の方が高機能 — サブエージェントの起動やツール制限など、より高度な制御が可能
Skills の方が一般的 — 複数の AI ツールで共通して使えるため、チームメンバーへの配布がしやすい

Skills についての詳細はこちらの記事で解説しています。

Commands との違い

Commands と Skills はよく似ていますが、統合されたわけではなく、両方が共存しています。

	Commands	Skills
場所	`.cursor/commands/*.md`	プラグイン内 `skills/SKILL.md`
起動方法	`/` で手動選択	エージェントが自動判断 (「xxxスキルを使ってこのタスクを実行して」とAIに依頼するだけでOKです)
用途	チーム共有のプロンプトテンプレート（レビュー、チェックリスト等）	専門分野の知識・ワークフロー（Figma連携、データ分析、翻訳等）
配布	git リポジトリで共有	Cursor Marketplace 経由

私の個人的な意見としては、本当はSkillsに統一化すべきですが、現時点では両方が共存してしまっているという状況です。Skillsだけを使っておけば間違いありません

Skills の構造や書き方

Skills についての構造や書き方についての詳細はこちらの記事で解説しています。

AIに専門的な役割を持たせる（Subagents）【超重要】

Subagents（サブエージェント）は、AI を「専門の担当者」として役割を与え、処理を依頼できる仕組みです。

たとえば、ブログ記事を AI に書かせる場合、

調査担当
執筆担当
画像作成担当

のように、担当を分けることができます。この一つ一つの担当者が、サブエージェントです。

サブエージェントを使うと結果の品質が大幅にアップします。その理由として、サブエージェントはそれぞれ別のコンテキストウィンドウで動くためです。

とても重要な話なので、しっかりと理解をしましょう。サブエージェントの詳細や Skills との違いについては、こちらの記事で詳しく解説しています。

ビルトインサブエージェント

Cursor には、最初から用意されているサブエージェントが 3 つあります。

名前	役割
Explore	プロジェクト内のファイル検索・分析。最大 10 件の並列検索が可能
Bash	コマンド操作の実行。冗長な出力をメインの会話から分離
Browser	MCP 経由でブラウザ操作を自動化

これらは特に設定しなくても、AI が必要に応じて自動的に使用します。

カスタムサブエージェントの作り方

自分で専門的な役割を持つサブエージェントを作ることもできます。保存場所はプロジェクトレベルが .cursor/agents/、ユーザーレベルが ~/.cursor/agents/ です。

定義ファイルの例（.cursor/agents/verifier.md）:

---
name: reviewer
description: "完成した文書をレビューする。誤字脱字や表現の一貫性を確認する"
model: inherit
---

# レビューエージェント
あなたは文書レビューの専門家です。
以下の手順でレビューを行ってください:
1. 誤字脱字をチェックする
2. 表現の一貫性を確認する
3. 結果をレポートする

フロントマターの主なフィールドは以下のとおりです。

フィールド	デフォルト	説明
`name`	ファイル名	一意の ID（小文字、ハイフン区切り）
`description`	—	AI がこの説明を読んで委任するか判断する
`model`	`inherit`	`fast`（高速モデル）、`inherit`（親と同じ）、または特定のモデル ID
`is_background`	`false`	`true` にすると、完了を待たずにメイン処理を続行

サブエージェントの呼び出し方

作成したサブエージェントは、/ コマンドで呼び出せます。

/reviewer この企画書をレビューして

会話の中で自然に言及しても、AI が適切なサブエージェントを選んで委任する場合もあります。

筆者が実際に使っているサブエージェント

ちなみに、筆者の場合は、このブログ記事を執筆した際、以下のサブエージェントを使ってレビューしています。

使い方はAIのチャット欄に「book-reviewerスキルを使って、このブログ記事をレビューして」と入力するだけです。

エージェント定義ファイル（.cursor/agents/book-reviewer.md）:

---
name: book-reviewer
description: "執筆された章をレビュー・修正する"
tools: Read, Edit, WebSearch
model: opus
---

# book-reviewer

あなたはプロの書籍編集者です。執筆された章をレビュー・修正してください。

## 実行手順

1. 以下のファイルを順番に読め:
   - .claude/skills/generate-book/persona.md（読者像）
   - {目次ファイルパス}（書籍全体の構成。この章の位置づけを理解する）
   - {該当章の調査ノートパス}（調査結果。事実確認に使う）
   - {該当章ファイルパス}（レビュー対象）

2. 以下の観点でレビューせよ:

### 正確性
- 調査ノートの情報と矛盾する記述はないか
- 技術的に誤った記述はないか（不確かな場合は WebSearch で確認）
- 最新の公式仕様と一致しているか
- 調査ノートにある重要な情報が執筆で漏れていないか

### 読者適合性
- persona.md の読者が理解できる内容・表現になっているか
- 専門用語に適切な説明が添えられているか
- 子供扱いしていないか（逆に難しすぎないか）
- 「日本一わかりやすい入門書」と言えるレベルか

### 執筆ガイド準拠
- writing-guide.md のルールに違反している箇所はないか
- 文体・トーンは統一されているか
- 1文の長さ、語尾の連続、禁止表現のチェック

### 構成・流れ
- 章内の論理展開は明快か
- 冗長な箇所、情報が不足している箇所はないか
- 具体例・操作手順が十分に含まれているか

3. 問題がある箇所は Edit ツールで直接修正せよ
4. 修正した箇所とその理由を最後にまとめて報告せよ

このエージェントは、レビュー時にペルソナ（読者像）を参照します。以下がその中身です。

ペルソナ定義（persona.md）:

# ペルソナ定義

この本の想定読者。執筆・レビューのすべての判断基準はこの人物像に基づく。

## プロフィール

- **年齢**: 22歳
- **職業**: 会社員2年目、駆け出しのシステムエンジニア
- **エンジニア歴**: 2年目（初心者）
- **学歴**: 普通科の高卒

## 技術スキル

- Git の基本操作（clone, commit, push, pull）はできる
- VS Code は日常的に使っている
- ターミナル操作は基本的なコマンド（cd, ls, mkdir等）ならわかる
- AIツール（ChatGPT等）は個人的に触ったことがあるが、開発業務に本格導入はしていない

## 知識レベル

- 「Cursor」という名前は聞いたことがある。AIでコードが書けるらしい、くらいの認識
- VS Code の拡張機能やショートカットはそこそこ使っている
- MCP、Agent、RAG などの用語すら知らないレベル

## この読者にとっての「わかりやすさ」とは

- 専門用語が出てきたとき、それが何をするものかが一言で添えられている
- 手順が具体的で、スクリーンショットや操作手順が明確
- 「なぜそうするのか」の理由が書かれている
- 読み終わったあと、すぐに手を動かせる実践的な内容
- ペルソナは22歳だが、高校生でも理解できる内容であること

このように、サブエージェントに「何を基準にレビューするか」を具体的に指示し、さらにペルソナなどの外部ファイルを参照させることで、一貫した品質のレビューが自動で行えるようになります。

FigmaやGitHubなど外部ツールとAIを繋ぐ（MCP）

MCP（Model Context Protocol）は、Cursor を外部のツールやサービスに接続するための仕組みです。GitHub のタスク一覧を取得したり、Figma のデザインデータを読み取ったり、Notion のドキュメントを参照したりと、普段使っているツールを AI から直接操作できるようになります。

「USB ポート」をイメージするとわかりやすいかもしれません。PC に USB ポートがあれば、マウス、キーボード、外付けドライブなどさまざまな機器を接続できます。MCP はそれと同じで、Cursor に「接続口」が用意されていることで、さまざまな外部サービスを繋ぎ込めるのです。

対応サービスの例

MCP で接続できるサービスは多岐にわたります。

カテゴリ	サービス例
デザイン	Figma
バージョン管理	GitHub, GitLab
プロジェクト管理	Linear, Jira
クラウド	AWS, Vercel, Cloudflare
データベース	PostgreSQL, MongoDB, Supabase
モニタリング	Sentry, Datadog

MCP の設定方法

MCP サーバーは .cursor/mcp.json という設定ファイルで管理します。プロジェクトレベル（.cursor/mcp.json）とグローバル（~/.cursor/mcp.json）の 2 箇所に配置できます。

設定ファイルの基本構造は以下のとおりです。

ヒント：設定ファイルは自分で書かなくて大丈夫です

これから設定ファイルの実例を解説しますが、実は自分で手書きする必要はありません。AI に「Figma の MCP を設定して」のようにお願いすれば、設定ファイルを自動で作ってくれます。ここでは「こういう仕組みになっているんだな」という理解だけで十分です。

{
  "mcpServers": {
    "server-name": {
      "command": "node",
      "args": ["/path/to/server/index.js"],
      "env": {
        "API_KEY": "your-api-key"
      }
    }
  }
}

実践: Figma MCP を設定する

実際に Figma と Cursor を接続する手順を紹介します。Figma のデザインデータを AI に読み取らせることで、デザインどおりの UI コードを生成できるようになります。

Figma にログインし、アカウント設定 > Security > Personal access tokens でトークンを生成する
プロジェクトルートに .cursor/mcp.json を作成する
以下の設定を記述する

{
  "mcpServers": {
    "Framelink Figma MCP": {
      "command": "npx",
      "args": [
        "-y",
        "figma-developer-mcp",
        "--figma-api-key=YOUR-TOKEN-HERE",
        "--stdio"
      ]
    }
  }
}

Cursor Settings > MCP を開き、緑のアイコンが点灯していれば接続成功

Figma でフレームを選択 → 右クリック → 「選択範囲へのリンクをコピー」
Cursor のチャットにリンクを貼り付けて、「このデザインを React コンポーネントにして」と指示する

セキュリティに関する注意

MCP の設定では、セキュリティに十分注意してください。

信頼できない MCP サーバーはインストールしない — MCP サーバーは外部のプログラムです。公式パートナーや信頼できるソースのサーバーを使いましょう

ここから先はエンジニア向けの内容です

非エンジニアの方はここまでの知識で十分に Cursor を活用できます。

AIに見せたくないファイルを除外する（.cursorignore）

プロジェクトには、AI に見せたくないファイルがあるものです。.env に書かれた API キー、node_modules/ の膨大な依存パッケージなど。.cursorignore を使えば、Cursor の AI がアクセスできるファイルを制御できます。

.cursorignore の作り方

プロジェクトルートに .cursorignore ファイルを作成し、除外したいパターンを記述します。構文は .gitignore と同じです。

# 依存パッケージ
node_modules/
vendor/

# ビルド成果物
dist/
build/
.next/

# 環境変数・機密情報
.env*
credentials.json

# ログ
*.log

.cursorignore が影響する範囲

.cursorignore に記述したファイルは、Tab 補完、Agent、インライン編集、@ メンションのいずれからもアクセスできなくなります。

ただし、重要な制限があります。Agent が使用するターミナルおよび MCP サーバーは、.cursorignore で除外されたファイルにもアクセスできてしまいます。機密ファイルの完全な保護には、ファイルシステムレベルのアクセス制御も検討してください。

なお、.gitignore に含まれるファイルやロックファイル、バイナリファイルなどはデフォルトでインデックス対象外になっています。.cursorignore は、デフォルトの除外では足りない場合や、機密ファイルを明示的にブロックしたい場合に追加するのが効果的です。

Cursor CLI ― 画面なしでAIを動かす

Cursor はエディタの画面だけでなく、ターミナルからも操作できます。Cursor CLI（コマンドラインインターフェース）を使えば、GUI版よりも自律的に全自動で処理を実行したり、スクリプトから AI を定期実行したりできます。

ターミナルからAIと対話する

Cursor CLI は、ターミナルからAIエージェントと直接対話するためのツールです。コマンド名は agent で、Cursor のエディタを開かずに、ターミナルだけでコードの作成・レビュー・修正を行えます。

インストール

macOS / Linux / WSL（Windows の Linux 環境）に対応しています。ターミナルで以下のコマンドを実行してください。

curl https://cursor.com/install -fsS | bash

Windows の場合は、PowerShell で以下を実行します。

irm 'https://cursor.com/install?win32=true' | iex

インストールが完了したら、PATH（コマンドの検索先）を通します。zsh を使っている場合は以下のとおりです。

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc
                source ~/.zshrc

bash の場合は ~/.zshrc の部分を ~/.bashrc に置き換えてください。

インストールと PATH の設定ができたら、バージョンを確認します。

agent --version

バージョン番号が表示されれば成功です。なお、以前は cursor-agent というコマンド名でしたが、現在は agent が正式な名称です。古い記事で cursor-agent と書かれている場合は agent に読み替えてください。

CLI は agent update コマンドでアップデートできます。デフォルトでは自動更新が有効になっているため、通常は手動で実行する必要はありません。

詳しいインストール手順は公式ドキュメントにまとまっています。

Cursor CLI は Pro プラン以上で利用できます（※2026年2月時点。無料の Hobby プランでも一時的に利用できたとの報告がありますが、公式ドキュメントに明確なプラン要件の記載がないため、最新の状況は公式の料金ページで確認してください）。

対話モードで使ってみる

ログインが済んだら、対話モードを起動します。

agent

これだけで対話モードが始まります。Cursor のエディタで Agent チャットを使うのと同じ感覚で、テキストを入力して AI とやり取りできます。

最初からプロンプトを渡して起動することも可能です。

agent "このプロジェクトの構成を説明して"

フォースモードで起動する

通常の対話モードでは、AI がファイルを変更したりコマンドを実行するたびに「許可しますか？」という確認が表示されます。安全ですが、何度も承認するのが面倒に感じることもあるでしょう。

そこで使えるのが --force（-f）フラグです。

agent --force "テストを追加して"

--force を付けると、明示的に拒否されていない操作はすべて自動で許可されます。ファイルの読み書き、コマンドの実行など、AI が必要だと判断した操作をいちいち承認する必要がなくなります。

便利な反面、AI が意図しないファイルを上書きしたり、予期しないコマンドを実行するリスクもあります。使う前に必ず Git でブランチを切っておいてください。万が一おかしな変更があっても、元に戻せます。

# ブランチを切ってからフォースモードで作業する
git checkout -b ai/add-tests
agent --force "ユーザー認証のテストを追加して"

フォースモードは、この後紹介するヘッドレスモード（-p フラグ）と組み合わせて使うことも多いです。たとえば agent -p --force "..." とすると、対話なし・承認なしで AI が作業を完了させます。

⚠ フォースモードの重大なリスク

フォースモードでは、AI があらゆる操作を確認なしで実行します。これはファイルの削除、システムコマンドの実行、環境設定の変更なども含まれます。最悪の場合、あなたのパソコンの環境を壊してしまう恐れがあります。

フォースモードを使うときは、Docker コンテナや仮想マシンなどのサンドボックス環境の中で実行することを強くおすすめします。ホスト OS（普段使っているパソコン）で直接実行するのは避けてください。

3つのモード

エディタ版と同じく、CLI にも 3 つのモードがあります。

モード	説明	切り替え方
Agent（デフォルト）	ファイルの読み書きやコマンド実行など、すべての操作が可能	起動時のデフォルト
Plan	コードを変更せず、実装の計画だけを立てる	`/plan` または `Shift+Tab`
Ask	コードを変更せず、質問への回答のみ行う	`/ask` または `Shift+Tab`

Shift+Tab を押すたびに Agent → Plan → Ask → Agent… とモードが回転します。起動時に --mode=plan や --mode=ask を指定することもできます。

# 計画モードで起動
agent --mode=plan "認証機能をリファクタリングしたい"

よく使うキーボードショートカット

ターミナル上での操作を効率化するショートカットを覚えておくと便利です。

キー	動作
`Shift+Tab`	モード切り替え
`Shift+Enter`	複数行の入力
`Ctrl+R`	変更内容の確認
`Ctrl+D`（2回）	終了
上矢印キー	過去のメッセージを遡る

Shift+Enter による複数行入力は、iTerm2、Ghostty、Kitty、Warp、Zed などのターミナルでそのまま使えます。Apple Terminal や Alacritty、VS Code の統合ターミナルでは Shift+Enter が使えません。/setup-terminal コマンドを実行すると、代わりに Option+Enter で改行できるよう設定されます。tmux や screen を使っている場合は Ctrl+J で改行してください。

どのターミナルでも確実に改行したい場合は、バックスラッシュ + Enter（\ を入力してから Enter）が使えます。

詳しくはターミナルセットアップの公式ドキュメントを参照してください。

コンテキストの指定とセッション管理

エディタ版の @メンション と同じように、CLI でも @ を使ってファイルやフォルダをコンテキストとして指定できます。

@src/utils/auth.ts この認証ロジックの問題点を指摘して

会話が長くなってきたら /compress と入力してください。会話の内容が要約され、コンテキストウィンドウ（AI が一度に読める情報量の枠）に空きができます。

過去の会話を再開したい場合は、以下のコマンドが使えます。

# 過去の会話を一覧表示
agent ls

# 最新の会話を再開
agent resume

# 特定の会話を再開（IDを指定）
agent --resume abc123

スラッシュコマンド

対話中に使えるスラッシュコマンドの主要なものを紹介します。

コマンド	説明
`/plan`	計画モードに切り替え
`/ask`	読み取り専用モードに切り替え
`/model <モデル名>`	AI モデルを切り替え
`/max-mode [on\|off]`	Max モードの切り替え
`/new-chat`	新しい会話を開始
`/compress`	会話を要約してコンテキストを解放
`/vim`	Vim キーバインドの切り替え
`/mcp list`	MCP サーバーの一覧表示
`/rules`	ルールの作成・編集
`/usage`	使用量の確認
`/quit`	終了

全コマンドの一覧は公式リファレンスにあります。

設定ファイル

CLI の設定は ~/.cursor/cli-config.json に保存されます。Vim モードの有効化や、AI に許可する操作の制御などを設定できます。

{
  "version": 1,
  "editor": {
    "vimMode": false
  },
  "permissions": {
    "allow": [],
    "deny": []
  }
}

permissions の詳しい書き方は、次のセクションで解説します。

設定ファイルのパスは、環境変数 CURSOR_CONFIG_DIR で変更できます。詳細は設定リファレンスを参照してください。

スクリプトからAIを自動実行する（ヘッドレスモード）

Cursor CLI には、人が画面を見ずにスクリプトから AI を自動実行するヘッドレスモードがあります。

ヘッドレスモードを使えば、「毎朝コードレビューを自動で走らせる」「テスト失敗時に AI が自動で原因を調査する」といった自動化が実現できます。

ヘッドレスモードの基本

-p（--print）フラグを付けて実行すると、ヘッドレスモードになります。対話的な入力を待たず、結果を出力して終了します。

agent -p "このプロジェクトのセキュリティ問題を調査して"

ただし、-p だけでは AI はファイルを変更しません。コードの読み取りや分析は行えますが、ファイルへの変更は「提案」にとどまり、実際には適用されません。

AI にファイルの修正やコマンドの実行まで任せたい場合は、--force（-f）フラグを追加します。

agent -p --force "このコードをES6構文にリファクタリングして"

この違いは重要です。-p だけなら「分析と提案の出力」、-p --force なら「実際のファイル変更やコマンド実行」になります。--force は、明示的に拒否されていない操作をすべて許可するフラグです。使う場合は必ず Git でブランチを切ってから実行してください。万が一おかしな変更があっても、元に戻せます。

公式ドキュメントに詳しい説明があります。

出力フォーマット

ヘッドレスモードの出力は 3 つの形式から選べます。用途に応じて使い分けてください。

フォーマット	指定方法	内容
`text`（デフォルト）	`--output-format text`	最終的な回答のテキストだけを出力
`json`	`--output-format json`	実行結果を JSON オブジェクトとして出力
`stream-json`	`--output-format stream-json`	実行中のイベントを 1 行ずつ JSON で出力

text は結果をそのまま読みたいときに使います。

agent -p ".ignoreの行数をカウントして"

json はスクリプトで結果を処理したいときに便利です。エラーの有無や実行時間などが構造化されたデータとして返ってきます。

agent -p --output-format json ".ignoreの行数をカウントして"

出力される JSON には、以下のようなフィールドが含まれます。

{
  "type": "result",
  "subtype": "success",
  "is_error": false,
  "duration_ms": 45000,
  "duration_api_ms": 45000,
  "result": ".ignoreの行数は13行です",
  "session_id": "abc123"
}

duration_ms は全体の実行時間（ミリ秒）、duration_api_ms は API 呼び出しの時間です。2026 年 2 月時点では、公式ドキュメントによると両者は同じ値になります。

stream-json は、実行中のイベントを 1 行に 1 つの JSON として出力する形式です（GUIで実行する際は、AIの進捗はある程度見ることができますが、CUI版では結果しか返ってこないため、CUI版でも進捗を見たいときはこのオプションを使います）。

権限設定

ヘッドレスモードでは、AI に許可する操作を細かく制御できます。プロジェクトのルートに .cursor/cli.json を作成し、権限を記述します。

{
  "permissions": {
    "allow": [
      "Read(src/**/*.ts)",
      "Write(src/**/*.ts)",
      "Shell(npm)",
      "Shell(git)"
    ],
    "deny": [
      "Write(.env*)",
      "Shell(rm)"
    ]
  }
}

権限は 5 つの型があります。

型	説明	例
`Read`	ファイルの読み取り	`Read(src/*/.ts)`
`Write`	ファイルの書き込み	`Write(src/**)`
`Shell`	シェルコマンドの実行	`Shell(npm)` で npm の全サブコマンドを許可
`WebFetch`	外部 URL へのアクセス	`WebFetch(api.example.com)`
`Mcp`	MCP ツールの使用	`Mcp(github:create_issue)`

deny（拒否）ルールは allow（許可）ルールより優先されます。上の例では、src 配下の TypeScript ファイルへの読み書きと npm / git コマンドは許可しつつ、.env ファイルへの書き込みと rm コマンドは拒否しています。

自動化スクリプトでは、必要最小限の権限だけを許可する設定にしておくのが安全です。詳しくは権限設定のリファレンスを参照してください。

スクリプトへの組み込み例

実際にシェルスクリプトに組み込む例を見てみましょう。コードレビューを実行し、結果をファイルに保存するスクリプトです。

#!/bin/bash

# APIキーの設定
export CURSOR_API_KEY=your_api_key_here

# コードレビューを実行し、結果をJSONで取得
RESULT=$(agent -p --output-format json "セキュリティ上の問題がないかレビューして")
echo "$RESULT" > review_result.json

# エラーが発生したかチェック（jq は JSON を操作するコマンドラインツール）
IS_ERROR=$(echo "$RESULT" | jq -r '.is_error')
if [ "$IS_ERROR" = "true" ]; then
  echo "レビュー中にエラーが発生しました"
  exit 1
fi

echo "レビュー完了: review_result.json に結果を保存しました"

モデルを指定して、ファイル修正まで行う場合は以下のようになります。

# 特定のモデルを使い、ファイル修正を許可して実行
agent -p --force -m gpt-5 --output-format json "テストを追加して"

-m でモデル名を指定し、--force でファイル修正を許可しています。--output-format json で結果を構造化データとして受け取れます。利用可能なモデルの一覧は agent --list-models で確認してください。

GitHub Actionsと組み合わせて自動化する

GitHub Actions は、GitHub が提供する自動化の仕組みです。「プルリクエストが作られたら自動でテストを走らせる」「コードが push されたら自動でデプロイする」といった処理を設定ファイルに書くだけで実現できます。設定は YAML（ヤムル）という、インデントで構造を表すテキスト形式で記述します。

Cursor CLI をこの仕組みに組み込むと、「プルリクエストを AI が自動でレビューする」「テスト失敗時に AI が原因を調査する」といったワークフローが作れます。

準備：API キーの設定

GitHub Actions から Cursor CLI を使うには、API キーを GitHub Secrets に登録しておく必要があります。

Cursor のダッシュボードにアクセスし、Integrations > User API Keys で API キーを生成する
GitHub のリポジトリ画面で Settings > Secrets and variables > Actions を開く
「New repository secret」をクリックする
Name に CURSOR_API_KEY、Secret に生成した API キーを入力して保存する

これで、ワークフロー内から ${{ secrets.CURSOR_API_KEY }}$ として API キーを参照できます。

ワークフローの基本構成

GitHub Actions のワークフローは、リポジトリの .github/workflows/ ディレクトリに YAML ファイルとして置きます。基本的な構造は以下のとおりです。

name: ワークフローの名前
on:
  # いつ実行するか（トリガー）
  pull_request:
    types: [opened]

jobs:
  # 実行する処理
  review:
    runs-on: ubuntu-latest
    steps:
      - name: ステップ1の名前
        run: echo "ここにコマンドを書く"

on がトリガー（いつ実行するか）、jobs が実行する処理の本体です。steps の中に、順番に実行したいコマンドを書いていきます。

PR レビューを自動化する

プルリクエストが作成されたときに、Cursor CLI でコードレビューを自動実行するワークフローの例です。

name: Cursor Code Review
on:
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review]

jobs:
  review:
    if: github.event.pull_request.draft == false
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
      contents: read
      issues: write

    steps:
      - name: Checkout PR
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Install Cursor CLI
        run: |
          curl https://cursor.com/install -fsS | bash
          echo "$HOME/.cursor/bin" >> $GITHUB_PATH

      - name: Run Cursor Review
        env:
          CURSOR_API_KEY: ${{ secrets.CURSOR_API_KEY }}
        run: |
          agent -p --output-format json \
            "Review the changes in this PR for security issues, \
             code quality, and best practices. \
             Provide a detailed report."

ポイントを説明します。

on.pull_request でプルリクエストの作成・更新をトリガーにしている
if: github.event.pull_request.draft == false でドラフト PR を除外している
Cursor CLI のインストール後、$HOME/.cursor/bin を $GITHUB_PATH に追加している。これにより、以降のステップで agent コマンドが使える
レビューだけなので --force は付けていない（ファイルを変更しないため）

GitHub Actions 環境では、CLI のバイナリは $HOME/.cursor/bin に配置されます。ローカルの ~/.local/bin とはパスが異なるので注意してください。

さらに使いこなす

ここまでの章で学んだ基本を土台に、クラウドで AI を動かす方法、自動処理を組み込む仕組み、プラグインによる機能拡張、外部サービスとの連携を身につけましょう。

自分のPCを使わずにAIに開発させる（Cloud Agents）

Cloud Agent（クラウドエージェント）は、クラウド上の仮想マシンで AI を動かす機能です。自分の PC のリソースを使わずに、AI にコードを書かせられます。

https://cursor.com/ にアクセスしてみましょう。

ここでは、ローカル環境を使わずに、クラウド上のクラウド環境でCursorを使うことができます。

通常の Agent モードでは、AI が作業している間エディタを開いたまま待つ必要がありました。Cloud Agent なら、タスクをクラウドに投げて自分は別の作業に取り掛かれます。複数の Cloud Agent を同時に起動して、異なるタスクを並列に進めることも可能です。

仕組み

Cloud Agent は、クラウド上の仮想マシン（Ubuntu ベース）で動きます。起動すると GitHub や GitLab からリポジトリがクローンされ、専用のブランチが作成されます。AI はそのブランチ上でコードの読み書きやコマンドの実行を行い、作業が終わるとプルリクエストを作成してくれます。ローカル環境とは完全に分離されているため、手元のコードが変わることはありません。

利用条件

Cloud Agent を使うには、以下の条件があります。

プラン: Pro プラン以上が必要
リポジトリ連携: GitHub または GitLab アカウントを Cursor に接続し、リポジトリの読み書き権限を付与する
従量課金の有効化: Max モード対応のモデルで動作するため、Cursor Settings で従量課金を有効にしておく

起動方法

Cloud Agent の起動方法は2つあります。

方法1: ブラウザから起動する

https://cursor.com/ にアクセスし、Webアプリ上からタスクを入力して実行します。ローカルにCursorをインストールしていなくても利用できます。

方法2: ローカルのチャットウィンドウから起動する

チャットパネルを開き、以下の画像のようにエージェント入力欄のプルダウンから「Cloud」を選択します。やってほしいタスクを自然言語で入力して送信してください。

起動すると、クラウド上に環境が構築され、AI がタスクに取り掛かります。進捗はエディタ内のパネルや Cursor の Web アプリからリアルタイムで確認できます。

環境の設定（environment.json）

Cloud Agent はクラウド上で動くため、ローカルの開発環境とは異なります。依存パッケージのインストールやサーバーの起動など、環境構築の手順を設定ファイルで指定できます。

プロジェクトルートに .cursor/environment.json を作成してください。

{
  "install": "npm install",
  "start": "npm run dev",
  "terminals": [
    {
      "name": "dev-server",
      "command": "npm run dev",
      "ports": [3000]
    }
  ]
}

install でパッケージのインストールコマンド、start で初期化コマンド、terminals でバックグラウンドプロセスを定義します。リポジトリにコミットしておけば、チームメンバーも同じ環境で Cloud Agent を使えます。

使い方のコツ

Cloud Agent は万能ではありません。「このコンポーネントに props を追加して」「このテーブルにカラムを足すマイグレーションを書いて」のように、ゴールが具体的な小さいタスクで力を発揮します。複雑な設計判断が必要な大きなリファクタリングには不向きです。

指示は具体的に書いてください。「どのファイルのどのパターンに従って実装してほしいか」まで伝えると成功率が上がります。

AIの行動の前後に自動で処理を挟む（Hooks）

Hooks（フック）は、AI エージェントの動作の前後に、自分で用意したスクリプトを自動実行する仕組みです。

「AI がファイルを編集したあとに自動でフォーマッターを走らせたい」「危険なコマンドを実行しようとしたらブロックしたい」といった処理を、プログラムで確実に制御できます。Rules は AI への「お願い」なので無視される可能性がありますが、Hooks はプログラムとして必ず実行される点が異なります。

設定方法

Hooks はプロジェクトルートの .cursor/hooks.json で設定します。基本的な構造は以下のとおりです。

{
  "version": 1,
  "hooks": {
    "afterFileEdit": [
      {
        "command": "npx prettier --write {file{'}'}"
      }
    ]
  }
}

この例では、AI がファイルを編集するたびに Prettier（コードフォーマッター）が自動で実行されます。

処理を挟めるタイミングには、プロンプト送信前（beforeSubmitPrompt）、シェルコマンド実行前（beforeShellExecution）、ファイル編集後（afterFileEdit）、タスク完了時（stop）などがあります。before 系のイベントでは処理の許可・拒否を返すことで、エージェントの行動を制御できます。

実践例：ファイル編集後に自動コミットする

afterFileEdit と stop を組み合わせると、AI の作業を自動的に Git コミットできます。

{
  "version": 1,
  "hooks": {
    "afterFileEdit": [
      {
        "command": "git add -A"
      }
    ],
    "stop": [
      {
        "command": "git commit -m 'AI による変更'"
      }
    ]
  }
}

AI がファイルを変更するたびにステージングし、タスク完了時にまとめてコミットする流れです。

Hooks の詳しい仕様は公式ドキュメントにまとまっています。

便利な機能をまとめて追加する（Plugins）

Plugins（プラグイン）は、Skills、Rules、MCP サーバー、Hooks などの機能をひとまとめにしたパッケージです。

たとえば Figma と連携するには、MCP サーバーの設定、Skills の作成、Rules の追加など複数の設定が必要でした。Plugins なら、こうした設定がワンクリックで完了します。

Plugin Marketplace

Cursor Marketplace から、公式パートナーやコミュニティが作ったプラグインをインストールできます。Figma、Stripe、AWS、Linear、Vercel など、設計からデプロイまで幅広い連携先が用意されています。

インストール方法

cursor.com/marketplace にアクセスする
使いたいプラグインを選ぶ
「Add to Cursor」をクリックする

MCP サーバーを含むプラグインでは、インストール後に認証が必要です。Cursor Settings > Tools & MCP Servers から該当する MCP サーバーの「Connect」をクリックして認証してください。

プラグインの利点

たとえば Figma プラグインをインストールすると、MCP サーバーが設定されるだけでなく、「デザインデータをどう解釈してコードに変換するか」という Skills も一緒にインストールされます。MCP サーバーだけを手動設定するより、AI の出力品質が高くなるのがプラグインの利点です。

外部サービスとの連携（Slack等）

Cursor は Slack や Linear などの外部サービスと連携できます。連携方法は「Cursor 公式の Slack アプリを使う方法」と「MCP サーバーを通じて連携する方法」の 2 つです。

Slack 連携（公式アプリ）

Cursor は公式の Slack アプリを提供しています。Slack のチャンネルやスレッドで @Cursor とメンションするだけで、Cloud Agent が起動してタスクを実行します。

たとえば、Slack でバグについて議論しているスレッドに @Cursor このバグを修正して と投稿するだけで、AI がリポジトリをクローンし、修正を行い、プルリクエストを作成します。完了すると PR のリンクが Slack に投稿されます。

Cloud Agent と同じ仕組みで動くため、小さく具体的なタスクに向いています。

この記事を書いた人

理事長

せお丸（田中淳介）

AI駆動開発協会代表理事サイバーフリークス株式会社代表取締役

著書：「AI駆動開発入門」 ※2026年出版予定
テック系Youtuber「せお丸」として活動（チャンネル登録者６万人）
システム開発会社代表取締役
エンジニア歴20年以上

← ブログ一覧に戻る

Cursor入門ガイド｜初心者向けにCursorの基本から応用まで完全解説【2026年 最新版】

Cursorとは

この記事で学べること

対象の読者（非エンジニアでも分かる入門書です）

料金プラン

無料プラン

有料プラン

法人向けプラン

インストールと初期設定

インストール

初回設定画面

セットアップの流れ

日本語化の設定

セキュリティ設定（Privacy Mode）

Privacy Modeとは

3つの設定オプション

Privacy Modeの有効化手順

企業で使う場合のポイント

基本的な使い方

Agentsタブ

Editorタブ

AIとのチャット ― まずは話しかけてみる

4つのモードの使い分け（Agent / Ask / Plan / Debug）

Agentモード（デフォルト）

Askモード

Planモード

Debugモード

AIに見てほしいファイルや情報を指定する（@メンション）

AIモデルの切り替え

Maxモード

複数エージェントの並列実行

やり方1: 複数のチャットタブで別々のタスクを進める

やり方2: git worktreeで隔離して並列実行する

やり方3: 同じタスクを複数モデルに同時に投げる（Best of N）

コード編集機能

Tab補完 ― AIがコードの続きを予測する

基本的な使い方

Tab補完の精度を上げるコツ

ブラウザ連携 ― 見た目を確認しながらAIに修正させる

内蔵ブラウザの開き方

AIがブラウザを操作する

見た目を見せながら修正を指示する

ビジュアルエディタ(画面のデザイン調整機能)

ビジュアルエディタの使いどころ

AIの動きをカスタマイズする

「こうしてほしい」をAIに事前に伝える（Rules）

ルールの種類

Project Rules

AGENTS.md

Team Rules

ルールの実例集

User Rules の例

Project Rules の例

ルールを書くときのコツ

コミュニティのルールを活用する

よく使う指示をショートカット化する（Commands）

Commands の作成方法

コマンドの例

Commands の保存場所

Rules と Commands の使い分け

AIにスキルを追加する（Skills）

Commands との違い

Skills の構造や書き方

AIに専門的な役割を持たせる（Subagents）【超重要】

ビルトインサブエージェント

カスタムサブエージェントの作り方

サブエージェントの呼び出し方

筆者が実際に使っているサブエージェント

FigmaやGitHubなど外部ツールとAIを繋ぐ（MCP）

対応サービスの例

MCP の設定方法

実践: Figma MCP を設定する

セキュリティに関する注意

AIに見せたくないファイルを除外する（.cursorignore）

.cursorignore の作り方

.cursorignore が影響する範囲

Cursor CLI ― 画面なしでAIを動かす

ターミナルからAIと対話する

インストール

ログイン

Cursor入門ガイド｜初心者向けにCursorの基本から応用まで完全解説【2026年最新版】