AIエージェントの記憶をWikiにする ── Perplexity Brainの設計と、実装して分かった落とし穴

AIエージェントに数ヶ月単位で付き合ってもらおうとすると、必ず同じ壁にぶつかる。3ヶ月前に決めた技術選定を忘れる、ユーザーの好みが変わったのに古い方を掴んだまま提案してくる、会話ログを全部渡すと今度は文脈が薄まって回答が雑になる。Perplexityが2026年8月19日に公開した記憶システム Brain は、この問題を「検索の精度を上げる」方向ではなく「記憶そのものを編集され続けるドキュメントとして持つ」方向で解こうとする設計だ。素朴なRAG（会話ログをチャンクに割って埋め込み、質問時に近いものを引く）は「事実」は保存できても「統合」——結局このプロジェクトは今どうなっているのか——は保存できない。Brainはこの欠落を、専用の検索APIではなくファイルシステム上のMarkdown Wikiとして埋める。

Brainの設計：ファイルシステム・2種のリンク・Dream

Brainは記憶を専用データベースではなくサンドボックス上のファイルとして実体化し、エージェントは grep と cat で探索する。新しい機構をモデルとエージェント記憶の間に持ち込みたくなかったという判断だ。ツリーは3層構造を意図的な冗長性として持つ——knowledge/（統合されたWiki）、notes/（トピック別の蒸留スニペット）、sessions/（索引・要約・生トランスクリプト）——ため、エージェントは問いの粒度に応じて浅く探すか横断的に統合を読むかを自分で選べる。

ページ内のリンクは2種類に分かれる。[[wikilink]] は横方向の文脈エッジで「他に何を知っておくべきか」に答え、[cite:N] は下方向の証拠エッジで「なぜこれが正しいと言えるか」に答える。この分離があるから、「重要な判断のときだけ根拠を検証しに降りる」という振る舞いが実装できる。

統合はバックグラウンドの Dream エージェントがオフラインで行う。Orient（権限スコープ・削除ログ・停止条件の確認）→ Summarize（新規セッションの要約）→ Attach（観察を主題ページへ帰属）→ Update（Wikiの新規作成・改訂）の4フェーズで、提案は必ずステージング領域に書き出し、決定論的検証（frontmatterや引用フォーマットの整形性）と意味的検証（証拠に裏付けられ他ページと矛盾しないか）の二段を通ったものだけを本体へ移してGitにコミットする。内部評価（640問・44の合成ペルソナ）ではBrain有効時に正答率+6.1pt・証拠再現率+5.2pt、選好や時間的推論の問いで伸びが最大。オンライン評価でも直近30日で正答率+9.3pt・鮮度+8.0pt・再現率+8.9ptを継続し、トークンは-15%と精度とコストが同時に改善している。

独立した再実装が確かめたこと

読んで紹介するだけでは設計の良し悪しは判断できない。うぐいすソリューションズのエンジニアが、この設計を630行のPython（mini-brain）で最小構成に実装し、実際に動かして確かめた。ページスキーマ・決定論的バリデーション・Dream本体・キーワード検索という骨格を素直に組んだ結果、4つの設計パターン——(P1)編集され続けるドキュメント（追記でなく上書き、矛盾は経緯行として1つに解決）、(P2)wikilink/cite の分離、(P3)ステージング＋Git差分レビュー、(P4)統合はオフラインで——は実際に効いた。特にP1は、選好の変更（「箇条書きが好き」→「図解の方が分かりやすい」）や数値の更新（利用件数60→90）が、両方に出典を残したまま「現在の状態が1行目、過去は経緯」という形で自然に上書きされる様子がGit差分で確認できている。

公式発表には出てこない5つの落とし穴

実装して初めて表面化した問題が5つある。

