Cursor Agent Modeの使い方｜Ask/Plan/Agentの違いと使い分け

Cursorのチャットは、Ask・Plan・Agentの3モードを使い分ける設計で、デフォルトはAgentです。
Askはコードを変更せずに読み取りだけを行い、Planは調査結果をもとに計画書を作るだけ、Agentは複数ファイルの編集やコマンド実行まで進めます。
Shift+Tabで会話の途中でも切り替えられるので、まずAskで理解し、Planで段取りを固めてからAgentに渡す流れにすると、作業はぐっと安定するでしょう。
説明だけ欲しいのにAgentのまま進めてしまい、関数の意味を聞いたつもりが該当ファイルを書き換えられて取り消しに追われた、という失敗は避けたいものです。

3つのモードでできること

Cursorのチャットは、Ask・Plan・Agentの3モードを軸に見ると整理しやすいです。
デフォルトはAgentですが、まず「コードを変えるのか、変えないのか」で分けると、各モードの役割が一気に見えてきます。
最初にここを押さえると、以降の使い分けはかなり楽になります。

Ask＝コードを変えずに質問・調査する

Askは読み取り専用で、コードベースを検索して答えるだけのモードです。
ファイルを書き換えないので、既存実装の意味を確かめたいときや、仕様の前提を崩さずに確認したいときに向いています。
実際、チャット欄左のセレクタを開いて初めてこの存在に気づくことも多く、そこで「調べるだけ」と「触る」の境界がはっきりすると、安心して質問できるようになります。

このモードを最初の入口に置くと、誤って実装修正が走る心配がありません。
とくにAgentのまま質問すると、答えではなく変更作業に寄ってしまうことがあるため、読むだけならAskに切り替えるのが基本です。
要するに、Askは理解のためのモードだと覚えておくと迷いません。

Plan＝実装前に計画書を作る

Planはコードベースを調査し、Markdown形式の計画書を作るモードです。
ここでもコードは編集されないので、複数ファイルにまたがる変更や新機能の追加を、いきなり実装へ飛ばさず整理できます。
方針、ToDo、変更の順番を先に固める段階で使うと、後続の実装がぶれにくくなるでしょう。

このモードの価値は、思いつきの修正をそのまま走らせない点にあります。
小さなtypo修正ならAgentで十分ですが、影響範囲が広いならPlanで一度設計してから進めるほうが安定します。
計画をレビューしてから実装に渡す流れは、理解→計画→実装という順序を自然に作ってくれます。

Agent＝計画なしでも自律的に実装まで進める

Agentは自然言語の指示からコードベースを自動探索し、複数ファイルの編集、コマンド実行、エラー修正まで自律的に進めるモードです。
最も強力で、Cursorのデフォルトでもあります。
だからこそ便利ですが、意図しない変更が混じる余地もあるため、何を任せるかの線引きは意識しておきたいところです。

使い方の軸はシンプルで、読み取りだけならAsk、方針整理が必要ならPlan、実装までまとめて任せるならAgentです。
切り替えはチャット入力欄左のセレクタからでき、Shift+TabでAgent→Plan→Ask→Agentと循環します。
会話の途中でも文脈を引き継いだまま移れるので、まずはこの3ステップで迷わず使ってみましょう。

Askモードの使い方：読み取り専用で安全に質問する

Askは、コードベースを検索しながら答えを返しますが、ファイルそのものは一切変更しません。
既存コードの意味を知りたいときや、仕様の読み違いがないか確かめたいときに向いていて、調べることと直すことをきれいに分けられます。
新しく入ったプロジェクトで全体像が見えない場面でも、まずここを使うと安全です。

既存コードの意味を確認したいときの聞き方

Askに向いているのは、「この処理は何をしているのか」「この分岐はなぜ必要なのか」といった理解の質問です。
たとえば main ファイルやコアモジュールをいくつかコンテキストとして渡し、処理の流れを順番に聞いていくと、コードに手を触れずに構造を追えます。
読み取り専用だからこそ、調査の途中で意図しない編集が混ざらず、頭の中だけで全体像を組み立てやすいのです。

実際、新しいプロジェクトに入ったときは、入口になっているファイルから順に役割を確認していくやり方が役立ちます。
最初に「何が起点か」、次に「どこへ流れるか」、最後に「どこで状態が変わるか」と分けて聞くと、ただ眺めるより早く理解が進むでしょう。
Askはレビュー前の下調べにも相性がよく、修正に入る前の土台づくりとして使いやすいです。

@で参照ファイルを指定して精度を上げる

