AIエージェントに何を覚えさせるか、どう呼び出すかは、実はかなり面倒な問題です。Cal Paterson はそこに対して、記憶を巨大なパイプラインではなく、もっと素朴な「ファイル形式」として扱おうと提案しています。記事の狙いは、既存の agent memory がなぜ使いづらいのかを整理したうえで、より単純で移植しやすい代替案を示すことにあります。単なる思いつきではなく、Markdown や SQLite、semantic search をどう組み合わせるかまで踏み込んでいるのが面白いところです。
記事の中心にあるのは、agent memory を処理工程ではなくデータとして扱おう、という考え方です。著者はまず、今よくある記憶システムを3種類に分けて批判します。ひとつ目は、特定のハーネスやプラットフォームに縛られるタイプです。会話履歴から情報を抜き出す設計が多く、結局「その人についての記憶」ばかりが増えやすい。ふたつ目は、pgvector、Neo4j、独自の LLM まで使うような複雑すぎる仕組みで、管理も大変だしモデルを混乱させる、と言います。みっつ目は、理想化された graph や論理命題で記憶を構成する「High Modernist」型で、文脈を切り離しすぎて役に立たないという見立てです。
そこで著者が出す案が memoryfield です。これはポータブルな記憶ファイル形式で、中身は Markdown の「ページ」と、必要なら YAML frontmatter、さらに semantic search 用の SQLite vector index から成ります。例としては my-memories.memoryfield.zip の中に carbon-fibre-woks.md や finnish-bureaucracy-tips.md のようなページが入り、最後に nomic-embed-text-v1.5.sqlite3 が置かれています。各ページは短めの文章で、だいたい 8KB、約2000 tokens くらいまでを想定しています。著者は、長すぎるよりはページを増やしたほうがよいと考えています。
設計の理由は4つあります。第一に、記憶は chunk や要約の断片ではなく、最初から prose として書くべきだということ。第二に、knowledge graph をたどるのではなく semantic search で関連ページへ一気に飛ぶほうがよいこと。graph を辿る方式だと tool call が N+1 回必要になり、ページのタイトルやリンク文字にも引っ張られて、重要な情報を見落としやすいとします。第三に、低機構であることです。専用 API が少ないぶん、モデルは bash や Markdown、SQLite を自分で使えるし、モデルが賢くなるほど記憶の書き方も自然に洗練される。第四に、オープンな形式であることです。zip を正規の保存形にしつつ、ローカルファイル、S3、GitHub、HTTP など、ファイルとして扱える場所ならどこでも運べるようにする。記事では、ollama pull nomic-embed-text、uv tool install git+https://github.com/calpaterson/memoryfield-tool、npx skills add calpaterson/memoryfield-skill -g -y という導入手順も示しています。
想定される反論にも答えています。これはただの RAG ではないか、という問いには、広義にはそうだが、chunking も re-ranking も hybrid search も使っていないし、しかも記憶を「読む」だけでなく「書く」ための仕組みでもあると返します。埋め込みモデルについても、nomic-embed-text-v1.5 は古く見えるかもしれないが、270MB と小さく、GPU なしでも動き、十分にバランスがよいと述べています。
この提案でいちばん新鮮なのは、記憶を AI 用の特別な知能化レイヤーとして扱わず、普通のファイルに戻している点だと思う。多くの記憶システムは、何を保存するか、どう要約するか、どう検索するかを全部ひとまとめにしてしまう。その結果、モデルよりもシステム側の都合が前に出る。著者が嫌っているのはまさにそこではないか。AI に必要なのは「賢そうな記憶装置」ではなく、あとでモデルが自分で再利用できる、見通しのよい資料なのだという感覚がある。
ただし、ここでの発想はかなり実務寄りでもある。Markdown を直接書かせる、Semantic search で関連ページへ飛ばす、SQLite で小さな補助検索をする。どれも派手ではないが、実際にモデルが得意な道具を選んでいる。私はこの点を評価したい。AI のために人間が新しい世界観を設計するより、既にモデルが訓練で知っている道具に寄せたほうが、失敗しにくいからだ。Graph データベースを中心に据える設計は見た目には美しいが、モデルにとっては「毎回迷路に入る」ことに近い。著者の批判はそこを突いている。
一方で、memoryfield の単純さは、そのまま限界にもなると思う。ファイル形式に寄せると、確かに移植性は高い。だが、複数エージェントが同時に読み書きする、権限を分ける、監査ログを残す、古い記憶を自動で統合する、といった運用上の要求が出ると、結局は別の仕組みが必要になるはずだ。著者は「ファイルが扱えればいい」とかなり割り切っているが、企業利用ではその割り切りだけでは足りない場面が多い。
さらに、semantic search で「関連ページに一気に飛ぶ」設計は、文脈を減らす代わりに、検索品質への依存を強める。埋め込みが外せない前提になる以上、どんなモデルを採るか、ページをどの長さにするか、重複した記憶をどう扱うかが地味に効いてくる。ここは「低機構」だから自動で解決するわけではない。むしろ、実装者が見えないところで丁寧に面倒を見る必要がある。著者はその負担を軽く見せているが、実際にはかなりの設計責任が残ると思う。
多くの RAG は、外部文書をどう読むかに意識が寄っています。対してこの記事は、AI が自分の記憶を書き残すところから話を始める。ここが重要だと思う。人間でも、あとで検索しやすいメモは「要約の要約」より、あとで見返したときに意味が立つ文章のほうが役に立つ。AI も同じで、圧縮しすぎた断片より、短いが意味の通った prose のほうが再利用しやすい、という見立てはかなり筋がいい。
同時に、この発想は「エージェントが何を重要だと判断するか」をモデル側に返している。どの記憶を残すかは固定ルールではなく、モデルの能力に合わせて変わるべきだ、という立場だ。これはモデル性能の向上を前提にした設計で、かなり今っぽい。賢いモデルなら、より賢くメモを書き、より賢く読める。逆に言えば、モデルが未熟な段階ではあまりうまく回らない可能性もある。だからこの方式は、すべてのエージェントに向く万能解ではなく、「もう bash や Markdown をある程度扱えるモデル」が前提の実践案として見るのが正しいと思う。
記事全体を通して、著者はベンダー依存をかなり嫌っています。特定のラボが提供するハーネスに閉じ込められたくないし、記憶資産をプロプライエタリな平台に預けたくない。これは単なる好みではなく、AI 時代のロックインへの警戒として読むべきだと思う。記憶は、モデル本体よりも長生きする可能性がある。そう考えると、Open format にして zip で持ち運べるようにする判断は、かなり現実的です。
ここから見えてくるのは、エージェントの価値はモデル単体ではなく、記憶の蓄積と移動のしやすさで決まる、という感覚です。今日のモデルが多少変わっても、過去の学びがそのまま持ち越せるなら、AI はようやく「育つ」感じに近づく。逆に、記憶がハーネスに縛られていたら、モデルを替えるたびに学習成果が蒸発する。著者はその危うさをよく分かっていて、だからこそ「ファイル形式」として定義したのだろう。地味だが、AI の世界で本当に残るのはこういう地味な設計かもしれない。
