ALTK-Evolve が ACE より少ないトークンでエージェント記憶を実現——AppWorld ベンチマーク比較

記事のサマリー（TL;DR）

• ALTK-Evolve と ACE はどちらもエージェントの過去の軌跡から学習する記憶機構だが、ガイドラインの「配信方法」が異なる
• DeepSeek-V3.2 では TGC 89.3 vs 80.4 と精度でも上回り、トークン消費は 263K vs 634K と約 40% で済む
• gpt-oss-120b では精度をほぼ同等（56.0 vs 54.8）に保ちながらトークンを約 7 分の 1（116K vs 777K）に削減

生成AI エージェント開発者が押さえるべきコスト最適化の視点

LLM エージェントを業務システムと接続する構成——たとえば kintone・Salesforce・Stripe などの API を複数またいでタスクを処理するシナリオ——では、1 タスクあたりのトークン数がそのままランニングコストに直結します。ACE は毎ステップで全プレイブックを注入する固定方式を採るのに対し、ALTK-Evolve はモデルの能力に応じてガイドライン注入量を動的に調整します。強いモデルには全ガイドラインを、弱いモデルにはタスクに関連する少数のガイドラインだけを渡すという設計は、コスト設計の自由度を高めます。日本国内でも Claude / GPT-4o クラスの強力モデルと、コスト抑制目的の小型モデルを用途別に使い分ける構成が現実的になりつつあり、そうした「モデル選定 × コンテキスト設計」の最適化において ALTK-Evolve のアプローチは参考になります。

詳細

背景：エージェントはなぜ失敗するのか

現実の多ステップタスク——請求書の分割、楽曲検索、9 つの模擬アプリをまたいだ注文照合——を LLM エージェントに与えると、失敗の原因はほとんどの場合、知識の欠如ではありません。API のページネーションのミス、誤った人物の解決、不要な値の返却といった「使い方の失敗」です。モデルは API 仕様を知っている。しかし、信頼性高く使いこなす方法を内面化できていない。その部分は、エージェント自身の過去の履歴から学習できます。

この課題に取り組む 2 つのシステムが ACE（Agentic Context Engineering） と IBM Research の ALTK-Evolve です。どちらも同じ種類のエージェントに適用できる「エージェント記憶」の一形態であり、過去の軌跡を再利用可能な教訓に変換し、推論時にフィードバックします。重みの更新も人間のラベルも不要です。

共通点：教訓を圧縮しない

両システムが共有する最も重要な原則は「教訓を要約しない」という点です。

ACE はその理由として 2 つの失敗パターンを明示しています。

• brevity bias（簡潔性バイアス）：最適化が短く一般的な指示へ収束してしまう現象
• context collapse（コンテキスト崩壊）：モデルがステップごとにコンテキスト全体を書き直す際に詳細が失われる現象

ACE はこれに対し、各箇条書きに helpful/harmful カウンターを持つ詳細なプレイブックを維持し、読み取り時にモデルが関連性を判断する方式を採ります。

ALTK-Evolve も同じ結論に別の角度から到達しています。各ガイドラインに「サポートカウント（何件の独立したエピソードがそれを生成したか）」を保持し、ストアを一握りのルールに要約することはしません。5 つの異なるタスクが発見した教訓と、1 回だけ現れた教訓は別物であり、どちらも保持する価値があります。

「エージェントが積み上げた教訓を整然とした要約に圧縮すべきか？」という中心的な問いに対し、ACE と ALTK-Evolve は同じ答えを出しています：No。数えよ、崩壊させるな。 ACE のバレット単位のカウンターと ALTK-Evolve のサポートカウントは、同じ考え方の 2 つの実装です。

相違点：構築方法と配信方法

両システムが分岐するのは「記憶の構築方法」と「配信方法」の 2 点です。特にコストに影響するのは配信方法です。

構築（ストアの構築方法）

