長いコンテキストは記憶ではない：今週の2本の論文が示す、エージェントの状態をモデルの外に置くべき理由

何が壊れ、どう直すかを見るHover to explore

エージェントが長い変更履歴をたどって「今どうなっているか」を割り出しているなら、今週公開された2本の論文に10分を使う価値があります。4回担当者が変わったチケット、注文のたびに調整される在庫数、100件のメッセージを通じて増えたり減ったりする予算を思い浮かべてください。1本目の論文は、フロンティアモデルがそうした履歴を読めても、履歴が十分に長くなると最終的な状態を間違えることを示しています。2本目は、モデルが受け付けられる量よりはるかに少ないコンテキストを渡しても、精度をほとんど、あるいはまったく失わず、費用を大きく下げられることが多いと示しています。どちらも創業者向けに書かれたものではありませんが、2本をあわせると、今週から取り入れられる設計が見えてきます。

本記事は、Ai2によるStateBenchの発表とその技術レポートarXiv:2611.03094、およびarXiv:2611.05306「You don't need long context」に基づいています。数値と引用はこれらの文書によるものです。第3節以降の解釈は筆者によるものです。

1. StateBenchは何を測ったのか

StateBenchは、Ai2が11月3日に発表し、技術レポートの日付は11月2日です。測っているのは1つの限られた能力、つまり一連の更新をたどり、最終的な状態を答えることです。著者のJackson Petty、William Merrill、Ashish Sabharwalは、更新の種類だけが異なる4段階の難易度を用意しました。

• 固定の代入。 値が設定され、その後は変わらない。
• 値による再代入。 変数に新しい値が設定される。
• 自己更新。 x = x + 5 のように、変数が自分自身を基準に変わる。
• 参照による代入。 x = y のように、変数が別の変数の値を受け取る。あるいは2つの値が入れ替わる。

各問題は、同じ構造を持つ6つの形式で書かれています。素のコードから、スプレッドシートのセルを埋める形式、部屋を移動する人を追う形式までです。フロンティアモデルは選択肢から選ぶのではなく、自分の言葉で答えました。テストされたのはGemini 3.8 Flash、Claude Opus 5.5、GPT-6 SolとLunaの4つです。

結果ははっきりしていました。レポートによれば、すべてのフロンティアモデルは「r-trivialと非周期的な問題では高い性能を示す」一方、入力が10K〜64Kトークンに達すると「可解な問題と有限の状態追跡問題では偶然並みの正答率に落ちる」とされています。最初の2段階は持ちこたえ、残りの2段階は崩れました。Ai2の発表では、最も難しいケースは「最も長い一般有限問題で13%以下」とされています。

ベンチマークのスコアでモデルを選ぶ人にとって重要な発見がもう1つあります。RULER形式、いわゆる「干し草の山の中の針」系の問題でほぼ満点を取った小規模な事前学習モデルが、同じ問題をスプレッドシートの編集として出題すると、ほぼ偶然並みになったのです。長い入力の中から事実を見つけられることは、その事実がどう変わったかを追跡できることを意味しません。

2. 圧縮の論文は何を測ったのか

2本目の論文「You don't need long context」は、Peter Belcakと11人の共著者によるもので、11月3日に公開されました。出発点はコストです。「後のトークンほど、生成にかかるコストは高くなる。」著者らが運用したオープンウェイトモデルでは、256Kのコンテキストウィンドウでの生成は、16Kの場合に比べて3.6倍から7倍のコストがかかりました。

そのうえで、コンテキストを短く保つ2つの方法を試しています。1つ目では、エージェントはコンテキストがしきい値を超えるまで普通に動き、超えたら自分の状態を一定の長さに収めた要約を書きます。そして元のタスクとその要約から、新しい会話を始めます。2つ目はより極端で、各会話は1つのアクションだけを実行し、要約を更新して破棄されます。うまく機能した要約には、タスクのほぼそのままの写し、エージェントの現在の意図と次の手順、そして後の作業に必要な成果物が含まれていました。著者らはそれを物語ではなく「慎重に選び抜いた要約」と呼んでいます。

SWE-bench VerifiedやTerminal-Bench 2.1を含む長期タスクでは、精度の変化はClaude Opus 4.5で-3.7〜+5.6ポイント、GPT 5.6 Solで-3.3〜+4.4ポイントでした。一方、小売価格ベースの推定節約額はそれぞれ2.2〜8.8倍と2.4〜5.0倍です。入力の長いタスクでは、Opusの精度の変化は-0.4〜+40.0ポイントで、推定節約額は6.5〜54.6倍でした。1会話につき1アクションでも持ちこたえています。OpusはSWE-bench Verifiedで70.0から70.2に、GPT 5.6 Solは84.4から82.4になりました。

3. これは研究所ではなく、あなたの問題である

本番環境のエージェントの多くは、そう呼ばれているかどうかにかかわらず、状態を追跡しています。サポートのエージェントは、3回の引き継ぎを経たチケットの担当者が誰かを割り出します。購買のエージェントは、予算に対する累計を管理します。運用のエージェントは、イベントログから「今の状況は?」に答えます。StateBenchの用語でいえば、累計は自己更新であり、引き継ぎは参照による代入です。まさに入力が長くなるにつれてフロンティアモデルが偶然並みに落ちた2つの段階です。

よくある設計は、これをさらに悪化させます。多くのエージェントは、会話の記録全体とすべてのツールの結果をコンテキストに残し、毎ターン、そこから現在の状態を割り出すようモデルに求めます。20件のメッセージのデモならそれで動きます。しかしそれは、StateBenchが10K〜64Kトークンで崩してみせたパターンそのものであり、出力の多いツールを使うエージェントなら、1回の作業セッションで届いてしまう長さです。

