Claude Codeは30日後に履歴を削除：保存する方法

Claude Codeのセッションがどこに保存されるのか、cleanupPeriodDaysを設定する方法、rsync、launchd、cronを使って外部アーカイブを整理する方法。

記事の全文を読む

サービスの使い方については、Ailootのドキュメントをご覧ください。

Claude Codeは本当にセッション履歴を消去するのか？

重要なポイント

はい。Claude Codeを起動するたびに、30日より古いセッションファイルが削除されます。これを担うのは~/.claude/settings.jsonのcleanupPeriodDays設定で、デフォルト値は30です。削除は警告も、同意の確認もなく行われ、ファイルを復元する方法もありません。

2か月前のセッションに戻ろうとClaude Codeを開くと、もうありません。ファイルはディスクから完全に消去されています。これは不具合やまれなバグではなく、デフォルトのクリーンアップ機能の動作です。

クリーンアップを制御する設定はcleanupPeriodDaysです。デフォルト値は30です。Claude Codeを起動するたびに履歴フォルダーをスキャンし、その期間より古いものをすべて削除します。私の~/.claude/settings.jsonにはこの設定がまったくなかったため、デフォルト値が有効になっていて、古いセッションのいくつかはすでに消えていました。

Anthropicのリポジトリにはこの件に関するバグ報告が複数ありますが、どれも修正されていません。

Claude Codeはセッション履歴をどこに保存するのか？

重要なポイント

各セッションの履歴は~/.claude/projects/<project-path>/<session-id>.jsonlに保存されます。フォルダー名はClaude Codeを実行した作業ディレクトリの絶対パスで、スラッシュはハイフンに置き換えられます。.jsonlファイルには会話全体が1行ずつ記録されています。プロンプト、モデルの応答、ツール呼び出し、ファイル編集が含まれます。クリーンアップが削除するのは、まさにこの記録です。

履歴を見つけるのは簡単です。ターミナルを開き、フォルダーの内容を確認してください。

ls ~/.claude/projects/

各サブフォルダーが個別のプロジェクトです。名前にはパスが符号化されています。たとえば、/Users/alex/dev/shopにあるプロジェクトは、-Users-alex-dev-shopというフォルダーになります。その中にセッションファイルがあります。

ls -lt ~/.claude/projects/-Users-alex-dev-shop/
# 3f8a1c2e-....jsonl   ← 1つのセッション = 1ファイル
# a91b7d40-....jsonl

各.jsonlは行ごとのログで、1行が1つのセッションイベントです。会話文だけではありません。特定のデータベース構造を選んだ理由、却下した選択肢、Claudeが間違えた箇所、そしてどう修正したかなど、判断の裏にあるロジックも含まれます。

つまり、これはプロジェクト開発の日誌です。失うと痛いのはそのためです。「チャット」ではなく、何週間もかけて積み上げた文脈を失うことになります。この文脈の構造については、ガイド「Claude MemoryとCLAUDE.mdの違い」で解説しました。

Anthropicはなぜ30日後にトランスクリプトを削除するのか？

重要なポイント

Anthropicの立場は、プライバシーとセキュリティです。セッションファイルはディスク上にプレーンテキストで保存され、ソースコード、パスワード、APIキーが含まれる可能性があります。永久に保管するのはリスクです。ノートパソコンが盗まれたり、誰かがディスクにアクセスしたりすれば、そうした機密情報がすべて漏れるからです。30日という期間は、「最近の作業を再開できること」と「必要以上に長くディスク上に秘密を保管しないこと」のバランスです。

削除には理由があり、すべて無効にする前に理解しておく価値があります。トランスクリプトはプレーンテキストです。セッション中にClaudeが.envファイルを読み込んだり、コマンドにキーを挿入したり、プロンプトにパスワードを貼り付けたりすれば、それらはすべて.jsonlにプレーンテキストで残ります。こうしたファイルがディスクに残る期間が長いほど、いつか漏えいする可能性が高まります。

Anthropicは明確に説明しています。トランスクリプトにはソースコード、認証情報、その他の機密情報が含まれる可能性があり、必要以上に長くディスク上に保管すると、実際のプライバシーリスクが生じます。30日という期間は妥協点として選ばれました。

