概要
Claude CodeのTodoWrite機能は、AIがタスクリストを作成・管理するための仕組みです。2025年8月から2026年4月にかけて、複数のプロジェクトでTodoWriteを使った開発を続けてきました。
その中で見えてきたのは、タスク粒度が3-7アイテムのとき最も効率が良いということです。少なすぎると方向を見失い、多すぎるとコンテキストウィンドウを圧迫します。
本記事では、プロジェクト別のTodoWrite使用パターン、最適なタスク粒度、セッション分割の判断基準、そしてRead連打問題について記録します。
TodoWriteとは
Claude Codeには、タスクリストを作成・更新するTodoWrite機能があります。AIが「今やるべきこと」をリスト化し、1つずつ完了にしていきます。
1☐ config.py にモジュールCのパラメータを追加2☐ moduleC.py を作成3☐ moduleManager.py にモジュールCのimportを追加4☐ engine.py にモジュールCの呼び出しを追加5☑ ユニットテストを作成・実行 ← 完了人間のタスク管理ツール(Jira、GitHub Issues)とは異なり、TodoWriteは1セッション内でのAIの作業管理に特化しています。
プロジェクト別の使用パターン
データ分析プロジェクト:3-7アイテム
分析モジュールの量産時は、1モジュール = 1タスクとして3-7アイテムを管理していました。
1☐ モジュールC 作成2☐ モジュールD 作成3☐ モジュールE 作成このプロジェクトでは「1つの分析モジュールを追加する」という作業が明確に定義されており、タスクの粒度が自然に揃いました。3-7アイテムという範囲は、1セッションで完了可能な量として最適です。
icoi-v4プロジェクト:最大50アイテム
ECサイト構築時は、商品のMDXファイル生成で最大50アイテムに達する場面がありました。
1☐ エチオピア イルガチェフェ MDX生成2☐ コロンビア スプレモ MDX生成3☐ ブラジル サントス MDX生成4... (以下27件)50アイテムのTodoWriteは非効率でした。理由は以下の通りです。
- タスクリストの表示だけでコンテキストを消費する
- AIが全タスクの状態を把握するのに時間がかかる
- 後半のタスクで品質が低下する
最終的に、8-10件ずつのバッチ処理に切り替えました。
claudelogプロジェクト:Spec-Driven Development
Spec-Driven Development(仕様駆動開発)では、要件定義→設計→テスト設計→タスク分割→実装の全工程でTodoWriteを使いました。
1☐ 要件定義書の作成2☐ 技術設計書の作成3☐ テスト設計書の作成4☐ タスク分割5☐ 実装: CLI引数パーサー6☐ 実装: ログ読み込み7☐ 実装: Ollama要約8☐ テスト実行工程が異なるタスクを混在させると、粒度が不揃いになります。「要件定義書の作成」と「CLI引数パーサーの実装」では作業量が全く異なります。対策として、工程ごとにTodoWriteをリセットする運用にしました。
最適なタスク粒度
3-7アイテムが最適な理由
| アイテム数 | 状態 | 問題 |
|---|---|---|
| 1-2 | 少なすぎ | 次に何をすべきか方向を見失う |
| 3-7 | 最適 | 1セッションで完了可能、全体像を把握しやすい |
| 8-15 | やや多い | 後半で品質が低下し始める |
| 16+ | 多すぎ | コンテキストウィンドウを圧迫、管理コストが増大 |
タスク1つの理想的なサイズ
- 所要時間: 10-30分で完了する単位
- 成果物: 1つのファイル変更、または1つの機能追加
- 検証可能: テスト実行やビルド確認で完了を判定できる
1# 良いタスク粒度2☐ moduleC.py の作成とユニットテスト3
4# 粗すぎるタスク粒度5☐ 分析モジュール全体の実装6
7# 細かすぎるタスク粒度8☐ moduleC.py のimport文を追加9☐ moduleC.py のcalculate関数を追加10☐ moduleC.py のgenerate_result関数を追加セッション分割の判断基準
「続けてください」のパターン
長時間の作業では、以下のようなやり取りが頻繁に発生しました。
1私: 「続けて作成してください」2私: 「続きをお願いします」3私: 「作業続行してください」これらの指示が増えてきたら、セッション分割を検討すべきサインです。
セッション分割の3つの判断基準
基準1: タスクの残量
残りタスクが5個以上ある場合、新しいセッションで作業した方が品質が高くなります。
基準2: AIの応答品質
以下の兆候が見えたら、コンテキストウィンドウが逼迫しています。
- 同じファイルを何度も
Readする(Read連打問題) - 以前のセッションで決めたルールを忘れる
- 「すでに完了したタスク」を再度実行しようとする
基準3: 作業の性質が変わるとき
「コード実装」から「テスト作成」に移る、「バックエンド」から「フロントエンド」に移るなど、作業の性質が変わるタイミングはセッション分割の好機です。
Read連打問題
何が起きるか
セッションが長くなると、Claude Codeが同一ファイルを5-8回繰り返しReadする現象が発生します。
1Tool: Read file "src/config/config.py"2... (作業)3Tool: Read file "src/config/config.py" ← 再読み込み4... (作業)5Tool: Read file "src/config/config.py" ← また再読み込みなぜ起きるか
コンテキストウィンドウが長くなると、古い情報がウィンドウの外に押し出されます。AIは「ファイルの内容を覚えていない」ため、再度読み込みます。しかし、読み込んだ内容がまたすぐにウィンドウの外に出るので、同じファイルを何度も読む悪循環に陥ります。
対策
対策1: セッションを分割する
最も効果的な対策です。新しいセッションはコンテキストが空なので、Read連打は発生しません。
対策2: CLAUDE.mdに要約を書く
頻繁に参照するファイルの要約をCLAUDE.mdに書いておくと、毎回Readする必要がなくなります。
1## config.py の構造2- LINE 1-50: インポートと定数定義3- LINE 51-100: モジュールA設定4- LINE 101-150: モジュールB設定5- LINE 151-200: モジュールC設定対策3: 1タスク完了ごとに状態を報告させる
1各タスク完了時に、以下を報告してください。2- 変更したファイル一覧3- 次のタスクで必要なファイル一覧4- 現在のTodoWrite状態これにより、AIが「次に何をすべきか」を自分で整理し、不要なReadを減らせます。
TodoWrite駆動開発のテンプレート
これまでの経験から、以下のテンプレートに落ち着きました。
セッション開始時の指示
1以下のタスクをTodoWriteで管理しながら実装してください。2
31. [タスクA]42. [タスクB]53. [タスクC]6
7各タスク完了時にテストを実行し、問題なければ次に進んでください。81セッションで完了しない場合は、残りタスクを報告して終了してください。セッション引き継ぎ時の指示
1前回のセッションで以下が完了しています。2- [完了タスクA]3- [完了タスクB]4
5今回は以下の残りタスクを実施してください。6- [残りタスクC]7- [残りタスクD]8
9前回作成したファイル: src/xxx.py, src/yyy.pyまとめ
| ポイント | 推奨 |
|---|---|
| タスク粒度 | 3-7アイテム |
| 1タスクのサイズ | 10-30分で完了する単位 |
| セッション分割 | 残タスク5+、Read連打発生、作業性質の変化 |
| Read連打対策 | セッション分割、CLAUDE.md要約、状態報告 |
| 工程またぎ | 工程ごとにTodoWriteリセット |
TodoWriteは「AIの短期記憶を補助するツール」です。人間のタスク管理ツールとは目的が異なります。AIの特性(コンテキストウィンドウの制約、セッション間の記憶喪失)を理解した上で使い分けることが重要です。