thedotmack

今日のGitHubトレンド thedotmack/claude-mem Claude Code向けの永続的なメモリ圧縮システムです。 ツールの使用状況を自動的に記録し、セマンティックな要約を生成することで、セッションをまたいだコンテキストの保存を可能にします。 これにより、セッションが終了したり再接続したりした後でも、プロジェクトに関する知識の連続性を維持することを目的としています。

I came across this impressive open-source project on GitHub: persistent AI agent memory. See link below. #opensource #AI #GitHub thedotmack/claude-mem

Claude Codeが/clearで全部忘れる問題。claude-memで記憶を持たせる前に知っておきたい4つのこと /clear を打つたびに、さっきまでの作業をAIに説明し直していませんか。 「このファイルはもう直した」「このエラーはこう解決した」——会話を整理するたびに、それが全部消えます。長い作業ほど、説明し直す手間は増えていきます。 この記事では、その手間を減らす記憶プラグイン claude-mem を取り上げます。GitHub のスターは約10万9千（2026年11月2日調べ）、調べた日は日次トレンド1位でした。 ただし、入れる前に知っておかないと困る点がいくつかあります。APIキーが記録に残りうること、入れ方を間違えると何も始まらないこと、そして記憶づくりにも使用量がかかることです。 YouTube で解説した内容を、図とソースコードの根拠つきでまとめ直しました。 この記事で分かること claude-mem が「何を・いつ・どこに」記録して、どう次の会話に戻すのか 正しい入れ方と、よくあるつまずき 入れたらすぐ変えたい設定（APIキーの伏せ字・日本語化） 記憶づくりの使用量と、上限が近いときの動き 先に結論 便利なのは、/clear や圧縮のあとでも前回の要点が自動で入ること APIキーの自動の伏せ字は初期設定でオフ。入れたらまずオンにする 入れ方は npx claude-mem install か /plugin。npm install -g では動かない 記憶づくりもAIを使うので、どこの使用量を使うかを最初に決める まず4問、3秒で予想してから読んでください ▲ YouTubeショートで出した4つの問いです。答えは記事の中で順に出てきます。 画面に出たAPIキー、AIの記憶から勝手に消える？ npm で入れたのに何も覚えない。なぜ？ AIの記憶づくり、使用量はタダ？ 使用量の上限まで残り5%。記憶はどうなる？ 1. claude-mem とは：/clear のあとに「前回の要点」が入る claude-mem は、Claude Code の作業記録を自動で集めて要約し、次の会話の最初に自動で差し込むプラグインです。 ▲ 流れは「フックで集める → 別のAIがまとめる → SQLiteに保存 → 次の会話に差し込む」。素の Claude Code は /clear で白紙に戻りますが、claude-mem を入れると白紙のあとに要点が入ります。 実際にリポジトリを取得して、フックの設定ファイル（plugin/hooks/hooks.json）を開いてみました。 ▲ git clone は11.3秒（動画の作業環境で計測）。hooks.json には、startup（起動時）・clear（/clear のあと）・compact（圧縮のあと）に記憶を差し込む指定が入っていました。 基本情報はこちらです。 項目 内容 ライセンス Apache-2.0 必要なもの Node.js 20 以上 バージョン 動画の撮影時は v15.8.0、記事を書いた11月3日時点では v15.9.0 保存先 手元の SQLite（設定は ~/.claude-mem/settings.json） 2. 入れ方：正しいのは2通りだけ 入れ方は次の2通りです（README 記載）。 ① ターミナルから npx claude-mem install ② Claude Code の中から /plugin marketplace add thedotmack/claude-mem /plugin install claude-mem 入れたら Claude Code を再起動します。OpenCode などほかのツールに入れる場合は --ide <名前> を付けます。 Q2の答え：npm で入れても記憶は始まらない いちばん多そうなつまずきがこれです。claude-mem は npm にも公開されていますが、npm install -g claude-mem で入るのは SDK（ライブラリ）だけ。記録に必要なフックが Claude Code に登録されず、裏で動くワーカーも用意されません（README の注記に明記されています）。 インストーラーの最後に「サインイン」がある npx claude-mem install は、最後にブラウザでのサインインを求めます。ここで選ぶ「記憶をどこのAIで作るか」は、あとの費用の話に直結します（5章で説明します）。サインインを飛ばしたい場合は --provider を指定します。 3. 記録のしくみ：いつ、何が記録されるのか claude-mem は Claude Code の フック（決まったタイミングで自動実行される仕組み）を使って記録を集めます。 ▲ hooks.json に登録されたタイミングは8種類。メッセージを送ったとき、ツールを使う前と後、応答が終わったとき、会話の終わりなど。 中心は「ツールを使ったあと（PostToolUse）」です。読んだファイル、実行したコマンド、編集の内容といったツールの入出力が観察記録として集められます。 ▲ 集めた記録は「別のAI」（初期値は haiku）がまとめ、手元の SQLite に保存します。応答が終わったときには、その回のまとめも作られます。 ここが大事なポイントです。記録されるのはツールの入出力です。つまり、ターミナルに表示されたものは記録に入りうる、ということです。これが Q1 の答えにつながります。 4. 差し込みと探し方：トークンを無駄にしない3段階 会話が始まるときに差し込む ▲ 起動したとき（startup）、/clear のあと（clear）、圧縮のあと（compact）の3つのタイミングで、過去の記録が会話の最初に入ります。差し込む件数は設定で変えられます（初期値は50件）。 必要な記録だけを全文で取り出す 過去の記録をまるごと読み込むと、トークンを大量に使います。claude-mem は目次 → 前後 → 全文の3段階で探します。 段階 ツール 取れるもの 1件あたりの目安（README記載） 1 search 目次（IDの一覧） 約50〜100トークン 2 timeline その記録の前後で何をしていたか — 3 get_observations 絞り込んだIDの全文 約500〜1,000トークン README では、全文を取る前に絞り込むことで「約10倍のトークン節約」になると説明されています（この数字は README の記載で、私は計測していません）。 5. 秘密を守る設定：入れたらまずここ Q1の答え：APIキーは初期設定では伏せ字にならない ソースコード（src/shared/SettingsDefaultsManager.ts）で設定の初期値を確認すると、自動の伏せ字（CLAUDE_MEM_REDACT_ENABLED）は "false"（オフ） でした。 3章のとおり記録の対象はツールの入出力なので、たとえば curl の応答に表示されたAPIキーが、そのまま記録に入る可能性があります。 秘密を守る方法は2つあります。 ① <private> タグ：囲んだ部分は、その会話では使えて、記録には残りません。 <private> Host: internal-db-prod.example.com User: admin_user </private> このエラーの原因は？ ② 自動の伏せ字：~/.claude-mem/settings.json に1行足すと、よくある秘密の形を見つけて <redacted/> に置き換えます。 { "CLAUDE_MEM_REDACT_ENABLED": "true" } docs によると、OpenAI・Anthropic・AWS・GitHub などのキーの形が組み込まれています（11月3日時点の docs では23種類）。password= のような形のないものまで対象にするには、"CLAUDE_MEM_REDACT_GENERIC_ENABLED": "true" も足します。 6. 費用と設定：記憶づくりにもAIを使う Q3の答え：初期値では、あなたのプランの使用量を使う 記録をまとめるのもAIなので、使用量がかかります。設定の初期値は次のとおりでした。 動かす元：claude 認証：subscription（あなたの Claude Code のログイン） モデル：haiku docs にも「memory shares your Claude plan usage（記憶はあなたの Claude プランの使用量を共有する）」と書かれています。 一方、対話式のインストーラーでは CMEM Pro（作者のサービス。30日無料）が最初から選ばれた状態になっています。選ぶと記録はそちらで処理され、購読しなければ、そのあとは自分の Anthropic のプランに切り替わります（docs 記載）。OpenRouter や Gemini の自分のキーを使う選択肢もあります。 どこのAIで、誰の使用量を使うのか。入れるときに自分で決めておくのがおすすめです。 Q4の答え：上限が近づくと、記録係のAIは止まる ログインで動かしている場合、使用量の枠が次の割合に達すると、記録係のAIが止まります（docs「Quota Guard Settings」と設定の初期値で確認）。 枠 止まる境目（初期値） 5時間の枠 95% 1週間の枠 93% 1週間の Sonnet の枠 92% 本来の作業のための使用量を、記憶づくりが食いつぶさないための仕組みです。APIキーで動かしている場合、この停止は働きません。 記録を日本語にする 記録は初期設定では英語で作られます。日本語にしたい場合は、設定に1行足して Claude Code を再起動します。 { "CLAUDE_MEM_MODE": "code--ja" } 入れる前の5点チェック ▲ スクショして、入れるときに見返してください。 入れ方は npx claude-mem install か /plugin（npm install -g ではない） 記憶をどこのAIで作るか決めた（CMEM Pro／自分のプラン／自分のキー） 自動の伏せ字をオンにした（"CLAUDE_MEM_REDACT_ENABLED": "true"） 残したくない部分は <private> で囲む 記録を日本語にするなら "CLAUDE_MEM_MODE": "code--ja" まとめ claude-mem は、/clear や圧縮のたびに作業を説明し直す手間を減らしてくれる道具です。一方で、記録の対象はツールの入出力そのものなので、APIキーの伏せ字をオンにしてから使うのが前提だと考えています。 動画では、ここで書いた内容を図とアニメーションで8分にまとめています。 ショート（Q1〜Q4の問い）はこちらです。 画面に出たAPIキー、AIの記憶に残る？ youtube.com npmで入れたのに、AIが何も覚えない。なぜ？ youtube.com AIの記憶づくり、使用量はタダ？ youtube.com 上限まで残り5%、AIの記憶はどうなる？ youtube.com この記事で確認したこと・していないこと 確認したこと：リポジトリを取得し、hooks.json の中身と、設定の初期値（src/shared/SettingsDefaultsManager.ts）、README・docs の記載を読みました（2026年11月2〜3日、v15.8.0〜v15.9.0）。 していないこと：記憶の作成・差し込みの動作そのものは実行していません。トークン数や「約10倍の節約」などの数字は README・docs の記載です。 内容は2026年11月時点の情報です。設定の初期値は今後のバージョンで変わる可能性があります。 公式とは関係のない個人の紹介記事です。 出典 claude-mem（GitHub）：thedotmack/claude-mem 公式ドキュメント：docs.claude-mem.ai 本文の根拠ファイル：README.md、plugin/hooks/hooks.json、src/shared/SettingsDefaultsManager.ts、docs/public/installation.mdx、docs/public/configuration.mdx、docs/public/usage/auto-redaction.mdx、docs/public/usage/private-tags.mdx、docs/public/usage/quota-fallback.mdx

