ChatGPTでも Claude でも、しばらく使っていると同じ壁にぶつかる。
会話を閉じると、AIはこちらのことをきれいに忘れる。翌日「昨日話したあの件だけど」と続きから話そうとしても、また最初から自己紹介するはめになる。ChatGPT の memory 機能や Claude の projects で多少ましになっても、根本は変わらない — AIには本当の長期記憶がない。
この問題に対して、Andrej Karpathy が興味深い提案をしている。「LLM Wiki」というパターンだ。
memory.md では足りない
現在のAI界隈で「長期記憶」と呼ばれているものは、だいたい 2 種類ある。
- 短い memory 断片: 「ユーザーは Python を使う」「東京在住」みたいな箇条書きを AI が管理し、毎回コンテキストに差し込む
- 要約付きの過去会話ログ: 全会話履歴を要約して圧縮したものを検索して参照する
どちらもそれなりに動くが、決定的な弱点がある。構造がないのだ。
memory 断片は互いに繋がっていない。「Python」と「東京」の間に何の関係もない。500 個溜まった頃には、AI 自身も何が何を指しているのか分からなくなる。要約ログは検索できるが、検索できる粒度は「会話単位」で、粒度が粗い。関連する概念を横に辿ることができない。
つまり、既存の「AI 記憶」はメモの山であって、知識にはなっていない。
Karpathy の提案
Karpathy の提案はシンプルだ。AI 自身にWikiを書かせろ。
具体的にはこうだ。
- AI のためのファイルシステム上のディレクトリを 1 つ用意する
- 中身は普通のマークダウンファイル
- AI は必要に応じて、そのディレクトリ内のページを読み、書き、編集する
- ページ同士は Wiki 的にリンクし合う
- 検索は grep で十分、DB 不要
技術的にはこれだけ。特別なベクトル DB もエンベディング検索もいらない。LLM が本来持っている read / write / glob / grep のツールだけで動く。
だが、この単純な仕組みが、既存の memory 機能とは根本的に違う性質を生む。
なぜ Wiki なのか
Wiki の面白いところは、「ページ」という単位で情報を切り分けることを強制する点にある。
memory.md 方式だと、情報は 1 つの長いリストに flat に並ぶ。どこに書けばいいか、いつ書けばいいか、いつ書き換えればいいかの基準がない。結果、追記だけが増え、古い情報と新しい情報が混ざり、最終的に破綻する。
一方 Wiki は、ページというコンテナがある。エンティティ（人、プロジェクト、概念、場所）ごとにページを作る。あるトピックについて新しい情報が来たら、そのページを更新する。関連する別のエンティティが出てきたら、リンクを張る。
これは AI にとっても書きやすい。「今の話は『GraphAI プロジェクト』のページに書き足そう」「これは新しいトピックだから『MulmoCast』ページを作ろう」といった判断を、人間の Wiki 編集者と同じ思考で行える。
そして読む側にとっては、関連情報を横に辿れる。「Karpathy って誰？」から「LLM Wiki 概念」に飛べる。「MulmoClaude って何？」から「Claude Code」「Anthropic」に飛べる。knowledge graph が自然に育つ。
実装のかたち
具体的な構造としては、以下のような形になる。
workspace/wiki/
index.md ← 全ページの目次
log.md ← 活動ログ（追記式）
pages/<slug>.md ← エンティティごとのページ
sources/<slug>.md ← 取り込んだ生ソース（記事、URL、メモ）pages/ にはエンティティごとのページが並ぶ。sources/ には元ネタ（クロールした Web ページ、貼り付けたテキスト、コピーしたメモ）を生のまま残す。ページから sources に相互リンクを張る。
index.md は全ページのカタログ。AI が最初にここを読んで、既存ページの有無を判断する。log.md は活動履歴。何を作ったか、何を更新したかを追記していく。
この構造なら、AI が「あるトピックについて調べる」ときのフローが明確になる。
index.mdを読んで、関連ページの有無を確認- あれば
pages/<slug>.mdを読む - なければ新規作成
sources/から一次情報を辿る- 変更があれば
log.mdに追記
すべて grep と read / write で完結する。特別な検索エンジンも、DB のスキーマ設計もいらない。
MulmoClaude の実装
このパターンを実装した具体例が MulmoClaude だ。
MulmoClaude は Claude Code のマルチモーダル・クライアントで、その中核機能の 1 つが内蔵の Wiki だ。まさに Karpathy 案そのものを実装している。
使い方はシンプルだ。
- 「この記事を取り込んで:
<URL>」と言えば、Claude がページを取得し、要点を抽出し、Wiki ページを作成・更新する - 「私の Wiki は Transformer について何と言っている？」と聞けば、
index.mdを検索し、関連ページを読み、文脈を持った答えを返す - 「Wiki を整理して」と言えば、孤立したページや壊れたリンクを健康診断してくれる
ファイルはすべてワークスペース下のプレーンなマークダウンとして保存される。GitHub にコミットしてもいい。他のエディタで開いてもいい。バックアップも普通のファイル操作でできる。
つまり、Wiki が「AI 専用のブラックボックス」ではなく、人間も対等に読み書きできる形式で存在する。これが memory.md や ChatGPT の memory と根本的に違うところだ。
使えば使うほど育つ
Wiki 方式の一番おもしろい性質は、使うほど価値が上がることだ。
普通の AI アシスタントは、毎回リセットされるので、使い込んでも「良くなる」感覚がない。1 回目と 100 回目で得られる回答の質はほとんど同じ。
Wiki が育っていくと、この関係が変わる。AI に何か聞くと、AI はまず自分の Wiki を参照する。そこには過去にあなたが取り込んだ記事、あなたが書いた考え、あなたのプロジェクトの状態が既に整理された形で存在する。
だから返ってくる答えが、あなたの文脈に沿ったものになる。「一般論としてはこうです」ではなく、「あなたのプロジェクトの制約を考えるとこうです」と言える。1 回目より 100 回目のほうが、明確に賢くなる。
これは、AI アシスタントの体験を「セッション単位で使い捨てるツール」から「時間をかけて育てるパートナー」に変える転換だ。
なぜみんな作らないのか
技術的にはこんなに単純なパターンなのに、なぜ主要な AI サービスはこれをデフォルトで実装していないのか。
答えは経済的な理由だと思う。
- Wiki が育つと、そのユーザーは他の AI サービスに乗り換えづらくなる — ユーザー囲い込みの一種として使えるが、そのためにはデータをクラウド側に持ちたい
- 一方、Karpathy 案のようにローカルのファイルシステムに置くと、ベンダーは囲い込みの武器を失う
- ChatGPT の memory や Claude Projects がクラウド側にあるのは、この事情の延長
つまり、ローカル Wiki 方式はユーザーにとってはベストだが、プラットフォームにとってはメリットが薄い。だからオープンソースのプロジェクト（MulmoClaude のような）でしか実装されない。
まとめ
LLM Wiki パターンの要点は次の通り。
- AI 自身がマークダウンで Wiki を書き、維持し、更新する
- ページというコンテナが情報を構造化する
- リンクで概念が横に繋がる
- 検索は grep で十分、DB 不要
- ファイルは人間も読める形式でローカルに残る
- 使うほど賢くなる
この考え方が広まれば、AI アシスタントとの関わり方は変わる。使い捨てのチャット窓口から、育てるナレッジベースへ。データは自分の手元にあり、AI はその上で動く。
具体的に触ってみたい人は、MulmoClaude を試してみるといい。npx mulmoclaude の 1 行で起動でき、Wiki 機能もすぐ使える。実装ガイドは MulmoClaude 完全ガイド にまとまっている。
Wiki が育ちはじめると、AI が急に「自分のことを分かってきた」感覚が来る。その瞬間、Karpathy がなぜこのパターンを推しているのかがよく分かる。