エージェントの「長期記憶」は幻想だった

2026年のLLMはエージェントとして動くことが前提になりつつある。ツールを呼び、結果を受け取り、次のアクションを決め、また呼ぶ。Claude Code、Cursor、Devin——どれも「長時間ループ」を基本戦略としている。

しかしこの戦略は、8GB VRAMのローカル環境では物理的に成立しない。

私はRTX 4060 Laptop (8GB) + Qwen2.5-7B Q4_K_Mでllama.cppベースのツール呼び出しエージェントを試した。結果は単純だ。ツール呼び出し5回を超えたあたりから、応答品質が目に見えて劣化する。 10回を超えると、直前に自分が呼んだツールの結果を無視し始める。

この記事では、この劣化がなぜ起きるのかをKVキャッシュとContext Rotの観点から分解し、8GBで使える3つの迂回策を検討する。

ツール呼び出しはどれだけKVキャッシュを食うか

ツール呼び出し1回のトークンコストを考えてみる。

1回のツール呼び出しサイクル:
  システムプロンプト         : ~500 tok (固定)
  ユーザー指示               : ~200 tok (固定)
  過去の会話履歴             : 可変 (蓄積)
  ツール定義 (function schema): ~300 tok × ツール数
  LLMの応答 (tool_call)      : ~100 tok
  ツール実行結果             : ~500-2000 tok (可変)

5つのツールを定義し、各呼び出しで平均800トークンの結果が返るとする。ステップごとのKVキャッシュ蓄積を概算すると:

ステップ	累積トークン	KVキャッシュ (fp16)	VRAM残り (7B Q4_K_M)
0 (初期)	~2,200	0.12 GB	2.60 GB
3	~4,900	0.26 GB	2.46 GB
5	~6,700	0.36 GB	2.36 GB
10	~11,200	0.60 GB	2.12 GB
20	~20,200	1.08 GB	1.64 GB
30	~29,200	1.56 GB	1.16 GB

def agent_vram_estimate(steps, tokens_per_step=900, base_tokens=2200,
                        model_gb=4.68, overhead_gb=0.6,
                        n_layers=28, n_kv_heads=4, head_dim=128, dtype_bytes=2):
    """エージェントループのVRAM消費推定"""
    total_tokens = base_tokens + steps * tokens_per_step
    kv_gb = (2 * n_layers * total_tokens * n_kv_heads * head_dim * dtype_bytes) / (1024**3)
    total_gb = model_gb + kv_gb + overhead_gb
    return {
        "steps": steps,
        "tokens": total_tokens,
        "kv_cache_gb": round(kv_gb, 2),
        "total_vram_gb": round(total_gb, 2),
        "remaining_gb": round(8.0 - total_gb, 2)
    }

for s in [0, 5, 10, 20, 30, 50]:
    r = agent_vram_estimate(s)
    print(f"Step {s:2d}: {r['tokens']:,} tok, KV={r['kv_cache_gb']}GB, 残り={r['remaining_gb']}GB")

30ステップあたりでVRAM残りが1GBを切り、50ステップで理論上OOMが見えてくる。Q4 KVキャッシュ量子化(--cache-type-k q4_0 --cache-type-v q4_0)を使えば約3.5倍に圧縮できるが、それでも100ステップ超の長期ループは現実的ではない。

ただし、OOMより先にもっと深刻な問題が来る。

Context Rot — 長いコンテキストが品質を殺す

VRAMに収まっていても、コンテキストが長くなると応答品質が崩壊する。これは「Context Rot」として知られる現象だ。

Chroma Researchの報告によれば、LLMの情報再現精度はトークン数に反比例して低下する。特にエージェントのような「中間結果の蓄積」パターンでは劣化が顕著だ。

MicrosoftとSalesforceの共同研究 "LLMs Get Lost In Multi-Turn Conversation" (arXiv:2505.06120) はさらに具体的な数字を出している。ベンチマークプロンプトをマルチターン会話（エージェントワークフロー類似）に変換したところ、6つの生成タスクで平均39%の性能低下を報告した。o3やDeepSeek-R1のような推論特化モデルでさえこの傾向から免れなかった。

7Bモデルではこの劣化がさらに早く始まる。私がQwen2.5-7Bで確認した挙動:

