自律型AIエージェントの過去履歴活用、IBM Researchが「ALTK-Evolve」と「ACE」のメモリ管理アプローチを比較
要点
- IBM Researchは、LLMエージェントが過去の実行履歴から学習するメモリシステム「ALTK-Evolve」と「ACE」の比較解説を公開した。
- どちらの手法もモデルの重み更新や人間の手動ラベリングを行わず、過去の失敗や成功を「レッスン」として推論時に再利用する。
- 両システムは要約による詳細の欠落を防ぐため「学習内容を無理に圧縮せずカウントして蓄積する」という設計思想で一致している。
- レッスンの提供方法において、ACEが単一のプレイブックを育てるのに対し、ALTK-Evolveは個別のガイドラインとして管理・検索する点が異なる。
IBM Researchの研究チームは2026年8月11日、Hugging Faceの公式ブログにおいて、大規模言語モデル（LLM）を用いた自律型エージェントの記憶機構に関する技術解説記事を公開した。エージェントが自身の行動履歴から失敗パターンや運用ルールを学習する手法として、先行する「ACE（Agentic Context Engineering）」とIBMが開発する「ALTK-Evolve」を取り上げ、両者の共通する設計原則と構造上の違いについて報告している。
エージェントの課題は「知識」ではなく「ツールの確実な使い方」
記事によると、複数ステップにまたがる実用的なタスクをLLMエージェントに実行させた際、失敗の主な要因はAPIなどの知識不足ではないという。請求書の分割や楽曲の検索、あるいは複数のシミュレーションアプリをまたぐ注文の照合といった複雑な処理において、エージェントはAPIのページネーションを誤ったり、対象となる人物を取り違えたり、求められていない値を返してしまうといった誤りを起こしがちである。
研究チームは、モデル自身はAPIの仕様を把握しているものの「いかにしてそれらを安定して確実に実行するか」という実践的なノウハウを十分に内面化できていないことが問題の本質であると指摘している。そして、こうした実践的なノウハウはエージェント自身の行動履歴（トラジェクトリ）から学習可能であると説明する。
過去の履歴を再利用する「エージェントメモリ」
この課題に対処するアプローチとして注目されているのが、エージェントが過去の履歴から再利用可能な「レッスン（教訓）」を抽出し、推論時にプロンプトへフィードバックする「エージェントメモリ（agentic memory）」の仕組みである。
このアプローチの大きな特徴は、モデルのパラメータを再学習する重み更新（ファインチューニング）や、人間による正解データのラベリングを一切必要としない点にある。ACEとALTK-Evolveは、いずれも同様の対象エージェントに対してこの仕組みを適用しており、基本原理において方向性を共有している。
両システムでは用語の定義が一部異なる。エージェントが経験から得る生の学びを「レッスン」と呼ぶのに対し、ACEはそれらのレッスンを単一の包括的で進化し続ける「プレイブック（playbook）」の中に整理する。一方でALTK-Evolveは、個別に検索・取得が可能な「ガイドライン（guidelines）」として集約する方式を採用している。
両者が一致する「圧縮の拒否」とカウントによる評価
技術的な核心部分において、ACEとALTK-Evolveは「獲得したレッスンを安易に要約・圧縮しない」という方針で完全に一致している。
ACEでは、コンテキストを要約しようとした際に生じる2つの失敗パターンが定義されている。1つは最適化の過程で指示が短く抽象的なものへと縮退してしまう「簡潔さへの偏向（brevity bias）」、もう1つはステップごとに全体のコンテキストを書き直すことで重要な詳細情報が削ぎ落とされてしまう「コンテキスト崩壊（context collapse）」である。ACEはこれらを防ぐため、箇条書きの項目ごとに役立ち度や有害度を記録するカウンター（helpful/harmful counter）を備えた詳細なプレイブックを維持し、実行時にモデルが必要な関連情報を抽出するアプローチをとる。
一方、ALTK-Evolveも別のアプローチから同じ結論に達しているという。ALTK-Evolveでは、各ガイドラインに対して独立したタスクから何回生成されたかを示す「サポートカウント（support count）」を記録し、ナレッジストアを少数の大まかなルールへと要約することは避けている。5つの異なるタスクで発見された教訓と、1度だけ現れた教訓は別個の価値を持つ対象として区別され、双方が保持される仕組みとなっている。
このように、苦労して得たエージェントの教訓を無理に要約して潰すのではなく、出現頻度をカウントしながら詳細なまま保持するという点で、両アプローチの設計思想は合致している。
学んだ教訓の「提供方法」とトークン消費の差
一方で、両システムが分岐するのは学習したレッスンの「提供方法（delivery）」である。
学んだ教訓を単一のプレイブックとして蓄積・更新していくACEと、個別のガイドラインとして整理して必要なものを検索・取得するALTK-Evolveでは、コンテキストとしてモデルに入力される形式が異なる。IBM Researchは、この提供構造の違いこそが推論時に消費されるトークン量（token bill）に直接的な影響を与える要因であると述べている。