コア機能詳解 ── Tab・Composer・Chat・Plan Mode

対象読者: Cursorを使い始めて数週間〜数ヶ月の開発者。基本操作は知っているが、各機能の「なぜ」「いつ」「どう使い分けるか」を深く理解したい方。

Cursorには、補完・Composer・Chat・Plan Modeという4つの主要な入力インターフェースがある。それぞれが独立した機能ではなく、「AIとの対話をどの粒度・どの権限で行うか」という設計思想の上に構築されている。本章では、各機能の内部動作を理解しながら、日々の開発でどう使い分けるかを具体例を交えて解説する。

---

Section 1: Tab補完 ── 「次の一手」の予測

Cursorの Tab補完は、多くの開発者が「ただの補完ツール」として過小評価している機能だ。しかし実際には、コードの補完を超えて「次の編集操作そのもの」を予測するシステムである。

従来のコード補完（GitHub Copilotの初期実装など）は「カーソル位置に続くコードを予測する」ものだった。Cursorの Tab補完はそれとは異なり、現在のカーソル位置だけでなく、直前の編集履歴・差分・周辺コードのコンテキストを組み合わせて「次にどこを・どう変更するか」を推定する。

たとえば、以下のような関数名をリネームしているとしよう。

// Before: fetchUserData という関数をリネームしている最中
function getUserProfile(userId: string): Promise<User> {
  return fetchUserData(userId);  // ← カーソルはここにある
}

fetchUserData を getUserById に変更しようとカーソルを当てた瞬間、Cursorは「直前の編集でfetchUserDataをgetUserByIdにリネームした」という文脈を把握し、この行の fetchUserData を getUserById に変更する補完を提示する。単なる文字列予測ではなく、意図の予測だ。

マルチライン補完とカーソル位置の予測

Tab補完は1行に留まらない。連続する数行の変更を一度に提案することができ、さらに「その補完を受け入れた後、次に編集すべき場所」までカーソルをジャンプさせる機能を持つ。

// interface に新しいフィールドを追加すると...
interface UserProfile {
  id: string;
  name: string;
  email: string;
  createdAt: Date;  // ← 今追加した
  // ↑ ここでTabを押すと、次の変更候補箇所（例: バリデーション関数）へジャンプを提案
}

Tab キーで補完全体を受け入れ、Ctrl+→（macOS: Option+→）で補完を単語単位・フレーズ単位で部分的に受け入れることができる。補完が長い場合、先頭部分だけ受け入れて残りを手で書き直す、という使い方が効率的だ。

「補完に頼りすぎる」という罠

一点、経験豊富な開発者ほど気をつけるべきことがある。Tab補完は非常に滑らかに動作するため、コードの意図を理解せずに連続してTabを押し続けるという状態に陥りやすい。補完が正しいかどうかを確認する思考コストを省いてしまうのだ。

特に、セキュリティに関わるコード（認証・認可・入力バリデーション）や、ビジネスロジックの核心部分については、補完を受け入れる前に「このコードが正しいか」を自分の言葉で説明できるか確認する習慣を持つことを推奨する。Cursorはあくまで「次の一手」を提案するツールであり、最終的な判断は人間の側にある。

---

Section 2: Composer（Agent Mode）── AIを開発者として動かす

Composerは、Cursorの中で最も「AIを本格的な開発者として扱う」に近いインターフェースだ。単なる質問・回答のやりとりではなく、タスクを渡して成果物を受け取るという形式の対話を提供する。

ComposerとAgent Modeの違い

Composerは「タスク指向の会話」であり、ユーザーが指示を出すとAIがコードを生成・編集し、その変更を diff 形式でユーザーに提示して承認を求める仕組みだ。ここまでは「高機能なコード生成ツール」に過ぎない。

Agent Modeはその上に「自律実行の権限」を追加したものだ。Agent Modeをオンにすると、Composerは次のことができるようになる。

• ファイルシステムの読み書き: プロジェクト内の任意のファイルを読み込み、新規ファイルを作成し、既存ファイルを変更する
• ターミナルコマンドの実行: npm install、npx prisma migrate、テストの実行、ビルドなど
• ブラウザの使用: ドキュメントサイトの参照、エラーメッセージの検索
• エラーのフィードバックループ: コマンドを実行してエラーが出たら、自動的にそのエラーを読み込んで修正を試みる

