Claude Codeのメモリ機構を完全解説｜MEMORY.md・CLAUDE.mdの使い分けと活用法

Claude Codeには、会話をまたいで情報を記憶し続ける「メモリ機構」が備わっています。 これを正しく理解して使いこなすことで、毎回同じことを説明する手間がなくなり、 作業効率が大幅に向上します。

本記事では、Claude Codeのメモリ機構の仕組みを3層構造で整理し、 それぞれの使い分けと実践的な活用法を解説します。

Claude Codeのメモリ機構とは

Claude Codeは通常、会話が終わると内容を忘れます。 しかしいくつかのファイルを使うことで、次のセッションでも情報を引き継ぐことができます。

メモリ機構は大きく3種類あります。

それぞれ役割が異なるため、用途に応じて使い分けることが重要です。

1. グローバルCLAUDE.md（~/.claude/CLAUDE.md）

概要

~/.claude/CLAUDE.md は、Claude Codeを起動するすべてのディレクトリで読み込まれるグローバルな設定ファイルです。 個人の作業スタイルやルールを記載しておくと、どのプロジェクトでも一貫した振る舞いが得られます。

書くべき内容

• コミュニケーションルール（言語、口調など）
• よく使うツールの挙動設定
• コーディングの基本方針
• スキルの使い方ルール

記載例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

## コミュニケーション
- 日本語で応答すること
- ですます調で記述すること

## ツール使用
- 読み取り系コマンドは確認不要で実行してよい

## スキル使用ルール
### session-record-start
- 必ず `pwd` を実行してから保存先を決定すること
- `pwd` が `~/projects/` 配下 → `~/.claude/sessions_projects/`
- それ以外 → `~/.claude/sessions/`

注意点

200行を超えると読み込みが打ち切られるため、簡潔に保つことが重要です。 詳細な情報は別ファイルに切り出し、リンクで参照する形をおすすめします。

2. リポジトリCLAUDE.md（~/project/CLAUDE.md）

概要

プロジェクトのルートディレクトリに置く CLAUDE.md は、チームで共有するルールを記載するファイルです。 gitでバージョン管理されるため、チームメンバー全員が同じルールのもとでClaude Codeを使えます。

グローバルCLAUDE.mdとの違い

1
2

グローバル CLAUDE.md  ＝  個人の .bashrc / .zshrc
リポジトリ CLAUDE.md  ＝  チームの .editorconfig / .eslintrc

書くべき内容

• このリポジトリ固有のコーディング規約
• ディレクトリ構成の説明
• よく使うコマンドや操作手順
• レビュー時の注意点

記載例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

## プロジェクト構造
- `src/` - アプリケーションコード
- `terraform/` - インフラ定義
- `docs/` - 技術ドキュメント

## コーディングルール
- 依頼されたことのみ行う（過剰実装しない）
- 既存ファイルの編集を優先し、新規ファイルは最小限にする

## テスト
- PRを出す前に必ず `make test` を実行すること

チームへの恩恵

新しいメンバーがジョインしたとき、CLAUDE.mdを読んだClaudeが自動的にプロジェクトの文脈を把握します。 オンボーディングコストの削減にも効果的です。

3. MEMORY.md（~/.claude/projects/.../MEMORY.md）

概要

MEMORY.mdは、Claude Codeが自分自身でメモを書き込めるプロジェクト固有のノートです。 セッションをまたいで永続的に保存され、次回起動時に自動的に読み込まれます。

保存場所の仕組み

保存先は起動ディレクトリのパスをダッシュ区切りに変換した形になります。

1
2
3
4
5

起動ディレクトリ: /Users/username/projects/myapp
         ↓
パスをダッシュ区切りに変換
         ↓
~/.claude/projects/-Users-username-projects-myapp/memory/MEMORY.md

重要な特性：ディレクトリが異なると別のMEMORY.md

1
2
3

~/projects/myapp        → Memory A
~/projects/myapp/src    → Memory B（別物）
~/projects/otherapp     → Memory C（別物）

