10秒でいうと
調べる → 計画する → 実装する → 検証する。この順を守るだけで結果が変わります。
違う方向へ進み始めたら、最後まで見ずにEscで止めるほうが速い。
Claude Codeで一番差が出るのは、道具の使い方ではなく進め方です。
4つの段階
調べる。いきなり直させません。「どこを触ることになるか、まず調べて」と頼みます。読むだけなので安全で、こちらの理解と食い違っていないかが分かります。
計画する。Shift+Tab でプランモードに切り替えると、ファイルを読んで方針を出すが、書き換えない状態になります。方針を承認してから実装に入ります。
公式ドキュメントも、込み入った作業ではプランモードを使うことを勧めています。理由がはっきりしていて、方向が違ったときのやり直しが高くつくからです。
実装する。ここで初めて書き換えます。小さく刻むのがコツです。1ファイル書いたら確かめる、を繰り返すほうが、まとめて10ファイル書かせるより速く終わります。
検証する。テストを走らせる、実際に動かす、差分を読む。Claudeに自分で確かめさせたうえで、人がもう一度見る（No.22）。
検証の材料を渡す
公式が挙げているコツで、実際に効きます。Claudeが自分で正解を確かめられる材料を先に渡してください。
- テストケース
- 期待する出力
- スクリーンショット
- 「こうなったら成功」の条件
材料があると、こちらが指摘する前にClaudeが自分で直します。往復が減ります。
割り込む
Esc を押す癖をつけてください。
違う方向へ進み始めたのに最後まで見届けるのは、時間もトークンも無駄です。3行読んで「違うな」と思ったら、そこで止める。
止めたあとの選択肢は2つ。
言い直す。「そうではなく、〜してください」と続ける。会話は残っているので、途中から軌道を変えられます。
戻す。/rewind か Esc の2回押しで、前の状態に戻します（No.39）。ファイルまで戻せるので、中途半端に書き換わった状態を残さずに済みます。
判断の目安は、すでに書き換わっているかどうかです。読んでいるだけなら言い直し、書き換わっていたら戻す。
会話を分ける
第1章のNo.06と同じ話が、ここでも効きます。違う作業を始めたら /clear。
Claude Codeでは、その効果が金額に出ます。会話が長いほど毎回のリクエストが重くなり、使用量が増えます（No.44）。
/clear の前に /rename で名前をつけておくと、あとで /resume で戻れます。
つまずきポイント
一息で全部やらせようとする。「この機能を作って、テストも書いて、コミットまでして」は失敗しやすい。段階で区切って、途中を見るほうが結局は速い。
最後まで見届けてしまう。「違うかもしれないが、もう少し見てから」で待つと、修正が大きくなります。早く止めるほど安い。
検証を飛ばす。動くように見えるコードと、動くコードは違います。必ず走らせてください。
指摘を遠回しにする。「なんか違う気がする」では直りません。何がどう違うのかを書く。第2章から一貫している話です。
やってみよう：プランモードで一往復する（5分）
手元のリポジトリで、小さめの変更を1つ選んでください。
Shift+Tabを押してプランモードに切り替えてから、こう頼みます。プロンプト
（やりたい変更）をしたいです。
どのファイルをどう変えるか、計画だけ立ててください。
影響が及ぶ範囲と、確認すべきことも挙げてください。計画を読んでから承認し、実装させます。
期待される結果：先に計画が出る。読むと、自分が想定していなかったファイルが入っていることがある。
うまくいかないとき：計画が抽象的なら、「どのファイルの何行目あたりか」まで書かせてください。具体的でない計画は、承認しても意味がありません。
まとめ
- 調べる → 計画する → 実装する → 検証する
- 込み入った作業はプランモードで計画を承認してから
- 検証の材料を先に渡す。往復が減る
- 違うと思ったら最後まで見ずに
Esc
次に読む
※本記事の情報は 2026年8月時点のものです。