In Silico

AI・信頼性・評価

Agentic Context Engineering（ACE）とは：ALTK-Evolveとの違い

2026/10/27 （更新: 2026/11/3）

🤖 AIを使用して執筆

  • ACE
  • 学習メモリ
  • AIエージェント
  • コンテキストエンジニアリング
  • ALTK-Evolve
  • AppWorld
  • τ²-bench
  • KV キャッシュ
  • プロンプトキャッシュ
  • ReAct
  • gpt-oss-120b
  • DeepSeek-V3.2
  • 指針
  • 支持件数
  • プレイブック
  • トークン
  • コンテキスト
  • コサイン類似度
  • プロンプト最適化
  • 追加学習
  • Reflector
  • Curator
  • Chroma
  • Anthropic
  • IBM Research
  • Apache-2.0
  • TGC
目次
背景・問い・要点
背景

AIエージェント（以下、エージェント）は、言語モデルがツールを呼び出しながら利用者の仕事を進めるプログラムである。エージェントは実行のたびに白紙から始めるので、前の実行でつまずいた箇所で同じ失敗を繰り返す。そこで実務者は、過去の実行の記録から「次はこうする」という指針を取り出して貯め、モデルの重みは変えずに次の実行のプロンプトに入れる。本稿は、この仕組みを学習メモリと呼ぶ。

指針は実行を重ねるほど増え、プロンプトは長くなる。モデルが読む文字列の単位をトークンと呼び、エージェントの費用は読んだトークンの数に応じて増える。モデルによっては、指針をすべて渡しても、選んで渡すより成績の伸びが小さく、トークンだけが増える。実務者は、貯めた指針を毎回すべて渡すか一部を選んで渡すかを、何を基準に決めればよいかが分からない。

過去の実行から学ぶ方法には、学習メモリのほかに、モデルの重みを追加学習する方法、プロンプト全体を書き直して短くまとめる方法（プロンプト最適化）、必要になった時点でツールを使って情報を読み込む方法がある。本稿は学習メモリの例として、Stanford University・SambaNova Systems・UC Berkeley の研究者が論文で示した ACE と、IBM Research が公開した ALTK-Evolve を取り上げる。二つを選んだ理由は三つある。どちらもオープンソースで、作り手が設計の理由を公開している。IBM Research は、二つを比べた測定も公開している。ALTK-Evolve は、渡す量を文書化された設定で変えられる。

問い

ACE は過去の実行から何を作って次の実行に渡し、その渡し方は ALTK-Evolve とどこが違うのか。

要点

ACE は実行から取り出した指針を箇条で積み増し、その全体をプロンプトに入れる手法である。ALTK-Evolve とは指針の作り方と渡す量が違い、費用の差を生むのは渡す量で、全部と一部のどちらがよいかは使うモデルで変わる。

IBM が ALTK-Evolve で示した 5 モデルでは、3 モデルで指針の全部を、gpt-oss-120b だけ一部を渡すのが最良だった。gpt-oss-120b で ACE と比べた IBM の単回の測定では、ALTK-Evolve は達成率で ACE と並び、使うトークンを ACE の約 7 分の 1 に抑えた。

モデル・例示

家計簿アプリのエージェントで、ACE が指針を 1 件足して次の課題に渡す

※ この節の例は、説明のために作った架空のものです。

全部を渡す ACE と選んで渡す ALTK-Evolve の差は、入るトークンの量と、モデルに届かない指針の両方に出る。家計簿アプリの API（Application Programming Interface）を呼び、利用者の頼みを片付けるエージェントがあるとする。このエージェントは、モデルが考え、ツールを一回呼び、結果を読む繰り返しで課題を進める。この繰り返しの一回を ReAct ステップと呼ぶ。この家計簿アプリでは、支払いの記録のサービス名がメモ欄に半角カナで入っているとする。