質問の精度を上げたいなら、@ファイル名や@Codebaseで参照範囲を明示します。
広いコードベースほど、どこを見て答えてほしいかを先に渡したほうが、見当違いの説明が減るからです。
単に「この実装を説明して」と聞くより、対象ファイルを絞ったほうが、判断材料の取りこぼしが少なくなります。

たとえば関連する設定ファイル、入口の処理、コアモジュールをまとめて指定しておくと、Askはその前提で検索して答えやすくなります。
範囲が広すぎると要点がぼやけますが、逆に狭すぎると前後関係が抜ける。
ちょうどよい粒度を渡すのがコツです。
コードレビューでも学習でも、この指定だけで返答の質はかなり変わります。

『質問だけ』のときは必ずAskに切り替える

Agentはデフォルトで、説明よりも実装に進みやすいモードです。
「この処理の意味を教えて」と聞いたつもりでも、文脈によってはコード修正を始めてしまいます。
質問だけしたい場面でこれが起きると、意図しない変更が入り、確認のつもりが作業になってしまう。
そこが事故の起点です。

だから、調べるだけのときは入力前にモードがAskかどうかを毎回確認する癖が効きます。
うっかりAgentのまま質問してファイルを書き換えられた経験があると、この切り替えの価値はすぐ身にしみるはずです。
新機能の実装や小さなtypo修正ならAgentでもよいですが、まずは理解したいだけならAskに戻す。
安全に進める近道はそこにあります。

Planモードの使い方：実装前に計画書を作る

Planモードでは、まずコードベースを調査して関連ファイルを洗い出し、必要なら明確化の質問を挟んでから計画を組み立てます。
いきなり実装に入らないので、見落としや方針ブレを先に潰しやすいのが利点です。
出てきた計画はMarkdownで整理され、人が読んでレビューできる形になります。

Planに計画を作らせて内容をレビューする

複数ファイルにまたがる機能追加では、Planに計画を作らせると、こちらが見落としていた設定ファイルまで拾ってくれることがあります。
実装の途中で「あそこも直す必要があった」と気づくと手戻りが増えますが、先に関連箇所を調べさせておけば、そのズレを着手前に解消できます。
調査から入る流れは遠回りに見えて、実際には最短です。

生成される計画はMarkdown形式で、タスク、ToDo、高レベルの変更方針が並びます。
文面がそのままレビュー対象になるので、実装の前に「この方針で進めてよいか」を落ち着いて判断できます。
見出しごとに意図が分かれているため、抜けや重複も見つけやすいでしょう。

計画を編集してからBuildで実装に渡す

Planの出力はそのまま受け入れるだけではありません。
気になる一行を削ったり、過剰なタスクを外したりしてからBuildへ渡せるので、AIの暴走を未然に防ぐ感覚があります。
実際、計画の中に少し広すぎる作業が含まれていたとき、Build前に範囲を絞っただけで、実装の焦点がぶれませんでした。

編集できることの価値は、単に細かく直せる点ではないです。
自分の意図を計画に反映したうえで次へ進めるため、AI任せになりません。
レビュー、修正、実装の順に区切るだけで、作業の責任分界が見えやすくなるのです。

計画をMarkdownでリポジトリに残す

計画はMarkdownファイルとしてリポジトリに保存できるので、あとから見返したりチームで共有したりできます。
単発のメモで終わらず、変更の意図や順序が残る点が扱いやすいです。
同じ種類の作業を繰り返すときも、前回の計画を土台にできるため、再利用のしやすさが生きてきます。

Buildを押すと、新しいチャットでその計画に沿って実装が進みます。
計画と実装を分けておけば、何をどこまで変えるかを把握したまま進められるでしょう。
残しておくべきはコードだけではありません。
変更の考え方まで保存しておくと、次の作業がずっと楽になります。

Agentモードの使い方：自律的に実装まで任せる

Agentモードは、指示を受けた瞬間にコードベースを探し、必要な箇所を複数ファイルにまたがって直し、コマンドを回して、失敗したら修正まで進める実務寄りの動き方です。
自然言語で「○○を実装して」と伝えるだけでも一連の作業をまとめて任せられるので、調べる・書く・直すを分けて段取りする手間が減ります。
とはいえ、指示が曖昧だと進む方向がぶれやすいので、どのファイルに何を入れ、どこを変えないかまで具体化すると安定します。

Agentへのタスクの渡し方

Agentはデフォルトモードで、AskとEditの機能をひとつにまとめて使えるのが強みです。
先に「関連箇所を探して」「必要ならテストも追加して」と自然言語で渡しておけば、コードの探索から編集、実行、エラー修正までを連続して進めてくれます。
実際、テストの追加を丸ごと任せたときも、対象関数を見つけ、テストファイルを作り、テストランナーまで回して失敗箇所を直すところまで自動で進みました。
小さな修正なら、この流れだけで十分に速いのです。

