ToolArc

ToolArc — AIと開発のTips・比較

※記事により広告・アフィリエイトリンクを含む場合があります。

Series:Cursor 開発シリーズ

Cursorモード使い分けガイド|Agent・Plan・Askをいつ切り替える?

CursorのAgent・Plan・Askモードの違いと使い分けを初心者向けに整理。悩み別の選択フローと向き不向き表で、意図しない実装を防ぐモード選びが分かります(実測運用ベース)。

  • Cursor
  • モード使い分け
  • Agentモード
  • Planモード
  • Askモード
  • 3

Cursorを使い始めると、「今はどのモードで頼めばいいのか」が最初のつまずきになりやすいです。
読むだけのつもりでPlanやAgentを選ぶと、意図しない実装やファイル作成まで進むことがあります。

本記事では、確認・設計・実装の3軸でモードを選ぶ流れを整理します。分散していたTipsの要点を1本にまとめ、詳細は既存記事へ送ります。シリーズ入口は Cursor 開発ガイド です。

この記事の結論

  • 「読むだけ→Ask、設計→Plan、実装→Agent」が基本の切り替え軸
  • 迷ったら「今やりたいのは確認・設計・実装のどれか」を1回自問してから選ぶ
  • Planは「生成→確認→build前修正」の3段階で使うと、やり直しコストを下げやすい
  • モードを間違えると意図しない実装が走りやすいため、依頼前の選択が重要
  • モード名・UIは変更されやすいので、本記事は執筆時点の名称を前提にする

Cursorのモード一覧と向き不向き表(執筆時点)

Cursorには大きく Ask / Plan / Agent があります(執筆時点)。画面上の名称や配置は変わることがあるため、最新の呼び方は公式ドキュメントで確認してください。いわゆるComposer表記も、執筆時点のUIでは扱いが変わっている可能性があります。

モード主な用途「読むだけ」の依頼をしたとき向く人・場面向かない場面
Ask質問・調査・確認内容を読んで回答する資料・コードを先に理解したいときファイル作成や実装まで任せたいとき
Plan設計・実装計画の立案計画を立てたうえで実装に進みやすい差分が不安で、方針を先に固めたいとき読むだけで終わらせたいとき
Agent自律的なコード実装・ファイル操作作成・編集まで実行しやすい方針が決まり、横断変更を任せたいときまだ範囲が曖昧な調査段階
Composer(表記は要確認)執筆時点のUI要確認画面上の現行名称を公式で確認してから使う名称だけを頼りに断定しない

筆者の運用感では、「読むだけ」の依頼をPlanで出すと、読んだあとに実装や記事作成まで進むことがあります。まず確認したいだけならAskが意図に合いやすいです。Askの詳細手順は CursorのAskモードTips を参照してください。

Agentをどこまで任せるかは、Cursor Agentは記事一括公開と基盤横断変更に絞って使う もあわせて読むと方針が立てやすいです。途中で止まったときの戻り方は Cursor Agentが止まったときの復旧Tips にまとめています。


迷ったときの選択フロー(悩み→モード→次に読む)

モード選びで迷ったら、次のフローで一度だけ振り分けます。

今やりたいことは?
├─ 資料・コードを読んで確認したい
│   → Ask(詳細: /blog/cursor-ask-mode-tips)
├─ 実装前に計画を立てたい・差分が不安
│   → Plan(本記事の次節へ)
└─ ファイル作成・横断変更まで任せたい
    → Agent(詳細: /blog/cursor-agent-scope-tips)
悩み選ぶモード次に読む
Daily Noteやsourceを先に読ませたいAsk/blog/cursor-ask-mode-tips
build前に方針と変更範囲を固めたいPlan本記事の次節
Planをファイルに残して振り返りたいPlan → 保存/blog/cursor-plan-mode-md-save-tips
方針が決まったあとに実装を任せたいAgent/blog/cursor-agent-scope-tips
ルールや設定を先に整えたい(モード選定の前準備)#1 ルール#3 設定

「確認なのか、設計なのか、実装なのか」を言語化してから依頼すると、余計な実行を防ぎやすくなります。


Planモードの基本運用: build前に確認・修正する

