第 45 章：Computer Use のコンテキスト管理
スクリーンショット予算は一つの数値ではありません。テキスト観測、browser screenshot、ユーザー画像は価値が異なり、ライフサイクルも分ける必要があります。
公開ソースのスナップショット：実装例は 2026-07-27 に確認した Kocoro 公開
origin/mainのコミット4ec6772に基づきます。定数は最新ソースで再確認してください。
45.1 Computer Use がコンテキストを急増させる理由
Browser loop は一手ごとに DOM snapshot、Accessibility Tree、screenshot、モデル応答を追加します。過去の観測を毎回すべて再送すると、次の行動は通常現在ページだけに依存するのに Prompt コストは全履歴とともに増えます。
画像上限を一つにまとめることもできません。Batch vision は多数のユーザー画像を必要としますが、Browser Agent は通常最新 viewport だけを必要とします。テキスト観測は Image Block ではないため、別の sliding window が必要です。
45.2 四つの独立した制御
| 制御 | スナップショット既定値 | 目的 |
|---|---|---|
| テキスト観測窓 | 3 | 最近の browser/GUI テキストだけを完全保持 |
| 観測単体のテキスト上限 | 24,000 Rune | 巨大な DOM・ページ snapshot を制限 |
| Browser screenshot 保持 | 1 | 現在 viewport を残し、古い GUI screenshot を置換 |
| 画像メッセージ全体上限 | 50 | 非 browser vision と batch image を保護 |
これらは workload 固有の選択で、普遍定数ではありません。重要なのは、各制御が一つの失敗モードを所有し、tool_use_id の対応を保ち、置換を明示し、繰り返し適用しても Prompt 接頭辞を変え続けないことです。
45.3 ライフサイクルと検証
Prompt から screenshot を除くことは、元ファイルの削除を意味しません。コンテキスト組み立て、監査保持、ローカル清掃、ユーザー upload の所有権は別々の方針です。削除・切り詰めはモデルにも明示しなければ、後続推論を監査できません。
45.4 実装チェックリスト
- Browser/GUI 観測、ユーザー画像、通常 Tool Result を分離する。
- 最新の行動可能状態と明示的な truncation marker を残す。
- Nested Image Block、多言語 Rune 上限、冪等性、cache stability をテストする。
- 一回の Demo ではなく、実タスク成功率と Token trace から予算を調整する。
45.5 まとめ
Computer Use のコンテキスト管理は観測ポリシーです。次の行動を変え得る情報を残し、古い状態を要約・置換し、他の画像 workload は別予算で扱います。