claude-memでClaude Codeにセッション間記憶を持たせる

Claude Codeを日常的に使っていると、あるタイミングで必ず「またか」という気持ちになります。
新しいセッションを開くたびに、プロジェクトの背景・命名規則・直前の設計判断の経緯を再度説明し直す、あの作業のことです。
実際に claude-mem を手元で動かして、圧縮されたコンテキストが次のセッションにどんな形で渡ってくるかを確かめてみました。
仕組みの内側まで掴んでおくと、「自分のプロジェクトに入れる価値があるか」の判断がずっとクリアになります。

セッションをまたぐたびに説明し直す、あの無駄をなくしたい

コンテキストウィンドウは、セッション単位でリセットされる揮発メモリです。
Claude Codeのセッションを閉じた瞬間に内容はすべて消え、次に起動したClaudeは白紙の状態から始まります。
この仕組み自体は設計上の必然で、変えようがありません。

問題は、毎回再注入しているものの量が意外と多いことです。
「このプロジェクトはモノレポ構成でアプリが apps/ 配下にあります」「DBのマイグレーションは drizzle-orm を使っています、Prismaではありません」「先週のセッションで WebSocket のハンドラーを ws.ts に切り出すことに決めました」といった情報を、何度もやり取りの冒頭で伝え直していませんか。
こうした文脈は CLAUDE.md に手書きで管理したり、/compact コマンドでセッション途中に要約したりすることで対処できます。
ただしどちらも 手動運用 が前提です。

claude-memはその自動化に特化したツールです。
セッション終了時にAIでコンテキストを圧縮・保存し、次回セッション開始時に自動注入します。
「CLAUDE.mdを自分でメンテする」から「AIが勝手にまとめてくれる」へのシフト、というイメージが近いです。

claude-mem の内部構造：ライフサイクルフックから保存ファイルまで

claude-memはClaude Codeのライフサイクルフック機構を利用して動きます。
SessionStart・UserPromptSubmit・PostToolUseといったタイミングでフックが起動し、セッション中のツール呼び出しの内容と結果を収集します。
セッションが終了すると、Claude Agent SDKを呼び出してセマンティックサマリーを生成し、そのサマリーを ~/.claude-mem/data/ 配下に保存します。
次回のSessionStartフックが走るときに保存済みのサマリーを読み込んでコンテキストとして注入する、という一連のサイクルです。

設定ファイルは ~/.claude-mem/settings.json に置かれ、初回実行時にデフォルト値で自動生成されます。
主なキーの構成はこのようなイメージです。

{
  "model": "<プロバイダーに応じたモデルを指定>",
  "workerPort": 3748,
  "dataDir": "~/.claude-mem/data",
  "logLevel": "info",
  "contextInjection": {
    "enabled": true,
    "maxTokens": 4096
  },
  "CLAUDE_MEM_MODE": "default"
}

model キーには claude-mem observer・OpenRouter・Gemini・Anthropicのいずれかのプロバイダーに対応した値が入ります。
workerPort はバックグラウンドプロセスが使うポートで、デフォルトのままで問題ない場面がほとんどです。
CLAUDE_MEM_MODE でワークフローの動作モードと言語を切り替えることができます。

使い始める前に把握しておきたいのが、生成されるサマリーはロッシーな圧縮だという点です。
ロッシーとは「情報を選別して捨てる」圧縮方式で、元のセッション内容をそのまま保持するわけではありません。
ファイルへの変更内容・設計判断の経緯・確定した技術選定は残りやすい傾向があります。
逆に、細かいエラーメッセージの文面・試行錯誤の一時的な実装・デバッグ中の詳細ログは捨てられやすいです。
AIが「重要そう」と判断したものだけが次のセッションに渡る——そういう性質のツールだということを最初に把握しておくと、使い方の解像度が上がります。

インストールから初回動作確認まで、実際に手を動かす

インストール方法は環境によって選べます。

npxで直接インストール: 最もシンプルで Claude Code向けのデフォルト
プラグインマーケットプレイス経由: Claude Code内のスラッシュコマンドで完結する
IDE指定オプション: OpenCodeやAntigravity CLI向けに --ide フラグを付ける

# npx で直接インストール（Claude Code向け）
npx claude-mem install

# Claude Code プラグインマーケットプレイス経由（Claude Code内で実行）
/plugin marketplace add thedotmack/claude-mem
/plugin install claude-mem

# OpenCode 向け
npx claude-mem install --ide opencode

npxで実行するとインストール完了後にブラウザでのサインインを求められます。
メールアドレスにマジックリンクが届く方式で、クレジットカードの登録は不要です。
サインインすると claude-mem observer という専用プロバイダーが14日間無料で使えるようになります。
無料期間が終わると、設定したプロバイダー（OpenRouter・Gemini・Anthropicのいずれか）に切り替わる仕組みです。

CI環境やアカウントを作りたくない場合は、サインインをスキップできます。
環境変数 CLAUDE_MEM_ONLINE_OPTIN を false にセットするか、--provider フラグを明示的に渡せばアカウントなしでインストールが完了します。

