7月11日、Bala Priya Cが「Choosing the Right AI Agent Memory Strategy: A Decision-Tree Approach」と題した記事を公開した。AIエージェントの開発で「ユーザーが覚えていてほしい情報をエージェントが忘れる」「逆に不要なのに複雑なメモリ基盤を持つ」という正反対の失敗が頻発する根本原因は、メモリ設計の後回しにある。この記事が提示するのは、「エージェント全体でメモリシステムを1つ選ぶ」のではなく、情報カテゴリごとに5つの質問からなるデシジョンツリーを走らせて最適なメモリ層を決めるという判断フレームワークだ。
なぜメモリ設計は失敗しやすいのか
AIエージェント開発では、オーケストレーションの設計には時間をかけるのに、メモリ設計は後回しにされることが多い。その結果、下記のような症状が現場で繰り返されている。
| 症状 | 原因 | 対策 |
|---|---|---|
| すでに教えた情報をエージェントが再度聞いてくる | ワーキングメモリのトリミングが過剰、または要約が必要な情報を落としている | 保持ウィンドウを広げるか要約の質を改善する。長期メモリ追加は不要 |
| 検索結果が無関係または矛盾している | 安定した事実と変化するイベントを同一ストアに混在させている | 事実は構造化ストア、イベントは別ログに分離する |
| セマンティックメモリが誤情報で上書きされる | 書き込み時にバリデーションやバージョン管理がない | 確認・バージョン管理・レビューステップを追加する |
| プロシージャルメモリが改善に繋がらない | 過去実行のログをそのまま保存している | ログではなく、そこから抽出した教訓を書き込む |
| 1つのメモリシステムがあらゆる情報を担っている | カテゴリを分類せずに同一ストアへ流し込んでいる | カテゴリごとにデシジョンツリーを実行する |
共通する根本原因は「ライフタイムの不一致」だ。セッション内でしか必要のない情報に永続化インフラを組んだり、逆に永続化が必要な情報をセッション内だけで扱ったりするケースが頻出する。本記事が提示する答えは明快だ。情報のカテゴリごとにメモリ層を選ぶ。カスタマーサポートエージェントであれば、「現在のチケット」「顧客のサブスクリプション契約」「過去のクレーム」という3カテゴリはそれぞれ異なる場所に置かれるべきだ、という考え方である。
4つのメモリ層を理解する
デシジョンツリーを使う前に、4つのメモリ層それぞれが「何を前提としているか」を押さえておく必要がある。
- ワーキングメモリ：現在の会話内で必要なものはすべてトークンバジェット内に収まる、という前提のもと機能する。古いターンのトリミングや要約をしても問題ないことが条件だ。
- セマンティックメモリ：名前・役職・利用言語・ビジネスルールなど、十分に安定していて再利用可能な知識を蓄積する。繰り返し推論や再質問するよりも、標準的な表現として保存しておく方が価値が高い情報が対象だ。
- エピソードメモリ：過去の意思決定、クレーム、取引履歴など「何が起きたか」の記録そのものに価値がある情報を扱う。現状だけでなく、経緯が次の対応に影響するケースで機能する。
- プロシージャルメモリ：同じ形の作業を繰り返すうちにエージェントが速くなる・精度が上がる、という前提で機能する。過去の記録を残すだけでなく、そこから蒸留した「再利用可能なルーティン」を保持する。
5つの質問で構成されるデシジョンツリー
このツリーは情報カテゴリごとに1回実行する。エージェント全体で1回ではない。
Q1：この情報は現在のターンを超えて持続する必要があるか？
一回限りの分類リクエストの文言や、その場限りのツール呼び出しの中間出力はメモリ不要。コンテキストウィンドウだけで十分だ。持続が必要なら Q2 へ。
Q2：単一セッションを超えて生き続ける必要があるか？
セッション内だけならワーキングメモリ（会話バッファ＋トリミングor要約）で完結する。OpenAI Agents SDKはこのセッション管理を直接サポートしている。セッションをまたぐ必要があれば Q3 へ。
Q3：安定した事実か、変化するイベントか？
ここが最も見落とされやすい分岐だ。名前・サブスクリプション階層・デフォルト配送先のような安定した事実はセマンティックメモリへ。先月のクレームや過去フェーズの意思決定など時系列で蓄積する出来事はエピソードメモリへ。
この区別は認知科学の「意味記憶」「エピソード記憶」の概念を借りている。なお、Zepというフレームワークは事実をナレッジグラフ上でモデル化し、各事実に有効期限ウィンドウを持たせることで、古い事実を「無効化」できる設計になっている。
Q4：このメモリはどのように検索されるか？
少量・境界のある保存（数個のユーザー属性など）ならセッション開始時に全件読み込みで十分だ。Anthropicのmemory toolはこの方式を採用している。大規模・増加し続ける保存（インタラクション履歴、ドキュメントコーパス）ならセマンティック検索またはハイブリッド検索で必要分だけ取得する（Mem0などがこのスケール向けに設計されている）。
1つのエージェントが「小さなセマンティックストアの全件読み込み」と「大きなエピソードログの類似検索」を同時に使い分けるケースも珍しくない。
Q5：エージェントは再利用可能なプロシージャを学習すべきか？
同じ形の作業が繰り返されるならプロシージャルメモリが有効だ。過去の実行ログをそのまま保存するのではなく、そこから蒸留した教訓・成功ステップ・再利用可能な戦略を書き込む。一回限りの作業なら、このレイヤーはスキップしてよい。
組み合わせると何になるか
| レイヤー | 用途 | 実装の典型例 |
|---|---|---|
| 永続化なし | その場限りの情報 | コンテキストウィンドウのみ |
| ワーキングメモリ | セッション内の継続性 | トリミング・要約付き会話バッファ |
| セマンティックメモリ | 安定した事実・知識 | 構造化プロファイル、ナレッジグラフ、ベクターDB |
| エピソードメモリ | セッションをまたぐ履歴 | 蓄積型ログ、関連度・新しさで検索 |
| プロシージャルメモリ | 繰り返し改善すべきルーティン | 蒸留済みルーティン（セマンティック・エピソード層の上位） |
コーディングエージェントであれば、ワーキング（現在の編集）・セマンティック（ユーザー設定・ツール知識）・エピソード（変更履歴）・プロシージャル（テスト＆検証ワークフロー）の4層すべてを使う。一方、シンプルなFAQエージェントはワーキングメモリだけで完結する場合もある。どちらも同じデシジョンツリーの正当な結果だ。
詳細はChoosing the Right AI Agent Memory Strategy: A Decision-Tree Approachを参照していただきたい。
