← すべての記事

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

3分で読めます
From the guide: Claude Code Comprehensive Guide

審議システムの構築を始めて90分後、エージェントは30分前に議論していたアーキテクチャへの参照を止めました。セッションログを確認すると、Claudeが新しいツール出力のためにモジュール依存関係グラフを圧縮して破棄していたのです。エージェントはコードを書き続けていましたが、最初の1時間で確立したモジュール間の契約を反映していませんでした。テストは通りました。しかし、統合は失敗しました。エージェントは自らの設計を忘れていたのです。

この障害のデバッグに丸一日を費やしました。なぜそうなったのか、今では研究が説明してくれます。

**AIエージェントのメモリはマルチターン会話で39%劣化します。** 原因となる3つのメカニズムは、コンテキスト圧縮による初期状態の破棄、ターンをまたいだ推論の一貫性の断片化、そして共有された真実の情報源なしでのマルチエージェント連携の崩壊です。コンテキストウィンドウを拡大しても解決しません。ファイルシステムに永続化した状態を用いたフレッシュコンテキスト反復が最も効果的な緩和策ですが、15〜20%のオリエントオーバーヘッドが発生します。

TL;DR

Microsoft ResearchとSalesforceが15のLLMを200,000以上のシミュレーション会話でテストした結果、シングルターンからマルチターンへの移行で平均39%のパフォーマンス低下が確認されました。1 劣化はわずか2ターンで始まります。崩壊を引き起こす3つの独立したメカニズムがあります。コンテキスト圧縮が重要な状態を破棄し、推論の一貫性がトークン予算の縮小とともに断片化し、共有された真実の情報源なしにエージェント間の連携が崩壊します。コンテキストウィンドウの拡大ではいずれも解決しません。Ralphループパターン（反復ごとにフレッシュコンテキスト＋ファイルシステム状態）は圧縮損失を回避しますが、独自のコストが伴います。以下では、研究内容、3つのメカニズム、今日から実行できる検出方法、そしてマルチターンレジリエンスのためのプロトコルを解説します。

90分の崖

コンテキスト・イズ・アーキテクチャの記事では、650ファイルにまたがる7層コンテキストシステムを文書化しました。このシステムの構築には、エージェントが複雑なアーキテクチャ状態を保持する必要がある長時間のコーディングセッションが求められました。モジュール境界、依存関係チェーン、フック実行順序、ファイル間の契約などです。

2026年1月と2月に30回のRalphループ反復でセッション品質を測定しました。データは一貫したパターンを示しています：

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

メカニズム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つの要素に分解されることを発見しました。わずかな適性の低下と、著しい信頼性の低下です。1 適性はモデルが正しい回答を生成できるかどうかを測定します。信頼性はそれを一貫して行うかどうかを測定します。

シングルターンモードでは、6つの生成タスクで約90%の平均パフォーマンスを達成しました。マルチターンモードでは約65%に低下し、25ポイントの絶対的な低下となりました。重要な発見は次のとおりです：「LLMがマルチターン会話で誤った方向に進むと、迷子になり、回復しません。」1

推論の一貫性の喪失は、エージェントが自身の以前の決定と矛盾する形で現れます。システムがコンテキストを圧縮破棄したからではなく（メカニズム1）、モデルの推論チェーンがターンをまたいで断片化したからです。各ターンの推論は局所的には妥当ですが、全体的には矛盾しています。

Duらの認知的意思決定ルーティングに関する研究は、このメカニズムに直接対処しています。2 カーネマンの二重過程理論（高速な直感的応答と低速な熟慮的推論）に着想を得た彼らのシステムは、タスクの要求に応じて推論の深さを適応させます。すべてのエージェントターンが同じ推論の深さを必要とするわけではなく、一律の深さを適用すると些細なステップに予算を浪費し、重要な決定への投資が不足するという洞察です。

検出方法： セッションの初期と後期の出力間の矛盾を探します。エージェントが15分目にアプローチAを提唱し、60分目に変更を認めずにアプローチBを提唱している場合、一貫性が劣化しています。

メカニズム3：連携の失敗

マルチエージェントシステムは、マルチターンの劣化に連携の失敗を重ね合わせます。2つ以上のエージェントがタスクで協力する場合、各エージェントのコンテキストは独立して劣化します。共有された制約を忘れたエージェントは、その制約を中心に連携することができません。

