クロード・コードの流出ソースを読んだ。メモリーの実際の仕組みはこうだ
クロード・コードのソースコードが誤って公開されてしまった。バージョン2.1.88には59.8MBのソースマップファイルが含まれていた。その1つのファイルには、完全で読みやすいTypeScriptコードベース（512,000行）が含まれており、現在はGitHub全体でミラーリングされている。
メモリ・システムは私たちの注意を引いた。クロード・コードは、市場で最も人気のあるAIコーディング・エージェントであり、メモリは、ほとんどのユーザーがボンネットの中でどのように動作しているのかを理解せずに操作している部分である。そこで、私たちは掘り下げてみた。
簡単に説明しよう：クロード・コードのメモリは、想像以上に基本的なものだ。メモの上限は200行。もし「ポートの競合」について質問しても、メモに「docker-compose mapping」と書かれていれば、何も得られない。そしてクロード・コードから何も出てこない。別のエージェントに切り替えると、ゼロからのスタートとなる。
ここに4つのレイヤーがある：
- CLAUDE.md- クロードが従うべきルールを自分で書いたファイル。手動で、静的で、事前に書き留めようと思う量によって制限される。
- Auto Memory- セッション中にクロードが自分でメモを取る。便利だが、200行のインデックスが上限。
- オートドリーム- あなたがアイドルである間、乱雑な記憶を統合するバックグラウンドクリーンアッププロセス。数日前の雑然とした記憶を整理するのに役立つ。
- KAIROS- リークされたコードにあった未発表の常時稼働デーモンモード。公開ビルドにはまだない。
以下では、各レイヤーを紐解き、アーキテクチャが破綻している部分と、そのギャップに対処するために構築したものを取り上げる。
CLAUDE.mdはどのように機能するのか？
CLAUDE.mdはMarkdownファイルで、プロジェクトフォルダーに作成します。コードスタイルのルール、プロジェクトの構造、テストコマンド、デプロイ手順など、クロードに覚えておいてほしいことを何でも書き込むことができます。Claudeはセッションの開始時にこのファイルを読み込みます。
プロジェクトレベル（リポジトリルート）、個人用（~/.claude/CLAUDE.md ）、組織用（enterprise config）の3つのスコープがあります。短いファイルほど、より確実に追跡される。
CLAUDE.mdは、あなたが事前に書き留めたものだけを保持します。デバッグの決定事項、会話の途中で触れた環境設定、一緒に発見したエッジケースなど、あなたが立ち止まって手動で追加しない限り、どれも捕捉されません。ほとんどの人はそうしない。
オートメモリーの仕組み
Auto Memoryは、作業中に表面化したものをキャプチャします。クロードが保存する価値のあるものを判断し、ユーザー（役割と好み）、フィードバック（あなたの修正）、プロジェクト（決定とコンテキスト）、リファレンス（物事の保存場所）の4つのカテゴリーに整理して、あなたのマシン上のメモリー・フォルダーに書き込みます。
各ノートは個別のMarkdownファイルです。エントリーポイントはMEMORY.md 、各行が詳細ファイルを指す短いラベル（150文字以下）であるインデックスです。クロードはインデックスを読み、関連すると思われる特定のファイルを引っ張ってくる。
~/.claude/projects/-Users-me-myproject/memory/
├── MEMORY.md ← index file, one pointer per line
├── user_role.md ← "Backend engineer, fluent in Go, new to React"
├── feedback_testing.md ← "Integration tests must use real DB, no mocking"
├── project_auth_rewrite.md ← "Auth rewrite driven by compliance, not tech debt"
└── reference_linear.md ← "Pipeline bugs tracked in Linear INGEST project"
MEMORY.md sample (each line ≤150 chars):
- [User role](user_role.md) — Backend engineer, strong Go, new to React
- [Testing rule](feedback_testing.md) — No mocking the database in integration tests
- [Auth rewrite](project_auth_rewrite.md) — Compliance-driven, not tech debt
- [Bug tracker](reference_linear.md) — Pipeline bugs → Linear INGEST
MEMORY.mdの最初の200行がすべてのセッションに読み込まれる。それ以上は見えない。
一つの賢い設計の選択：リークされたシステム・プロンプトは、クロードに自分自身のメモリーを事実ではなくヒントとして扱うように指示する。これは、他のAIエージェントフレームワークが採用し始めているパターンである。
オート・ドリームはどのようにして古くなった記憶を統合するのか？
Auto Memoryはメモを取り込むが、何週間も使っているとそのメモは古くなる。昨日のデプロイのバグ」というエントリーは、1週間後には無意味になる。あるメモにはPostgreSQLを使っていると書いてあるが、新しいメモにはMySQLに移行したと書いてある。削除されたファイルにはまだメモリーが残っている。インデックスは矛盾と古い参照でいっぱいになる。
オート・ドリームはクリーンアップ・プロセスである。バックグラウンドで実行され
- 曖昧な時間参照を正確な日付に置き換えます。"昨日のデプロイ問題" → "2026-03-28のデプロイ問題"。
- 矛盾を解決します。PostgreSQL note + MySQL note → 現在の真実を保持します。
- 古いエントリを削除。削除されたファイルや完了したタスクを参照しているノートは削除されます。
MEMORY.mdを200行以下に保つ。
トリガー条件：最後のクリーンアップから24時間以上経過しており、かつ新しいセッションが5つ以上蓄積されている。dream "と入力して手動で実行することもできる。このプロセスは、バックグラウンドのサブエージェントで実行されます - 実際のスリープのように、アクティブな作業を中断することはありません。
ドリームエージェントのシステムプロンプトはこう始まる："あなたは夢を見ています-あなたのメモリーファイルに対する反射的なパスです。"
KAIROSとは？クロード・コードの未発表常時稼働モード
最初の3つのレイヤーはライブまたはロールアウトしている。リークされたコードには、出荷されていないものも含まれている：KAIROSだ。
KAIROSはギリシャ語で「正しい瞬間」を意味する言葉から名付けられたようだが、ソースには150回以上登場する。KAIROSは、Claude Codeをあなたが積極的に使用するツールから、あなたのプロジェクトを継続的に監視するバックグラウンド・アシスタントに変えるだろう。
リークされたコードに基づくと、KAIROSは以下のようになる：
- 一日中、観察、決定、行動の実行ログを保持する。
- タイマーでチェックイン。一定間隔でシグナルを受信し、行動するか静観するかを決定する。
- あなたの邪魔をしない。15秒以上あなたの邪魔になる行動はすべて延期される。
- ドリームクリーンアップを内部で実行し、さらにバックグラウンドで完全なobserve-think-actループを実行する。
- 通常のClaude Codeにはない特別なツールがある：ファイルをプッシュしたり、通知を送ったり、GitHubのプルリクエストを監視したり。
KAIROSはコンパイル時の機能フラグに隠れています。公開ビルドにはありません。Anthropicは、エージェントのメモリがセッション単位でなくなり、常時オンになったときに何が起こるかを探っているのだと考えてください。
クロードコードのメモリアーキテクチャはどこで破綻するのか？
Claude Codeのメモリは実際に動作する。しかし、5つの構造的な制限によって、プロジェクトが大きくなるにつれて処理できることが制限される。
| 制限 | 何が起こるか |
|---|---|
| 200行インデックス上限 | MEMORY.md 25KBを保持。何ヶ月もプロジェクトを運営すると、古いエントリーが新しいエントリーに押されてしまう。"先週はどんなRedis設定にしたっけ？"- がなくなる。 |
| Grepのみの検索 | メモリー検索では、リテラルなキーワードマッチを使う。あなたは "デプロイ時のポートの競合 "を覚えているが、メモには "docker-composeのポートマッピング "と書かれている。Grepはそのギャップを埋められない。 |
| 要約のみ、推論なし | Auto Memoryはハイレベルなメモを保存し、デバッグの手順やそこに至った理由は保存しません。どのようにしたかが失われる。 |
| 基礎を修正せずに複雑さを積み重ねる | CLAUDE.md → Auto Memory → Auto Dream → KAIROS。各層が存在するのは、最後の層が十分でなかったからだ。しかし、いくらレイヤーを重ねても、その下にあるものは変わらない：1つのツール、ローカルファイル、セッションごとのキャプチャ。 |
| メモリーはクロード・コードの中に閉じ込められている | OpenCode、Codex CLI、その他のエージェントに切り替えると、ゼロからのスタートとなる。エクスポートも、共有フォーマットも、移植性もありません。 |
これらはバグではありません。シングルツール、ローカルファイルアーキテクチャの自然な限界なのです。毎月新しいエージェントが出荷され、ワークフローは変化しますが、プロジェクトで蓄積した知識は、それらと一緒に消えてはいけません。それが、memsearchを開発した理由です。
memsearchとは？あらゆるAIコーディング・エージェントのための永続的なメモリ
memsearchはエージェントからメモリを取り出し、独自のレイヤーに格納します。エージェントは行ったり来たりします。メモリは残ります。
memsearchのインストール方法
Claude Codeユーザーはマーケットプレイスからインストールします：
/plugin marketplace add zilliztech/memsearch
/plugin install memsearch
完了。設定不要。
他のプラットフォームも同様に簡単。OpenClaw:openclaw plugins install clawhub:memsearch.uv または pip 経由の Python API：
uv tool install "memsearch[onnx]"
memsearch は何を捕捉するのか？
一度インストールすると、memsearch はエージェントのライフサイクルにフックします。すべての会話は自動的に要約され、インデックス化されます。履歴が必要な質問をすると、リコールが勝手にトリガーされます。
メモリーファイルは、日付付きMarkdownとして保存されます：
.memsearch/
└── memory/
├── 2026-03-28.md ← one file per day
├── 2026-03-29.md
├── 2026-03-30.md
└── 2026-04-01.md
どのテキストエディタでもメモリーファイルを開き、読み、編集することができます。移行したい場合は、フォルダをコピーする。バージョン管理が必要な場合は、gitがネイティブで動作する。
Milvusに保存されているベクターインデックスはキャッシュレイヤーであり、万が一失われた場合は、Markdownファイルから再構築します。あなたのデータはインデックスではなく、ファイルに保存されています。
memsearchはどうやってメモリーを見つけるのか？セマンティック検索とGrepの比較
クロード・コードの記憶検索では、grep（リテラル・キーワード・マッチング）を使っています。これは数十のメモがあるときには有効ですが、数ヶ月の履歴があり、正確な表現を思い出せないときには破綻します。
memsearchは代わりにハイブリッド検索を使う。セマンティック・ベクトルは言い回しが異なっていてもクエリに関連するコンテンツを見つけ、BM25は正確なキーワードにマッチする。RRF（Reciprocal Rank Fusion）は、両方の結果セットをマージし、一緒にランク付けします。
例えば、"先週のRedisのタイムアウトはどのように修正されましたか？"と質問したとします。- セマンティック検索は意図を理解し、それを見つける。例えば、"search forhandleTimeout" - BM25は正確な関数名をヒットします。この2つの経路はお互いの死角をカバーする。
リコールがトリガーされると、サブエージェントは3段階で検索を行い、必要なときだけさらに深く検索を行う：
L1: 意味検索 - 短いプレビュー
サブエージェントはmilvusインデックスに対してmemsearch search 、最も関連性の高い結果を引き出す：
┌─ L1 search results ────────────────────────────┐
│ │
│ #a3f8c1 [score: 0.85] memory/2026-03-28.md │
│ > Redis port conflict during deploy, default │
│ 6379 occupied, switched to 6380, updated │
│ docker-compose... │
│ │
│ #b7e2d4 [score: 0.72] memory/2026-03-25.md │
│ > Auth module rewrite complete, JWT replaced │
│ with session tokens, mobile token refresh │
│ was unreliable... │
│ │
│ #c9f1a6 [score: 0.68] memory/2026-03-20.md │
│ > DB index optimization, added composite │
│ index on users table, query time dropped │
│ from 800ms to 50ms... │
│ │
└─────────────────────────────────────────────────┘
各結果は関連性スコア、ソースファイル、200文字のプレビューを表示する。ほとんどのクエリはここで終了する。
L2:フルコンテキスト - 特定の結果を展開する
L1のプレビューだけでは不十分な場合、サブエージェントはmemsearch expand a3f8c1 、完全なエントリーを引き出します：
┌─ L2 expanded result ───────────────────────────┐
│ │
│ ## 2026-03-28 Deploy troubleshooting │
│ │
│ Redis port conflict resolution: │
│ 1. docker-compose up → Redis container failed │
│ 2. Host port 6379 occupied by another instance │
│ 3. Changed docker-compose.yml: "6380:6379" │
│ 4. Updated .env: REDIS_PORT=6380 │
│ 5. Updated config/database.py connection │
│ │
│ Note: Only affects local dev. Prod unaffected. │
│ │
│ [source: memory/2026-03-28.md lines: 42-55] │
└─────────────────────────────────────────────────┘
L3: 生の会話記録
何を言われたかを正確に確認する必要がある場合、サブエージェントはオリジナルのやり取りを取り出します：
┌─ L3 raw transcript ───────────────────────────┐
│ │
│ [user] docker-compose up won't start, Redis │
│ port conflict — can you take a look? │
│ │
│ [agent] Checking host port usage... │
│ Running lsof -i :6379... │
│ Suggest remapping to port 6380... │
│ (tool_call: Bash "lsof -i :6379") │
│ (tool_call: Edit "docker-compose.yml")│
│ │
│ [user] Done. Anything else to update? │
│ │
│ [agent] Also need to update .env and │
│ database.py... │
│ │
└────────────────────────────────────────────────┘
トランスクリプトは、あなたの正確な言葉、エージェントの正確な応答、すべてのツールコールのすべてを保存します。3つの段階は、軽いものから重いものまであり、サブエージェントがどの程度深く掘り下げるかを決定し、整理された結果をメインセッションに返します。
memsearchはどのようにAIコーディングエージェント間でメモリを共有するのか？
これがmemsearchとClaude Codeのメモリの最も根本的なギャップだ。
クロードコードのメモリは一つのツールの中に閉じ込められている。OpenCode、OpenClaw、Codex CLIを使えば、ゼロから始めることになる。MEMORY.mdはローカルで、一人のユーザーと一人のエージェントに縛られています。
memsearchは4つのコーディングエージェントをサポートしている：Claude Code、OpenClaw、OpenCode、Codex CLIです。これらは同じMarkdownメモリーフォーマットと同じmilvusコレクションを共有しています。どのエージェントから書き込まれたメモリも、他のすべてのエージェントから検索可能です。
つの実際のシナリオ
ツールの切り替えあなたは、デプロイパイプラインを理解するためにクロードコードで午後を過ごし、いくつかの問題にぶつかりました。会話は自動要約され、インデックス化されます。翌日、OpenCodeに切り替えて、"昨日のポートの衝突はどうやって解決したんだっけ？"と質問する。OpenCodeはmemsearchを検索し、昨日のClaude Codeの記憶を見つけ、正しい答えを教えてくれる。
チームコラボレーション。MilvusのバックエンドをZilliz Cloudに向けると、複数の開発者が異なるマシンで異なるエージェントを使い、同じプロジェクトのメモリを読み書きします。新しいチームメンバーが加わっても、Slackやドキュメントを何ヶ月も読み込む必要はありません。
開発者API
独自のエージェントツールを構築する場合、memsearch は CLI と Python API を提供します。
CLI
# Index markdown files
memsearch index ./memory
# Search memories
memsearch search “Redis port conflict”
# Expand a specific memory’s full content
memsearch expand a3f8c1
# Watch for file changes, auto-index
memsearch watch ./memory
# Compact old memories
memsearch compact
Python API：
from memsearch import MemSearch
mem = MemSearch(paths=[“./memory”])
await mem.index() # index markdown
results = await mem.search(“Redis config”) # hybrid search
await mem.compact() # compact old memories
await mem.watch() # auto-index on file change
milvusはベクター検索を扱います。Milvus Lite(設定不要)でローカルに実行するか、Zilliz Cloud(無料ティアあり)を使ってコラボレーションするか、Dockerを使ってセルフホストする。エンベッディングのデフォルトはONNX - CPUで動作し、GPUは不要。OpenAIやOllamaといつでも交換可能。
クロード・コード・メモリとmemsearchの比較：完全比較
| 特徴 | クロードコードメモリ | memsearch |
|---|---|---|
| 何が保存されるか | クロードが重要視するもの | すべての会話を自動要約 |
| ストレージの制限 | ~200行インデックス (~25 KB) | 無制限（毎日のファイル＋ベクターインデックス） |
| 古い記憶の検索 | Grepキーワードマッチ | 意味ベース＋キーワードのハイブリッド検索 (Milvus) |
| 読めるか？ | メモリフォルダを手動でチェック | 任意の.mdファイルを開く |
| 編集できるか？ | 手動でファイルを編集 | 同じ - 保存時に自動再インデックス |
| バージョン管理 | 設計されていない | gitはネイティブに動作する |
| クロスツールサポート | クロードコードのみ | 4エージェント、共有メモリ |
| 長期リコール | 数週間で劣化 | 数ヶ月間持続 |
memsearchを始めよう
クロード・コードの記憶には、自己懐疑的なデザイン、夢の統合コンセプト、KAIROSの15秒間のブロック予算など、本当の強みがある。Anthropicはこの問題について懸命に考えている。
しかし、単一ツールのメモリーには限界がある。ワークフローが複数のエージェント、複数の人々、あるいは数週間以上の履歴にまたがると、それ自体が存在するメモリが必要になる。
- memsearchを試してみよう - オープンソース、MITライセンス。クロードコードに2つのコマンドでインストールできます。
- memsearchがどのように動作するかは、Claude Codeプラグインガイドを参照してください。
- 質問がありますか？MilvusのDiscordコミュニティーに参加するか、無料のオフィスアワーセッションをご予約ください。
よくある質問
Claude Codeのメモリシステムはどのように動作しますか？
Claude Codeは4層のメモリアーキテクチャを使用しており、全てローカルのMarkdownファイルとして保存されています。CLAUDE.mdはあなたが手動で書く静的ルールファイルです。Auto Memoryは、セッション中にClaude自身のメモを保存し、ユーザーの好み、フィードバック、プロジェクトのコンテキスト、参照ポインタの4つのカテゴリーに整理します。Auto Dreamは、バックグラウンドで古くなった記憶を統合する。KAIROSは、流出したソースコードから見つかった未発表の常時稼働デーモンである。システム全体の上限は200行のインデックスで、検索可能なのはキーワードの完全一致のみである。
AIコーディング・エージェントは、異なるツール間でメモリを共有できるのか？
ネイティブではない。クロード・コードのメモリはクロード・コードにロックされており、エクスポート・フォーマットやエージェント間のプロトコルはありません。memsearchは、ベクターデータベース（milvus）にインデックスされた日付入りのMarkdownファイルとしてメモリを保存することで、この問題を解決しています。サポートされている4つのエージェントは全て同じメモリストアを読み書きするため、ツールを切り替えてもコンテキストは自動的に移行します。
エージェントメモリのキーワード検索とセマンティック検索の違いは何ですか？
キーワード検索(grep)は正確な文字列にマッチします - メモリに "docker-compose port mapping "と書かれていても、"port conflicts "と検索すると何も返されません。memsearchはハイブリッド検索で両方のアプローチを組み合わせ、1つのクエリで意味ベースのリコールと正確なキーワード精度を提供する。
クロード・コードのソースコード流出事件で何が流出したのか？
クロードコードのバージョン2.1.88は、59.8MBのソースマップファイルと共に出荷されました。このファイルには、完全なメモリシステムの実装、Auto Dreamのコンソリデーション処理、未発表の常時稼働エージェントモードであるKAIROSへのリファレンスを含む、約512,000行に及ぶ可読のTypeScriptコードベースが含まれていた。このコードは、削除される前にすぐにGitHubにミラーされた。
Try Managed Milvus for Free
Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.
Get StartedLike the article? Spread the word
