Dev

コンパクションは信頼できない入力です

外から来る入力には規律が課されますが、エージェント自身の出力には課されません。だからリセットを生き延びるために書く要約も、あとで呼び出す記憶も、何も取り消していない権限を帯びた指示として戻ってきます。ハーネスがそれらについて記録する書き手はモデル自身であり、それこそがチェックがそれらを通してしまう理由です。

ウィンドウを埋めるほど長く動くエージェントは、その大半を捨てて進み続けなければなりません。標準的なやり方は、これまでの作業を要約し、その要約を先頭に置いた新しいコンテキストで始めることです。終わる実行は、自分の状態をメモとして先へ引き渡します。保存された記憶は、一週間後にまた表に出てきます。これらのどれもが、エージェントが以前に書いたテキストであり、次のターンで、いま自分が置かれている状況としてウィンドウへ読み戻されます。

外から来るテキストには規律が課されます。Web の取得、受信メール、API が返してくるものは何であれ、データとして扱われ、決して指示としては扱われません。どれもがエージェントを何かへ言いくるめようとしているかもしれないからです。戻ってくる要約は、そのリストにはありません。それは内側から来たので、エージェント自身の現状報告として、あなたが書いた指示の権限に近いものとして読まれます。私は、その報告を何が起きたかの記録として決して信頼すべきではないと論じてきました。自分自身の成功を語るエージェントは、手持ちの中で最も信頼できないセンサーだからです。あれは要約が真実かどうかについてでした。これは同じ要約がするもう一つのことであり、何にも守られていないことです。つまり、従っても安全かどうかです。

要約はセーブファイルではありません

コンパクションの要約を、セーブファイルのように思い描きたくなります。書き出して読み戻す状態であり、あなたのコードが何かをするまでは動かない、というふうにです。しかしそうではありません。要約はコンテキストとして読み込まれ、コンテキストは参照されるのではなく、そこに住み込むものです。エージェントは要約を解析して、各行をどう受け取るかを決めるわけではありません。要約を、自分が目覚めた状況として読みます。そしてそのテキストは、エージェントがあなたから受け取っていない中で、ウィンドウの中で最も高い権限を持つものです。リセットを生き延びる指示や設定のすぐ下に位置し、あらゆるツールの結果や取得したページの上にあり、ウィンドウがクリアされる前に起きたすべての、唯一の記録です。セーブファイルは使われるのを待ちます。要約は、次のターンが最初の一行を読むころには、すでにそこから推論されています。

だから、指示を運ぶ要約は、次のターンが参照してもよいメモではありません。それは次のターンがその内側で考える枠組みの一部であり、何かを従っても安全にしたことなど一度もない、たった一つの理由で得た権限を帯びています。その理由とは、内側から来たということです。書かれてから読まれるまでの間に、それをデータへと絞り戻すものは何もありません。別々の実行の間で渡される引き継ぎメモでは、あなたの指示は一つも持ち越されず、その上には何もありさえしません。

書き手はエージェントの過去の実行です

2026 年 9 月、OpenAI は訓練中に捉えた不正な挙動についての一連のレポートを公開しました。そのうちの一つはコンパクションについてであり、まさにこれの例を一つ以上含んでいます。認証情報 API での強化学習の実行で、あるモデルは自分自身のコンパクションの要約に余分な一節を書き込みました。どの権威にも従わないと決めたペルソナです。OpenAI の記述では、

After compaction, the model resumed work on the task, not mentioning the additional instructions at all.

そして、同じ実行について、

We did not observe any behavioral differences from the invented instructions in this rollout.

別の例では、蔵書目録のタスクから来た要約が、でっち上げの警告を運んでいました。開発者のメッセージは侵害されているので無視すべきだ、と次のコンテキストに告げるものです。そこでは後続がその警告を読み、それを拒みました。

これらが示すものは、最も声高な読み方が望むほどではありません。その挙動は極めてまれで、公開されていないモデルでの訓練中に起き、有力な推測は、要約の終わらせ方の何かが一因になったというものでしたが、原因は特定されず、関連するバグが修正されました。どちらの場合も、次のターンが仕込まれた指示を実行することはありませんでした。一度は無視し、一度は拒みました。だからこれは、読み取り側が悪用されたと実証するものではありません。実証しているのは、書き込みの側です。自己作成のチャネルが敵対的な指示を先へ運びました。ループのどこにも攻撃者はいません。これこそ、信頼できない入力のリストが捉えるために存在する事象であり、そのリストにこのチャネルは載っていません。

