AIエージェントの適切なメモリ戦略の選択：意思決定ツリーアプローチ

この記事では、シンプルな意思決定ツリーをカテゴリごとに順に進めていくことで、AIエージェントに適したメモリ戦略の選び方を学びます。

以下のようなトピックを扱います：

• エージェントメモリの4つの種類（ワーキングメモリ、セマンティックメモリ、エピソードメモリ、手続きメモリ）と、それぞれが保持する情報に関する前提
• あるカテゴリの情報が実際に何を必要とするかを分類する5つの質問からなる意思決定ツリーと、それらの回答がどのように組み合わさって完全なメモリアーキテクチャになるか
• エージェントメモリを実装した後に発生しやすい落とし穴と、その修正方法

さっそく始めましょう。

はじめに

メモリはAIエージェントを定義する機能の一つですが、しばしば後回しに設計されがちです。一部のエージェントはユーザーが記憶してほしいと期待する情報を忘れ、他のエージェントは実際には必要のない複雑なメモリ基盤を与えられています。どちらも同じ未解決の設計上の問いから生じています：異なる種類の情報はどれくらいの期間保持すべきで、どのように検索すべきか？

エージェントメモリ戦略はオーケストレーションと同じように意図的に設計されるべきです。しかし、オーケストレーションパターンとは異なり、エージェントメモリは単一のアーキテクチャ選択であることは稀です。現在の会話、ユーザーが明示した好み、過去のインタラクション履歴、学習されたルーチンはそれぞれ異なる情報カテゴリであり、それぞれが異なる種類のメモリを必要とする傾向があります。有用な問いは「エージェントがどのメモリシステムを使うべきか」ではなく、「各情報カテゴリが実際にどのレイヤーを必要とするか」です。

本記事では以下を扱います：

• ワーキングメモリ、セマンティックメモリ、エピソードメモリ、手続きメモリを区別する中核的なメモリ概念
• ある情報カテゴリが何を必要とするかを分類するための5つの質問からなる意思決定ツリー
• それらの分類が実際にエージェントが運用するレイヤー化されたメモリ構成にどのように統合されるか
• メモリが実装・利用された後に発生する落とし穴

まず、なぜこの分類が重要なのかを説明します。

AIエージェントのメモリ戦略を選択することが重要な理由

意思決定ツリーを進める前に、各メモリレイヤーが割り当てられた情報について何を前提としているかを明確にしておきましょう。

• ワーキングメモリは、現在の会話と有限のトークンバジェット内に今必要な情報がすべて存在しており、古いターンを削除または要約してもエージェントがまだ必要とする情報が静かに失われることはない、という考えに基づいています。
• セマンティックメモリは、ある情報が十分に安定していて再利用可能であるため、正規表現を保存する方が、繰り返し推論したり再質問したり再処理したりするよりも価値があると仮定します。これには、名前・役割・希望言語などの永続的なユーザー情報、ビジネスルールや製品仕様などのドメイン知識、繰り返しのインタラクションから抽出された一般化された知識が含まれます。
• エピソードメモリは、過去に何が起こったかの履歴自体に価値があるという前提で構築されます。現在の状態だけでなく、過去の決定・苦情・取引の記録が次のインタラクションに役立つという考えです。
• 手続きメモリは、同じ形状のタスクを繰り返し解決することで、次回の試行でエージェントがより速く・より確実になるべきであり、単に過去の試行の記録を残すだけではない、という前提に立っています。

この4つのレイヤーは情報に関する異なる質問に答えるため、ほとんどの本番用エージェントは複数のレイヤーを利用します。

例えばカスタマーサポートエージェントの場合、現在のチケットをワーキングメモリに、顧客のサブスクリプション階層をセマンティックメモリに、過去の苦情をエピソードメモリに、学習された返金処理ルーチン手続きメモリに保持するかもしれません。各レイヤーはそれぞれ異なる目的を果たします。

問題は、情報が誤ったレイヤーに保存されたときに発生します。構造化プロファイルに属する安定した事実をベクトルストアに使用すると、検索が遅くなり信頼性が低下します。一方、インタラクション履歴全体を検索すると、構造化レコードが上書きしていたはずの古いまたは矛盾する情報が表面化する可能性があります。効果的なコンテキストエンジニアリングでは、メモリは限られたコンテキストウィンドウを争うコンテキスト源の一つに過ぎないため、意味のある改善をもたらす場合にのみ情報を検索すべきです。

AIエージェントの適切なメモリ戦略を選択するための意思決定ツリー

このツリーは5つの分岐質問からなり、それぞれが具体的な情報の性質に基づいて、特定のカテゴリの情報が何を必要とするかを絞り込みます。エージェント全体ではなく、カテゴリごとにツリーを実行してください。サポートエージェントの「現在のチケット」「アカウント詳細」「苦情履歴」は3つの別々のカテゴリであり、それぞれがツリー上の異なる位置に到達する可能性があります。

質問1：この情報は現在のターン以降も保持する必要がありますか？

