Claude Code の Plan モードで「朝に一日を設計」したら、手戻りが半分になった

Claude Code を使い始めて最初の数週間、私は「とにかく指示を出せばコードが出てくる」という使い方をしていました。確かにコードは出てきます。出てくるんですよ、ちゃんと。問題は、一日の終わりに振り返ると、なぜか思ったほど進んでいないことでした。手戻りが多く、結局自分で書き直す部分も少なくない。動くものを大量に作って、その半分を翌朝こっそり捨てている。生産性が高いのか低いのか、自分でもよく分からない状態でした。

最初に断っておくと、この記事は「仕様書を6つ書け」という spec-driven の話でもなければ、「/clear せずに9時間使うとコンテキストが腐る」という話でもありません。どちらも別の機会に書いたテーマです。今日扱うのは、Claude Code の Plan モード という機能を、一日のリズムの中でどう運用するか、それだけです。道具の使い方を変えたのではなく、一日の設計を変えた、という話だと思ってもらえれば近いです。

朝イチでコードを書くのをやめた

転機になったのは、朝一番にやることを変えたことでした。それまでは席に着いた瞬間に「じゃあ認証機能を実装して」と打ち込んでいました。今は違います。最初の30分は、コードを1行も書きません。Plan モードで、その日の作業を設計します。

Plan モードは Shift+Tab で切り替わるモードで、Claude がファイルを書き換えずに計画の策定と認識合わせに集中してくれます。私が朝にやっているのは、だいたいこんな対話です。

> (Plan Mode) 今日はユーザー認証機能を実装したい。
> メール/パスワード認証、Google OAuth、パスワードリセットの3つ。
> 優先度と実装順を提案して。

Claude: 以下の順序を提案します。

1. メール/パスワード認証(基盤。他の機能が依存)
2. パスワードリセット(メール認証の拡張)
3. Google OAuth(独立性が高い)

各機能の見積もりと、考慮すべき設計判断を示しますか？

ポイントは、ここでまだ実装させないことです。順番、依存関係、設計方針。この3つの認識を合わせるだけで朝の30分を使います。一見、遠回りに見えます。最初は私もそう思っていました。

なぜ朝にやると手戻りが減るのか

理由は3つあって、どれも「実装に入る前に潰しておけるもの」です。

1つ目は、認識違いの事前防止です。 いきなり実装に入ると、Claude が「良かれと思って」選んだ設計が自分の意図と違っていることがあります。これに気づくのはたいてい、コードが半分できた後です。Plan モードで方針を合わせてから実装に入れば、この手戻りがそもそも発生しません。私の書き直しの大半は、実はこのパターンでした。

2つ目は、タスク分解の品質です。 Claude に計画を立てさせると、自分では見落としていた依存関係が洗い出されます。「あ、このテーブルのマイグレーションを先にやらないとダメだ」という気づきが、コードを書く前、朝の時点で得られる。これが午後の「詰まり」を1つ消してくれます。

3つ目は、生成コードそのものの品質です。 計画を経てから実装に移ると、出力品質が上がります。コンテキストに「何をどう作るか」がすでに入っているからです。設計を口頭で合意した相手と、いきなり「作って」と言われた相手の差、と言えば伝わるでしょうか。

タスクは「機能単位」で切る

朝の設計でいちばん効くコツは、タスクの切り方です。技術スタック単位ではなく、ユーザーから見た機能単位で分解します。

❌ 技術スタック分割(結合時に壊れやすい)
- タスク1: 全テーブルのマイグレーション
- タスク2: 全APIエンドポイント実装
- タスク3: 全画面のUI実装

✅ 機能単位分割(結合テストできる最小単位)
- タスク1: 商品一覧表示(DB + API + 画面)
- タスク2: カート追加(DB + API + 画面)
- タスク3: 決済処理(DB + API + 画面 + 外部連携)

機能単位で切っておくと、各タスクが終わるたびにエンドツーエンドで動作確認できます。「結合テストができる最小単位」が、ちょうどいい粒度の目安です。技術スタック単位で切ると、最後の結合フェーズで全部の歪みが一気に噴き出します。あれは、月末にまとめて家計簿をつけて愕然とするのと同じ構造です。毎日少しずつ確認していれば防げたものを、最後にまとめて精算しようとするから痛い。

実装に入ったら、セッションを分ける

計画が固まったら通常モードに戻して実装に入ります。ここで私が守っているのは「タスクごとにセッションを分ける」ことです。

# タスク1: ユーザー登録
claude
> ユーザー登録機能を実装して(Plan Modeの計画に従う)
# ... 実装完了 ...
> /clear

# タスク2: ログイン
> ログイン機能を実装して

/clear でコンテキストをリセットするのは、別の機能の文脈が混ざるのを防ぐためです。長い実装セッションの途中では /compact でコンテキストを圧縮します。私の目安は、サブタスクが1つ完了したとき、エラーの試行錯誤が5回以上続いたとき、そして「そろそろ重いな」と感じたときの3つです。3つ目はかなり感覚的ですが、これが意外とあてになります。

夕方に、翌朝の自分へ申し送る

一日の最後、セッションを閉じる前に、翌日への申し送りを残します。

> 今日の作業を要約して。
> 完了したこと、明日やるべきこと、未解決の課題を
> docs/daily-log.md に追記して。

このログが、翌朝の Plan モードの入力になります。前日の文脈を持った状態で計画を立てられるので、朝のウォームアップがほぼゼロで済む。昨日の自分が今朝の自分に申し送りをしてくれている状態です。地味ですが、ここが一日のリズムをつないでいる継ぎ目だと思っています。

一日のリズム(まとめ)

時間	フェーズ	Claude Code の使い方
9:00-9	計画	Plan モードで設計・タスク分解
9:30-12	実装	通常モードで機能実装。タスク間は /clear
13:00-15	テスト・リファクタ	テスト追加、コードレビュー依頼
15:00-17	レビュー・整理	差分レビュー、コミット整理、翌日への申し送り

道具を新しくしたわけでも、プロンプトのテクニックを覚えたわけでもありません。変えたのは、コードを書く前に一日を設計するという、ただそれだけの順番です。手戻りが体感で半分になったのは、午後に消えていた時間の正体が「朝に潰せたはずのもの」だったから。それを朝に前倒ししただけ、というのが正直なところです。

Plan モードを起点にした計画→実装→テスト→レビューの日次フロー、/compact や /clear の使い分け、CLAUDE.md への設計判断の永続化まで、Claude Code を開発の道具として運用する具体的な手順は 実践Claude Code にまとめています。この記事は、その日次フローの「朝の30分」だけを切り出して、実際に何が変わったかを書いたものです。