Claude Codeのメモリ管理完全ガイド｜CLAUDE.mdで開発効率を爆上げする方法

「AIコーディングツールを使い始めたのに、毎回同じ説明を繰り返すのが面倒くさい」「チームで使いたいけど、設定をどう共有すればいいのかわからない」――そんな悩みを抱えているエンジニアの方は多いのではないでしょうか。

AIはステートレス（状態を持たない）が原則です。新しいセッションを開始すると、前回の会話で積み上げたコンテキストはリセットされてしまいます。プロジェクトのアーキテクチャ、使用しているフレームワーク、チームのコーディング規約……毎回これらを伝え直すのは、時間と労力の大きな無駄です。

Claude Codeが提供するメモリ管理機能は、まさにこの課題を解決するために設計されています。「CLAUDE.md」というMarkdownファイルを通じて、Claudeに「永続的な記憶」を与える仕組みで、一度設定してしまえばセッションをまたいで常にコンテキストが維持されます。

この記事では、Claude Codeのメモリ管理を基礎から徹底的に解説します。4つのメモリタイプの使い分けから、チーム・エンタープライズ向けの設定方法、実際の活用事例、競合ツールとの比較まで、読み終えたその日から実践できる内容をお届けします。

Claude Codeのメモリ機能とは？基本的な仕組みを理解する
- なぜメモリ管理が必要なのか
- Auto memory（自動メモリ）との違い
4種類のメモリタイプと使い分けの完全解説
メモリの追加・編集・確認：3つの操作方法
@importで実現する高度なメモリ管理術
- ファイルをモジュール化してメンテナンス性を向上
- Claudeのメモリ検索の仕組みを理解する
競合ツールとの比較：GitHub Copilot・Cursor・Gemini CLIとどう違う？
実際の活用事例：こんな使い方でチームの生産性が上がった
注意点とデメリット：過信は禁物
ベストプラクティス：明日から使える実践ルール
まとめ

Claude Codeのメモリ機能とは？基本的な仕組みを理解する

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

LLMは基本的にステートレスであり、新しい会話を始めるとそれまでの文脈がリセットされてしまいます。この問題の解決策として、Claude Codeはメモリ管理という仕組みを提供しています。

具体的には、CLAUDE.mdという名前のMarkdownファイルを特定の場所に置くだけで、Claude Codeが起動時に自動でそのファイルを読み込み、その内容をコンテキストとして保持してくれます。「毎回同じルールを説明する」という繰り返し作業から解放されるわけです。

Auto memory（自動メモリ）との違い

CLAUDE.mdファイルはClaudeが従うべき指示、ルール、設定を含むマークダウンファイルで、ユーザーが作成・管理します。一方のAuto memoryは、セッション中にClaudeが発見したことに基づいてClaudeが自分自身のために記述するメモを含みます。

つまり、メモリには次の2種類があります。

CLAUDE.md：人間が書くルールブック（「こう動いてほしい」という指示書）
Auto memory：Claudeが自動で書く作業メモ（「ここで気づいたこと」を自分用にメモ）

Auto memoryはメインファイルの最初の200行のみを読み込みます。この点は設計時に注意が必要です。重要な指示は冒頭にまとめて記述するのがベストプラクティスです。

4種類のメモリタイプと使い分けの完全解説

Claude Codeのメモリ管理の核心は、階層構造の4つのメモリロケーションを提供し、それぞれが異なる目的を果たすという点にあります。この階層構造を正しく理解することが、効率的な運用の第一歩です。

メモリタイプ	ファイルパス	共有範囲	主な用途
エンタープライズポリシー	macOS: `/Library/Application Support/ClaudeCode/CLAUDE.md`	組織全体のユーザー	セキュリティポリシー、企業コーディング標準
プロジェクトメモリ	`./CLAUDE.md` または `./.claude/CLAUDE.md`	チーム全員（Git管理）	アーキテクチャ、コーディング規約、ワークフロー
ユーザーメモリ	`~/.claude/CLAUDE.md`	自分のみ（全プロジェクト）	個人のコードスタイル、ショートカット
プロジェクトローカル	`./CLAUDE.local.md`	自分のみ（現プロジェクト）	個人的な環境設定（※非推奨）

エンタープライズポリシー：組織全体に効く最上位ルール

エンタープライズ組織は、すべてのユーザーに適用される中央管理されたCLAUDE.mdファイルをデプロイできます。このファイルは最上位の優先順位を持ち、配下のすべての設定よりも優先されます。

