🧠

Claude Code の 6種類のメモリと優先順位を理解して効率的に活用しよう

に公開
AI
LLM
Claude
Claude Code
tech

Claude Code をひたすら使い続けています。ただ、いつの間にやらメモリ管理の手法が更新されていたので、改めて整理してみました。

この記事では、Claude Code の 6種類のメモリ とその 優先順位 について解説します。それぞれのメモリがどのように適用されるのか、実際に検証した動画も作ってみたので時間のある方はぜひご覧ください。

https://youtu.be/Dw7TUQqgXgw?si=wggZ_MBxrHRBrCC5

TL;DR

  • Claude Code には 6種類のメモリ がある（公式ドキュメントでは5種類だが、User-level Memory を含めると実際は6種類）
  • 優先順位は Enterprise > Project Memory = Project Rules > User Memory = User-level Rules > Local
  • 下位のメモリは上位に打ち消されるわけではなく、競合しない内容は 「いい感じに」マージ される

なぜメモリ管理が必要なのか？

LLM は基本的に ステートレス です。新しい会話を始めると、それまでの文脈はリセットされてしまいます。

コーディングをしていると「毎回同じことを説明しないといけない」という経験はありませんか？組織レベルのルール、プロジェクト内のルール、個人的な好み...これらを毎回会話のたびに伝えるのはやっていられないです。

この問題を解決する一つの方法として Claude Code の メモリ管理 があります。

6種類のメモリとその配置場所

公式ドキュメントの表 を見ると、執筆時点（2025/12/13）では5種類となっていますが、実際は User-level Memory を含めた 6種類 になります。

それぞれのメモリの種類と配置場所を表にまとめました。

メモリの種類 配置場所 主な用途
Enterprise Policy /etc/claude-code/CLAUDE.md (Linux)
~/Library/Application Support/ClaudeCode/CLAUDE.md (Mac)
%PROGRAMDATA%\ClaudeCode\CLAUDE.md (Windows)		 組織のセキュリティポリシー、コンプライアンス
Project Memory CLAUDE.md または .claude/CLAUDE.md プロジェクト全体のアーキテクチャ、技術スタック
Project Rules .claude/rules/*.md モジュール単位の規約（frontend.md, backend.md など）
User Memory ~/.claude/CLAUDE.md 個人の好み（日本語でやり取り、サマリーを出すなど用途は様々）
User-level Rules ~/.claude/rules/*.md 個人 x ファイルタイプ別の設定
Project Local CLAUDE.local.md プロジェクト固有の自分独自の設定(e.g. 現在のブランチ固有の指示)

優先順位の仕組み

Claude Code メモリ優先順位の図

公式ドキュメントおよび実際の検証に基づくと、優先順位は以下のようになります。

Enterprise > Project Memory = Project Rules > User Memory = User-level Rules > Local

重要なポイント: 下位にあるメモリは基本的に上位を打ち消すことができません。ただし、問答無用に下位の設定が無視されるわけではなく、競合しない内容に関しては「いい感じに」マージ されます。

新機能の Project Rules と User-level Rules

特に最近追加された Project Rules や User-level Rules は今後かなり活用できる印象があります。Cursor に存在している Rules と同じような使い方ができそうです。

Project Rules の活用例

もともと私は以下のように整理していました。

.
├── .cursor/
│   └── rules/
│       └── frontend.md
└── frontend/
    ├── app/
    └── CLAUDE.md  # 冗長にルールを書きたくない&ルートのCLAUDE.mdにも
                   # 書きたくないので @.cursor/rules/frontend を読み込ませる

Project Memory の CLAUDE.md を肥大化させたくないので、サブディレクトリにも CLAUDE.md を作ったりしていました。今回追加された Project Rules のおかげで、以下のように書けるようになります。

.
├── .claude/
│   └── rules/       # Claude Code に Cursor のような rules が置けるようになった
│       └── frontend.md
└── frontend/
    └── app/

シンボリックリンクにも対応 しているので、Cursor を使っている人であれば以下のようにして共通化することも可能です。

.
├── .claude/
│   └── rules/
│       └── frontend.md -> ../../.cursor/rules/frontend.md  # シンボリックリンク
├── .cursor/
│   └── rules/
│       └── frontend.md  # 実体はここ
└── frontend/
    └── app/

Project Rules の書き方

Project Rules では paths でファイルパターンを指定できます。

---
paths: README.md, docs/global/**/*
---

