Claude Codeで複数プロジェクトの記憶を管理する方法：CLAUDE.md、Memory、Hooksのチーム運用

Claude Codeを本格的に使い始めると、すぐに問題になるのがプロジェクトごとの記憶です。あるリポジトリではpnpmを使い、別のリポジトリではPoetryを使う。あるプロジェクトでは先にテストを書き、別のプロジェクトでは先にドキュメントを直す。こうした違いを混ぜると、AIコーディングは一気に不安定になります。

解決策は、すべてのルールを巨大なプロンプトに詰め込むことではありません。CLAUDE.md、Memory、Hooksを役割ごとに分けることです。

複数プロジェクトで記憶が乱れる理由

実際のチームには、フロントエンド、バックエンド、運用スクリプト、ドキュメントなど複数のリポジトリがあります。技術スタックもテストコマンドも違います。口頭の約束だけでは、毎回同じ説明を繰り返すことになります。

目標はClaude Codeに何でも覚えさせることではなく、正しい場所に正しい情報を置くことです。

3層の記憶モデル

層	向いている内容	向いていない内容
`CLAUDE.md`	現在のリポジトリのビルド、テスト、ディレクトリ、禁止事項	個人設定、一時タスク、他プロジェクトの情報
Memory	チーム共通の長期的な好みや協業ルール	特定リポジトリのパスやコマンド
Hooks	フォーマット、テスト、秘密情報チェックなどの自動化	人間が判断すべきプロダクト判断

CLAUDE.mdは「このプロジェクトのやり方」、Memoryは「このチームの協業スタイル」、Hooksは「毎回自動で確認すべきこと」を担当します。

CLAUDE.mdはプロジェクトごとの作業マニュアル

CLAUDE.mdはリポジトリのルートに置き、具体的で安定した内容だけを書きます。READMEの代替ではなく、AIコーディングエージェント向けの作業手順書です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


# Project Guide

## Tech Stack

- Runtime: Node.js 22
- Package manager: pnpm
- Framework: Next.js
- Tests: Vitest and Playwright

## Common Commands

- Install dependencies: `pnpm install`
- Run dev server: `pnpm dev`
- Run unit tests: `pnpm test`
- Run lint: `pnpm lint`
- Run e2e tests: `pnpm test:e2e`

## Working Rules

- Before editing shared UI components, inspect existing usage first.
- Prefer existing helpers in `src/lib` before adding new utilities.
- Do not change database migrations unless the task explicitly asks for it.
- Keep unrelated refactors out of feature fixes.

## Verification

- For UI changes, run `pnpm lint` and the nearest relevant test.
- For API changes, add or update request-level tests.
- For database changes, include migration notes in the final summary.

固定コマンド、特殊なディレクトリ、触ってはいけないファイルがあるなら、ここに書きます。

CLAUDE.mdをゴミ箱にしない

便利だからといって何でも追記すると、重要なルールが埋もれます。古いコマンド、長すぎる背景説明、一時タスク、同じ意味の繰り返しは避けます。あるディレクトリにだけ適用されるルールは、範囲を明示します。

Memoryはプロジェクト横断の好みを保存する

Memoryには、リポジトリをまたいで有効なルールを入れます。たとえば、コミットメッセージの言語、プロダクション設定変更時の説明、未コミット変更を勝手に戻さないこと、モバイル表示の確認、コードレビューの書き方などです。

一方で、特定リポジトリの起動コマンドやデプロイスクリプトのパスはMemoryではなくプロジェクト内ドキュメントに置くべきです。

Hooksで固定チェックを自動化する

Hooksは、毎回必要な処理に向いています。

編集後のフォーマット。
コミット前の秘密情報チェック。
特定ディレクトリ変更時のテスト実行リマインド。
.envやトークンの誤コミット防止。
作業終了時の変更ファイルと検証結果の要約。

Hooksは明確なチェックを自動化するものであり、プロダクト判断を代替するものではありません。

推奨ディレクトリ構成

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


workspace/
├── app-web/
│   ├── CLAUDE.md
│   └── package.json
├── app-api/
│   ├── CLAUDE.md
│   └── pyproject.toml
├── infra/
│   ├── CLAUDE.md
│   └── deploy.ps1
└── docs/
    └── ai-working-rules.md

各リポジトリに自分用のCLAUDE.mdを置き、チーム共通ルールは文書化し、長期的に安定したものだけMemoryに昇格します。

プロジェクト別の書き方

フロントエンド：

1
2
3
4
5
6


## Frontend Rules

- Use existing components in `src/components` before creating new ones.
- Keep layout stable on mobile and desktop.
- Use `pnpm lint` for quick validation.
- For visual changes, mention what viewport was checked.

バックエンド：

1
2
3
4
5
6


## Backend Rules

- API handlers live in `src/routes`.
- Database migrations must be reviewed manually.
- Do not change authentication middleware without explicit approval.
- Run `pytest tests/api` after endpoint changes.

運用：

1
2
3
4
5
6


## Operations Rules

- Treat deployment scripts as production-sensitive.
- Do not print secrets or tokens in logs.
- Prefer dry-run mode before changing remote state.
- Summarize changed commands before final handoff.

同じテンプレートにそろえる必要はありません。その場所で最も大事な制約がすぐ分かることが重要です。

いつ記憶を更新するか

Claude Codeが同じ間違いを繰り返す、同じルールを何度も説明している、検証フローが変わった、ディレクトリ構造が変わった、古いルールが無効になった。こうした時は更新のタイミングです。

コードレビューでの使い方

コードレビューでは、まず現在のCLAUDE.mdを読み、変更されたディレクトリを確認し、最小限の検証を行い、バグ・回帰・テスト不足を優先して指摘します。最後に短い変更概要を出します。

よくある失敗

すべてをMemoryに入れること、CLAUDE.mdを完全な開発マニュアルにすること、ルールだけ書いて自動化しないこと、古い記憶を掃除しないことです。

導入手順

各リポジトリに短いCLAUDE.mdを追加する。
技術スタック、コマンド、禁止ファイル、検証方法だけを書く。
横断的な好みをMemoryへ移す。
繰り返しチェックをHooksにする。
2週間ごとに古いルールを整理する。

まとめ

Claude Codeで複数プロジェクトを扱うなら、記憶を分けることが重要です。リポジトリの事実はCLAUDE.md、長期的な好みはMemory、繰り返し確認はHooksへ置きます。良い記憶システムは長いものではなく、正しいプロジェクトで正しい行動を助けるものです。