Bhardwajらのエージェントコンテキストプロトコルは、エージェント間の構造化された通信チャネルを確立することでこの問題に対処しています。3 彼らのフレームワークは、コンテキスト共有、エラー伝播、状態同期のための明示的なプロトコルを定義することで、AssistantBenchで28.3%の精度を達成しました。Krishnanのユニファイドエージェント通信プロトコルは、エージェント間のゼロトラストセキュリティ境界でこれを拡張しています。4

10エージェントの審議中に連携の失敗に遭遇しました。3人のレビュアーが同じコード変更を評価する場面で、4回目のレビューラウンドまでに、エージェントはコードの「現在のバージョン」が何であるかについて食い違っていました。各エージェントのコンテキストが異なるスナップショットを保持していたのです。レビューが矛盾したのは意見が異なったからではなく、異なるコードをレビューしていたからでした。

検出方法： マルチエージェントワークフローでは、各エージェントが保持する状態の前提を比較します。エージェントが同じアーティファクトの異なるバージョンを参照している場合、連携は失敗しています。

コンテキストウィンドウの拡大では解決しない理由

マルチターン劣化に対する直感的な対応は「モデルにより多くのトークンを与える」ことです。MSR/Salesforceの研究は、巧みな実験デザインでこの直感を否定しました。

彼らは「Concat」条件をテストしました。マルチターン会話全体を単一の連結プロンプトとして提示するものです。Concat条件はシングルターンパフォーマンスの95.1%を達成しました。1 コンテキストの長さはマルチターン条件と同一で、情報の内容も同一でした。唯一の違いはインタラクションの構造です：1ターン対複数ターン。

39%の劣化はコンテキスト長の問題ではありません。コンテキストウィンドウを200Kから400Kトークンに倍増しても劣化は解消されません。劣化はスペースの不足ではなく、ターンの境界そのものから生じているからです。

Concatの発見は本番データと一致します。Claudeは約200,000トークンのコンテキストで動作します。コンテキストウィンドウ管理の測定では、最長のシングルセッション実行（3時間以上、大量のツール使用）がコンパクション発動前に約180,000トークンを消費することが示されました。しかし、品質はウィンドウが埋まるよりもはるかに前に劣化します。90分の崖はコンテキスト使用率が約60〜70%の時点で発生し、境界ではありません。結果として生じる認知的負債は、エージェントが開発者の検証速度を超えてコードを生成するにつれて複利的に蓄積されます。これは異なるスケールでの同じ複合コンテキスト問題です。各ターンが追加する情報は、以前の情報と非線形に相互作用します。

Duらの認知的意思決定ルーティングは問題を再定義しています。問題はモデルが保持できるトークン数ではなく、それらのトークンに対してモデルがいかに効率的に推論リソースを配分するかです。2 彼らのシステムは、単純な決定を高速推論に、複雑な決定を熟慮的推論にルーティングすることで、計算コストを34%削減し、一貫性を23%向上させました。

フレッシュコンテキストによる解決策（とそのコスト）

Ralphループは、会話がメカニズム1（圧縮）やメカニズム2（一貫性）が発現するほど長く続くことを防ぐことで、両方を解決します。各反復は200Kトークンのフルコンテキストを持つ新しい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の再帰的言語モデルは補完的なアプローチを取っています。新しいインスタンスを生成する代わりに、モデルがコンテキストをPython REPL環境にオフロードし、トークン空間ではなくコード内でコンテキストを推論します。5 RLM-Qwen3-8Bは、長いプロンプトを内部メモリではなく外部データ構造として扱うことで、長文コンテキストタスクでベースラインを28.3%上回りました。Ralphループがファイルへ状態を外部化するのに対し、RLMはコードへ状態を外部化します。どちらのパターンも、異なるメカニズムで同じ圧縮問題を解決しています。

Nandaらのwinkシステムは、劣化がすでに進行している場合の対処法を提示しています。6 10,000以上の実世界のエージェント軌跡を分析した結果、仕様のドリフト、繰り返しループ、ツール呼び出しの失敗などの誤動作が全セッションの約30%で発生していることを発見しました。Winkはエージェントの軌跡を観察し、的を絞った軌道修正を行い、単一介入の誤動作の90%を解決します。検出はリアルタイムで行われ、失敗がコードベース全体に波及するのを待つのではなく、劣化パターンが発生した時点で識別します。

コスト

フレッシュコンテキスト反復は無料ではありません。3つのコストがあります：

1. オリエントオーバーヘッド。 各反復は、前の反復がすでに理解していた状態を再読み込みするためにトークンを消費します。測定では、各反復のトークン予算の15〜20%がオリエントステップに費やされます。状態ファイルの読み込み、最近のgit履歴のスキャン、作業を続行するために十分なコンテキストの再構築です。200Kトークンの反復は、約160,000〜170,000トークンの実質的な容量で始まります。