活用シーン： - 「社外秘情報をAIに渡さないこと」というセキュリティ制約 - 「コミット前にセキュリティスキャンを必ず実行すること」というコンプライアンス要件 - 全社共通のコーディング標準（インデントはスペース4つ、など）

構成管理システム（MDM、グループポリシー、Ansibleなど）を通じてデプロイして、すべての開発者マシン間での一貫した配布を確保します。

プロジェクトメモリ：チーム開発の共通言語

プロジェクトルートに置いたCLAUDE.mdは、Gitでリポジトリに含めることでチームメンバー全員が同じコンテキストを共有できます。プロジェクトの目的、主要な技術スタック、コーディング規約、重要なファイルパス、特定のドメイン知識などを記述します。

実際のCLAUDE.md記述例（プロジェクトメモリ向け）：

# プロジェクト概要
ECサイトのバックエンドAPI。Node.js + Express + PostgreSQL構成。

# アーキテクチャ
- コントローラー: /src/controllers/
- サービス層: /src/services/
- データアクセス: /src/repositories/

# コーディング規約
- インデント: スペース2つ
- 命名: キャメルケース（変数・関数）、パスカルケース（クラス）
- エラーハンドリング: すべての非同期処理でtry-catchを使用

# よく使うコマンド
- ビルド: npm run build
- テスト: npm test
- リント: npm run lint

ユーザーメモリ：個人の生産性を最大化する設定

~/.claude/CLAUDE.mdは、どのプロジェクトでも自動的に適用される個人設定ファイルです。自分だけの開発スタイルや好みを記述しておきます。

ユーザーメモリに適した内容の例として、作業管理ルール（「中締め」「締め」などの区切り）、個人的な開発スタイル（4行以内での簡潔な回答を好む、絵文字は使わないなど）があります。

ユーザーメモリの記述例：

# 個人スタイル
- 回答は簡潔に。コードの説明は5行以内
- 不明点があれば実装前に確認を求めること
- デバッグ時はまず仮説を提示してから調査すること

# 言語・環境
- 基本的にTypeScriptを優先
- パッケージマネージャーはnpmではなくpnpmを使用

# 好みのワークフロー
- コード変更後は必ずテストが通ることを確認
- コミットメッセージはConventional Commitsに従う

プロジェクトローカル（非推奨）と@importの活用

以前はCLAUDE.local.mdがプロジェクトレベルの個人設定に使われていましたが、CLAUDE.local.mdは非推奨となっており、代わりにCLAUDE.mdでのインポート機能を使用することが推奨されています。

代替手段として、個人的な設定ファイルをユーザーのホームディレクトリに置き、プロジェクトのCLAUDE.mdからインポートする方法が推奨されています。

# project/CLAUDE.md
See @README for project overview and @package.json for available npm commands.

# 個人固有の設定（Gitにコミットされない）
- @~/.claude/my-project-instructions.md

たとえばAWS環境へアクセスする際にawsumeを普段使っているとします。この場合のプロファイル名は個人の環境の話ですし、プロジェクト全体でリポジトリにコミットしにくいです。このような個人固有の情報をインポートで管理できます。

メモリの追加・編集・確認：3つの操作方法

①「#」ショートカット：最速でメモリを追加

メモリを追加する最速の方法は、入力を「#」文字で開始することです。このメモリを保存するメモリファイルを選択するよう求められます。

例えば、セッション中に「これは覚えさせておきたい」と思ったら：

# このプロジェクトではpnpmを使用。npmは使わないこと

と入力するだけで、保存先を選ぶダイアログが表示されます。日常の開発中にリアルタイムでメモリを育てていく感覚で使えます。

②「/memory」コマンド：体系的に編集・確認する

セッション中に「/memory」スラッシュコマンドを使用して、システムエディタでメモリファイルを開き、より広範な追加または整理を行います。

このコマンドを使うと： - 現在読み込まれているメモリファイルの一覧を確認できる - Auto memoryのオン/オフを切り替えられる - ファイルセレクタから直接編集できる

③「/init」コマンド：プロジェクトのCLAUDE.mdをゼロから作成

新しいプロジェクトに参加したときや、初めてClaude Codeを導入するときは、/initコマンドが便利です。コードベースを自動解析してCLAUDE.mdの雛形を生成してくれます。

> /init