ただし、投げ方が雑だと結果も散らばります。
どのファイルを触るのか、何を変えるのか、既存の挙動のうち何を残すのかを書いておくと、Agentは迷わず寄せてきます。
たとえば「この関数の入力検証を追加し、関連テストも1本入れる」と伝えるだけでもよく、さらに制約を添えれば狙い通りになりやすいでしょう。

途中で止めて軌道修正する操作

進行中に違う方向へ寄り始めたら、中断して引き戻せます。
これは地味ですが効きます。
大きな修正ほど途中で設計の前提がずれやすく、放置すると不要な変更まで広がるからです。
実行の途中でも止めて、追加の条件を1つ足すだけで軌道はかなり戻しやすくなります。

逆に、何度もやり直す局面では、止める判断が早いほど被害は小さいです。
設計が固まっていないまま大きな機能を投げたとき、途中から方向性がぶれて手戻りが増えたことがありました。
そこでは一度止め、意図を言い直したうえで再開するほうが、最後まで押し切るよりも結果が整います。
止めるのも使い方の一部だと考えるとよいでしょう。

小さなタスクはAgent単独、大きなタスクはPlan併用

規模で使い分けるのがいちばん安定します。
1行修正やtypo直しのような小さい作業は、Agent単独で十分ですし、むしろ計画を挟まないほうが速い場面が多いです。
テスト追加のように関係箇所が限られる仕事も、自然言語で渡してそのまま進めるほうがテンポがいいでしょう。

ただし、大きめのタスクはPlanで筋道を作ってからAgentに渡すと結果が安定します。
設計の分岐が多い機能や、複数ファイルの変更が連鎖する案件は、最初にPlanで順序と前提を固めたほうが、途中の迷走が減ります。
大きいほど計画、小さいほど即実行。
この切り分けを意識してみてください。
おすすめです。

モードの切り替え方：Shift+Tabとショートカット

チャット欄の左にあるセレクタでモードを直接選べるので、入力前に現在の設定を確認しておくと、意図しない切り替えを避けやすくなります。
操作の入口が目に見えているぶん、慣れるほど切り替えは速くなり、作業の流れも乱れにくいです。
最初の一手をきちんと見ておくことが、あとで迷わない近道になるでしょう。

チャット欄からモードを選ぶ

モード選択は、チャット入力欄の左側にあるセレクタから行えます。
ここで今どのモードにいるかを入力前に確認しておくと、思っていた役割と違うまま送信してしまう事故を防げます。
とくに作業が立て込んでいると、Askのつもりで開いた会話をAgentとして進めてしまうようなズレが起こりやすいものです。
選択UIが常に見える位置にあるのは、その確認を習慣化しやすいからだと言えるでしょう。

Shift+Tabで素早く循環させる

Shift+Tabを押すと、Agent、Plan、Ask、Agentの順にモードが循環します。
マウスで毎回セレクタを開くやり方より、キーボードだけで移動できるほうがはるかに手早く、思考の途中で手を止めにくいのが利点です。
最初は切り替えるたびにカーソルを動かしていましたが、この循環を覚えてからは、質問、計画、実装の行き来がほぼ無意識になりました。
結果として、体感の作業速度も上がります。
ポイントは、操作そのものを覚えることより、考える流れを止めないことです。

Macではモデルやモード関連の切り替えにCommand+.などのショートカットも使えます。
キー操作を一度把握しておくと、セレクタを探す時間が減り、短い切り替えを何度重ねても疲れにくくなります。
おすすめです。
特に複数の会話をまたぎながら使う場合は、指の動きが固定されているだけで迷いが減るはずです。

会話の途中でモードを切り替える

モードは会話の途中でも切り替えられるので、最初にAskで内容を理解し、そのまま同じスレッドでAgentへ移って実装に入る使い方が自然です。
会話の文脈が引き継がれるため、改めて背景を説明し直す手間が少なく、理解から実行までの距離が短くなります。
これは地味ですが効きます。
スレッドを分けずに進められると、考え直しのコストが下がり、流れの良さが保てるからです。

Planを挟んでからAgentへ進む使い方も扱いやすく、途中で視点を変えたい場面ほど効果が出ます。
必要なのは、切り替えを特別な操作だと考えすぎないことだけです。
会話の続きをそのまま別モードで扱えるので、状況に応じて遠慮なく移ってみてください。
おすすめの使い方です。

Ask→Plan→Agentの使い分けフロー

このフローでは、まずAskで状況を言語化し、Planで方針を固め、Agentで実装へ進む流れが最も安定します。
いきなりAgentに投げると、前提の取り違えや修正範囲の読み違いが起きやすく、手戻りが増えます。
逆に、タスクの規模に応じて入口を選べば、迷いなく進められるでしょう。