ステップ3-5: 正常動作。ツール結果を正確に参照し次のアクションを選択
ステップ5-8: 初期の指示を忘れ始める。同じツールを冗長に再呼び出し
ステップ8-10: 直前のツール結果を無視。ハルシネーション混入率が上昇
ステップ10+: 会話の方向性を失う。ツール呼び出しが目的と無関係になる

これは「Lost in the Middle」(Liu et al., TACL 2024)で指摘された中間情報の忘却と同じ構造だ。エージェントの場合、ステップ3-4のツール結果がちょうど「中間」に押し出され、先頭のシステムプロンプトと末尾の最新結果だけが参照される。

大型モデルなら解決するのか

反論として重要なデータがある。

GPT-4.1はツール重視の対話で劣化しなかった。 Parloaの検証で、大型モデルは長い会話でも安定した性能を維持している。

MemAgentは8Kコンテキストから3.5Mトークンのタスクに外挿し、性能損失10%未満を達成した(OpenReview)。RLM（Recursive Language Model）は1000文書・10M+トークンでも91.33%の精度を維持している。

ただし、これらはすべて数十〜数百GBのメモリを持つ大型モデルかクラウド推論の話だ。

8GB VRAMで動く7Bモデルの場合:

コンテキストウィンドウ自体が物理的に制限される（前述の通り）
Attentionヘッド数が少ないため長距離依存関係の保持力が弱い
GQA (Grouped Query Attention) でKVキャッシュは節約できるが、モデルの「記憶力」自体は改善しない

「モデルサイズが十分なら問題は緩和される」のは事実だが、「8GBでは設計で迂回するしかない」もまた事実だ。

迂回策① 短ループ×コンテキストリセット

最もシンプルで効果的な方法。エージェントのループを短く区切り、各ループの開始時にコンテキストをリセットする。

def short_loop_agent(task: str, tools: list, max_steps_per_loop: int = 5):
    """短ループ×リセット戦略のエージェント"""
    memory = []  # ループ間で引き継ぐ要約のみ
    
    while not is_task_complete(memory):
        # コンテキストを最小限で再構成
        context = build_context(
            system_prompt=SYSTEM_PROMPT,
            task=task,
            memory_summary=summarize(memory[-3:]),  # 直近3件の要約のみ
            tools=tools
        )
        
        # 短いループを実行
        for step in range(max_steps_per_loop):
            response = llm.generate(context)
            if response.tool_call:
                result = execute_tool(response.tool_call)
                context.append(result)
                memory.append({"step": step, "tool": response.tool_call, "result_summary": summarize_result(result)})
            else:
                break
        
        # ループ終了時: コンテキストをリセット、要約のみ持ち越し
        # KVキャッシュは解放される

ポイントはmemory_summaryだ。ループ間で渡すのは生のツール結果ではなく、その要約。これでKVキャッシュの蓄積を防ぎつつ、必要な情報は保持する。

5ステップ×6ループ＝30ステップ相当のタスクを、各ループ約6,700トークン（KVキャッシュ0.36GB）で処理できる。30ステップを一気に回す場合の1.56GBと比べて、VRAM消費は4分の1以下だ。

迂回策② Persistent Q4 KV Cache

arXiv:2603.04428 "Agent Memory Below the Prompt" (2026) は、エージェントのKVキャッシュをディスクにQ4量子化して永続化し、必要時にAttentionレイヤーに直接ロードする手法を提案している。

この論文がApple M4 Proで検証した結果:

FP16では10.2GBのKVキャッシュ予算で3エージェント分しか保持できない
Q4量子化で4倍のエージェントコンテキストが同じメモリに収まる
キャッシュ復元によるTTFT (Time-to-First-Token) 改善: 最大136倍 (Gemmaで22〜136倍、DeepSeekで11〜76倍)

この手法の本質は「再計算の回避」だ。通常、コンテキストを復元するには全トークンのprefill計算をやり直す必要がある。Persistent KV Cacheはこの計算を丸ごとスキップして、保存済みのKVキャッシュを直接ロードする。

この論文はApple M4 Proで検証されたものだが、原理はRTX 4060でも同じだ。llama.cppには現時点でKVキャッシュの保存/復元APIが実験的に実装されている(--save-state, --load-state)。NVMe SSD上にエージェントごとのKVキャッシュスナップショットを保存し、タスク切り替え時にロードすることで、prefill再計算を回避できる。8GBでは同時に保持できるエージェントコンテキストが1つに限られるため、この「スワップ」戦略の恩恵がM4 Pro以上に大きい。

