ブログ記事
- Cursor
- Planモード
- AIワークフロー
- 実装Tips
- Tips
CursorのPlanモードはbuild前にPlanを修正できる
"CursorのPlanモードは実行計画を確認してからbuildできます。不足や誤りがあれば追指示して修正し、1回のbuildで完了しやすくする運用方法を解説します。"
Cursorで「Planモードを使ってみたけど、そのままbuildしていいのかよく分からない」という場面は意外と多いです。
結論から言うと、生成されたPlanは確認・修正してからbuildするのが基本です。
この記事の結論
- Planモードは「実行計画を出す」→「確認・修正する」→「buildする」の順で使う
- 修正点があれば build前に 同じPlanモードで追指示できる
- 1回のbuildで完了しやすくなり、やり直しコストを下げやすい
Planモードの基本的な流れ
CursorのPlanモードは、コードを実際に変更する前に実装方針（Plan）を先に生成します。
Planを読んでから判断できるため、意図しない変更が起きにくくなります（仕様は執筆時点 2026-06-05 のもの、要確認）。
Planモードで依頼する
↓
Plan本文を読む（何をどの順で変更するか）
↓
問題なし → build実行
修正が必要 → 同じPlanモードで追指示 → 再確認 → build実行
build前に修正できることを知っておく
Planが出た段階ではまだコードは変わっていません。
以下のような点を確認してから、必要であれば同じチャットで追指示します。
| 確認ポイント | 修正例 |
|---|---|
| 変更ファイルの範囲が広すぎる | 「lib/config.ts だけに絞ってください」 |
| 対応順序が違う | 「Aの変更を先にしてからBを変えてください」 |
| 不要な処理が含まれている | 「〇〇の削除はこのタスクでは不要です」 |
| 前提が抜けている | 「既存の〇〇関数は変えずに追加してください」 |
追指示後に再度Planが更新されるので、問題なければbuildを実行します。
やり直しコストを下げる意識
Planを確認せずにbuildすると、意図と違う変更が入った場合に差し戻しが必要になります。
差分が大きくなるほど「どこが変わったか」の把握も難しくなります。
build前の数分の確認が、後の修正コストを下げます。
大きな差分が出そうな変更（リファクタ・ファイル移動・型の変更など）は、Planの段階で範囲を絞るか、タスクを分割してbuildするのが無難です。
手順まとめ
- Planモードで実装方針を出させる
- Plan本文で変更ファイル・順序・不足・誤りを確認する
- 修正が必要なら同じPlanモードで追指示する
- Planに問題がなければbuildを実行する
チェックリスト
- Planを読んで変更ファイルの範囲を確認した
- 意図しない変更や不要な処理が含まれていないか確認した
- 修正が必要な場合はbuild前に追指示した
- 大きな差分が出そうなタスクは分割を検討した
次に読む
本記事の内容はCursorの仕様変更により古くなる可能性があります。Planモードの挙動は執筆時点（2026-06-05）のものです。最新情報はCursor公式ドキュメントをご確認ください。