• ACE：Generator → Reflector → Curator のループで 1 つのプレイブックを成長させ、差分更新と埋め込みによる重複排除を実施
• ALTK-Evolve：近似重複の教訓をクラスタリングし、クラスタ内でサポートカウントを保存しながらマージ（複数の教訓がマージされると、生き残った教訓が合算カウントを引き継ぐ）。また、戦略・回復・最適化といった型付きガイドラインを因果帰属とソース軌跡への出典付きで抽出し、サブタスク粒度で管理するため、あるアプリで学んだ教訓を別のアプリに転用できる

配信（推論時にモデルへ何を渡すか）

ここがトークン数の差を生む核心です。

• ACE：毎ステップで包括的なプレイブック全体を注入。モデルやタスクに関わらず固定
• ALTK-Evolve：配信量を「ダイヤル」として扱う。サポートが高い少数の固定コアに加え、タスクごとにコサイン類似度または LLM ガイドによる優先度付き選択で数件を追加。強いモデルには統合セット全体を渡す

同じ教訓が両エージェントで利用可能であり、違いは ACE が常に全件送るのに対し、ALTK-Evolve が各モデルが実際に活用できる量だけ送る点にあります。

AppWorld ベンチマーク結果

同一の ReAct ベースエージェントを用いたインハウス評価（AppWorld test_normal、168 タスク）の結果は以下の通りです。TGC = Task Goal Completion、SGC = Scenario Goal Completion。

強いモデル（DeepSeek-V3.2）では精度・コスト両面で上回り、推論コストは ACE の約 40% です。弱いモデル（gpt-oss-120b）では精度はほぼ同等（56.0 vs 54.8、再実行では 54.8 と一致しベンチマークの試行間ノイズ範囲内）、コストは約 7 分の 1 です。

なお、ACE 自身のコスト効率の主張はコンテキストを安価に「構築」することにあります。ALTK-Evolve のコスト効率は「配信」の軸——タスクごとに少数のガイドラインを取得することで、毎ステップのプレイブック全注入を回避する——にあります。

難易度別精度の分析

2 つのモデルは異なる傾向を示しています。

gpt-oss-120b（弱いモデル）

Easy・Medium では ACE の包括的なプロンプトが有効です。一般的な指示追従でタスクの多くが解決できる場合、包括的なプロンプトが絞り込み選択より効果的です。しかし Hard タスクでは、適切な教訓を選び出す必要があり、キュレーションされた検索が優位に立ちます——そしてこの難易度帯が総合結果を決定します。

DeepSeek-V3.2（強いモデル）

強いモデルでは ACE のプレイブック全体を吸収する能力があるため、Medium で ACE がわずかに上回ります。一方、ALTK-Evolve は Easy・Hard・Overall でリードし、能力に余裕があるほど多くの教訓（ALTK-Evolve 流の配信で）がお互いを押しのけることなく機能し続けます。

各モデルに最適な構成を適用することが重要です——強いモデルには統合セット全体を、弱いモデルには選択的検索を。大きなコンテキストは弱いモデルには助けになるどころか負荷になります。

参照データ（完全版）

DeepSeek-V3.2 — test_normal（168 タスク）

gpt-oss-120b — test_normal

まとめ：同じ教訓、異なる配信

両システムはエージェントが積み上げた経験を整然とした要約に圧縮することを拒否している点で一致します。相違点は配信が固定か調整可能かという点です。ACE は何にでも毎ステッププレイブック全体を送り、ALTK-Evolve は各モデルが実際に活用できる量を送ります。この調整こそが、同等以上の精度を ACE の推論コストの一部で実現した源泉であり、弱いモデルでは「助けになるガイダンス」と「邪魔になるガイダンス」の分岐点でもありました。

ALTK-Evolve ライブラリ（抽出・統合・検索パイプラインを含む）の詳細は ALTK-Evolve GitHub およびテクニカルレポートを参照してください。