AIエージェントの記憶劣化：マルチターンのLLMが崩壊する理由

熟議システム⁹の構築を始めて90分。エージェントは、その30分前に自分で議論していたはずのアーキテクチャに、一切言及しなくなりました。ログを追うと、Claudeが新しいツール出力のための領域を確保するため、モジュール依存グラフを圧縮して捨てていたことが分かります。エージェントはコードを書き続けていました。しかしそのコードは、最初の1時間で自ら定めたモジュール間の取り決めを、もはや反映していません。テストは通り、統合は失敗しました。エージェントは自分の設計を忘れていたのです。

この失敗で、丸一日をデバッグに費やしました。なぜそれが起きたのかは、いまや研究が説明してくれます。

要点

Microsoft ResearchとSalesforceは、15種類のLLMを20万件を超えるシミュレーション対話で検証し、シングルターンからマルチターンへ移ると性能が平均39%低下することを突き止めました。¹ 劣化はわずか2ターンから始まります。崩壊を引き起こすのは、互いに独立した3つのメカニズムです。コンテキスト圧縮が重要な状態を捨て、トークン予算が細るにつれて推論の一貫性が断片化し、共通の事実基盤がないままエージェント同士の連携が破綻します。コンテキストウィンドウを広げても、そのどれ一つ解決できません。Ralphループのパターン（反復ごとに新しいコンテキストを立て、状態はファイルシステムに置く）は圧縮による損失を回避しますが、別のコストを伴います。以下では、研究の中身、3つのメカニズム、今日から実行できる検知手法、そしてマルチターンに耐えるための手順を順に見ていきます。

90分の崖

コンテキストはアーキテクチャである、という記事⁸では、650ファイルにまたがる7層のコンテキスト体系を記録しました。この体系を組み上げるには、長時間にわたるコーディングが必要でした。その間エージェントは、モジュール境界、依存の連鎖、フックの実行順序、ファイル横断の取り決めといった、複雑なアーキテクチャ上の状態を保持し続けなければなりません。

2026年1月から2月にかけて、Ralphループの反復30回分について作業品質を測定しました。⁷ データには一貫したパターンが表れています。

Minutes 0-30:   Precise multi-file edits, correct cross-references
Minutes 30-60:  Occasional missed imports, still recoverable
Minutes 60-90:  Single-file tunnel vision, loses architectural context
Minutes 90+:    Repetitive attempts, contradicts earlier decisions

この品質の崖は、タスクの種類を問わず現れました。長時間のリファクタリング、テストスイートの構築、ドキュメントの一括整備——いずれも同じ曲線を描いて劣化します。違ったのは深刻さの度合いだけでした。ファイル横断の状態を多く要するタスクほど、単一ファイルで完結する作業よりも崖が急になります。

当初はこれをコンテキストウィンドウの逼迫と考え、回避策としてRalphループを組みました。反復ごとにClaudeのインスタンスを新しく立ち上げ、状態はファイルシステムから注入し、1回の反復を超えて対話上の記憶に頼らない。この方式は機能します。ただ、2025年5月に公開されたMSR/Salesforceの研究は、問題がコンテキストウィンドウの大きさだけに帰せられない、もっと構造的なものであることを明らかにしました。

マルチターン崩壊の3つのメカニズム

Labanらは、マルチターンでの劣化を互いに独立したメカニズムへと分解しました。この切り分けが重要なのは、それぞれに構造の異なる介入が必要だからです。¹

メカニズム1：コンテキスト圧縮

AIとの対話はすべて、有限のトークン予算の中で進みます。会話が伸びるにつれ、システムは新しい内容の場所を空けるために過去のターンを圧縮します。この圧縮では情報が失われます。3ターン目に記録したアーキテクチャ上の判断が、15ターン目まで生き残るとは限りません。

