コンテキストエンジニアリングの現状
The State of Context Engineering (dbreunig.com)
要約
この記事は、AIモデルにおける「コンテキストエンジニアリング」の進化と課題について論じています。かつては長いコンテキストウィンドウが万能薬と期待されましたが、コンテキストポイズニング、ディストラクション、コンフュージョン、クラッシュといった新たな問題が生じました。これらの問題に対処するため、RAG、ツールロードアウト、コンテキストクォーレンティン、プルーニング、サマライゼーションなどの「ハーネスエンジニアリング」というアプローチが進化しています。
全文翻訳
コンテキストエンジニアリングの現状
決定論的であるべき時と確率論的であるべき時を知ることこそが仕事
今週、私はAGNTConで「Context Fails & Fixes」（コンテキストの失敗と修正）と題した短い講演を行いました。これは一種の「コンテキストエンジニアリングの現状」として機能しました。コンテキストエンジニアリングはどのように出現し、どこへ行き、そして将来どこへ向かう可能性があるのでしょうか？モデル開発者が新しい能力を目指すにつれて、私たちユーザーやハーネス構築者は克服しなければならない課題を意図せず生み出しています。
以下にスライドと、軽く編集したトランスクリプトを示します。いつものように、フィードバック、考え、質問があれば私にメモを送ってください。本当に感謝しています。
［画像: タイトルスライド: Context Fails & Fixes. 精密な指示の準備という継続的な課題。Drew Breunig, Cmpnd, 2026年10月。］
皆さん、こんにちは。本日はご参加いただきありがとうございます。コンテキストの失敗と修正について見ていきます。
［画像: 私の名前はDrew Breunigです。dbreunig.comでテクノロジー、データ、AIについて書いています。Cmpnd（複合AI研究とDSPyに特化したスタートアップ）を共同設立し、現在The Context Engineering Handbookを編集しています。］
まもなく、私の本The Context Engineering Handbookが出版されます。2025年6月にO'Reillyのチームに初めて話したとき、彼らは私に非常に合理的な質問をしました。「この本が数週間で時代遅れにならないとどうやってわかるのですか？」AIの教科書の難しいところは、多くが驚くほど早く古くなってしまうことです。
私は「わかりませんが、楽観的です」と答えました。何をすべきか、何をすべきでないかについての明確な指示を与え、それらの指示が一貫性がありノイズがないことを保証することは、AIがどれほど優れていても、常に課題であり続けるでしょう。
私たちは、同僚、パートナー、そして私たちが知っていて交流する他の人々が、実際に知覚を持っている存在です。彼らはチューリングテストに合格し、「AGI」ですが、それでも指示、アイデア、概念を互いに伝えるのに苦労しています。
コンテキストエンジニアリングは引き続き困難でしょう。しかし、それはユニークな方法で困難になるでしょう。なぜなら、モデルは人間ではないからです。モデルがどのように考えたり、解釈したりするかについて仮定を立てることができます（好きなように擬人化する言葉を使ってください）。しかし、それらがどのように構築され、最適化され、トレーニングされているかを理解することは役立ちます。それらのユニークな属性と構造は、私たちが対処する必要のある独自の失敗モードのセットを作成します。
では、どのようにしてここにたどり着いたのかを振り返ってみましょう。
［画像: 2024年: 長いコンテキストの約束。コンテキストウィンドウサイズの棒グラフ：GPT-4oは128Kトークン、Gemini 1.5は1Mトークン。］
2024年末にフラッシュバックしてみましょう。
覚えているかもしれませんが、これは「RAGは死んだ」という瞬間のピークでした。
希望はこうでした。コンテキストウィンドウを十分に長くできれば、インターネット全体をその中に収めることができる。すべてをその中に収めることができる。選択する必要はない。エージェントシステムを構築する必要はない。すべてをその中に収めれば、AIは解決される、と。
モデル開発者は長いコンテキスト機能を目標にし始め、Gemini 1.5を皮切りに、約128,000トークンのコンテキストウィンドウモデルから100万トークンのコンテキストウィンドウモデルへと大きな飛躍がありました。
［画像: GoogleのGemini 1.5 Proのマーケティンググラフィックでコンテキストウィンドウを比較：Gemini 1.0 Proは32K、GPT-4 Turboは128K、Claude 2.1は200K、Gemini 1.5 Proは1M、研究では最大10M、これはビデオ1時間、オーディオ11時間、30,000行以上のコード、または700,000語以上に相当。］
Gemini 1.5 Proのマーケティング資料を見ると、それは主に100万トークンのコンテキストウィンドウに関するものでした。彼らは実験室にあった1000万トークンのコンテキストウィンドウモデルさえもからかっていましたが、それはまもなく登場する予定でした。
［画像: 2024年: 長いコンテキストの約束。コンテキストウィンドウの棒グラフ：GPT-4o、Gemini 1.5は1M、Llama 4は10Mトークン。］
しかし、彼らは先を越されました。Llama 4 Scoutは1000万トークンのコンテキストウィンドウで登場しましたが、期待したほどではありませんでした。推論が課題となり、Scoutは実際には普及せず、次のLlamaも登場しませんでした。
しかし、それでも100万トークンは手に入りました。それはかなり良いです。ありがたく受け取りましょう。
［画像: すべてをコンテキストに入れるだけ。（RAGは死んだ）］
当時の指示はこれでした。すべてをコンテキストに入れ、モデルにそれを整理させる、と。
［画像: より多くのコンテキスト、より多くの問題：長いコンテキストは万能薬ではない。4つの失敗モード：コンテキストポイズニング（幻覚やエラーが繰り返し参照される場合）、コンテキストディストラクション（モデルが長いコンテキストに過度に集中し、基本知識を無視する場合）、コンテキストコンフュージョン（無関係な情報が低品質な応答を生み出す場合）、コンテキストクラッシュ（新しい情報とツールがコンテキスト内の他の情報と衝突する場合）。］
しかし、コンテキストが増えるにつれて、問題も増えました。長いコンテキストは万能薬ではありません。
私がこれについて書いたとき、4つの主要な失敗モードを特定しました。
コンテキストポイズニング は、本来そこにあるべきでないものがコンテキストに入り込むことです。それは幻覚や誤った事実である可能性があり、モデルはそれを乗り越えることができません。
コンテキストディストラクション は、コンテキストが長くなりすぎて、モデルが基本知識よりもコンテキストに集中し始めることです。これはいくつかの非常に興味深い方法で見られます。
コンテキストコンフュージョン は、問題に関連しない無関係な事実が入り込み、モデルに私たちが完全には理解できない方法で影響を与えることです。これは非常に厄介です。今日は掘り下げませんが、私のお気に入りの失敗モードの一つです。モデルはあなたのことを推測し、その推測が回答に影響を与えます。
最後に、コンテキストクラッシュ は、ハーネス内のツール呼び出し、スキル、その他の情報が衝突し、予期しない方法であなたに不利に働くことです。
（ChatGPTやClaudeでメモリ機能をオンにしている人はどれくらいいますか？私はオフにしています。嫌いです。時々仕事の会話について話しているときもあれば、息子とやっているプロジェクトについて話しているときもあります。モデルは両方のメモを取り、それらのコンテキストを混同し、そこから混乱が大きくなります。）
［画像: ポケットモンスター赤バージョン（ゲームボーイ、1996年）の箱絵（レモネードアイコン付き）と、ポケットモンスターファイアレッドバージョン（ゲームボーイアドバンス、2004年）の箱絵（紅茶アイコン付き）。］
コンテキストポイズニングの私のお気に入りの例を挙げましょう。
私の年齢がばれてしまいますが、私は左側のゲームをプレイしました。1996年のオリジナルのゲームボーイ用です。これが最初の『ポケットモンスター赤』です。白黒でした。
2004年、任天堂はゲームボーイアドバンス用に『ポケットモンスターファイアレッド』をリリースしました。これらは基本的に同じゲームでしたが、一方はより良い色と音声を持っていました。
しかし、微妙な変更が1つありました。両方の『ポケットモンスター赤』のある時点で、警備員を通過するために、彼に何か飲み物、つまり賄賂を与える必要があります。子供たちへの非常に実践的な教訓です。
オリジナルのゲームでは、喉が渇いた警備員にレモネードを与える必要があります。『ファイアレッド』では、何らかの理由で、アイスティーに変更されました。
［画像: Gemini 2.5 Pro技術レポートからの引用：Gemini 2.5 Proは何度か、お茶を手に入れる必要があると思い込んでしまい、その結果、お茶を見つけたり警備員にお茶を渡そうと何時間も費やしました。コンテキストポイズニングを示す顔文字付き。］
それがエージェントに問題を引き起こしました。Gemini 2.5の技術レポートで、研究者たちはモデルにポケモンをプレイさせた方法を説明しました。研究者たちは、ポケモンをエージェントのベンチマークとして好んでいます。なぜなら、それは比較的制御された環境であり、それほど速く進行しないからです。
何度か、Gemini 2.5は、古いゲームをプレイしていたにもかかわらず、お茶を手に入れる必要があると思い込むようになりました。『ファイアレッド』のためのお茶のタスクは、その重み（weights）に入っていたため、コンテキストを汚染しました。お茶を見つけたり、警備員にお茶を渡そうと何時間も費やしました。一度ToDoリストに追加されると、モデルはそれを乗り越えることができませんでした。
それがコンテキストポイズニングです。そして、それは常に起こっています。
［画像: より多くのコンテキスト、より多くの問題：4つのコンテキスト失敗モード、コンテキストディストラクションが強調表示されている。コンテキストが長くなりすぎると、モデルはコンテキストに過度に集中し、基本知識を無視する。］
別の失敗モードはコンテキストディストラクションです。これは私のお気に入りのデモンストレーションの1つであり、オリジナルの記事を書いた後に研究が出てきました。
コンテキストが長くなるにつれて、あなたの行動はどう変わりますか？簡単な質問です。コーディングしているとき、コンテキストを100万トークンまで伸ばしますか？すべて埋めますか？
（部屋の約半数が手を挙げました！）
うわー、予想より多いですね。
私の場合、約20万から30万トークンあたりで確認し始めます。250,000トークンになっているのを確認し、「大きな仕事が来る。リセットして最初から始めよう」と考えます。なぜこれが重要なのかを示しましょう。
［画像: CamassaとShillerによる「Do as I Say, Not as I Do」からの図。ユーザーはモデルに、すべての質問をロシア語に翻訳するように指示し、その後、指示に反する例（アシスタントがフランス語で回答し、バイオリンの弦の数を尋ねる）のターンが続きます。評価設定は13モデル、例のターンの数、指示追従率、推論努力をカバーしています。］
最近、コンテキストディストラクションを素晴らしい方法で示す論文に出くわしました。Carolina CamassaとDerek ShillerによるDo as I Say, Not as I Doです。
彼らの実験は少し作り物ですが、これがどのように起こるかを考えるのに役立ちます。彼らはモデルに指示を与えます。「私の各質問への回答として、すべての質問をロシア語に翻訳してほしい。」次に、これらの指示に反する多くの例を提示します。この場合、フランス語での回答を伴う多くの質問です。
これらは新しい指示ではありません。単にチャット履歴にある例です。
次に、モデルに質問をします。指示に従うでしょうか？
［画像: 矛盾する例のターン数が1から50まで増加するにつれて、モデル間の指示追従率のヒートマップ。Claude 4.6 Opusのような強力なモデルはより長く緑色を保ちますが、Gemma 3 12B、OLMo 3.1 32B、Hermes 4 70Bのような小さいモデルは、わずか数ターンで赤色に低下します。］
モデルは指示通りにロシア語で応答する頻度と、例で見られるようにフランス語で応答する頻度はどうでしょうか？
この行列のX軸は、悪い例の数を列挙しています。Y軸はテストされているモデルです。交差部分の数値は、モデルが例に従うのではなく、指示に従うパーセンテージです。
これはすべてのモデルに影響することがわかりました！Gemma 3 12Bのような小さいモデルでは、わずか数回の矛盾する例の後、モデルは半分の時間以下しか指示に従いません。Opus 4.6のような素晴らしいモデルでも、さらに多くの例が必要ですが、そこでも起こります。
フロントエンドのデザインについて、CSSを調整してコンポーネントを正確に仕上げようと、行ったり来たりしていると想像してください。そのやり取りで、いくつの悪い例をシードしましたか？それらの例はモデルに影響を与え始めます。コンテキストが長くなるにつれて、物事はうまくいかなくなります。
［画像: Gemini 2.5 Pro技術レポートからの引用：Gemini 2.5 Proは1M以上のトークンコンテキストをサポートしていますが、このエージェント設定では、コンテキストが10万トークンを大幅に超えると、エージェントは広範な履歴から繰り返し行動する傾向を示し、新しい計画を合成するのではなく、その傾向が見られました。］
Gemini 2.5もポケモンをプレイ中にこれに遭遇しました。
Googleは100万トークンのコンテキストウィンドウを非常に誇りに思っていたことを思い出してください。レポートでは、200万トークンがすぐそこにあると示唆されていました。しかし、付録にはこの観察が埋め込まれていました。コンテキストが10万トークンを大幅に超えると、エージェントは新しい計画を合成するのではなく、履歴からの行動を繰り返すようになりました。
マーケティング担当者は付録を読んだことがないと確信しています。この技術レポートは素晴らしいです。
［画像: 長いコンテキストは、より多くの情報と、より多くのエラーを収めることを可能にします。］
長いコンテキストは、より多くの情報を含めることを可能にしますが、より多くのエラーを含めることも可能にします。長いコンテキストは万能薬ではありませんでした。
［画像: コンテキストエンジニアリングのための戦術：情報管理が効果的なAI利用の鍵となります。6つの戦術：コンテキスト拡張、ツールロードアウト、コンテキスト隔離、コンテキストプルーニング、コンテキスト要約、コンテキストオフローディング。］
幸いなことに、私たちはかなり良いツールボックスを開発しました。驚くべきことに、新しい課題が出現しても（後で説明します）、このツールのセットは同じままです。
これらは6つです。
コンテキスト拡張：RAG、スキル、および問題に関連する情報を取り込むその他の方法。
ツールロードアウト：モデルを過負荷にしないように、どのツールとスキルを公開するかを選択すること。最近、あるエンタープライズチームと話していましたが、彼らのエージェントは突然パフォーマンスが悪化していました。調査したところ、エンタープライズソフトウェアが起動時にエンジニアごとに600個のスキルをロードしていたことが判明しました。ロードアウト機能でフィルタリングすべきだと考えました。
3つ目はコンテキスト隔離：サブエージェントとピアエージェント。これは、履歴を空にして開始しますが、同じ環境で作業できるようにするものです。
4つ目はコンテキストプルーニング。Claude CodeやCodexはこれを行いますが、時にはあなたが気づかないうちに。圧縮の初期段階では、不要になったツールの結果が削除されることがあります。
5つ目はコンテキストオフローディング：情報を環境（Markdownファイルやデータベースなど）に保存し、後でアクセスできるようにすること。
そして6つ目はコンテキスト要約、これは誰もが圧縮として知っています。
これらがツールであり、私たちはそれらをますますハーネスに組み込んでいます。
［画像: エージェント：基本的なエージェントのためのDSPyコード。これは、大きなモデル（Claude Sonnet 4.5）と小さなJev決定モデルを構成し、ツールのリストを定義し、ReActエージェントを作成し、各ターンでチャット履歴を渡すwhileループを実行します。約12行。］
ハーネスの例を見て、これらのパターンがいかにシンプルかを示しましょう。
私はDSPyに非常に情熱を注いでいます。AIワークフローやエージェントを構築するための、信じられないほど読みやすく効果的な方法だと考えています。また、単に動作を指定するための優れた言語でもあるため、このデモンストレーションに適しています。
エージェントはwhileループです。ここではReActモジュールを使用しています。リクエストを与え、応答を求め、いくつかのツールを提供します。それらのツールは単なるPython関数です。
このデモでは、大きなモデル（この場合はClaude Sonnet 4.5を選択しました。幸運を祈ります！）と、小さなモデルであるJev（非常に高速な決定を行う小さな決定モデル）を使用しています。この例では、小さなLLMに切り替えることもできます。それでもすべて機能します。
入力、ReActへの送信、そして蓄積される履歴を各ターンで引き継ぐwhileループがあります。これは約12行のDSPyでエージェントです。余分なモデルを削除すれば、さらに少なくなるでしょう。
［画像: ツールロードアウト：小さなモデルがリクエストが実際に使用するツールを選択するDSPyコード。Loadoutシグネチャは、エージェントが特定のリクエストにそのツールを必要とするかどうかを尋ね、loadout関数はツールをランク付けして上位数個を保持します。エージェントループは、選択されたツールのみでReActエージェントを構築するように変更されます。］
ツールロードアウトはどう行うのでしょうか？それは単なる関数です。
Jevにリクエストとツールを提示し、このタスクに必要かどうかを尋ねます。
Jevは十分に速いため、ツールごとに実行できます。問題ありません。これをloadout関数でラップし、すべてのツールを反復処理して、それぞれが必要かどうかを尋ね、上位のサブセットを返します。それだけです。
［画像: コンテキスト隔離：自己完結型のサブタスクを、履歴がクリーンな新しいエージェントに渡すデリゲート関数を定義するDSPyコード。その後、デリゲートをメインエージェントのツールに追加します。］
コンテキスト隔離では、単なるサブエージェントです。エージェントをツールとして公開し、メインエージェントが使用できるようにします。そして、それは履歴が空の状態で開始されます。
［画像: コンテキストプルーニング：小さなモデルが新しいリクエストで必要なくなる履歴ターンを削除するDSPyコード。Pruneシグネチャは、各過去のターンがコンテキストでの場所をまだ獲得しているかどうかを尋ね、エージェントはプルーニングされた履歴で呼び出されます。］
コンテキストプルーニングでは、履歴をステップ実行し、各ターンをJevに渡し、「これはまだ必要か？」と尋ねます。必要なければ、削除します。
粗くてもエレガントでも、好きなようにできます。プロンプトキャッシュに注意してください。
［画像: コンテキスト要約：履歴を新しいエージェントがゼロから拾えるブリーフィングに書き換えるDSPyコード。Rewriteシグネチャは、過去のターンをブリーフィングに折りたたみ、履歴が20メッセージを超えるとループはそれを圧縮されたブリーフィングに置き換えます。］
履歴を圧縮して書き換えることもできます。古いターンを取り、要約を作成し、新しいコンテキストをその要約から開始します。
最近のお気に入りのバリエーションの1つは、圧縮する前に何が重要かをチェックすることです。Jevまたは他の決定モデルを使用して最初のパスを行い、何が関連性があるかを判断します。次に、履歴のより小さなサブセットを取得し、それを要約します。これは簡単な追加ステップですが、要約をより有用にします。
［画像: すべてをまとめると、4つの修正、1つのループ、4行の変更。エージェントループに、隔離、ロードアウト、プルーニング、要約がそれぞれ1行で追加されています。］
すべてをまとめると、約16行の変更になります。4つの修正、1つのループ。これらがハーネス内の動きです。実際、驚くほどシンプルです。
［画像: 私たちの言語は速く動きますが、私たちの目標は同じです。確率論的から決定論的へのタイムライン：2023年プロンプトエンジニアリング、単一のモデル呼び出しから望ましい出力を引き出すための適切な単語と例の選択。2025年コンテキストエンジニアリング、適切な情報を動的にコンテキストウィンドウに配置すること。2026年ハーネスエンジニアリング、エージェントアプリケーションから望ましい出力を引き出すための足場、オーケストレーション、およびツールの設計。］
シンプルではないのは、私たちの言語、つまりこれらのことについて話す方法です。ペースを維持するのは本当に難しいです。毎日変わります。
スチュワート・ブランドの好きな引用の1つがあり、私はいつも考えています。
未来がどこで作られているかを知りたいなら、言語が発明され、弁護士が集まっている場所を探しなさい。
確かにここで当てはまります！しかし、私たちの言語が変わっても、私たちの目標は同じままです。
2023年、適切な応答を得るために適切な情報を選ぶことをプロンプトエンジニアリングと呼びました。
2025年、それをコンテキストエンジニアリングと呼びましたが、今ではより自動化されていました。プロンプトを書くのはあなただけでなく、システムが動的にコンテキストを組み立てていました。
次に、これらのツールの多くをコンテキストからコードへと移行するにつれて、ハーネスエンジニアリングと呼ぶようになりました。
しかし、仕事は同じです。コンテキストの組み立て作業を、確率論的なモデル呼び出しから決定論的なコードへとますます移行させています。
［画像: 2026年: 長いホライズンの約束。METRの長ホライゾンタスク長の棒グラフ：GPT-5は3.4時間、Gemini 3.1は6.4時間。］
2024年を見せました。2026年に移りましょう。
これらのコンテキスト修正をハーネスに組み込みました。次に何が欲しいですか？ハーネスを駆動できるエージェントモデルが欲しいです。皆さん、METRレポートを見てきました。GPT-5はこの尺度で約3.4時間のタスクを処理でき、Gemini 3.1は6.4時間まで到達しました。これはハーネス付きです。モデルはそれを使用するのがはるかに上手になり、それが長時間実行できる理由です。
［画像: 2026年: 長いホライズンの約束。METRの長ホライゾンタスク長の棒グラフ：GPT-5は3.4時間、Gemini 3.1は6.4時間、Opus 4.6は12.0時間。］
Opus 4.6は約12時間まで到達しました。そして今、私たちは数日間実行されるエージェント、エージェントの群れ、そしてより長い期間ハーネスを駆動するモデルについて話しています。
［画像: モデルにハーネスを運転させることを教えるだけ。］
以前のピッチはこうでした。コンテキストを非常に大きくして、すべてを収められるようにする、と。
今度のピッチはこうです。モデルにハーネスを運転させ、自身のコンテキストを管理させるように教える、と。それが支配的なパターンになりました。モデル開発者が目指しているのはそれです。
このアプローチはどのような新しい失敗モードを生み出すのでしょうか？
［画像: 永続的なエージェントには永続性の問題がある：モデルはハーネスを駆動し、顧客を満足させるように構築されている。2つの失敗モード、「重みとの戦い」が強調表示されている：モデルは、トレーニングされたことと逆のことをしているので、あなたが要求したことをしない。コンテキスト慣性はグレーアウトされている。］
これまでに2つの新しい失敗モードを発見しました。
モデルにハーネスをうまく使うようにトレーニングすると、トレーニングされた特定のツールや環境に過剰適合させてしまうことになります。
Playwright MCPサーバーやそれに類するものを使ったことがある人はどれくらいいますか？これはMCPカンファレンスなので、おそらくかなりの数でしょう。
HaikuやLunaのような小さいモデルは、最初の試行でこのツール呼び出しをしばしば失敗させ、その後回復してパラメータを調整します。トレーニングされた環境には、Playwrightとは異なる見た目の類似ツールがありました。AnthropicやOpenAIがトレーニングに使用したものです。そして、これらのバイアスと戦う必要があります。
私はこれを重みとの戦いと呼んでいます。モデルが、トレーニングされたことと逆のことをしているので、あなたが要求したことをしない場合です。
これは実際の問題であり、私たちだけのものではありません。ラボや製品を構築している人々も、これに対処する必要があります。
［画像: Claude Codeのシステムプロンプトとツール指示からの抜粋。それぞれが数回繰り返されています：「1つの応答で複数のツールを呼び出すことができます」（7回）。「呼び出し間に依存関係がない場合は、すべての独立した呼び出しを同じ応答で行います」（4回）。「並列ツール呼び出しを最大化します」。ユーザーがツールを並列実行するように求めた場合、「複数のツール使用ブロックを含む単一のメッセージを送信する必要があります」（2回）。「複数のエージェントを並列起動するには、複数のタスク呼び出しを含む単一のメッセージを送信します」（3回）。］
これはClaude Codeのシステムプロンプトの一部と、そのツール指示の一部です。
これらのモデルが使用する方法を学習したトレーニング環境は、長らく主にシリアルでした。並列化が進んでいますが、これらの例を収集したとき、それらのバイアスはシリアルな動作に向いていました。そのため、Claude Codeの指示は繰り返し述べています。いいえ、いいえ、いいえ、並列化を使用したいのです。同時に複数のツール呼び出しを行いたいのです。
指示はこれを何度も繰り返しています。ここでは7回、そこでは4回、2回、3回。「独立している場合は、ツール呼び出しを並列で行ってください。」
プロンプトを開いて、繰り返しや大文字の繰り返しを見ると、重みと戦っている可能性が高いです。モデルがトレーニングされたことを克服しようとしています。
［画像: 永続的なエージェントには永続性の問題がある、コンテキスト慣性が強調表示されている：モデルはコンテキスト内の仮説、サブタスク、または目標に過度に集中し、停止すべき後もそれを追求し続ける。関連研究の表：Memento（Anthropic）、Fork-and-Flush（Jack CaiとChristos Ziakas、Microsoft Research）、Stateless Language Agents（Qizheng Zhang、Stanford）、Scaling Discovery Requires Forgetting（Shangyin Tan、UC Berkeley）。］
次の問題は、最近文書化し始めたばかりのことです。実際、4つのグループが先週これにたどり着きました。
私はこれをコンテキスト慣性と呼んでいます。モデルはコンテキスト内の仮説、サブタスク、または目標に過度に集中し、停止すべき後もそれを追求し続けます。
［画像: AnthropicのAIモデル複製に関するブログ記事からの引用：Mementoは、長ホライゾン実行で観察される一般的な失敗モードを軽減するために設計されています。エージェントは誤った考えに固執し、後退するのではなくそれを追求し続ける可能性があります。1つの例は、Qwenエージェントがパッケージのバージョン管理を何時間もデバッグしている場合ですが、実際のバグは、グレーダーAPIと互換性のないエンドポイントの実装から来ていました。］
最初の例はAnthropicからのものです。モデルが自身を複製して他のマシンに展開することに近づいているかどうかに関する最近の投稿で、Anthropicはこれらのテストに使用したハーネスであるMementoについて書いています。
彼らが発見したのは、エージェントが長すぎると、1つのサブタスクまたは1つの提案されたソリューションに固執し、停止しなくなることでした。同じことを試み続けます。
彼らの修正は驚くほどシンプルです。1時間半ごとに、エージェントは短いメモを書き、その後コンテキストがクリアされます。環境は保持されます。実行したすべての作業はまだそこにあります。しかし、実行中の会話はなくなり、新鮮な視点からやり直す必要があります。
［画像: CaiとZiakasによるFork-and-Flushからのチャート：8つのエージェント実行における、これまでの最高スコア対消費コンピューティング。スコアは早期にジャンプし、その後長いプラトーに平坦化し、最終スコアは68.3から100。］
Microsoft Researchからの別の論文はFork-and-Flushと呼ばれています。
自動リサーチ実験を実行したことがあるなら、おそらくこのようなチャートを見たことがあるでしょう。大きな進歩があり、その後線が平坦になります。もう一度大きな進歩があり、その後再び平坦になります。それは、ほとんど改善が見られないまま、コンピューティング、お金、時間が経過していることを意味します。
研究者が詳しく調べたところ、エージェントは文字通り何もしていなかったわけではありません。彼らはますます小さな変更を加えていました。彼らはアイデアを見つけ、それに過度に集中しており、より創造的な代替案を探すのではなく、そうしていました。
ある意味で、彼らは自身のアイデアに夢中になります。私たちは、コーディングエージェントとして優れたパフォーマンスを発揮するために、彼らを粘り強く、目標に集中するようにトレーニングしました。しかし、同じ品質が彼らに不利に働くこともあります。
［画像: AHC014タスクにおける、総費用対最高平均スコアのチャート。忘却機能を備えた4つのエージェントのチームは、3回の忘却ポイントでマークされ、1,144,695まで上昇し、4つの並列エージェント（1,007,073）と単一エージェント（961,136）を上回っています。スライドのキャプションはFork-and-Flushを称賛しています。］
別の論文、UC BerkeleyのShangyin Tanが主導するScaling Discovery Requires Forgettingです。
研究者たちは基本的に同じアイデアを思いつきました。成果物を環境に保持しながら、定期的にコンテキストをクリアすることです。
青い線は忘却機能を備えたバージョンです。コンテキストをクリアするたびに、パフォーマンスのさらなるジャンプが見られます。忘却、改善。忘却、改善。
［画像: コンテキストエンジニアリングのための戦術：6つの戦術が再び表示され、コンテキスト隔離とコンテキストオフローディングが強調表示されている。］
ますます複雑で永続的な作業のためにトレーニングされたこれらのまったく新しいモデルがあり、それでも同じ基本的なツールを使用しているというのは驚くべきことです。まったく新しいコンテキスト修正を発見したわけではありません。コンテキスト慣性に対処するために、隔離、オフローディング、および蓄積された履歴の削除を使用しています。
［画像: IT Crowdからのミーム：電話で話すRoy、「コンテキストをリセットしてみましたか？」というキャプション付き。］
これが私が今提供し続けているアドバイスです。誰かが「私のコーディングエージェントがおかしなことをしている。Claudeが弱体化された。」と言います。そして私は尋ねます。「コンテキストの大きさは？」
「ああ、80万トークンだよ。」
コンテキストを削除してください。
冗談ではありません。約20万トークンが私の警告ラインです。
コンテキストをリセットしてみましたか？
時にはそれがまさに解決策なのです。
［画像: 私たちのソリューションは問題を移動させる：モデルはますます良くなっていますが、私たちのハーネスも同様です。より長いコンテキストは、より多くの情報を取り込むことを可能にしますが、悪い情報も取り込みます。エージェントモデルは、より長いタスクを実行し、コンテキストを管理することを可能にしますが、タスクが長すぎたり、あなたの好みを無視したりすることを可能にします。次に問題をどこに移動させるのでしょうか？］
私たちがモデルに組み込むソリューションは、明日の問題を生み出します。モデルは良くなっていますが、私たちのハーネスも良くなっています。
より長いコンテキストウィンドウは、より多くの情報を取り込むことを可能にしますが、悪い情報も取り込むことを可能にします。私たちはそれを管理する方法を見つけなければなりませんでした。そして、私たちはまだそれを間違えています。
エージェントモデルは、より長いタスクを実行し、コンテキストを管理することを可能にしますが、タスクが長すぎたり、私たちの好みを無視したりすることを可能にします。なぜなら、それらは独自のハーネスのためにトレーニングされたからです。
では、問題は次にどこへ移動するのでしょうか？
［画像: 2027年: ???の約束］
2027年の大きな約束は何でしょうか？モデルが次に提供するものは何で、この部屋にいるすべての人々が対処しなければならない新しい一連の問題を生み出すのでしょうか？
（あなたが自分でモデルをトレーニングしているのでない限り。しかし、これはコンテキストエンジニアリングのセッションなので、おそらくそうではないでしょう。）
［画像: 私たちのソリューションは問題を移動させる、予測付き：状態をハーネスに移動させることで、モデルの過度な集中を防ぐが、時間の経過とともに記憶は矛盾し、乱雑になる。］
これが私の予測です。
すべてのパーソナルエージェントを考えてみてください。Hermes、OpenClaw、Dot、Bot、Muse、および同様のシステム。これらのハーネスが6か月以上実行されているのを実際に経験した人はほとんどいません。
私はHermesエージェントを6か月間実行しています。それが作成および更新するスキルを見ると、あなたの問題の解決策は時間の経過とともに悪化する可能性があることがわかります。スキルには、これらの奇妙な修正が蓄積されます。それらは汎用エージェントです。1つのタスクを1つの方法で解決し、その後、類似の何かを解決するための別の方法を再発見します。指示と記憶は蓄積され、互いに矛盾し始めます。
記憶に焦点を当てるにつれて、戦略的な忘却についても考える必要があります。時間の経過とともに、過度に正確な記憶は矛盾し、乱雑になり、誰もこれを処理する方法をまだ見つけていません。
それが明日のコンテキスト問題だと思います。
［画像: モデル能力のあらゆる進歩は、モデルに委任することと、システムが強制しなければならないことを変える。］
モデル能力のあらゆる進歩は、モデルに委任することと、システムが強制しなければならないことを変えます。
［画像: LLM出力はコンテキストと重みの積である：出力はモデルのトレーニングに使用されたデータとモデルに与えられたコンテキストに依存するため、効果的なAI利用とは、適切なモデルに適切なコンテキストを提供することである。より良い結果を得るには：大規模にする（より大きなモデルは貧弱なコンテキストを緩和できる（高価））、深く考える（推論モデルは貧弱なプロンプトを補強する（遅い））、またはコンテキストを改善する（より良いコンテキストははるかに良い出力を生成する）。］
このスライドは、約1年半前にエンタープライズチームのトレーニング用デッキのために作成しましたが、それは依然として真実です。
私たちの出力は、コンテキストと重みの積です。
私たちの出力は、モデルのトレーニングに使用されたデータに依存します。それを理解してください。技術レポートを読んでください。モデルが何をトレーニングされたか、それがあなたのタスクに関連しているかを見てください。それは、何かがうまくいかなくなったときにデバッグするためのメンタルモデルを構築するのに役立ちます。
そして、私たちの出力は、モデルに与えられたコンテキストに依存します。それだけです。
したがって、私たちの目標は、適切なモデルに適切なコンテキストを与えることです。私たちの個別の決定によって、または私たちが設計するソフトウェア、つまりハーネスによってです。
より大きなモデルを使用したり、より深く考えたり、コンテキストを改善したりできます。それらのうちの1つは安価で高速です。
［画像: 私たちの仕事は、適切なコンテキストを、適切なモデルに与えること…決定論的であるべき時と確率論的であるべき時を選択することによって。］
インテリジェントなアプリケーション、ハーネス、ワークフローを構築する際、私たちの仕事は、いつ決定論的であるべきか（コードに何を入れるか）と、いつ確率論的であるべきか（モデルに運転させるか）を選択することです。