タイプ別にメモリを構造化することで、取得トークンを約40%削減できる

なぜフラットなメモリ・ストアでは限界があるのか

初心者向けのチュートリアルの多くは、新しい情報をすべて単一のリストに追加し、そのリストを毎ターンモデルにフィードバックすることでLLMエージェントに「記憶」させる方法を教えています。コードは文字通りわずか3行で、動作するデモを作成できます。しかし、実運用ではリストは際限なく増大していきます。そこで、2つの問題が発生します。

  • エージェントが古いデータを依然として正しいものとして扱い、例えば数時間前に期限が切れたETA（到着予定時刻）を提示してしまう。
  • コンテキストウィンドウが、回答に全く影響を与えない些末な情報で埋め尽くされ、APIコストの増大とレスポンス時間の低下を招く。

単純なベクトルストアやシンプルなキーバリュー・キャッシュでは、ユーザーの役職と一時的なプロジェクトのステータスを区別できません。エージェントがセマンティック検索を実行すると、たとえそのデータがもはや関連していなくても、クエリに同じ単語が含まれているという理由だけで、類似性アルゴリズムが古いETAを上位に表示してしまうことがあります。

構造化メモリ：4つのバケット、1つの目的

解決策は、メモリを単一の塊（モノリス）として扱うのをやめ、各エントリを以下の4つのカテゴリのいずれかに分類し始めることです。

  • ユーザー情報 (User facts) – ユーザーの役割、優先言語、セキュリティクリアランスなどの安定した属性。これらはめったに変更されないため、セッション全体を通してキャッシュできます。
  • フィードバック (Feedback) – エージェントが遵守すべき明示的なルール（例：「データベースのパスワードは決して明かさない」「コンプライアンスに関する質問ではユーモアを避ける」など）。これらは振る舞いを規定するものなので、検索可能なプールではなくシステムプロンプトに含めるべきです。
  • プロジェクトの状態 (Project state) – 現在のETA、タスクの進捗、一時的なトークンなどの動きの速いデータ。このバケットには有効期限のチェックが必要です。タイムスタンプが定義された期間を過ぎた場合、エントリを削除する必要があります。
  • リファレンス (References) – 外部サービス、ドキュメントID、またはAPIエンドポイントへのポインタ。これらは表示されるべきコンテンツではなく、必要に応じて最新データを取得するためのルートです。

Mem0を使用すると、開発者は各メモリレコードに任意のメタデータを付与できます。「kind」フィールドでインデックスを作成することで、LLMが結果をどのように使用するかを決定する前に、まず関連するバケットをフィルタリングしてクエリを実行できます。

Mem0による2ステップの検索

  1. 種別によるメモリの抽出 – 短いフィルタクエリを使用して、Mem0に「すべてのフィードバック」や「短い間隔より新しいプロジェクト状態のエントリ」を要求します。結果セットは、すでに適切なカテゴリに絞り込まれています。
  2. LLMに判断させる – フィルタリングされたスニペットを、ユーザーの現在の質問とともにプロンプトに挿入します。これにより、モデルは無関係な事実を精査することなく、それらについて推論できるようになります。

具体的な例を挙げます。セマンティック検索によって「データベースを揶揄しない」というルールが浮上するのを待つ代わりに、開発者はセッション開始時にそのルールをシステムプロンプトに直接注入し、インタラクション全体を通してキャッシュします。ユーザーのクエリにデータベースへの明示的な言及が含まれていなくても、モデルはすでにその制約を把握しています。

コストを抑えるための実践的なテクニック

  • フィードバックルールをキャッシュする – ルールセットをセッションごとに一度だけ保存し、毎ターン検索し直すのではなく再利用します。これにより、各ラウンドのトークン使用量を削減できます。
  • 不要なプロジェクト状態の検索をスキップする – ユーザーが純粋に概念的な質問（「教師あり学習と強化学習の違いは何ですか？」など）をした場合、ETAやタスクの進捗データを取得する必要はありません。

これら2つの習慣を適用することで、単純なフラットメモリのアプローチと比較して、トークン使用量を約40%削減できます。この節約は、特に多くのやり取りが行われるエージェントにおいて、API料金の削減とターンアラウンドタイムの短縮に直結します。

恩恵を受けるのは誰か、懸念されるのは誰か

勝者 – カスタマーサポートボット、社内ワークフローアシスタント、またはあらゆるマルチターンLLMインターフェースを構築しているチーム。彼らは、より信頼性の高い回答を得られ、古いデータによる恥ずかしいミスを回避でき、予算をより有効に活用できます。

まとめ

長いセッションを通じて高い精度を維持するLLMエージェントを構築したいのであれば、すべての事実を単一のコンテキストウィンドウに詰め込むのはやめましょう。各メモリに「ユーザー情報」「フィードバック」「プロジェクトの状態」「リファレンス」のタグを付け、必要に応じて有効期限を適用し、Mem0のようなツールに重労働を任せてください。その結果、より新鮮な回答、無駄なトークンの削減、そして運用コストの顕著なカットが実現します。