2. 暗黙知の喪失。 会話コンテキストには、ファイルシステムの状態では捉えられない暗黙知が含まれています。設計上の選択の背後にある理由、検討して却下した代替案、アプローチAがアプローチBよりも選ばれた理由のニュアンスなどです。オリエントステップはファクト（何が変わったか、次に何をするか）を注入しますが、推論（なぜ）は反復間で消失します。

3. 連携コスト。 複数のRalphループが並行して実行される場合（並列ストーリー実装）、各ループは独立した状態を維持します。ループ間の連携には、単一の長いセッションが暗黙的に処理する明示的なマージロジックと競合解決が必要になります。

コスト対効果の計算は明確です。60分未満のセッションでは、単一の会話の方が効率的です。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：クロスリファレンス追跡

エージェントが出力ごとに参照する異なるファイル数を監視します。減少傾向は圧縮損失のシグナルです：

# 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分ごとに状態をファイルシステムにチェックポイント 低：5分のセットアップ
2 一貫性 60〜90分後にフレッシュコンテキスト反復 中：状態のシリアライズが必要
3 連携 エージェント間の明示的な状態同期 高：プロトコル設計が必要

ティア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}
  ]
}

各エージェントがターン開始時にこのドキュメントを読み、終了時に更新します。競合が発生した場合、暗黙の乖離ではなく連携の一時停止がトリガーされます。最良のエージェントはこれを目に見えない形で運用します。The Invisible Agentで探求したように、目標は開発者が気づかずに機能するインフラストラクチャです。

重要なポイント

  • マルチターンの劣化は構造的な問題であり、コンテキスト長の問題ではありません。 MSR/Salesforceの研究は、コンテキスト長が一定であっても39%の劣化を示しました。トークンの限界ではなく、ターンの境界が崩壊を引き起こしています。1
  • 3つの独立したメカニズムには3つの異なる介入が必要です。 圧縮損失には状態チェックポイントが、一貫性の喪失にはフレッシュコンテキスト反復が、連携の失敗には共有状態プロトコルが必要です。
  • 90分の崖は現実であり、測定可能です。 コンテキスト使用率、クロスリファレンスの多様性、アーキテクチャの矛盾を追跡することで、本番障害が表面化する前に劣化を検出できます。
  • フレッシュコンテキスト反復は機能しますが、15〜20%のオーバーヘッドがかかります。 Ralphループパターンは、オリエントオーバーヘッドと引き換えに反復ごとのフルコンテキスト予算を得ます。60〜90分を超えるとフレッシュコンテキストが有利になります。
  • 適応的な推論配分は一律の深さを上回ります。 Duらの認知的意思決定ルーティングは、推論の深さをタスクの要求に合わせることで、コストを34%削減し、一貫性を23%向上させました。2

FAQ

なぜLLMはマルチターン会話で劣化するのですか？

LLMがマルチターン会話で劣化する原因は、3つの独立したメカニズムにあります。コンテキスト圧縮がトークン予算内に新しいコンテンツを収めるために以前の情報を破棄します。推論の一貫性がモデルの思考チェーンが複数のターンにまたがることで断片化し、局所的には妥当でも全体的には矛盾する出力を生成します。各エージェントのコンテキストが独立して劣化することで、複数エージェント間の連携が失敗します。Microsoft ResearchとSalesforceは、15のLLMと200,000以上の会話で平均39%のパフォーマンス低下を記録しており、劣化はわずか2ターンで始まることが確認されています。

コンテキストウィンドウを拡大すればマルチターンの劣化は解決しますか？

コンテキストウィンドウの拡大ではマルチターンの劣化は解決しません。MSR/Salesforceの研究では、会話全体を単一プロンプトとして提示する「Concat」条件をテストし、シングルターンパフォーマンスの95.1%を達成しました。同じ内容を複数のターンに分割すると約65%に低下します。劣化はコンテキスト長の制限ではなく、ターンの境界そのものから生じています。コンテキストウィンドウを倍増しても、39%のパフォーマンスギャップは解消されません。

AIエージェントのフレッシュコンテキスト反復パターンとは何ですか？

フレッシュコンテキスト反復は、単一の長い会話を続けるのではなく、作業サイクルごとに新しいAIインスタンスを生成するパターンです。状態は会話メモリではなく、外部ストレージ（ファイルシステム、データベース）を通じて永続化されます。各反復は現在の状態を読み取り、作業を行い、更新された状態を書き戻します。このパターンは、新しいインスタンスが外部状態を読み取って処理する「オリエント」ステップに15〜20%のオーバーヘッドがかかる代わりに、圧縮アーティファクトと一貫性の断片化を排除します。本番データでは、60〜90分を超えるタスクにおいてシングルセッションアプローチを上回ることが示されています。