コミュニティの異議は3点です。削除がひそかに行われること（設定時にも起動時にも警告がない）、同意を求められないこと、復元できないこと（ゴミ箱は使われず、ロールバックもない）です。issue #59248では、開発者たちは1つのことを求めています。クリーンアップを公平にし、警告、復元期間、そしてより緩やかなデフォルト期間を設けることです。

バックアップスクリプト自体が削除を引き起こすことがあるのはなぜ？

重要なポイント

クリーンアップはファイルの更新時刻（mtime）を基準に削除対象を判断します。セッション内で実際に最後に活動した時刻は確認しません。.jsonlファイルに触れるあらゆるプロセス、つまりクラウド同期、rsync、エディター、スクリプトなどがmtimeを変え、新しいセッションを古く見せる可能性があります。次回のClaude Code起動時、そのセッションは古いと判断され、削除されます。皮肉なことに、管理対象フォルダー内で履歴をバックアップしようとする安直な方法が、履歴の消失を早めます。

これは最も厄介な点で、自分でデータを守ろうとする人がつまずきます。クリーンアップが参照するのはmtime、つまりファイルの最終更新時刻です。mtimeがセッションで最後に作業した時刻を示すものと見なしています。実際には、DropboxやiCloudの同期クライアント、rsync、ウイルス対策ソフト、インデクサー、あるいは自分のバックアップスクリプトなど、何でもmtimeを変更できます。

ここに落とし穴があります。履歴を保存しようと考え、~/.claude/projects/のクラウド同期を設定したとします。ある時点で同期サービスがファイルを書き換え、mtimeを過去の日付に設定します（クラウドコピーから復元するときに起こることがあります）。Claude Codeは起動時にファイルを「古い」と判断し、削除します。保存するつもりが、削除を早めてしまったのです。

結論は1つです。バックアップは~/.claude/projects/の外に置かなければなりません。クリーンアップが動作するのはこのフォルダー内だけです。外部に保存したコピーにはクリーンアップが届きません。この原則を中心に解決策を組み立てます。

履歴の削除を今すぐ止めるには？

重要なポイント

設定は1つです。~/.claude/settings.jsonを開き、cleanupPeriodDaysを大きな数値、たとえば3650（10年）に設定します。実質的に自動削除を無効にできます。上限より古いものはなくなるからです。重要なのは、この設定がまだ削除されていないファイルだけを保護することです。クリーンアップですでに消去された履歴は復元できません。ですから、次のセッションを失う前に行動することが第一歩です。

削除を止めるには、次の3手順を行います。

設定ファイル~/.claude/settings.jsonを開きます（ファイルが存在しない場合は作成してください）。
cleanupPeriodDays設定に大きな値を追加します。

{
  "cleanupPeriodDays": 3650
}

ファイルを保存します。設定は次回Claude Codeを起動したときに有効になります。

値3650は10年を意味し、実質的に削除は行われなくなります。クリーンアップを続けつつ期間を延ばしたい場合は、365（1年）に設定してください。すると、1年より古いセッションだけが消えます。次のコマンドで設定が読み込まれているか確認できます。

grep cleanupPeriodDays ~/.claude/settings.json

見落としやすい注意点が1つあります。期間を延ばしても、すでに削除されたものは復元されません。クリーンアップは起動時に実行され、過去の実行で消去されたものは完全に失われています。だからこそ、まずこの設定を行うべきです。今後の損失は防げますが、すでに消えたものは戻りません。Claude Codeの履歴だけでなく、誤ったコマンドからプロジェクトも守りたい場合は、ガイド「プロジェクトを壊さないClaude Codeの設定方法」をご覧ください。

セッション履歴はプロジェクトの第二の脳の一部です。他のどこにも記録していない判断のロジックが含まれます。cleanupPeriodDaysはファイルを保護しますが、6か月後に必要なものを取り出せる仕組みにはなりません。

クリーンアップ対象外へ履歴を自動アーカイブするには？

重要なポイント

クリーンアップの対象外である~/.claude/projects/の外にセッションをコピーします。1日1回、rsync -aで別のディレクトリにコピーするだけで十分です。新しいファイルが追加され、古いファイルはそのまま残ります。アーカイブは外部にあるため、cleanupPeriodDaysもmtimeの問題も影響しません。macOSではlaunchd、Linuxではcronで実行を自動化すれば、履歴は自動的に蓄積されます。