新機能追加：Plan→Agentで設計してから実装

新機能追加や複数ファイルにまたがる変更は、Planから入るのが安全です。
先に画面、設定、API、既存処理のつながりを整理しておくと、実装の途中で「ここも直す必要があった」と気づく回数が減ります。
特に仕様がまだ曖昧な段階では、Planで選択肢を並べてからAgentに渡したほうが、実装の軸がぶれません。
設計を固めてから動く、これが回り道に見えて近道です。

ポイントは影響範囲の見落としを先に潰すことです。
ファイル単体では小さく見える変更でも、設定値、表示文言、分岐条件が連動していると、後から別の不具合が顔を出します。
Planで「どこを変え、どこは変えないか」を決めておくと、Agentは実装に集中できます。

バグ調査：Askで原因把握→Agentで修正

原因不明のバグは、まずAskで周辺コードやエラーの意味を整理するのが効きます。
実際、エラーの周辺コードを質問して仮説を立て、原因が特定できてからAgentに修正を任せたほうが、狙いの定まった変更になります。
最初からAgentに丸投げすると、見当違いの箇所を直されて状況がこじれることがあるのです。
だからこそ、調査と修正を分ける発想が役立ちます。

原因の切り分けが終わっていれば、Agentは余計な探索に時間を使いません。
どの条件で再現するか、どの関数が怪しいかが見えているだけで、修正案の精度はぐっと上がります。
バグ修正は勢いより順序でしょう。

小さな修正：Agent単独で完結

設定値を1つ変える、typoを直す、文言を少し整える、といった小さな作業はAgent単独で十分なことが多いです。
以前はこうした修正にまでPlanを挟んでいて、明らかに過剰でした。
小さな変更ほど判断材料が少なく、考える時間より実際の修正時間のほうが短いからです。
そこでは段取りを増やすより、すぐ直して終えるほうが早い。

迷ったら「コードを変えたくないならAsk、方針から決めたいならPlan、もう実装してよいならAgent」で見分けるとです。
リファクタや複数箇所の調整はPlan寄り、既に原因が見えている修正はAgent寄りと考えると、入口の選択で詰まりません。
小規模ならすぐ動く、大規模なら先に整える。
おすすめです。

Auto-Run（自動実行）とカスタムモードの注意点

Auto-Runは、確認を挟まずにターミナルコマンドを流せる設定で、Agent設定のRun Modeから切り替えます。
手数が減るぶん作業は速くなりますが、意図しないコマンドまで通ると事故につながりやすいので、使い方を先に決めておくのが先決です。
非本番のプロジェクトで試し、許可リストと組み合わせて運用するのが落ち着いたやり方でしょう。

Auto-Runを有効にする場所と仕組み

Auto-Runを使うと、ターミナル上の実行確認を毎回はさまずに進められます。
設定場所はAgent設定のRun Modeで、ここを切り替えるだけで挙動が変わるのが扱いやすい点です。
ただし、確認が省かれるということは、人間が止める前提の一手がそのまま走るということでもあります。
実際、何の制限もなく有効にしたときに想定外のコマンドまで自動で走り、ヒヤッとした経験がありました。
だからこそ、最初から本番リポジトリで回すのではなく、影響範囲の小さい環境で試すのが安全です。

許可リストで実行できるコマンドを絞る

許可リストを空にしておけば、すべてのアクションで承認を求められます。
逆に、pnpmやgitのように安全だと分かっているコマンドだけを登録すれば、テンポを保ちながら危険な操作だけ止められる。
要するに、全部止めるか全部通すかではなく、よく使う安全な操作だけを通す設計にすると、実務でのストレスが減ります。
Auto-Runを使う場面でも、この絞り込みがあるかどうかで安心感は大きく変わるのです。

本番リポジトリや破壊的なコマンドが入り得る環境では、都度承認に戻しておくほうが堅い運用になります。速度よりも取り返しのつかなさを優先する場面はあるものです。

カスタムモードで自分専用モードを作る

カスタムモード（ベータ）はChat設定から有効化でき、使えるツール、プロンプト、モデルを用途に合わせて組み替えられます。
コードレビュー専用モードのように編集ツールを外して読み取り中心に寄せれば、余計な変更が混ざりにくく、確認作業が安定します。
定型作業を毎回同じ手順で回したいなら、この作り分けは相性がいいでしょう。
まずは標準のAsk/Plan/Agentに慣れてから、必要になった段階でAuto-Runやカスタムモードへ広げる順序が自然です。
最初から自動実行を全開にせず、用途ごとに少しずつ強めていきましょう。