第1章と第2章で、Claude Code が何でどう動くかは掴めているはずです。この章で作るのは毎日同じ形で回せるリズム——探索→計画→実装→コミットの4拍です。
型が要る理由ははっきりしています。うまくいかない日の原因は、たいてい「拍を飛ばしたこと」だからです。読ませずに書かせた、検証手段を渡さずに任せた、区切らずに走らせ続けた——症状は違っても、戻る場所は同じです。
1日の型 ― 4拍で回す
関係するファイルを読ませ、現状を言葉にさせる。まだ書かせない。
手順を先に出させ、あなたが直す。唯一の安い修正点。
書かせてその場で検証を走らせる。第1章のループを回し切らせる。
通った時点で戻れる地点を打つ。次の探索はここから始まる。
1周の目安は「途中経過を思い出せなくなったら大きすぎる」。半日の1周より、1時間の周を4回のほうがほぼ常に安定します。
「毎回すべてやる」という意味ではありません。 タイポの修正に計画は要りません。判断すべきはどの拍を省けるかで、初期設定は「全部やる」。
始める前に、検証手段を渡す
4拍に入る前に、一度だけやっておくことがあります。Claude が自分で自分を確かめられる手段を先に渡しておくことです。
第1章で見たとおり、中身は収集→実行→検証のループでした。強いのは STEP 3 があるからで、テストが通るまで自分で直し続けられます。裏返せば検証手段が無いとループは1周で止まります——書いて、たぶん合っている、で終わる。チャット型と同じです。
「テストを通して」で済む。失敗の出力が次の入力になり、あなたが見ていなくてもループが回る。
あなたが動かし、結果を伝え、また書かせる。あなたがボトルネックになる。任せた気になっているだけです。
渡すものは大げさでなくて構いません。「このコマンドを打てば正しいか分かる」という1行で足ります。これは口で言うよりファイルに書くほうが確実です——プロジェクト直下の CLAUDE.md は、圧縮をまたいでもディスクから読み直されるからです。
CLAUDE.md に書いておくと効くもの（例）
- 変更したら通すコマンド: テスト / 型チェック / リンタ
- 通らないまま「できました」と報告しないこと
- 触ってはいけない場所（生成物・本番設定など）
こう書くと、毎回「テストして」と言わなくても、変更のたびに自分で確かめるようになります。指示を出す回数が減るのではなく指示が要る場面が減る——これが型の効き方です（書き方は第6章）。第1章で「向かない」に入れたタスクがここで落ちるのも、渡せる検証手段が無いからです。
探索 ― 書かせる前に読ませる
1拍目。やることは1つ——関係するファイルを読ませ、今どうなっているかを説明させる。まだ書かせません。飛ばすと Claude は読んでいない部分を推測で埋めます。それらしいコードが返り、既存の書き方と微妙に食い違い、ズレに気づくのはレビューか本番です。
悪い探索: 「認証まわりを直して」
→ いきなり編集が始まる。何を前提にしたのか分からない
良い探索: 「認証に関わるファイルを探して読んで。
いまログインがどう処理されているかを、
関係するファイルの一覧と一緒に説明して。
まだ何も変更しないで」
→ 前提が画面に出る。ズレていればここで直せる
返ってきた説明は読んでください。ここが最も安い介入点です。「そのファイルはもう使っていない」の一言のコストは、間違った実装をレビューで見つけるコストの何十分の一かです。
もう1つ、探索には費用があります。読んだファイルはコンテキストに載るので、大きく探索するほど後の余裕が減る——第1章の「埋まると鈍くなり、前半を忘れる」はここから始まります。抑え方は3つ。
- 範囲を切る——「まずは認証まわりだけ」と限る。全体像は要るが全ファイルは要らない
- 巨大ファイルは部分で読ませる——丸ごとだと一気に埋まる。行範囲や関数単位で足りる
- 出力の多い調査は分ける——ログ調査や大量検索はサブエージェントへ。自分のコンテキストを持ち、戻るのは要約だけなので本体が膨らみません（第6章）
計画 ― プランモードが効くとき、重いとき
2拍目。何をどの順で変えるかを、書き始める前に出させます。 Claude Code にはこの拍のためのプランモード（計画モード）があり、調べて計画を提示するところで止まって、承認するまで書き込みに進みません。切り替え方は版で変わるので、手元の版のヘルプで確認してください。
本質は権限のゲートを「編集のたび」から「作業の入口」へ移すことです。既定ではツールを呼ぶたびに確認が入りますが、プランモードはそれを1回にまとめて前に持ってくる。承認する対象も「この1行」ではなく「この作業の方針」になります。
複数ファイルに跨がる／やり方が2通り以上ある／既存の設計に合わせる必要がある／間違えたときの戻しが面倒／自分もまだ最善手を決めていない
やることが1つしかない／すでに手順が決まっている／失敗しても即座に戻せる／計画を読む時間のほうが実装より長い
右側は素直に飛ばしてください。計画は無料ではなく、作る時間・読む時間・コンテキストを消費します。受け取ったら見るのは3点だけ。①前提が合っているか（1拍目がずれていれば計画も丸ごとずれます）②検証が入っているか（「テストを通す」が無いなら足す）③刻みが十分細かいか（1手で全部やる計画は、失敗したときに原因を特定できません）。
長い作業なら、計画はファイルに落としておく。 会話の中にしかない計画は、セッションが長くなると要約に潰れます。PLAN.md のような場所に書き出させておけば、文脈を畳んでも読み直せ、席を外して戻ったときの再開点にもなります。
実装 ― 小さく刻んで、走らせながら直す
3拍目。ここでようやく書かせます。原則は2つ。
1つ目、1手ごとに検証を走らせる。 5つの変更をまとめてからテストすると、落ちたときに「どれが原因か」を切り分ける仕事が発生します。1つ書いて1つ通せば、直前の1手が原因です。Claude のためというよりあなたのための作法。
2つ目、失敗の出力はそのまま渡す。 要約して伝え直す必要はありません。STEP 3 は「出力を読んで STEP 1 に戻る」なので、生の出力がいちばん情報量の多い入力です。噛み砕くと、かえって手がかりが減ります。
実装中の1周（これを刻んで繰り返す）
[編集] 計画の1項目だけ書き換える
↓
[実行] テスト／型チェックを走らせる
↓
緑 → 次の項目へ（あるいはコミット）
赤 → 出力を読んで、もう一度 [編集] へ
同じ場所で3回赤が続いたら、直させ続けない
→ 手を止めて、切り分けに移る（第4章）
最後の1行は経験則です。同じ失敗を繰り返し始めたら「もう少しで直る」ではなく「前提が間違っている」の合図であることが多いからです。
検証に時間がかかるとき——長いビルドやCIの完了待ち——は、張り付かずに任せる手もあります。Claude Code には指示を一定間隔で繰り返させる仕組みがあり、間隔を省略すると次に見に来る間合いをClaude自身が決め、完了したと判断すればループを止めます。仕組みと制約は /loopコマンドとは何か へ。セッションを閉じると止まる点は要注意です。
コミット ― 区切りは自分で打つ
4拍目。テストが通ったらその時点でコミットします。「きりのいいところまで進んでから」ではなく、通った瞬間が、きりのいいところです。
- 戻れる地点になる——次の1手が失敗しても、確実に緑だった場所へ戻れる
- 差分が読める大きさになる——半日ぶんの変更は読めません。読めない差分は実質レビューされません
- 会話を切ってよくなる——成果が入っていれば、セッションを捨てるのが怖くなくなります
コミットメッセージも書かせて構いませんが、差分を見ずに承認しないこと。「何を変えたか」ではなく「変えるつもりのなかったものが混ざっていないか」を見ると決めれば、目が滑りません。
なおコミットとプッシュは別の判断です。デプロイのように取り消しにくい操作をどこまで任せるかは第5章で扱います。
セッションの畳み方と、巻き戻し
4拍を何周かすると、必ずコンテキストが埋まってくる問題にぶつかります。第1章の2症状——応答が鈍る、前半を忘れる——が出たら畳みどき。手段は圧縮か始め直しの2つで、分かれ目はひとつです。
次が「続き」なら圧縮——経緯を要約として引き継げますし、何を残すかを指示できるのが、自動で走るのとの違いです。次が「別件」なら始め直す——要約すら要らないなら、要約を作る費用も要りません。無関係な作業を引きずらないぶん精度も出ます。
タイミングにも型があります。時計や割合ではなく、作業の区切りで押す——周が終わり、次の長い作業に入る直前です。途中で押すと、先で使う詳細まで要約に潰されます。根拠は /compactは定期的に押すべきか で扱っています。
畳む前に、消えては困るものをファイルへ出す。 プロジェクト直下の CLAUDE.md と自動メモリはディスクから読み直されるので何回畳んでも生き残りますが、会話の中にしかない決定事項は要約で薄まります。
もう一つ、任せ方そのものを変える仕組みがあります。Claude Code はプロンプトごとに戻れる地点を自動で作っており、おかしくなったらそこまで巻き戻せます。対象はコードだけ・会話だけ・両方から選べ、いちばん使うのは「コードだけ戻して、会話は残す」——変更は無かったことにしつつ、何が駄目だったかを覚えている状態で言い直せます。
効くのは操作の手軽さよりリスクの取り方です。戻せないつもりだと1手ずつ確認することになり、エージェントを使う意味が薄れます。戻せると分かれば大きく渡せて、試して駄目なら捨てるが選択肢になります。
ただし、戻るのは「Claude が編集ツールで書き換えたファイル」だけです。 シェルコマンドで作った・消したファイル、あなた自身の編集、DBの状態は戻りません。Git の代わりにはならず、節目のコミットと併用する前提です。線はこう引けます——ファイル編集で完結する作業は大きく渡す。シェル経由で状態を変える作業は、渡す前にコミットする。詳細は チェックポイントと巻き戻し へ。
レビューさせる ― 書いた側と読む側を分ける
テストが通ったコードが良いコードとは限りません。テストは「壊れていないこと」は保証しても、「その書き方でよかったか」には答えないからです。
原則は1つ。書いた文脈と、読む文脈を分けること。 たった今その実装を書き終えた会話に「レビューして」と言っても、自分の判断を追認しがちです。選んだ理由が全部見えている状態は、粗探しに向きません。具体的には3つ。
- 別セッションで読ませる——コミットして差分を作り、まっさらな会話に差分だけ渡す。経緯を知らない目で読ませる
- 観点を指定する——「よくして」ではなく「境界条件」「既存の書き方との一貫性」と軸を渡す。曖昧な依頼は曖昧な指摘を生む
- 指摘を鵜呑みにしない——正しいかは実物で確かめる。直させる前に、まず読む
3つ目はこの章の他の場所とつながっています。レビューは「検証手段の無いタスク」の典型で、自動で正誤が決まらないぶん、Claude は自信のある口調で的外れなことも言います。そのまま修正指示に流すと正しかったコードを壊す——指摘は候補として扱い、1つずつ判定してください。毎回同じ観点で回したくなったら、仕組みに落とす合図です（第6章）。
複数セッション ― どこまでが得か
片方が長いテストを回している間に別件を進めたい——自然に出る発想です。Claude Code には、独立したセッションを背後で複数立ち上げ1画面で管理する仕組みがあります。要は隔離で、バックグラウンドのセッションはファイルを編集する前に自分専用の作業ディレクトリへ移ります。読みは共有、書きは分離になるので、同じファイルを上書きし合う事故が構造的に起きません。詳細は agent viewとディスパッチ へ。
タスクが互いに独立／途中経過を見なくてよい／結果を受け取ってから判断すれば足りる／片方が待ち時間の長い作業
同じ設計判断に依存している／途中で方向を決め直す必要がある／取り消せない操作を含む／そもそも結果を確認しきれない数
右の最後が、いちばん効く制約です。並列化はレビューの総量を増やします。 3つ投げれば3つぶんの「本当にそうか」が返るのであって、確認の手間は並列化されません。投げてよい数の上限は、あなたが結果を検証できる数です。費用も増えます——バックグラウンドだから安い、ということはありません（第7章）。
並列を始める前に、権限の設定を見直してください。 背後で走るセッションはその場で選ぶのではなく、設定から権限を引き継ぎます。普段ゆるめにしている人ほど「ゆるい権限で、誰も見ていないセッション」が数のぶんだけ生まれます。第5章が先です。
地味ですが事故が多いのが後片付けです。背後のセッションが作った作業場は、セッションを削除すると一緒に消えます。「終わった」と「取り込んだ」は別——消す前にコミットを。
まとめ
- 1日のリズムは探索→計画→実装→コミットの4拍。不調の原因は、たいてい拍を飛ばしたこと
- 始める前に検証手段を渡す。無いと収集→実行→検証のループが1周で止まる
- 探索は書かせる前に読ませる。ただし読んだぶん余裕は減るので範囲を切る
- 計画は権限のゲートを作業の入口へまとめる仕組み。1手で済む作業には重い
- 実装は1手ごとに検証し、3回失敗したら切り分けへ。コミットは通った瞬間に打つ
- 畳むか始め直すかは「次が続きか、別件か」。畳む直前はファイルへ書き出す
- 巻き戻しはファイル編集だけを戻す。シェル経由の変更は戻らないのでコミットと併用
- レビューは書いた文脈と切り離し、指摘は候補として扱う。並列の上限は検証できる数
型ができても、詰まるときは詰まります。次章で切り分けの順序を持っておきましょう。次の 第4章「詰まりを抜ける」 へ進みましょう。