想定読者

• Cursorを使い始めたけれど「なんとなくAskしか使っていない」方
• Copilotの延長のような感覚でAgentを使ってうまくいかなかった経験がある方
• 設計やレビューの工夫に関心がある方

目次

1. はじめに
2. Cursorの4つのモードと使い分け
3. Planモードでできること
4. Planモードの実践的な使い方
5. よくある失敗パターン
6. まとめ

1. はじめに

Cursorでコーディングしているとき、こんなことに心当たりはありませんか？

• とりあえず個別に分からないことをAskモードで都度質問しているけど、なんとなく思ったような答えが得られなくて堂々巡りになってしまう
• 全体の方針や設計を固めずに、いきなりAgentモードで「こんな機能作って」と任せてみたら、意図していないコードやイマイチな実装が返ってきてしまったことがある
• 要件や意図がLLM（AI）にちゃんと伝わっていないまま進めてしまい、「なんでこうなった？」と感じた経験がある

実はCursorは4つの試行モードを持っています。それがAsk / Agent / Plan / Debugです。
なぜコードの質が安定しないのか？
その答えは、「設計を明確にせずに実装に進んでしまう」ことにあると自分は考えています。
Agentモードは優秀ですが、前提が曖昧だと迷走し、その場しのぎのコードを量産しやすい傾向がある。とも。。

それぞれのモードの特徴を理解することで、コードの質を安定させ、設計を明確にしながら効率的に開発しやすくなると信じています。
Cursorを使用してみて、また調べたりした中での自分なりの解釈も含まれていると思いますので、一解釈として捉えていただければ幸いです。
その結果「自分はこう思う」、「この箇所はこうだ」という議論のきっかけにつながれば嬉しいなという思いです。
最後までお付き合いいただけると大変嬉しいです。

2. Cursorの4つのモードと使い分け

それぞれのモードについて順番に確認していきましょう。
公式ドキュメントはこちらです：https://cursor.com/ja/docs/agent/modes

2.1. Ask モード：壁打ち・検索・局所理解

• 役割
  • 質問・調査・コードリーディング補助
  • ChatGPT的だが「今開いているコード」を文脈に持てる
• 向いている用途
  • 「このメソッド何してる？」
  • 「Railsでこれどう書く？」
  • 「このエラーが出た時の対処方法は？」
• 弱点
  • 複数ファイルをまたぐ判断が不安定になりやすい

2.2. Agent モード：実装を"手で書かせる"

• 役割
  • コード生成・修正・リファクタ
  • 指示に基づきファイルを編集する実行役
• 向いている用途
  • 単機能の追加
  • 定型リファクタ
  • テスト生成
• 危険ポイント
  • 設計を渡さずに使うと事故りやすい
  • その場しのぎのコードを"それっぽく"量産する傾向がある

2.3. Debug モード：バグの再現と修正支援（2025年12月追加）

• 役割
  • ランタイムログを埋め込んでバグの再現と修正を支援
  • 複雑なバグの根本原因を特定
  • さまざまなスタック、言語、モデルで動作
• 向いている用途
  • 再現が困難なバグの調査
  • ランタイム時の動作確認
  • 複雑なバグの根本原因分析
• 特徴
  • 2025年12月10日のバージョン2.2で追加された比較的新しい機能
  • 実行時のログを自動的に収集・分析
  • バグの再現条件を特定しやすくする

2.4. Plan モード：設計・思考の言語化

Plan モードは「コードを書かないモード」です。それではなぜコードを書かないのか？

• 役割
  • 設計の整理・最適化
  • 実装前の計画立案
  • コード生成の指示を構造化
• Planモードの本質
  • コードを書かない
  • ファイルも編集しない
  • 「何を・なぜ・どう進めるか」を構造化することで、コードの質を向上させやすくなる
• なぜ Planモード が存在するのか？（自分なりの解釈です🙏）
  • LLMは「最初の前提」が曖昧だと破綻しやすい傾向がある
  • Agentにいきなり投げると問題が起きやすい：
    • 境界が曖昧（どこまで実装すべきか判断できない）
    • 責務が混ざる（単一責任の原則が守られない）
    • 後から直しづらい（設計意図がコードに反映されない）

2.5. 4つのモードの使い分け判断基準

では、実際にどのモードを使うべきか？作業の種類でざっくりと分類すると以下の通りだと考えています。

人間の作業	Cursorモード
要件整理	Plan
設計レビュー	Plan
実装	Agent
調べ物	Ask
バグの再現・調査	Debug

