Skip to content
Published on

コンテキスト予算 — 何を入れるかではなく何を外すかが設計です

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
シェア
Authors

ウィンドウは余っているのに正確さが落ちる

エージェントのセッションが長くなると妙なことが起きます。コンテキストウィンドウはまだ上限に達していないのに、序盤に与えた指示を忘れ、確認済みのファイルをまた読み、先に決めたルールと食い違うコードを書きます。この描写は特定の測定ではなく構成した状況ですが、方向そのものは公開された観察と一致します。Anthropicのコンテキストエンジニアリングの記事は、トークンが積み上がるほど回収の正確さが落ちる現象をコンテキストの腐敗（context rot）と呼び、その理由としてアテンションがトークンのペア単位に分散する構造と、短いシーケンス中心の学習分布を挙げています。

結論は単純です。コンテキストウィンドウは埋めるための倉庫ではなく、配分すべき注意予算です。予算であるなら、支出項目と削減基準が要ります。

コンテキストエンジニアリングはプロンプトエンジニアリングの拡張です

同じ記事は2つの仕事の関係をこう整理します。プロンプトエンジニアリングが指示文をうまく書く仕事だとすれば、コンテキストエンジニアリングは推論のたびにウィンドウへ入る最適なトークン集合をキュレーションし維持する仕事です。システムプロンプトだけでなく、ツール定義、外部資料、メッセージ履歴まで全部が対象です。一度うまく書けば終わる文書作業ではなく、ターンごとに繰り返される編集の決定だという点が違います。

ハーネスの観点でこの定義が重要な理由は明確です。コンテキストポリシーはハーネスの6つのつまみのひとつで、コードとしてデプロイされる決定です。「毎ターン何を入れ、何を外すか」への答えが、リポジトリのどこかに関数として存在すべきなのです。

ツールのスキーマも予算を食います

よく忘れられる支出項目がツールのスキーマです。モデルに公開したすべてのツールは、名前、説明、パラメータスキーマとして毎ターン、ウィンドウの一部を占めます。21個のツールを公開すれば、モデルが何かを呼ぶ前に予算のひと切れがすでに消えています。ツールが増えるほど選択もぶれるので、スキーマのコストはトークンだけの問題ではありません。このトレードオフは第3回のツール表面の設計で別途扱います。

逆方向の節約手段がジャストインタイムの読み込みです。資料全体を前もってウィンドウに載せる代わりに、ファイルパス、クエリ、リンクのような軽い参照だけを置き、必要な瞬間にツールで取りに行きます。人が文書を丸暗記する代わりに在りかだけ覚えるのと同じ構造で、Anthropicの記事が勧める基本戦略のひとつです。

プロンプト累積からプレイブックへ

最もよくあるコンテキストポリシーは、ポリシーがないことです。新しく学んだルールがシステムプロンプトの末尾に足され続け、文書は育つ一方です。ひと月後には矛盾する指示が共存し、どの項目がまだ有効なのか誰も知りません。この状態では削除が不可能です。消す根拠がないからです。

Lilian Wengのハーネスの記事が紹介するエージェント・コンテキストエンジニアリングの接近は、この問題を構造で解きます。コンテキストを進化するプレイブックとして扱い、項目を作る役割、振り返る役割、選別する役割を分けます。項目ひとつはだいたいこんな形です。

- id: pb-041
  rule: 'integration テストは -j1 で回す。並列だとポートが衝突する。'
  scope: 'repo:payments-api / task:test'
  added: '2026-07-18'
  last_used: '2026-08-07' # 長く使われない項目はキュレーション対象
  helped: 23 # この項目が実際に役立った回数

要点は形式ではなくメタデータです。いつ追加され、どんな状況に適用され、最近役に立ったかが記録されれば、削除が可能になります。コンテキスト管理の難しい半分は入れる側ではなく外す側であり、外せるためには項目に根拠が付いていなければなりません。

ドロップポリシーとコンパクション：何を、いつ

予算があふれたら、何かは出ていかなければなりません。何が出ていくかはポリシーが決めます。古いものから押し出すポリシーは実装がタダですが、序盤の中核ルールから失います。大きな塊から切るポリシーはトークンを節約しますが、重要度を知りません。プレイブックのように適用可能性の低い項目から降ろすポリシーだけが「いまの課題に必要性の低いもの」を基準にします。いずれにせよ、ドロップポリシーはハーネスの明示的な決定であるべきです。デフォルトに任せることは、古いものから押し出すポリシーを選んだのと同じです。

要約、つまりコンパクションはドロップの補完です。上限の近くでここまでの進行を圧縮要約し、その要約から再出発します。Anthropicの記事はこのとき保存すべきものとして、アーキテクチャ上の決定、未解決のバグ、実装の細部を挙げます。裏返せば、何を保存するか明示しないコンパクションは、まさにその3つを失う形で失敗します。併用される技法が構造化メモです。進行状況をウィンドウの外のファイルに書き、必要なときに読み直せば、要約が失敗しても復旧地点が残ります。

サブエージェント委任：きれいなウィンドウを買い、トークンで払う

コンテキスト予算の最後の手段はウィンドウを分けることです。探索の広いサブタスクをサブエージェントに渡せば、サブエージェントは自分だけのきれいなウィンドウで働き、圧縮した要約だけを本隊に返します。本隊の予算は結論の分だけ払えば済みます。

タダではありません。Anthropicのマルチエージェントシステムの記事は、自社システムの数字として、エージェントは通常チャットの約4倍、マルチエージェント構成は約15倍のトークンを使うと報告しています。委任が正当化されるのは課題の価値がそのコストを超えるときであり、委任するときも目標、出力形式、ツールの案内、課題の境界を明示しないと、重複探索と暴走を招くというのが同じ記事の教訓です。サブエージェントはコンテキスト問題の脱出口ではなく、予算をより大きな単位で再配分するつまみです。

実際に練習する

ハーネスエンジニアリングRPGのティア4「コンテキスト予算」がこの記事の演習です。プロンプト累積、切り落とし、プレイブック、キュレーションの4つのポリシーを同じシナリオに差し替えてみると、ドロップポリシーが結果をどう変えるかが直接見えます。ツールのスキーマが予算を食うことも、ゲーム内の数値で確認できます。

参考資料

Discuss on Twitter • View on GitHub