考え方は簡単です。Claude Codeには自分のフォルダーを好きに扱わせ、その外側に別のアーカイブを持ちます。その削除機構からは守られますが、ディスク故障、誤削除、コピー失敗で失われる可能性はあります。次のように設定します。

管理対象ディレクトリの外にアーカイブフォルダーを作成します。

mkdir -p ~/claude-history-archive

現在の履歴をそこにコピーします。-aフラグは構造とタイムスタンプを保持し、--ignore-existingはすでにコピー済みのファイルを変更せずに残します。

rsync -a ~/.claude/projects/ ~/claude-history-archive/

1日1回の実行を自動化します。macOSではlaunchdを使います。~/Library/LaunchAgents/com.example.claudearchive.plistファイルを作成します。

<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>com.example.claudearchive</string>
  <key>ProgramArguments</key>
  <array>
    <string>/usr/bin/rsync</string>
    <string>-a</string>
    <string>/Users/YOUR_NAME/.claude/projects/</string>
    <string>/Users/YOUR_NAME/claude-history-archive/</string>
  </array>
  <key>StartInterval</key>
  <integer>86400</integer>
</dict>
</plist>

launchdエージェントを読み込んで、バックグラウンドで実行します。

launchctl load ~/Library/LaunchAgents/com.example.claudearchive.plist

Linuxでは、crontabの1行（crontab -e）で同じことができます。

0 3 * * * rsync -a ~/.claude/projects/ ~/claude-history-archive/

前のセクションの同期が失敗するのに、こちらが機能するのはなぜでしょうか？アーカイブは~/.claude/projects/の外にあるため、クリーンアップからまったく見えません。コピーは一方向（稼働中フォルダーからアーカイブへ）で、稼働中ファイルのmtimeには触れないため、mtimeの問題も起きません。明日Claude Codeが自身のフォルダーからセッションを削除しても、アーカイブ内のコピーは残ります。

セッションアーカイブを検索可能な第二の脳にするには？

重要なポイント

アーカイブをgitで管理すれば、すべてのセッションを含む、バージョン管理され、完全に検索できるデータベースになります。アーカイブフォルダーでgit initを実行し、毎日git add -A && git commitを実行すれば、変更履歴が得られ、誤った上書きから保護できます。通常のgrepで過去のセッションを検索し、.jsonlは行区切りJSONなのでjqで構造化コンテンツを取り出せます。これにより、アーカイブは実用的なツールになります。

ファイルを蓄積するだけでは足りません。アクセスできる必要があります。2つの手順でアーカイブを実用的なツールにできます。

まず、gitでバージョン管理します。アーカイブフォルダーでリポジトリを初期化します。

cd ~/claude-history-archive
git init
git add -A && git commit -m "Claude Codeの履歴の最初のスナップショット"

rsyncと同じ毎日の実行にgit add -A && git commitを追加します。これでバージョン履歴が得られ、何がいつ追加されたかを確認でき、誤った上書きを1つのコマンドで元に戻せます。

次に、検索します。.jsonlファイルは行区切りJSONなので、使い慣れたツールで扱えます。特定のトピックを話したセッションを探します。

grep -rl "データベース移行" ~/claude-history-archive/

jqを使って、セッションからプロンプトのテキストだけを抽出します（JSONのため）。

jq -r 'select(.type=="user") | .message.content' session.jsonl

ここまでくると、セッション履歴はプロジェクトの第二の脳として機能し始めます。「3月にどう決めたか」を数秒で取り出せるデータベースです。セッションで文脈がどこに保存されるか、その管理方法を別途解説した記事は「Claude Codeでトークンはどこへ行くのか」をご覧ください。

すでに削除されたセッションを復元できる？

重要なポイント

組み込みの方法はありません。Claude Codeは削除したファイルをゴミ箱に入れず、ロールバックも保持しません。ファイルは完全に消去されます。唯一の可能性は、削除前に作成した外部コピーです。macOSのTime Machineスナップショット、OneDriveやDropboxのバージョン履歴、手動バックアップなどです。どれもなければ、セッションは失われています。だからこそ、失うものができる前に、事前に保護を設定する必要があります。

正直な答えは、おそらく無理です。Claude Codeには復元機能も、ゴミ箱も、削除されたトランスクリプトの取り消しログもありません。ファイルはディスクから消えるだけです。