これは「AIが開発者として独立して作業し、人間はPM（プロダクトマネージャー）または技術承認者として振る舞う」という分業モデルを実現する。

具体例：Stripe 決済フォームの追加

次のような指示を Agent Mode の Composer に与えたとしよう。

Stripeの支払いフォームを追加して。
要件：
- クレジットカード情報の入力フォーム
- Stripe Elements を使用
- 決済完了後に /success ページへリダイレクト
- エラーハンドリング付き

Agent Mode はこれを受けて、以下のステップを自律的に実行する。

1. package.json を読み込み → @stripe/stripe-js が未インストールと判断
2. npm install @stripe/stripe-js @stripe/react-stripe-js を実行
3. src/components/ を探索 → 既存のフォームコンポーネント構造を把握
4. src/components/PaymentForm.tsx を新規作成
5. src/pages/checkout.tsx を読み込み → PaymentForm を組み込む
6. src/pages/success.tsx が存在しない → 新規作成
7. .env.example に NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY を追記
8. テストコマンドを実行 → TypeScript の型エラーを検出 → 自動修正

人間が行う作業は「指示を出す」「生成されたコードを diff で確認して承認する」「Stripe の API キーを設定する（機密情報のため）」の3つだけだ。

Composer 2（2026年3月）の進化

2026年3月にリリースされた Composer 2 では、マルチファイルにまたがる変更の一貫性が大幅に改善された。以前のバージョンでは「AファイルとBファイルの変更が整合していない」という問題が頻発していたが、Composer 2 はプロジェクト全体の依存グラフを把握した上で変更計画を立てるため、型の不整合や import のミスが劇的に減少している。

---

Section 3: Chat ── リアルタイムの技術相談

ChatとComposerは、どちらも「AIと会話する」インターフェースに見えるが、その目的はまったく異なる。**Chatは「理解するための対話」、Composerは「実装するための対話」**だ。

Chat の使い方と @コンテキスト参照

Chatの強力さは、@記法によるコンテキスト参照にある。ファイル名・コードベース全体・外部ドキュメント・Gitの履歴など、様々な情報源を会話に取り込むことができる。

記法	参照先	典型的な用途
@filename.ts	特定のファイル	「このファイルのこの関数について説明して」
@codebase	プロジェクト全体	「認証周りの実装はどこにある？」
@docs	公式ドキュメント	「Next.js 15 の Server Actions の書き方」
@web	Web検索	「最新のReact Router v7の変更点」
@git	Gitの差分・履歴	「先週のコミットで何を変えたか」

@codebase は特に強力で、「このプロジェクトのエラーハンドリングはどのパターンを使っているか？」という質問に対して、コードベース全体を走査して一貫したパターンを見つけ出す。

インライン Chat（Ctrl+K）

コードエディタ上で特定の範囲を選択して Ctrl+K（macOS: Cmd+K）を押すと、その選択範囲に対してのみ変更を指示できるインライン Chatが起動する。「この関数をリファクタリングして」「このロジックにコメントを追加して」といった局所的な変更に最適だ。

いつ Chat を使い、いつ Composer を使うか

質問の種類                          → 使うツール
─────────────────────────────────────────────────
「なぜこのエラーが出るのか？」       → Chat
「このアルゴリズムを理解したい」     → Chat
「○○の実装方法を教えて」           → Chat（まず理解してから Composer へ）
「このコードを実装して」             → Composer
「バグを修正して」                  → Composer
「テストを追加して」                → Composer
「このファイルを説明して」           → Chat (@filename)
「この設計の問題点を指摘して」       → Chat
「リファクタリングを実行して」       → Composer（Plan Mode 推奨）

大まかな判断基準として、ファイルへの書き込みが発生するかどうかがある。書き込みが伴うなら Composer、読み取りと理解が目的なら Chat、という切り分けが実用的だ。

---

Section 4: Plan Mode ── 承認してから実行

