コンテキスト設計

コンテキストは足し算ではなく、有限の枠の取り合いです。システムプロンプト、ツール定義、知識、会話履歴、そしてツール実行結果——これらがひとつの枠を分け合います。

さらに重要なのは、枠に収まっていれば良いわけではないという点です。文脈が長くなるほど、モデルが本当に必要な情報へ払う注意は薄まります。「入るから入れておく」は、精度を下げる方向に働きます。

そしてもうひとつ。エージェントが自分の残量を意識すると、仕事を早仕舞いする挙動が出ることが報告されています。枠の管理は、単なる容量の話ではなく、振る舞いの話でもあります。

最初の手は、使い終わったツール実行結果を外科的に落とすことです。3ターン前の検索結果、5ターン前のファイル読み取り——これらは同じ操作でもう一度取得できます。会話の要約と違い、落としても情報そのものは失われません。

調整できるのは、おおむね次の5点です。

• いつ発動するか — 残量がどの水準を切ったらクリアリングを始めるか。
• 直近をいくつ残すか — 文脈の連続性が切れない最小限を残す。
• 最低どれだけ落とすか — 小刻みに消すと、そのたびにキャッシュが無効になり、かえって割高になる。まとめて落とす。
• 落とさない対象 — 記憶・メモリ系のツールは必ず除外する。ここの指定漏れが、最も重い事故になる。
• 呼び出し引数も落とすか — 結果だけ消すのか、「何を尋ねたか」も消すのか。

①②を尽くしてなお足りないとき、初めて要約します。ここで多くの実装が省くのが、「何を逐語で残すか」の指示です。指示がなければ、何が残るかは運になります。

とくに落ちやすいのが文脈付きの数値です。「28件」だけが残って「32件中28件が一致」の文脈が消えると、後続の判断が狂います。数値は必ず、それが何の数値かとセットで残すよう指示します。

タスクの状態も同様です。どのバッチが完了し、どれが未着手か。これが消えると、エージェントは終わった作業をやり直すか、未着手のものを完了扱いにします。

「必要になりそうな資料を全部渡しておく」は、一見安全に見えて2つの問題を抱えます。使わないものが枠を食うことと、積んだ時点の情報で固定されることです。長い作業では、途中で古くなった前提を掴んだまま進むことになります。

このハイブリッドが成立する前提は、手掛かりが読めることです。フォルダ構造が整理されていて、ファイル名から中身が推測でき、更新日時が信用できる。逆に言えば、情報の置き方そのものがコンテキスト設計の一部になります。整理されていない置き場は、そのままエージェントの精度に跳ね返ります。

ここまでの内容を、実装で見かける形にして並べます。