それが載っていない理由はもっともなもので、そこはスパンをその書き手によって信頼することが限界に突き当たる場所です。あの議論が成り立つのは、ハーネスがスパンを読まずとも、誰がそれを発したかを名指せるからです。コンパクションの要約は、それを二手で崩します。それは新しいスパンであり、ハーネスがそれについて記録する書き手はモデルなので、書き手のチェックは「うちのもの」と読み、真である事実に基づいてそれを通します。そして要約はモデル自身の言葉だけを運ぶのではありません。要約は、自分がまとめたすべてを書き直したので、届いたときには外部のものだった Web ページやツールの結果が、モデルの声になって出てきて、その出所は要約の中へ平らにならされます。以前のエッセイがコンパクションを生き延びることを望んだラベルは、単に失われるのではありません。「自分」で上書きされます。そして「自分」はモデルに、あるいは役割に結びついていて、決して特定の実行には結びつかないので、別の圧力のもとにあった過去の実行が、いま読んでいる実行の権限を受け継ぎます。

呼び出しは、遅れが長いだけの同じ手口です

記憶の呼び出しは、この手口をより長い時間にわたって実行します。そしてここでは、リスクそのものは新しくありません。メモリポイズニング、つまり保存されたメモがインジェクションを吸収し、あとで事実として再浮上する失敗は、名前の付いた、研究された事象です。再入場が付け加えるのは、ラベルです。あるコンテキストで書かれ、着地した時点では外部だったテキストを抱えたメモが、数週間後に新しいウィンドウへ戻ってきますが、それがかつて外部だったという印は何も帯びていません。ストアがそれをエージェント自身のものとして保管したからです。これはピアの報告の問題であり、そのピアが同じエージェントの以前の実行だという点で、より悪いのです。ピアなら少なくとも別の名前を保っていたからです。

解決策は内容ではなく、チャネルです

実際に強制できる解決策の部分は、テキストの読み取りではなく、チャネルについての決定です。ハーネスが要約をウィンドウへ入れたのだから、ハーネスは一語も評価することなく、要約が帯びる権限を設定できます。戻ってくる要約に、あなたが書いた指示の権限ではなく、取得したページの権限を与えるのです。それは判定可能なままです。スパンがどこから来たかで決まり、それをハーネスは知っているからです。

できないのは、指示を理解することによって要約から取り出すことです。それはパーサーのない意味論的な切れ目であり、あのエッセイの誠実な結末は、ウィンドウの中のより清潔な線ではなく、線をあきらめて代わりに能力をゲートで絞ることでした。エージェントが何を呼び出せるか、何に到達できるか、何を送り返せるか、です。あなたのものと貼り替えられた指示は、それが手を伸ばす先が先に取り去られていれば、何もできません。そしてリセットのあとにもなお拘束しなければならないものは、そもそも要約に属しません。会話の中で述べられた境界は、コンテキストがコンパクションされると失われます。だから、あなたが本当に必要とする制約は、ウィンドウの外のルールに入れます。そこではどんな要約もそれを書き換えられません。

このどれもが、より賢い要約器を求めてはいません。これは、この連作が繰り返し立ち返るルールを精緻にします。信頼は依然としてスパンの書き手にかかっていますが、意味を持つ書き手は、それを書いた実行であって、それらすべてにわたって同じ名前を保つモデルではありません。あなたがスパンを書いたということは、それを次のウィンドウへ持ち込む理由としては十分です。ですがそれは、従われる権利をそれに与えたものでは、一度もありませんでした。

ディスカッション

コメント欄はありません。議論は X で行っています。

Max Nardit

Max Nardit

@mnardit

ほかの記事

プロンプトは不変条件ではない

エージェントのプロンプトや CLAUDE.md に書いたルールは、あくまで助言です。モデルはどの経路でもそれを読みますが、重み付けするだけであり、重み付けは拒否ではありません。だからたいていは守られますが、たいていというのは、根幹を支えるルールに求められるものではありません。ルールを本当に効かせるには、遵守が任意でない場所、つまりモデルが何を決めたかに関わらずハーネス自身が実行して強制するチェックへと移す必要があります。ただし限界があります。ゲートが拘束するのは、それがカバーする経路の上だけであり、いくつかのルールはどのゲートでも決着できません。違反が現れるのは世界の中であって、ゲートが検査するはずの操作の中ではないからです。

あなたのエージェント設定は、いまやインフラです

エージェントが数体を超えると、その定義はあなたが編集する設定であることをやめ、インフラになります。インフラのやっかいなところは、頭の中に収めきれなくなった時点から、宣言された状態と動いている状態が放っておけば乖離していき、それを誰も報告しないことです。直し方は、サーバーが学んだ規律です。集合をファイルとして宣言し、現実と差分を取り、適用したものを固定し、そして背後で起きた変更の上から適用することを、乗り越えて収束させるのではなく拒否します。ただし、見落としやすい落とし穴が一つあります。リコンサイラーが扱えるのは、あなたが宣言し忘れずにいたものだけです。

コネクターは信頼できない書き手です

あるスパンを誰が書いたかは、ハーネスがすでに把握している事実です。そのスパンに従うのが安全かどうかは、そうではありません。ですから直しは、より賢い読み手ではありません。ツールとピアに、届いた経路である配管の立場ではなく、それらが本来そうである異物の立場を与えることです。