エージェントにメモリは不要：ドキュメントベースのコンテキストのすすめ

RAGベースのエージェントメモリの失敗

現在のAIエージェントの「メモリ」プラグインのほとんどは、Retrieval-Augmented Generation（RAG）に基づく欠陥のあるアーキテクチャに依存しています。このアプローチは通常、セッションのトランスクリプトを分析し、孤立した「メモリ」スニペットを生成し、それらをベクターデータベースに保存し、最も類似したスニペットの上位数件をすべてのプロンプトに注入するというものです。

このアーキテクチャは、メモリをプロジェクトの構造化された理解ではなく、類似性検索の宝くじとして扱うため、失敗します。主な技術的な欠点は以下の通りです：

• コンテキストの欠如： RAGスニペットは孤立した断片であり、元の会話を取り巻く動機、環境、教訓を失っています。
• 類似性 ≠ 正確性： 埋め込みベースの検索は、情報が最新であるか正確であるかではなく、ベクトル空間での数学的な近さによってスニペットをランク付けします。
• 陳腐化： コードベースは日々進化しますが、RAGメモリは不変の真実として扱われることが多く、エージェントが時代遅れの認証方法や非推奨のAPIに依存することにつながります。
• 盲点： エージェントは知らないことを検索できません。エージェントが特定の制約の存在を知らなければ、関連するメモリスニペットの検索をトリガーしません。
• 監査可能性ゼロ： ベクターデータベースはブラックボックスです。どのメモリが存在するか、どれが古いか、どの誤ったスニペットが密かにエージェントの動作に影響を与えているかを人間が監査することはほぼ不可能です。

想起からドキュメント化への移行

想起を通じて過去を「記憶」しようとする代わりに、エージェントには構造化されたワークスペース、つまり「脳」が必要です。そこに指示、仕様、決定、調査を記録できます。これにより、エージェントのループはプロンプト → 構築 → 忘却のサイクルから、より持続可能なプロンプト → 参照 → 構築 → 更新のサイクルに移行します。

ドキュメントベースのシステムでは、エージェントはバックグラウンドデーモンに依存してコンテキストを「夢見る」または圧縮することはありません。代わりに、タスクを開始する前に関連するMarkdownファイルを読んでコンテキストを取得し、タスク完了後にそれらのファイルを更新します。これにより、「メモリ」は、読み取り、更新、バージョン管理（Git）へのコミット、チーム全体での共有が可能な生きたドキュメントであることが保証されます。

実装：オペレーターメモリモデル

この哲学の実用的な実装の1つがOperator Memoryであり、ベクターデータベースをMarkdownベースの脳に置き換えます。このシステムは単純な前提で動作します：重要な知識をプレーンテキストとして永続化します。作業前に、エージェントは脳を参照して関連ドキュメントを取得します。作業後は、古いドキュメントを再訪し、必要に応じて新しいドキュメントを追加します。

コミュニティの視点と代替アプローチ

開発者間の議論では、極端なミニマリズムから複雑な構造化システムまで、エージェントのコンテキストを管理するための戦略のスペクトラムが明らかになっています。

「コードをドキュメントとして」派

一部の開発者は、外部ドキュメントは必然的に陳腐化する「ルーブ・ゴールドバーグ・マシン」であると主張しています。彼らは、コード自体が唯一の真実の源であると主張します：

「コードがドキュメントだ...ドキュメントは常に、コンテキストを持たない人々が始められるようにするためのコードの代用物だった。明らかに、コードを読むこととドキュメントを読むことのコストが同じなら、ドキュメントは完全に無価値だ。」

構造化ワークスペース戦略

他の開発者は、特定のフォルダ構造と専用ファイルを使用してエージェントをガイドすることで成功を収めています：

• ワークベンチパターン： .workbench または internal/ フォルダ（多くの場合git-ignored）を使用し、エージェントが一時的なメモやプロジェクトのマップを書き留めます。
• ハンドオフパターン： STATUS.md または handoff.md ファイルを作成し、エージェントがセッション開始時に読み、終了前に更新することを必須にします。これにより、異なるエージェントセッションや異なるモデル間のシームレスな移行が保証されます。
• ADR（アーキテクチャ決定記録）： 決定が行われた理由の正式な記録を使用します。これにより、エージェントはプロジェクトの最終状態だけでなく、その軌跡を把握できます。
• 原則駆動開発： エージェントが従わなければならない高レベルの原則（例：「JSON解析にはPythonではなくjqを使用する」）を書きます。これは過去のイベントの特定のメモリではなく、ガイドラインです。

ドキュメントベースメモリへの技術的批判

ドキュメントファーストアプローチの批判者は、問題をあるメディアから別のメディアに移すだけかもしれないと指摘します：

• 発見の問題： RAGと同様に、エージェントは情報が存在することを知らなければ、どのMarkdownファイルを開くべきかわからないかもしれません。
• メンテナンスのオーバーヘッド： ドキュメントは積極的なメンテナンスを必要とします。エージェントがドキュメントとコードを照合するように厳密にプロンプトされない場合、ドキュメントは混乱の原因になります。
• トークンコスト： 「脳」が成長するにつれて、複数の大きなドキュメントを読み書きするコストが膨らみ、いくつかのRAGスニペットのコストを超える可能性があります。

要約表：RAGメモリ vs. ドキュメントベースメモリ

機能	RAGベースメモリ	ドキュメントベースメモリ
ストレージ	ベクターデータベース（埋め込み）	プレーンテキスト（Markdown）
検索	類似性検索	明示的な参照/インデックス
監査可能性	低い（ブラックボックス）	高い（人間可読/Git）
真実の源	過去のトランスクリプト	現在の仕様/ドキュメント
更新メカニズム	追加専用/バックグラウンドデーモン	積極的な編集/更新
コンテキスト	孤立したスニペット	構造化されたドキュメント

SUMMARY: AIエージェントは、信頼性の低いRAGベースのメモリプラグインを、構造化された人間が読めるドキュメントに置き換え、監査可能性、正確性、永続的なプロジェクト知識を確保すべきです。

TITLE: エージェントにメモリは不要：ドキュメントベースのコンテキストのすすめ