結論:Claude Code時代に最適なdoc管理、それが「日付_機能名.md」
個人開発をしていると、「前回ここ何やったっけ?」「あれ、なんでこの設計にしたんだ?」という“意図の断絶”が必ず訪れる。
特にClaude CodeなどのAIコーディングツールを活用している場合、その断絶はAIにとっても致命的で、的外れな提案やバグの温床になることもある
で、こう思うんよね
- Claude Code に「どこまで実装が終わっているか」自動で認識させたい
- 自分やチームメンバーに対して「どんな実装を、いつ頃やったのか」伝えたい
そこで便利なのが、_docs/templates/
に yyyy-mm-dd_機能名.md
という形式で残す「実装ログ」ルール。これ、レガシーっぽく見えて、めっちゃ合理的
日付をつける方法を、古臭いと揶揄してはいけない。この方法は究極的に、AI と人間が認識しやすいドキュメント管理法なのである
なぜ今「mdファイル」なのか?
最近はNotionやJira、Linearなど優秀なツールが山ほどある。だけどそれでもあえて .md
ファイルでローカル管理してるのには、ちゃんと理由がある。
1. Claude Code との相性が抜群
Claude Codeにこう指示しておく
実装が完了したら、要件定義ディレクトリ _docs/
に「yyyy-mm-dd_機能名.md」で実装ログを残して。そこには、実装の背景・設計意図・副作用・関連ファイルを簡潔に書いて。起動時もこのディレクトリを読んでおいて。
こうしておくだけで、Claudeは常に _docs/
にあるログを読み込んでくれる。これによって「前回、どんな方針で実装したか」「なぜその設計にしたか」といった“文脈”を理解してくれるんやな
正確な日付
Claude Code は、日時の取得が下手である。
Time MCP Server使うか、.zshrcで以下のnowコマンド作り CLAUDE me に「今日の日付をコマンド now で取得して」と書くだけでよい
2. Gitと相性がいい
.md
ファイルなのでGit管理に最適。差分も取りやすく、レビューもできる。日付+機能名形式だから、時系列での検索性もめっちゃ高い
Git管理だけだとセッションが切れるたびにClaudeが記憶を失うが、この方法はコンテキストを保持できるのが強み
「情報を読みやすい形で人間と共有し可視化する」ということなんよね
3. Markdownなら誰でも読めるし書ける
わざわざドキュメント専用ソフトに頼らなくても、VSCodeやエディタでそのまま開けるし、プレビューもできる。シンプルイズベスト。
実際の構成例
このように、日付と機能名をファイル名にしておくと、タイムラインを意識した振り返りができる。
Xでの反響と実践者の声
この方法をポストしたところ、X(旧Twitter)でもいろんな実践者から反応があった。
Snow さん:Git管理だけだとセッションが切れるたびにClaudeが記憶を失う。でもこの方法は「自前のコンテキスト保持&メモリ機能」になる。なるほど的確
Nier さん:作業開始時に日付フォルダを作成し、タスクごとに yyyy-mm-dd__
の形式でドキュメント生成。Claudeに読ませる設計書として活用してるらしい。プロダクト管理感あるね
ROU さん:Claudeの暴走が増えたので導入。AI coding はこういう定期メンテが生産性に直結する。まさに。
みんな同じような課題を感じて、辿り着いた実装ってことか。他にも有益な情報を沢山いただいたが、長くなるので今回は一部紹介。感謝したい
Claudeの強みを引き出す運用Tips
Claudeにとってこの形式は“最高の燃料”。Claudeはファイル構造や時系列の理解が得意やから、このような構成を自然にナビゲートできる
Claudeに読み込ませるプロンプト例
この一文を冒頭に添えるだけで、Claudeの提案精度が格段に変わる。たとえば「product_registration は v2 があるので、それをベースに進めます」とか、「occupation_pulldown_update の副作用を考慮してください」みたいに、ちゃんと“記憶してる”ように動いてくれる。
どういう情報を.mdに残すべきか?
あくまでClaudeに読ませる前提なので、冗長な仕様書である必要はない。Token が心配なら要点だけ記録させてもいい
最低限こんな構成でOK
セクション | 内容例 |
---|---|
機能名 | Stripe連携バグ修正 |
日付 | 2025-06-06 |
概要 | Stripeのwebhookイベント処理が二重送信されるバグを修正 |
変更点 | webhook handlerのidempotencyチェックを追加 |
副作用 | subscriptions テーブルの updated_at が頻繁に変わる可能性あり |
関連ファイル | /api/stripe/webhook.ts |
なぜ他のAI(GPT-4など)では難しいのか?
Claudeが特に優れているのは「長文コンテキスト保持」と「ファイル構造の解釈力」。GPT-4にも似た使い方はできるけど、Claudeほど「自然にドキュメントを記憶しながら実装を継続」できるAIはまだ珍しい。
実際、Claudeに _docs/
を読ませてから、「続き書いて」と指示するだけで、何の文脈説明もなしにスッと続きを提案してくれる。
実装ログの命名規則が重要な理由
Claudeはファイル名から文脈を推測する力がある。だからこそ、次のような命名が効いてくる。
2025-06-06_product_title_placeholder.md
→ Claude「これはタイトル入力欄のプレースホルダを扱ってるな」2025-06-03_notification_system_analysis.md
→ Claude「通知システムの分析段階やな、まだ実装前かも」
命名に時系列を入れるだけで「最近の実装」「古い設計」「未対応の要件」が視覚的に分かりやすくなるし、Claudeにとっても理解しやすい
まぁ、俺達と同じやな
結果として、個人開発の負担が激減した
この運用に切り替えてから、Claudeとの対話がめちゃくちゃスムーズになったのよ
- いちいち背景を説明しなくてよくなった
- 副作用の見落としが減った
- 残件の把握が楽になった
- 「あれどこまでやったっけ?」が減った
- むしろ、「ここまでやってますよ」と教えてくれる
要するに、「AIが記憶を持ったかのように振る舞ってくれる」
いや、これ凄いよね。有能すぎる社員やもん
終わりに
この「日付+機能名で実装ログをMarkdownに残す」という運用、シンプルなのにClaudeと相性抜群で、めっちゃ強い
そもそも、実装後に、勝手に書いてくれるのがいいよね
ログを書く文化がないと、AIは“空のノート”に向かって喋ってるようなもん。でも、ほんの少しの習慣でClaudeは“記憶のある開発パートナー”になる