RAGの先にある「AIの記憶」設計 — Obsidian×Claude Codeで実装した話

「ベクトルDBを入れたから記憶はOK」の落とし穴

AIアプリケーションを作る際、最初にぶつかる壁が「どうやってAIに自社の情報を覚えさせるか」です。多くの人がRAG（検索拡張生成）に辿り着きます。ドキュメントをベクトル化して、質問に関連する情報を検索して、それをプロンプトに突っ込む。自分も以前、RAGの基礎記事を書きました。

でも、RAGを実装した後に気づくことがあります。検索はできるけど、AIが「覚えている」感じがしない。

前回の会話で話した内容を次のセッションで忘れている。ユーザーの好みや文脈が蓄積されない。毎回ゼロから説明し直す必要がある。これは、RAGが解決する問題と「記憶」が解決する問題が根本的に違うからです。

RAGとAI Memoryは別のコンポーネント

この問題を明快に整理した記事が最近Zennに公開されました。「AI Memory vs RAG」と題した記事で、著者の主張はシンプルです。

RAGは「外部知識の検索」、AI Memoryは「動的な状態の持続」。両者は代替関係ではなく、役割が根本的に違う。

具体的に比較するとこうなります。

RAGが扱うのは、マニュアル、FAQ、論文といった比較的静的な外部知識です。「このドキュメントの中から関連する部分を見つけてきて」という検索の仕事です。

AI Memoryが扱うのは、ユーザーの好み、タスクの進捗、過去の判断とその理由といった動的に変化する状態です。「このユーザーは前回こう言っていた」「この判断は以前うまくいかなかった」という文脈の仕事です。

RAGだけでは、AIはどれだけ優秀な「検索付きチャットボット」にしかなれません。ユーザーとの関係を築く「エージェント」になるには、別のレイヤーが必要です。

自分のシステムでの実装

自分はこの1年ほど、Obsidian VaultとClaude Codeを組み合わせた知識管理システムを日常的に使っています。振り返ると、意図せずRAGとMemoryの分離を実現していました。

RAG的な層: Obsidian Vault

Obsidian Vaultには、外部から取り込んだ知識が蓄積されています。

• LiteratureNote — 読んだ論文や記事の要約
• Digest — 毎日のニュースダイジェスト（PubMed、RSS、Semantic Scholar）
• Resources — 技術メモ、リファレンス

これらは基本的に「書いたら変わらない」静的な知識ストックです。Claude Codeが仕事をするとき、必要に応じてこれらのノートを検索して参照します。従来のRAGと同じ構造です。

Memory的な層: Claude Code memory

一方で、Claude Codeには独自のmemoryシステムがあります。.claude/projects/*/memory/配下にMarkdownファイルとして保存される仕組みで、記憶には型があります。

• user — ユーザーの役割、スキル、好み（「TypeScript歴は長いがReactは初心者」等）
• feedback — 過去のフィードバック（「テストではDBをモックしない」「PRは不要、直接push」等）
• project — プロジェクトの動的な状態（「来週リリースフリーズ」「認証リファクタは法務要件」等）
• reference — 外部リソースへのポインタ（「バグトラッカーはLinearのINGESTプロジェクト」等）

これらは毎回の対話で更新される動的な状態です。「前回のセッションで学んだこと」が次のセッションに引き継がれます。

両者が連携する瞬間

面白いのは、この2つの層が連携して動く場面です。

毎朝のDaily Digestを例に取ります。Claude Codeがダイジェストを作成するとき、まずmemoryから「自分が今どんなプロジェクトに取り組んでいるか」を読み込みます。精密栄養PoC、AI講師事業、Google Cloud関連 — これらの文脈を把握した上で、RSSやPubMedから取得した最新記事をトリアージします。

「この論文はGLP-1作動薬のpolyagonist approachについて。精密栄養PoCに関連するので🔴必読」

memoryがなければ、全記事をフラットに並べるだけです。memoryがあるから、自分にとって何が重要かを判断できる。これが、RAG単体では実現できない「記憶」の価値です。

記憶の型を分けることの意味

Claude Codeのmemoryシステムで特に効いているのが、記憶を型で分類している設計です。

feedbackメモリが特に強力です。例えば、自分は以前「テストでデータベースをモックしないで」と指示しました。理由は「モックとプロダクションの乖離でマイグレーションが壊れた」から。このフィードバックがmemoryに保存されると、次回以降のセッションでは何も言わなくても実DBを使ったテストを書いてくれます。

重要なのは、理由（Why）も一緒に保存していることです。「DBをモックしない」というルールだけだと、例外的にモックが適切な場面でも頑なに避けてしまいます。理由があれば「この場面はモック/プロダクション乖離のリスクがないからモックでOK」と判断できます。

projectメモリは鮮度が命です。「来週リリースフリーズ」という情報は1週間後には陳腐化します。だから相対日付ではなく絶対日付（「2026-03-05からフリーズ」）で保存し、期限切れの情報は定期的に棚卸しします。

まだ解決できていないこと

正直に書くと、このシステムにはまだ弱点があります。

記憶のポータビリティがない。 Claude Code以外のAIツールに記憶を持ち越せません。ChatGPTに相談するときは、文脈をゼロから説明し直す必要があります。理想的には、記憶がモデルやツールに依存しない共通フォーマットで保存され、どのAIエージェントからもアクセスできるべきです。

記憶の整合性管理が手動。 memoryに「精密栄養PoCはフェーズ1」と書いてあっても、実際にはフェーズ2に進んでいる可能性があります。今は「memoryを読んだら現在のコードやファイルと照合して、古ければ更新する」というルールを設けていますが、完全には機能していません。

記憶の量が増えたときのスケーリング。 今はMEMORY.mdというインデックスファイルが200行以内に収まっていますが、1年後、3年後にどう管理するかは未知数です。重要度による自動アーカイブの仕組みが必要になるかもしれません。

結局、何をすべきか

AIアプリケーションの記憶設計で大事なのは、最初に「RAGで十分か、Memoryが必要か」を見極めることです。

RAGだけで十分なケース:

• 一問一答型のQ&Aボット
• ドキュメント検索・要約ツール
• ステートレスなタスク実行

Memoryが必要なケース:

• ユーザーとの長期的な関係を持つアシスタント
• 複数セッションにまたがるプロジェクト作業
• 過去の判断から学習するエージェント

そして多くの実用的なシステムでは、両方が必要です。RAGで外部知識を検索し、Memoryでユーザー文脈を維持し、両者を組み合わせてパーソナライズされた応答を生成する。

自分のObsidian Vault + Claude Codeの仕組みは、まだ発展途上ですが、この「両層分離」の設計が日常的に機能している実例です。RAGの次のステップとして、AIの記憶設計について考えてみる価値はあると思います。