ACE は、貯めた指針の一覧をプレイブックと呼ぶ。この時点のプレイブックには 5 件の箇条がある。前の課題は「先月の音楽配信の支払いを一覧にする」だった。エージェントはメモ欄を全角カナの「オンガク」で検索して 0 件を受け取り、支払いを全件読み出して、メモ欄が「ｵﾝｶﾞｸ」の記録を見つけた。この実行のあと、ACE は三つの役で箇条を 1 件足す。

  1. Generator1. 課題を実行し、「オンガク」の検索で 0 件、全件の読み出しで「ｵﾝｶﾞｸ」の記録を得る
  2. GeneratorReflector2. 検索語と結果を含む実行の記録を渡す
  3. Reflector3. 記録を振り返り、「メモ欄は半角カナでも検索する」という教訓を取り出す
  4. ReflectorCurator4. 教訓を渡す
  5. Curator5. 既存の 5 件を書き換えず、新しい ID の箇条を 6 件目として足す
  6. CuratorGenerator6. 6 件のプレイブックを、次の課題で全体ごとプロンプトに入れる

足された箇条は、リポジトリが示す形に合わせると [str-00006] helpful=0 harmful=0 :: メモ欄の検索では、半角カナと全角カナを別の文字として扱う になる。helpful と harmful は、その箇条が役に立った回数と害になった回数である。Curator は既存の箇条を要約し直さないので、1 件目から 5 件目の文言はそのまま残る。

ALTK-Evolve は、同じ 6 件のそれぞれに支持件数を付ける。支持件数は、その指針が何件の別々の課題から得られたかを表す。6 件目は前の課題 1 件から得られたので、支持件数は 1 である。ALTK-Evolve の中核と検索で渡す設定（IBM の呼び方は curated retrieval）は、支持件数 3 以上の指針を中核として毎ステップ入れ、残りからは課題に最も近い 1 件を選んで足す。

指針支持件数中核と検索で渡るか
一覧の API は 1 回に 20 件までしか返さないので、最後のページまで送る5渡る（中核）
日付は利用者の地域の時刻に直してから比べる4渡る（中核）
送金の前に、宛先の ID を連絡先の一覧で確かめる3渡る（中核）
ログインのセッションは課題の初めに作り直す2渡らない
返金は元の支払いの ID を指定して頼む1渡る（検索）
メモ欄の検索では、半角カナと全角カナを別の文字として扱う1渡らない

次の課題は「先月の音楽配信の支払いを集め、二重に引き落とされた分の返金を頼む」で、どちらの設計でも 20 ステップで終わるとする。ここでは指針の部分のトークンだけを数え、要求やツールの結果は数えない。どの指針も 40 トークンとする。

ACE は 6 件すべてを毎ステップ入れるので、課題全体の指針は 20×6×40=4,80020 \times 6 \times 40 = 4{,}800 トークンになる。中核と検索では、中核の 3 件と、検索で選ぶ 1 件が入る。この例では、検索は課題の文の「返金」と語が重なる返金の指針を選び、半角カナの指針は選ばないとする。課題全体では 20×4×40=3,20020 \times 4 \times 40 = 3{,}200 トークンである。差の 1,6001{,}600 トークンは、中核と検索で渡らないログインと半角カナの 2 件の分（20×2×4020 \times 2 \times 40）にあたる。

結果が分かれうるのは、半角カナの指針である。エージェントは今回も「オンガク」で検索する。ACE ではこの指針がプロンプトに入っているので、モデルが従えば「ｵﾝｶﾞｸ」でも検索し直し、二重の引き落としを見つける。中核と検索では、この指針は支持件数が 1 で中核に入らず、検索でも選ばれない。エージェントは 0 件を受け取り、二重の引き落としは無いと答えうる。

二つの設計を同じ課題で数えると、次の三点が分かる。

  1. 全部を渡すと、指針のトークンは件数とステップ数の積で増える。選んで渡すと、指針が数百件に増えても、入る量は中核の件数と選ぶ件数で決まる。
  2. 選んで渡すと、支持件数が低く、課題の文と語の重ならない指針はモデルに届かない。例の半角カナの指針がこれにあたる。
  3. 全部を渡して増える分（例では 1,6001{,}600 トークン）が見落としを防ぐ費用で済むか、判断を誤らせるかは、課題に関係しない指針をモデルが無視できるかで決まる。これは例の数からは決まらず、モデルごとに測る必要がある。

