Claude Codeの横断メモリ設定3層（2026）

「別のリポジトリで同じ指示を何度も入力する」「前回の判断をClaude Codeが引き継がない」という状態なら、設定を一つの巨大なメモリにまとめる方法は適していません。

最も安定する構成は、CLAUDE.mdに安定した事実、Claude Code Skillsに必要な手順、外部のAgent Memoryに変化する履歴や好みを分けて保存する三層方式です。 すべての会話履歴を全体向けのプロンプトへ連結するのではなく、情報の寿命と共有範囲で配置を決めます。

対象は、複数リポジトリを保守する個人開発者、共通の開発手順を整えたいチーム責任者、そして長時間稼働するコーディングエージェントの永続化・隔離・バックアップを設計するチームです。

注意: 設定ファイルが新しいセッションで読み込まれることと、モデルが過去の会話を永久に記憶していることは別です。公式に確認できる設定の読み込みと、外部コンポーネントによる永続化を混同しないでください。

最終更新日：2026年8月10日。設定の配置、Skillsの動作、メモリ読み込みの仕様は公式ドキュメントで確認しています。

まず情報の寿命と共有範囲を分ける

最初に「何を覚えさせたいか」ではなく、「その情報はいつまで有効で、誰が使うか」を決めます。プロジェクトのアーキテクチャやテストコマンドは比較的安定していますが、直近の障害対応、個人の好み、作業中のIssue番号は変化します。

保存先	主な内容	共有範囲	読み込みの考え方	向いていない情報
CLAUDE.md	構成、規約、確認コマンド	プロジェクト単位	セッション開始時の基本ルール	会話履歴、秘密情報
SKILL.md	デプロイ、レビュー、テスト手順	個人、プロジェクト、組織	必要な場面で読み込む	常時必要な基本事実
外部Agent Memory	判断履歴、個人設定、未完了タスク	ユーザー・プロジェクト単位	検索やAPIで必要な記録だけ取得	無制限のコード全文

Claude Codeの公式メモリ機能では、プロジェクト内のCLAUDE.mdだけでなく、ユーザー領域の設定も扱えます。現在の作業ディレクトリから親方向へ探索し、読み込まれたファイルは/memoryで確認できます。インポートの最大深度は5段階です。詳しくは公式のメモリ管理ドキュメントを参照してください。 (docs.anthropic.com)

共有対象から外すべきものも先に一覧化します。APIキー、SSH秘密鍵、顧客名や顧客データ、非公開リポジトリの固有事情、個人の認証情報は、全プロジェクト向けのファイルや外部メモリへ保存しない方が安全です。必要な場合も、実値ではなく環境変数名、仮の識別子、参照先だけを記録します。

単一プロジェクトのCLAUDE.mdを整える

最初の実装は、リポジトリごとのCLAUDE.mdです。ここには「このプロジェクトで常に守る事実」だけを書きます。

# sample-dashboard

## 構成
- `apps/web` が画面、`packages/api` がAPI
- データベースの変更は `db/migrations` に保存

## 確認コマンド
- `npm run lint`
- `npm test`
- `npm run build`

## 制約
- APIレスポンスの公開形式を変更する場合はテストを追加
- 本番用の環境変数をファイルへ書き込まない

このファイルへデプロイの全手順や長い設計資料まで詰め込むと、常時読み込まれる情報が増え、重要なルールが埋もれます。公式ドキュメントも、CLAUDE.mdはプロジェクトの指示、規約、頻繁に使うコマンドを置く場所として説明しています。設定を作成したら新しいセッションを起動し、/memoryで対象ファイルが読み込まれているか確認してください。 (docs.anthropic.com)

CLAUDE.mdとSkillsの分担はどう決めるべきでしょうか。
「常に守る事実」はCLAUDE.md、「依頼されたときに実行する作業」はSKILL.mdへ置きます。たとえば命名規則は前者、リリース前にテスト・ビルド・差分確認を行う手順は後者です。

個人だけの好みをチーム共有ファイルへ混ぜないことも重要です。個人設定を共有したい場合は、専用ファイルをインポートする構成にし、リポジトリへコミットする規則と個人用設定を分離します。

繰り返す手順をClaude Code Skillsへ移す

次に、何度も貼り付けている操作手順をSkillsへ移します。SkillsはSKILL.mdを入口とするディレクトリで、関連する場面で自動読み込みさせることも、スラッシュコマンドから明示的に呼び出すこともできます。本文は使用時に読み込まれるため、長い手順を常時コンテキストへ入れずに済みます。 (docs.anthropic.com)

例として、架空のプロジェクトでレビュー用Skillを作成します。

.claude/
└── skills/
    └── review-change/
        └── SKILL.md

---
name: review-change
description: 差分のレビュー依頼、リリース前確認、変更点の安全性確認で使用する
disable-model-invocation: true
---

1. git diffを確認する
2. 関連テストを実行する
3. 破壊的変更、秘密情報、未検証の入力を確認する
4. 問題を重大度順に報告する

