Japanese Translation:

現在、AI エージェントシステムは、「健忘症」に頻繁に見舞われる問題を抱えています。これは、過去の対話を絶対的な真実として扱うためにベクターデータベースに依存しており、コードベースの急激な変化を考慮できていないためです。既存の市場ソリューションでは、この問題を複雑な圧縮層やマルチティアメモリ、バックグラウンドデーモンなどの追加機能で修正しようとするものが多いですが、すべて共通する核心的欠陥があります：つまり、不透明な埋め込み空間に過去の情報を記録・想起させ、アクセス可能なドキュメントを提供していない点です。この非可視的な想起に基づく Retrieval-Augmented Generation（RAG）への依存により、エージェントは自分が知っている内容を監査できず、陳腐化した情報を特定することも、それらの機能を事前に知る必要があるため特定の特徴を検索することもできません。

提案される解決策は、この不都合なモデルから、「Operator Memory」プラグインを使用する透明性の高いドキュメントベースのワークスペースへの移行です。数百万トークンを埋め込み空間に保存するのではなく、システムは指示書、仕様書、調査報告、インデックスなどのプレーン Markdown ファイルを管理し、「プロンプト → 照会 → 構築 → 更新」という持続可能なループの中で運用します。これは従来の「プロンプト → 構築 → 忘れる」サイクルに代わるものです。ベクター埋め込みよりも読みやすいドキュメントを優先し、バックグラウンドデーモンや高価な埋め込み空間の必要性を排除することで、エージェントは機能を正確に見つけることができ、プロジェクトの目標を理解し、監査可能な知識ベースを維持できます。ユーザーは、人間が読める形式で、この進化する理解を自由に読み、更新し、コミットし、共有することができます。このオープンソースの方法論は、すでに 1 年以上にわたって成功裏に導入されており、https://github.com/aerovato/operator-memory で利用可能です。

メモリプラグインの再考：想起ではなく「ドキュメンテーション」による会話分析

現状の問題点とアーキテクチャの限界

現在のシステム（メモリプラグイン）は、以下のようなプロセスを採用しています。

孤立したスニペットの生成: 1,000 個のスニペットを作成し、ベクトルデータベースに挿入する。
類似度検索による注入: プロンプトに対して上位 5 つのスニペットを自動で付与する。
手動検索の依存: エージェントが混乱した場合のみ、追加の手動検索を行う。

しかし、このアプローチには本質的な欠陥があります。

理解ではなく宝くじ方式: プロジェクトの本質（機能の位置づけ、理由、合意事項）を理解させるのではなく、ランダムな RAG スニペットを注入する「宝くじ」に近い仕組みになっています。
「混乱している」エージェントへの依存: エージェントが実際には混乱していても、それを前提とした設計になっており、本質的な解決になり得ません。
誤った問題の解決: 「メモリ不足」という仮定に基づき、事実上**「ドキュメンテーション」**が必要な問題を間違った方向に向かわせています。

既存なメモリプラグインの共通欠陥

市場に出ているあらゆるメモリプラグインは、基本的に同一の欠陥のあるアーキテクチャを採用しています。

セッショントランスクリプトの巡回
「メモリー」となるスニペットの生成
RAG データベースへの挿入
各プロンプトでの上位 5 つ検索と注入
必要に応じた文字単位のツール検索（追加機能）

これに多層化メモリ、背景デーモンによる管理、「夢見る」エージェントによる overnight 更新などの高度な機能が加わっても、基となるアーキテクチャの欠陥は修正されていません。その結果、トークンの浪費と信頼性の低下を招いています。

想起（Recall）方式固有の問題点

すべてのメモリプラグインが以下の問題に直面しています。

類似度だけでは不十分: シミュラティ検索は埋め込み空間での距離のみを考慮し、「何が正しいか」「現在何が起こっているか」は判断できません。
文脈の欠如: スニペットには情報量の限界があり、動機や教訓、環境などの重要な文脈が失われます。
「真実」としての過去の固定化: コードベースは日々変化するため、古いスニペットはすぐに陳腐化します。エージェントは検索ツールを「いつ使うべきか」判断できません。
監査不可能な蓄積物: 埋め込みデータが大量に蓄積しても、何が有効で何が誤りかは不明確であり、エージェントの動作に悪影響を与えています。

これらの問題はすべて**「エージェントは忘れる」という前提**に基づいています。「記憶するためにはより多くのデータを捕捉・索引化する」という思考は、根本的な解決策ではありません。

解決策：想起ではなく「ドキュメンテーション」

人々は過去の失敗（3 年前のミーティングなど）を再検索するのではなく、記録を残して活用することを通じて対応しています。AI でも同様です。

単一ファイルでは不十分:
```
AGENTS.md
```
などの単一ファイルはプロジェクトの唯一のドキュメントとなることは稀ですが、多くの場合それが限界です。
「Entire Brain（完全な脳）」の必要性: エージェントには、指示書、仕様書、意思決定プロセス、調査結果などを網羅した構造化されたワークスペースが必要です。

オペレーター・メモリによるアプローチ

このシステムは、以下のように機能します。

プロンプト → 構築 → 忘却 のループを断ち切り、プロンプト → コンサルテーション → 構築 → 更新へ転換させます。
エージェントは作業前に「脳」から関連文書を読み取り、作業後は陳腐化しているものを更新して新しいドキュメントを追加します。
全体像は常にコンテキスト内に保たれます。

実践テスト：Operator Memory

AI プログラミング経験が浅い頃から試行錯誤を重ねてきた結果、以下のシステムを確立しました。

コアコンセプト

internal/
フォルダの活用: エージェントに仕様書、計画、索引などをすべて書き留めさせることでセッションを超えて知識を共有します。
常套手段としてのドキュメント管理: 作業前には必ず「脳」を検索・相談し、作業後には更新するタスクとして定着させました。

Operator Memory の特徴

Operator Memory は、以下の原則に基づいています。

ドキュメントベースのメモリ: ベクトルデータベースや埋め込みは使用しません。
明確な「脳」の提供: Markdown で構成された指示書、仕様書、調査結果を永続化します。
能動的な更新サイクル: 作業前・後に常に文書の検索と更新を行います。
不要な複雑さの排除: サマライザ、キュレータ、バックグラウンドデーモン、ブラックボックス的な検索ツールは一切使用しません。

このアプローチにより、すべての知識はあなたが読み、更新し、コミットしてチームと共有できるプレーンな Markdown ドキュメントとして管理されます。

利用方法

このシステムを無料でオープンソースで利用できます：

https://github.com/aerovato/operator-memory

エージェントには記憶よりも文書化が必要です