ACE は要約し直さず、指針を箇条で積み増してプレイブック全体を渡す

ACE は、要約し直すと細部が消えるという問題から、教訓を箇条で積み増して全体を渡す設計を選び、長い入力の費用は KV キャッシュ（Key-Value cache）で抑えられると考える。ACE（Agentic Context Engineering）は Zhang らが 2025 年 10 月に arXiv で発表し、ICLR 2026 に採録された手法で、著者は Stanford University、SambaNova Systems、UC Berkeley に所属する1。実装のリポジトリ ace-agent/ace は 2025 年 11 月に作られ、ライセンスは Apache-2.0 で、2026 年 10 月 22 日の時点で GitHub のスターは 1,386 である2。

論文によると、文脈を改善する既存の方法には二つの欠点がある1。一つは、最適化を重ねるとプロンプトが短く一般的な文へ縮む傾向である。もう一つは、貯めた文脈をモデルに毎回すべて書き直させると、細部が失われて文脈が崩れる現象である。論文の測定では、別の手法で 60 ステップ目に 18,282 トークンで正解率 66.7 だった文脈が、次の書き直しで 122 トークンに縮み、正解率は文脈を使わない場合の 63.7 より低い 57.1 に下がった1。どちらの問題も、プロンプト全体を書き直す方式で起きる。ACE の Curator が既存の箇条を書き換えずに新しい箇条を足すのは、この崩れを避けるためである。

ACE の論文とリポジトリでは、プレイブックの各項目は、固有の ID と、役に立った回数と害になった回数を数えるカウンタを持つ箇条である1。リポジトリが示す項目の形は [str-00001] helpful=5 harmful=0 :: Always verify data types before processing である2。Generator が課題を実行し、Reflector が実行を振り返って教訓を取り出し、Curator が教訓を差分としてプレイブックに統合する2。Curator は新しい ID の箇条を足し、既存の箇条をその場で更新する。さらに、文の意味を数値のベクトルで表した埋め込みで箇条どうしを比べ、重複を削除する1。

ACE の実装は、プレイブック全体を一つの文字列としてモデルに渡す2。毎ステップ全体を渡すと明言しているのは IBM の記事で3、論文自身は、箇条に分けた設計の利点の一つに、関連する知識だけを取り出せることも挙げている1。全体を渡す設計の前提として、論文は二つを置く。文脈は簡潔な要約ではなく、網羅的で構造化されたプレイブックとして働くべきだという前提と、言語モデルは長く詳しい文脈から関連する部分を自分で取り出せるという前提である1。後者は、課題に関係しない指針をモデルが無視できると想定することにあたる。

全体を渡すと、入力は箇条の数に比例して長くなる。その費用について論文は、入力が長くなっても推論の費用と GPU（Graphics Processing Unit）のメモリは比例して増えはしないと述べ、その理由に KV キャッシュを挙げる1。KV キャッシュは、モデルが一度読んだ入力の途中の計算結果を保存し、同じ先頭部分を次に読むときに計算し直さない仕組みを指す。著者らの GPT-5.1 での評価では、入力トークンの 91.8% をキャッシュから供給した1。リポジトリの設定では、プレイブックの大きさの上限となるトークン予算の既定値が 80000 である2。

論文はベンチマーク AppWorld の test-normal の分割で、DeepSeek-V3.1 を使う ReAct のエージェントの TGC（Task Goal Completion、課題の目標の達成率）を報告する1。学習用の分割で先にプレイブックを作るオフライン適応では、TGC が 63.7 から、正解ラベルを使う ACE で 76.2、使わない ACE で 75.0 に上がった1。論文は限界も挙げる。ACE は十分に強い Reflector を前提としており、Reflector が弱いとプレイブックは雑音になり、害にもなりうる1。

ALTK-Evolve は支持件数で中核を決め、渡す量をモデルごとの設定にする

