7月1日、LangChainが「Wiki Memory」と題した記事を公開した。この記事では、AIエージェントの長期メモリ設計における新興パターン「Wikiメモリ」について詳しく紹介されている。

エージェントのメモリに「Wiki」という答え

エージェントのメモリ設計は、まだ標準化が進んでいない領域だ。「メモリ」の意味は実装者によってまちまちで、RAG（Retrieval-Augmented Generation）を指す場合もあれば、会話履歴の保持を指す場合もある。

そのなかで、一つのパターンが浮かび上がりつつある。それがWikiメモリだ。

考え方はシンプルだ。エージェントを使って生のソースデータを処理し、「コンパクトで永続的な、エージェントが読みやすい知識層」に変換する。ログ、ノート、コード、Slackスレッド、実験記録——これらはノイズが多く、そのままエージェントに渡しても非効率だ。Wikiメモリはそれらを事前処理し、より密度の高い表現へと圧縮する。

RAGとの違いはどこか

RAGはクエリのタイミングで生のチャンクを取得する。これに対しWikiは、高レベルな合成を事前に計算・維持しておくアプローチだ。エージェントが毎回データ構造を再発見する必要がなくなる。

RAGが「必要になったときに原典を引く図書館の司書」だとすれば、Wikiメモリは「すでに整理・要約された百科事典を手元に置く」イメージに近い。前者はソースの鮮度に強く、後者は繰り返し参照される構造的知識の再利用に強い。両者は競合するというより、用途が異なる補完関係にある。（※編集部の考察）

記事の中でLangChainは、あるリサーチ企業の知人の言葉を引用して背景を説明している。その人物は「研究者の頭の中にある知識を会社に残したい」と話しており、実験記録・ノート・行動履歴を見ることで「脳のクローン」を近似できないかと考えていた、という。Wikiメモリは、すべてを保存するのではなく、重要なことを再利用可能な知識ベースに圧縮するという点でそのアプローチに近い。

すでに実装例が登場している

このパターンはすでにいくつかのプロダクトとして形になっている。

• **DeepWiki（Cognition）**：GitHubリポジトリに対してAI生成ドキュメントを作成するツール。人間とコーディングエージェントの両方に、コードベースのハイレベルな全体像を提供する。
• **Andrej KarpathyのLLM Wiki**：コードに限らず任意のソースファイルを対象にした汎用版。LLMが段階的にMarkdown形式のWikiを構築・更新し、ユーザーと生データの間に置くという設計だ。
• **AutoWiki（Factory）**：DeepWikiと同様にコードベースを解析し、リポジトリの変更に追従する構造化ドキュメントを自動生成する。

また、LangMem、Letta、Mem0、Zep といった既存のエージェントメモリシステムとも隣接する領域だ。ただし、これらがエージェントメモリ全般を扱うのに対し、Wikiメモリはファイルという最もシンプルな基盤を使う点が特徴だとLangChainは述べている。

エージェントメモリの設計パターンについては、LangChainが公開しているMemory conceptual guideも参照に値する。短期・長期・エピソード的メモリといった分類軸の整理が、Wikiメモリの位置づけを理解する助けになる。

ファイルが「基盤」として選ばれる理由

Wikiメモリの実装で浮かび上がる問いと、現時点での答えを記事はこう整理している。

ファイルが選ばれる理由は、検査可能・編集可能・バージョン管理可能であり、エージェントとの読み書きが容易だからだ。Gitとの親和性が高く、既存の開発ワークフローへの統合障壁が低い点も実用上の利点として挙げられる。

Wikiメモリの適用範囲と限界

LangChainは「あらゆるドメインに対して、作る価値のある知識ベースが存在する」と主張している。ただし、Wikiメモリがすべてのメモリ問題を解くわけではない。短期的な会話状態、ユーザー設定、高頻度なイベントログにはWikiは向かない。あくまで「耐久性のあるドメイン知識」に強いパターンだ。

それでも、長期メモリの設計として「ファイルベースのWiki」は現時点で最もシンプルで実用的な選択肢の一つだと記事は結んでいる。エージェントが知識を蓄積・更新し続けるユースケースが増えるにつれ、このパターンの採用事例はさらに広がっていくことが予想される。

詳細はWiki Memoryを参照していただきたい。