← トップに戻る
この構成は一例。パスや命名は自分の環境に合わせて読み替えること。
2026.07.09 | 対象: Claude Code のセッション履歴・メモリ運用

Claude Code のセッション履歴・メモリは、
どこに・いつ・どう保存するか

Claude Codeが自動で書く生ログと、アシスタントが手動で書く要約メモリは別物であり、扱いも別になる。このページはその2層を分けたうえで、保存場所・保存のタイミング・.gitignoreの設定・CLAUDE.mdに追記する文面までを実例つきでまとめたものである。人間だけでなく、別の環境で動くClaude Codeがこのページを読み込んで、同じ構成を自分の環境に再現することも想定している。
保存の層
2
層A=生ログ(自動)/層B=要約(手動)
生ログの実測サイズ
222MB
ある環境で75セッション分の生ログを合計した値
保存のトリガー
3種類
セッション開始時/作業の区切り/会話終了前
記録要否の判定基準
5
設定変更・判明事実・方針・新ツール・トラブル結論
01

全体像は2層に分かれる

Claude Codeが書くものと、アシスタントが書くものは、書き手も同期の扱いも別になる。まずこの2層を分けて把握する。

層A: 生ログ(自動保存)

Claude Codeが自動で書く。保存先は ~/.claude/projects/<cwdエンコード名>/<セッションUUID>.jsonl。そのセッションの全発言とツール呼び出しがそのまま入る。容量が大きく、機密が混じることもあるため、git同期の対象からは外す。

層B: 要約(手動保存)

アシスタントが書く。MEMORY.md/LOG.md/WORK_QUEUE.md/daily/ の各ファイルがこれにあたる。会話の全部ではなく、次のセッションに引き継ぐべき要点だけを人が読める形にまとめたもので、git同期の対象に入れる。

役割の違い: 引き継がれるのは層Bだけ

層Aは復元・検索用でローカル限定であり、同じPC・同じセッションUUIDでしか実質的に読み返さない。別PC・別セッション・別モデルに引き継がれるのは層Bのみである。層Aに書いたつもりでも、層Bに転記していない情報は次のセッションから見えない。参考値として、ある環境では75セッション分の生ログが合計222MBに達した記録があり、これが層Aをgit同期から外している理由になっている。

02

ディレクトリ構造

~/.claude/ を起点にしたツリー。<cwdエンコード名> は、作業ディレクトリのパスの区切り /- に置換したもの(例: /Users/name-Users-name)。
~/.claude/
├── CLAUDE.md                        # 人格・運用ルールの正本
├── WORK_QUEUE.md                    # 進行中タスクのキュー
├── .gitignore                       # 生ログ・機密を除外する定義(詳細はセクション06)
├── daily/
│   └── YYYY-MM-DD.md                # 日次メモ
├── docs/
│   └── *.md                         # 運用手順書(同期フロー・命名規則など)
├── skills/
│   └── <skill-name>/SKILL.md        # 固定手順のスキル定義
└── projects/
    └── <cwdエンコード名>/           # 作業ディレクトリごとに1フォルダ
        ├── <セッションUUID>.jsonl   # 層A: 会話の生ログ(自動・git対象外)
        └── memory/
            ├── MEMORY.md             # 層B: メモリの索引(1行1メモリ)
            ├── core/
            │   └── feedback_*.md     # ユーザーの好み・作業方針
            ├── reference/
            │   └── reference_*.md    # 外部サービス・ツールの情報
            ├── projects/
            │   └── <name>/
            │       ├── RULES.md       # そのプロジェクトの運用正本
            │       ├── LOG.md         # 時系列の作業記録
            │       └── PROJECT.md     # プロジェクト概要
            ├── decisions/
            │   └── NNNN-*.md         # 意思決定の記録(ADR)
            └── _archive/              # クローズ済み案件の退避先
03

ファイルの役割

同じ「メモリ」でも、書き手とgit同期の有無でファイルの性格が分かれる。
ファイル誰が書くかgit同期役割
<uuid>.jsonl自動されない会話の生ログ
MEMORY.md手動される索引のみ。1行1メモリ。本文は書かない
core/feedback_*.md手動されるユーザーの好み・作業方針
reference/reference_*.md手動される外部サービス・ツールの情報
projects/{name}/LOG.md手動される時系列の作業記録
projects/{name}/RULES.md手動されるそのプロジェクトの運用正本
decisions/NNNN-*.md手動される意思決定の記録(ADR)
WORK_QUEUE.md手動される進行中タスクのキュー
daily/YYYY-MM-DD.md手動される日次メモ
04

保存のタイミング(3つのトリガー)

層Bは自動では書かれないため、いつ書くかを固定しておく。3つのタイミングそれぞれで、読む順序・書く順序も決めておく。
T1 セッション開始時

直近の状態を読んでから着手する

git pullWORK_QUEUE.md → 該当 projects/{name}/{RULES,LOG}.mdMEMORY.md の順に読む。この順で読むと、まず自分がやるべきことが分かり、次に個別プロジェクトの正本と経緯が分かり、最後に全体の索引で漏れを確認できる。

T2 作業が一区切りついたとき

その場で層Bを更新してから次に進む

LOG.md 追記 → WORK_QUEUE.md 更新 → メモリ更新 → git add -A && git commit -m "sync: …" && git push。区切りごとに行うことで、セッションが長くなっても引き継ぎ内容が最新のまま保たれる。

T3 会話が終わる前

