powered by TechFeed
表示モード
Deep Dive

AIエージェントがタスクをまたいで記憶を持てない問題に挑む「メモリハーネス」— 「書く・管理する・読む」の3軸設計で長期タスクの一貫性を保つ

8月13日、startuphub.aiが「AI Agents Need Memory Harnesses for Long Tasks」と題した記事を公開した。長期タスクを担うAIエージェントにとって、セッションをまたいだ記憶の欠如は根本的な制約だ。ベクトルDBを接続するだけでは解決しきれないこの問題に対し、Sakana AIの研究者Drugaが「メモリハーネス」と呼ぶ体系的な設計アプローチを発表した。記事ではその構造と実験結果が詳しく紹介されている。

8月13日、startuphub.aiが「AI Agents Need Memory Harnesses for Long Tasks」と題した記事を公開した。長期タスクを担うAIエージェントにとって、セッションをまたいだ記憶の欠如は根本的な制約だ。ベクトルDBを接続するだけでは解決しきれないこの問題に対し、Sakana AIの研究者Drugaが「メモリハーネス」と呼ぶ体系的な設計アプローチを発表した。記事ではその構造と実験結果が詳しく紹介されている。


AIエージェントのメモリ問題とは何か

現在のAIエージェントの多くは、タスクをまたいだ記憶を持たない。セッションが終われば、それまでの判断履歴や文脈はリセットされる。これは短いタスクであれば問題にならないが、複数ターンにわたる長期的なリサーチ作業では致命的な制約になる。エージェントが同じ判断ミスを繰り返したり、前のターンで確認済みの情報を再度探索したりといった非効率が生じ、タスク全体の一貫性が崩れる。

この課題に取り組んだのが、Sakana AIに所属する研究者のDrugaだ。Sakana AIは進化的アルゴリズムや自己組織化の思想をAI研究に応用することで知られる日本発のAI研究機関であり、Drugaはその所属研究者としてこの成果を発表した。彼女はAIエージェントに「永続的な記憶」を与えるための構造、メモリハーネス(Memory Harness)の設計を提案している。


メモリハーネスの核心:「書く・管理する・読む」のループ

Drugaが設計したハーネスの基本思想は、メモリを**"write-manage-read loop"(書く・管理する・読むのループ)**として捉えることだ。

このシステムは3つのブロックで構成される:

  • コアコンポーネント:エージェントに常に提示される、固定的な情報。
  • リコールブロック:異なるメモリ取得モードをテストするための領域。
  • アーカイブブロック:セッションをまたいだ情報の永続化を担う。

リコールモードについては複数のアプローチを実験した。「メモリなし」という最もシンプルな状態から始まり、ベクトル検索による取得、ターンごとに下した判断を記録する**"decisions ledger"(意思決定台帳)、そして記憶取得のグラウンドトゥルースを与える"oracle"モード**まで試している。

「decisions ledger」は特に実装者にとって参考になる発想だ。エージェントが「なぜその選択をしたか」をターンごとに記録しておくことで、長期タスク中の判断の一貫性を保てる。ベクトル検索が「何を覚えているか」を取り出すのに対し、decisions ledgerは「どう考えてきたか」の文脈を保持する。


ローカルモデルとの組み合わせ

発表ではローカルモデルの活用についても言及されている。CoinbaseがローカルAIモデルへの移行によってAIコストを削減しつつ利用量を増やした事例を挙げながら、より良いルーティング・キャッシング・コンテキスト管理がコスト効率に直結することを示した。

Druga自身の実行環境は、M3 UltraチップのMac Studio。そこで以下の2モデルを動かしている:

  • Qwen 27B(4ビット量子化)
  • DeepSeek V3 Flash

RAMのボトルネックが依然として残る中でも、GLMやDeepSeekのようなローカルモデルがエージェント的タスクやツール利用において実用的になりつつあるという見方だ。4ビット量子化(※モデルの重みをより少ないビット数で表現することで、メモリ使用量を圧縮する手法)を使えば、ハイエンドなコンシューマー機材でも大規模モデルを動かせる水準に来ている。


実装者への示唆

設計の要点は明確だ。エージェントに記憶を与えるとはどういうことかを「何を常時見せるか」「何を検索で取り出すか」「何をセッションをまたいで保持するか」の3軸で整理する枠組みは、実装上の指針として使いやすい。

特に注目したいのは、この設計が「メモリの種類」ではなく「メモリのアクセスパターン」を軸に整理している点だ。コアコンポーネント・リコールブロック・アーカイブブロックという3層は、それぞれ「常時参照」「動的取得」「長期保存」という異なるアクセス特性に対応しており、単一のベクトルDBで全てを賄おうとする設計とは発想の根が異なる。

長期タスク向けエージェントを設計する際、decisions ledgerのようなターンレベルの文脈管理を加えることで、エージェントの振る舞いの一貫性が向上する可能性がある。「ただベクトルDBをつなぐ」で済ませずに、判断の経緯そのものを記録する層を設けることが、長期タスクの品質を左右する鍵になりうる。LangGraphにおけるメモリ管理MemGPTのような既存フレームワークと比較しながら読むと、このアプローチの位置づけがより明確になるだろう。

詳細はAI Agents Need Memory Harnesses for Long Tasksを参照していただきたい。