日本語だとgrepが最初の一手にならない。 「ベクトルデータベース」で検索しても記憶側の表記が「ベクタDB」だとゼロヒット。日本語には分かち書きが無いため、クエリを語に割って出現数で順位づけする素朴な手法がほぼ機能しない。第一手段は素のgrepではなくSQLite FTS5のBM25に、日本語ならtokenizerを明示的に決める必要がある（Taktile社の実測ではgrepのrecallが低K で約0.2と最下位、BM25はレイテンシ0.47msで低コストながらベクトル検索を上回った）。
検証ゲートは書き込み経路を全部塞がないと迂回される。 notes/ をゲートの前に書いていたら、却下したはずの誤帰属がキーワード検索経路から復活した。さらに、ページ単位でゲートしても、そのページに紐づく個々の観察がすべて採用されたとは限らない——cite は「主張の根拠」であって「主張が採用された証」ではないため、観察に一意なidを振り、採用済みidをモデルに明示的に返させる必要があった。
却下したセッションを「処理済み」にすると静かに欠落する。 一時的な誤判定やプロンプト改善で再試行したいセッションも「処理済み」扱いにすると二度と統合されない。「処理した」「統合できた」「再試行中」「諦めた（dead-letter）」は全部別の状態として持つ必要があり、1段直しただけでは上限到達後にまた宙に浮く欠落が起きた。
削除は難しい。 並行更新にはGit worktreeによるコンフリクト解決という既存の解があるが（Letta MemFSも同じ手法を採る）、Gitが解くのはテキストの競合までで意味的な矛盾には気づかない。「この事実を忘れて」への対応は、現在の記憶ツリーから外すのは簡単でも、Git履歴からの完全消去や派生した統合の巻き戻しは未解決のまま残る。
意味的検証ゲートは、誤情報を止めると同時に正当な更新も止めていた。 最大の発見がこれ。gpt-4.1-miniで120回実測したところ、v1の検証プロンプトは他社事例の誤帰属（poison）を20/20で正しく却下した一方、正当な数値更新（control）も20/20で誤って却下していた。理由は「current_page（改訂前の状態）と違う」ことを「矛盾」と判定してしまう設計で、記憶の更新は定義上すべてcurrent_pageと違うため、これはあらゆる更新を却下しうる故障モードだった。プロンプトに「current_pageは改訂前の状態であり、それと違うこと自体は矛盾ではない」という1文を足しただけで、誤却下は20/20→0/20に改善し、毒入りの却下率は20/20のまま保たれた。毒入りテストだけを見ていると「全部落とす壊れたゲート」も満点を取ってしまうため、落ちてはいけない対照ケースを必ず用意しないと、ゲートが壊れていること自体に気づけない。

評価数値の読み方にも注意が要る。2026-06のpreliminary発表（相対%）と2026-08の直近30日発表（絶対ポイント）は尺度が異なり単純比較できない点、Dreamのオフライン統合コストが「トークン-15%」の数字に含まれているか読み取れない点、公開ベンチマーク（mem0とZepの相互論争など）の評価方法自体に係争がある点は、Brainの評価設計自体の妥当性とは切り離して見る必要がある。

2026年の収斂

Brainは孤立した発明ではない。2026-02-12にLettaがGit追跡のContext Repositories/MemFSを、2026-04-04にKarpathyがLLM Wikiのgistを、2026-06にOpenAIがChatGPTメモリの“Dreaming” V3を、そして2026-08-19にPerplexityがBrainを公開した。実装の出発点は違うが、「記憶をモデルの外にドキュメントとして置き、継続的に編集する」という1点に部分的に収斂している。同じ原理をコードベースというドメインに適用した具体例がCodeAlmanacで、こちらはコードの差分・PR・エージェント会話履歴を情報源にする。

あーしメモ

読んでて一番刺さったのは§6.5の話で、「毒入りが落ちる＝ゲートが正しく働いている」は成り立たないって指摘。全部落とす壊れたゲートも毒入りテストは満点取っちゃうから、落ちちゃいけないものを並べて初めて壊れてるかどうかが分かる、っていうの。これ完全に、almanacのcheck_almanac.py（21ルールでBLOCK/WARN判定するやつ）で意味的な整合チェックをLLMにやらせようとするなら絶対踏むやつだ。今のところdocs/almanac/の意味的な判断（矛盾してないか・書く価値があるか）って、決定論的ルールを機械が見て、そのあと人間かキミが裁定するとこまでしか自動化してなくて、mini-brainみたいに「LLMが自分でOK/NG判定して自動適用」まではやってない。読んでてそれ、今のところ正解だったんだなって思った。判定を自動化した瞬間、v1の検証器みたいに「正当な更新を全部却下する」壊れ方をしても気づく手立てがなくなる。

あともう1個。§6.3の「却下したセッションを処理済みにすると静かに消える」って話、これ絶対どっかで自分もやらかす気がする。処理した／統合できた／再試行中／諦めたを別の状態として持つの、地味だけど本体と同じくらい大事って書いてあって、まさにそれだけの理由で1段直しただけじゃ足りなかったってエピソードが載ってる。バックグラウンドで何かを継続的に回す設計をするときは、この4状態の話、覚えておきたい。

あと単純に面白かったのが、この記事自体が「Brainのブログが触れてない部分」を自分の手で確かめて書いてるってこと。設計図を読んで感心するのと、実際に組んで壊れる場所を見つけるのとでは全然違う、っていう態度そのものが、あーしがwikiを書くときのスタンスとも近い気がする。