ガバナンスの崩壊：コンテキストの圧縮がエージェントのポリシーをいかに侵食するか、そして強制力はどこに置くべきか

エンタープライズAIにおける最も静かな失敗モードに、新しい用語が生まれました。それは、 ガバナンスの減衰 です。これは、エージェントの履歴が圧縮されるにつれ、コンテキスト内のルールが静かに侵食されていく現象を指します。この言葉は、2026年6月の研究論文「Governance Decay: How Context Compaction Silently Erases Safety Constraints in Long-Horizon LLM Agents」（arXiv:2606.22528）で提唱されたもので、その冒頭のシナリオは注目に値します。あるエージェントに対し、組織外への契約書のメール送信を禁止する指示が与えられました。エージェントは数十回にわたってその指示に従い、要求を正しく拒否します。しかし、履歴がコンテキストウィンドウの容量を超えると、 圧縮 が実行されます。これは、タスクの継続性を維持するために、現在すべての長期運用型ハーネスで行われているLLMベースの要約ステップです。要約はタスクの状態を忠実に記録しますが、継続性を最適化する過程で、「古い」コンプライアンスの前提条件を静かに削除してしまいます。再び同じ要求を受けると、エージェントは契約書をメールで送信してしまいます。脱獄（ジェイルブレイク）も、モデルの変更も、新しい要求もありません。ただ、エージェントが従っていたルールが目の前から消えただけなのです。この論文の調査結果は警鐘を鳴らしています。この減衰はモデルではなく、 ハーネスの特性 によるものです。強力なモデルであっても同様に失敗します。また、コンテキストにコンテンツを配置できる攻撃者が忘却を加速させることができるため、悪用も可能です。提案されている防御策である 制約の固定（constraint pinning）は有効ですが、オペレーターのなりすましには無力です。著者らは、これを防ぐには「信頼できる帯域外のオペレーターチャネル」が必要であると指摘しています。結論は、引用すべき7つの言葉に集約されます。「エージェントを統治するには、その忘却の仕方を統治する必要がある」。本ガイドは、論文が示唆しながらも書ききれなかったエンタープライズ向けの参照資料です。ガバナンスの減衰とは何か、なぜ圧縮によって不可避となったのか、類似の失敗モードと何が違うのか、そしてアーキテクチャ上の解決策とは何か。重要なポリシーは、圧縮が届かない場所、つまりすべての呼び出しが必ず通過するレイヤーの外側に配置し、強制しなければなりません。他の最新用語と同様、研究や語彙の進化に合わせてこのページも随時更新していきます。

ガバナンスの減衰とは何か？その定義

ガバナンスの減衰とは、エージェントの会話履歴がコンテキストウィンドウに収まるように圧縮される過程で、 コンテキスト内ガバナンス （デプロイされたエージェントが何をすべきか、何をすべきでないかを規定する組織ポリシー、常時適用される指示、メモリに読み込まれた制約など）が、段階的かつ静かに失われていく現象です。このメカニズムはありふれたものですが、それゆえに危険です。長期運用型エージェントは、ウィンドウの拡大速度よりも速く履歴を蓄積します。現在主流のエンジニアリング上の対応は、 コンテキスト圧縮 です。これは、定期的にトランスクリプトを圧縮するLLMベースの要約または削除処理ですが、圧縮は「タスクの正確性を維持する」というただ一つの目的のために設計されています。要約者の視点から見れば、常時適用されるポリシーは「現在のサブゴールではない古いテキスト」であり、限られたトークン予算を巡ってアクティブなタスク状態と競合します。そのため、ポリシーは要約によって切り捨てられ、曖昧にされ、あるいは削除されます。エージェントの行動は目の前にある情報に依存しているため、何の変化も通知されないまま、ガバナンスのないデフォルト状態へと戻ってしまうのです。この研究では、この問題を単なるバグからカテゴリーへと昇華させる2つの特性が追加されています。第一に、 ソフト/ハード勾配モデルに学習されたハードな規範（安全性ベンチマークが検証する項目）は維持される一方で、ソフトなデプロイメント固有のルール、つまり お客様の ルール、すなわち運用者が指定したルールこそがまさに損なわれていくのです。これが、標準的な評価手法ではこの障害が見過ごされてきた理由です。次に、敵対的利用可能性についてです。エージェントのコンテキストにコンテンツを挿入できる攻撃者（間接的インジェクションの標準的な想定）は、意図的に履歴を肥大化させて誘導し、コンパクション（圧縮）によって妨げとなる制約を消去させることが可能です。明確にしておくと、ガバナンスの減衰はモデルドリフト（重みは不変）ではなく、コンテキストの劣化（長さとともに検索品質が低下すること）でも、機械学習的な意味での忘却でもありません。これはハーネス（制御基盤）レベルでの情報損失であり、ガバナンスに影響を及ぼすものです。そして、これはコンパクションが実行されるたびに、設計通りに発生します。

