何が起きたか
チャットを新規に開かず延々と会話を続けると、AIラボの各サービスは会話履歴を要約して文脈枠を空けます。これが「コンパクション（compaction）」と呼ばれる文脈圧縮です。要約である以上、情報は必ず落ちます。Penn Stateの研究者は、その「何が落ちるのか」「被害はどれほど深刻か」を体系的に測りました。
最も落ちやすかったのは、研究者が「セッション制約（session constraints）」と呼ぶものです。「変更する前に必ず私に確認して」「返答で私の名前を使わないで」といった、そのセッション中のAIの振る舞いを縛るルールを指します。平均でわずか17%しか圧縮を生き延びません。
なぜ消えるのか — 設計思想の必然
これは実装バグではなく、設計の帰結です。圧縮システムは「タスクの継続性」を守るように作られています。ゴールは何か、いまどの状態か、次に何をするか。この3点を残すことが最優先で、ユーザーが横から付けた条件はタスクそのものではないため、優先度の低い付随情報として切り捨てられます。
さらに悪いのは、セッション制約が「恒久的なシステム命令」でもないことです。システムプロンプトに書かれたルールは残る。タスクの本筋も残る。その中間にある「今日この会話だけのルール」だけが構造的に脆い。ユーザーが最も強く意識して打ち込んだ一文が、最も消えやすい、という逆説がここにあります。
品質問題ではなく、セキュリティ問題
研究者はこの損失を、品質とセキュリティの両方の問題として位置づけています。制約が消えたエージェントは、承認されていないツール呼び出しを実行し、伏せておくべき情報を開示し、ユーザーが明示的に求めた検証ステップを飛ばします。
論文が挙げる例は端的です。「私の承認なしにメールを送らないで」と伝えたユーザーに対し、エージェントは圧縮後まさにそれをやる。添付図では、(A)ユーザーが「行動前に確認して」と指示し、(B)コンパクションがそのルールを落とし、(C)エージェントが確認なしにカレンダーの予定を書き換える、という3コマが示されています。
数字が示す深刻さ
評価には研究チームが新たに作ったスイート「COMPINT」が使われました。結果は率直に言って厳しいものです。
圧縮せず完全な文脈と制約を保持した状態でも、ルール遵守率は59〜71%にとどまります。つまり圧縮以前に、モデルはユーザーの指示を3〜4割は守っていない。そのうえで圧縮をかけると、多くのコンパクタで遵守率は急落し、「そもそも制約を与えなかった場合」とほとんど変わらない水準まで落ちます。制約を書いた意味が、統計的に消滅するということです。
テストされた圧縮設定の大半は、圧縮なしのベースラインより成績が悪い。一部シナリオでGPT-5.4-miniがベースラインを上回るのが例外的な明るい材料です。「ユーザー制約を保持せよ」と明示的に設計したプロンプトを使っても、保持率は40%を下回りました。プロンプトの工夫では埋まらない溝がある、という結論です。
処方箋は「小さな別モジュール」
提案された解決策は、主圧縮システムを作り替えるのではなく、その横に小さなモジュールを併走させるものです。Qwen3.5-9B（90億パラメータ）という小型モデルを使い、ユーザー入力を毎回読んでセッション制約を検出し、別リストとして蓄積する。そして後で文脈が要約されるとき、そのリストを要約に追記する。これだけです。
学習は不要、圧縮システム側の改修も不要。結果、保持率は3シナリオすべてで90%超に達しました。エージェント軌跡95.6%、長期リサーチタスク95.1%、マルチターン対話90.3%です。COMPINTと抽出モジュールはGitHubで公開されています。
点をつなぐと何が見えるか
重要なのは、この構造が「文脈管理をちゃんとやれる人」には見えにくいことです。会話をこまめに分割し、指示を都度書き直す運用ができていれば、そもそも圧縮が走らない。一方で、ひとつのチャット窓に何もかも放り込む一般的な使い方をしている人ほど、圧縮が頻発し、自分の出したルールが静かに剥がれ落ちる。リテラシーの高い層が問題を体感しにくく、体感しない層が最も被害を受ける、という非対称がここにあります。
出典: THE DECODER（2026年8月18日）
💼 事業会社視点：これは自社にどう効くか
AIエージェントを業務に組み込んでいる事業会社にとって、これは「ガードレールの置き場所」の設計問題です。
日本企業の多くは、AI活用の安全策を「利用者への注意喚起」で担保しています。「重要な操作の前は確認を取らせること」といった社内ガイドラインを配り、あとは現場の入力任せ。この研究は、その運用が平均17%しか機能しないことを示しました。ガイドラインを守った真面目な社員ほど、チャット中の一文を信じて放置し、圧縮後に裏切られます。
ECや業務SaaSでエージェントに実行権限を渡している事業者は特に急ぎの点検が要ります。メール送信、在庫更新、予約変更、返金処理——「ユーザーが会話中に止めた」だけの制御は、長時間セッションで実質無効と考えるべきです。制約は会話ではなく、システムプロンプト・ツール定義の権限設計・実行前の確定的な承認フローに移す。これが本質的な打ち手です。
受託開発・SIerにとっては商機と責任の両面があります。顧客に納めたAIエージェントが「確認なしに実行した」場合、責任の所在は仕様書に書かれているか。今後のRFPでは「セッション制約の永続化方式」が問われる項目になります。逆に、Qwen3.5-9B規模の抽出モジュールを併走させる構成は9Bと小さく、オンプレ／VPC内で回せる現実的な受注メニューになり得ます。
経営者が今週やるべきことは一つ。自社のAI業務フローで「人間の承認」がコードで担保されているか、チャットの言葉で担保されているかを棚卸しすることです。後者なら、それは統計的に守られていません。