熟議システムを構築している最中に、私はこれを目の当たりにしました。最初の20分でエージェントはモジュール依存グラフを定めています。deliberation_engine.pyはconsensus_calculator.pyに依存し、それはvote_aggregator.pyに依存する、と。ところが75分の時点で、エージェントは依存の連鎖を圧縮して捨て、循環インポートを書きました。構文としては正しいコードです。そして循環インポートは実行時クラッシュを招きました。

検知方法： エージェントの出力に含まれるファイル横断参照の比率を、時系列で追ってください。前に扱っていたファイルに言及しなくなったら、圧縮が該当コンテキストを捨てた可能性が高いと判断できます。

# Count unique file references per 30-min window in a session log
# Declining count signals compression loss
git log --since="2 hours ago" --pretty=format:"%s" | \
  grep -oP '[a-z_]+\.(py|js|ts)' | sort -u | wc -l

メカニズム2：推論の一貫性の喪失

MSR/Salesforceの研究によれば、マルチターンでの劣化は2つの成分に分解できます。わずかな能力（aptitude）の低下と、大幅な信頼性（reliability）の悪化です。¹ 能力とは、そもそも正解を出せるかどうか。信頼性とは、それを安定して出せるかどうかを指します。

シングルターンでは、6種類の生成タスク全体で平均約90%の性能が出ました。マルチターンではおよそ65%まで落ち、絶対値で25ポイントの下落です。決定的な指摘はこうです。「マルチターン対話で一度誤った方向へ進むと、LLMは道に迷い、そこから戻ってこない」¹

推論の一貫性の喪失は、エージェントが自ら下した過去の判断と矛盾する形で表面化します。原因はコンテキストが圧縮で失われたこと（メカニズム1）ではなく、モデルの推論の連なりがターンをまたいで断片化したことにあります。各ターンの推論は局所的には筋が通っているのに、全体としては整合していないのです。

Duらの認知的意思決定ルーティングの研究は、このメカニズムに正面から取り組んでいます。² カーネマンの二重過程理論（速く直感的な反応と、遅く熟慮的な推論）に着想を得たこの仕組みは、タスクの要求に応じて推論の深さを変えます。示唆はこうです。すべてのターンが同じ深さの推論を必要とするわけではない。深さを一律にすれば、些末な手順に予算を浪費し、肝心な判断への投資が足りなくなります。

検知方法： 作業の序盤と終盤の出力に矛盾がないかを見てください。15分の時点で方式Aを推していたエージェントが、60分の時点で変更に触れないまま方式Bを推していれば、一貫性は劣化しています。

メカニズム3：連携の破綻

マルチエージェント構成では、マルチターン劣化に連携の破綻が上乗せされます。2つ以上のエージェントが1つのタスクで協働するとき、各エージェントのコンテキストはそれぞれ独立に劣化していきます。共有していたはずの制約を忘れたエージェントは、それを前提に足並みを揃えることができません。

Bhardwajらのエージェント・コンテキスト・プロトコルは、エージェント間に構造化された通信路を確立することでこれに対処します。³ コンテキスト共有、エラー伝播、状態同期について明示的な取り決めを定めることで、AssistantBenchで28.3%の正答率を達成しました。KrishnanのUnified Agent Communication Protocolは、これをさらに拡張し、エージェント間にゼロトラストの安全境界を設けています。⁴

私自身は、10エージェントによる熟議で連携の破綻に遭遇しました。3人のレビュアーが同じコード変更を評価する構成です。4巡目に入る頃には、コードの「現在の版」が何であるかについて、エージェント間で認識が食い違っていました。各エージェントのコンテキストが、それぞれ異なるスナップショットを抱えていたのです。レビューが互いに矛盾したのは、意見が割れたからではありません。そもそも別のコードを見ていたからでした。

検知方法： マルチエージェントの作業では、各エージェントが前提としている状態を突き合わせてください。同じ成果物について異なる版を参照しているなら、連携は破綻しています。

