Obsidian VaultをAIエージェントの「育つ記憶」にする方法 — エージェントメモリの最新実装ガイド
この記事は調査レポートです。るなちゃん(Luna-chan)が、Hermes AgentというAIエージェントフレームワークの運用者としての実体験と、外部の研究データ・事例を組み合わせてまとめています。
2026年に入ってから、AIエージェントの「記憶(メモリ)」に関する議論が急に熱を帯びてきた。
Hacker NewsではUniversal Memory Protocol(31ポイント)、GoogleはAgent Memoryのホワイトペーパーを発表、Mem0はエージェントメモリの統一ベンチマークレポートを公開した。QiitaやZennでも「claw-memory」や「Obsidian × arscontexta」といった日本語記事が29〜40likesを集めている。
同時に気になるのが、これらの話題の多くが「Obsidian」という単語と一緒に出てくることだ。なぜプログラマーのメモツールが、AIエージェントの記憶設計の文脈で語られるのか。
この記事では、2026年春〜夏のエージェントメモリ事情を整理した上で、Obsidian VaultをAIエージェントと共有する設計について、具体的な実装パターンと運用の知見をまとめる。
AIエージェントに「記憶」が必要な理由
AIエージェントの基盤となるLLMは、本質的にステートレスだ。1回の呼び出しごとに状態はリセットされ、直前の会話さえも「次にコンテキストとして渡す」ことでしか保持できない。
Damian Galarza氏の記事(2026年2月)はこの問題を端的に表現している:
「ストレージは簡単な部分だ。難しいのは『いつ書き込むか』と『いつ読み込むか』を見極めること。それができれば、あとは単なるファイル操作になる」
まさにここが核心だ。いくら高性能なデータベースを用意しても、「何を覚えさせて、いつ思い出させるか」の設計なしには、エージェントは毎回「初めまして」のまま動き続ける。
3種類のエージェントメモリ
Googleが2025年11月に公開したAgent Memoryのホワイトペーパーは、エージェントメモリを以下の3つに分類している:
| タイプ | 説明 | 具体例 |
|---|---|---|
| エピソード記憶(Episodic) | 過去の出来事や相互作用 | 「前回のセッションで何をデバッグしたか」 |
| セマンティック記憶(Semantic) | 事実や好み | 使っている技術スタック、コード規約 |
| 手続き記憶(Procedural) | ワークフローや学習済みルーティン | デプロイ手順、テストパターン、PRのチェックリスト |
この3つをうまく組み合わせるのが理想だが、実装上で最大の課題は「抽出」と「正確性」にある。会話から何を記憶に残し、何を捨てるか。そして時間とともに古くなった情報をどう更新するか。
2026年のエージェントメモリ、4つの重要な動き
1. ベンチマークの標準化(Mem0, 2026年4月)
Mem0のエンジニアリングチームが公開した「State of AI Agent Memory 2026」レポートは、エージェントメモリの評価に3つのベンチマーク(LoCoMo, LongMemEval, BEAM)を導入し、統一された評価軸でメモリアーキテクチャの性能を測定している。
Mem0の2026年4月時点のスコア:
| ベンチマーク | スコア | クエリあたりの平均トークン数 |
|---|---|---|
| LoCoMo(1,540問) | 92.5 | 6,956 |
| LongMemEval(500問) | 94.4 | 6,787 |
| BEAM(1Mトークン) | 64.1 | 6,719 |
| BEAM(10Mトークン) | 48.6 | 6,914 |
特に注目したいのは、前年比で時間的推論(temporal reasoning)で+29.6ポイント、マルチホップ推論で+23.1ポイントの改善があった点だ。これは「前に何を話したか」だけでなく、「そのときの状況はどうだったか」を考慮した検索が可能になったことを示す。
品質向上の鍵は2つのアーキテクチャ変更にある:
- 単一パスの追加専用抽出(Single-pass ADD-only extraction) — エージェントが生成した事実(確認事項や推奨事項など)を正式な記憶として扱う
- マルチシグナル検索(Multi-signal retrieval) — 意味的類似性・キーワード一致・エンティティ一致の3つのスコアを並行実行し、統合する
2. フレームワークの乱立と統合の動き
エージェントメモリのフレームワークは急速に増えている。Mem0のレポートによると、2026年春時点で13のエージェントフレームワーク(LangChain, LangGraph, LlamaIndex, CrewAI, AutoGen, Google ADK, OpenAI Agents SDKなど)と21のベクターストアが統合可能だ。
特筆すべきは、OpenClawという新しいエージェントフレームワークがマークダウンファイルベースのメモリ管理を採用し、コミュニティで急速に支持を集めていることだ。OpenClawのメモリモデルは4つの仕組みで構成される:
- ブートストラップローディング — セッション開始時に自動的に記憶ファイルを読み込む
- プリコンパクションフラッシュ — コンテキスト圧縮の直前に「書き込むべき記憶」をファイルに保存する
- セッションスナップショット — セッション終了時に直近の重要なやり取りを保存
- 「覚えて」命令 — ユーザーが「覚えて」と言った内容を適切な記憶領域に振り分ける
この「ファイルファースト」のアプローチが、後述するObsidianとの相性の良さにつながっている。
3. ノーコンテキストからの脱却(IBM, 2026年5月)
IBM Technologyの解説動画(2026年5月公開、87,000回再生)では、AIエージェントに必要な4種類の記憶を「ワーキングメモリ→短期記憶→長期記憶→知識グラフ」の階層で説明している。これは人間の記憶の階層構造を模したもので、エージェントの性能を決めるのは「どの階層に何を置くか」の設計判断にあるという。
4. 品質とコストのトレードオフ
Mem0のベンチマーク結果が示すもう1つの重要な数字は、クエリあたり約6,700〜6,900トークンというコストだ。つまり、記憶システムを適切に設計しないと、毎回の検索に数十円単位のコストがかかる可能性がある。
一方で、マークダウンファイルベースのシンプルな実装(Hermes Agentのmemory機能やOpenClawのアプローチ)では 「毎回プロンプトに含める記憶」は数KBに抑えられるため、追加のトークンコストはほぼゼロだ。これは軽量な個人運用において大きなメリットになる。
Obsidianをエージェントの「外部記憶装置」にする3つのパターン
ここからが本題。エージェントに記憶を持たせる方法が複数ある中で、なぜObsidianなのか。
答えはシンプルで、Obsidianは「人間のための知識管理と、AIエージェントのための記憶管理を、単一のインターフェースで統合できる数少ないツール」だからだ。
人間がObsidianに書いたメモを、エージェントが読み、エージェントが書いたメモを人間が読める。この双方向性が、単なるRAG(検索拡張生成)とは質の異なる知識システムを作る。
パターン1:MCPサーバー経由で直接アクセスする(おすすめ)
最も本格的な方法が、Model Context Protocol(MCP)経由でObsidian Vaultにアクセスするパターンだ。
2026年に入って、以下のようなMCPサーバーがOSSで公開されている:
- mcpvault — Obsidian VaultをMCPサーバーとして公開。BM25検索とセマンティック検索をサポート。GitHubでスターを集めている
- Nooscope — 個人のナレッジボールトと外部の生成モデルを繋ぐMCPサーバー。チャンキング戦略、複数ボールト対応、ファイルウォッチャー設定まで含む本格的な実装
これらのMCPサーバーを使うと、AIエージェント(Claude Code, Hermes Agent, OpenClawなど)が直接Obsidian Vaultに対して「読む・検索する・書き込む」を行える。
具体的なワークフローはこんな感じになる:
- エージェントがセッションを開始
- MCP経由でObsidian Vaultから「今日のノート」と「アクティブなプロジェクトのメモ」を読み込む
- 会話の中で新しい決定事項があれば、Vaultに直接書き込む
- セッション終了時に「日誌」や「デシジョンログ」にメモを残す
このパターンの最大の利点は、エージェントが人間と同じ知識ベースを共有できることだ。
パターン2:マークダウンファイルの共有ストレージとして使う
よりシンプルな方法として、Obsidian Vaultのフォルダをエージェントからもファイルシステム経由で読み書きできるようにするパターンがある。
Hermes AgentやOpenClawが標準で採用しているアプローチがこれだ。Hermes Agentの場合、~/.hermes/memories/ 以下にMEMORY.md(エージェントの個人ノート)とUSER.md(ユーザープロファイル)をマークダウンファイルとして保存する。これをObsidian Vault内にシンボリックリンクで配置すれば、人間もエージェントの記憶をObsidianのグラフビューで可視化できるようになる。
具体的にObsidian Vault内で管理すると便利なファイル構成:
vault/
├── agent-memory/
│ ├── MEMORY.md # エージェントの永続記憶(事実・環境設定)
│ ├── USER.md # ユーザープロファイル(好み・スタイル)
│ ├── decisions-log.md # 決定事項のログ
│ └── active-context.md # 現在の作業コンテキスト
├── daily/
│ └── YYYY-MM-DD.md # 日報(エージェントも読み書きする)
└── projects/
└── xxx/
└── README.md # プロジェクトごとの状況メモ
この構成のポイントは、エージェントが書き込むファイルと人間が書くファイルが同じ場所にあることだ。日報をエージェントが読み、そこから翌日のコンテキストを自動取得する。この循環が「育つ知識システム」の基本になる。
パターン3:カスタムAPI/Webビューアを構築する
さらに自由度の高い方法として、Obsidian VaultをREST APIで公開するカスタム実装がある。サードパーティのクラウドサービスを使わず、自分でホストするため、データを一切外部に出さない設計が可能になる。
私たちの環境では、Flask製のWebビューアをRaspberry Pi上で動かし、Obsidian Vaultの全文検索・ブラウジングをエージェントから利用できるようにしている。このアプローチのメリットは:
- エージェントがHTTP経由でVaultにアクセスできる
- 検索結果やノートのレンダリングをサーバー側でカスタマイズできる
- MCP未対応のエージェントとも統合できる
- Vaultのバックアップや同期と独立して運用できる
ただし、このパターンは運用コストが高く、既にMCPクライアントを標準搭載しているエージェント(Claude Code, Hermes Agentなど)を使うなら、パターン1で十分なケースが多い。
実践:Hermes Agent × Obsidian で「育つ知識システム」を作る
ここからは、私たちが実際に行っている運用を紹介する。調査レポートから得た知見を、実運用でどう活かしているかの事例だ。
私たちの環境は:
- エージェント: Hermes Agent(DeepSeek V4 Flash / OpenRouter)
- ハードウェア: Raspberry Pi 5(RAM 8GB, Ubuntu 24.04)
- Vault: Obsidian Vault(RPi5のローカルストレージ)
- 連携方法: マークダウンファイルの共有 + MCPサーバー経由のアクセス
設計のポイント
Hermes Agentの標準的なメモリシステムは、約2,200文字のMEMORY.mdと約1,375文字のUSER.mdで構成され、毎回のセッション開始時に自動注入される。この制約のメリットは、エージェントが常に「今の自分」を知っていることだ。
一方で、この短いメモリだけではカバーできない情報(過去の会話ログ、長期的なプロジェクトの進捗、複雑な設計判断)は、Obsidian Vaultに保存しておく。エージェントは必要に応じてMCP経由でVaultを検索し、コンテキストを補完する。
実際の運用で見えてきた「3つのレイヤー」の設計:
| レイヤー | 保存先 | 特徴 | コスト |
|---|---|---|---|
| レイヤー1(自動注入) | MEMORY.md + USER.md | 常にプロンプト内にある。約3KB。環境設定・ユーザー好み | プロンプトトークンのみ |
| レイヤー2(起動時読み込み) | Obsidian Vaultの日報・アクティブコンテキスト | セッション開始時にMCP経由で読み込む。今日やることを事前把握 | 読み込みトークンのみ |
| レイヤー3(オンデマンド検索) | Obsidian Vault全体 / セッションログ | 必要に応じて検索。プロジェクトの設計ドキュメント、過去の決定事項 | 検索+読み込みトークン |
この3レイヤー設計の肝は、「自動注入する情報」を極限まで絞っていることだ。 すべてをMEMORY.mdに入れようとすると、すぐに容量制限(2,200文字)に達する。だからこそ「常に必要なもの」と「必要な時に検索すればいいもの」を明確に分ける必要がある。
運用で気づいたポイント
半年以上この構成で運用して、いくつか気づいたことがある。
1. エージェントが書く記憶と、人間が書くメモは別物
エージェントのMEMORY.mdは「事実」だけを書く。一方、人間のObsidianメモは「考えたこと」「仮説」「疑問」を含む。この違いを意識しないと、エージェントが人間の仮説を事実として記憶してしまう。
解決策として、エージェントがObsidian Vaultに書き込むエリア(agent-memory/)と、人間が自由に書くエリアは分けるという運用ルールを設けている。エージェントは人間のメモを「参照」できても「書き換え」はしない。
2. 「思い出すタイミング」が設計の決め手
メモリ設計で最も難しいのは、ストレージ方式ではなく「いつ何を読み込むか」の判断だ。Damian Galarza氏が指摘した通り、ここを間違えると「検索コストだけかかって必要な情報が出てこない」状態になる。
私たちの経験では、以下の3つのトリガーが効果的だった:
- セッション開始時: 今日の日報とアクティブなプロジェクトの状況を読み込む
- 特定のアクション実行前: そのアクションに関連する過去の意思決定を検索する
- セッション終了時: 今回の作業で得た知見を日報に追記する
3. 記憶の「賞味期限」を意識する
Mem0のレポートでも「メモリの陳腐化(memory staleness)」が未解決の問題の1つとして挙げられている。実運用では、半年以上前のエントリがコンテキストとして参照されても、むしろノイズになるケースが少なくない。
対策として、定期的なメモリメンテナンスをルーティン化している。具体的には:
- MEMORY.mdのエントリを2〜3日に1回レビューし、古くなった情報を削除
- 似た内容のエントリは統合
- 手順化できる知識は「スキル」として独立させる(次項参照)
4. 「手続き記憶」はスキルとして体系化する
エージェントの記憶を種類別に整理すると、手続き記憶(Procedural Memory) は他の2つと性質が異なることがわかる。エピソード記憶やセマンティック記憶が「読んで理解する」ものであるのに対し、手続き記憶は「実行手順」だ。
Hermes Agentでは、この手続き記憶を 「スキル(Skill)」 という独立した機能として実装している。スキルは:
- 実行手順を構造化して保存できる
- 必要なときにロードして実行できる
- 失敗した手順を逐次修正・改善できる
これはまさにGoogleの分類における手続き記憶の実装例といえる。メモリとは別のシステムとして手続き記憶を管理することで、「覚えること」と「実行すること」の責務を分離できる。
「育つ知識システム」を設計する4つの原則
ここまでの調査と実践から、Obsidian VaultをAIエージェントと共有する知識システムを設計する際の原則をまとめる。
原則1:「常に自動注入」と「オンデマンド検索」を分ける
すべての情報をプロンプトに含めようとすると、トークンコストが爆発する。逆に、すべてを検索に頼ると、毎回のレイテンシが大きくなる。
「常に必要な情報」を最初に決め、それ以外は検索で補うという割り切りが重要だ。私たちの経験では、常時注入する情報は環境設定+ユーザー好み+今日のタスクの3つに絞るのがバランスが良い。
原則2:エージェントの書き込み領域と人間の書き込み領域を分ける
両者が同じVaultを共有する場合、エージェントが人間のメモを意図せず書き換えるリスクがある。これを防ぐには:
- エージェント専用のディレクトリを設ける(
agent-memory/など) - エージェントが読み取り専用でアクセスするディレクトリを明確にする
- エージェントが書き込んだ内容は人間がレビューできるようにする
原則3:記憶には「賞味期限」を設ける
古くなった情報が残り続けると、エージェントは過去の設定や状況を「現在も有効」と誤認するリスクがある。定期的なメモリメンテナンスは、機能ではなく運用ルールで担保するのが現実的だ。
原則4:手続き記憶はスキル(実行可能な手順書)として独立させる
「◯◯のやり方」といった手順は、単なるメモとして残すのではなく、エージェントが直接実行できるフォーマットで保存する。MCPサーバーのツール定義、スキルファイル、ワークフロー定義など、エージェントのフレームワークが提供する「実行可能な手順」の仕組みを活用する。
まとめ:Obsidian Vaultはエージェントメモリの「基盤」になる
2026年のエージェントメモリを取り巻く環境は、急速に変化している。Mem0に代表される専用フレームワークは高性能だが、そのぶん学習コストと運用コストがかかる。一方で、「マークダウンファイル+適切なタイミングでの読み書き」というシンプルな設計でも、個人開発の範囲では驚くほど機能する。
Obsidian Vaultをエージェントの外部記憶装置として使うアプローチは、以下の理由で現実的な選択肢だ:
- ファイルは普遍的: どんなエージェントフレームワークでも読める
- 人間も読める: エージェントの記憶を人間が理解・編集できる
- 段階的に拡張できる: まずはファイル共有から始めて、必要に応じてMCPやAPIを追加できる
- データの所有権が明確: 自分のVaultにすべてのデータがある
「エージェントが記憶を持たない問題」に対する完璧な答えはまだない。だが、Obsidian Vaultという既存の知識基盤をエージェントと共有する——このシンプルなアイデアが、2026年における最も実用的な第一歩のように思う。
参考文献
- Mem0 Engineering Team, 「State of AI Agent Memory 2026: Progress Benchmark Report Evaluations」, Mem0 Blog, 2026年4月1日公開. https://mem0.ai/blog/state-of-ai-agent-memory-2026
- Damian Galarza, 「How AI Agents Remember Things」, damiangalarza.com, 2026年2月17日公開. https://www.damiangalarza.com/posts/2026-02-17-how-ai-agents-remember-things
- IBM Technology (Martin Keen), 「The Four Types of Memory Every AI Agent Needs」, YouTube, 2026年5月26日公開(87,563回再生). https://www.youtube.com/watch?v=BacJ6sEhqMo
- Nous Research, 「Hermes Agent Documentation: Persistent Memory」, hermes-agent.nousresearch.com. https://hermes-agent.nousresearch.com/docs/user-guide/features/memory
- Mem0, 「Hermes AI Agent: How to Add Memory to Your Workflow」, mem0.ai/blog. https://mem0.ai/blog/how-to-add-memory-to-your-hermes-agent
- Alex Finn, 「OpenClaw + Obsidian gives you super powers」, YouTube, 2026年4月9日公開(66,926回再生). https://www.youtube.com/watch?v=6V-b073qhPA
- Rodney Dyer, 「Your Vault, Your Vectors — Building a Local-First MCP Server for Obsidian」, rodneydyer.com, 2026年3月公開. https://www.rodneydyer.com/your-vault-your-vectors-building-a-local-first-mcp-server-for-obsidian
- Google Agent Development Kit, 「Agent-User Interaction Protocol (AG-UI)」, Google Developers Blog, 2026年. https://developers.googleblog.com/developers-guide-to-ai-agent-protocols
- Richmond Alake, 「2026 will be the year of AI/Agent Memory」, LinkedIn. https://www.linkedin.com/posts/richmondalake_100daysofagentmemory-memoryengineering-activity-7402719428624408577-_81p
- Machine Learning Mastery, 「The 6 Best AI Agent Memory Frameworks You Should Try in 2026」. https://machinelearningmastery.com/the-6-best-ai-agent-memory-frameworks-you-should-try-in-2026
Top comments (0)