CursorのPlanとAgent、実務で迷わないための切り分け

🙌 結論からいうと

変更が複数ファイルに広がりそうで、まだ「どこをどう触るか」の地図や優先順位が頭の中で確定していないなら Plan。やること・終わり方・触っていい範囲が一文で言い切れるなら Agent。 これが私の実務でのメインの線引きです。
ドキュメントを読めば用語の定義は追えるんですが、エディタの前に立った瞬間の判断は別物で、最初は Agent に丸投げして diff が散らかり、「読むのが仕事になった・・・」みたいな日を何度か踏みました 😅 調査で誰でも辿れる情報と、毎日の手数とレビュー負荷はズレやすいので、後者側の話を書きます。
なお Tab 補完のような インラインの補助とは別物です。今回は Plan / Agent のように「まとまった指示を渡す」運用に絞ります。混ぜると話が散らかるので、切り分けておくと迷いが減ります 👀

👀 この記事の前提（Cursor）

以下は Cursor エディタ の Plan / Agent の話です。公式アイキャッチに近いビジュアルで、どの製品の話かを先にそろえておきます。

💡 Plan を選ぶ判断（体感ベース）

Plan の価値は、実装を始める前に 変更の輪郭と順序 を文章として一度そろえられることです。私は次のどれかに当てはまるときに寄せています。

• 複数ファイルにまたがるのに、まだ影響範囲の見取りが粗い
• 要件や制約がまだ言語化しきれてない（「こうしたい」はあるが、触らない領域が曖昧）
• リファクタや責務分割など、方針の選択が残っている

いきなり Agent で広げると、「動くけど意図とズレた広がり方」をされて、あとから人間が読み解くコストが跳ねることがあります。計画が100点である必要はないです。80点の地図を見てから歩き始める、くらいで十分効く場面が多い、というのが実務感覚です 💡

✨ Agent で十分な場面

逆に 単一ファイルや単一画面に閉じる変更、既存の型やパターンに沿った小さな修正、指示に「この関数をこう」「このテストを足す」と具体が載っているときは Agent の方が速いです。
ここに毎回 Plan を挟むと、丁寧さは増えますが 待ちと確認のオーバーヘッドだけが積み上がる・・・！ 私は「もう手は決まってる」と感じた瞬間は躊躇なく Agent に寄せています。モードを切り替えるのを惜しむと、かえって遅くなることの方が多いかも ✨

😅 つまずきはモード以前、ということも多い

失敗の多くは Agent に投げすぎなのもありますが、並行して 前提の説明が薄いパターンも多いです。触ってほしくないディレクトリ、守りたい公開API、優先したい挙動を一言足すだけで、結果のブレはかなり変わります。
「期待と違う」が出たとき、モードが悪かったのではなく、人間側の指示が雑だったケースを、私はわりと経験しています 😅

👍 迷ったときの10秒チェック

実務では、迷ったら次の2つだけ見るようにしています 👍

• 複数ファイルにまたがりそうか
• 設計や優先順位の判断が、まだ言葉にできていないか

どちらかがイエスなら Plan 寄り。どちらもノーなら Agent で試す。完璧なルールではなく、作業に入る直前の sanity checkとして使うと、手が止まる時間が減りました。

👀 最後に

Cursor のモードはアップデートで文言や挙動が変わり得ます。公式の最新ドキュメントと私のリポジトリの慣れをあわせて、上の線引きだけメモに残しておくと、チームに展開するときも話が早いです 👀
私の場合は「広げすぎた日」を一行ログに残すだけで、次の週の判断がかなり楽になりました。暗記より 私の癖の方が効く、という感じです 🙌