エージェント記憶（Agent Memory）のための共有形状について：OpenTelemetry の教訓と合意の形成

現状：断片的な記憶管理の課題

現在、開発者ツールは「思い出」を保持する際、互換性のない異なる形式を採用しています。これらは 4 つの主要なカテゴリに分けられますが、相互に読み込むことができません。

• 指示ファイル：多くのリポジトリに存在する

  AGENTS.md

  や

  CLAUDE.md

  、および Cursor の

  .cursor/rules/*.mdc

  など。
• エージェント管理用ファイル：Anthropic の記憶ツールなどが

  /memories

  ディレクトリにファイルを配置するケース。
• ホスティングリポジトリ事象：GitHub Copilot Memory が各リポジトリに関する事実を保持する形式。
• 知識グラフ（MCP サーバー）：JSONL 形式の知識グラフを管理する記憶対応の MCP サーバー。

現在の壁と本質的な問題

• 互換性の欠如：CI ジョブで学習された教訓は、記述された環境以外では利用できません。エディターエージェントも他のツールもこれらを相互に読み込めず、結果として「単一の小さなアイデア（エージェントのメモ）」を何度も再構築しなければなりません。
• 孤立した解決策：コミュニティには独自なストレージ、スキーマ、MCP ツールを持つ記憶レイヤー構築案が絶えず登場しています（例：

  r/ClaudeAI

  ,

  r/LocalLLaMA

  等）。これは問題が実在する決定的な証拠です。
• 問題の本質：新しい解決策が加わるたびに、互換性の壁は増えるのみ。**不足しているのはツールではなく、「合意（アグリーメント）」**です。

LoreKit とは？ 著者は「LoreKit」というオープンソースツールを開発していますが、これが記憶問題の完全な解決策であると主張するものではありません。これは単なる形状の一つであり、独自に持つギャップも存在します。重要なのは、今こそ共有される形状について合意する時だということです。

歴史的教訓：2019 年の可視化業界から

2019 年以前、すべての可視化（Observability）ベンダーは独自のエージェント、ライブラリ、データ形式で競争していました。ベンダーの変更はコードの再インスツルメンテーションを意味しました。この状況を変えるため、OpenTelemetry が統合されました。

OpenTelemetry の成功要因

ベンダー間の競争が止まったことで、以下の 4 つの層について合意が達せられました：

• データモデル：スパン、メトリクス、ログレコードの定義。
• セマンティック規約：共有される名前（

  service.name

  ,

  http.*

  など）。
• プロトコル：データ転送のための単一の方法（OTLP）。
• 参考実装：共有された SDK とコレクター。

ベンダーは依然としてストレージや分析などで競争しましたが、ユーザーは一度インスツルメントすれば他者のデータをすべて読み取ることができました。OpenTelemetry は 4 つのレイヤーについての合意と、残りの処理における競争のバランスが取れた例です。

エージェント記憶（Agent Memory）も同様の進化が必要です。形式はまだ若く、変更可能ですし、Linux Foundation の「Agentic AI Foundation」下で中立な居場所が確保されています（MCP,

AGENTS.md

記憶形状の現状スナップショット（2026 年末時点）

急速に変化する状況ですが、以下の表は現在の主要な形状を分類したものです。

AGENTS.md

CLAUDE.md

/memories

user_id

run_id

既存形式の良い点

いくつかの形式は、共有仕様として維持すべき正しい要素を持っています：

• Copilot Memory：デフォルトで機能する忘却と、検証可能なコード引用の組み合わせ。
• LangGraph：極めてシンプルなコア（

  put(namespace, key, value)

  ）。
• Graphiti：事実が真であった時間と記録時間を分離したタイムラインモデル。
• AGENTS.md：既知パスにおける単純なファイル標準化への道筋を示唆。

すでに存在する提案とその限界

現在、記憶問題を解決しようとする試みとして以下の案があります：

1. Portable Memory (MacPaw Research)：バイト再現可能なシリアライゼーションと削除用トーンストーンを持つ `.mem バンドル」。
2. Open Memory Protocol：会話の派生記憶を ZIP ファイル（マニフェスト付き）でプラットフォーム間移動する仕様。
3. COGX フォーマット (Cognee)：Mem0, Letta, Zep からインポートできる形式。

これらの提案は主にエクスポート（輸出）、すなわちベンダー間の記憶移動を解決していますが、コード作成ツールには別の課題があります：ライブ・アドレス指定（Live Addressing）。 CI ジョブやエディターエージェントが同時に同じリポジトリで動作する場合、**「誰がどこを読んでいるのか」**という合意が必要です。既存の提案は輸出に焦点を当てており、共有アドレスによる同時操作の問題には十分対応していません。

記憶が答えるべき 4 つの質問

各形状は以下の 4 つの問いに対して異なる答えを与えています：

1. Where is it true（どこで真か）：
   • ローカルファイルなのか、グローバルデータベースなのか。
2. What is its identity（アイデンティティとは何か）：
   • 第二の書き込みは更新か複製か。
3. What does it say（何を言っているか）：
   • メモのコンテンツそのもの。
4. When does it stop being true（いつ真でなくなるか）：
   • 有効期限や忘却機能の有無。

これらについて誰も重要だと反論していません。OpenTelemetry は、異なる答えを持つツール同士を統合し、共通の基盤を作った例です。唯一のフォークは「誰が記憶を書記するか」ですが、これは仕様が特定の起源を選ばず、信頼度の記録方法を選べばよいという点で解決可能です。

提案されたレコード構造（Frontmatter）

以下は、データモデルの図示としてのレコードサンプルです：

---
spec: agent-memory/0.1
id: 8f0c2a6e-4b1d-4c7a-9e2f-3a5b6c7d8e9f
address: { level: repo, value: github.com/acme/checkout }
key: tests-need-local-postgres
kind: lesson
written_by: { type: agent, name: claude-code }
content_type: text/markdown
lifecycle: { expires_at: null, extended_by: write }
attributes: { vcs.pr: 482, ci.run_url: "https://ci.example/runs/123" }
---

Postgres が既に実行されていない限り、統合テストは `ECONNREFUSED 127.0.0.1:5432` で失敗します。`pnpm test` を実行する前に起動してください：

    docker compose up -d db

レコードの構成要素

• Frontmatter（ヘッダー）：アドレスとキー（真の範囲）、ID（アイデンティティ）を定義。
• ライフサイクル：有効期限と更新規則を示す。
• Written_by：フォーク問題を解決し、誰が記述したかを明記。
• Attributes：ツール固有のメタデータはネームスペースに格納され、他ツールの読み取りに影響しない。
• シリアライゼーション：JSON としても変換可能で、ネットワーク転送に適する。

OpenTelemetry 型の仕様構成要素

このレコードを中心に、仕様は以下の 3 つの層を模倣します：

1. 規約（Conventions）：
   • アドレスレベル（グローバル〜リポジトリ）やアトリビュート名空間の共有定義。
2. 契約（Contract）：
   • 固定の入力・出力を持つ少数の操作（書き込み、読み取り、検索など）。MCP を介して公開される。
3. パフォーマンステスト：
   • レコードを往復させ欠落がないか確認し、有効期限や未知アトリビュートの生存を確認。

除外すべき要素：ストレージ、ランキング、埋め込みベクトル、UI。これらは各ツールの競争領域であり、中立な場所には置くべきではありません。

懐疑論者からの反駁への回答

• 「記憶ツールを作りたいなら標準も作りたい」
  • LoreKit はテンプレートではなく「表の一行（実装の一つ）」です。共有仕様が異なる形状であっても、それらを採用すべきです。
• 「MCP 自体がすでに標準だ」
  • MCP は呼び出しを標準化しますが、レコードそのものは標準化していません。OpenTelemetry のように両方が必要です。
• 「共有記憶はプロンプトインジェクションの経路となる」
  • 正しい懸念です。しかし、仕様は「誰が書いたか」を記録し（署名）、依存するコードへのポインタを提供することで可視化・防衛します。毒を完全に防ぐことは難しいですが、リスクを管理できます。
• 「別の標準では断片化問題は解決しない」
  • xkcd コミックス #927 の教訓通り、強制統合ではなく既存の正しい部分を拾い上げ、共有部分で合意することが重要です。

未解決の問題（Open Questions）

これらに対する答えはまだ確立されておらず、公開での議論が必要です：

• アドレスレベルの粒度：モノリポはリポジトリとブランチの中間層を望んでいます。固定リストにするべきか？
• 忘却（Forgetting）：デフォルトとするべきか？Copilot は即時削除ですが、LoreKit は保持し、LangGraph は読み取り時に更新です。
• 依存コードへのポインタ：レコードにコードホストの URL を持つことで陳腐化を防ぐべきか？それとも縛りになりすぎるか？
• 調整プロセス：ワーキンググループ、財団、またはドラフト仕様の公開哪一种が適当か？

参加と検証の方法

LoreKit のスキーマは MIT ライセンスで公開されています。他のツールとの比較や、共有フォーマットとして欠けている要素の指摘を歓迎します。

オフラインストアでは、検索可能・差分比較可能なプレーンな Markdown ファイルが生成されます：

npx @lorekit/cli install

既存の提案とこれらを比較し、共通して欠けている機能を特定しましょう。