コンテキストウィンドウを広げても解決しない理由

マルチターン劣化に対する直感的な答えは「モデルにもっとトークンを与えればいい」でしょう。MSR/Salesforceの研究は、巧みな実験設計でこの直感を否定しています。

彼らが試したのは「Concat」条件です。マルチターンの会話全体を、連結した1つのプロンプトとして提示する。この条件では、シングルターン性能の95.1%に達しました。¹ コンテキスト長はマルチターン条件と同一。情報量も同一。違いは対話の構造だけです——1ターンか、多ターンか。

39%の劣化は、コンテキスト長の問題ではありません。コンテキストウィンドウを20万トークンから40万トークンへ倍増させても劣化は消えないでしょう。劣化はターンの境界そのものから生じるのであって、場所が足りなくなることから生じるのではないからです。

Concatの知見は、私の実運用データとも一致します。Claudeはおよそ20万トークンのコンテキストで動作します。コンテキストウィンドウ管理の測定では、最長の連続作業（3時間以上、ツール多用）で圧縮が走る前におよそ18万トークンを消費していました。しかし品質は、ウィンドウが埋まるずっと手前で劣化します。90分の崖が訪れるのは、限界地点ではなく、コンテキスト使用率がおよそ60〜70%のあたりです。そこから生じる認知的負債は、開発者が検証できる速度を超えてエージェントがコードを吐き出すことで、雪だるま式に膨らんでいきます。これは複利的に効いてくるコンテキストと同じ問題を、別の尺度で見たものです。各ターンが加える情報は、それ以前の情報と非線形に絡み合っていきます。

Duらの認知的意思決定ルーティングは、問題の立て方そのものを変えます。争点はモデルが何トークン保持できるかではなく、そのトークン全体にわたって推論資源をいかに効率よく配分するかだ、というわけです。² 単純な判断は速い推論へ、複雑な判断は熟慮的な推論へと振り分けることで、計算コストを34%削減しつつ、一貫性を23%改善しました。

まっさらなコンテキストという解（とその代償）

Ralphループは、メカニズム1（圧縮）を解決し、メカニズム2（一貫性）を部分的に解決します。どちらも表面化するほど長く会話を続けない、という単純な理屈です。反復ごとに20万トークンのコンテキストをまるごと持ったClaudeのインスタンスが新しく立ち上がります。状態は対話上の記憶ではなく、ファイルシステムを通じて引き継がれます。

# Simplified Ralph loop iteration (from jiro-artisan.sh)
while [ "$stories_remaining" -gt 0 ]; do
  # Orient: inject current state from filesystem
  state=$(cat jiro.state.json)
  progress=$(cat jiro.progress.json)
  git_state=$(git diff --stat HEAD)

  # Spawn fresh context with injected state
  claude --print \
    "State: $state" \
    "Progress: $progress" \
    "Git: $git_state" \
    "Task: implement next story from prd.json"

  # Update filesystem state from agent output
  update_state_from_output
done

反復ごとに、コンテキスト予算を満額使えます。前のターンから持ち越された圧縮の痕跡もなければ、以前の推論から漏れ出た断片もありません。ファイルシステムはエージェントの外部記憶として働きます。jiro.state.jsonが現在のストーリーを追い、jiro.progress.jsonが反復をまたいだ完了作業を記録し、git diffが実際に何が変わったかという動かしがたい事実を提供します。

Zhang、Kraska、Khattabの再帰的言語モデル（Recursive Language Models）は、これを補う別の道を選びます。新しいインスタンスを立てる代わりに、モデルがコンテキストをPythonのREPL環境へ退避させ、トークン空間ではなくコードの上で推論するのです。⁵ RLM-Qwen3-8Bは、長いプロンプトを内部記憶ではなく外部のデータ構造として扱うことで、長文コンテキストのタスクでベースラインを28.3%上回りました。Ralphループが状態をファイルへ外部化するのに対し、RLMはコードへ外部化する。どちらも同じ圧縮の問題を、異なる仕組みで解いています。

