エージェントの記憶を扱う新しいポータブルファイル形式「Memoryfields」が発表

2026 年 8 月

Memoryfields：エージェントの記憶を扱う、はるかにシンプルな方法

*[フロッピーディスク挿入音] おおー、企業 VLAN の設定を知ってるぞ！

多くのモデルベンチマークは 空のコンテキストウィンドウからスタートします。これは AI における「白紙の状態（タブラ・ラーサ）」です。ある程度、公平な比較を保つために必要な措置だと言えるでしょう。

しかし、実際のエージェントが空のコンテキストウィンドウからスタートしてはなりません。利用可能な関連情報を最大限に備えた状態で起動すべきです。AI エージェントには、記憶（メモリ）が必要なのです。

既存のエージェント用メモリシステムが機能しない理由

問題は、多くのエージェント用メモリシステムが実のところあまりにもお粗末だということです。現在、主に三つの種類のメモリシステムが存在しますが、それぞれが独自の理由で機能していません。

第一に、特定のハネス（実行環境）にユーザーを縛り付けるタイプです。これは通常、そのハネスをレンタルするラボによって開発されています。そのラボは、競争の激しい「API ビジネス」から脱却し、より収益性の高い「プラットフォームビジネス」へと移行することを切望しています。この種のシステムは、会話履歴から情報を抽出して動作しますが、その結果、記憶の内容がユーザー自身に関するものばかりになりがちです。しかし、世界に関する情報の方が一般的にはるかに有用なのです。

もう一つのタイプのシステムは、あまりにも複雑すぎます。私は、何が記憶に値するかを判断するために、pgvector と Neo4j グラフデータベース、そして独自の LLM が必要になるような有名なシステムを知っています。この複雑さは管理する上で困難であるだけでなく、後ほど説明するように、これらの大規模なシステムはモデル自体を混乱させてしまいます。また、モデルの最先端が前進するにつれて、スケーラビリティにも失敗しています。

最後に登場するのが「ハイ・モダニスト」型です。これは記憶の理想化された合理主義的な形態を想定したものです。必然的にグラフ構造を採用し、場合によっては論理的な命題も含まれます。このタイプは体系的に情報を文脈から切り離し、エージェント（そしてあなた）にとって孤立して無意味なものにしてしまいます。結局のところ、「凝縮された事実」の単純なリストなど、どれほど有用でしょうか。

これらに共通しているのは、記憶を「プロセス」と捉えている点です。しかし、特にモデルにとっては、記憶はデータとして表現する方がはるかに適しています。

記憶は多段階のパイプラインではなく、データフォーマットであるべきだ

ブルックスはこう言っています。

フローチャートを見せられてテーブルを隠されれば、私はいまだに混乱したままです。テーブルを見せられれば、通常はフローチャートは不要になります；それらは自明だからです。

そこで、「memoryfield」というポータブルな記憶ファイルフォーマットをご紹介します：

my-memories.memoryfield.zip
├── carbon-fibre-woks.md
├── finnish-bureaucracy-tips.md
├── [... many more md files...]
├── wec-2026-season-notes.md
└── nomic-embed-text-v1.5.sqlite3

memoryfield とは以下の要素で構成されます：

• Markdown 形式の「ページ」
• （任意）YAML フロントマター
• （任意）セマンティック検索用の SQLite ベクトルインデックス

エージェントにとって、ファイルで扱うのが最も効果的です。その理由を説明しましょう。

デザイン判断 1：チャンクや「事実」ではなく、文章（プロース）を使用する

RAG パイプラインが非常に複雑になりがちなのは、既存の人間が作成した膨大な文書を AI エージェントが読みやすい形に変換しようとするからです。これらの文書は、AI エージェントにとって直接読むのが極めて困難な場合が多いのです。例えば、大きな PDF 形式であるケースなどが挙げられます。

しかし、エージェントのメモリは複雑なレガシードキュメントとは異なります。メモリが形成される瞬間、それは AI エージェントに対して直接的に起こる出来事であり、そのエージェントは文章を書く能力を十分に備えています。そのため、その文章をチャンク化したり、情報を付加したり、二重要約をかけたり、機械的に処理する必要はありません。エージェントに好きな形式（Markdown）で直接メモリを書かせればよいのです。

