Claude Code に -[ ] チェック入れさせる方法を使うと、ファイルを記憶装置として使うと開発効率上がる。こんなやつね
タイトルの Claude Checklist Driven Development（CCDD）っていうのは、ワイが勝手に作った言葉
X で毎日 AI 情報を配信してるコムテです。Claude Code / AI 駆動開発 / Claude Code などを中心に情報を配信しています
ファイルを外部メモリにする
この記事は Tech with Mak 氏の X 投稿にインスピレーションを受け、Anthropic 公式ドキュメントと複数の研究論文を引っ張り出して検証したもの
具体的には以下の 3 つのファイルを軸にする
CLAUDE.md- Claude Code の行動指針と記憶のインデックスtasks/todo.md- 今やるべきことの計画と進捗管理tasks/lessons.md- 過去の失敗と学びの蓄積
この仕組みの強さは、セッションが切れても記憶が消えないこと。次のセッションで Claude Code が CLAUDE.md を読み込んだ瞬間、前回の続きからスムーズに作業を再開できる。まるで優秀な同僚が引き継ぎノートを完璧に残してくれてるような感覚
思いついてた人もいるだろうけど、案外やってる人少なそう
NeurIPS 2023 で採択された「Reflexion」(2303.11366) という論文がまさにこのアプローチの理論的裏付けになる。Reflexion は重み更新ではなく言語的フィードバックで強化学習を行うフレームワークで、エージェントがタスクのフィードバックを言語で振り返り、エピソディックメモリバッファに反省テキストを保持して次の試行での意思決定を改善する。やろうとしてるのは、まさにこの Reflexion のアプローチを Claude Code に適用すること
Claude Code には Auto Memory というビルトインのメモリシステムもあるが、それは後述する
CLAUDE.md
まずはじめに、CLAUDE.md にこれを書く
これだけ。Claude Code はセッション開始時に CLAUDE.md を自動で読み込むから、この指示によって必ず todo.md と lessons.md を最初に確認するようになる。結果として、前回のセッションの続きからシームレスに作業できる
tasks ディレクトリを作る
コマンドでサクッと
ディレクトリ
tasks/todo.md による計画駆動開発
多くの開発者が Claude Code を使うとき、いきなりコードを書かせ始める。やけどそれだと Claude Code が途中で迷子になりやすい。特に複雑なタスクでは、全体の見通しがないまま部分的な実装を進めてしまい、あとで整合性が取れなくなることがある
tasks/todo.md のワークフローはこの問題を根本から解決する
tasks/lessons.md で同じ失敗を繰り返さない
開発で一番もったいないのは、同じバグを何度も踏むこと。人間の開発者なら「あ、これ前にも見たやつや」と気づけるけど、セッションが切れるたびにリセットされる Claude Code にはその記憶がない
tasks/lessons.md がこの問題を解決する
このファイルのポイントは、具体的な行動レベルまで落とし込むこと。「型に気をつける」みたいな曖昧な教訓やなくて、「Prisma のスキーマを変更したら必ず npx prisma generate を実行する」のように、Claude Code がそのまま実行できるルールにする
arxiv の「A Survey of Self-Evolving Agents」(2507.21046) が整理した Plan-Execute-Reflect-Memorize ループそのもの。エージェントが計画し、実行し、結果を振り返り、学びをメモリに保存する。このサイクルを回し続けることで、エージェントはオンジョブで進化していく
Claude Code のビルトイン Auto Memory も活用する
ここまで tasks/todo.md と tasks/lessons.md による手動メモリ管理を見てきたけど、Claude Code には Auto Memory というビルトインのメモリシステムもある
公式によると、Auto Memory は CLAUDE.md とは根本的に違う。CLAUDE.md は「人間が Claude に向けて書く指示」やけど、Auto Memory は「Claude 自身がセッション中に見つけたパターンや知見を自分で書き留めるメモ帳」。保存先はユーザーのホームディレクトリ配下で、プロジェクトパスのハッシュごとに分かれてる
同じ Git リポジトリ内ならサブディレクトリが違っても 1 つの Auto Memory を共有する。Claude Code 2.1.32 で導入された機能で、セッション中に「Recalled 1 memory, wrote 1 memory」のように自動で読み書きしてくれる
ここで注意したいのは MEMORY.md の 200 行ルール。自動でシステムプロンプトに読み込まれるのは最初の 200 行だけ。やけどこれは Auto Memory 全体の容量制限やない。200 行を超える詳細な内容は debugging.md や patterns.md みたいなトピックファイルに分けて書いておけば、Claude が必要なときにオンデマンドで読みに行ってくれる。MEMORY.md はあくまでインデックスとして簡潔に保つのがコツ
Auto Memory が自動で記憶してくれる内容はこんな感じ
- プロジェクトパターン（ビルドコマンド、テスト規約、コードスタイル）
- デバッグ知見（トリッキーな問題の解決策、よくあるエラー原因）
- アーキテクチャメモ（重要ファイル、モジュール関係、抽象化）
- ユーザー設定（コミュニケーションスタイル、ワークフロー習慣）
自分から「pnpm を使うことを覚えておいて」「API テストにはローカルの Redis が必要なことをメモリに保存して」と直接指示もできるし、/memory コマンドでファイルセレクタを開いて直接編集もできる
Auto Memory はまだ段階的ロールアウト中。まだ見当たらない場合は CLAUDE_CODE_DISABLE_AUTO_MEMORY=0 を環境変数にセットすれば強制的に有効にできる
わざわざ tasks/ ディレクトリに書く理由
じゃあ Auto Memory があるのに、なんでわざわざ tasks/ ディレクトリで手動管理するのか
「プロジェクト内に作れるなら共有できるやん？」と思うかもしれないが、ここが紛らわしいポイント。Auto Memory の保存先は ~/.claude/projects/<project>/memory/ なので、プロジェクトディレクトリ内やなくてユーザーのホームディレクトリ配下。つまり Git の管理外で、チームメンバーとは共有できない構造になってる
一方で tasks/todo.md と tasks/lessons.md はプロジェクトルート直下に置くから、普通に Git で追跡できる。チーム全員の Claude Code が同じ教訓を共有できるし、新メンバーが git clone した瞬間にプロジェクトの知見が手に入る
もう一つの違いは、Auto Memory は Claude が「自分で判断して」書くもの。何を記憶するかの制御が人間側にない。一方で tasks/ ディレクトリは人間が意図的に構造化できる。「この教訓は絶対に忘れるな」「このタスクの順番で進めろ」みたいな強い指示は、手動メモリのほうが確実に伝わる
Auto Memory と手動メモリは排他的やなくて相互補完的。Auto Memory には Claude が自然に拾うプロジェクトの暗黙知を任せて、tasks/ ディレクトリには人間が明示的にコントロールしたい計画と教訓を入れる。この使い分けがベストプラクティス
まとめ
Claude Code の生産性を劇的に上げるのに、特別なツールや複雑な設定は要らない。必要なのは 3 つのファイルと、それを中心にしたシンプルなワークフロー
CLAUDE.mdで記憶のハブを作るtasks/todo.mdで計画を立ててから実装するtasks/lessons.mdで失敗を記録して同じミスを繰り返さない
後は、このあたりも組み合わせるといいね
- Plan Mode で見通しを立ててから着手する
- サブエージェントでコンテキストを守る
ファイルを外部メモリとして使うというシンプルな仕組みが、Claude Code を経験から学び続けるパートナーに変える。セッションが切れても記憶は残るし、チームで共有もできる。そして使えば使うほど、lessons.md が育って、Claude Code の精度が上がっていく