方法は1つあります。事前に有効化していた場合のシステムバックアップです。

macOS Time Machine—削除前に~/.claude/projects/を含むスナップショットがあれば、必要な日付のバックアップからファイルを取得できます。
OneDrive / Dropboxのバージョン履歴—バージョン管理を有効にしてフォルダーを同期していた場合、クラウドのバージョン履歴からファイルを探します（ただし、mtimeの落とし穴に注意してください。同期が削除を引き起こしていた可能性もあります）。
手動コピー—管理対象フォルダーの外に手動で実行したrsyncやcpなど。

どれも存在しなかった場合、セッションは失われています。そして、これは珍しいことではありません。Anthropicのリポジトリにあるバグ報告の投稿者の1人は、38件の記録のうち26件が破損し、数か月分の作業が失われたとしています。信頼できる保護策は、損失が起きる前に設定することです。保存できるものがまだあるうちに、今日cleanupPeriodDaysと自動アーカイブを設定してください。

cleanupPeriodDaysにはどの値を選べばよい？

重要なポイント

ほとんどの人には、3650（10年で、実質的に削除を無効化）と外部の自動アーカイブの組み合わせがおすすめです。履歴が不要で、ディスク上に秘密を残さないことをより重視する場合に限り、デフォルト値の30を使ってください。365は妥当な中間案で、年に1回クリーンアップします。履歴をまったく書き込まない選択肢もあります。環境変数CLAUDE_CODE_SKIP_PROMPT_HISTORYまたはフラグ--no-session-persistenceを使いますが、これは目的が逆です。

設定は1つですが、その意味はいくつかあります。選択肢を比較し、用途に合わせて選んでください。

値	動作	適している人
`30`（デフォルト）	起動時に30日より古いセッションを削除	履歴は不要で、機密データをディスクに保存しないことをより重視する人
`365`	1年分の履歴を保持し、その後は年1回クリーンアップ	最近の履歴は必要だが、無期限のアーカイブは不要な人
`3650`	実質的に削除を無効化	すべてを保持し、外部アーカイブも使いたい人（推奨）
`CLAUDE_CODE_SKIP_PROMPT_HISTORY`	履歴をディスクにまったく書き込まない	最大限のプライバシーを求め、履歴がまったく不要な人

重要なセキュリティ上の注意点があります。3650を設定してすべてを保持する場合、キーやコードが含まれる可能性のあるトランスクリプトをディスクに保存することに同意したことになります。これは、アーカイブの利便性とリスクの間の意図的なトレードオフです。リスクを最小限にするには、アーカイブを暗号化ディスク（macOSのFileVaultなど）に保存し、パブリッククラウドに置かず、公開gitリポジトリにコミットしないでください。Claude Codeを通じて漏えいする可能性のあるデータを、別のガイド「Claude Codeのデータセキュリティ」にまとめました。

今日やること：チェックリスト

重要なポイント

cleanupPeriodDays: 3650で保持期間を延ばし、~/.claude/projects/外へコピーし、版を管理すると損失を減らせます。Claude Codeの削除から守られるのは、成功してコピーしたファイルだけです。毎日の実行が成功しても直近1日分が未保存の場合があり、失敗や未実行で間隔は広がります。同一ディスクのコピーはディスク故障への対策にはなりません。

次の手順で保護を設定します。

~/.claude/settings.jsonでcleanupPeriodDays: 3650を設定します。これで削除を止められます。
管理対象フォルダーの外に~/claude-history-archiveを作成し、最初のrsync -aを実行します。
macOSではlaunchd、Linuxではcronを使い、毎日実行するよう設定します。
アーカイブでgitを初期化し、同じ実行にgit add -A && git commitを追加します。
アーカイブが暗号化ディスク上にあり、パブリッククラウドと同期されていないことを確認します。
定期実行ごとのコピー成功を確認し、最近のセッションを調べ、定期的に別の一時フォルダーへ復元して読めるか確認します。
機器やディスクの損失にも備える場合は、適切なアクセス制御を持つ独立保存のバックアップを用意し、復元も試します。同一ディスク上のGit履歴は独立バックアップではありません。

セッション履歴はClaudeを信頼できるものにする文脈の一層にすぎません。

出典

Ailootを詳しく知る。

詳細を見る