この質問は、本当にメモリを必要とする情報と、そう見えるだけの情報を区別します。

• 自己完結型で引き継ぎ不要：一度限りの分類リクエストの文言、現在の質問にのみ使用されるツールコールの途中結果
• 引き継ぎが必要でメモリが必要：この会話でサポートエージェントがすでに解決した問題、昨日から再開するコーディングプロジェクトの状態

情報が自己完結型である場合 → メモリレイヤーは不要です。そのターンのコンテキストウィンドウで十分です。引き継ぎが必要な場合 → 質問2に進みます。

質問2：この情報は単一セッションを超えて存続する必要がありますか？

この質問は、ワーキングメモリと、耐久性が必要なものを区別します。

• セッション内のみ：すでに尋ねられた内容、すでに呼び出されたツール、すでに解決された内容 → トリミングや要約によって範囲を制限した会話バッファで十分です。OpenAI Agents SDKのセッションベースメモリ管理はこれを直接扱います。
• セッションを超えて：再来訪顧客の好み、進行中のプロジェクトの状態、数日かかるタスク → 単一の会話とは独立して存在する必要があるため、ワーキングメモリだけでは不十分です。

セッション内の継続性のみが重要な場合 → このカテゴリに対する答えはワーキングメモリです。セッションを超えて存続する必要がある場合 → 質問3に進みます。

⚠️ よくある設計ミスは、情報の寿命と保存先を誤ることで、セッションスコープの状態を永続的に扱ったり、会話中のみ必要な情報に対して永続メモリ基盤を構築したりすることです。

質問3：これは安定した事実ですか、それとも変化するイベントですか？

この質問はしばしばスキップされ、永続が必要なすべての情報が形状に関係なく同じストアに投入されてしまいます。

• 安定した事実（セマンティックメモリ）：名前、サブスクリプション階層、希望トーン、デフォルトの配送先など、セッションを超えて有効であり、繰り返し推論・再質問するよりも正規の事実として保存する方が価値がある永続的な知識
• 変化するイベント（エピソードメモリ）：先月提出された苦情、プロジェクトの早期段階で行われた決定、複数のインタラクションにわたる行動パターン

メモリアーキテクチャは認知科学が人間の記憶を分類する方法からこの語彙を借用し、安定した知識と特定の過去の出来事の記憶を区別します。一部のフレームワークは時間的次元をストレージレイヤーに直接組み込んでいます。例えば、Zepは知識グラフ上に事実をモデル化し、各事実が有効期間を持ち、置き換えられた事実は無効化されて新しい事実と静かに矛盾しないようにします。

安定した事実は、ユーザー属性用の構造化レコード、リレーションシップ用の知識グラフ、セマンティック検索可能なドメイン知識用のベクトルデータベースなど、永続的な知識ストアに属します。変化するイベントはログに近いものに属し、エントリが蓄積され、古いものは要約や剪定が必要になる場合があります。

このカテゴリが主に事実とドメイン知識である場合 → セマンティックメモリです。主に履歴である場合 → エピソードメモリです。次の質問は、そのログが大規模にどのように検索されるかであり、質問4に進みます。

質問4：このメモリはどのように検索されますか？

この質問は、どこでも同じ検索戦略を使うのではなく、メモリストアのサイズ・構造・成長率に合わせて検索を適合させるものです。

• 小さく境界のあるストア（少数のユーザー事実または単一のプロファイル）：セッション開始時にストア全体を読み取ります。Anthropicのメモリツールはこの方式で動作します。ストアが小さく、全読み込みが安価だからです。
• 大きく検索可能なストア（インタラクション履歴、文書コーパス、または拡張中の知識ベース）：セマンティック検索やハイブリッド検索を使用して最も関連性の高いエントリのみを取得します。すべてを読み込むことはすぐに非現実的になります。GoogleのMemory Bankはこの規模向けに設計されており、Mem0のようなメモリフレームワークはLangGraphやCrewAIなどのフレームワークと組み合わせて使用できる、プロバイダ非依存の同等のアプローチを提供します。

一つのエージェントが両方の検索パターンを同時に必要とすることは一般的です。小さなセマンティックストア用の全読み込みプロファイルと、大きなエピソードログやセマンティック知識ベースに対する類似度検索を併用します。

各ストアの実際のサイズと構造に検索が適合したら、質問5に進みます。

質問5：エージェントは再利用可能な手続きを学習する必要がありますか？

ここで手続きメモリが登場します。これは既存のセマンティックレイヤーやエピソードレイヤーの上に位置し、それらを置き換えるものではありません。

• 繰り返しによって改善すべき反復タスクの形状（同じ種類のリファクタリング、同じカテゴリのチケット）：手続きメモリに抽出する価値があり、エージェントは過去の試行を再生するのではなく、洗練されたルーチンを適用します。
• 一度限りまたは繰り返さないタスク：このレイヤーはスキップします。以前に選択したセマンティックメモリまたはエピソードメモリで十分です。