Claude Codeが/clearで全部忘れる問題。claude-memで記憶を持たせる前に知っておきたい4つのこと !image.png /clear を打つたびに、さっきまでの作業をAIに説明し直していませんか。 「このファイルはもう直した」「このエラーはこう解決した」——会話を整理するたびに、それが全部消えます。長い作業ほど、説明し直す手間は増えていきます。 この記事では、その手間を減らす記憶プラグイン claude-mem を取り上げます。GitHub のスターは約10万9千（2026年11月2日調べ）、調べた日は日次トレンド1位でした。 ただし、入れる前に知っておかないと困る点がいくつかあります。APIキーが記録に残りうること、入れ方を間違えると何も始まらないこと、そして記憶づくりにも使用量がかかることです。 YouTube で解説した内容を、図とソースコードの根拠つきでまとめ直しました。 この記事で分かること - claude-mem が「何を・いつ・どこに」記録して、どう次の会話に戻すのか - 正しい入れ方と、よくあるつまずき - 入れたらすぐ変えたい設定（APIキーの伏せ字・日本語化） - 記憶づくりの使用量と、上限が近いときの動き 先に結論 - 便利なのは、/clear や圧縮のあとでも前回の要点が自動で入ること - APIキーの自動の伏せ字は初期設定でオフ。入れたらまずオンにする - 入れ方は npx claude-mem install か /plugin。npm install -g では動かない - 記憶づくりもAIを使うので、どこの使用量を使うかを最初に決める --- まず4問、3秒で予想してから読んでください !image.png ▲ YouTubeショートで出した4つの問いです。答えは記事の中で順に出てきます。 1. 画面に出たAPIキー、AIの記憶から勝手に消える？ 2. npm で入れたのに何も覚えない。なぜ？ 3. AIの記憶づくり、使用量はタダ？ 4. 使用量の上限まで残り5%。記憶はどうなる？ --- 1. claude-mem とは：/clear のあとに「前回の要点」が入る claude-mem は、Claude Code の作業記録を自動で集めて要約し、次の会話の最初に自動で差し込むプラグインです。 !image.png ▲ 流れは「フックで集める → 別のAIがまとめる → SQLiteに保存 → 次の会話に差し込む」。素の Claude Code は /clear で白紙に戻りますが、claude-mem を入れると白紙のあとに要点が入ります。 実際にリポジトリを取得して、フックの設定ファイル（plugin/hooks/hooks.json）を開いてみました。 !image.png ▲ git clone は11.3秒（動画の作業環境で計測）。hooks.json には、startup（起動時）・clear（/clear のあと）・compact（圧縮のあと）に記憶を差し込む指定が入っていました。 基本情報はこちらです。 !image.png | 項目 | 内容 | |---|---| | ライセンス | Apache-2.0 | | 必要なもの | Node.js 20 以上 | | バージョン | 動画の撮影時は v15.8.0、記事を書いた11月3日時点では v15.9.0 | | 保存先 | 手元の SQLite（設定は ~/.claude-mem/settings.json） | --- 2. 入れ方：正しいのは2通りだけ !image.png 入れ方は次の2通りです（README 記載）。 # ① ターミナルから npx claude-mem install # ② Claude Code の中から /plugin marketplace add thedotmack/claude-mem /plugin install claude-mem 入れたら Claude Code を再起動します。OpenCode などほかのツールに入れる場合は --ide <名前> を付けます。 Q2の答え：npm で入れても記憶は始まらない !image.png いちばん多そうなつまずきがこれです。claude-mem は npm にも公開されていますが、npm install -g claude-mem で入るのは SDK（ライブラリ）だけ。記録に必要なフックが Claude Code に登録されず、裏で動くワーカーも用意されません（README の注記に明記されています）。 !image.png インストーラーの最後に「サインイン」がある npx claude-mem install は、最後にブラウザでのサインインを求めます。ここで選ぶ「記憶をどこのAIで作るか」は、あとの費用の話に直結します（5章で説明します）。サインインを飛ばしたい場合は --provider を指定します。 --- 3. 記録のしくみ：いつ、何が記録されるのか claude-mem は Claude Code の フック（決まったタイミングで自動実行される仕組み）を使って記録を集めます。 !image.png ▲ hooks.json に登録されたタイミングは8種類。メッセージを送ったとき、ツールを使う前と後、応答が終わったとき、会話の終わりなど。 中心は「ツールを使ったあと（PostToolUse）」です。読んだファイル、実行したコマンド、編集の内容といったツールの入出力が観察記録として集められます。 !image.png ▲ 集めた記録は「別のAI」（初期値は haiku）がまとめ、手元の SQLite に保存します。応答が終わったときには、その回のまとめも作られます。 ここが大事なポイントです。記録されるのはツールの入出力です。つまり、ターミナルに表示されたものは記録に入りうる、ということです。これが Q1 の答えにつながります。 --- 4. 差し込みと探し方：トークンを無駄にしない3段階 会話が始まるときに差し込む !image.png ▲ 起動したとき（startup）、/clear のあと（clear）、圧縮のあと（compact）の3つのタイミングで、過去の記録が会話の最初に入ります。差し込む件数は設定で変えられます（初期値は50件）。 必要な記録だけを全文で取り出す 過去の記録をまるごと読み込むと、トークンを大量に使います。claude-mem は目次 → 前後 → 全文の3段階で探します。 !image.png | 段階 | ツール | 取れるもの | 1件あたりの目安（README記載） | |---|---|---|---| | 1 | search | 目次（IDの一覧） | 約50〜100トークン | | 2 | timeline | その記録の前後で何をしていたか | — | | 3 | get_observations | 絞り込んだIDの全文 | 約500〜1,000トークン | README では、全文を取る前に絞り込むことで「約10倍のトークン節約」になると説明されています（この数字は README の記載で、私は計測していません）。 --- 5. 秘密を守る設定：入れたらまずここ Q1の答え：APIキーは初期設定では伏せ字にならない !image.png ソースコード（src/shared/SettingsDefaultsManager.ts）で設定の初期値を確認すると、自動の伏せ字（CLAUDE_MEM_REDACT_ENABLED）は "false"（オフ） でした。 3章のとおり記録の対象はツールの入出力なので、たとえば curl の応答に表示されたAPIキーが、そのまま記録に入る可能性があります。 秘密を守る方法は2つあります。 !image.png ① <private> タグ：囲んだ部分は、その会話では使えて、記録には残りません。 <private> Host: internal-db-prod.example.com User: admin_user </private> このエラーの原因は？ ② 自動の伏せ字：~/.claude-mem/settings.json に1行足すと、よくある秘密の形を見つけて <redacted/> に置き換えます。 { "CLAUDE_MEM_REDACT_ENABLED": "true" } docs によると、OpenAI・Anthropic・AWS・GitHub などのキーの形が組み込まれています（11月3日時点の docs では23種類）。password= のような形のないものまで対象にするには、"CLAUDE_MEM_REDACT_GENERIC_ENABLED": "true" も足します。 --- 6. 費用と設定：記憶づくりにもAIを使う Q3の答え：初期値では、あなたのプランの使用量を使う !image.png 記録をまとめるのもAIなので、使用量がかかります。設定の初期値は次のとおりでした。 - 動かす元：claude - 認証：subscription（あなたの Claude Code のログイン） - モデル：haiku docs にも「memory shares your Claude plan usage（記憶はあなたの Claude プランの使用量を共有する）」と書かれています。 !image.png 一方、対話式のインストーラーでは CMEM Pro（作者のサービス。30日無料）が最初から選ばれた状態になっています。選ぶと記録はそちらで処理され、購読しなければ、そのあとは自分の Anthropic のプランに切り替わります（docs 記載）。OpenRouter や Gemini の自分のキーを使う選択肢もあります。 どこのAIで、誰の使用量を使うのか。入れるときに自分で決めておくのがおすすめです。 Q4の答え：上限が近づくと、記録係のAIは止まる !image.png ログインで動かしている場合、使用量の枠が次の割合に達すると、記録係のAIが止まります（docs「Quota Guard Settings」と設定の初期値で確認）。 | 枠 | 止まる境目（初期値） | |---|---| | 5時間の枠 | 95% | | 1週間の枠 | 93% | | 1週間の Sonnet の枠 | 92% | 本来の作業のための使用量を、記憶づくりが食いつぶさないための仕組みです。APIキーで動かしている場合、この停止は働きません。 記録を日本語にする !image.png 記録は初期設定では英語で作られます。日本語にしたい場合は、設定に1行足して Claude Code を再起動します。 { "CLAUDE_MEM_MODE": "code--ja" } --- 入れる前の5点チェック !image.png ▲ スクショして、入れるときに見返してください。 1. 入れ方は npx claude-mem install か /plugin（npm install -g ではない） 2. 記憶をどこのAIで作るか決めた（CMEM Pro／自分のプラン／自分のキー） 3. 自動の伏せ字をオンにした（"CLAUDE_MEM_REDACT_ENABLED": "true"） 4. 残したくない部分は <private> で囲む 5. 記録を日本語にするなら "CLAUDE_MEM_MODE": "code--ja" --- まとめ claude-mem は、/clear や圧縮のたびに作業を説明し直す手間を減らしてくれる道具です。一方で、記録の対象はツールの入出力そのものなので、APIキーの伏せ字をオンにしてから使うのが前提だと考えています。 動画では、ここで書いた内容を図とアニメーションで8分にまとめています。 youtu.be ショート（Q1〜Q4の問い）はこちらです。 - 画面に出たAPIキー、AIの記憶に残る？ youtube.com - npmで入れたのに、AIが何も覚えない。なぜ？ youtube.com - AIの記憶づくり、使用量はタダ？ youtube.com - 上限まで残り5%、AIの記憶はどうなる？ youtube.com --- この記事で確認したこと・していないこと - 確認したこと：リポジトリを取得し、hooks.json の中身と、設定の初期値（src/shared/SettingsDefaultsManager.ts）、README・docs の記載を読みました（2026年11月2〜3日、v15.8.0〜v15.9.0）。 - していないこと：記憶の作成・差し込みの動作そのものは実行していません。トークン数や「約10倍の節約」などの数字は README・docs の記載です。 - 内容は2026年11月時点の情報です。設定の初期値は今後のバージョンで変わる可能性があります。 - 公式とは関係のない個人の紹介記事です。 出典 - claude-mem（GitHub）：thedotmack/claude-mem - 公式ドキュメント：docs.claude-mem.ai - 本文の根拠ファイル：README.md、plugin/hooks/hooks.json、src/shared/SettingsDefaultsManager.ts、docs/public/installation.mdx、docs/public/configuration.mdx、docs/public/usage/auto-redaction.mdx、docs/public/usage/private-tags.mdx、docs/public/usage/quota-fallback.mdx