更に具体的な判断基準は以下の通りです。

• Askモード：コードを理解したい、調べ物をしたい時
  • 「このコードの意味は？」
  • 「このエラーの原因は？」
  • 「この機能の実装方法は？」
• Agentモード：設計が明確で、単一のタスクを実装したい時
  • 単機能の追加
  • 定型リファクタ
  • テスト生成
• Planモード：複雑なタスクや、設計を明確にしたい時
  • 複数ファイルにまたがる機能追加
  • 大規模なリファクタリング
  • 新規機能の設計検討
  • バグ修正の原因特定と修正計画
• Debugモード：バグの再現や調査が必要な時
  • 再現が困難なバグの調査
  • ランタイム時の動作確認
  • 複雑なバグの根本原因分析

3. Planモードでできること

2章で説明した通り、Planモードは「前提を固定するための安全装置」です。
なぜ本記事でPlanモードを特に強調するのかというと、「設計や前提を明文化するプロセス」こそが、実はコードの質と開発効率を大きく左右すると考えているからです。

ここからは、Planモードで実際にどんなことができるか、具体的な使い方や機能を見ていきましょう。

3.1.できること

Planモードでは、以下のようなことができます：

• 設計の整理・最適化
  • 実装前に設計を構造化して整理
  • 責務の分離や境界の明確化
  • 実装順序の最適化
• コード生成の指示を整理・最適化
  • Agentモードに渡す指示を明確化
  • 実装の粒度や範囲を定義
  • エラーハンドリングやテストの方針を決定
• リスクの事前発見
  • 実装前に設計上の問題点を発見
  • 依存関係や影響範囲の確認
  • 実装の難易度や工数の見積もり

3.2.弱点・注意点

Planモードにも以下のような限界があります：

• 設計責任はすべて人間にある
  • Planモードは設計を「整理」するだけで、設計自体は人間が考える必要がある
  • 良い計画を立てるためには、そもそも良い設計をインプットとして与える必要がある
• 計画の過信に注意
  • 計画はあくまで「仮説」なので、実装中に問題があれば柔軟に修正する必要がある
  • 計画が細かすぎると、実装の柔軟性を失う可能性がある
• 計画作成にも時間がかかる
  • 複雑なタスクほど計画作成に時間がかかる
  • 単純なタスクではAgentモードを直接使う方が効率的な場合もある

4. Planモードの実践的な使い方

Planモードの真価は、Agentモードと組み合わせることで発揮されます。
ここでは、最も効果的な使い方である「Plan → Agentの黄金パターン」と、実践的な使い方について紹介します。（黄金パターンは大げさかもです。。笑）

4.1. 基本フロー

1. Planモードで計画を作成
   • タスクの全体像を把握
   • 実装すべき機能を分解
   • 実装順序を決定
2. 計画をレビュー・修正
   • 計画の妥当性を確認
   • 不足している点を補完
   • 実装の優先順位を調整
3. Agentモードで実装
   • 計画に基づいて明確な指示を出す
   • 段階的に実装を進める
   • 各ステップで動作確認
4. 必要に応じて計画を見直し
   • 実装中に問題が発見されたら計画を修正
   • 柔軟に対応する

4.2. 実例：ユーザー認証機能の追加

• 悪い例（PlanなしでAgentに投げる）
  • プロンプト

    $ ユーザー認証機能を追加して

  • 結果
    認証ロジック、セッション管理、エラーハンドリングが混在し、後から修正が困難になる傾向がある。

• 良い例（Plan → Agentの黄金パターン）
  • Step 1：Planモードで計画を作成
    • プロンプト：

      $ ユーザー認証機能を追加したい。以下の要件を満たす設計を考えて：
      - メールアドレスとパスワードでのログイン
      - セッション管理
      - エラーハンドリング
      - テストコード

    • Planモードが生成する計画例
      • 認証コントローラーの作成（ログイン / ログアウト）
      • 認証サービスの作成（認証ロジックの分離）
      • セッション管理ミドルウェアの実装
      • エラーハンドリングの実装
      • テストコードの作成
  • Step 2：計画をレビュー
    • 各コンポーネントの責務が明確か
    • 実装順序が適切か
    • 要件に漏れがないか
  • Step 3：Agentモードで段階的に実装
    • プロンプト

      $ Step 1の計画に基づいて、
      まず認証コントローラーを作成してください。
      ログインとログアウトのエンドポイントを実装し、
      認証サービスを呼び出すようにしてください。

  • このように1ステップずつ実装 → 動作確認を繰り返すことで、実装の破綻を防ぎやすくなる。