Planモードは、コードを変える前に実装方針(Plan)を先に出すモードです。
生成されたPlanは、確認・修正してからbuildするのが基本です(挙動は執筆時点のもの、要確認)。

Planモードで依頼する
    ↓
Plan本文を読む(何をどの順で変更するか)
    ↓
問題なし → build実行
修正が必要 → 同じPlanモードで追指示 → 再確認 → build実行

Planが出た段階では、まだコードは変わっていないことが多いです。次の点を確認し、必要なら同じチャットで追指示します。

確認ポイント修正例
変更ファイルの範囲が広すぎるlib/config.ts だけに絞ってください」
対応順序が違う「Aの変更を先にしてからBを変えてください」
不要な処理が含まれている「〇〇の削除はこのタスクでは不要です」
前提が抜けている「既存の〇〇関数は変えずに追加してください」

Planを確認せずにbuildすると、意図と違う変更が入ったときに差し戻しが必要になります。
build前の数分の確認が、後の修正コストを下げます。大きな差分が出そうな変更(リファクタ・ファイル移動・型の変更など)は、Planの段階で範囲を絞るか、タスクを分割するのが無難です。

手順の要点は次の4つです。

  1. Planモードで実装方針を出させる
  2. Plan本文で変更ファイル・順序・不足・誤りを確認する
  3. 修正が必要なら同じPlanモードで追指示する
  4. Planに問題がなければbuildを実行する

モード切り替えの実践パターン(Ask→Plan→Agent)

実務では、1つのモードに固定せず、段階ごとに切り替えると安定しやすいです。

1. Askで先読みする

Daily Note・AIログ・source.md など、先に理解したい資料をAskで添付します。

(Askモードで)
この source.md を読んで、構成のポイントを整理してください。

実装の依頼はせず、「読んで確認する」だけに絞ります。詳細手順は AskモードTips を参照してください。

2. Planで方針を固める

内容確認が終わったらPlanに切り替え、構成や実装方針を出します。

(Planモードに切り替えて)
先ほどの source.md をもとに、変更方針を作ってください。
buildはまだしないでください。

出てきたPlanは、前節のとおりbuild前に確認・修正します。

3. 必要ならPlanを保存し、Agentで実装する

チャット上のPlanは時間が経つとさかのぼりにくくなります。複数タスクを続けるときは、.plan.md として残す運用が向きやすいです。保存手順の詳細は Plan出力を.plan.mdで保存するTips に任せます。

方針が固まったらAgentへ切り替え、Planの範囲内で実装を依頼します。参照ファイルを渡すときは Cursorの@記法Tips(#6)も役立ちます。


チェックリスト+まとめ・次に読む

依頼前チェックリスト

  • 今やりたいのは「確認 / 設計 / 実装」のどれかを言語化した
  • 読むだけならAsk、方針固めならPlan、実装ならAgentを選んだ
  • Planを使う場合、build前に変更範囲・順序・不要処理を確認した
  • 修正が必要なら、同じPlanモードで追指示してからbuildした
  • 大きな差分が出そうなタスクは分割を検討した
  • Agentに渡す範囲が広すぎないか確認した(必要ならscope記事へ)

FAQ

Q. AskとPlanはどちらを使えばよいですか?
A. 読んで確認するだけならAsk、実装前の計画を立てたいならPlanです。読むだけの依頼をPlanですると、実装まで進むことがあります。

Q. Planモードで出た計画はそのまま実行してよいですか?
A. build前に変更範囲・順序・不要処理を確認し、必要なら同じチャットで追指示してから実行するのが基本です。

Q. Composerモードはなくなったのですか?
A. 執筆時点のUIでは名称・配置が変わっている可能性があります。最新の名称は公式ドキュメントで確認してください。

まとめ

  • モード選びの軸は「確認・設計・実装」の3つ
  • Askで読む → Planで固める → Agentで実装、が安定しやすい流れ
  • Planは生成だけでなく、build前の確認・修正までセットで使う

次に読む


本記事の内容はCursorの仕様変更により古くなる可能性があります。モード名称・UI・挙動は執筆時点(2026-07-17)のものです。最新情報はCursor公式ドキュメントをご確認ください。