起動ディレクトリが完全一致しないと異なるMEMORY.mdになります。 サブディレクトリで起動した場合は別扱いになる点に注意してください。

グローバルCLAUDE.mdとの使い分け

書くべき内容の例

1
2
3
4
5
6
7

## このリポジトリで調査した知見
- 本番DBのエクスポートは同一クラスタ同時実行1つまで
- バッチ処理はJST 1:30以前に完了させること

## よく使うコマンドパターン
- 再実行時はidxをインクリメントすること
  `{"cluster_prefix": "app-infra-", "idx": 2}`

Claudeが自動で書き込む

MEMORY.mdの特徴の一つは、Claudeが会話の中で発見した有益な情報を自分でここに書き込める点です。 「これ覚えておいて」と言うと、次のセッション開始時にすでに把握した状態になります。

3層構造の全体像

1
2
3
4
5
6
7
8

~/.claude/CLAUDE.md              ← 個人グローバル（全プロジェクト共通）
       ↓ 常時読み込み

~/projects/myapp/CLAUDE.md       ← チーム共有（gitで管理）
       ↓ そのプロジェクト起動時

~/.claude/projects/.../MEMORY.md ← 個人プロジェクト固有メモ
       ↓ そのディレクトリ起動時のみ

上位のルールほど広く適用され、下位になるほど特定のコンテキストに限定されます。 情報の性質に応じて適切な層に書くことで、無駄な重複や読み込みの肥大化を防げます。

よくある失敗パターンと対策

失敗1：グローバルに書くべきことをMEMORY.mdに書いてしまう

問題: スキルの使い方ルールをMEMORY.mdに書いたが、別のディレクトリで作業すると参照されない。

対策: どのプロジェクトでも使うルールはグローバルCLAUDE.mdへ。

失敗2：MEMORY.mdが肥大化する

問題: なんでも書き込んだ結果、200行制限に引っかかり重要な情報が読み込まれなくなる。

対策: 定期的に棚卸しをして古くなった情報を削除する。見出しと箇条書きで簡潔に保つ。

失敗3：チーム固有のルールを個人設定に書いてしまう

問題: グローバルCLAUDE.mdにリポジトリ固有のルールを書いたため、他のプロジェクトで混乱する。

対策: チームで使うルールはリポジトリルートのCLAUDE.mdに書いてgitで共有する。

失敗4：pwd確認を省略して保存先を誤る

問題: スキル実行時にpwd確認をスキップし、誤ったディレクトリにファイルを保存した。

対策: スキル実行前にpwdを必ず実行するルールをグローバルCLAUDE.mdに明記する。

実践：MEMORY.mdの運用例

実際の運用では、以下のような情報をMEMORY.mdに蓄積していくと効果的です。

技術的な知見

1
2
3
4

## 調査済み仕様
- DBエクスポートの同時実行制限: 同一クラスタ1つまで
- クエリエンジンのUNLOAD: Parquet形式が最も高速
- BQ Load: gs://のみ対応（s3://は不可）

よく使うコマンドのパターン

1
2
3
4
5
6
7

## バッチ再実行
# idxは毎回インクリメントすること
{
  "cluster_prefix": "app-infra-",
  "idx": 2,
  "snapshot_date": ""
}

プロジェクト固有の注意点

1
2
3

## 運用上の注意
- 本番作業は夜間バッチ前に完了またはキャンセルすること
- 開発環境のジョブスケジューラはキューから試し打ち可能

まとめ

Claude Codeのメモリ機構を整理すると、次の3層構造になります。

この3層を適切に使い分けることで：

• 毎回同じことを説明する手間がなくなる
• チームメンバー全員が同じコンテキストでClaudeを使える
• プロジェクト固有の知見を自動で引き継げる

Claude Codeを単なる「その場限りのアシスタント」ではなく、継続的に成長するチームメンバーとして活用するために、メモリ機構を積極的に使っていきましょう。

参考

• Claude Code 公式ドキュメント
• CLAUDE.mdの200行制限に注意（超過分は読み込まれない）
• MEMORY.mdは ~/.claude/projects/{パス}/memory/MEMORY.md に自動生成される