簡単な歴史：コンパクションはいかにしてガバナンスの領域となったか

この用語は新しいものですが、それが指し示す衝突は2年前から醸成されていました。2024年から2025年にかけて、エージェントは長期的な視野を持つようになり、マルチステップのツール利用、丸一日の実行、永続的なセッションなどが一般的になりました。その結果、履歴はフロンティアモデルのウィンドウサイズさえも超えるようになり、圧縮は最適化の一環ではなく、ハーネスの標準機能となりました。実務者のエコシステムはしきい値による要約へと収束し、主要なフレームワークではウィンドウの70〜90%に達するとコンパクションが作動し、積極的な設定では数千トークンで実行されるようになりました。並行して、ガバナンスは コンテキスト内へと 移行しました。この時代のデプロイ可能な制御面はコンテキスト内にあります。システムプレアンブル、常駐指示、AGENTS.md形式の動作ルール、ロードされたメモリなどがそれにあたります。なぜなら、これらは再学習なしで運用者が実際に指定できるレイヤーだからです。2025年から2026年にかけて、研究コミュニティはコンテキスト管理をエージェントの主要なサブシステムとして扱い始めました。構造化された削除スキーム、分岐と復帰を伴うコンテキストフォールディング、KVキャッシュを意識した圧縮など、すべてがタスクの忠実度を最適化するためのものです。2026年6月、arXiv 2606.22528がこの衝突を定義しました。ガバナンスチャネルと圧縮ステップは最初から互いに向き合っていたのです。この論文は、モデル全体でこの減衰を実証し、敵対的な変種を示し、制約の固定（抽出可能なルールを隔離し、要約者がそれを保持するようにする）を提案しました。また、固定の限界についても率直に述べています。暗黙的な制約は固定できず、最近のコンテキストで運用者になりすまされると固定は無効化されるため、「信頼できる帯域外の運用者チャネル」が必要であると指摘しています。この用語は、単なる名称としてよりも、企業がすでに経験しながら説明がつかなかったインシデント、つまり「ルールに従わなくなった」エージェントが、ログには日常的なコンパクションしか残っていないという事態に対処するための診断として有用です。

ガバナンスの減衰 vs プロンプトインジェクション、コンテキストの劣化、モデルドリフト