マルチターン劣化を障害が発生する前に検出するには？

実践で機能する3つの検出方法があります。コンテキスト圧力モニタリングはトークン使用率を追跡し、60%を超えると（品質劣化の可能性あり）または80%を超えると（新しいセッションの開始推奨）警告を発します。クロスリファレンス追跡は、エージェントが出力ごとに参照する異なるファイル数を監視し、減少傾向は圧縮損失のシグナルとなります。矛盾検出は、エージェントのアーキテクチャに関する主張を時間経過とともに比較し、明示的な決定なしにモジュール依存関係の理解が変化している場合、一貫性が劣化したことを示します。

LLMのパフォーマンスが劣化し始めるまで何ターンかかりますか？

MSR/Salesforceが15のLLMと200,000以上の会話を対象にした研究によると、パフォーマンスの劣化はわずか2ターンで始まります。深刻度は会話の長さとともに増加し、実際の測定では継続的なエージェントインタラクションの約60〜90分で一貫した品質の崖が確認されています。ファイル間のアーキテクチャ状態を必要とするタスクは、単一ファイルの独立した作業よりも早く劣化します。重要な発見は、LLMがマルチターン会話で「誤った方向に進む」と自己修正せず、エラーがその後のターンを通じて複利的に蓄積されるということです。

参考文献

  1. Laban, Philippe, et al., “LLMs Get Lost In Multi-Turn Conversation,” arXiv:2505.06120, May 2025. arxiv.org. Microsoft Research and Salesforce Research. Tested 15 LLMs across 8 model families on 200,000+ simulated conversations. ↩↩↩↩↩↩

  2. Du, Y., et al., “Cognitive Decision Routing in Large Language Models: When to Think Fast, When to Think Slow,” arXiv:2508.16636, August 2025. arxiv.org. Achieved 34% reduction in computational costs with 23% improvement in consistency. ↩↩↩

  3. Bhardwaj, et al., “Agent Context Protocols Enhance Collective Inference,” arXiv:2505.14569, May 2025. arxiv.org. Introduces structured communication protocols for multi-agent coordination, achieving 28.3% accuracy on AssistantBench. ↩

  4. Krishnan, “Beyond Context Sharing: A Unified Agent Communication Protocol,” arXiv:2602.15055, February 2026. arxiv.org. Proposes standardized agent-to-agent orchestration with zero-trust security boundaries. ↩

  5. Zhang, Alex L., Tim Kraska, and Omar Khattab, “Recursive Language Models,” arXiv:2512.24601, December 2025. arxiv.org. MIT CSAIL. RLM-Qwen3-8B outperforms baseline by 28.3% on long-context tasks by offloading context to a Python REPL environment. ↩

  6. Nanda, Rahul, et al., “Wink: Recovering from Misbehaviors in Coding Agents,” arXiv:2602.17037, February 2026. arxiv.org. Misbehaviors occur in approximately 30% of all agent trajectories; Wink resolves 90% of single-intervention cases. ↩

  7. Author’s session quality measurements across 30 Ralph loop iterations, January-February 2026. Data collected from jiro.progress.json session logs and git diff --stat output per iteration. Orient overhead measured by token count of state injection vs. total iteration budget. ↩

  8. Author’s context-is-architecture system. Seven-layer hierarchy across 650 files documented in Context Engineering Is Architecture. ↩

  9. Author’s multi-agent deliberation system. 10-agent consensus with 3-reviewer autonomous code review documented in The Deliberation System. ↩

関連記事

Ralphループ：自律型AIエージェントを一晩中稼働させる方法

ストップフック、スポーンバジェット、ファイルシステムメモリを備えた自律エージェントシステムを構築しました。失敗から学んだことと、実際にコードをシップする仕組みを紹介します。

3 分で読める

あなたのエージェントは、あなたが読むより速くコードを書く

今週、5つの研究グループが同じ問題について発表しました。AIエージェントは開発者が理解できる速度を超えてコードを生成しています。負債はあなたの頭の中にあります。

3 分で読める

リポジトリに自身の信頼性を投票させてはならない

37日間で2件発生したClaude Codeの信頼ダイアログバイパスCVEは、ロード順序の欠陥を露呈させました。これを修正する不変条件は1つだけです。パスが信頼されるまで、ワークスペースのバイトを一切解釈しないこと。

2 分で読める