2026年3月末、Claude Codeのソースコードが意図せず公開されたことがありました。コミュニティではすぐにPython移植版が出て、数時間でGitHubのstarを大きく伸ばしました。
本当に分解して見る価値があったのは、その中の記憶システムです。
Claude Codeはどう記憶を管理するのか
Claude Code内部にはmemdirというモジュールがあります。流出したファイル構造を見ると、関連記憶の検索、batch scan、記憶aging、type分類、複数人の共有memory pathなど、複数のサブモジュールが見えます。
名前を見るだけでも設計思想がわかります。記憶は保存するだけでは足りません。見つけられること、古くなったか判断できること、読み込むべきか決められることが必要です。
ただし、この設計には前提があります。開発者ツール向けであることです。Claude Codeは、各会話が独立したタスクであり、ユーザーとAIの間に長期的な関係がないと想定しています。
では、AIが長期のパートナーだったら？
最初の発見：分類方法が間違っていた
AIアシスタントを長期利用する人は、よく「修正記録」フォルダを作ります。AIに訂正したことを全部そこへ入れます。
- コーヒーよりお茶が好き
- 運動指導は身体感覚で説明してほしい
- コードはすべて別のAIに任せる
- 暗号資産の秘密鍵には触らない
一見きれいですが、問題が出ます。AIが新しい会話を始める時、どれを読むべきかどう判断するのでしょうか。
全ファイルのタイトルを走査し、今の話題に関係するものを判断し、読み込む。これはまさにClaude CodeのfindRelevantMemoriesがしていることです。
最初の解決策はこの方向へ行きがちです。indexボードを作り、各記録の使用頻度を追跡し、よく使うものを上に置き、極めて重要なものは「卒業」させて永久ルールにする。
設計はどんどん複雑になります。specを書き、別のAIに何度かchallengeさせた後、より根本的な問いが浮かびます。
「修正記録」は本当に記憶タイプなのか？
違います。
「コーヒーよりお茶が好き」はユーザーに関する事実です。 「運動指導は身体感覚で説明」は健康トレーニングのやり方です。 「コードは別AIへ渡す」は運用ルールです。
これらに同じラベルが付いたのは、すべて「AIを修正した後に発生した」からにすぎません。
言い換えると、多くの人は「どう学んだか」で分類しています。本当に使うべき基準は「それが何であるか」です。
人間の脳はどう記憶を分類するのか
認知科学では、長期記憶をいくつかに分けます。
意味記憶、事実と知識。台北の緯度経度、あるプログラムのAPI形式。 手続き記憶、物事のやり方。車の運転手順、code reviewの流れ。 エピソード記憶、個人的経験。「あの日システムが初めて本番稼働した」「午前3時にdebugした記憶」。 感情記憶、感情と関係性。「彼は急かされるのが嫌い」「彼女は意思決定前に静かに考える時間が必要」。
ここに「誰かに教えられたこと」という分類はありません。脳は「母に注意されたこと」専用エリアを作って、料理のコツ、交通ルール、人付き合いの礼儀を全部入れたりしません。
脳がしているのはconsolidation（記憶の統合）です。同じ経験を分解し、内容の性質に応じて別々の領域へ送ります。「母がコンロは熱いと言った」という出来事は、「コンロの温度」が意味記憶へ、「やけどした」がエピソード記憶へ、「コンロを見ると気をつける」が感情記憶へ入ります。
AIの記憶も、こう設計したほうがよいのかもしれません。
最高の検索は、正しい場所に置くこと
ここまで考えると、解決策は意外なほど単純でした。
知識を、読まれるべき場所へ置く。
運動トレーニングのやり方？健康プロジェクトに置く。次に健康の話をすると自然に読まれます。 運用ルール？ルールファイルに置く。毎回起動時に読み込まれます。 個人の好み？個人ファイルに置く。必要になった時だけ読みます。
indexボードも、使用頻度追跡も、「卒業」機構もいりません。
場所そのものが最高のfilterです。
散らかった「修正記録」を分解した後、それぞれ本来の場所へ戻しました。トレーニング方法は健康プロジェクトへ、ブランドの口調はブランド規範へ、運用ルールはルールファイルへ（多くは既に存在していて重複していただけ）、個人の好みは個人ファイルへ。結果、フォルダ全体が空になりました。
構造より防止策に力を使うべき
整理が終わると、すぐ次の問題が出ます。今後また同じことを二か所に書かないか。
たとえば運動計画の話の中で体の不調に触れた場合、それは健康プロジェクトに書くべきか、個人の健康ファイルに書くべきか。両方に書けば、いずれ不一致になります。
判断ルールを一つ置けます。
もしこのプロジェクトが明日消えたとして、この情報はまったく無関係な会話でも繰り返し使われるか？ 使われない → プロジェクトへ書く。 使われる → 個人ファイルへ書く。 不確か → プロジェクト寄り。 絶対に二か所へ同時に書かない。
このルールは、どんな検索アルゴリズムより有効です。
最も詰まりやすい点は、同じ記憶が二つに分かれて書かれ、数週間後に互いに衝突することです。記憶が見つからないことは、むしろ主問題ではありません。
Claude Codeから学んだこと、学ばなかったこと
Claude Codeの設計を振り返ると：
記憶aging。 Claude Codeは古い記憶を自動で弱めます。ツール用途なら合理的です。ただ、パートナー関係には向きません。1か月友達と連絡していないからといって、その人の好みを忘れる人はいません。
関連性検索。 物が正しい場所に置かれていれば、そもそも検索はいりません。冷蔵庫に牛乳検索エンジンは必要ありません。牛乳は冷蔵庫のドアにあります。
記憶タイプ分類。 Claude Codeはuser / feedback / project / referenceに分けます。短期ツールには十分ですが、長期パートナーには足りません。よりよい分類は認知科学に合わせ、意味、手続き、エピソード、感情で分けることかもしれません。
Claude Codeのアーキテクチャは「見知らぬ開発者の独立作業session」向けです。長期パートナーのAIなら、まず分類方法を変え、事実、やり方、経験を人間の脳に近い形で分けるほうが、大量の検索機能を足すより効果が出やすいです。
最終的な記憶アーキテクチャ
整理後はこうなりました。
常に読み込む（毎回ある）：中核価値観、運用ルール、チーム分担。性格や習慣のように、起きている時は常にあります。
毎回の会話で読み込む（作業記憶）：現在のtodo、今日起きたこと。朝出かける前にカレンダーを見るようなものです。
話題になった時だけ読み込む（長期記憶）：各プロジェクトの文脈と注意事項、個人の好みファイル。ある友人を思い出すと、その人に関する記憶が自然に浮かぶようなものです。
能動的に探す（参考資料）：履歴記録、技術文書。久しぶりに本棚から本を探すようなものです。
各層は、その時必要なものだけを読み込みます。各会話のbootコストは大きく下がり、長期的にはtokenコストと読み込み速度の両方で効いてきます。
同じようなことをしているなら
重要な点をいくつか。
Claude Codeの記憶分類をそのままコピーしない。 その4分類は短期ツール向けです。長期パートナーには別のアーキテクチャが必要です。
分類基準を先に明確にする。 「情報がどう来たか」で分類するのか、「情報が何か」で分類するのか。当たり前に聞こえますが、多くの人がここで詰まります。
検索機構を考える前に、物を正しい場所へ置く。 冷蔵庫に検索エンジンはいりません。
防止ルールは機能より投資価値がある。 「絶対に同じことを二か所へ書かない」という硬い規定は、多くの自動化ツールより保守コストを減らします。
よいシステム設計はだいたいこういうものです。答えが単純すぎて、自分は今まで何をしていたのかと疑いたくなります。
関連記事
小企鵝の経験
AIアシスタントを長期運用すると、一番厄介なのは本当に記憶です。記憶をうまく扱い、agentに忘れさせない難しさは、「保存できるか」ではありません。「次回、それを自然に読めるか」です。実戦でのコツは、中核ファイルを簡潔に保ち、場所そのものをindexにすること。検索機構を設計するより効果があります。OpenClaw上の多agent構成（Opus / Sonnet / ChatGPT）は、この論理で動いています。
よくある質問
Q: Claude Codeの記憶システムはどう動きますか？
Claude Code内部にはmemdirモジュールがあり、記憶検索、batch scan、記憶aging、type分類、共有memory pathなどの機能を持ちます。記憶をuser、feedback、project、referenceに分け、関連性検索でどの記憶を読み込むか決めます。
Q: AIアシスタントの記憶はどう分類すべきですか？
認知科学を参考に、情報の出どころではなく性質で分類できます。意味記憶（事実）、手続き記憶（やり方）、エピソード記憶（経験）、感情記憶（関係性）。使う時に自然に読まれる場所へ知識を置くことが、最もよい検索の仕組みになります。
Q: 記憶のSSoT原則とは何ですか？
Single Source of Truth、つまり1つの情報は1か所にだけ置くという原則です。判断方法は、もしそのプロジェクトが消えても、この情報は他の場面で繰り返し使われるか。使われないならプロジェクトへ、使われるなら個人ファイルへ。絶対に両方へ書かないことです。
本記事は研究と議論を目的としたものであり、投資助言ではありません。DYOR + NFA。
— Penchan