Plan Mode はタスクの性質で判断する - Claude Code でトークンを無駄にしない5つの条件
きっかけ
Claude Codeで週間制限の78%を消費してしまった。原因を調べると、Plan Modeの不適切な使用だった。
「プロジェクトの公開準備を計画してください」と指示したところ、Plan Modeが起動して50K-150Kのトークンを消費。これを数回繰り返すと、あっという間に制限に達した。
調査の中で「Plan Modeはファイル数が膨大な時に使うもの」という認識が間違っていることに気づいた。
前提: 自分の状況
- プロジェクト規模: 小規模個人OSSプロジェクト（100-500ファイル程度）
- 主なタスク: OSSの公開準備、個人情報除去、新機能追加の計画
- 技術スタック: TypeScript、Node.js
- 制約条件: 週間トークン制限があり、効率的な使用が必須
補足: 当初、Tabキーで Think Mode（シーケンシャル思考）を切り替えられることを知らず、自動でThink Modeになっていた可能性もある。これもトークン消費が増えた一因かもしれない。ただし、本記事の主題はPlan Modeの適切な使用判断なので、Think Modeの詳細は別記事で扱う。
直面した課題
Plan Modeをいつ使うべきか判断できなかった。
選択肢:
- ファイル数基準: 1000ファイル以上ならPlan Mode → 誤解だった
- タスクの複雑さ基準: 複雑な構造理解が必要な時のみ → 正解
- とりあえず使う: 何も考えずにPlan Mode → トークン浪費
当初は選択肢1を採用していたが、小規模プロジェクトでも頻繁にPlan Modeが起動し、トークンを大量消費していた。
採用した方法
タスクの性質で判断する5つの条件
以下の1つでも該当すればPlan Modeを検討する：
- 既存コードの構造的理解が必須（依存関係、アーキテクチャパターン）
- 複数の実装方法を比較検討する必要（トレードオフ分析）
- 問題の原因が不明（ボトルネック特定、調査→仮説→検証）
- システム全体に影響する変更（大規模リファクタリング）
- レガシーコード・ドキュメント不足（暗黙の仕様）
Plan Modeが不要なタスク（典型例）
- 新規機能の追加（既存コードと独立）
- バグ修正（原因が特定済み）
- ドキュメント作成
- 設定ファイルの修正
- OSSプロジェクトの公開準備（標準チェックリストあり）
- 個人情報除去（パターンマッチング可能）
理由:
- 標準的なパターンが存在する
- ファイル数を限定して確認できる
- コードベース全体の理解が不要
実際にやってみて
良かった点
トークン消費を70%削減できた。
具体例（OSSプロジェクト公開準備）:
- 改善前: 「プロジェクトの公開準備を計画してください」→ Plan Mode起動 → 50K-150K
- 改善後: 「package.json、README.md、LICENSEのみ確認してTodoWrite作成。Plan Mode不要」→ 15K-25K
削減量: 25K-125K（3-6倍効率化）
想定外だった点
ファイル数は全く関係なかった。
10ファイルのプロジェクトでも、既存の複雑な依存関係を理解する必要があれば、Plan Modeは有効だった。逆に1000ファイルのプロジェクトでも、新規機能追加ならPlan Modeは不要だった。
改善したい点
Plan Modeを使う際も、スコープを限定する必要がある。
「認証システムを刷新したい」とだけ指示すると、プロジェクト全体を探索してしまう。代わりに「src/auth/ディレクトリのみ分析。UI・テストコードは除外」と範囲を明示することで、トークン消費を50%削減できた。
他の選択肢を取るべきケース
自分とは異なる状況での推奨：
大規模プロジェクト（10万行以上）で新規参画した場合
- アーキテクチャ理解が必須
- ドキュメントが不足している
- この場合はPlan Modeを積極的に活用すべき
レガシーコード（5年以上前）のメンテナンス
- 暗黙の仕様を読み解く必要
- 依存関係が複雑
- Plan Modeで段階的に理解を深める
小規模プロジェクト（個人開発）
- 標準的なタスクが中心
- Plan Modeはほぼ不要
- チェックリスト方式で十分
まとめ
Plan Modeの判断基準は「ファイル数」ではなく「タスクの性質」。標準的なパターンが存在するタスクは、確認ファイルを限定してPlan Modeを避けることで、トークン消費を3-6倍削減できる。
知識がない場合は「標準チェックリストを教えて」→「それを元にプロジェクト確認」という2段階質問で、トークン消費を3-8倍削減できた。