Claude Code の会話は30日で消え、compact で要約される。何をどこに残すか
Claude Code で長く作業していると、二つのことで情報が失われます。
- 会話ログが消える：ローカルの会話ログは、既定で30日たつと削除される
- 会話が要約される：会話が長くなってコンテキストがいっぱいに近づくと、自動で compact（要約）される
どちらも、それ自体は困ることではありません。ただ、「前に話したはず」の決めごとが、気づかないうちに消えていることがあります。どこに何を残しておけばよいかを、自分のログと公式ドキュメントで確かめました。
※ 環境は Claude Code 2.1.296 です。
会話ログは30日で消える
Claude Code の会話ログは ~/.claude/projects/<プロジェクト>/<セッション>.jsonl に、平文で保存されます。公式ドキュメントによると、これはセッションを再開（resume）するためのもので、既定では30日 で削除されます。期間は cleanupPeriodDays という設定で変えられます。
実際、私の手元に残っていたのは、ちょうど1か月分のログでした。auto mode の拒否を集計した記事 でも、それより前のデータは数えられていません。
ログを長く残したいなら cleanupPeriodDays を延ばせば済みます。ただ、ログは会話の記録であって、あとから読み返して使う形にはなっていません。次の会話で使いたいことは、ログとは別に残す ほうが確実です。
3割のセッションで compact が起きていた
もう一つが compact です。会話がコンテキストの上限に近づくと、Claude Code はそれまでの会話を要約して、要約から続きを始めます。
手元のログ（198セッション）を数えると、61セッション、約3割で compact が起きていました。記事を何本も続けて書くような長い作業では、ほぼ毎回です。この記事を書いているセッションも、途中で一度 compact されています。
compact のあとも、作業はふつうに続きます。要約には、作業の目的、どこまで進んだか、変更したファイル、未解決のエラーなどが入るからです。それでも、要約である以上、細かいところは落ちます。
compact のあとに残るもの、落ちるもの
公式ドキュメントに、compact のあとにそれぞれがどうなるかの表があります。主なものをまとめます。
| もの | compact のあと |
|---|---|
| プロジェクト直下の CLAUDE.md | ファイルから読み直される |
auto memory（MEMORY.md） | ファイルから読み直される |
| plan mode で書いた計画 | ファイルから読み直される |
| 直前に読んだ・編集したファイル | 新しいものから最大5つ読み直される |
サブディレクトリの CLAUDE.md、paths: 付きのルール | 該当するファイルを触ったときに読み直される |
| 会話の中で伝えたこと | 要約の一部になる |
ポイントは最後の行です。会話で伝えただけのことは、要約に入るかどうかが分かりません。逆に、ファイルに書いてあることはディスクから読み直されるので、compact の影響を受けません。
ドキュメントには、具体的な注意も書かれています。
- 「compact のあとに指示が消えた」なら、その指示は会話でしか伝えていなかったか、まだ読み直されていないサブディレクトリの CLAUDE.md にある
- auto mode で「レビューするまで push しないで」のように会話で伝えた制限も、compact でその発言が消えると効かなくなることがある。確実にしたいなら、
permissions.denyなどのルールにする
手動で compact するのは、やめた
自動の compact に任せず、自分のタイミングで /compact を実行する方法もあります。私も一時期、X の記事 を参考にして、手動で compact していました。ただ、いまはやめています。やってみて感じたメリットとデメリットはこうです。
メリット
- ちょうどよいタイミングで引き継ぎ資料を作れる。区切りのよいところで「ここまでの経緯と次にやること」をまとめさせてから compact できるので、自動の compact より、残る内容を自分で選べる
デメリット
- コンテキストが大きくなり、手動で compact する恩恵が減った。いまは 100万トークンのコンテキストを使えるモデルもあり、compact が必要になるところまで会話が伸びること自体が減った
- 引き継ぎ資料より、コードを読ませたほうが正確。モデルの性能が上がり、Claude は必要になったらコードや git の履歴を自分で読みに行く。要約した引き継ぎ資料より、一次資料であるコードのほうが確かで、資料が古くなる心配もない
- そもそも compact しない進め方のほうが、自分の開発に合っていた。大きな作業は先に分割しておき、個別の実装タスクごとに
/clearして新しい会話で始める。1つの会話が長くならないので、compact をどう制御するかを考えなくてよくなった
いまは、compact をどう制御するかではなく、次の2つを大事にしています。
- 1つのスレッドで扱う話を1つに収める。話題が変わったら、新しい会話（
/clear）で始める。関係のない話が積み重ならなければ、要約で何が落ちても困りにくい - 覚えておいてほしいことは、その場で文章にまとめておく。会話の流れに頼らず、CLAUDE.md・memory・リポジトリのドキュメントに、適切な粒度で書いておく
ファイルに書いてあることは compact のあとも読み直されるので、compact のタイミングを気にする必要がなくなります。compact は自動に任せて、残したいものは先にファイルにしておく、という分担です。
何をどこに残すか
「適切な粒度で文章にまとめる」の中身を、置き場所ごとに整理しました。
| 残したいもの | 置き場所 | 理由 |
|---|---|---|
| 毎回守ってほしいルール（言語・口調・禁止事項・コマンドの決まり） | CLAUDE.md | 毎回読み込まれ、compact のあとも読み直される |
| 作業の中で分かった落とし穴、指摘された直し方 | auto memory | Claude が自分で書き、次の会話から読み込まれる |
| タスク・進捗・期限 | リポジトリのファイル（TODO.md など） | git で履歴が残り、人も読める |
| 「絶対にやってほしくないこと」 | permissions.deny やフック | 会話やメモではなく、仕組みで止める |
CLAUDE.md：ルールを書く
CLAUDE.md は自分で書く指示書です。毎回の会話の最初に読み込まれ、compact のあとも読み直されます。私のグローバル CLAUDE.md には、「応答は日本語で」「ユーザーに実行させるコマンドは1行で」「ヒアドキュメントを使わない」といったルールを書いています（設定ツアー参照）。
compact に関する指示も書いてあります。
## Compact
保持優先：現タスク目的・進捗、変更内容・理由、未解決エラー。ただし、これがどこまで要約に効いているかは確かめていません。要約の中身を指定したいなら、/compact 認証まわりの修正を中心に のように、/compact に指示を付けて自分で実行する方法もドキュメントに載っています。
auto memory：分かったことを Claude に書かせる
auto memory は、Claude が自分で書くメモです。~/.claude/projects/<プロジェクト>/memory/ に、1件1ファイルの Markdown と、目次の MEMORY.md が置かれます。
公式ドキュメントによると、仕組みは次のとおりです。
MEMORY.mdの 先頭200行（または25KB） が、毎回の会話の最初に読み込まれる- 個別のファイルは、必要になったときに Claude が読む
- 30日の削除の対象外。自分か Claude が消すまで残る
手元で数えると、23プロジェクトに計134件のメモがありました。種類の内訳は次のとおりです。
| 種類 | 件数 | 例 |
|---|---|---|
| project（プロジェクトの事情） | 85 | 「dev サーバーを動かしたまま build を繰り返すと、新しい記事が404になる」 |
| feedback（指摘された直し方） | 38 | 「AI レビューの指摘は、複数が一致していても、ビルドして確かめてから適用する」 |
| user（自分について） | 6 | 役割や好み |
| reference（外部の場所） | 5 | ダッシュボードの URL など |
役に立っているのは、理由と一緒に残したメモ です。たとえば「新しい記事を dev で見せる前に curl で200を確認する」というメモには、「下書きの確認を頼まれたときに404を見せてしまった」という経緯が付いています。理由があると、似ているけれど少し違う場面でも、当てはまるかを判断できます。
一方で、memory は Claude が判断して書く ものなので、何が残るかは任せきりになります。どうしても次に引き継ぎたいことは、「これを memory に残して」と頼むか、自分で CLAUDE.md に書きます。
リポジトリのファイル：タスクと進捗を書く
タスクの一覧、進捗、期限のような「状態」は、リポジトリのファイルに書いています。このサイトなら、収益化と SEO のタスクは TODO.md、記事のネタ帳は CONTENT_PLAN.md です。
memory にも書けますが、リポジトリに置くと git で履歴が残ります。自分でも読みやすく、別の PC や別のツールからも使えます。記事を書き終えたら、Claude にネタ帳の該当行を「公開済み」に直してもらっています。
ルールでも足りないもの：仕組みで止める
CLAUDE.md も memory も、Claude にとっては「文脈」です。公式ドキュメントにも、強制される設定ではない とはっきり書かれています。「main に force push しない」のように、絶対に起きてほしくないことは、permissions.deny やフック（危険な git 操作をフックで止める）で止めます。
まとめ
- 会話ログは既定で 30日で削除 される（
cleanupPeriodDaysで変更できる）。次に使いたいことはログとは別に残す - 長い作業では compact がよく起きる。手元では 約3割のセッション で起きていた
- compact のあと、CLAUDE.md と auto memory はファイルから読み直される。会話で伝えただけのことは要約に頼ることになる
- 手動の compact は、引き継ぎ資料を作るタイミングを選べるのが利点。ただ、コンテキストが大きくなったこと、コードを読ませたほうが正確なことから、やめた。かわりに 作業を分割して1スレッド1つの話 にし、覚えておいてほしいことは文章にまとめておく
- ルールは CLAUDE.md、分かったことは auto memory、タスクと進捗はリポジトリのファイル、絶対に止めたいことは deny ルールやフック
- memory は理由と一緒に残すと、似た場面でも使える
compact をうまく制御するより、compact されても困らない状態にしておくほうが楽でした。会話で何度も同じことを伝えていると気づいたら、それはファイルに書くべきことです。「前にも言ったよね」と思ったら、CLAUDE.md か memory に書き足すようにしています。
この記事をシェア