迂回策③ 動的ツール選択（Tool Loadout）

ツール定義が増えるとモデルの選択精度が落ちる。Berkeleyのfunction-calling leaderboardでも、ツール数が増えるほど説明が重複し正しいツールの選択が困難になる傾向が確認されている。経験的には、7Bモデルでは5〜10ツールが実用的な上限だ。ツール定義自体がコンテキストを消費し、KVキャッシュを圧迫するためだ。

解決策は「全ツールを常時定義しない」こと。

def dynamic_tool_selection(query: str, all_tools: list, max_tools: int = 5):
    """クエリに応じてツールを動的に選択"""
    # 軽量な分類器でクエリカテゴリを判定
    category = classify_query(query)  # "search", "code", "data", etc.
    
    # カテゴリに応じてツールサブセットを選択
    tool_groups = {
        "search": ["web_search", "file_search", "grep"],
        "code": ["run_python", "read_file", "write_file"],
        "data": ["sql_query", "csv_parse", "chart_generate"],
    }
    
    selected = tool_groups.get(category, all_tools[:max_tools])
    return selected

20ツールの定義をすべてコンテキストに入れると約6,000トークン。5ツールに絞れば約1,500トークン。差の4,500トークンは、Q4 KVキャッシュでも0.04GBの節約になる。小さく見えるが、30ステップのループではこの差が蓄積して1.2GB以上の差になる。

8GBエージェントの設計原則

3つの迂回策を組み合わせた設計原則をまとめる。

原則1: ループは5ステップ以内

7Bモデルのコンテキスト品質が維持できるのは約6,000〜8,000トークンまで。ツール呼び出し1回あたり900トークンとすると、5ステップが上限だ。

原則2: 記憶は「要約」で持ち越す

生のツール結果をコンテキストに残さない。各ループ終了時に結果を要約し、次のループではその要約のみを参照する。

原則3: ツール定義は5つまで

動的ツール選択で、各ステップに必要なツールだけをロードする。「万能エージェント」は8GBでは成立しない。

原則4: 「コンテキスト品質」を監視する

ツール呼び出しの「的中率」（呼んだツールが目的に合致していたか）を追跡し、低下したらループをリセットする。自動リセットのトリガーに使える。

8GBの制約はエージェント設計を改善する

128Kコンテキストの記事でも書いたが、8GBの制約は「ハンデ」ではなく「設計の強制力」だ。

クラウドの大型モデルは100ステップのエージェントループを力技で回せる。しかし、MicrosoftとSalesforceの研究が示すように、回せることと品質が維持されることは別問題だ。o3ですら39%劣化している。

8GBの制約は「5ステップで品質が落ちる」という事実を隠さない。だからこそ、短ループ設計・要約持ち越し・動的ツール選択という「本質的に正しい設計」に到達できる。これらの設計原則はクラウド環境でもそのまま適用できる——むしろ適用すべきだ。

エージェントの性能を決めるのは、コンテキストの長さではなく、コンテキストの品質だ。

参考

"Context Rot: How Increasing Input Tokens Impacts LLM Performance" (Chroma Research): https://research.trychroma.com/context-rot
"Lost in the Middle: How Language Models Use Long Contexts" (Liu et al., TACL 2024): https://arxiv.org/abs/2307.03172
arXiv:2603.04428 — Agent Memory Below the Prompt: Persistent Q4 KV Cache for Multi-Agent LLM Inference on Edge Devices
"LLMs Get Lost In Multi-Turn Conversation" (Microsoft Research & Salesforce, arXiv:2505.06120): https://arxiv.org/abs/2505.06120
Parloa Labs — Long Conversations and LLM Performance: https://www.parloa.com/labs/insights/long-calls-LLM-performance/
Berkeley Function-Calling Leaderboard: https://gorilla.cs.berkeley.edu/leaderboard.html
"Cutting Through the Noise: Smarter Context Management for LLM-Powered Agents" (JetBrains Research, NeurIPS 2025 Workshop): https://blog.jetbrains.com/research/2025/12/efficient-context-management/
llama.cpp: https://github.com/ggerganov/llama.cpp