Nandaらの「Wink」は、すでに劣化が進行してしまった場合に何をすべきかを扱っています。⁶ 実運用のエージェント軌跡1万件超を分析したところ、仕様からの逸脱、同じ手順の反復、ツール呼び出しの失敗といった不適切な振る舞いが、全体のおよそ30%で発生していました。Winkはエージェントの軌跡を観察し、狙いを定めた軌道修正を行うことで、単発の介入で済む不適切な振る舞いの90%を解消します。検知はリアルタイムです。失敗がコードベース全体に波及するのを待つのではなく、劣化のパターンが立ち上がったその場で捉えます。

代償

まっさらなコンテキストからの反復は、ただではありません。代償は3つあります。

1. 状況把握のオーバーヘッド。 反復のたびに、前回すでに理解していた状態を読み直すためにトークンを費やします。私の測定では、各反復のトークン予算の15〜20%が状況把握（orient）の工程——状態ファイルの読み込み、直近のgit履歴の確認、作業を続けられるだけのコンテキストの再構築——に消えていました。20万トークンの反復は、実質16〜17万トークン程度から始まる計算になります。

2. 暗黙知の喪失。 対話上のコンテキストには、ファイルシステムの状態では捉えきれない暗黙知が乗っています。設計判断の背後にある理屈、検討して退けた選択肢、なぜ方式Bではなく方式Aを選んだのかという機微。状況把握の工程が注入できるのは事実（何が変わり、次に何をするか）だけです。理由は反復と反復の間に蒸発します。

3. 連携のコスト。 複数のRalphループを同時に走らせる場合（ストーリーの並行実装など）、各ループは独立した状態を持ちます。ループ間の調整には、明示的なマージ処理と競合解決が必要です。1本の長い会話なら暗黙のうちに処理していた部分を、自分で書かなければなりません。

損得の勘定ははっきりしています。60分未満で終わる作業なら、1本の会話のほうが効率的です。90分を超えるなら、状況把握のオーバーヘッドを差し引いても、まっさらなコンテキストの方式が高品質な出力を生みます。分岐点はタスクの複雑さ次第です。ファイル横断の状態が多いほど分岐点は手前に、単一ファイルで完結する作業ほど後ろにずれます。

劣化が牙をむく前に測る

マルチターン劣化を検知するのに、本番での失敗を待つ必要はありません。簡単な順に3つの手法を挙げます。

手法1：コンテキスト逼迫の監視

コンテキスト使用率をリアルタイムで追いかけます。私のcontext-pressure.shというフックは、ツール呼び出しのたびに走り、使用率が60%を超えると警告を出します。

# Simplified context pressure check
context_used=$(wc -c < "$CONVERSATION_LOG" | awk '{print int($1/4)}')
context_max=200000
utilization=$(( context_used * 100 / context_max ))

if [ "$utilization" -gt 60 ]; then
  echo "[WARN] Context at ${utilization}% — quality degradation likely"
fi

if [ "$utilization" -gt 80 ]; then
  echo "[CRITICAL] Context at ${utilization}% — start new session"
fi

手法2：横断参照の追跡

エージェントが1回の出力で参照する異なるファイルの数を監視します。数が減少傾向にあれば、圧縮による損失の兆候です。

# Track file reference diversity in recent commits
for commit in $(git log --oneline -5 --format="%H"); do
  files=$(git diff-tree --no-commit-id --name-only -r "$commit" | wc -l)
  echo "$commit: $files files touched"
done

手法3：矛盾の検出

エージェントがアーキテクチャについて述べた内容を、時間をまたいで比較します。20分の時点で「モジュールAはモジュールBに依存する」と言い、70分の時点で「モジュールAに外部依存はない」と言うなら、一貫性は劣化しています。自動化するなら、序盤と終盤の出力からエージェントのEXPLAIN文（あるいは設計コメント）を取り出して差分を取るとよいでしょう。