大きなリファクタリングや、既存コードへの影響範囲が広い変更を Composer の Agent Mode でそのまま実行しようとすると、「気づいたら意図しないファイルが変更されていた」という事態が起きることがある。これを防ぐのが Plan Mode だ。

Plan Mode の仕組み

Plan Mode をオンにすると、Composer は即座に実装を始めない。まず「何をするか」の計画（Plan）を自然言語と箇条書きで提示し、ユーザーの承認を待つ。承認後に初めて実装が始まる。

sequenceDiagram
    actor User as ユーザー
    participant Composer as Composer (Plan Mode)
    participant FS as ファイルシステム
    participant Terminal as ターミナル

    User->>Composer: タスク指示<br/>「認証システムをJWTからセッションベースに移行して」
    Note over Composer: コードベースを分析中...

    Composer->>User: 📋 Plan を提示<br/>1. src/auth/jwt.ts を削除<br/>2. src/auth/session.ts を新規作成<br/>3. 12ファイルの import を更新<br/>4. テストを実行して確認

    User->>Composer: ✅ Approve（承認）<br/>または ✏️ Plan を修正してから承認

    Composer->>FS: src/auth/session.ts を作成
    Composer->>FS: 12ファイルの import を更新
    Composer->>Terminal: npm test を実行
    Terminal-->>Composer: ❌ 3テスト失敗
    Composer->>FS: 失敗箇所を自動修正
    Composer->>Terminal: npm test を再実行
    Terminal-->>Composer: ✅ すべてパス
    Composer->>User: 実装完了 ✅

Plan Mode を使うべき場面

以下のような作業では、Plan Mode を必ず有効にすることを推奨する。

• 大規模リファクタリング: 影響ファイルが5つ以上になる変更
• 依存関係の変更: ライブラリのメジャーバージョンアップ
• データベースマイグレーション: スキーマ変更を伴う作業
• 認証・セキュリティ関連: 変更のスコープを事前に確認したい場合

逆に、新しいコンポーネントを1つ追加する、既存の関数にパラメータを1つ追加するといった「影響範囲が限定的な変更」では Plan Mode を使わない方が速い。

Plan を修正する力

Plan Mode の真の価値は「承認する前にプランを修正できる」点にある。たとえば Composer が提示した計画に「不要なファイルを削除する」という項目が含まれていた場合、承認前にその項目を除外するよう指示できる。これにより、AIの自律性と人間のコントロールのバランスを保てる。

---

Section 5: Yolo Mode と権限管理

Agent Mode には、さらに強力（かつ危険）な動作モードとして Yolo Mode が存在する。

Yolo Mode とは何か

通常の Agent Mode では、ターミナルコマンドを実行する前にユーザーへの確認を求める。Yolo Mode をオンにすると、この確認ステップを省略してコマンドを自動実行する。名前の通り「やってみよう（You Only Live Once）」の精神で、AIが自律的に実行し続ける。

いつ使い、いつ使わないか

Yolo Mode が有効な場面は限られている。

使ってよい場面:

• 開発用の使い捨て環境（Docker コンテナ内、CI/CD のサンドボックス）
• npm install、npx create-* など副作用が予測可能なコマンドのみ
• 本番環境とは完全に隔離された環境

使うべきでない場面:

• rm -rf を含む可能性がある操作
• データベースへの書き込みが伴う操作
• 本番環境の認証情報が存在するプロジェクト
• 未知のスクリプトやツールを実行する可能性がある場合

権限の粒度設定

Cursor の設定（Settings > Features > Agent）では、Agent Mode が実行できる操作の粒度を制御できる。「ファイルの読み取りは自動、書き込みは確認、ターミナルは毎回確認」といったカスタム権限セットを設定することで、利便性とセキュリティのバランスを自分でチューニングできる。

プロジェクトの性質（個人の実験的プロジェクトか、チームの本番コードベースか）に応じて、権限設定を使い分けることを強く推奨する。

---

次章予告: 各機能の動作を最大限に引き出すためには、AIに「どのようにコードを書いてほしいか」を伝える仕組みが必要だ。次章では、Cursor Rules を使ってプロジェクト固有のコーディング規約をAIに覚え込ませる方法を解説する。

＋ － ⟳ ✕