探索・計画・実装・記録のサイクル

Claude Codeで一つの仕事を頼むとき、いきなり「これを直して」と打つか、まず調べさせてから頼むかで、返ってくる結果の質は変わります。この違いを生んでいるのは、頼み方の巧拙よりも、仕事をどう段階に分けるかという習慣です。

claude-code-101ではPlanモードの入り方と権限モードの基本操作を扱いました。このレッスンでは操作方法でなく、探索・計画・実装・記録という4段階を毎回の習慣にする理由と、省いてよい場面の見分け方を扱います。

探索と計画を、実装から切り離す

Claudeがコードをいきなり書き始めると、見当違いの問題を解決してしまうことがあります。公式ドキュメントは、この事故を避ける理由をこう述べています。

推奨される流れは4段階です。

探索と計画をひとまとまりの段階として先に済ませ、実装に入ってから調べ直さないという順番を守ることが、このサイクルの要点です。

計画が要らない仕事もある

4段階すべてを毎回律儀に踏む必要はありません。公式ドキュメントは、計画を省いてよい基準をはっきり示しています。差分を一文で言い表せるなら、計画は飛ばしていいという基準です。

誤字を直す、ログを1行足す、変数名を変える。こうした仕事は、計画を作る手間のほうが実装そのものより大きくなります。逆に、複数のファイルにまたがる変更や、扱ったことのないコードに手を入れるときは、先に計画を作ったほうが結局速くなります。

どちらか迷ったら、「この変更を人に一文で説明できるか」を自分に問うと判断がぶれません。説明が二文、三文と伸びていくなら、それは計画を作ったほうがいい仕事です。

実装中は、操縦し続ける

計画を立てて実装に入っても、そこで手を離していいわけではありません。書かせている途中で見当違いの方向に進み始めたら、その場で止めて直すほうが、最後まで走らせてから直すよりずっと早く済みます。

Escでの一時停止、Esc二回または/rewindでの巻き戻し、/clearでの仕切り直しといった操縦の道具は、会話の畳み方・戻り方ですでに扱いました。ここで加えたいのは、いつ使うかの目安です。

同じ問題で2回訂正しても直らないときは、3回目を試す前に/clearして、学んだことを盛り込んだ新しい指示で仕切り直すほうが、たいてい結果が良くなります。訂正を重ねるほど、会話の中に失敗した試みの記録が積み上がり、Claudeがそれに引きずられてしまうためです。

記録する: コミットも仕事の一部

実装が終わったら、コミットメッセージを書かせて終わりにします。「何を」だけでなく「なぜ」変えたかが分かるメッセージにしてもらうと、あとで自分が読み返すときにも、他の誰かが読むときにも役立ちます。

記録まで含めて一つの仕事、という感覚を持っておくと、実装を終えた時点で気が緩んで雑なコミットメッセージで済ませる、という事故を防げます。

やってみよう

演習1：直近の依頼を4段階に当てはめる

直近でClaude Codeに頼んだ仕事を1つ思い出してください。探索・計画・実装・記録のどこを省き、どこを厚くやったかを振り返ってみましょう。省いた段階があるなら、それは「一文で言える差分」だったかどうかも確かめてください。

演習2：計画が要る仕事、要らない仕事を仕分ける

今抱えている、または最近扱った仕事を3つ書き出し、それぞれ計画を作るべきか、直接頼んでよいかを判断してみましょう。判断の理由を一言添えると、次に似た仕事が来たときの目安になります。

今日のまとめ

3行で振り返ります。

• 推奨されるサイクルは探索・計画・実装・記録の4段階で、実装からいきなり始めると見当違いの問題を解決してしまうことがある
• 差分を一文で言い表せる仕事は計画を省いてよく、複数ファイルにまたがる変更や不慣れなコードには計画が効く
• 同じ問題で2回訂正しても直らないときは、3回目を試す前に/clearして仕切り直す

次のレッスンでは、CLAUDE.md・スキル・フックという3つの指示の置き場所を、強制力の強さで比べます。