5基準に該当する情報がないか最終確認する

セクション05の5基準に該当する情報が会話中に出ていれば、会話が終わる前に必ずメモリへ保存する。ここを飛ばすと、その会話でしか分からなかった判断や結論が次のセッションから失われる。

05

メモリに保存する5基準と保存先

「これが出たら必ず書く」という基準を先に固定しておくと、書くかどうかの判断に迷わなくなる。
#これが出たら必ず書く
1設定変更(settings.json・CLAUDE.md・環境変数など)
2調査して判明した事実や根本原因
3ユーザーが示した方針・判断(「これは深追いしない」等)
4新しく導入したツール・サービス・API
5トラブルシューティングの結論(原因と解決策)
内容保存先
ユーザーの好み・方針feedback_*.md
外部サービス・ツールの情報reference_*.md
進行中の状況project_*.md
ユーザー自身のことuser_*.md

新規作成より更新を優先する

既存のメモリファイルに追記できる内容であれば、新規ファイルを作らずそちらに追記する。ファイルが増えすぎると、次に読むときにどれを読めばよいか分からなくなる。

06

.gitignore(コピペ用)

生ログと機密ファイルを除外する最小セット。生ログは容量が大きいうえに会話の中身がそのまま入っており機密が混じりうるため、同期の対象にしない。
# 会話の生ログ(層A)。容量が大きく機密が混じるため同期しない
**/*.jsonl
**/subagents/
**/tool-results/

# セッション・キャッシュ(巨大なため同期しない)
sessions/
cache/
history.jsonl
shell-snapshots/

# PC固有設定・認証情報(他PCに持ち込まない)
settings.json
settings.local.json
.credentials.json

# セッション内の一時データ(引き継ぎ不要)
todos/
plans/
07

CLAUDE.md に貼るルール文(コピペ用)

そのまま ~/.claude/CLAUDE.md に貼れる形。個人名・固有の案件名を含まない一般化した表現にしてある。
## セッション引き継ぎ(必須)
会話中に以下が発生したら、会話が終わる前に必ずメモリに保存する:
- 設定変更(settings.json、CLAUDE.md、環境変数など)
- 調査して判明した事実や根本原因
- ユーザーが示した方針・判断(「これは深追いしない」「こちらを優先」など)
- 新しく導入したツール・サービス・API
- トラブルシューティングの結論(何が原因で、何で解決したか)

保存先の判断基準:
- ユーザーの好み・方針 → `feedback_*.md`
- 外部サービス・ツールの情報 → `reference_*.md`
- 進行中の状況 → `project_*.md`
- ユーザー自身について知ったこと → `user_*.md`

既存メモリに追記できるなら新規作成より更新を優先する。

## PC間同期
`~/.claude/` はgit管理のリポジトリとして同期する。

- セッション開始時: `git pull` → `WORK_QUEUE.md` → 該当 `projects/{name}/{RULES,LOG}.md` → `MEMORY.md` を読む
- 作業区切り: 該当 `projects/{name}/LOG.md` 追記 → `WORK_QUEUE.md` 更新 → メモリ更新 → `git add -A && git commit -m "sync: …" && git push`
- 書き出し前: メモリ・コミットメッセージはタイポを1ステップ自己確認してから保存
08

セットアップ手順(コピペ用)

ディレクトリを作り、.gitignoreを置き、リポジトリとして初期化するまでの一連の流れ。
# 作業ディレクトリのパスを cwdエンコード名 に変換して1フォルダ作る
CWD_ENC=$(pwd | sed 's/\//-/g')
mkdir -p ~/.claude/projects/$CWD_ENC/memory/{core,reference,projects,decisions,_archive}

# 日次メモ・運用手順書の置き場
mkdir -p ~/.claude/daily ~/.claude/docs

# リポジトリ化
cd ~/.claude
git init

# .gitignore はセクション06の内容で作成してからコミット
git add -A
git commit -m "init: セッション履歴・メモリ運用の初期構成"

# 任意: GitHub privateリポと接続して同期する場合
gh repo create <repo-name> --private --source=. --push
09

この仕組みが壊れるポイント

運用を続けると、以下の3点で崩れやすい。

層Bは手動なので、書き忘れる

層Bはアシスタントが手動で書く前提であり、書かなければ何も残らない。締め処理を固定手順のスキルとして持ち、毎回同じ順で走らせるようにすると、書き忘れによる引き継ぎ漏れが減る。

層Aはgit同期されないため、別PCから参照できない

生ログはローカルにしか残らない。別PCや別セッションでの引き継ぎに必要な情報は、その場で層Bに転記しておかないと、後から取り出せなくなる。

MEMORY.mdに本文を書き始めると、索引が肥大して読まれなくなる

MEMORY.mdは索引であり、1メモリにつき1ファイル・MEMORY.md側は1行リンクのみに保つ。ここに本文を書き足していくと、次第に全体が長くなり、セッション開始時に読まれる前提が崩れる。

10

このページを読んだ Claude Code への指示

別環境でこの構成を再現する場合の手順。
この仕様を自分の環境に再現するには、
(1) セクション08のbashでディレクトリを作る
(2) セクション06の.gitignoreを置く
(3) セクション07の文面を ~/.claude/CLAUDE.md に追記する
(4) 以降、T1/T2/T3のタイミングで層B(MEMORY.md・LOG.md・WORK_QUEUE.md・daily/)を更新する

生ログ(層A)はClaude Codeが自動で書くため、何もしなくてよい。