ALTK-Evolve も学びを要約せずに保持するが、支持件数で中核を決め、残りを課題ごとに検索して渡し、渡す量をモデルごとに設定する。ALTK-Evolve は IBM Research が GitHub の AgentToolkit 組織で公開するリポジトリで、ライセンスは Apache-2.0、2026 年 10 月 22 日の時点でスターは 129 である4。研究論文は 2026 年 3 月に arXiv に出て、IBM は 2026 年 4 月にこの実装を開発者向けに公開した4。README は ALTK-Evolve を、毎回白紙から始めるので同じ失敗を繰り返すコーディングエージェントに記憶を与える道具と説明する4。

IBM の方針は「数え、まとめない」である3。ALTK-Evolve は、似た指針を一つの文に要約し直す代わりに、各指針が何件の別々の課題から得られたかを支持件数として数える5。ほぼ同じ指針はまとめて一つを残し、残った指針がまとめた指針の支持件数の合計を引き継ぐ3。IBM は、指針を戦略・回復・最適化の型に分け、どの実行の記録から得たかを残す点も、ACE との作り方の違いに挙げる3。支持件数が 3 以上の指針は中核として毎回渡し、支持件数が 1 以上の指針を保持する。二つの閾値は設定 EVOLVE_CORE_SUPPORT と EVOLVE_MIN_SUPPORT で変えられ、既定値は 3 と 1 である4。

中核に入らない指針からは、課題ごとにコサイン類似度（二つの埋め込みの向きの近さ）か言語モデルの判断で数件を選んで足す3。支持件数が低く、課題の文と語の重ならない指針は、この段で選ばれずにモデルに届かない。IBM 自身も、コサイン類似度の順位はどの指針が課題に役立つかを完全には予測しないと書いている6。その次の手として IBM が挙げるのは、課題の成否を信号に学習した選択器である6。リポジトリの文書は、実行をサブタスクに分けて指針を作る設定を有効にすると、失敗した試みと後の訂正が別の断片に分かれ、両方の指針が同じ支持件数で保存されるので、検索が逆の規則を正しい規則より上に並べうると書く4。この設定が既定で無効なのはそのためで、無効にすると矛盾は元から出なくなったという4。

渡す量は、モデルに合わせて設定で選ぶ。IBM は、統合した全量はそれを使いこなす余力のある強いモデルに渡し、弱いモデルには課題ごとに選んで渡すとしている3。リポジトリの文書は、どれだけ入れるかはモデルによるので既定値のほかに推奨する値はない、としている4。

全部と一部のどちらがよいかがモデルで変わるかを確かめるため、IBM は 8 モデルを測った6。AppWorld の test-normal の 168 課題で、IBM は学習用の分割から一度だけ指針を取り出し、重みを変えずに三つの設定を比べた6。指針なし、全量（すべての指針を ReAct ステップごとに入れる）、中核と検索（信頼の高い一定の中核と、課題に関係する数件）である。

モデル指針なしの TGC最良の TGC最良だった設定
gpt-oss-120b39.956.0中核と検索
DeepSeek-V3.279.889.3全量
Claude Opus 4.690.594.6全量
GPT-5.592.395.2全量
GLM-587.5変化なしなし

表は IBM が代表として示した 5 モデルで、主張を担うのは gpt-oss-120b の行である。示された 5 モデルの中では、指針なしの成績が最も低いこのモデルだけ、中核と検索が最良だった6。トークンの増え方もモデルで違った。gpt-oss-120b に全量を渡すと課題あたりのトークンは 110K から 166K へ 51% 増え、中核と検索では 116K で 5% の増加だった6。DeepSeek-V3.2 は 1 課題あたり 18〜19 回の ReAct ステップで課題を終え、全量が最良で、トークンは 148K から 263K へ 78% 増えた6。

IBM は、大きな文脈は弱いモデルを助けるよりも処理しきれなくさせると説明する3。ただし同じ記事の測定では、全量を渡す ACE も gpt-oss-120b の TGC を 39.9 から 54.8 に上げており、全量が成績を上げなかったわけではない3。また IBM は、モデルの分類は観察によるもので原因は証明していないこと、パラメータ数だけでは傾向が決まらないこと、モデルのコンテキストウィンドウの大きさが効くという仮説はまだ試していないことを断っている6。

