0:00 0:00
Article
Claude Codeを使った1日の開発フロー：朝の計画から夕方の引き継ぎまで
Claude Codeを日常開発に組み込むための1日のワークフローを、朝の計画・小タスク化・Plan→Implement・確認・記録・翌日への引き継ぎの6ブロックに分けてまとめます。CLAUDE.mdの読み直し、/clearの使いどころ、claude --continue／--resumeの使い分け、コンテキスト肥大の見極めまでカバーします。
結論：1日を6ブロックに区切るとClaude Codeは安定して回る
Claude Codeを使い始めて最初に困るのは、**「気がつくとセッションが膨らみ、午後には精度が落ちている」**という状態です。これはClaudeが悪いのではなく、コンテキストウィンドウに無関係な情報が積み上がるからです。公式のBest Practicesも「コンテキストはもっとも重要なリソース」と明言しています。
そこで本記事では、1日を次の6ブロックに区切る運用を紹介します。
- 朝の計画（15分）：
CLAUDE.mdを読み直し、その日に倒すタスクを3つに絞る - 小タスク化（30分以内）：1タスクずつPlan Modeで計画を立てる
- 実装（1〜2時間）：Normal Modeに切り替えて実装し、検証コマンドまで走らせる
- 確認とコミット（15分）：差分を自分の目で読んでPRを開く
- 記録（10分）：
NOTES.mdに翌日への申し送りを残す - 引き継ぎ（5分）：セッションに名前を付け、
/clearまたはclaude --continueの判断をする
タスク分解そのものの粒度はClaude Codeに大きなタスクを渡す前の分解方法、Plan Modeの内側はClaude Codeに「計画してから実装」させるプロンプト例、最後のコミット運用はClaude Codeで安全にコミットとPRを作るワークフローで個別に扱っているので、本記事は1日の通し運用にフォーカスします。
朝の15分：CLAUDE.mdを読み直して3タスクに絞る
朝にやるべきことはたった2つです。
CLAUDE.mdを自分でざっと読み直す- その日にClaudeに倒してもらいたいタスクを3つだけ書き出す
CLAUDE.mdは公式ドキュメントが言うとおり「セッション開始時に毎回ロードされる」ファイルです。前日のうちにルールを追加していたり、チームメンバーがpushしていたりすると、その日のClaudeの挙動が変わります。「今日のClaudeは何を前提に動くのか」を頭に入れる15秒だけで、午後の事故が減ります。
タスクを3つに絞るのには理由があります。Claudeはどれだけ並列化しても、人間がレビューできる量がボトルネックになります。1日にPRを5本も6本も出しても、自分がgit diffを読めなければ意味がありません。
朝のメモはNOTES.mdに直書きで構いません。
## 2026-04-27 のタスク
1. /posts のスラッグ重複チェッカーを CLI 化する（30分）
2. CSV パーサで空行を許容する（15分）
3. README に dev コマンドを追記する（10分）この時点ではタスクの依頼文までは書きません。書いてしまうと「Claudeに渡せばいい」モードに頭が切り替わって、優先順位の判断が雑になります。
タスクごとに30分以内のPlan Modeで計画を立てる
ここからはタスク1つずつ処理します。複数タスクを同時に1セッションで進めると、コンテキストが「タスクA・タスクB・タスクC」の混ざった状態になり、Claudeがどれの話をしているか曖昧になります。
新しいタスクに入るときは、まず/clearで前のタスクの残骸を捨てます。
claude --permission-mode plan セッション内であればShift+Tabを2回押せば、Auto-Accept Mode → Plan Modeの順に切り替わります。Plan Modeは読み取り系ツールしか動かないので、コードを壊す心配なくClaudeに調査させて計画だけ作らせることができます。
依頼文のテンプレートは次の3行で十分です。
@docs/spec.md と @src/cli/ を読んで、
「{{タスク内容}}」を実現する計画を立てて。
触るファイル一覧、テスト方針、影響範囲、想定外の依存追加の有無を含める。計画が出てきたら、Ctrl+Gでテキストエディタに開いて自分で読むのが安全です。公式がBest Practicesで勧めているとおり、計画段階で読み違いを直しておくと、実装後の手戻りが激減します。
計画レビューで毎回見る5項目
| 観点 | 何を確認するか |
|---|---|
| スコープ | 朝に決めたタスク以外に手を伸ばしていないか |
| 依存追加 | 新しいnpmパッケージやサービスを呼んでいないか |
| テスト | 何を検証するか具体的なコマンドが書かれているか |
| 互換性 | 既存の入出力形式を壊していないか |
| 秘密情報 | .envや認証情報を読み込んでいないか |
OKならNormal Modeに戻します。
実装は「Claudeに任せる時間」と「人間が見守る時間」を分ける
Normal Modeに切り替えたら、計画にそって実装させます。依頼文はシンプルです。
今の計画に従って実装して。
完了したら次を順に実行し、結果を報告して。
1. npm test
2. npm run lint
3. git diff --stat
4. 想定外の追加（依存・設定・生成物）があれば列挙ここで効くのが検証コマンドを依頼文に埋め込んでおくことです。Best Practicesも「検証手段を与えることが最も効果が高い」と書いています。Claude自身がnpm testの結果を見て直せるので、人間が画面を見続ける必要が減ります。
実装中の人間の役割
Claudeに任せている1〜2時間、人間は全部見続けないで構いません。ただし次の3タイミングだけは確認します。
- 計画から逸脱した瞬間：「やっぱり別ファイルも触る」と言い出したら
Escで止める - 依存追加が出た瞬間：「
npm installを……」と書いた行を見つけたら一旦止める - テスト失敗を3回繰り返した瞬間：根本原因を別アプローチで再検討する
3回直させても直らないときは、/clearしてより具体的な依頼文で書き直すほうが、結局速く着地します。Best Practicesも「2回修正で直らなかったら/clearして書き直せ」と推奨しています。
確認とコミットは「自分の目で差分を読む」が必須
実装が終わったら、Claudeの要約を読むのではなく、自分のターミナルでgit diffを読みます。
git diff --stat git diff 差分が大きいときはファイル単位でgit diff <path>に絞って読みます。ここを省略すると、後から/security-reviewで秘密情報の混入を見つけても、**「いつ入ったのか」**を追えなくなります。
コミット粒度・PR本文・gh pr createの運用はClaude Codeで安全にコミットとPRを作るワークフローに詳しく書いたのでそちらを参照してください。本記事の文脈では、**「1タスク=1〜3コミット=1PR」**を守るとレビューが回ります。
記録10分：NOTES.mdに「翌日の自分」あての申し送りを残す
タスクが終わったら、NOTES.mdに翌日の自分あての3〜5行を残します。これが翌朝の起点になります。
## 2026-04-27 終わり
- スラッグ重複チェッカー CLI 化: PR #142 で出した。テストは通っているがレビュー待ち
- CSV パーサ空行許容: 実装中。未着手の境界値テストあり → @tests/csv.test.ts L120 から
- README 追記: 未着手（明日の最初に倒す）
## 明日まずやること
- @tests/csv.test.ts に「先頭が空行」「末尾が空行」「連続空行」の3ケース追加
- 失敗テストを先に書いてから実装に入るこのNOTES.mdはCLAUDE.mdテンプレート完全版で書いたとおり@NOTES.mdで次の朝のセッションに読ませられます。Claudeは前日の経緯をコミット履歴より早く把握できます。
引き継ぎ5分：セッションに名前を付け、/clearか--continueを選ぶ
最後の5分でやるのは、明日の自分が困らない準備です。
セッションに名前を付ける
公式ドキュメントも推奨しているとおり、セッションには名前を付けます。
/rename csv-parser-empty-lines無題の「あの会話」は、3日経つと探せなくなります。タスク単位で命名する習慣を付けると、claude --resumeの選択画面が一気に使いやすくなります。
/clearするか、--continueで続けるか
判断はシンプルです。
| 翌日の状況 | コマンド |
|---|---|
| 別タスクに入る | 翌朝に新規セッション（前のは--resumeで必要時だけ呼び戻す） |
| 同じタスクの続き | claude —continue または claude —resume csv-parser-empty-lines |
| 仕様だけ確認したい | /btwで会話を膨らまさず一時的に確認 |
/btwは会話履歴に残らないサイドチャネル質問で、ちょっとした仕様確認をコンテキストに混ぜずに済む点が便利です。
1日のタイムライン例
実際にどう流れるかを表にしておきます。
| 時間帯 | やること | コンテキスト操作 |
|---|---|---|
| 09:00〜09:15 | CLAUDE.md再読、3タスク決定、NOTES.md更新 | セッション未開始 |
| 09:15〜09:45 | タスク1のPlan Mode計画＋レビュー | 新規 or /clear |
| 09:45〜11:00 | タスク1の実装＋テスト＋差分確認 | Normal Mode |
| 11:00〜11:30 | タスク1のコミット・PR | 同セッション |
| 11:30〜12:00 | /clearしてタスク2のPlan Mode | /clear |
| 13:00〜15:00 | タスク2実装、必要に応じてサブエージェントで調査だけ並列化 | サブエージェント分離 |
| 15:00〜16:00 | タスク3（小さめ）を一気に処理 | /clearしてから |
| 16:00〜16:30 | 全タスクのPRレビュー対応、/security-review | 各PRに--from-pr |
| 16:30〜17:00 | NOTES.md更新、/rename、明日の3タスクの種を書く | セッション保存 |
実装に2〜3時間使えるのは、朝の15分でタスクを絞り込んでいるからです。3つに絞れば、各タスクに60〜90分の集中時間が確保できます。
避けたいアンチパターン
公式のBest Practicesが挙げる「kitchen sink session（何でも放り込む長時間セッション）」は、特に1日の後半にやりがちです。次の症状が出たら**即座に/clear**してください。
- 同じファイル名を3回違って言い間違える
- 「前にも言ったけど」とClaudeを叱る回数が増える
/compactを1日に2回以上走らせている- 1セッションで5タスク以上扱っている
逆にやってはいけないのは「1日中ずっと--continue」です。コンテキストが翌日に持ち越されて、無関係な前日のファイル内容がいつまでも残ります。タスクが終わったら新規セッションを基本にしてください。
1日の終わりに使うチェックリスト
- 朝に決めた3タスクのうち、未完了のものは
NOTES.mdに理由つきで残した - 出したPRは自分の目で差分を読んだ（Claudeの要約だけで承認していない）
-
.envや秘密情報をコミットしていない（git statusで確認した） - 続けるセッションには名前を付けた
- 不要な長セッションは
/clearまたは閉じた - 明日まず触るファイルが
NOTES.mdにパス付きで書いてある
ここまで習慣化できれば、Claude Codeは**「精度が落ちる時間帯のない開発パートナー」**として1日を支えてくれるはずです。
次に読む
- Claude Codeに大きなタスクを渡す前の分解方法 — 朝に決めた3タスクをさらに小タスクに割る具体手順
- Claude Codeに「計画してから実装」させるプロンプト例 — Plan Modeの依頼テンプレートと中断条件
- Claude Codeで安全にコミットとPRを作るワークフロー — 1日の終盤の確認・コミット・PRの実装