メモリフィールドのページは以下のようになります。

---
created: '2026-03-01T09:00:00Z'
updated: '2026-08-22T14:30:00Z'
uuid: 6aa615f0-486f-48a7-a210-ba4f5ff18c8b
summary: Thermal properties of carbon fibre cookware
---

Carbon fibre woks conduct heat evenly, but...

ただし、一つの制限があります。このページはベクトル埋め込みのサイズ内に収まるように短くなければならないため、実質的な上限は約 8kb（約 2000 トークン）となります。

しかし、これは実際には非常に有益な制約です。8,000 文字は約 1,300 語に相当し、中程度の雑誌記事の長さと同じくらいです。つまり、本来ならこの程度の制限を設けること自体が理にかなっているのです。さらに詳細を追加したい場合は、ページを増やせばよいだけです。エージェントにとってこれは苦になる作業ではありません。

デザイン判断 2：グラフの探索ではなく、意味的なジャンプ

先行事例として重要なものといえば、Karpathy のウィキ（https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f）です。

この Karpathy ウィキは、Roam や Obsidian で使われているようなハイパーリンク付き Markdown ファイルを基盤に設計されています。AI エージェントが「知識グラフ」をたどって関連ページを見つけ出すというアイデアでした。

しかし実際には、AI エージェントが知識グラフを探索するのは、遅く、信頼性に欠けるだけでなく、エージェント自身にとっても混乱を招きます。

探索が遅い理由は、モデルが連続するページを読み取るために頻繁に停止し、逐次的なツール呼び出しを実行しなければならないからです。

エージェントが知識グラフをたどる際の概略アルゴリズムは以下の通りです：

• ウィキのトップページを読む [ツール呼び出し] → 関連リンクを検索
• リンクされたページ（複数可）を読む [ツール呼び出し] → 関連リンクを検索
• 十分な関連情報が得られたか判断。不足していれば #2 に戻る

もし必要な情報が知識グラフ内で N ステップ先にある場合、それを取得するには N+1 回のツール呼び出しが必要です。これは非常に遅いプロセスです。数十億ドル（あるいは兆ドル？）規模の LLM モデルが、各ツール呼び出しごとに停止し、それぞれに数秒（2〜3 秒程度）を要するからです。また、この方式は深層構造を持つ知識グラフに対して著しく不利で、そもそも知識グラフが持つ意義自体を損なう結果になります。

知識グラフもまた信頼性に欠けます。AI が情報の関連性を判断できるのは、リンクテキストや（何らかの方法で外部化されていれば）ページタイトルを見ることだけだからです。これにより、エージェントには 1990 年代の SEO のようなページメタデータ操作を強いることになります。つまり、各ページのリンクテキストやタイトル、キャプションが魅力的かつ正確であるように仕向ける必要があるのです。しかし、そのようなアプローチは脱線や、周囲の詳細を自然に記録する行為、そして大規模なテキストコーパスでは一般的で非常に有用な暗黙の知識（lore）を罰することになります。

実際には、Karpathy のウィキにおいて関連情報が欠落することが多いのは、検索エージェントにとって魅力的に見える形でタイトル付けやキャプション付けがされていないからです。

また、知識グラフはエージェントにとって混乱を招きます。なぜなら、グラフ内を移動する際に無関係な情報を大量に精査しなければならないからです。意図せずして無関係な情報（特にトップページが問題となるケースが多い）を読み込むと、モデルのコンテキストウィンドウにノイズが混入し、出力品質が低下します。その結果、エージェントがおかしいことに執着しているように見えてしまうのです。

これらすべての問題は、意味検索（semantic search）を用いて、ページメタデータではなく実際のコンテンツに基づき、関連するすべてのページへ直接ジャンプすることで解決できます。そして、エージェントはそれらの関連ページを一度に、*並列で* 読むことができます。現在では、大半のエージェントがすでにこの手法を採用しています。つまり、メモリフィールドにおいては、最大でも 2 つのツール呼び出し（#1: 検索、#2: 並列読み込み）で済みます。これにより、必要な情報が確実に発見され、無関係な入力トークンを最小限に抑えることが可能になります。