IBM による ACE との比較は、渡す量のほかに指針の数とプロンプトの型も違う

IBM は別の記事で、ACE と ALTK-Evolve を AppWorld で比べた3。これは一方の作り手が、自分の実行で他方を測った結果で、二つは渡す量のほかに指針の数とプロンプトの型も違う。そのため、トークンの差を選んで渡すことだけの効果とは読めない。IBM の挙げる留保は三つある。ACE の数字は ACE の論文のものではなく IBM 自身の実行によるもので、論文は DeepSeek-V3.1 を使っていた。プロンプトの型が違うので、DeepSeek-V3.2 の指針なしの TGC も二つの型で 72.0 と 79.8 に分かれる。どの数字も単回の実行である3。

DeepSeek-V3.2 では、ACE（106 件の指針）が TGC を自分のプロンプトの型での指針なしの 72.0 から 80.4 へ、ALTK-Evolve（191 件）が 79.8 から 89.3 へ上げた3。伸びは 8.4 ポイントと 9.5 ポイントで近く、最終の TGC の差の大部分は指針なしの出発点の差から来ている。課題あたりのトークンは ACE が 634K、ALTK-Evolve が 263K、指針なしが 148K だった3。

gpt-oss-120b では、ACE（全量）が 54.8、ALTK-Evolve（選んだ約 29 件）が 56.0 で、トークンは 777K と 116K だった3。ALTK-Evolve の gpt-oss-120b の再実行は 54.8 で誤差の範囲だったので、IBM はこのモデルでの達成率を引き分けとしている3。大きく違うのはトークンで、ALTK-Evolve は ACE の約 7 分の 1 だった。ただし ALTK-Evolve 自身の全量でも gpt-oss-120b のトークンは 166K で6、全量を渡す方式どうしでも課題あたりのトークンには差がある。

入力を長くする代償は開発元の外でも報告されている

入力を長くすると性能が落ちうるという指摘は、関係しない指針が判断を誤らせうることを、開発元の外から支える。Anthropic の Applied AI チームが公開したコンテキストエンジニアリングの指針は、コンテキストを、増やすほど得られる効果が減る有限の資源として扱うよう求める7。同じ指針によると、言語モデルには大量の文脈を読むときに使う「注意の予算」があり、新しいトークンはどれもこの予算を減らす7。そのうえで指針は、ファイルのパスや保存した問い合わせのような軽い識別子を持っておき、実行中にツールで必要なデータを読み込む方法を勧める7。エージェントが定期的にメモを書き、後でコンテキストに読み戻す方法も、エージェントの記憶として挙げている7。

Chroma の Hong らは 18 の言語モデルを測り、すべての実験で入力が長いほど性能が落ちたと報告する8。課題は長い入力を扱う合成の課題で、著者らは、実際の使い方を網羅していないこと、性能が落ちる仕組みを説明していないことを断っている8。この測定は、長い入力にも代償があることを示す外部の証拠であり、ACE や ALTK-Evolve の測定ではない。

最適な量が領域でも変わるかは、課題の数が足りず決まらない

最適な量が領域でも変わるかどうかは、まだ決まっていない。IBM は τ²-bench の小売と航空の二つの領域で、GPT-4.1 に学習用の課題から指針を取り出させ、システムプロンプトの業務方針（domain policy）の後に箇条で足した5。各課題を 4 回ずつ試した成功率は、小売（40 課題）で指針なし 78.1%、支持件数 3 以上の指針 78.8%、全量 82.5% で、航空（20 課題）で 57.5%、60.0%、65.0% だった5。4 回すべてで成功した課題の割合（Pass4\mathrm{Pass}^4）では、小売は全量が 67.5% で最も高く、航空は支持件数 3 以上の 45.0% が全量の 40.0% を上回った5。航空の試験の課題は 20 件なので、この差は 1 課題分にあたり、各回の成功率ではどちらの領域でも全量が最も高い。ACE の論文も、すべての用途が詳しい文脈を要するわけではなく、HotPotQA では簡潔な指示のほうが役に立つとしている1。領域で最適な量が変わる兆しはあるが、それを確かめるには課題の数が足りない。