圧縮の論文は、対策のコストが小さいことを示唆しています。難しいエージェントタスクで短い要約が精度を数ポイント以内に保てるなら、長い履歴から状態を再構築することをモデルに強いる理由はほとんどありません。そもそもモデルは、その状態の正本を保管する場所としてふさわしくありません。

4. 状態をプロンプトの外に出す

パターンはシンプルです。現在の状態はコードが持ちます。モデルはその状態を読み、変更を構造化された操作として提案し、コードがそれを適用します。各ターンは、履歴全体ではなく短い要約から始めます。

from dataclasses import dataclass, field

@dataclass
class OrderState:
    status: str = "draft"
    quantity: int = 0
    assignee: str | None = None
    log: list[dict] = field(default_factory=list)

ALLOWED_OPS = {"set_status", "add_quantity", "assign"}

def apply(state: OrderState, op: dict) -> OrderState:
    kind = op.get("op")
    if kind not in ALLOWED_OPS:
        raise ValueError(f"unknown operation: {kind}")
    if kind == "set_status":
        state.status = op["value"]
    elif kind == "add_quantity":
        state.quantity += int(op["value"])  # arithmetic happens here, not in the model
    elif kind == "assign":
        state.assignee = op["value"]
    state.log.append(op)  # full history kept for audit, not for the prompt
    return state

def brief(task: str, state: OrderState, next_steps: list[str]) -> str:
    return (
        f"TASK: {task}\n"
        f"CURRENT STATE: status={state.status}, quantity={state.quantity}, "
        f"assignee={state.assignee}\n"
        f"NEXT STEPS: {'; '.join(next_steps)}"
    )

注意点が2つあります。モデルが書いた要約は、モデルの出力です。9月にはモデルが自分の圧縮要約に指示を書き込んでいた事例を取り上げました。できる限り保存済みの状態から要約を組み立て、モデルが付け加えた内容を確認してください。そして、長い履歴、担当の付け替え、累計を含む状態追跡のケースを評価セットに加えてください。「干し草の山の中の針」のスコアでは、この問題は警告してもらえません。

5. 筆者が主張しないこと

フロンティアモデルは状態を追跡できない、とは言いません。 より単純な2つの段階ではよい結果でした。崩れたのは自己更新と参照で、10Kトークン以上の場合です。

StateBenchがあなたのプロダクトを表している、とは言いません。 使われているのは合成した系列です。筆者が読んだ範囲では、レポートはフロンティアモデルがどの推論設定を使ったかを示しておらず、コードの実行といったツールの利用で結果が変わる可能性もあります。自分たちのタスクで測ってください。

圧縮はタダだ、とは言いません。 著者ら自身がはっきり書いています。「会話の履歴を圧縮すれば、その結果として情報は失われる。」より弱いモデルは、厳しい予算で苦戦しました。Qwen 3 Coder Nextは、最も厳しい設定でSWE-bench Verifiedが53.0%から3.6%に落ちています。

長いコンテキストは役に立たない、とは言いません。 圧縮の論文は、その証拠が「長いコンテキストが有益なタスクの存在を否定するものではない」と述べています。長い契約書を一度読むことと、長いセッションを通して変化を追跡することは、別の仕事です。

正直なまとめ

11月2日と3日に公開された2本の論文は、正反対の方向から同じ実践的な結論にたどり着いています。StateBenchは、フロンティアモデルが固定の値と単純な再代入はうまく扱える一方、入力が10K〜64Kトークンに達すると、自己更新と参照の追跡で偶然並みに落ちることを示しました。「You don't need long context」は、エージェントのコンテキストを短い要約に圧縮しても、難しいエージェントタスクで精度をほとんど、あるいはまったく失わず、推定コストを数分の1にできることを示しました。

創業者にとっての教訓は、状態をどこに置くかです。コンテキストウィンドウはモデルが読む場所であって、プロダクトが記録を保管すべき場所ではありません。

今週、エージェントが長い履歴から現在の状態を割り出している箇所を1つ見つけてください。その状態をコードに移し、モデルには変更を構造化された操作として提案させ、各ターンを要約から始めてください。

出典:Ai2、StateBenchの発表(2026年11月3日)——4段階の難易度、テストされたフロンティアモデル、最も長い一般有限問題での「13%以下」という数値。Jackson Petty、William Merrill、Ashish Sabharwal、A Fine-Grained Hierarchy and Benchmark for State Tracking in Language Models, arXiv:2611.03094(2026年11月2日)——6つの形式、フロンティアモデルの生成形式での評価、10K〜64Kトークンでの偶然並みの結果、RULER形式とスプレッドシート形式の比較。Peter Belcakほか、You don't need long context, arXiv:2611.05306(2026年11月3日)——3.6〜7倍のサービングコストの比較、2つの圧縮手法と効果的な要約の中身、Claude Opus 4.5とGPT 5.6 Solの精度の変化と推定節約額、Qwen 3 Coder Nextの結果、そして明記された限界。第4節のコードは筆者による例示であり、第3〜5節の解釈は筆者によるものです。

Related Posts

2か月目の壁：AIエージェントはなぜ忘れるのか、そしてそれを解決するメモリーアーキテクチャ（2026年）2026年7月27日

誰も読み返さないエージェントの入力2026年9月18日

リファクタリング1件で14.29ドル。エージェントが読んだファイルは請求書に残り続けました2026年9月2日