デザイン判断 3：モデルを重視し、仕組みは最小限に

"ハイ・メカニズム"なメモリシステム（高度に特別設計された API やデータベースを多数含むもの）には、一つの大きな課題があります。それは、エージェントが目標を達成するために、複雑なインターフェースの迷宮を抜けなければならない点です。

もしインターフェースが大きければ、コンテキスト内に大量の openapi.json を読み込む必要が生じます。逆に小さすぎれば、機能に制限がかかります。たとえバランスが取れていたとしても、API 自体が間違っているケースも少なくありません。誰かが自分のニーズを想定せずに作成した API を使わされた時のことを思い出してください。その経験を楽しめましたか？

そこで登場するのが Memoryfields です。これは"ロー・メカニズム"なシステム（単なるファイル形式）であるため、エージェントには独自のアクセスパターンを自由に設計する余地が生まれます。

(おそらく) 役立つツール は提供されていますが、エージェントは好きなアクセスパターンを何でも利用できます。例えば、perl を使ってコパス全体で置換処理を行ったり、メモリ内にインライン CSV ファイルを埋め込んで SQLite でクエリを実行したりするケースです（どちらも私が実際に目にした事例です）。

「メカニズムを低く保つ」ということは、メモリフィールドがモデルの最先端とともにも成長していくことを意味します。モデルが進化すればするほど、エージェントはより多くのタスクを考え出すようになります。最近の画期的な発見の一つとして、モデルが偶然にも Bash や Markdown、SQLite に対して非常に高い能力を発揮することが挙げられます。

私が考えるに、メモリフィールドが実際のエージェント内でうまく機能する理由は、エージェントがトレーニングデータから「今何が起きているか」を本質的に理解できるからです。これは、記憶を読み取れるようになるまでにはそのデータしか頼れないという点で重要です。一方、「メモリパイプライン」内の単なる非具身的な LLM 呼び出しでは、そのような理解は不可能です。

モデルが向上するにつれ、自動的により賢明にメモ리를記述するようになります。「サイドバッグ型」のメモリシステムでは、このようにはなかなか行われません。固定された API エンドポイントに対して想像力豊かにアプローチする方法には限りがあるからです。メモリフィールドは、モデルの最先端とともに拡張されていきます。

デザイン決定 4: オープン形式、相互交換可能、転送非依存

メモリのコレクションが蓄積されるにつれ、それらは貴重な資産となります。学んだ教訓や苦労して得た確かな事実の宝庫です。特定のフレームワーク、モデル、あるいはエージェントに縛り付けられたくはないはずです。

私はファイル形式のための RFC 風仕様 を作成しました。これは主に曖昧さを排除し、特定の埋め込み関数に依存しないようにするためです。

仕様に基づけば、必要なツールを自分で構築することも可能です。ただし、私は skill と、エージェントに最適化されたコマンドラインツール agent-optimised command line tool も用意しています。

memoryfield の標準的なアーカイブ形式は zip ファイルです。データ交換を容易にするためです。ただし、仕様はローカルファイル、Amazon S3、GitHub、HTTP 経由での提供も可能となるよう意図的にオープンに設計されています。実際には、ファイルを扱える環境であれば何でも利用可能です。私は個人用 memoryfield に Syncthing を、共有用には S3 を使い分けています。

はじめに

エージェントが SPEC.md を取得して実装を作成することもできますが、最も簡単な方法は私のツールを利用することです：

# Requires: ollama, uv and npx (comes with npm)
#
# 1. Pull the embedding model:
ollama pull nomic-embed-text
# 2. Install the CLI tool:
uv tool install git+https://github.com/calpaterson/memoryfield-tool
# 3. Install the skill:
npx skills add calpaterson/memoryfield-skill -g -y

ここからエージェントがセットアップを支援します。

