AIエージェントの記憶とは何か？会話履歴を業務判断に変える設計

ファイルベース記憶とDBベース記憶を使い分ける

　Agent Memoryというと、Vector DBやGraph DBのようなデータベースを思い浮かべる人もいるでしょう。もちろん、それらは重要です。一方で、実際のAgent Memoryはデータベースだけではありません。ファイルとして管理される記憶もあります。

　代表例が、Claude Codeの `CLAUDE.md` やAuto memoryの `MEMORY.md` です。Claude Codeでは、セッションをまたいで知識を保持する仕組みとして、人間が書く `CLAUDE.md` と、Claudeが作業中の学びを蓄積するAuto memoryが用意されています。Auto memoryでは、`MEMORY.md` が記憶ディレクトリの索引として機能し、詳細なトピックファイルは必要に応じて参照されます。

　OpenAI Agents SDKのSandbox Agent memoryにも近い考え方があります。通常の会話セッションとは別に、過去実行から得た教訓をファイルに蒸留し、小さな `memory_summary.md` から必要に応じて詳細な要約へたどる構成です。

　※なお、OpenAI Agents SDKのSandbox Agent memoryは、2026年4月下旬時点ではBeta機能として提供されており、APIや既定動作は今後変更される可能性があります。

　ファイルベースの記憶は、Agentに読ませるドキュメントに近いものです。人間が読める。編集できる。Gitで差分管理できる。レビューしやすい。開発規約、運用手順、設計方針、障害対応Runbook、問い合わせ対応ルールのように、人間とAgentが共有すべき前提を置くには相性が良い方式です。

　一方で、ファイルベースの記憶には限界もあります。大規模な意味検索、ユーザーごとのスコープ分離、顧客ごとの権限管理、時系列の更新、監査ログとの連携には向いていません。そこで必要になるのが、DBベースの記憶です。ユーザー嗜好、顧客ごとの前提、過去対応履歴、問い合わせ履歴、契約条件、担当者変更、組織構造、監査ログのような情報は、検索可能なデータベースとして管理した方が適しています。

メモリライフサイクルを設計する

　Agent Memoryは、単独の保存先ではありません。Agentの実行ループの中で、どの情報を記憶にし、どの記憶を維持・更新し、どのタイミングで思い出すかを制御する仕組みです。サーベイ論文では、この動きをMemory Formation、Memory Evolution、Memory Retrievalの3つで整理しています。

　Memory Formationは、会話、ツール実行結果、部分計画、自己評価、環境フィードバックなどから、将来使える記憶候補を作る処理です。Memory Evolutionは、新しい記憶を既存の記憶ベースへ統合し、重複をまとめ、矛盾を解消し、不要な記憶を削除または無効化する処理です。Memory Retrievalは、現在の質問や業務ステップに応じて、必要な記憶を取り出す処理です。論文のFigure 8（本記事の図3）は、この形成・進化・想起の循環を図示しています。

　ここで注意したいのは、Formation / Evolution / Retrievalは、特定製品の処理フローそのものではなく、Agent Memoryを理解するための概念モデルだという点です。Mem0、Zep、LangMem、LangGraphなど、具体的なMemory関連ツールがどこまで自動化するか、どの処理をアプリケーション側で実装するかはそれぞれ異なります。これらの違いは、次回以降の本連載で触れる予定です。

例：A社対応ルールが記憶として使われるまで

　問い合わせ対応Agentの例で考えてみます。担当者が「A社は通常のメール回答ではなく、専用ポータルにチケットを起票して回答する必要がある。緊急度が高い障害の場合は、情報システム部にも同時に連絡する」と話したとします。この発話は、そのまま保存するだけでは、次回の判断に使いやすい記憶にはなりません。Agent Memoryを設計する際には、このような発話を、次のような観点で整理します。

　1. 記憶候補を作る

　「顧客：A社」「回答方法：専用ポータル」「条件：緊急障害」「通知先：情報システム部」のように、再利用できる記憶候補へ切り出します。

　2. 記憶として使える状態に整える

　A社対応ルールとして扱えるように、根拠、有効期限、スコープ、承認状態を付けます。古いルールと矛盾する場合は、新しい記憶として追加するのか、既存の記憶を更新するのか、過去の経緯として残すのか、監査用に残すだけにするのかを分けて考えます。

　3. 次回の文脈で想起する

　A社から緊急障害の問い合わせが届いたとき、「A社」「緊急障害」「対応ルール」という文脈から、今回の判断に必要な記憶だけを取り出します。

　4. 回答やツール実行に反映する

　想起した記憶をもとに、専用ポータルにチケットを起票し、情報システム部にも通知する、という対応方針に反映します。

　ただし、これは特定の製品やフレームワークの処理手順を示したものではありません。実際には、会話をいったん短期記憶やイベントログとして保持し、後から非同期に長期記憶へ反映する場合もあります。あるいは、会話から直接記憶候補を抽出する場合もあります。追加、更新、関連付け、無効化、削除、検索、回答生成やツール実行時にどう渡すかの方法は、利用するMemory機能や実装方針によって異なります。ここで重要なのは、すべての実装が同じ順序で動くことではなく、記憶を「作る」「使える状態に整える」「必要な場面で想起する」という観点で設計することです。

　このライフサイクルの中では、忘却も重要な設計対象になります。実際のAgent Memory設計では、人間の記憶に関するエビングハウスの忘却曲線をヒントに、時間経過に応じて記憶の重みや優先度を調整するアプローチもあります。ただし、すべての記憶を時間だけで弱めればよいわけではありません。契約条件、顧客ごとの運用ルール、担当者情報のような業務上の前提は、有効期限、根拠、承認状態、更新履歴とあわせて扱う必要があります。忘却とは単に消すことではなく、記憶を現在の判断に使ってよいかを制御することでもあります。