第 45 章：Computer Use のコンテキスト管理
現在のビューポートは証拠です。過去の十一画面は負担です——十二枚すべてを比較する依頼でない限り。
クイックトラック（5 分で核心をつかむ）
- Computer Use では、テキスト観測と画像という二種類の履歴が同時に伸びる
- 観測単体の上限、テキスト窓、ブラウザ画像窓、全体画像上限を別々に持つ
- ブラウザ履歴の刈り込みをツールの種類で限定し、ユーザーのアップロードとバッチ視覚処理には広い予算を残す
- 古い内容を明示的なプレースホルダーに置き換えながら、
tool_use_idの対応関係を守る- フィルターを冪等かつ観測可能にする。プロンプトの刈り込みは、元のファイルの削除ではない
公開ソースのスナップショット：実装例は 2026-07-27 に確認した Kocoro 公開
origin/mainのコミット4ec6772に基づきます。定数は最新ソースで再確認してください。
45.1 Agent が操作できない十一画面
Computer-use Agent が設定画面を開いてスクリーンショットを撮り、アクセシビリティツリーを読み、タブを選び、これを繰り返します。十二回操作した後、次のモデル要求には以下が入ります。
12 screenshots
12 page / accessibility observations
12 assistant decisions
11 viewports that no longer exist最新の一枚を除く十一枚の古いスクリーンショットは高価で、通常はもう役に立ちません。モデルはそれらを操作できず、画面もすでに変わっています。
ただし「通常」が重要です。ユーザーの作業が「この十二枚のスクリーンショットを比較する」ことなら、すべての画像が作業対象です。ブラウザ操作には最適な「全体で一枚だけ残す」という規則が、バッチ視覚処理を壊してしまいます。
テキストにも同じ不一致があります。最新の観測でも、DOM ダンプが 80,000 文字になることがあります。三つ残す窓だけでは、一つの巨大なページがプロンプトを支配するのを防げません。
Computer-use のコンテキストは一つの予算ではありません。半減期の異なる複数のデータ種別から成ります。
45.2 四つの制御、四つの障害
公開スナップショットは四つの制御を分けています。
| 制御 | スナップショット既定値 | 担当する障害 |
|---|---|---|
| 観測単体のテキスト上限 | 24,000 rune | 一つの巨大なページまたはアクセシビリティ情報 |
| テキスト観測窓 | 3 | 手順を重ねるたび蓄積する古いページ状態 |
| ブラウザ/GUI のスクリーンショット窓 | 画像を含むメッセージ 1 件 | 古いビューポートが操作用コンテキストを支配する |
| 画像メッセージの全体上限 | 50 | ブラウザ以外の作業で画像履歴が暴走する |
数値は作業負荷に応じた選択です。重要な設計は分離そのものです。
単体上限では項目数を制限できません。移動窓では一つの異常に大きな項目を制限できません。ブラウザ固有の画像窓ではバッチ画像処理を守れません。全体上限には、最新のビューポートと六ターン前のユーザー画像のどちらが操作可能か分かりません。
各制御に、一人の所有者、一つの設定、一つの公開境界テストを与えます。max_context_items に統合すると、調整するたび別の作業負荷を壊す数値になります。
45.3 取得時に上限、組み立て時に経時処理
24,000 rune の制御は、ブラウザまたは GUI ツールの結果が初めてコンテキストへ入る時に適用されます。観測の先頭を残し、内容を自ら説明するマーカーを追加します。
[browser observation truncated: 81342 chars total]マーカーも上限に含むため、返した観測が設定上限をひそかに超えません。バイトではなく rune を数えれば、中国語、日本語、絵文字の途中で切らず、「24,000 文字」が言語を越えて意味を保ちます。
テキスト窓はその後、要求を組み立てるたびに適用されます。最新三つの GUI 観測を完全に保ち、古い文字列の結果を一行のスタブへ置き換えます。
[elided browser observation: browser_snapshot, was 23811 chars]二つの制御は異なる時間軸を扱います。取得時の切り詰めは「新鮮な時点でも単体が大きすぎた」、経時処理は「以前は重要だったが、今は完全な形で残す価値がない」という意味です。
この生成元別の経時処理は、汎用のコンテキスト逼迫時圧縮より先に動きます。したがって、第 37 章のブラウザ向け Tier 2 下限が保証するのは汎用圧縮器の中だけです。そこでは操作可能なスナップショットをメタデータまで落とさず、本章の観測ウィンドウが役目を終えた GUI 状態をより早く整理します。
これは第 36 章で分けた単体結果の大きさとターン全体の総量を、一般的なツール出力ではなく観測に適用したものです。
45.4 ブラウザ画像はユーザー画像ではない
スクリーンショットは tool_result ブロックの中に入っていますが、対話内の画像がすべてブラウザ由来とは限りません。ユーザーが参照画像をアップロードしたかもしれません。file_read が図を返す場合も、視覚処理が意図的に何十枚も保持する場合もあります。
そこでブラウザ用スクリーンショットの刈り込みは、まず GUI 系のツール呼び出しを識別し、その tool_use_id から対応する結果を追います。「最新一枚」の窓に入るのは、それらの画像だけです。ユーザーのアップロードと非 GUI ツールの画像は、この処理では変更しません。
次に全体フィルターが、最上位と入れ子の画像を含むメッセージ全体へ、緩い 50 件の上限を適用します。範囲の狭いフィルターを先に動かす順序が重要です。全体処理は既に薄くなったブラウザ履歴を見るため、広い予算を本当に必要な作業へ使えます。
画像以外にも一般化できます。強い予算制限は、その制限を正当化する生成元だけに適用するのです。安価な全体分類器は、データの出所を知る代わりにはなりません。
45.5 対話の契約を保つ
スクリーンショットのブロックを丸ごと消すと、Provider のメッセージ契約が壊れ得ます。Assistant の tool_use は残っているのに、対応する tool_result の形が変わるか消えるためです。
フィルターは結果ブロックと tool_use_id を保ち、古いデータだけを明示的なテキストに置き換えます。
[previous screenshot removed to save context]モデルは情報が消えたことを知り、Provider は正しい呼び出しと結果の組を見て、監査記録は後の判断に古い画素がなかった理由を説明できます。
テキストフィルターも同じ規則に従います。結果内の文字列だけを変え、周囲のターン構造を保ちます。第 37 章で扱った対応関係の不変条件を、GUI 観測に特化した形です。
黙って削除するのは最悪です。token を節約しながら、実際には除かれた証拠をモデルが見たかのように記録が嘘をつきます。
45.6 冪等性がキャッシュを守る
フィルターはモデルを呼ぶたびに実行されます。既にスタブ化した観測を反復のたびに少し違うスタブへ書き換えると、接頭辞も毎回変わり、第 39 章で扱ったキャッシュが同じメッセージで永遠に外れ続けます。
テキストスタブには識別できる接頭辞があり、後の処理は飛ばします。画像の置き換えも安定したテキストブロックです。キャッシュ調査用の計測を有効にすると、初回の変更だけが新旧ハッシュ付きのキャッシュ圧縮イベント（obs_window、browser_img_strip、全体用の img_strip）を出し、何も変わらない再訪はイベントを出しません。
期待するライフサイクルは次のとおりです。
full observation → one deterministic placeholder → byte-stable thereafterここでの冪等性はコードの整理だけでなく、料金を左右する性質です。
45.7 プロンプト保持は元ファイルの保持ではない
四つの制御が操作するのは、要求に含めるメッセージの見え方です。それだけでスクリーンショットファイルを消したり、完全な監査イベントを消したり、ユーザーのアップロードを無効にしたりはしません。
これらは別々のポリシーです。
- プロンプト保持： 次の反復でモデルへ渡すもの
- セッション/監査保持： 後から運用者が再構成できるもの
- 一時ファイルの後処理： ローカルのスクリーンショットをディスクから消す時期
- ユーザー素材の所有権： アップロードしたファイルをユーザーが引き続き利用できるか
一緒にすると「コンテキストを節約」が「証拠を破壊」になり得ます。分ければ、モデルのプロンプトから古いビューポートを刈り込みながら、誤ったクリックを調べる記録を残せます。
モデルには損失の開示が必要です。プレースホルダーが何を、なぜ消したかを示します。運用者にはテレメトリーが、保存領域には独自のライフサイクルが必要です。一つの刈り込み関数が三つすべてを所有したふりをしてはいけません。
45.8 token への不安ではなく、作業から調整する
通常は現在のビューポートだけでクリックできますが、常にではありません。フォームのエラーが移動後にだけ出る場合、比較作業に前の画面が要る場合、キャンバス作業に数手順分の視覚的な連続性が要る場合があります。
実際の操作列で調整します。
- 複数ページをまたぐ移動
- 前後を比較すべきモーダル
- ユーザー提供画像の一括処理
- 巨大な多言語アクセシビリティツリー
- 同じ履歴へのフィルターの反復適用
- 古い画像をスタブ化した永続メッセージからの再開
作業成功率、モデル呼び出し回数、入力 token、キャッシュのずれ、再観測率を測ります。Agent が同じスクリーンショットを取り直し続けるなら、窓が狭すぎるか、プレースホルダーが必要な手掛かりを消しています。成功率が安定し、コンテキストが大きく減るなら、予算が本当に機能しています。
一つのきれいな実演から普遍的な上限を導かないでください。Computer Use では画面が直感より速く変わります。
45.9 スナップショットの根拠
| 観測 | 4ec6772 のソース |
|---|---|
| 四つの既定値と、それぞれの作業負荷上の理由 | observation_window.go L11 |
| 観測単体の上限は rune の途中で切らず、明示的なマーカーを含む | observation_window.go L84 |
| テキスト窓は対応関係を保ち、スタブ化済みの結果を飛ばす | observation_window.go L134 |
| ブラウザのスクリーンショットフィルターは GUI ツールの種類で範囲を限定する | observation_window.go L212 |
| 全体画像フィルターは最上位と入れ子の画像を扱う | loop.go L5911 |
| ブラウザ固有、全体画像、テキスト窓の実行順 | loop.go L3253 |
| GUI の結果はコンテキストへ入る時に厳しい上限を受ける | loop.go L4742 |
| Daemon は四つの制御を別々に接続する | runner.go L2737 |
これは特定時点の実装と作業負荷を述べたもので、普遍的な観測上限ではありません。
45.10 よくある失敗
すべての作業負荷に一つの画像上限。 ブラウザ操作は最新のビューポートを、バッチ視覚処理はすべてのアップロード画像を必要とし得ます。
単体上限のない窓。 一つの巨大な DOM ダンプがプロンプトを支配します。
窓のない上限。 個別には合法な観測が何千件も蓄積します。
バイトを文字として数える。 マルチバイト文字が使えるコンテキストは少なくなり、rune の途中で切れる可能性もあります。
結果ブロック全体を消す。 ツール呼び出しとの対応が壊れ、Provider が要求を拒否し得ます。
黙って刈り込む。 実際には消した証拠をモデルが見たかのように記録が示します。
冪等でないプレースホルダー。 組み立てるたび同じ接頭辞を汚し、キャッシュを何度も無効にします。
プロンプトの刈り込みで元ファイルを消す。 コンテキスト方針が意図せず保持方針になります。
一つの作業だけで調整する。 フォーム操作に強い上限が、視覚比較を壊し得ます。
要点
- Computer Use には複数のコンテキスト寿命があります。 テキスト、GUI のスクリーンショット、ユーザー画像は同じ速度で古くなりません。
- 大きさと件数を別々に制限します。 一つの巨大な観測と多数の通常観測は異なる障害です。
- 強い刈り込みは生成元で範囲を限定します。 ブラウザ履歴を厳しくしても、バッチ視覚処理を罰しません。
- 対応関係を保ち、損失を開示します。 データを明示的で安定したプレースホルダーへ置き換えます。
- プロンプトの刈り込みは見え方の変更であって、削除ではありません。 監査記録、ファイル、ユーザー素材には、それぞれ別のライフサイクル所有者がいます。
これで Part 10 のループが閉じます。コンテキスト圧縮、ツール結果の予算、キャッシュの安定性、実行中の操作、時間の規律が、第 28 章で導入した観測負荷の高い作業へ集まります。