Cursorに「この機能を追加して」と頼むと、いきなりファイルを書き換え始めます。小さな修正ならそれで済みますが、数十ファイルに波及する変更では、気づいたときには想定と違う方向に大量の差分ができています。
この手戻りを減らすための機能が、Cursorの Plan モードです。コードを書かせる前に実装計画を作らせ、人間が読んで直してから実装に進ませます。2026年10月時点の公式情報をもとに、起動から実装への移り方、計画がずれたときの直し方、チームでの運用基準までを順に見ていきます。
なお「cursor plan」で検索して料金プランを探している方は、Cursorの料金プラン解説をご覧ください。本記事が扱うのは料金ではなく、機能としての Plan モードです。
この記事でわかること
- Plan モードが通常の Agent モードと何が違うのか
- 起動から Build（実装開始）までの具体的な手順
- 計画の保存先について、公式の記述と第三者記事の記述がなぜ食い違うのか
- 計画と結果がずれたときの、公式が勧める直し方
- チームで使うときのレビュー基準と、Claude Code・VS Code との違い
Planモードは実装前に計画書を作らせるモード
Plan モードは、Agent が即座にコードを書く代わりに、まず調べて計画書を出すモードです。人間は計画書を読み、編集し、納得してから実装を許可します。「いきなり施工する業者」と「見積もりと図面を先に出す業者」の違いと考えるとイメージしやすいでしょう。
通常の Agent モードとの違い
Agent モードは、依頼を受けたらそのままコードの読み書きに入ります。Plan モードの流れは次の順序です。
- Agent が確認質問を投げる
- コードベースを調べる
- 実装計画を作る
- 人間がチャットまたは Markdown で確認・編集する
- 準備ができたら Build で実装へ進む
計画は、ファイルパスとコード参照を含む Markdown ファイルとして作られます。To-do の追加や削除もその場でできるので、「この修正は今回やらない」と書き換えるだけで実装範囲を絞れます。
実装前に人間の判断が一度挟まる。違いはこの一点で、効き目も大半はここから来ます。
料金プランの「cursor plan」とは別物
「cursor plan」は検索すると料金プランの話題が混ざります。Plan モードは機能の名前で、契約プランとは無関係です。
参考までに、公式の料金ページ（Cursor Pricing、2026年10月時点）では、個人向けが Free $0、Plus $8、Premium $30、Super $100、Ultra $200（いずれも月額）、法人向けが Teams（1ユーザー $30〜）と Enterprise（個別見積もり）です。Pro や Pro+ といった旧名称は、公式のモデル・料金ページでレガシープラン（既存契約者向けに継続）扱いになっています。旧名称で書かれた記事は古い可能性が高いので注意してください。
Plan モード専用の追加料金は、公式のモデルと料金のページに記載がありません。計画の作成が使用量にどう計上されるかも、公式には明記されていません。計画作成も Agent 系の利用と同じ枠で消費される可能性はありますが、確認できていない以上、本記事では断定しません。
起動から実装までの手順
手順は、起動・質問への回答・計画の編集・Build の4段です。細かい操作は公式ドキュメントに沿っています。Cursor 全体の使い方はCursor完全ガイドで扱っているので、初めての方は先にそちらを開いてください。
Shift+Tabで切り替える
チャット入力欄で Shift+Tab を押すと、モードが順に切り替わります。Agent のモードピッカー（ドロップダウン）から Plan を選ぶ方法でも同じです。
複雑なタスクを示す言葉が入った依頼では、Cursor 側から Plan モードへの切り替えが提案されることもあります。提案が出たら受けて構いません。
起動後に送る依頼文は、目的と制約を書くほど計画の質が上がります。たとえば次のような書き方です。
注文履歴画面に CSV エクスポートを追加したい。既存の
OrderServiceは変更せず、新しい API エンドポイントとして実装する。テストは既存の形式に合わせる。計画だけ作って、実装はまだしないでほしい。
確認質問には全部答える
依頼を送ると、Agent はいきなり計画を出さず、確認質問を返すことがあります。出力品質は、この質問への回答が多いほど上がります。
質問を面倒がって「お任せで」と返すと、Agent は自分で判断した前提を計画に埋め込みます。その前提が間違っていても、計画が整って見えるぶん気づきにくくなります。分からない項目は「未定。選択肢と影響を計画に書いて」と返すのが安全です。
計画を読み、直接編集する
計画が出たら、実装に進む前に次の点を読みます。
- 変更対象のファイルが妥当か（触ってほしくないファイルが入っていないか）
- To-do の粒度と順序が実装の流れに合っているか
- 既存の実装を読んだ上での提案か、一般論の寄せ集めか
- 依頼に書いていない作業が紛れていないか
直したい箇所は、チャットで追加指示するか、Markdown を直接編集します。To-do の削除は「今回は見送る」の意思表示として最も確実です。
2025年12月の Cursor 2.2 で、計画内に Mermaid 図をインラインで表示する機能と、選択した To-do を新しいエージェントに送る機能も加わりました（公式 changelog で確認できます）。To-do を別エージェントに渡せれば、独立した作業を並行して進められます。
Buildで実装に移る
納得したら、計画画面の Build をクリックします。ここから Agent が計画に沿って実装に入ります。
Build 後に計画を読み返す機会は少なくなりがちです。実装が進んだら、完了した To-do と差分を見比べて、計画外のファイルが変更されていないか確認してください。
計画の保存先は公式の記述を基準に考える
保存先は、解説記事によって書いてあることが違います。公式ドキュメントの記述では、計画の既定の保存先はホームディレクトリです。「Save to workspace」を実行するとワークスペース側に移り、後からの参照・チーム共有・ドキュメント化に使えます。
一方、第三者の記事には「Save to workspace すると .cursor/plans/ に保存される」という記述があります。公式のドキュメントとブログでは、このパスの記載を確認できていません。実際の保存場所は、お使いのバージョンで一度実行して確かめるのが確実です。
保存しないまま進めるとどうなるか。計画は一時的な仮想ファイルとして開かれるため、未保存のままだと、後日その計画を調整しようとしたときにエージェントが計画を見つけられない、というユーザー報告が公式フォーラムに上がっています。個別の報告で再現条件は確定していませんが、長く残したい計画は保存しておくほうが安全です。
要点を表にまとめます。
| 項目 | 公式の記述 | 第三者記事の記述 |
|---|---|---|
| 既定の保存先 | ホームディレクトリ | 記述なし、または仮想ファイル |
| Save to workspace 後 | ワークスペースへ移動し共有可能 | .cursor/plans/ に保存 |
| 現状の扱い | 公式の記述を基準にする | 実機で確認してから採用 |
表の右列は断定できません。チームの運用ルールに書き込むなら、まず自分たちの環境で保存場所を確認し、実測した結果を書いてください。
計画と結果がずれたときは追加指示より巻き戻す
実装結果が計画とずれたとき、追加指示を重ねて直したくなります。公式が勧めるのは別の手順です。変更を Revert（巻き戻し）し、計画をより具体的に書き直して、もう一度実行します。
手順にすると次のとおりです。
- 実装による変更を Revert して、作業ツリーを元に戻す
- ずれた原因を特定する（曖昧だった To-do、書かれていない制約）
- 計画の該当箇所を具体的に書き直す
- 書き直した計画で再度 Build する
追加指示は、ずれた差分の上に修正を重ねるため、後から読み返しにくくなります。巻き戻したほうが速くきれいに済む、というのが公式の見立てです。
使いどころは複雑な変更に限る
Plan モードが効くのは、決めること自体が難しい変更です。公式の整理では、何を作るかを決めるのが難しい部分で、そこに時間を使えば、明確な指示を受けた Agent が残りを片付けます。逆に、単純な変更で毎回計画を作らせると、手間が増えるだけです。
向く場面と向かない場面
| 場面 | Plan モード | 理由 |
|---|---|---|
| 有効なアプローチが複数ある機能追加 | 向く | 方式の選択を実装前に確認できる |
| 多数のファイルやシステムに影響する変更 | 向く | 影響範囲を先に洗い出せる |
| 要件が曖昧で事前調査が必要な作業 | 向く | 確認質問で要件を詰められる |
| 進める前に決めたいアーキテクチャ判断 | 向く | 判断を計画に残してレビューできる |
| 簡単な変更、慣れた作業 | 向かない | Agent で直接進めたほうが速い |
向かない場面は、誤字修正や定型的な修正、同じ形の作業の繰り返しです。判断に迷ったら、「失敗したときに手戻りが半日を超えそうか」で決めると実務では使いやすい基準になります。この基準は当協会の見解で、公式の記述ではありません。
よくある失敗は、計画を信じすぎることと細かくしすぎること
日本語の解説記事が挙げる失敗例には、計画の過信、計画が細かすぎる、単純タスクへの使いすぎ、といったものがあります。いずれも二次情報ですが、当協会の見立てでも的外れではありません。
中でも危ないのは過信です。計画は、実際に動かしたコードの結果ではなく、読んだコードからの推測にすぎません。実装中に見つかる想定外は必ずあるので、計画は「合意した出発点」として扱い、完了条件はテストの通過で判断します。
細かすぎる計画も弊害があります。関数名や変数名まで固定すると、実装中の合理的な判断を縛り、かえって手戻りが増えます。計画に書くのは、変更するファイル、守る制約、完了条件の3点で十分です。
Claude Code・VS Code の計画機能との違い
計画してから実装する考え方は、他のツールにもあります。保存先と承認の流れが違うので、混在環境では注意が必要です。公式ドキュメントで確認できる範囲をまとめます。
| ツール | 計画の入り方 | 計画の保存先 | 実装への移り方 |
|---|---|---|---|
| Cursor | Shift+Tab またはモードピッカー | Markdown ファイル（既定はホームディレクトリ、Save to workspace で移動） | Build |
| Claude Code | claude --permission-mode plan または Shift+Tab | 公式の該当ページで保存先の記述は確認できず | 承認するまで編集しない権限モードを解除 |
| VS Code（GitHub Copilot） | agents ドロップダウンまたは /plan | セッションメモリ /memories/session/plan.md（プロジェクト外） | Start Implementation で Agent に切り替え |
Cursor の特徴は、計画が To-do 付きの Markdown ファイルで、リポジトリに移して共有できる点です。Claude Code では、計画は「承認までファイルを編集しない」権限モードとして実現されています。VS Code の既定の保存先はプロジェクト外のセッションメモリなので、計画をチームで見たいなら別途ファイルとして取り出す必要があります。
どれが優れているという話ではなく、計画をレビュー対象にしたいかどうかで相性が変わります。2つのツールの全体比較はCursorとClaude Codeの比較記事にまとめています。
チームで使うときのレビュー基準
個人で使うなら、計画を自分で読んで進めれば足ります。チームで使うと、「誰が計画を承認するのか」「計画をどこに残すのか」「規約をどこに書くのか」が決まっていないと、人によって品質がばらつきます。
ただし、コミット運用やレビューフローについて、公式が推奨する手順は確認できていません。以下は、公式の機能説明を前提にした当協会の提案です。
計画を成果物として扱う
Save to workspace でリポジトリ内に置いた計画は、共有とドキュメント化に使えると公式に説明されています。そこから先の運用は、チーム内で決めることになります。たとえば次のような決め方です。
- 影響範囲が大きい変更では、計画をプルリクエストに含めてレビューする
- 計画のレビューでは、変更ファイルの範囲、完了条件、触らない領域の3点を確認する
- 実装後、計画と差分が大きくずれていたらその理由をプルリクエストの説明に書く
計画をコミットするかどうかは、保存先の確認とセットで決めます。ホームディレクトリに残るだけの計画は、リポジトリには入りません。
規約は Rules に、今回の判断は計画に書く
Cursor には、Project Rules（.cursor/rules、バージョン管理対象）、User Rules、Team Rules（Team・Enterprise プラン、ダッシュボードで管理し強制適用も可能）、AGENTS.md の4種類があります。優先順位は Team、Project、User の順です。詳細は公式の Rules ドキュメントにあります。
Rules のドキュメントには、Plan モードへの言及がありません。Plan と併用する際の公式手順は確認できていないので、役割分担は次のように考えるのが現実的です。
| 書く内容 | 置き場所 | 例 |
|---|---|---|
| 毎回守る規約 | Rules / AGENTS.md | 命名規則、テストの書き方、禁止ライブラリ |
| 今回の変更だけの判断 | 計画 | 対象ファイル、方式の選択理由、見送る範囲 |
規約を計画に毎回書くと、書き漏れが起きます。逆に今回限りの判断を Rules に書くと、ルールが肥大化します。この分担は公式裏付けのない運用提案ですが、迷いは減ります。
Cursor を会社として導入するときの進め方は、Cursorの法人導入ガイドに別途まとめています。
計画を作る力をチームに根づかせる
Plan モードは、ボタンを覚えれば使えます。ただ、良い計画の依頼文を書けるか、計画の粗を見抜けるかは、人によって差が出ます。
差が出やすいのは、制約の言語化と、計画のレビューです。ここは個人の勘に任せず、チームで共通の観点を持つほうが早く揃います。Cursor研修では、Plan モードを含む Agent の使い分けと、計画のレビュー観点をチームで揃える進め方を扱っています。社内の標準的な使い方を決めたい場合に役立ちます。
運用開始前のチェックリスト
最後に、運用を始める前に決めておく項目を並べます。
- Plan モードを使う基準（影響ファイル数、手戻りの大きさなど）を決めたか
- 計画の保存先を、自分たちのバージョンで実機確認したか
- 計画をコミット・レビューの対象にするか決めたか
- 規約を Rules に寄せ、計画には今回の判断だけを書くと決めたか
- ずれたときは Revert して計画を書き直す、という手順を共有したか
使用量の管理については、計画作成時の計上方法が公式に明記されていないため、導入初期は管理画面で実際の消費を観察するのが確実です。料金体系の詳細は料金プラン解説を参照してください。
よくある質問
Plan モードの起動方法は？
チャット入力欄で Shift+Tab を押すか、Agent のモードピッカーから Plan を選びます。複雑な依頼では Cursor 側から切り替えが提案されることもあります。
計画はどこに保存されますか？
公式ドキュメントでは、既定はホームディレクトリで、Save to workspace を使うとワークスペースへ移せます。.cursor/plans/ と書く記事もありますが、公式では確認できていません。
計画と違う実装になったら？
追加指示を重ねるより、変更を Revert して計画をより具体的に書き直し、再度実行するのが公式の推奨です。差分が積み上がらず、結果もきれいになります。
Plan モードは追加料金がかかりますか？
公式のモデルと料金のページに、Plan モード専用の追加料金の記載はありません。計画作成時の使用量の扱いは明記がなく、確認できていません。料金プラン自体は料金記事で整理しています。
簡単な修正でも Plan モードを使うべきですか？
必要ありません。簡単な変更や慣れた作業は、Agent モードで直接進めたほうが速く済みます。Plan は、複数の方式がある変更や、影響範囲が広い変更で使います。
まとめ
まず試すなら、複数ファイルにまたがる小さめの機能追加を1件選び、Plan モードで計画だけ作らせてください。確認質問に答え、不要な To-do を削ってから Build を押す。この一往復で、Agent モードとの違いが体感できます。
その次にやることは、Save to workspace を実行して、計画の保存場所を自分の環境で確かめることです。公式と第三者記事の記述が食い違っているので、確かめた結果をチームの手順書に書けば、後から迷う人が出ません。
チームで使うなら、規約は Rules に、今回の判断は計画に分け、ずれたら Revert して計画を書き直す運用を最初に共有します。計画のレビュー観点まで揃えられると、Plan モードは個人の道具からチームの仕組みに変わります。
Plan モードの使い分けや計画のレビュー観点をチームで揃えたい場合は、Cursor研修で実際のコードを使って練習できます。