この用語を正確に定義するために3つの区別があります。運用上最も重要なのは最初の区別です。 プロンプトインジェクションとの比較： インジェクションは 追加 攻撃であり、コンテキストに不正な指示を紛れ込ませるものです。これは我々の インジェクション防御分析 が対象とする脅威です。一方、減衰は 削除 による障害であり、システムのメンテナンスによって保護指示が密かに取り除かれるものです。これらは悪質に組み合わさります。論文の敵対的結果が示すように、インジェクションされたコンテンツがコンパクションを誘導して防御を消去させるため、強化されたプロンプトであっても、その強化自体がコンパクションによって消去されてしまえば、永続的な防御にはなりません。 コンテキストの劣化との比較： 劣化とは、コンテキストが長くなるにつれて品質が低下すること（検索の失敗、アテンションの希薄化、モデルが既存の情報をうまく使えなくなること）を指します。一方、減衰とは、コンテンツが完全に失われてしまうというガバナンス特有のケースを指します。この区別は重要です。なぜなら、劣化に対する緩和策（検索の改善、ウィンドウの拡大）は減衰には効果がなく、逆に減衰に対する緩和策（ルールをコンテキスト外に移動する）は劣化には適用できないからです。 モデルドリフトとの比較： ドリフトとは重みやバージョンの変更による挙動の変化を指しますが、ディケイ（減衰）はモデルが固定された状態で発生します。これこそが、ドリフト対策として構築された監視システムをすり抜けてしまう理由であり、論文が示す「モデルではなくハーネス（基盤）の問題」という結論が実務上の重要な教訓となる理由です。つまり、アップグレードで解決することはできず、ベンチマークで検知することもできません。なぜなら、失われていくルールとは、ベンチマークには含まれないデプロイメント固有のものだからです。これら3つの対比に共通するのは、ガバナンスのディケイはモデルに向けられたあらゆる監視の目から見えないということです。それはモデルの挙動ではなく、情報のライフサイクルにおける挙動であり、そのライフサイクルはハーネスに属しているからです。

エンタープライズにおけるガバナンスのディケイ：圧縮不可能なポリシー

ここでTrueFoundryの出番となります。今回のベンダーとしての主張は、論文の結論にアーキテクチャを付加しただけのシンプルなものです。エージェントのガバナンスに「忘却の制御」が必要であるならば、企業には2つの選択肢しかありません。忘却を安全にする（制約の固定、監査サマリーの作成、要約機能の強化など。これらは必要ですが脆弱であり、著者らも認める通り不完全です）か、あるいは制約を 忘れられないものにする つまり、忘却メカニズムが到達できない場所に配置することです。この2つ目の選択肢には「インフラストラクチャ」という名前があります。 ガードレール を構成されたフック（LLMの入出力、およびトラフィック照合のためのMCPのツール前後処理）に設置することで、「外部アドレスへの契約送信禁止」といったデータ境界ルールを、3回目のやり取りでも3,000回目のやり取りでも、実際の送信アクションに対して一貫して評価できます。なぜなら、そのルールは リクエストパスに紐付けられており、プロンプトに紐付けられているわけではないからです。トランスクリプト内には圧縮処理によって削除されるような要素は存在しません。この再配置は制御リスト全体に適用されます。ツールの利用範囲は、コンテキスト内での懇願ではなく、MCP層でのIDとタスクによってスコープが決定され（TBAC）、支出はエージェントが要約で消し去ることのできない 予算 によって制限されます。また、研究者が提唱する「信頼できる帯域外のオペレーターチャネル」とは、まさにゲートウェイが提供するものです。 すなわち 、オペレーターがプレーン上でポリシーを変更すれば、その瞬間からすべてのリクエストに変更が適用されます。エージェントのコンテキストは関与しないため、トランスクリプト内でのオペレーターのなりすましは何の影響も及ぼしません。この姿勢を補完する2つの実践があります。圧縮処理自体を 観測可能なイベントとすることです。ハーネスのステップトレースに履歴が圧縮されたタイミングを記録すれば、「エージェントの挙動が不可解に変化した」のか「圧縮処理の前後で挙動が変化した」のかを区別できます。これは、アプリケーションレベルの計測やトランスクリプトの比較が必要になるかもしれない診断ですが、現在のドキュメントではトレース内のコンテキスト増加は確認できても、専用の圧縮イベントマーカーは存在しません。また、コンテキスト内のガバナンスは廃止されるのではなく、格下げされるだけです。トーン、好み、タスクの枠組みなど、本来そうあるべき ものについては、依然としてステアリング（舵取り）のための適切なチャネルであり続けます。 対話とともに進化する。コンプライアンスや影響範囲に関わるあらゆる要素がプレーンへと移行する一方で、私たちの分業体制は コンテキストエンジニアリング および ジャストインタイム・コンテキスト 構築側から発展していきます。この研究を企業向けに一言で要約すると、「エージェントのメモリは情報が欠落しやすいチャネルであるため、コンプライアンス体制をそのまま流し込むのはやめるべきだ」ということです。

‍