これを実行するだけで、プロジェクト構造に基づいたCLAUDE.mdの初期版が作成されます。その後、自分たちのプロジェクト固有の情報を追記していけばOKです。

@importで実現する高度なメモリ管理術

ファイルをモジュール化してメンテナンス性を向上

CLAUDE.mdファイルは「@path/to/import」構文を使用して追加ファイルをインポートできます。

この機能を活用することで、一つの巨大なCLAUDE.mdを避けてルールを分割管理できます。たとえば、以下のようなディレクトリ構成が考えられます：

shared-rules/
├── nextjs-rules.md     # Next.js開発規約
├── security.md         # セキュリティプラクティス
├── git-workflow.md     # Gitフロー
└── test-strategy.md    # テスト戦略

projects/
├── project-a/
│   └── CLAUDE.md       # @importで必要なルールを読み込む
└── project-b/
    └── CLAUDE.md

project-a/CLAUDE.mdの内容：

# SaaSプロジェクト固有設定

## 共通ルールの読み込み
@import ../../shared-rules/nextjs-rules.md
@import ../../shared-rules/security.md
@import ../../shared-rules/git-workflow.md

## このプロジェクト固有の設定
- API認証: JWT
- デプロイ先: Vercel
- DB: PostgreSQL + Prisma

巨大なCLAUDE.mdを避けられることでルールを分割して管理でき、見通しが良くなります。またコンテキストの効率的な活用として、必要なファイルに対してだけルールを適用できます。

インポートされたファイルは追加ファイルを再帰的にインポートでき、最大深度は5ホップです。ただし、潜在的な衝突を避けるために、インポートはマークダウンコードスパンおよびコードブロック内では評価されません。

Claudeのメモリ検索の仕組みを理解する

Claude Codeはメモリを再帰的に読み込みます。現在の作業ディレクトリから開始して、Claude Codeはルートディレクトリまで再帰し、見つかったCLAUDE.mdファイルを読み込みます。

また、Claudeは現在の作業ディレクトリの下のサブツリーにネストされたCLAUDE.mdも検出します。起動時に読み込まれるのではなく、Claudeがそれらのサブツリー内のファイルを読み込むときにのみ含まれます。

大規模なモノリポ（一つのリポジトリで複数サービスを管理する構成）では特に有効で、サービスごとにCLAUDE.mdを分けて設置することで、Claudeが適切なコンテキストだけを参照できます。

競合ツールとの比較：GitHub Copilot・Cursor・Gemini CLIとどう違う？

AIコーディングツールのメモリ・コンテキスト管理機能を比較します。

機能	Claude Code	GitHub Copilot	Cursor	Gemini CLI
設定ファイル名	CLAUDE.md	.github/copilot-instructions.md	.cursorrules / .cursor/rules/	GEMINI.md
階層構造	4階層（Enterprise/Project/User/Local）	3階層（Organization/Repo/Personal）	2〜3階層	2〜3階層
組織管理	✅（Enterprise Policy）	✅（Organization Policies）	△（限定的）	△
ファイルインポート	✅（@import構文、5段階）	❌	△（一部対応）	未確認
自動メモリ生成	✅（Auto memory機能）	❌	❌	❌
コマンド操作	✅（#ショートカット、/memory）	❌	❌	❌
Git管理の可否	✅	✅	✅	✅

特に最近追加されたProject RulesやUser-level Rulesは、CursorのRulesと同じような使い方ができそうです。

Claude Codeの際立った特徴は、組織全体に強制できるEnterpriseポリシーと、@importによるモジュール化、そしてAuto memoryによる自動学習の3点です。チームでの運用やエンタープライズ向けの要件では、Claude Codeのメモリ管理が最も体系的に設計されていると言えるでしょう。

実際の活用事例：こんな使い方でチームの生産性が上がった

事例①：新メンバーのオンボーディングを自動化

新しいエンジニアがチームに加入した際、これまではプロジェクトのルールを口頭や別ドキュメントで伝える必要がありました。

CLAUDE.mdにプロジェクト全体の情報を集約することで、新メンバーがClaude Codeを起動した瞬間から、プロジェクトの文脈を把握したClaudeのサポートを受けられます。「このプロジェクトで使えるコマンドは？」「コーディング規約は？」といった質問に即座に答えられるようになります。

事例②：コードレビューの品質を均一化

CLAUDE.mdに詳細な情報を記述することで、Claude Codeの応答の質と関連性が劇的に向上します。