個人用Skillsは~/.claude/skills/、プロジェクト用は.claude/skills/、プラグイン用はプラグイン配下に置けます。公式仕様では、同名の場合に組織、個人、プロジェクトの順で優先関係があり、プロジェクト固有の手順で上書きしたい場合は名前の衝突を意識して設計する必要があります。 (docs.anthropic.com)

ただし、チームで共有するデプロイSkillへ個人の本番接続先や秘密の引数を直接書くのは避けます。接続先は環境変数や承認済みの設定から取得し、Skill本文には実行順序、確認条件、失敗時の停止条件だけを記述します。

外部Agent Memoryを最後に接続する

三層目は、プロジェクトをまたいで変化する情報です。たとえば「レビューでは先に互換性を確認する」「前回は認証部分を変更せず保留した」「次回はIssueの設計案から再開する」といった記録は、CLAUDE.mdへ固定するより外部Agent Memoryへ保存する方が管理しやすい場合があります。

ここでいう外部Agent Memoryは、Claude Codeに永久記憶が内蔵されているという意味ではありません。SDKやMCPなどを使って、別の保存層から必要な記録を取得し、現在のセッションへ渡す設計です。公式のSDKはプログラムからClaude Codeを実行する仕組みを提供し、MCPは外部ツールやデータソースとの接続に使えます。 (docs.anthropic.com)

最低限、次の項目を持たせます。

• project_id：リポジトリ名だけに依存しない固定識別子
• user_id：個人設定とチーム共有記録を分離する識別子
• memory_type：好み、判断履歴、未完了タスクなどの分類
• source：どのIssue、PR、セッションから得た記録か
• created_at と updated_at：古い判断を見分ける日時
• delete_at または削除処理：不要な記録を消す仕組み

複数プロジェクトで設定を共有しながら、コード情報の漏えいを防ぐにはどうすればよいでしょうか。
共有するのはルールと手順に限定し、コード断片や顧客情報はプロジェクト識別子の境界内に閉じ込めます。検索結果を別プロジェクトへ返さないフィルター、ユーザー単位の権限確認、保存前の秘密情報検査、記録の出典表示を必須にしてください。

再起動と更新を固定タスクで検証する

最後に、設定が存在するだけでなく、再現可能に動くかを確認します。Claude CodeのSkillsは、既存ディレクトリ内の変更をセッション中に検知できますが、セッション開始時に存在しなかったトップレベルのSkillsディレクトリは再起動が必要です。公式ドキュメントにも、変更検知と再起動が必要になる条件が記載されています。 (docs.anthropic.com)

次の順で検証すると、設定ファイルの再読み込みと動的記憶を区別できます。

• [ ] 新しい空のセッションで/memoryを実行し、対象のCLAUDE.mdを確認する
• [ ] プロジェクトAでのみ有効なルールが、プロジェクトBに現れないことを確認する
• [ ] Skillの説明に一致する依頼と、一致しない依頼をそれぞれ実行する
• [ ] SKILL.mdを変更し、再起動なしで反映される範囲を確認する
• [ ] 外部Agent Memoryを停止して、設定ファイルだけでも作業できることを確認する
• [ ] 再起動後に同じ固定タスクを実行し、動的記憶が正しいプロジェクトだけから復元されるか確認する
• [ ] Claude Codeや記憶コンポーネントの更新前に設定をバックアップする

Claude Codeは以前のプロジェクトを自動的に覚えているのでしょうか。
プロジェクトのCLAUDE.mdや設定されたSkillsは、仕様に基づいて読み込まれます。しかし、別のリポジトリで過去の会話や判断履歴まで自動的に永久保存されるわけではありません。会話を再開する場合はセッション再開機能、継続的な履歴検索が必要な場合は、隔離条件を備えた外部Agent Memoryを別途設計します。

三層構成の導入判断

まだ一つのリポジトリしか扱わず、記録したいのが構成とコマンドだけなら、まずCLAUDE.mdだけで十分です。複数プロジェクトで同じレビューやデプロイ手順を使う段階になったらSkillsを追加し、判断履歴や未完了タスクを再起動後も引き継ぐ必要が出た時点で外部Agent Memoryを導入します。

自前のノートやローカル環境だけで運用する方法は、短期の個人開発では手軽です。一方で、端末停止時の復旧、複数人の権限分離、プロジェクトごとのデータ隔離、更新後の回帰確認が弱くなりやすく、長時間稼働するAgent環境では運用負担が増えます。継続稼働やチーム共用が目的なら、設定をバックアップでき、プロジェクト単位で環境を分けられる遠隔開発環境を検討する価値があります。

一時的な検証環境や複数リポジトリの切り替えが必要な場合は、ZutcloudのMacレンタル環境を使い、設定ファイルと動的記憶の復旧手順を分けて検証できます。運用条件や接続方法を確認したい場合は、Zutcloudヘルプセンターで事前に要件を確認してください。