全量を渡すと、会話あたりの費用は小売で 65%、航空で 32% 増えた5。プロンプトキャッシュは、同じ先頭部分を持つ入力の計算結果を提供側が再利用し、安く処理する機能である。IBM は、この機能で費用の増加を相殺できる可能性を挙げる5。

利用者は渡す量をモデルごとに測って決める

ここからは本稿の解釈である。利用者は、モデルを替えるたびに全量と中核と検索の両方を自分の課題で測り、渡す量を決める。5 モデルのうち gpt-oss-120b だけで中核と検索が最良だったことを、IBM は観察として報告しており、原因は証明していない。gpt-oss-120b では、全量を渡す ACE との達成率の差も誤差の範囲だった。参照できる比較の数字は、どれも開発元自身の単回の実行で、一つのベンチマークに限られる。

全量を渡す費用の一部は、下げられる。同じ先頭部分を繰り返し読むなら、ACE の評価のように入力の大半をキャッシュから供給できる。一方で、キャッシュが減らすのは計算の重複で、モデルが読む内容は同じである。

中核と検索が最良になる場面は限られる。IBM が示した 5 モデルのうち、DeepSeek-V3.2、Claude Opus 4.6、GPT-5.5 では全量が最良で、GLM-5 では指針を足しても成績が変わらなかった6。小売の領域でも全量が最良だった5。強いモデルを使い、キャッシュが効く形でプロンプトを組むなら、全量を毎回渡す ACE の前提は IBM の数字とも食い違わない。

いまのコーディングエージェントは、ACE も ALTK-Evolve も標準では組み込んでいない

Claude Code、Codex、GitHub Copilot、OpenCode の公式の文書には、ACE や ALTK-Evolve を取り入れたという記述は無い（2026年10月27日時点）。ALTK-Evolve については、IBM が、Claude Code と Codex に後から足す軽量版（Evolve Lite）を配っている4。Claude Code では、インストーラーが三つのものを置く。プロジェクトの CLAUDE.md から読み込ませる指針のファイル .evolve/EVOLVE.md、プラグインのスキル、補助のスクリプトである9。標準の機能ではなく、利用者が自分で入れる外付けの仕組みである。軽量版ではなく完全版のサーバ evolve-mcp を動かす場合について、README は、ローカルで開く API に認証が無く、同じ端末のどのプロセスからも記憶を読み書きできると書いている4。

一方で、四つのうち三つは、前の作業から得たことを次に渡す記憶を自前で持つ。

ツール標準の記憶何を残し、古い記憶をどう扱うか
Claude Codeauto memory（既定で有効）。Claude 自身がプロジェクトごとのメモのファイルに書き、次のセッションで読む10利用者の修正、確かめた進め方、好み、プロジェクトの事情を残す。コードから分かることは書かない10
Codexmemories。前の作業の文脈を、端末ごとのローカルの保存先に残す11必ず守らせる規則は AGENTS.md に書き、記憶は思い出す補助として扱うよう、文書は求める11
GitHub CopilotCopilot Memory。リポジトリの事実と利用者の好みを残す12使う前に、事実に付けたコードへの参照を今のブランチで確かめ、有用さを Copilot 自身の投票で数える。票を得た記憶ほどプロンプトに入りやすく、作られてから、または最後に票を得てから既定で 90 日たつと消える12
OpenCodeAGENTS.md。/init がリポジトリを調べて作り、更新する13本稿が読んだ文書の範囲では、作業から自動で学ぶ記憶は無い

