AIエージェントに長時間の作業を任せていると、序盤に伝えた注意事項がいつの間にか無視され始めたと感じたことがある開発者は少なくないはずだ。Claude Codeを使う日本語圏のエンジニアの間では、この現象への対処法が複数のブログ記事にまとめられるほど実務で顕在化している。だが体感でしか語られてこなかったこの問題に、ペンシルベニア州立大学の研究チームが数値を突きつけた。長い会話やタスクを要約する「コンテキスト圧縮」処理を経ると、ユーザーが課した制約は平均で83%が消える。その対象には行動の可否や出力形式の指定なども含まれ、「確認するまで削除しないで」といった安全に関わる指示も例外ではない。
「確認するまで消さないで」が平均83%消える実験結果
米ペンシルベニア州立大学のZhiqi Wang氏、Yichi Zhang氏、Dongwon Lee氏、Yuchen Yang氏は、論文「Lost in Compaction: Evaluating Side-Constraint Loss under Context Compaction」(arXiv:2608.11242、2026年7月31日提出)を発表した。the-decoder.comが2026年8月18日付でこの論文を報じている。論文が提唱する「Session Constraints(SC、セッション制約)」とは、会話やタスクが終わるまで維持されるべきユーザーの指示を指す。「確認するまでメールを削除しないで」といった一文が典型例だ。
研究チームは3つのシナリオでAIの制約保持能力を測る評価スイート「COMPINT」を構築した。複数ターンの対話を再現するWildChat、エージェントの行動履歴を再現するHermes Agent、長期の調査タスクを再現するOpenResearcherだ。圧縮処理を挟まない状態でのSC遵守率はシナリオごとに59.2%から70.7%にとどまり、圧縮を経ていない時点でもユーザー指示の徹底には限界がある。そこにコンテキスト圧縮を挟むと、SCの生存率は平均17%まで落ち込んだ。裏を返せば、圧縮のたびにユーザーが課した制約の83%が消えている。
研究チームは同時に、Qwen3.5-9Bをベースにした「SC-aware extractor」というプラグイン型の対策手法も提案している。これをコンパクタに組み込むと、保持率はHermes Agentで95.6%、OpenResearcherで95.1%、WildChatで90.3%まで回復した。今回評価対象になった既存の圧縮システムは、この90%超えを支える仕組みそのものを備えていなかった。
要約エンジンは「続きが書けるか」しか見ていない
コンテキスト圧縮は、あふれそうになった会話履歴を要約し、モデルがタスクを続けられる分量まで圧縮する処理だ。要約エンジンが最適化しているのは「次のターンでタスクを続行できるか」であり、直近で参照されていない過去の発言は不要な情報として圧縮対象になりやすい。ユーザーが冒頭で一度だけ発した「確認するまで削除しないで」という制約は、以降のターンで明示的に繰り返されない限り、要約エンジンの目には使われなくなった過去の指示として映る。タスクの継続に必要な情報と、常時維持すべき制約は、デフォルトの要約エンジンにとって区別されていない。
この失敗のパターンに近い現象は、日本語圏のClaude Codeユーザーの間でも報告されている。Zennに掲載された記事は、プロジェクトルート直下のCLAUDE.mdに書いたルール(パス指定のないもの)は圧縮後も自動的に再読み込みされ消えないとしつつ、会話履歴の中で伝えた細かい指示は要約でパラフレーズされ、GitHub Issueで報告された数値として遵守率が60〜70%程度まで下がる「見えない劣化」が起きると伝えている。サブディレクトリ配下のCLAUDE.mdや特定パスにひも付くルールは、対象ファイルが再び読まれるまで自動再読込の対象にならない。この数値と、今回の論文が示した平均17%という生存率は、測定対象も方法も異なるため単純比較はできないが、圧縮処理がユーザー指示の遵守を静かに損なうという同じ方向の問題を指し示している。
圧縮処理に入る前に、対話やタスク履歴からSession Constraintに該当する文をあらかじめ抽出し、要約とは別枠で維持する設計が、SC-aware extractorが90%超の保持率を達成した理由だ。論文は、圧縮プロンプトに「制約と好み」のような専用欄を設けるだけでは不十分であることも示している。この欄を持つコンパクタ(pi-mono)は、モデル・データセットによって保持率が0%近くから36%程度まで大きく変動し、制約保持を明示的に指示したプロンプト(Anthropic SC-targeted)でもWildChatで最大37.6%にとどまった。論文は、どのコンパクタもいずれのSCカテゴリでも平均保持率36%を超えないと結論づけている。制約の存在を書いておくことと、要約とは切り離して構造的に抽出・保持することの間には、大きな性能差がある。
6件中5件が消える先にあるのは安全制約が破られるリスクだ
仮に長時間のコーディングエージェントに6件のセッション制約(不可逆操作の禁止、外部送信前の確認、特定ファイルへの書き込み制限など)を与えたとする。論文はSCを5カテゴリに分けて集計しており、比較的保持されやすい好み(Preference)系の制約でさえ、どのコンパクタも平均保持率36%を超えないと報告している。全カテゴリ平均の17%をそのまま適用すると、1回の圧縮を経た後に実際に守られ続ける制約は6件中およそ1件にとどまる、という概算になる。残り5件は、ユーザーが取り消した覚えがないまま、AIの記憶から消えている可能性がある。
長時間のエージェントタスクでは圧縮が1回では終わらない。仮に圧縮が2回連続で発生し、各回の生存確率が独立に17%だと仮定すると、2回の圧縮を経た後の生存率は0.17×0.17で約2.9%まで落ち込む計算になる。この掛け算はあくまで独立事象を仮定した概算であり、論文自体が複数回の圧縮を直接検証したわけではない。それでも、長時間運用ほど制約が失われるリスクが積み上がりやすい構造であることは、この単純な計算からも読み取れる。
同種の脆弱性を指摘した研究は今回が初めてではない。2026年6月に発表された「Governance Decay」論文(arXiv:2606.22528)は、7つのモデルファミリーを対象に、圧縮を経た後の安全制約の違反率が0%から30%、一部のモデルでは59%まで上昇すると報告している。測定指標はLost in Compactionの「制約の生存率」とGovernance Decayの「制約の違反率」で異なり、単純な数値比較はできない。
Governance Decay論文の提出は2026年6月21日、Lost in Compaction論文の提出は同年7月31日で、著者もチームも異なる。わずか40日ほどの間隔で独立した2つの研究グループが、圧縮後の制約管理という同じ構造的な弱点を別の角度から指摘した形になる。単発のバグではない。コンテキスト圧縮という設計思想そのものに根ざした課題だとみてよい。
文脈が長くなるほどAIの性能が不安定になる傾向は、圧縮を経ない場合でも観測されている。AI企業Chromaが2025年に発表した「Context Rot」研究は、Claude・GPT・Gemini・Qwenの計18モデルを対象に、平均約11万3000トークンのフル文脈と、関連部分のみ約300トークンに絞ったfocused入力を比較した。結果はどのモデルでもfocused入力の方が明確に高い性能を示し、入力が長くなるほど性能が低下する傾向が確認された。ただしChroma自身、その低下の仕方は一様でなく「しばしば意外な形で表れる」と注記している。圧縮の有無を問わず長い文脈の扱いには限界があり、要約によって情報を圧縮する現在のアプローチが、その限界への対症療法にとどまっている可能性を示唆する。
Anthropicの公式文書は「自動的な指示保持」を保証していない
AnthropicはAPI向けのコンテキスト圧縮機能をベータヘッダーcompact-2026-01-12として提供しており、Claude Opus 5やClaude Sonnet 5などが対象になっている。公式ドキュメントは、圧縮によって生成される要約の目的を「タスクの継続に有用な情報」を残すことだと説明しており、ユーザーが明示した指示や制約を自動的に保持することを保証する記述はない。一方で、圧縮後に処理を一時停止して直近のメッセージを明示的に保持し直すpause_after_compactionパラメータや、圧縮時の挙動そのものを書き換えるinstructionsパラメータも用意されている。指示の保持は「デフォルトで保証される機能」ではなく、「開発者が明示的に実装すれば実現できるオプション」という位置づけだ。
Lost in Compaction論文が実際に評価対象としたコンパクタは、gpt-oss-120bやGemma、Qwen3、GPT-5.4-miniなどのオープンモデルが中心で、Claudeそのものを圧縮システムとして直接テストしたわけではない。ただし論文はAnthropic公式文書が示すデフォルトの圧縮プロンプトを、gpt-oss-120bと組み合わせた実験条件の一つとして実際に採用・評価している。つまりAnthropicの「プロンプトの設計思想」は評価対象に含まれているが、Claude自身のモデル・APIとしての挙動は測定されていない。したがって「Claudeも17%しか制約を保持しない」と断定することはできない。確認できるのは、Anthropicの公式文書が自動的な指示保持を保証する言葉を持たない一方で、保持を実現する手段そのものは開発者向けに用意されているという事実だ。
開発者にできる防御策は、圧縮の外側に指示を退避させることだ
長時間のエージェントセッションで安全に関わる制約を課す場合、圧縮のタイミングをまたいで指示が生き残るとは前提しない方がよい。日本語圏のブログが提案してきた対策の実質は、圧縮のたびに指示をその場で送り直す一時しのぎというより、CLAUDE.mdのような圧縮後も再読み込みされる永続ファイルにルールを書く、Compact Instructionsで圧縮時の挙動そのものを指定する、Hooksで決定論的な処理を挟むといった、圧縮の影響が及ばない層に指示を退避させる設計にある。Anthropicの公式APIにも、圧縮後に一時停止して直近のメッセージを明示的に保持し直すpause_after_compactionパラメータや、圧縮プロンプト自体を書き換えるinstructionsパラメータが用意されている。
この問題が技術的に解決不能というわけではない。研究チームが示したSC-aware extractorは、圧縮前に制約を専用に抽出して隔離するだけで保持率が90%超まで回復することを実証した。圧縮システムを提供する各社がSession Constraintsに相当するカテゴリを設計に組み込みさえすれば、同種の改善は再現可能だということになる。課題は技術的な壁というより、ユーザーの指示を要約とは別枠で扱う設計をデフォルトの挙動として組み込むかという、各社に残された運用上の選択に近づいている。
この論文がAnthropicをはじめとする各社の圧縮機能に具体的な仕様変更を促すかどうかは、今後の公式文書の更新を追う必要がある。ただし現時点でも、Anthropicのパラメータや日本語圏のブログが提案する永続ファイル設計のように、指示を圧縮の外側へ退避させる手段そのものはすでに存在する。それを標準の挙動にするか、開発者ごとの個別対応に委ねたままにするかが、各社に残された選択だ。
