AIエージェントの長期記憶は、専用のメモリ基盤やベクトルDBを立てずに「ただのファイル」で持てるのか？——結論から言うと、MarkdownとSQLiteキャッシュだけで持てる、というのが2026年8月31日に公開されたCal Paterson氏のエッセイ「Agent memory as a file format」の主張です。氏が提案する「memoryfield」は、YAMLフロントマター付きMarkdownページの集合をzipにまとめただけの可搬フォーマットで、Hacker Newsで190ポイント・93コメントを集めて大きな議論になりました。何が提案され、どこが評価され、どこが疑問視されているのか。日本でエージェントを運用するチームの視点で読み解いていきます。
何が公開されたのか——「memoryfield」という提案
公開されたのは、ソフトウェアエンジニアのCal Paterson氏による技術エッセイと、それに付随する一式のツール群です。エッセイの副題は「Memoryfields – a vastly simpler way to do agent memory（エージェントメモリをはるかに単純にやる方法）」。2026年8月31日に公開され、同日Hacker Newsに投稿されて190ポイントを獲得しています。
提案の核心は一文で要約できます。エージェントの記憶は「処理パイプライン」ではなく「データフォーマット」であるべき、というものです。Paterson氏はFred Brooksの有名な言葉を引きます。
「フローチャートを見せられてテーブルを隠されたら、私は困惑し続けるだろう。テーブルを見せてくれれば、フローチャートはたいてい要らない。自明だからだ」（Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.）
つまり、抽出パイプラインや常駐サービスやプラガブルなAPIを積み上げるのではなく、「記憶がどういうデータとして置かれているか」だけを定義すれば十分だ、という立場です。エッセイにはRFCスタイルの仕様書、CLIツール（memoryfield-tool）、エージェント用スキル（memoryfield-skill）、デモ用のmemoryfield（soapstones.memoryfield.zip）が添えられており、単なる思想エッセイではなく動く実装込みの提案になっています。
Paterson氏は既存のメモリシステムを3類型に分けて批判しています。整理すると次の通りです。
| 類型 | 特徴 | Paterson氏の指摘する問題 |
|---|---|---|
| ハーネス囲い込み型 | 特定のエージェント実行環境（ハーネス）に記憶が紐づく。多くはモデルを提供するラボ製 | ラボが「API業」から「プラットフォーム業」へ移行するためのロックイン。記憶を持ち出せない |
| 複雑パイプライン型 | 抽出・チャンク化・加工の多段パイプラインを備えた大掛かりなシステム | 運用が大変なだけでなく、モデル自身を混乱させる。モデルの進化にも追従できない |
| High Modernist型 | ナレッジグラフや論理命題で「理想化された記憶」を構築する | 文脈情報が体系的に削ぎ落とされる。「蒸留された事実」のリストにどれほどの価値があるのか |
この3類型批判は、Mem0やZepのようなマネージドメモリサービス、Neo4jやpgvectorを使った自前構築の両方に矢が向いています。既存プロダクトの詳しい比較はMem0・Zep・LangMemの比較ガイドで扱っているので、対立軸を押さえたい方はあわせて確認してみてください。
フォーマットの中身——zipの中はMarkdownだけ
では、memoryfieldの実体はどうなっているのでしょうか。エッセイに示されている構造をそのまま引用します。1つのmemoryfieldは、次のようなzipファイルです。
my-memories.memoryfield.zip
├── carbon-fibre-woks.md
├── finnish-bureaucracy-tips.md
├── [... 多数のmdファイル ...]
├── wec-2026-season-notes.md
└── nomic-embed-text-v1.5.sqlite3
構成要素は3つだけです。
- Markdownの「ページ」——記憶の本体。エージェントが散文で直接書く
- YAMLフロントマター（任意）——タイトル、作成・更新日時、UUID、要約などのメタデータ
- SQLiteのベクトルインデックス（任意）——セマンティック検索用。ただし後述の通り「消してよいキャッシュ」扱い
各ページの先頭に付くフロントマターの例も仕様に示されています。
---
title: Carbon Fibre Woks
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
---
（以下、Markdownの本文が続く）
注目すべきは、ベクトルインデックスの位置づけです。エッセイは「ベクトルインデックスはあるが、それは削除可能なキャッシュであってシステムではない。記憶はデータだ！（Memory is data!）」と明言しています。埋め込みモデルにはnomic-embed-text-v1.5が既定として指定されており、270MBと小さくGPUなしのハードウェアでも動くこと、広く使われている定番であることが選定理由です。ただし仕様上は他の埋め込みモデルへの差し替えも許容されています。
4つの設計判断を読む
エッセイの中核は、4つの設計判断（Design decision）の説明です。それぞれ、実務でエージェントのメモリ設計をした経験がある人ほど刺さる内容になっています。
判断1: チャンクや「事実」ではなく、散文で書く
RAGパイプラインが複雑になる主因は、「人間向けに書かれた既存文書の山をエージェントに読める形にしよう」とするからだ、とPaterson氏は指摘します。memoryfieldsでは発想を逆転させ、エージェント自身が最初からMarkdownの散文として記憶を書くため、チャンク分割も事実抽出も不要になります。
制約は1つだけ。各ページはベクトル埋め込みに収まる必要があるため、1ページあたり約8KB（約2,000トークン、英文で約1,300語）のソフトリミットがあります。エッセイはこれを「中編の雑誌記事くらいの長さ」で、むしろ課すべき健全な制約だと評価しています。詳細を足したければページを増やせばよく、エージェントはそれを苦にしない、と。
判断2: グラフ探索ではなく、セマンティックジャンプ
先行事例として挙げられるのが、RoamやObsidianを模したハイパーリンク付きMarkdown群「Karpathyウィキ」です。エージェントがリンクをたどって知識グラフを歩く発想ですが、実際にやらせると遅くて不確実で、エージェント自身が混乱する、というのが氏の観察です。エッセイに示されたグラフ探索のアルゴリズムを見ると理由が分かります。
# ナレッジグラフを歩くエージェントの動き（エッセイの記述を整理）
1. ウィキのトップページを読む [ツールコール] 関連リンクを探す
2. リンク先ページを読む [ツールコール] さらにリンクを探す
3. 十分な情報が集まったか判断。足りなければ2へ戻る
# → 目的の情報がNステップ深くにあれば、N+1回のツールコールが必要
これに対してセマンティック検索なら、最大2回のツールコール（1回目で検索、2回目で該当ページ群を並列読み込み）で関連ページに直接ジャンプできます。遅延が減るだけでなく、探索途中で無関係な情報をコンテキストに流し込まずに済む点も利点として挙げられています。
判断3: 仕組みを減らし、モデルに任せる（More model, less mechanism）
専用APIやデータベースを多く備えた「high mechanism」なメモリシステムでは、エージェントはインターフェースの迷路を抜けなければ目的を果たせません。インターフェースが大きければ大量のopenapi.jsonがコンテキストを圧迫し、小さければできることが制限される。どちらに転んでも損です。
memoryfieldsは「ただのファイル形式」という低い機構（low mechanism）に徹することで、エージェントに自由なアクセスパターンを許します。エッセイには実例として、エージェントがgrepで全コーパスを走査したり、記憶の中にインラインCSVを置いてSQLiteでクエリしたりする様子が「実際に目撃した使い方」として紹介されています。モデルが賢くなるほど新しい使い方を発明する——つまりフォーマットがモデルの進化と一緒にスケールする、というのがこの判断の狙いです。
判断4: オープンで可搬、トランスポート非依存
記憶は溜まるほど貴重な資産になります。「学んだ教訓と苦労して確立した事実の宝の山」を、特定のハーネスやモデルにロックインされたくない。だからこそ静的なzipファイルを正準形式とし、ローカルファイル、Amazon S3、GitHub、HTTPなど「ファイルが置ける場所ならどこでも」配信できる設計になっています。Paterson氏自身は個人用にSyncthing、共有用にS3を使い分けているそうです。
Hacker Newsの受け止め——支持と手厳しい懐疑
ここからはコミュニティの反応です。一次情報である本文とは区別して読んでください。190ポイント・93コメントというスコアは、エージェントメモリという主題への関心の高さを示す一方、コメント欄は賛否がくっきり割れました。
共感・支持側の代表格は、実際に似た構成へ収斂したという実務者の声です。あるユーザー（pavo-etc氏）は「自分のエージェント群でも似たようなローファイ解に行き着いた。シンプルなクエリ付きMarkdownウィキはメモリシステムとしてそこそこ有効」と述べ、セッションを長期的な教訓に要約するスキルの整備が一番のアンロックだと付け加えています。仕様を読んだ上で「理解しやすく筋が通っている」と評価する声もありました。
懐疑側はより辛辣です。「Markdownだと言うのにずいぶん長文だな」（JustFinishedBSG氏）という一刀両断から、「非構造化なメモリファイルの寄せ集めが正解だとはまったく思えない」（pietz氏）という設計思想レベルの反対まで。特に重要なのは、エッセイの「無関係な記憶はセマンティック検索で浮上しないから、ゴミが溜まっても問題ない」という主張への反論です。あるコメント（docheinestages氏）は「これは完全に間違っている。このアプローチのアキレス腱はまさにRAGだ。古い・誤った・幻覚由来の記憶が大量にあると事態は悪化する。キュレーションされたデータに勝るものはない」と、記憶の定期的な見直し・圧縮・清掃の必要性を指摘しました。「記憶とは検索の問題だけでなく、何をいつ取り出すべきかを知る問題でもある」（skapadia氏）という補助線も本質を突いています。
「毒された1行が下流のすべてに悪影響を与えるから、そもそも自動メモリを使わない」という運用者の声もあり、「書き込みは簡単になったが、記憶の品質管理は依然として未解決」というのがコメント欄の最大公約数と言えそうです。
日本のエージェント運用チームにとっての意味
このニュースを「海外の面白エッセイ」で終わらせず、自社のエージェント運用に引き付けて考えると、論点は3つあります。
ロックイン回避の具体的な選択肢が増えた
各社のエージェント基盤に組み込みのメモリ機能は便利ですが、そこに溜めた記憶は基本的に持ち出せません。モデルやハーネスを乗り換える判断をした瞬間、蓄積した運用ノウハウが宙に浮きます。memoryfieldsのような「ただのzip + Markdown」という選択肢は、極端に言えばvim（あるいはメモ帳）で開けて、diffが取れて、Gitで履歴管理できる記憶です。ベンダー選定をやり直す可能性がある2〜3年スパンの計画を持つ企業ほど、この可搬性の価値は大きくなります。
監査可能性——「エージェントが何を覚えているか」を人間が読める
エンタープライズ導入で必ず問われるのが「AIが何を根拠に動いているのか説明できるか」です。記憶が不透明なマネージドストアの中にあると、この説明は難しくなります。Markdownファイルの集合なら、情報システム部門やリスク管理部門がそのままレビューでき、問題のある記憶を特定して削除する運用も現実的です。HNコメントが指摘した「記憶のキュレーション」の課題は、裏を返せばファイル形式ならキュレーションが人間の手でできるということでもあります。
セキュリティは自己責任の度合いが上がる
一方で注意も必要です。エッセイ自身が「信頼できない相手と、記憶を含むコンテキストウィンドウを共有してはならない」と明記しています。他者から受け取ったmemoryfieldは、エージェントのコンテキストに直接流れ込む文書、すなわちプロンプトインジェクションの経路になり得るからです。仕様が静的zipを正準形式にしている理由の1つは、受け取ったファイルを人間がレビューし、sha256sumでピン留めできるようにするためだと説明されています。この論点はプロンプトインジェクション対策の多層防御で整理した「外部由来テキストは信頼しない」原則の適用対象が、Webページから「記憶ファイル」にまで広がったと理解するのが正確です。
手元で試す3ステップ
検証環境で試すためのセットアップは3コマンドです。前提としてOllama、uv、npx（npmに同梱）が必要になります。以下はエッセイに記載されている公式手順です。
# 動作要件: ollama, uv, npx（npm同梱）
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
# 1. 埋め込みモデルを取得
ollama pull nomic-embed-text
# 2. CLIツールをインストール
uv tool install git+https://github.com/calpaterson/memoryfield-tool
# 3. エージェント用スキルをインストール
npx skills add calpaterson/memoryfield-skill -g -y
ポイントは次の通りです。
- 埋め込みモデル（nomic-embed-text-v1.5）は270MBで、GPUなしのマシンでも動作します。検証はノートPCで十分始められます
- デモ用に、Paterson氏の過去プロジェクトから記憶をキュレーションした「soapstones.memoryfield.zip」が公開されており、空の状態から始めなくても検索の挙動を確かめられます
- 仕様書（RFCスタイル）が公開されているため、既存ツールを使わず自分のエージェントスタックに合わせて実装する道も開かれています
検証で見るべきは「検索が当たるか」だけではありません。むしろ1〜2週間運用した後の記憶ファイルを開いて、人間が読んで有用だと思える内容が書かれているかを確認してください。HNの議論が示した通り、書き込み品質こそがこの方式の成否を分けます。
【要注意】導入時につまずくポイント
つまずき1: 記憶の書き込み基準を決めずに始める
❌ 「覚えておいて」とだけ指示し、何でも記憶させる
⭕ 「複数セッションで再利用する確定事項のみ」「推測・途中経過は書かない」など書き込み基準を先に決める
なぜ重要か: HNコメントで最も強く指摘された弱点が、幻覚由来・期限切れの記憶の蓄積です。セマンティック検索は「関係ない記憶」は拾いませんが、「関係あるが間違っている記憶」は拾ってしまいます。
つまずき2: 8KBのページ制限を無視して長大ページを作る
❌ 1つのMarkdownにプロジェクトの全経緯を書き足し続ける
⭕ 約8KB（約2,000トークン）のソフトリミットを守り、トピックごとにページを分割する
なぜ重要か: ページ全体が1つのベクトル埋め込みになる設計のため、長大ページは検索精度をそのまま毀損します。詳細が必要ならページを増やすのが仕様の想定です。
つまずき3: 外部から受け取ったmemoryfieldを無検査で読み込む
❌ 共有されたzipをそのままエージェントに接続する
⭕ 中身のMarkdownを人間がレビューし、sha256sumでハッシュをピン留めしてから使う
なぜ重要か: 記憶ファイルはコンテキストに直接注入されるため、悪意ある指示文を仕込まれるとエージェントの挙動を乗っ取られる恐れがあります。エッセイ自身が「信頼できない相手とコンテキストを共有するな」と警告しています。
よくある質問
Q. Mem0やZepのようなメモリサービスは不要になりますか？
A. 現時点では用途次第です。memoryfieldsは可搬性・監査性・シンプルさに強みがありますが、マルチユーザーでの権限管理や大規模運用の機能は自分で作り込む必要があります。マネージドサービス側の強み・弱みはMem0・Zep・LangMem比較を参照してください。
Q. 短期記憶・エピソード記憶のような分類とはどう関係しますか？
A. memoryfieldsが扱うのは、セッションをまたいで残す長期記憶の「保存形式」です。何を短期に留め、何を長期化するかという設計論はフォーマットとは独立の問題で、エージェントメモリの設計（短期・長期・エピソード）で整理した考え方がそのまま適用できます。
Q. 埋め込みモデルはnomic-embed-text-v1.5固定ですか？
A. 既定はnomic-embed-text-v1.5ですが、仕様上は他の埋め込みモデルの使用も許容されています。インデックスのSQLiteファイル自体が「削除可能なキャッシュ」扱いなので、モデルを替えて再生成する運用が可能です。
要点の整理
- Cal Paterson氏が2026年8月31日、エージェント記憶の可搬フォーマット「memoryfield」を提案。Markdownページ＋YAMLフロントマター＋SQLiteベクトルインデックス（削除可能なキャッシュ）のzipという極めて単純な構成
- 設計判断は4つ——散文で書く（1ページ約8KB）、グラフ探索ではなく最大2ツールコールのセマンティック検索、仕組みを減らしモデルに任せる、オープンでトランスポート非依存
- Hacker Newsでは190ポイント・93コメント。可搬性と単純さへの共感の一方、「記憶の品質管理（キュレーション）は解決していない」という手厳しい指摘が集まった
- 日本企業にとっての意味は、ロックイン回避の選択肢と監査可能な記憶。ただし外部由来memoryfieldはプロンプトインジェクション経路になるため、レビューとハッシュ検証が前提
次のアクションとしては、まず検証環境で公式ツールとデモ用memoryfieldを動かして検索の挙動を確かめること。次に自社エージェントに1〜2週間書き込ませて記憶ファイルの品質を人間の目でレビューすること。その上で、既存のマネージドメモリと比較して移行・併用の判断をする、という順序をおすすめします。
あわせて読みたい:
参考・出典
- Agent memory as a file format — Cal Paterson（参照日: 2026-09-02）
- Hacker News: Agent memory as a file format（190pt・93コメント） — Hacker News（参照日: 2026-09-02）
- calpaterson/memoryfield-tool — GitHub（参照日: 2026-09-02）
- calpaterson/memoryfield-skill — GitHub（参照日: 2026-09-02）
著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』。
この記事を読んで導入イメージが固まってきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。