試せるデモ用の memoryfield として、`soapstones.memoryfield.zip` をお勧めします。Soapstones は私が以前取り組んでいたエージェントの記憶に関するプロジェクトで、このキュレーションされたエクスポートには、データへのアクセス方法（エージェントとしての Reddit 検索、Jina Reader の利用、MediaWiki API を用いたウィキの効率的な読み込みなど）に関する高価値な情報が多数含まれています。

「これは単なる RAG ではないか？」という疑問とその他の一般的な反論

これは単なる RAG ではありませんか？

「RAG」という用語は現在、非常に広義に解釈されるようになりました。エージェントがデータを取得する瞬間を指すだけで、「RAG が発生した」と言われるほどです。

しかし、実際にはほぼすべてのエージェントがデータ検索を行っています。例えばウェブを検索することもその一例です。ただ、通常「RAG システム」と呼ばれる際に想定される技術の多くは、ここでは適用されていません。チャンク分割も、再ランク付けも、ハイブリッド検索も存在しません。

一方で、記憶を記述するのはエージェント側であるという点も重要です。RAG システムが主に「読み込み」に焦点を当てるのに対し、memoryfields は「書き込み」にも対応しています。

nomic-embed-text-v1.5 はすでに 2 年以上前のモデルではありませんか？もっと新しい、優れたモデルはないのでしょうか？

埋め込みモデルは最先端の大規模言語モデルほど巨大ではなく、また急速に進化しているわけでもありません。`nomic-embed-text-v1.5` は、小ささと高性能さのバランスが優れており、現在も広く推奨されるデフォルトの埋め込みモデルです。サイズは 270MB と軽量で、GPU を必要としないハードウェアでも高速に動作します。

ただし、この仕様では他の埋め込みモデルの使用も可能です。

良い記憶とはどのようなものですか？また、不要な情報でメモリを埋め尽くさないためにはどうすればよいのでしょうか？

これはメモリシステムに対する一般的な懸念ですが、memoryfields ではあまり問題になりません。関連性の低い情報は、意味検索によって自動的にフィルタリングされ、表示されることはありません。確かに無関係な記憶は容量を消費しますが、定期的に整理する必要があるかもしれません。しかし、それらがエージェントの動作に支障をきたすことは決してありません。

最適な結果を得るには、メモリーフィールドに積極的に情報を追加してください。私が特に推奨するのは、メモリーに引用元を含めることです。できれば URL 形式で記載すると、後からそのメモリーを検証する際や、古くなったり不審な情報を見つけたりした際に、事実確認がしやすくなります。

セキュリティはどうなるのでしょうか？また、「無視せよ」という指示（Disregard that!）への対応は？

信頼できない相手とは、コンテキストウィンドウを共有してはいけません。メモリーを通じてでも同様です。

仕様に静的な zipfile 形式が含まれている理由の一つは、外部から受け取ったメモリーフィールドを手動でレビューし、sha256sum を用いて固定（ピン留め）できるようにするためです。

なお、現在も「良いプロンプト」と「悪意のあるプロンプト」をエージェントが区別する方法はありません（参照）。

データファースト

フローチャートが明確になったので、あえて明言しておきましょう。

• メモリーは Markdown で記述する
• 埋め込みベクトルを SQLite に保存する
• セマンティック検索でメモリーを検索・再発見する

このメモリーシステムの特徴は、プロセスではなくデータ構造を定義している点にあります。抽出パイプラインも、バックグラウンド処理サービスも、プラグイン機能も存在しません。ベクトルインデックスはありますが、これは削除可能なキャッシュであり、システムの核ではありません。

メモリーとは「データ」です。エージェントとデータの間に固定された機構を最小限に抑えるほど、エージェントの性能は向上します。

連絡先など

ノート

もしお時間があれば、ぜひ以下の仕様書をご覧ください。

spec

この仕様の人間によるレビューは、非常に貴重です。

私のインストール手順では、カウントすると4つの異なるパッケージマネージャー（Ollama, uv, NPM, Vercel Skills）を使用しています。もっと良い方法があるはずです。その答えをポストカードでいつもの住所へ送ってください。