Claude Code プロンプトと Plan モード：要件の明確化から検証サイクルまで

有効なプロンプトは、目標、関連するスコープ、遵守すべき制約、期待される成果物、検証方法を示すべきだ。Claude は実装の詳細を自ら探索できるが、チームが明文化していない業務境界を推測することはできない。

ファイルパス、エラーテキスト、既存の実装例、テストコマンドは、「しっかり考えて」よりもはるかに価値がある。スコープが不確実な場合は、まず読み取り専用での探索を求め、徐々に収束させるとよい。

Plan モードは Claude に読み取りと分析を許可するが、直接編集はしない。複数ファイルにまたがる変更、アーキテクチャのトレードオフ、不慣れなコード領域に適している。現状を探索してから、人間がレビュー可能な計画を作り、Plan を終了してから実装する。

計画には、具体的なファイル、データフロー、移行や互換性のリスク、テスト、およびやらないことを含めるべきだ。目標が明確でも実装に選択肢が残っている場合にのみ、計画は真に手戻りを減らす。

Plan モードにはコンテキストと時間のコストがある。スペルミスの修正、明確なログの追加、定義済みの機械的変更の実行などは、直接変更を求めて検証すればよい。

判断方法はシンプルだ。期待される diff を一文で正確に記述できるなら、通常は正式な計画は不要であり、どのモジュールが関わるかすら不確実な場合は、まず探索すべきだ。

テストの終了コード、ビルド、lint、固定の入出力、ブラウザのスクリーンショットはいずれもフィードバックの検証サイクルを形成する。検証シグナルがなければ、Claude は実装が「正しそうに見える」時点で止めるしかない。

「検証済み」とだけ言うのではなく、実際のコマンドと主要な結果を提示するよう求める。重要な変更については、新しいサブエージェントに要件と diff に基づいた独立したレビューをさせてもよい。

Claude が方向を間違えたと気づいたら、すぐに Esc で停止し、具体的な誤りの事実と新しい制約を指摘する。大量の無関係な変更を完了してから全体を却下するのを待たないこと。

同一問題を連続2回修正してもまだ外れる場合は、/clear でクリーンなコンテキストを開き、直前に学んだ制約を新しい最初のプロンプトに書き込む。無関係なタスクも別セッションに分け、古いログや失敗した案が現在の判断を邪魔しないようにする。

@ でファイルを参照し、完全なエラーを貼り付け、スクリーンショットを添付するか公式 API URL を示す方が、内容を言い換えるより正確である。データ量が大きい場合は、すべてのログを一度にメインコンテキストに詰め込むのではなく、Claude に必要に応じて読み込ませる。

ビジネス上の選択が絡む場合は、Claude にまずインタビューさせ、結論を自己完結した仕様として書き出すよう要求できる。その後、新しいセッションで仕様を実行し、実装フェーズにクリーンなコンテキストを残す。