どの記憶も、ACE のように実行の成否を振り返って指針を積み増す仕組みとしては説明されていない。Copilot の文書は、記憶をすべてプロンプトに送るのではなく、票を得た記憶ほど送りやすくすると書く12。ただし票は Copilot が自動で入れるもので、利用者がモデルに合わせて渡す量を変える ALTK-Evolve の設定とは違う12。Copilot が参照で記憶を確かめ、票で残す記憶と送る記憶を決めるのは、指針が古くなる問題への、ACE とも ALTK-Evolve とも違う答えである。本稿は、ACE と ALTK-Evolve が論じる「全部か一部か」を自分の作業で試すなら、いまは ALTK-Evolve の軽量版を入れるか、自分で組むことになると考える。

出典13件

  1. Zhang ほか「Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models」ICLR, 2026. https://arxiv.org/abs/2510.04618 — 書き直しで細部が消える問題、箇条の積み増し、キャッシュの評価、強い Reflector が要る限界。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13

  2. ace-agent「ace」GitHub（2026-10-22 取得）. https://github.com/ace-agent/ace — Apache-2.0、1,386 スター、2025-11 作成。Generator・Reflector・Curator の役割と、プレイブックのトークン予算の既定値 80000。 ↩ ↩2 ↩3 ↩4 ↩5

  3. IBM Research「Thinking of ACE? We Can Do It with Fewer Tokens」Hugging Face Blog, 2026. https://huggingface.co/blog/ibm-research/altk-evolve-sldd — ACE との比較。IBM 自身の単回の実行で、プロンプトの型が異なり、gpt-oss-120b の達成率は引き分け。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14

  4. IBM Research「ALTK-Evolve」GitHub（2026-10-22 取得）. https://github.com/AgentToolkit/altk-evolve — Apache-2.0、129 スター。中核と保持の閾値の既定値 3 と 1、渡す量はモデルによるという説明、サブタスク分割を既定で無効にする理由。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  5. IBM Research「ALTK-Evolve: How learned memory tops the τ²-bench leaderboard」Hugging Face Blog, 2026. https://huggingface.co/blog/ibm-research/altk-evolve-bc — 最良の量が小売と航空で異なり、試験の課題は 40 件と 20 件。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  6. IBM Research「How Much Memory Does Your Agent Actually Need?」Hugging Face Blog, 2026. https://huggingface.co/blog/ibm-research/altk-evolve-hmm — AppWorld の 5 モデルで最良の渡し方が分かれた測定と、原因は未証明という著者の留保。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10

  7. Anthropic Applied AI team「Effective context engineering for AI agents」Anthropic Engineering, 2025. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents — コンテキストを有限の資源とし、必要な時点で読み込む方針。 ↩ ↩2 ↩3 ↩4

  8. Hong ほか「Context Rot: How Increasing Input Tokens Impacts LLM Performance」Chroma, 2025. https://www.trychroma.com/research/context-rot — 18 モデルで入力が長いほど性能が落ちた測定。合成の課題で、エージェントの記憶の測定ではない。 ↩ ↩2

  9. IBM Research「Starter Example with Evolve and Claude Code」ALTK-Evolve docs, 2026（2026-10-27 取得）. https://agenttoolkit.github.io/altk-evolve/examples/hello_world/claude/ — Evolve Lite のインストーラーが置くものと、プラグインだけでは足りないこと。 ↩

  10. Anthropic「How Claude remembers your project」Claude Code Docs, 2026（2026-10-27 取得）. https://code.claude.com/docs/en/memory — CLAUDE.md と auto memory の違い、auto memory が残す 4 種類と既定で有効なこと。 ↩ ↩2

  11. OpenAI「Memories」Codex Docs, 2026（2026-10-27 取得）. https://developers.openai.com/codex/memories — ローカルの記憶の置き場と、必ず守らせる規則は AGENTS.md に書くこと。 ↩ ↩2

  12. GitHub「About GitHub Copilot Memory」GitHub Docs, 2026（2026-11-02 取得）. https://docs.github.com/en/copilot/concepts/agents/copilot-memory — 参照による確認、自動の投票で送る記憶を選ぶこと、既定 90 日の期限。 ↩ ↩2 ↩3 ↩4

  13. OpenCode「Rules」opencode.ai, 2026（2026-10-27 取得）. https://opencode.ai/docs/rules/ — AGENTS.md と /init による生成・更新。 ↩

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。