# サインインをスキップしてインストール
CLAUDE_MEM_ONLINE_OPTIN=false npx claude-mem install

一番つまずきやすいのはワーカープロセスの起動忘れ です。
インストールしただけではフックは仕掛かっていますが、バックグラウンドのワーカーが動いていないと記録が何も起きません。
「ちゃんと動いているはずなのに何も記録されない」という状況の大半はこれです。
インストール後に必ず以下を実行してください。

claude-mem start

PCを再起動したあとも、ワーカーは自動では復活しません。
「なんか動いていないな」と感じたら、まずワーカーを再起動するのが確認の第一歩です。

ワーカーを起動してClaude Codeを再起動したあと、普通に作業してセッションを閉じてみてください。
~/.claude-mem/data/ 配下にプロジェクトパスに対応するサマリーファイルが生成されていれば、記録は正常に動いています。

圧縮されたコンテキストが次セッションにどう見えるか

次のセッションを開くと、SessionStartフックが走ってサマリーが読み込まれます。
Claude側にはシステムコンテキストとして注入されるので、ユーザー視点では「前回の続きを知っているClaude」として現れます。

注入されるコンテキストは、おおむねこのような形式のテキストとして渡ってくるイメージです（実際の出力はバージョンや設定により異なります）。

[Claude-Mem Context]

Project: payment-api-refactor
Last session: 2025-07-10

Summary:
Stripeのwebhookハンドラーをsrc/webhooks/stripe.tsに実装。
処理対象イベントはpayment_intent.succeededとpayment_intent.payment_failedの2種。
署名検証にはstripe.webhooks.constructEventを使い、秘密鍵は
STRIPE_WEBHOOK_SECRETから読む設計に確定。
エラー時のリトライ戦略は未決定。次回セッションで検討が必要。

「どのファイルを触ったか」「なぜその設計を選んだか」「次に何が残っているか」がコンパクトにまとまったイメージです。
細かいエラーの文言や試行錯誤の過程は捨てられますが、セッションを再開する起点としては十分な情報量になります。

実際にどんな内容がサマリーに残ったかを確認したいときは、 ~/.claude-mem/data/ 配下のファイルを直接開いてみてください。
ここを定期的に覗く習慣が、サマリー品質を評価する一番の近道です。
「次のセッションの起点になるか」を自分の目で判断できる——それがこのツールの透明性の高さでもあります。

Cursor向けには、インストール時にコンテキストの書き出し先が .cursor/rules/claude-mem-context.mdc になります。
このファイルはCursorの全チャットに自動インクルードされる仕組みで、Claude CodeとCursorを並用しながらコンテキストを共有する運用も可能です。

CodexやGitHub Copilotへの対応については、現時点では限界があります。
claude-memがセッション間記憶を自動化できるのは、エージェント側にライフサイクルフック機構があることが前提です。
フックを持たないエージェントでは、サマリーファイルが生成されても次セッションへの自動注入が機能しません。
Claude CodeメインにCursorをサブで使う構成であれば恩恵を得やすく、CodexやCopilotがメインの場合は現時点では相性がかなり悪いと考えておく方が現実的です。

「自分のプロジェクトに入れるか」の判断軸

正直に言うと、全員に刺さるツールではありません。

効果が出やすいのは、数週間〜数ヶ月にわたって継続している開発で、設計判断が積み重なっているプロジェクトです。
「先週どこまで決めたかを思い出す」ために毎回ロストタイムが発生しているなら、導入の動機として十分です。
チーム規模としては個人か少人数が向いていて、大規模チームではサマリーの粒度や管理の運用コストが別の問題になってきます。
逆に使い捨てスクリプトや単発の調査タスクでは恩恵はほぼありません。
毎回フレッシュな状態でAIに考えさせたい場面では、過去のサマリーが意図せずバイアスになることもあるので、むしろオフにしておく方がよいです。

判断のときに意識しておきたいのは、このツールが 「自動化」と「正確さ」を同時には保証しない という点です。
サマリーの生成は自動ですが、ロッシーな圧縮の性質上、重要な判断経緯がサマリーから抜け落ちることがあります。
自動要約を信頼して確認をやめた途端に、重要な情報が次のセッションに渡っていない状態に気づかないまま作業を進める、という事態が起きます。
~/.claude-mem/data/ のファイルを時々読む習慣——これだけは自動化できないので、運用として組み込んでおくことをおすすめします。

14日間の無料トライアルで試して判断するという入り口は現実的です。
評価基準はシンプルで、「生成されたサマリーを読んで、次のセッションの起点になると思えるか」だけです。
使えるレベルの文章になっていれば導入価値があります。
逆に重要な設計判断がすっぽり抜けているようなら、素直に見送りでいいです。

株式会社ホコサキは山口県宇部を拠点に、Web制作・業務システム開発・AI活用支援を手がけています。
claude-memのような新しい開発ツールの評価・導入検討もお気軽にご相談ください。
詳しくはホコサキのサービスページをご覧ください。