Claude Codeで「長期メモリ」を活用する方法：プロジェクト進捗を賢く管理
何が嬉しいか：文脈喪失からの解放
Claude Codeを使っていて「あ、前のセッションで決めたアーキテクチャの詳細、また説明しなきゃ」という経験はありませんか？特に数日単位でプロジェクトに取り組む場合、毎回同じ背景説明を繰り返すのは時間の無駄です。
Claude Codeには公式な「プロジェクトメモリ」機能はありませんが、会話履歴の活用とプロンプト設計で、事実上「長期メモリ」を実装できます。
Before: 毎回リセット
新しいセッション開始
→ 「前回のアーキテクチャを思い出してください」と説明から開始
→ コンテキスト上限に達するまでに実装できる量が限定される
→ 開発速度が低下
After: 進捗が蓄積
セッション開始時に「プロジェクトサマリー」をペースト
→ Claude Codeが即座に文脈を理解して作業再開
→ 数ターン分のトークン節約で、より深い実装に割ける
→ 一貫した設計を維持したまま開発が加速
使い方：3つの実装パターン
パターン1：「プロジェクト概要書」の保持
新規プロジェクト開始時に、以下の情報をテキストファイル（例：PROJECT_CONTEXT.md）として管理します。
# プロジェクト: [名称]
## 概要
- 目的：〇〇を実現する
- 言語：Python / TypeScript / 他
- 期間：〇〇年〇月〜〇月
## アーキテクチャ
- フロントエンド：React + [ライブラリ]
- バックエンド：Node.js + Express
- DB：PostgreSQL
- 主要ディレクトリ構成：[構造図]
## 実装済み機能
- [ ] ユーザー認証
- [ ] データベース設計
- [x] API基本構造
## 今後の作業
- フロームバリデーション実装
- エラーハンドリング強化
新しいセッションを開く際、このファイルの内容を最初のメッセージに貼り付けるだけで、Claude Codeは即座にプロジェクト状況を把握します。
パターン2：「決定ログ」の活用
開発中に「なぜこの設計にしたのか」という判断記録を残します。
## アーキテクチャ決定ログ
### 決定1：認証方式をJWTに統一（決定日：2026-04-10）
- **理由**：ステートレス設計でスケーリング容易
- **代替案検討**：セッション認証は状態管理が複雑
- **実装者note**：refresh tokenは7日でローテーション
### 決定2：API レスポンス形式 (2026-04-12)
- **統一形式**：`{ success: bool, data: {}, error?: string }`
- **HTTP ステータス**：business logicエラーは常に200で返す
セッション再開時に「以前の決定に矛盾していないか確認しながら提案してください」と指示すれば、一貫性のある提案が得られます。
パターン3：「前回の停止点＋TODO」
セッション終了時に、Claude Codeの最後のメッセージをコピーして SESSION_END_STATE.md に保存。次のセッションではこれを見返すだけで、前回どこまで進んだかが一目瞭然です。
## 前回セッション終了時の状態（2026-04-18 18:00）
### 実装完了
✅ ユーザー登録フロームのバリデーション
✅ サーバーサイドのエラーメッセージ国際化対応
### 次回着手予定
⏭️ パスワードリセットメール送信機能
⏭️ ユーザープロフィール画像アップロード
### ブロッカー・検討事項
❓ 画像ストレージ：S3 vs. Firebase Storage
→ パフォーマンス比較が必要
注意点・落とし穴
1. 古い情報の腐敗
プロジェクトサマリーは更新を忘れると負債になります。特に：
- 仕様変更を反映させていない
- 実装済み項目のチェックマークが古いまま
- 削除された機能が載っている
→ 対策：セッション終了時に必ず5分かけて更新する習慣
2. トークン数の勘違い
「プロジェクト概要を貼り付ければ長期メモリになる」は正確には誤解です。同じセッション内で履歴が保持されるだけです。新しいセッションでは毎回ペーストが必要。
→ 注意：Claude Codeとの会話が長くなってきたら、新規セッションを開き始めることが推奨される
3. 秘密情報の取り扱い
プロジェクト概要にAPIキーやパスワードを含めてはいけません。必要な場合は：
- DB接続：環境変数から読み込み（キーは `.env.example` を参照）
- 外部API：[SERVICE_NAME] 認証済み（認証情報は別管理）
応用アイデア
1. チーム開発時の「仕様書兼進捗管理」
複数人でプロジェクトを進める場合、共有Markdownファイルをセッション開始時に必ず貼り付けることで、「A氏が実装した機能の詳細を知らない」というズレを防げます。
2. 「設計レビューチェックリスト」
新しいモジュール追加時に以下をプロンプトに加えます：
## 設計レビューチェックリスト
以下の観点から提案してください：
- [ ] プロジェクトの既存アーキテクチャと矛盾していない
- [ ] 以前決めたAPI仕様に準拠している
- [ ] 過去の実装ミスパターンを踏まえている
3. 「コード品質スナップショット」
定期的にプロジェクトの「現在の懸念点」をまとめることで、technical debtが見える化できます：
## 技術負債レポート（作成日：2026-04-18）
### 高優先度
- [x] 認証エラー時のログ出力不足 → セッション18で修正
- [ ] DBクエリのN+1問題（カテゴリ一覧で顕在化）
### 低優先度
- [ ] クライアント側の型定義が甘い
出典
- 公式：Anthropic Claude Code仕様（context window管理）
- ベストプラクティス：「プロンプトエンジニアリング」における文脈管理の知見
- ユーザーTips：複数セッション間の情報保持に関する開発者コミュニティの実装例
※ここでご紹介した「プロジェクトメモリ」は、Claude Codeの会話履歴機能を活用したユーザー工夫です。Anthropic公式の「永続メモリ機能」ではありません。