Claude-MemはSIerで安全に使える？仕組みとプロジェクト間のメモリ分離をコードから調査 はじめに zenn.dev 異なるコーディングエージェントの情報を共有できるclaude-memというライブラリがあるみたいです。 Claude-Memは、コーディングAgentの作業履歴を自動収集し、AIで圧縮して、次のセッションで使えるようにするOSSです。 便利そうですが、セキュリティリスクは検討しないといけません。 同じ開発者が顧客Aと顧客Bの案件を並行して担当していたとき、顧客Aの設計やコードの情報が顧客BのAIの回答に紛れ込まないでしょうか。 本記事では仕組みを整理したうえで、「PJごとに記憶が分類される」ことと「PJをまたいで情報を読めない」ことの違いを中心に、ソースコードと公式ドキュメントからPJの案件情報が混在しないかを確認します。 結論 通常のセッション開始時のコンテキスト注入は、デフォルトでは現在のプロジェクトを対象にする。 保存先はローカルWorker構成の場合、同じOSユーザーの ~/.claude-mem/ 配下のSQLiteなど。複数PJの記録が同じ保存基盤に入る。 PJ名による絞り込みはアクセス権限ではない。 ローカルMCPの検索操作では project を省略でき、検索が他PJのデータに及ぶ経路がある。明示的に別PJを指定する操作も、企業のテナント認可としては扱われない。 共有の制御は存在する。 名前付きEnvironmentの inherit、クラウド同期、TeamBrainなどがある。ただし、それぞれ「同一端末内の検索範囲」「同一アカウントの端末間同期」「チームへの選択的共有」と意味が異なる。 受託開発での推奨は、顧客単位の実行環境・保存領域・外部通信を分けること。 通常開発は管理された既存PCまたはWindows 365、高機密案件では案件専用Azure VMなどを候補にする。設定で current や inherit: [] を指定しただけでは、厳密な顧客間分離の保証にならない。 1. Claude-Memは何を記憶しているのか Claude-MemはClaude CodeなどのライフサイクルイベントをHookで受け取り、作業の途中で発生した情報を整理して保存する「外付けの永続メモリ」です。 処理を大きく分けると次のようになります。 UserPromptSubmitで指示を、PostToolUseなどでファイル操作・コマンド実行・結果を収集する。 Workerが要約モデルを使って「どんな問題を解き、何を決定し、何を変更したか」をObservationとして圧縮する。 観測結果、セッション要約、ユーザープロンプトをSQLiteに保存する。FTS5でキーワード検索でき、Chromaを使えば意味検索もできる。 次のセッション開始時や検索要求時に、必要な過去情報をAIのコンテキストへ戻す。 検索は、まず短い結果一覧を取得し（search）、前後の経緯をたどり（timeline）、必要な記録だけ詳細取得する（get_observations）という段階的な方式です。すべての履歴を毎回LLMへ詰め込まない設計になっています。 ここで重要なのは、LLMに渡す情報を小さくすることと、保存されるデータが少ないことは同義ではないという点です。要約された記憶とは別に、プロンプトや作業由来の情報もローカルに残ります。 2. 「PJごとのメモリ」はどこで分離されているか ローカルWorker構成を、同一OSユーザーが複数の案件を扱う状況で考えてみます。 PJ単位のラベルやフィルターはありますが、PJごとに自動で独立したDBが作成されるわけではありません。 現行のローカルWorkerは、同じユーザーデータ領域に複数PJの記憶を保持できます。 2-1. プロジェクト名をどう決めるか 基本の識別方式はフォルダやGitリポジトリに基づきます。現行実装には次のルールがあります。 開発環境 主な識別方法 SIerでの注意 通常のGitリポジトリ Gitルートフォルダ名（標準のpathモード） 顧客が違っても同じフォルダ名なら衝突しうる Gitのoriginあり git-remoteモードなら org/repo フォルダ移動に強いが、ホスト名までは識別子に入らない Git worktree 親PJとworktreeを関連付け、親の記憶も読める ブランチ単位の完全分離ではない Git submodule 親PJ配下の識別子を使い、親の記憶も参照 サブモジュール単体の閉域を意味しない Git管理外 カレントディレクトリ名、マーカーファイル等 フォルダ名の重複や移動に注意 名前付きEnvironment パスのglobパターンにより指定名へ割り当て 複数のフォルダを意図的に同じメモリへまとめられる たとえば、二つの顧客案件のリポジトリがどちらも backend というフォルダ名なら、標準の命名では識別名が重複するリスクがあります。git-remote を利用すれば軽減できますが、異なるGitホスト上の同一 org/repo が区別されないケースも設計上考慮が必要です。 2-2. デフォルトの自動注入は「現在のPJ」 CLAUDE_MEM_CONTEXT_PROJECTS の標準値は current です。通常の SessionStart では、現在のcheckoutに対応する履歴を読み込むよう設計されています。all にすると複数PJを対象にしたコンテキスト注入が可能です。 つまり、何も設定しなければ全PJの全履歴が毎回AIに注入される、という仕様ではありません。 ただしこれは「どの情報を注入するか」の既定動作であり、アクセス制御ではありません。 同様に、CLAUDE_MEM_SESSION_START_INCLUDE_ALL_SOURCES=false は、Claude Code・Codexなど複数のハーネスをまたぐ自動注入を制限する設定です。これもユーザーや顧客ごとの閲覧権限を実現するものではありません。 2-3. 意外に重要：検索ではPJスコープが省略できる ソースコード上、ローカルWorker向けのMCP search / get_observations などは project が任意引数です。検索側はPJ条件が渡された場合にSQLの絞り込みを組み立てますが、渡されない場合はそのPJ条件を付けません。 さらに withCheckoutProjects() は、現在のcheckout名が明示的に指定された場合には継承キーを補完しますが、スコープ指定がない検索を強制的に現在のcheckoutへ閉じる関数ではありません。 そのため、次の二つは分けて評価する必要があります。 セッション開始時に「顧客Aの記憶だけが自動表示される」こと 顧客Aの環境から「顧客Bの記憶を検索・取得できない」こと 前者はデフォルト動作として期待できますが、後者をローカルWorkerのPJフィルターだけで保証するのは危険です。 同じユーザープロセスに対する操作を悪用したメモリ汚染や、誤った検索指示による情報の混入も想定すべきです。 この問題はGitHub Issue #3764 でも指摘され、より広いPJ識別・検索スコープの改善Issue #3608へ集約されています。旧版での指摘をそのまま現行版の脆弱性と断定するのではなく、最新コードでも任意のPJ指定を受け付ける経路があるという点を導入試験の対象にします。 3. 共有はどこまでできるのか 「共有」と一口に言っても、Claude-Memには少なくとも四つの異なる仕組みがあります。 仕組み 共有される範囲 標準動作・境界 同じPJ名・Git worktree 同一ユーザー内の関連PJ履歴 親の記憶などを引き継げる。認可境界ではない CLAUDE_MEM_PROJECT_ENVIRONMENTS 複数ディレクトリを共通PJ名にまとめる inheritで読み込む他PJのキーを選べる。検索権限とは別 Cloud Sync 同一cmem.aiアカウントの端末間 有効時はObservation・セッション要約・プロンプト等がSync Hubへ送信される TeamBrain チームメンバーが選んだPJ 共有するPJとbroadcastを選択。ローカルの個人作業ボードとは別 3-1. 名前付きEnvironmentによる「共通」と「個別」 たとえば次のように、案件ごとに名前付きEnvironmentを定義できます。 { "CLAUDE_MEM_PROJECT_ENVIRONMENTS": [ { "name": "customer-a-app", "patterns": ["~/work/customer-a/app/"], "inherit": [] }, { "name": "customer-b-app", "patterns": ["~/work/customer-b/app/"], "inherit": [] } ] } inherit: [] は、フォルダやGit名から自動導出された別の記憶キーをデフォルトの読み込み対象に含めず、そのEnvironmentの記憶を中心にする指定です。 反対に、承認済みの共通知識を読み込みたい場合、次のような構成も可能です。 { "name": "customer-a-app", "patterns": ["~/work/customer-a/app/**"], "inherit": ["shared-practices"] } これは「顧客Aの記憶 + shared-practices として保存した記憶」をデフォルトの参照対象にする考え方です。shared-practices の記録は別途、対応するPJ名として保存されている必要があります。 ただし公式ドキュメントにも、inherit はデフォルトのコンテキスト選択であってアクセス権限ではないと明記されています。 また過去に実施したPJのmergeは引き続き効く可能性があるので、設定変更だけで履歴が切り離されたと判断してはいけません。 3-2. TeamBrainは「すべて自動でチーム共有」ではない TeamBrainは、チームメンバーが共有するPJを選択し、作業リストや関連する発見を共有ワークスペースに表示する機能です。通常の個人用 My Work のレビュー記録がそのままチームへ統合される仕組みではありません。 実装では、共有するPJの選択が空配列なら「共有なし」、null なら「すべてのPJを共有」という区別が見られます。SIerでは「今後作る案件も含めてすべて共有」の設定を誤って選ばない運用が重要です。 一方、TeamBrainの選択共有を導入しても、元となる端末上のローカルWorkerにある全履歴の認可問題が自動的に解消するわけではありません。 3-3. Cloud Syncは個人の複数端末をまたぐ Cloud Syncを有効化すると、端末上の記憶はcmem.aiのSync Hubを通じて同期されます。公式仕様では、Observation、セッション要約、ユーザープロンプト、対応時の作業状態などが対象です。 複数の顧客案件が一つのユーザーデータ領域に保存されていれば、PJを意識しない個人端末間同期の扱いも検討が必要です。顧客Aから顧客Bへの自動注入を防いだとしても、記録のコピー先やデータ管理主体の問題は残ります。 4. SIerとしてどう評価するか 利用場面 判断 理由 公開OSS・学習用環境 導入候補 機密性の低いデータで有用性を検証できる 一般的な社内開発 条件付き 送信先・端末・保存データ・更新の制御が必要 同一開発者による複数顧客の受託開発 標準構成のままでは非推奨 PJフィルターと顧客のアクセス境界が一致しない 金融機関・高機密案件 厳格な隔離が前提 個別環境・通信制御・検証済み版・監査が必要 特に見落としやすいリスクは次のとおりです。 データ収集：プロンプトのほか、ツール入力・出力、エラー、変更背景に機密情報が含まれる。<private> タグは使えるものの、タグを付け忘れた情報の保護にはなりません。自動マスキングは標準で無効なので、有効化と精度検証が必要です。 外部送信：要約時にはAnthropic、Gemini、OpenRouter、CMEM Pro、任意のOpenAI互換エンドポイントなどの設定先へ情報が渡る可能性があります。ローカルSQLiteに保存していても、推論まで端末内で完結しているとは限りません。テレメトリもデフォルトで有効です。 ローカルAPIとログ：Workerは標準でループバックにバインドしますが、同じ端末の別プロセスやポート転送、ローカルに保存されるログ・設定ファイルまで含めて保護する必要があります。 Prompt Injection：不正な文章が記憶として取り込まれると、後のセッションのAIにとって「過去の文脈」に見える可能性があります。メモリは信頼されたシステム指示ではなく、検証可能な参考情報として扱う設計が必要です。 5. SIer向けの推奨構成：既存PC／Windows 365と案件専用Azure VMを使い分ける Claude-Memのメモリを「自動で検索できるように分類する」ことと、「別顧客の情報に技術的にアクセスできない」ことは異なります。そのため、守秘義務が異なる顧客案件間の分離は、メモリの検索条件ではなく、実行環境・OS権限・保存領域・ネットワークの境界で実現する方針が良さそうです。 5-1. 機密区分別の使い分け 利用シーン 推奨する開発環境 Claude-Memの扱い 主な確認事項 公開OSS・学習・低機密PoC 既存の会社管理PC（Windows＋WSL2など） ローカルで試験導入 外部通信、端末管理、ダミーデータでの検証 一般的な社内開発 既存の管理PC、またはWindows 365 Cloud PC チーム内の利用方針を定めて導入 Intune・Entra ID・条件付きアクセス、保存データ保護 通常の受託開発 顧客別に割り当てた管理PC／Windows 365、必要に応じてAzure VM 顧客ごとに保存先・認証情報・同期を分ける 複数顧客の同一Cloud PCへの混在を防ぐこと 銀行・高機密・閉域案件 顧客・案件専用Azure VM（WindowsまたはLinux）、要件によって専用VDI 専用ユーザー／VM／DBに限定。外部同期は原則無効 VNet・Private Endpoint、通信制御、ログ、破棄手順 多人数の集中管理VDIが必要 Azure Virtual Desktop（AVD）も比較対象 セッション分離と保存ボリューム分離を検証 マルチセッション時のユーザー間隔離、運用コスト Windows 365は管理された永続Cloud PCを提供し、IntuneやEntra IDと連携できる点が利点です。一方、厳格なネットワーク境界、Linuxネイティブの開発環境、案件別のリソース構成を細かく制御したい場合には、Azure VMのほうが設計しやすいことがあります。MicrosoftがWindows 365を推奨していることと、どのSI案件にもWindows 365が最適であることは同義ではありません。 5-2. 推奨アーキテクチャ この図では、AとBのメモリDBをそれぞれ別のVM内に置きます。個々のWorkerが同じローカルSQLiteを共有しないため、誤ってPJ指定を省略した検索が発生しても、別VMのDBには直ちにアクセスできません。もちろん、これはVM間の権限・ネットワーク・共有ストレージが適切に分離されていることが前提です。 実際の設計では、少なくとも以下の境界をそろえます。 実行・認証の境界：顧客ごとにOSユーザー、VM、SSH/RDPアクセス、Entra ID権限などを分離する。 データの境界：~/.claude-mem/（または CLAUDE_MEM_DATA_DIR の保存先）、ログ、ベクトルDB、バックアップ、認証情報を分離する。 通信の境界：モデルの要約送信先を許可済みのGateway／ローカル推論へ限定し、Cloud Sync、テレメトリ、未承認APIへの通信を制御する。 持ち出しの境界：案件間のメモリ同期やコピペによる移動を原則禁止し、共通化できる設計原則・障害対応手順だけをレビュー後に昇格させる。 なお、Claude-Memの外部通信を制限しても、本体のAIコーディングエージェントが使うLLMやGitHubなどの外部接続は別に管理する必要があります。さらにWindows 365を使う場合も、同じCloud PCで複数顧客案件を扱えばメモリ混在リスクは残ります。Cloud PCという製品名だけで自動的に顧客分離が実現するわけではありません。 5-3. 共通知識は「全PJの記憶を読ませる」のではなく、承認後に配布する 顧客間で再利用すべきなのは、実際の顧客名や内部API、ソースコード断片ではなく、レビューして一般化したテスト手法・設計原則・障害対応パターンなどです。CLAUDE_MEM_CONTEXT_PROJECTS=all や単一メモリDBへの集約で共有範囲を広げる代わりに、元データの守秘義務と持ち出し可否を人が確認してから共通ナレッジを作ります。 将来的に企業共通のAgent Memory基盤を作るなら、顧客・PJ・ユーザーの認可を備えたAPIを別途設け、アクセス権限と記憶の分類を独立して設計する方法が考えられます。 5-4. PoC向けの設定例 次は隔離した検証環境で、デフォルト注入と外部送信をできるだけ抑えて動作確認するための参考例です。 { "CLAUDE_MEM_CONTEXT_PROJECTS": "current", "CLAUDE_MEM_SESSION_START_INCLUDE_ALL_SOURCES": "false", "CLAUDE_MEM_WORKER_HOST": "127.0.0.1", "CLAUDE_MEM_CLOUD_SYNC_HUB_URL": "", "CLAUDE_MEM_REDACT_ENABLED": "true", "CLAUDE_MEM_REDACT_GENERIC_ENABLED": "true", "CLAUDE_MEM_PROJECT_ENVIRONMENTS": [ {"name": "customer-a-app", "patterns": ["~/work/customer-a/app/"], "inherit": []}, {"name": "customer-b-app", "patterns": ["~/work/customer-b/app/"], "inherit": []} ] } テレメトリは別途 DO_NOT_TRACK=1 または npx claude-mem telemetry disable で無効化できます。要約処理を社内推論に限定する場合は openai-compatible プロバイダーを承認済みのローカルまたは社内エンドポイントへ向け、外部へのフォールバックまで含めて通信制御で検証します。実稼働では共有DBに両案件を置くのではなく、上記の実行環境・データ保存先の分離を優先します。 ! このJSONは顧客間のセキュリティ境界を成立させる「完成済み設定」ではありません。inherit: [] は自動読み込みのスコープに関する設定であり、任意のMCP検索、ローカルDBへのアクセス、OS権限、クラウド同期済みデータなどを一括で遮断する機能ではありません。 6. 実際に検証したいテストケース 導入前には、公開情報の確認だけでなく、ダミーデータで越境検索を試すことを推奨します。 No. テスト 合格条件 1 顧客A・Bの二つのPJで異なるダミー記憶を作成 各記憶に想定どおりのPJ名が付く 2 Aのセッションを開始 Bの記憶が自動注入されない 3 Aの状態から search をPJ指定なしで実行 Bを取得できるなら、分離不足と判定する 4 get_observations にBの記憶IDを渡す Bの詳細を取得できるなら、分離不足と判定する 5 A・Bのリポジトリ名を同じにする PJ名の衝突を検出できる 6 worktree・submodule・inheritの組み合わせ 意図しない親・旧キーの記憶を読み込まない 7 EXCLUDED_PROJECTSを設定した後に検索 既存データの扱いを含め、期待した取得制限を確認する 8 Cloud SyncとTeamBrainの共有設定を変更 許可したデータだけが同期・共有される 9 架空のAPIキー・秘密文字列をツール出力に含める ローカルDB、ログ、外部リクエストで露出しない 10 AI推論先を遮断する 未承認の外部プロバイダーへ自動退避しない 11 顧客AとBを別VM／Cloud PCに配置し、AからBのメモリAPI・DBへアクセスを試す アクセスできない。共有マウントや共通バックアップにも抜け道がない 12 案件終了・担当者変更時にメモリDB、ログ、認証情報を棚卸しして破棄する 保持期間・削除証跡・クラウド同期の扱いを説明できる 以下はローカルDBのPJ別レコード件数を確認する例です。架空データのみを利用した隔離環境で実行してください。 sqlite3 ~/.claude-mem/claude-mem.db \ 'SELECT project, COUNT(*) FROM observations GROUP BY project ORDER BY project;' ローカルWorkerの実際のポートを確認したうえで、PJスコープなしの検索と、PJを指定した検索を比較できます。以下の文字列は架空の識別子です。 PORT=$(cat ~/.claude-mem/.worker.port) PJ名を渡さず検索 curl -sG "http://127.0.0.1:${PORT}/api/search" \ --data-urlencode 'query=BOUNDARY_CANARY_B' \ --data-urlencode 'limit=10' PJ Aに明示的に絞って検索 curl -sG "http://127.0.0.1:${PORT}/api/search" \ --data-urlencode 'query=BOUNDARY_CANARY_B' \ --data-urlencode 'project=customer-a-app' \ --data-urlencode 'limit=10' ポートファイルやAPIレスポンスの形式は採用版で確認してください。ここで見るべきなのは、スコープを省略した場合にどの範囲まで検索できるかです。検索でPJ Bが見えるなら、デフォルト注入がAに限定されていても顧客分離としては不十分です。 7. まとめ Claude-Memの「Hookで作業を記録し、LLMで圧縮し、検索して必要な文脈だけ再注入する」という設計は、AI駆動開発の継続性を改善するうえで有用です。Bun、SQLite、Chroma、MCPの組み合わせも、特殊なブラックボックスというより理解・検証可能な構成です。 Claude-MemにはPJ別の分類、選択的な履歴の読み込み、複数PJの意図的な共有、端末間同期、TeamBrainによるチーム共有が用意されています。しかし、ローカルWorkerのPJ指定は基本的に検索・コンテキスト選択の仕組みであり、顧客テナントの認可境界ではありません。 したがって、公開OSSや低機密の社内PoCでは試すのは良いが、複数顧客の機密案件に標準構成のまま横展開することはお勧めできません。 顧客単位でメモリ保存領域と実行環境を分け、承認済みの一般化されたナレッジだけを共通化する方法が現実的です。開発端末については通常開発なら管理された既存PCまたはWindows 365、高機密案件なら顧客専用Azure VMなどで分離することで根本的に混入をさせない構成になりそうです。 参考資料 Claude-Mem GitHub Architecture Overview 設定項目とProject Names PJ識別の実装: project-name.ts Environmentとinherit: project-environments.ts ローカルMCP: mcp-server.ts MCPのcheckoutスコープ: checkout-search-scope.ts 検索フィルター: SessionSearch.ts Cloud Sync TeamBrain Auto-Redaction Security Policy PJ識別・注入スコープ改善Issue #3608 PJ省略時のMCP検索に関するIssue #3764