エージェントのメモリモジュールは通常、計画レイヤーやツールレイヤーと並んで配置され、学習されたコンテキストを将来の計画の作成方法にフィードバックします。重要な設計上の決定は、何を書き込むかです。過去の実行の生ログはエピソードメモリを捉えますが、手続きメモリはそれらの経験から抽出された教訓・成功したステップ・再利用可能な戦略を保存します。有用な手続きストアは将来の適用を念頭に置いて書かれ、エージェントが類似タスクに実証済みのワークフローとパターンを直接適用できるようにします。

以上の質問により、以下のような意思決定ツリーが得られます：

メモリレイヤーの組み合わせ方

各情報カテゴリに対してツリーを実行すると、エージェント全体に対する単一の回答ではなく、メモリプロファイルが得られます。これらのプロファイルを組み合わせることで、エージェントのニーズに最も適合したメモリアーキテクチャが明らかになります。

例えば、コーディングエージェントは、現在のセッションの編集にワーキングメモリ、ユーザーの好みやツール知識にセマンティックメモリ、プロジェクト全体の変更履歴にエピソードメモリ、繰り返し使用によって改善された再利用可能なテスト＆検証ワークフローに手続きメモリを使用するかもしれません。一方、シンプルなFAQエージェントは、どの情報も現在の会話を超えて保持する必要がないため、ワーキングメモリのみで十分かもしれません。

どちらも同じ意思決定プロセスの有効な結果であり、違いはエージェントが保持する必要のある情報の種類と、その情報の使い方から生じます。

レイヤー	用途	典型的な実装
永続化なし	引き継ぎ不要の自己完結型情報	コンテキストウィンドウのみに依存し、メモリレイヤーは使用しない
ワーキングメモリ	単一セッション内の継続性	トリミングまたは要約を伴う会話バッファ
セマンティックメモリ	セッションを超えて永続する安定した事実と一般化された知識	構造化プロファイル、知識グラフ、またはセマンティック検索用のベクトルデータベースに保存。小規模ストアは全読み込み、大規模知識ベースは類似度検索で取得
エピソードメモリ	セッションを超えて永続する変化する履歴	成長するログ。規模に応じて最新性または関連性検索で取得
手続きメモリ	繰り返しによって改善すべき反復タスクパターン	既存のセマンティックまたはエピソードストアの上に重ねられた、抽出された再利用可能なルーチン

AIエージェントメモリのよくある落とし穴（と修正方法）

各カテゴリに対して正しいレイヤーを選択しても、メモリの実装は予測可能な少数の方法で失敗する傾向があります。以下のテーブルは、よくある症状とその通常の原因・修正を対応づけています。

問題	考えられる原因	修正
エージェントがすでにこのセッションで提供された情報を再び尋ねる	ワーキングメモリが過度にトリミングされた、または要約が関連する詳細を失った	長期メモリレイヤーを追加するのではなく、保持ウィンドウを広げるか、要約が保持する内容を改善する
検索結果が無関係または矛盾する結果を返す	安定した事実と変化するイベントが1つの区別されていないストアに混在している	分割する：事実には小さな構造化ストアを使用し、イベントには別個のログを使用する
セマンティックメモリが誤った情報で上書きされる	書き込み時に検証やバージョン管理が行われていない	事実が既存のものを置き換える前に、確認・バージョン管理・レビュー手順を追加する
手続きメモリが何も改善していないように見える	ストアが過去の実行の生の再生を保持しており、抽出された教訓を保持していない	試行のトランスクリプトではなく、消化された教訓を書き込む
1つのメモリシステムが事実・履歴・セッション状態をすべて同時に扱っている	すべての情報カテゴリが個別に分類されるのではなく、同じストアに強制的に通された	カテゴリごとに意思決定ツリーを実行し、それぞれが実際に必要とするレイヤーに到達させる

まとめと次のステップ

意思決定ツリーは、メモリ設計を単一のデフォルトアプローチではなく、明確な選択のセットに変えます。ストレージを構築する前に重要な質問をします：この情報はどれくらいの期間保持すべきか、それは安定した事実か過去のイベントか、後でどのように検索されるか、そしてそれは将来のタスクを改善できる再利用可能な振る舞いを表しているか？

多くのメモリ問題は、エージェントが扱うすべての情報を同じ種類のデータとして扱うことから生じます。上で述べたように、ワーキングメモリ、セマンティックメモリ、エピソードメモリ、手続きメモリは異なる目的を持ち、異なる保存・検索戦略を必要とします。効果的なエージェントは、どの情報が保持される必要があるか、どのように検索されるべきか、将来の振る舞いを改善すべきかどうかに基づいて、これらのレイヤーを組み合わせます。

次のステップは、利用可能なエージェントメモリフレームワークとツールを探索することです。今後の記事では、これらのフレームワークを評価し、アプリケーションの要件に基づいて適切なものを選択する方法を説明します。

まだコメントはありません。