Plan Modeは議論の場だ：実装させる前に2案出させて反論させる

Claude Codeの公式ドキュメントを読むと、Plan Mode は「コードを書かずに調査・計画だけを行うモード」と説明されています。Shift + Tab 2回で入り、Write / Edit / Bash が使えなくなる安全装置——これが公式の位置づけです。

しかし、実務で成果を出しているユーザーの使い方はもう一歩先にあります。Plan Mode は**「Claudeに反論させる場」**です。

「最良の1案」を聞くのは素人の使い方

Plan Modeに入ってこう聞くことが多いと思います。

認証をJWTからセッションベースに切り替えたい。最善の方法を提案して。

Claudeは丁寧に1つの方案を出してきます。ステップバイステップで、きれいで、整然としている。そしてそのまま実装に入ると——2時間後に「そもそもこの方針で良かったのか」が疑問になる。

なぜなら、1案だけ出された時点で比較検討が行われていないからです。人間の設計レビューでも同じことが起きます。「これでいきます」と言われた方案にはバイアスがかかりやすい。

「2案＋トレードオフ」を引き出すプロンプト型

達人が使っているのは次のパターンです。

認証をJWTからセッションベースに切り替えたい。

以下の形式で計画を出してくれ:
1. 方案A（推奨案）: 概要、必要な変更、リスク
2. 方案B（代替案）: 概要、必要な変更、リスク
3. AとBのトレードオフ比較（テーブル）
4. Aを採用した場合に反論されそうな点を自分で列挙

現状のコードを先に読んで、現実に即した案にしてくれ。

ポイントは4番目の**「反論されそうな点を自分で列挙」**です。Claudeは自分の推奨案に対して自分でデビルズ・アドボケイト（悪魔の代弁者）を演じることができます。ここで出てくる反論の質が、そのまま後工程で起きるはずだった手戻りを先取りします。

具体例：出力の差

パターン1（素朴に聞いた場合）

ユーザー: このAPIエンドポイントのレスポンスを高速化したい。計画を立てて。

Claude: 以下の計画を提案します:
1. N+1クエリを解消するためにJOINを追加する
2. レスポンスをRedisでキャッシュする
3. 不要なフィールドをレスポンスから除外する

整然としていますが、「なぜJOINであってサブクエリでないのか」「Redisの運用コストは許容範囲か」「除外してはいけないフィールドを見落としていないか」が見えません。

パターン2（2案＋反論を要求した場合）

ユーザー: このAPIエンドポイントのレスポンスを高速化したい。
2案出して、各案のリスクと、推奨案への反論を自己列挙して。

Claude:
方案A（推奨）: クエリ最適化 + 選択的キャッシュ
- JOINでN+1解消、TTL 5分のRedisキャッシュ
- リスク: JOIN後のクエリ計画が遅くなる可能性

方案B: API レスポンス分割
- 重いフィールドを別エンドポイントに分離、必要時だけ取得
- リスク: フロント側の呼び出しが複数に分散

トレードオフ:
| | 方案A | 方案B |
|---|---|---|
| 実装量 | 中 | 大 |
| 効果の確実性 | 高 | 中 |
| Redis依存 | あり | なし |
| 将来の拡張性 | 低 | 高 |

方案Aへの反論:
- Redis障害時のフォールバックが未定義。キャッシュ透過で本番DB負荷が急増するリスク
- JOINの追加でテーブルロックの粒度が変わる可能性を検証していない
- TTL 5分は根拠なし。ビジネスロジック的に5秒で古くなるデータはないか

この反論セクションが金です。自分では気付かなかった「TTL 5分は根拠なし」のような指摘が出てくるだけで、後から炎上するタイプの設計ミスを先に潰せます。

Plan地獄を避ける

このパターンの落とし穴は「Plan Modeでの議論が楽しくなりすぎて、いつまでも計画を練り続ける」状態です。

経験則としてPlan Modeでの往復は最大3ターンまでにします。

ターン1: 2案＋トレードオフ＋反論を出させる
ターン2: 反論への対処と最終案の確定
ターン3: 実装ステップの確認（ここで Plan Mode 解除）

3ターンを超えたら、それはPlanの問題ではなく要件の問題です。Plan Mode を出て、要件そのものを再定義する必要があります。

Plan Mode の隠れた効果

Plan Mode の効果は「良い計画が立つ」だけではありません。コンテキストが整理される副作用があります。

Plan Mode では Write / Edit / Bash が使えないため、Claude は探索結果と思考だけをセッションに残します。その状態で Plan Mode を抜けると、Claude のコンテキストには「何をどう変えるか」の整理された計画が直近に載っています。この状態から Code フェーズに入ると、実装の命中率が段違いです。

逆に Plan Mode を挟まずにいきなり auto で走らせると、Claude は探索と実装を同時にやろうとして、中途半端なコンテキストで手を動かし始めます。

まとめ

Plan Mode は安全装置ではなく議論の場です。そして「2案＋反論」というフォーマットを使うだけで、議論の質が構造的に上がります。

• 1案だけ聞く → 比較できない → バイアスが入る → 手戻り
• 2案＋反論を聞く → 比較できる → 弱点が先に見える → 手戻り激減

Plan Mode を3ターンで抜けて実装に入る。このテンポが、結果として最も速い。

---

参考:

• Claude Code Docs — Common workflows