AIエージェント向けの「memory」が、いまかなりバラバラな形で広がっている。あるものはMarkdownファイル、あるものはJSONLの知識グラフ、別のものはサービスの中に閉じたレコードだ。LoreKitのMads Thinesは、その断片化が観測基盤の世界で起きたこととよく似ていると指摘し、OpenTelemetryのような共通の土台が必要ではないか、と投げかけている。単なる理想論ではなく、すでに複数の提案が出ている今だからこそ、何を共通化し、どこを競争領域に残すのかを整理する意味がある。
元記事がまず示すのは、現場の散らかり方だ。典型的な開発環境では、リポジトリ内の AGENTS.md や CLAUDE.md、Cursor の .cursor/rules/*.mdc のような指示ファイルがあり、Anthropic の memory tool は /memories ディレクトリにファイルを書き込む。GitHub Copilot は GitHub 側にリポジトリごとの知識を持ち、memory MCP server は JSONL の知識グラフを扱う。これだけで、少なくとも四つの異なる形が並んでいることになる。
問題は、どれも「記憶」を持っているのに、互いに読めないことだ。あるエージェントがCIで学んだことは、そのツールの中に閉じる。別のエディタ用エージェントはそれを参照できず、次に試す別製品も同じ壁にぶつかる。著者は、これは単に道具が足りないのではなく、共有された約束事がないからだと言う。しかも利用者が「自分のエージェントに memory layer を作った」と投稿し続けている以上、需要そのものは本物だ。ただ、そのたびに新しい形式が増え、また別のツールから読めないものが増える。
そこで著者は、OpenTelemetry を引き合いに出す。2019年以前の observability は、各ベンダーが独自の agent、instrumentation library、データ形式を持ち、乗り換えるたびに計測をやり直す世界だった。OpenTracing と OpenCensus が別々に解決を試みたあと、OpenTelemetry にまとまったとき、業界が合意したのはデータモデル、semantic conventions、送信プロトコル、参照実装だった。ベンダーはその上で storage や分析で競争すればよくなった。著者は、エージェントの memory も今まさにその前段階にいると見る。
そのうえで、いま存在する記憶形式をざっと並べる。Instruction files は Markdown ファイル全体を、Anthropic の memory tool は /memories 配下のファイルを、Copilot Memory はコード引用付きの fact を、Letta core memory は制限付きの block を扱う。Mem0 は message から抽出した fact に user_id や agent_id などを付け、LangGraph BaseStore は namespace と key を使う。MCP の reference memory server は entity と relation の知識グラフを持ち、Graphiti と Zep は時間軸を意識した graph を扱う。LoreKit 自身は、scope と key と lifecycle を持つ record を提案している。
著者が強調するのは、いま出ている提案の多くが「export」、つまりあるベンダーから別のベンダーへ記憶を移すことに寄っている点だ。だが実際の開発現場では、CIジョブ、エディタエージェント、レビューbotが同じリポジトリで同時に動く。必要なのは引っ越しだけではなく、「今ここを誰がどう書き、誰が読むのか」を同時に扱える live addressing だという。ここに、単なるエクスポート形式では足りないという著者の問題意識がある。
この記事で面白いのは、著者が「フォーマットを一つに決めよう」と雑に言っていないことだと思う。むしろ、何を揃えるべきかをかなり細かく切り分けている。記憶がどこで真実なのか、何がそのIDなのか、同じ内容を二度書いたら上書きなのか複製なのか、いつ失効するのか。この四つを分けて考える姿勢は、かなり実務的だ。AIエージェントの記憶は、ただのメモではなく「いつ、どこで、誰が、何を信じていいのか」の管理だからだ。
個人的には、ここでの本質はフォーマットよりも責任の所在だと思う。人が書く instruction file、モデル自身が書く memory tool、サービスが抽出する Mem0 や Graphiti。書き手が違えば、信頼の置き方も変わる。著者が written_by を明示する案を出しているのは、その差を隠さないためだろう。AIが自動で蓄積したメモは便利だが、何でも同列に扱うと危ない。誰が書いたかを残せば、読む側は「これは人間の指示なのか、モデルの推測なのか、抽出された事実なのか」を判断できる。
逆に言うと、記憶の共通仕様が必要なのは、互換性のためだけではない。誰が書いたかを標準化しないと、後から見たときに、古い推測が事実のように居座る。これはLLM特有の厄介さだと思う。普通の設定ファイルなら、間違っていたら消せばいい。でもエージェントの記憶は、会話や実行ログから静かに増え、別のツールに引き継がれ、いつの間にか意思決定の材料になる。だからこそ、記憶の「来歴」を持つことに価値がある。
OpenTelemetryの話を持ち出したのは、単なる比喩ではない。著者は、観測基盤の世界でも最初は各社が独自に全部を抱え込み、結果として利用者が何度も instrument し直す羽目になったと振り返る。そこから生まれたのが、データモデルとプロトコルを共通化し、上の層で各社が競争する仕組みだった。エージェント記憶でも、今まさに同じ層分けが必要だ、というのが主張の骨格だ。
ここで大事なのは、「標準化されたら面白くなくなる」のではなく、面白さの置き場所が変わるという点だと思う。著者が標準に含めるべきだと考えているのは、address の階層、kind の分類、属性名前空間、write/read/list/search/archive のような基本操作、そして conformance test だ。一方で、storage の実装、検索のランキング、embedding の使い方、UI は競争領域に残すべきだとしている。これはかなり筋がいい。標準が全部を飲み込むと、結局つまらない製品が増える。けれど土台がなければ、毎回ゼロから接続し直すだけになる。
興味深いのは、著者が「MCP だけでは足りない」とはっきり言っているところだ。MCP は呼び出し方を標準化するが、レコードの中身までは揃えない。これは実際、かなり重要な指摘だと思う。APIがあっても、渡されるデータの意味が違えば相互運用は崩れる。OpenTelemetry でも、プロトコルだけでなく data model が必要だった。同じ構図がここでも起きているわけだ。
もっとも、著者自身が反論を先回りしているのも印象的だ。「また標準を一つ増やすだけでは断片化は直らない」という指摘は、その通りだろう。いわゆる xkcd 927 の問題だ。標準は増やすほど良いわけではないし、実装側にとっては新しい仕様が一つ増えるだけにも見える。だからこの記事は、空論としては弱くなりうる。その弱さを自覚したうえで、既存の提案がそれぞれ得意なところを持ち寄るべきだ、と言っているのがポイントだと思う。
それでも、私は共有仕様の議論は始める価値があると思う。なぜなら、今の分断は「機能差」ではなく「データの置き場所と意味の差」だからだ。たとえば LoreKit は plain Markdown のファイルとして書き出せるので、grep も diff もできる。これは運用面ではかなり強い。一方で、Copilot Memory のように引用付きで信頼性を高める方式もあるし、Graphiti のように時間の扱いに強い設計もある。個々の強みを残したまま共通の読み書きだけ揃えられれば、利用者の利便性はかなり上がるはずだ。
ただし、標準化の最大の難所は技術ではなく政治だと思う。誰が仕様を管理するのか、どの address level を採用するのか、忘却をデフォルトにするのか、コードへの参照を必須にするのか。これらは実装上の好みではなく、権限の配り方そのものだ。著者が「どこか中立的な場所で」と書いているのは、その意味で重要だろう。LoreKit でも GitHub Copilot でもなく、Linux Foundation 配下の Agentic AI Foundation のような中立地帯に置くべきだ、という発想には現実感がある。
この話が実際に効くのは、エージェントを本番の作業に入れ始めたチームだと思う。CI、レビュー、リポジトリ保守、ドキュメント更新。こうした場面では、記憶が便利であるほど、誤った記憶の害も大きくなる。標準仕様があれば、少なくとも「このレコードは誰が書いたか」「いつまで有効か」「どのリポジトリやブランチに属するか」を機械的に見られる。これは、エージェントを怖がらずに使うための最低条件に近い。
一方で、標準ができたからといって、記憶の危険が消えるわけではない。著者も明言しているように、shared memory は prompt injection の入口にもなる。誰でも書けるようになれば、汚染の面積も広がる。だからこそ、署名や依存コードへの参照のような仕組みが必要になる、という議論には説得力がある。エージェントの記憶は便利だが、信頼の設計を雑にするとすぐ壊れる。その現実を、この記事はかなり正面から見ている。
私は、この記事の価値は「標準を作ろう」という掛け声より、AIエージェントの記憶を“ただのキャッシュ”ではなく“共有される作業メモ”として捉え直したところにあると思う。メモなら、書き手、場所、期限、信頼度が必要だ。そこを揃えられるかどうかで、エージェントが道具で終わるか、チームの一員として扱えるかが変わってくる。まだ答えは出ていないが、問題設定としてはかなり筋がいい。
参考: Agent memory needs its OpenTelemetry moment — LoreKit blog