4.3. メリット

• コードの質が安定しやすい
  • 一貫性のあるコードが生成されやすい
  • 責務の分離が適切に行われやすい
• 修正が容易
  • 問題箇所の特定が早い
  • 影響範囲が明確
• レビューが効率的
  • 実装前後で設計と照合できる
• チーム開発での共有が容易
  • 認識合わせがしやすい
  • 実装方針が明確になる

5. よくある失敗パターン

Planモードを理解していても、実践では様々な失敗をしてしまいます。
ここでは、よくある失敗パターンとその回避方法を紹介します。

失敗パターン1：PlanなしでAgentに投げる

• 症状
  • Agentモードに複雑なタスクを丸投げ
  • 生成されたコードが期待と違う
  • 修正に時間がかかる

  • 例：
    「ユーザー管理機能を実装して」
    → 認証、認可、プロフィール管理が混在
    → 後から分離するのに時間がかかる
            

• 回避方法
  • 複雑なタスクは必ずPlanモードで設計を固める
  • 「このタスクは1ファイルで完結するか？」を自問する
  • 設計が不明確ならPlanモードを使う

失敗パターン2：計画を過信する

• 症状
  • Planモードで作成した計画を絶対視
  • 実装中に問題が発見されても計画を修正しない
  • 柔軟性を失う

  • 例：
    Planで「A → B → C」の順序を決めた
    → 実装中に「Bの前にDが必要」と判明
    → でも計画を変えずに進めて、後で大修正
            

• 回避方法
  • 計画は「仮説」として扱う
  • 実装中に問題が発見されたら、すぐに計画を見直す
  • Planモードは何度でも使える

失敗パターン3：計画が細かすぎる

• 症状
  • 計画が細かすぎて、実装の柔軟性を失う
  • 計画作成に時間がかかりすぎる
  • 実装中に微調整できない

  • 例：
    Planで「1行目のコードはこう、2行目はこう...」と詳細に指定
    → 実装中に「この方法の方が良い」と気づいても変更できない
    → 計画に縛られて非効率
            

• 回避方法
  • 計画は「何を」「なぜ」を明確にし、「どう」は大まかに
  • 実装の詳細はAgentモードに任せる
  • 計画の粒度は「コンポーネント単位」程度が適切

失敗パターン4：Planモードを過度に使う

• 症状
  • 単純なタスクでもPlanモードを使う
  • 計画作成に時間がかかり、効率が悪い
  • 「計画を作るのが目的」になってしまう

  • 例：
    「変数名を変更する」という単純なタスクでもPlanモードを使う
    → 計画作成に5分、実装に1分
    → 直接Agentモードで1分で終わるタスクを6分かける
            

• 回避方法
  • 単純なタスクはAgentモードを直接使う
  • 「このタスクはPlanが必要か？」を判断する
  • 計画作成の時間もコストとして考える

失敗パターン5：計画をレビューしない

• 症状
  • Planモードで計画を作成したら、すぐにAgentモードで実装
  • 計画の妥当性を確認しない
  • 実装後に「計画が間違っていた」と気づく

  • 例：
    Planで「認証はJWTで実装」と計画
    → レビューせずに実装開始
    → 実装後に「セッション管理が必要」と判明
    → 最初からやり直し
            

• 回避方法
  • 計画を作成したら、必ずレビューする
  • 「この計画で本当に要件を満たせるか？」を確認
  • チーム開発では計画を共有してレビュー

失敗パターン6：Askモードを活用しない

• 症状
  • コードベースを理解せずにPlanモードで設計
  • 既存の実装と整合性が取れない
  • 重複実装や不整合が発生

  • 例：
    既存の認証実装を確認せずにPlanモードで設計
    → 既存の認証方式と異なる方式を提案
    → 実装後に不整合が発覚
            

• 回避方法
  • 新しいタスクに取り組む前に、Askモードで既存コードを理解する
  • 既存の設計パターンや規約を確認する
  • Planモードで設計する際も、既存実装との整合性を考慮する

6. まとめ

この記事では、Cursorの4つのモード（Ask / Agent / Plan / Debug）について、 特にPlanモードに焦点を当てて解説しました。

「いきなり書かせる」のではなく、「設計してから書かせる」。
この意識を持つだけで、Cursorとの付き合い方が大きく変わる可能性があります。
ぜひ、Planモードを活用して、より効率的で質の高い開発を実現してみてください。
最後までお付き合いいただきありがとうございました。