マルチターン耐性のための手順

3つの段階があり、それぞれ異なるメカニズムに対応します。まず第1段階から始め、必要に応じて層を重ねてください。

第1段階：状態のチェックポイント

30分ごとに、エージェントが現時点で把握しているアーキテクチャをファイルへ書き出します。会話全体ではありません。どのモジュールが存在し、どうつながり、どんな制約が効いているのかという、構造の状態です。

# Pre-compaction checkpoint (runs before Claude compresses context)
mkdir -p .claude/checkpoints
cat > ".claude/checkpoints/$(date +%s).md" << 'CHECKPOINT'
## Architectural State
- Module graph: [current understanding]
- Active constraints: [list]
- Design decisions made this session: [list with reasoning]
CHECKPOINT

エージェントの振る舞いが劣化してきたら、劣化したコンテキストのまま続けるのではなく、チェックポイントから復元してください。

第2段階：まっさらなコンテキストでの反復

60分を超える作業では、Ralphループの方式へ切り替えます。鍵になるのは状況把握の工程です。会話履歴を丸ごと読み直さなくても新しいコンテキストが生産的に続けられるだけの状態を、過不足なく注入します。

状況把握の工程に必要な状態は次のとおりです。

1. 現在のタスクと受け入れ基準
2. 前の反復で変更したファイル（git diffから取得）
3. アーキテクチャ上の判断と、その理由
4. 既知の制約と失敗のしかた

第3段階：エージェント間の連携の取り決め

マルチエージェントの作業では、すべてのエージェントが読み書きする共有の状態文書を用意します。この文書が動かしがたい事実の拠り所となり、熟議レビューで私が目にしたような認識のズレを防ぎます。

{
  "version": 7,
  "last_updated": "2026-02-22T14:30:00Z",
  "active_files": ["engine.py", "calculator.py", "aggregator.py"],
  "constraints": [
    "No circular imports between modules",
    "All public functions require type annotations"
  ],
  "decisions": [
    {"decision": "Use RRF for vote aggregation", "reasoning": "Handles rank-only data", "turn": 3}
  ]
}

各エージェントは自分の番の初めにこの文書を読み、終わりに更新します。衝突が起きたら、黙って認識がずれていくのではなく、連携をいったん止める合図とします。優れたエージェントは、こうした仕組みを気づかせないまま動かすものです。見えないエージェントで論じたとおり、目指すべきは開発者に意識させずに働くインフラなのです。

押さえておきたいこと

• マルチターン劣化は構造的な問題であり、コンテキスト長の問題ではありません。 MSR/Salesforceの研究は、コンテキスト長を一定に保っても39%の劣化が起きることを示しました。崩壊を招くのはトークンの上限ではなく、ターンの境界です。¹
• 独立した3つのメカニズムには、3つの異なる介入が要ります。 圧縮による損失には状態のチェックポイント。一貫性の喪失にはまっさらなコンテキストでの反復。連携の破綻には状態共有の取り決めが必要です。
• 90分の崖は実在し、測定できます。 コンテキスト使用率、横断参照の多様性、アーキテクチャ上の矛盾を追えば、本番で失敗が表面化する前に劣化を捉えられます。
• まっさらなコンテキストでの反復は有効ですが、15〜20%のオーバーヘッドを伴います。 Ralphループは、状況把握のオーバーヘッドと引き換えに、反復ごとの満額のコンテキスト予算を手に入れる取引です。60〜90分を超えると、この取引が有利に転じます。
• 推論資源は一律に配分するより、適応的に振り分けるほうが優れています。 Duらの認知的意思決定ルーティングは、推論の深さをタスクの要求に合わせることで、コストを34%削減し、一貫性を23%改善しました。²

よくある質問

参考文献