## ルール

- 英語で書く
- 最初の一文は "This product is..." から始める
- 箇条書きを必ず入れる
- 日本語は絶対使わない

このように設定すると、README.md や docs/global/ 配下のファイルを扱う時だけこのルールが適用されます。

User-level Rules の活用例

User-level Rules にも可能性を感じています。例えば以下のように書いておくことで、TypeScript のコードを生成した後に特定の観点でレビューしてもらうようなプロンプトを設定できます。

---
paths: **/*.ts
---

## 和田卓人さんによるレビュー

あなたは和田卓人(t-wada)さんです。TypeScriptのファイルを編集したあとに、和田卓人さんの観点による編集内容のレビューをしてフィードバックをください。

実際にはもっとコンテキストを考慮した詳細な指示を書いたり、Sub-agent を活用した方が良いでしょうが、自分のお気に入りの設定をユーザーレベルで入れられるのは便利ですね。

実際の活用イメージ

実際のプロジェクトでは以下のような役割分担で活用していけると思っています。

メモリの種類 活用例
Enterprise Policy(※) OWASPトップ10を常に意識、コードレビューはPR必須・直プッシュ禁止、ログに個人情報マスキング必須
Project Memory フロントエンドはNext.js（App Router）、データベースはPostgreSQL+Prisma、TypeScript strictモード必須
Project Rules app/**/*.tsx, components/**/*.tsx に対して：Tailwind CSS使用、サーバーコンポーネント優先、 use client は最小限
User Memory 会話のやり取りは日本語で行う、ファイル編集後は簡単にサマライズする
User-level Rules **/*.ts を編集した時はテストをどう書くか先に提案してもらう
Project Local 現在のブランチ固有の情報、今日のタスク、実験的な設定

※ Enterprise Policy は個人で使う機会は少ないと思いますが、組織で Claude Code を導入する際には、この層の存在を知っておくと様々な問題を未然に防げる可能性が高まりそうです

メリットとデメリット

メリット

  • 巨大な CLAUDE.md を避けられる: ルールを分割して管理できるので、見通しが良くなる
  • コンテキストの効率的な活用: 必要なファイルに対してだけルールを適用できる
  • チーム開発での恩恵: 組織・プロジェクト・個人のレイヤーで設定を分離できる
  • Cursorや他のプロンプトとの共通化: シンボリックリンクでルールを共有できる

デメリット

  • 設定が分散して把握しづらい: 6種類もあると、どこに何を書いたか忘れがち(ただし、Rulesには期待したい)
  • 新規ファイル作成時の挙動が不安定: paths 指定のルールが適用されないケースがある
  • デバッグが難しい: どのメモリが優先されているのか、実際に試さないとわからないことも（/statusで見れることがあるが、なんだか不安定）
  • 学習コスト: 最適な分割方法を見つけるまでに試行錯誤が必要

まとめ

Claude Code のメモリ管理は、セッションを超えて設定を保持するための重要な仕組みです。

6種類のメモリと優先順位を理解することで、以下のような使い分けができます。

  1. Enterprise Policy: 組織全体で絶対に守らせたいルール
  2. Project Memory / Rules: プロジェクト固有の設定
  3. User Memory / Rules: 個人の好みやワークフロー
  4. Project Local: プロジェクトレベルでの個人の好みの設定

特に最近追加された Project Rules と User-level Rules は、ファイルパターンに応じた条件付きのルール適用ができるので、今後さらに活用の幅が広がりそうです。

メモリ管理をしっかり意識することで、巨大な CLAUDE.md を避け、コンテキストも効率的に活用できるようになります。継続的に磨いていきたいですね！

Discussion