エージェントのメモリにはOpenTelemetryのような共通標準が必要

AIエージェントのメモリエコシステムは現在断片化しており、各ツールが独自のデータ形状とストレージメカニズムを使用しています。Mads Thines氏は、この状況は2019年以前のソフトウェア可観測性の混沌とした状態を反映しており、異なるエージェント間でコンテキストを効果的に共有するために統一された標準が必要だと主張しています。

何が起きたか

今日の多くの開発環境では、セッション間で情報を保持するために、複数の分断されたシステムに依存しています。典型的な構成には、AGENTS.mdやCLAUDE.mdなどの指示ファイル、/memoriesなどのエージェント管理ディレクトリ、GitHub Copilotなどのサービスから提供されるホスト型ファクト、そしてModel Context Protocol (MCP) サーバーによって維持される個別のナレッジグラフが含まれます。これら4つの一般的なアプローチはお互いのデータを読み取ることができないため、継続的インテグレーション（CI）エージェントが得た洞察は、エディターエージェントや後続のツールからは見えなくなります。

この断片化によりカスタムソリューションが急増し、開発者は特定のギャップを埋めるために独自のメモリレイヤーを頻繁に構築しています。個々の形式は論理的に正しくても、結果として基本的な概念（アドレスに保存され、一定期間有効なノート）の冗長な再構築が生じています。根本的な問題はツールの不足ではなく、コミュニティ全体での共有データモデルに関する合意の欠如です。これは、可観測性セクターがOpenTelemetryの作成を通じて成功裏に解決した問題です。

仕組み

2019年以前、可観測性ベンダーは独自のエージェント、計装ライブラリ、データ形式を作成して競い合い、ユーザーのプロバイダー変更を困難にしていました。業界はこの問題を、OpenTracingとOpenCensusを統合してOpenTelemetryを設立することで解決しました。これにより、スパンとメトリクス向けの統一データモデル、命名のためのセマンティック規約、OTLPと呼ばれる単一のトランスポートプロトコル、そして共有SDKなどの参照実装という4つの重要な合意層が確立されました。その後、ベンダーはデータ収集ではなくストレージと分析で競うようになり、ユーザーはコードを一度計装するだけで済むようになりました。

エージェントのメモリには、現在この基礎的な合意がありません。提案されている共有仕様は、グローバル、プロジェクト、リポジトリなどの標準的なアドレスレベルを定義し、属性に対するセマンティック規約を確立することで、OpenTelemetryのアプローチを模倣します。また、MCP経由で公開される書き込み、読み取り、検索などの基本操作に対する契約も定義しますが、ストレージ、ランキング、ユーザーインターフェースの決定は個々のベンダーに委ねます。この分離により、ツールはデータ構造上で相互運用できつつ、付加価値機能で競うことが可能になります。

主要な詳細

• 現在のメモリ形式には、指示ファイル、エージェント管理ファイル、ホスト型リポジトリファクト、コンテキストブロック、抽出ファクト、名前空間付きストア、ナレッジグラフが含まれますが、これらは相互に読み取りできません。
• OpenTelemetryは、データモデル、セマンティック規約、プロトコル、参照実装について合意することで成功し、ベンダーがデータ収集ではなくデータ利用で競えるようにしました。
• Portable Memory、Open Memory Protocol、COGXなどの既存の提案は、主にベンダー間でのデータエクスポートに焦点を当てており、ライブかつ同時並行的なアドレッシングの実現には至っていません。
• 提案されているメモリレコード構造には、アイデンティティ、アドレス、キー、コンテンツタイプ、ライフサイクル、属性などのフィールドが含まれ、実際のメモリコンテンツは別々に保存されます。
• 仕様では、人間またはエージェントなど、誰がメモリを書き込んだかを記録すべきです。これにより、読者が信頼性を評価し、プロンプトインジェクションリスクを軽減できます。
• LoreKitは、共有標準の開発に向けた具体的な入力として、そのスキーマとディスク上の形式をMITライセンスの下で提供しています。

なぜ重要なのか

エージェントワークフローを構築するエンジニアにとって、現在の標準化の欠如は、コンテキストが特定のツールやベンダー内にサイロ化されることを意味します。これにより、あるコンポーネントで学んだ教訓を手動介入や複雑なカスタム統合なしには別のコンポーネントで活用できないため、エージェント間の効果的なコラボレーションが妨げられます。エージェントツールの数が増えるにつれて、これらの分断されたメモリシステムを維持するコストが増大し、開発努力の重複や一貫性のないユーザー体験につながります。

共有標準を採用すれば、開発者はエージェントを一度計装するだけで、異なるプラットフォームやツール間でシームレスに動作させることができます。これにより、ベンダーが独自データ形式へのロックインではなく、より優れた検索アルゴリズムやユーザーインターフェースなどの高度な機能で競い合う、活発なエコシステムが可能になります。この転換はベンダーロックインを減らし、チームが歴史的コンテキストを失ったり、メモリインフラを再設計したりすることなく新しいツールを導入しやすくします。

あなたができること

• 現在の開発環境を監査し、エージェントメモリが保存されているすべての場所を特定し、それらの間の非互換性をメモしてください。
• Portable Memory、Open Memory Protocol、COGXなどの既存の提案を確認し、データエクスポートとシリアライゼーションに対する彼らのアプローチを理解してください。
• npx @lorekit/cli installを実行してLoreKitのオフラインストアを試験し、プレーンなMarkdownファイルが構造化されたメモリレコードをどのように表現するか調べてください。
• 現在のツールによって生成されるメモリレコードを提案された構造と比較し、あなたのユースケースに必要なフィールドや属性の欠落を特定してください。
• ライブアドレッシングや信頼メカニズムに焦点を当て、共有フォーマットがサポートすべき要件についてフィードバックを共有することで、コミュニティに参加してください。
• Linux FoundationのAgentic AI Foundationなどの中立的な場での議論への貢献を検討し、新興標準の形成を支援してください。