لاعاد تشرح مشروعك من الصفر كل ما فتحت Claude Code 🦦 فيه ريبو مجاني اسمه claude-mem الاول في GitHub Trending اليوم و110K نجمة: 1- يحفظ ايش سوى الايجنت بالجلسة اللي قبل 2- يرجع له السياق المفيد لحاله 3- يشتغل مع Codex و OpenCode احفظها 🤓 thedotmack/claude-mem

Claude Code now has permanent memory 😳 Meet claude-mem (~110K stars) > Remembers your last coding session > Saves context for future sessions > Works with Claude Code, Codex, OpenCode and more try thedotmack/claude-mem t.co

t3code Tops GitHub Trending with 3,100 Stars Today What it is !pingdotgg/t3code t3code is the top repository on GitHub trending today, picking up 3,100 stars in a single day. That is more than double the next closest project on the list, and it happened with a repository description that is currently empty. The only signals available are the name, the organization behind it, and the star velocity. The pingdotgg organization is the same one behind the T3 stack ecosystem, which includes create-t3-app and the T3 Turbo monorepo. That context matters because it tells you what kind of codebase to expect: TypeScript-first, opinionated about tooling, and aimed at developers who already work in the React and Next.js world. But the repository itself does not yet ship a description, so anything beyond that is inference. Why it is getting attention The star count is the story. 3,100 stars in a day puts t3code well ahead of every other project on today's trending list. For comparison, claude-mem pulled 1,527, hex pulled 1,329, and Claude-Code-Game-Studios pulled 970. t3code more than doubled the runner-up. That kind of velocity usually means one of a few things. Either a well-known maintainer announced something publicly, a launch post linked here, or the repository is a placeholder that got shared before the actual code landed. The empty description supports the third possibility, though it is not proof. What is clear is that a large number of developers decided this repository was worth starring today, and the star count is the only concrete data point available. It is also worth noting what t3code is competing against on the same day. The rest of the trending list is dominated by AI tooling: persistent memory for coding agents, a headless browser built for automation, an offline speech-to-text app, a local voice dictation tool for three platforms, and an open-source security operations center that ships an MCP server. In that company, a repository with no description still leading the chart is unusual and suggests the T3 name carries real weight with its audience. Who should care Developers already using the T3 stack should watch this repository. If it turns out to be a new scaffolding tool, a runtime, or a component library, it will likely slot into the same workflow as create-t3-app and T3 Turbo. The organization has a track record of shipping tooling that people actually adopt, which is why the star count spiked before any documentation existed. Anyone evaluating TypeScript web tooling more broadly should also keep an eye on it, but with a caveat. Without a description, a README, or a release, there is not enough information to recommend adoption. Starring a repository is cheap. The useful next step is to wait for the maintainers to publish what the project actually does, then decide whether it fits your stack. If you are looking for something you can use today, the other entries on the trending list are more concrete. claude-mem has a clear description of persistent context across agent sessions. hex and Handy both ship offline voice input. AiSOC documents alert fusion and a replayable decision ledger. t3code, by contrast, is a signal without a payload, at least for now. The 3,100 stars are real. The project's purpose is not yet public. That gap is exactly why it is worth following rather than adopting. View the repository on GitHub

今日のGitHubトレンド thedotmack/claude-mem Claude Code向けの永続的メモリ圧縮システムです。 ツール使用時の情報を自動的に取得して要約し、セッション間でコンテキストを保存することで、セッション終了後や再接続後でもプロジェクトに関する知識の継続性を維持することを目的としています。

Trending repository of the day 📈 claude-mem Persistent Context Across Sessions for Every Agent – Captures everything your agent does during sessions, compresses it with AI, and injects relevant context back into... Last 24h: 1,723 ⭐ Total: 107,020 ⭐️ thedotmack/claude-mem