例えば、CLAUDE.mdにコードレビューの観点を記述しておくと：

## コードレビュー観点
- セキュリティ: 入力値の検証、SQLインジェクション対策
- パフォーマンス: N+1問題、不要なループ
- 可読性: 変数名は意図が明確か、コメントは適切か
- テスト: 境界値、エラーケースはカバーされているか

「このPRをレビューして」と指示するだけで、毎回一定水準のレビューが行われます。

事例③：AWS環境ごとのコマンド自動適用

プロジェクトローカルのメモリを使って、AWSのdev環境へアクセスする際はawsume foo-dev &&、prod環境へアクセスする際はawsume foo-prod &&を付けるよう設定しておくことで、環境ごとの操作ミスを防げます。

個人環境固有の情報なのでGitにはコミットせず、@importで個人設定ファイルから読み込む形にするのがベストプラクティスです。

事例④：テスト駆動開発（TDD）との組み合わせ

Auto memory機能を使ってClaudeにTDDのワークフローを学習させることもできます。

# TDDで開発すること。必ずテストを先に書いてから実装に入ること
# テストが失敗することを確認してから実装を始めること
# テストが通ったらリファクタリングを行うこと（Red-Green-Refactorサイクル）

この設定をユーザーメモリに入れておくことで、どのプロジェクトでも自動的にTDDスタイルのサポートを受けられます。

注意点とデメリット：過信は禁物

注意点①：メモリが多すぎるとコンテキストを圧迫する

Auto memoryはMEMORY.mdの最初の200行のみを読み込みます。また、CLAUDE.mdが巨大になるとコンテキストウィンドウを圧迫し、かえって応答品質が下がる可能性があります。定期的に見直し、不要な記述を削除することが重要です。

注意点②：優先順位の理解が必要

優先順位はEnterprise > Project Memory = Project Rules > User Memory = User-level Rules > Localとなっています。重要なポイントとして、下位にあるメモリは基本的に上位を打ち消すことができません。ただし、競合しない内容に関しては「いい感じに」マージされます。

複数の設定が競合した場合、どのルールが実際に適用されているか分かりにくくなることがあります。/memoryコマンドで現在のメモリ状態を定期的に確認する習慣をつけましょう。

注意点③：機密情報の管理に注意

CLAUDE.mdをGitでチーム共有する場合、個人のアクセストークンやAPIキー、環境固有の認証情報を絶対に記述しないことが鉄則です。これらは@importで参照する個人設定ファイルに分離し、.gitignoreに追加してください。

注意点④：設定が分散して管理が複雑になる

6種類もあると、どこに何を書いたか忘れがちです。また、新規ファイル作成時の挙動が不安定で、pathsを指定したルールが適用されないケースがあります。デバッグが難しく、どのメモリが優先されているのか実際に試さないとわからないこともあります。

これを防ぐためには、チーム内で「どこに何を書くか」の運用ルールを事前に決めておくことが重要です。

ベストプラクティス：明日から使える実践ルール

メモリのベストプラクティスをまとめると、まず「具体的にする」こと（「コードを適切にフォーマットする」よりも「2スペースのインデントを使用する」の方が良い）、次に「構造を使って整理する」こと（各個別のメモリを箇条書きとしてフォーマットし、関連するメモリを説明的なマークダウン見出しの下にグループ化する）、そして「定期的に確認する」こと（プロジェクトが進化するにつれてメモリを更新して、Claudeが常に最新の情報とコンテキストを使用していることを確認する）の3点です。

これらを踏まえた実践的なステップをまとめます：

Step 1：まずユーザーメモリを整備する（今日できること） ~/.claude/CLAUDE.mdに、自分の開発スタイルや好みを記述する。インデント、言語設定、回答スタイルなど。

Step 2：プロジェクトに/initを実行する（チームへの展開） 新規プロジェクトや既存プロジェクトで/initを実行し、CLAUDE.mdの雛形を作成。その後チームで内容を充実させてGitにコミット。

Step 3：共有ルールをモジュール化する（中級者向け） 複数プロジェクトで共通するルール（Git運用、セキュリティプラクティスなど）は別ファイルに切り出し、@importで参照する形に整理。

Step 4：エンタープライズポリシーを導入する（管理職向け） 組織全体で守らせたいルールはEnterpriseメモリに集約し、MDMやAnsibleで全開発者マシンに配布する。