はじめに
｢context used｣は、1回のやり取りでモデルに渡した入力文脈がどれだけコンテキストウィンドウを占めたかを示す実務指標です。文脈が過少だと幻覚や取りこぼしが増え、過多だと上限で切り詰めが起きます。本稿は意味・見方・増減要因・運用レシピを体系化し、再現性のある高品質出力に結び付けます。用語と操作の前提は、一次資料としての公式ガイド（例： Cursor｜コンテキストの扱い方）を適宜参照します。
1. 用語整理：｢コンテキスト｣＝モデルに渡す入力情報の集合
｢コンテキスト｣は、プロンプト、開いているファイル、関連コード、ログ、会話履歴などをトークン化した入力の総体です。
- Cursorは関連ファイル・実行ログなどを自動で取り込む
- @file/@folder/@code で根拠を明示指定できる
- 十分かつ適切な文脈は精度を上げ、不適切な混入は幻覚や非効率を招く
2. ｢context used｣の見方：何の％か、何と混同しやすいか
- ｢context used｣：当該リクエストでコンテキストウィンドウの何％を消費したかの目安
- 合算対象：会話履歴、貼り付けコード、自動取得コンテキスト、@指定の総量
- ｢Usage Summary｣との違い：こちらは月次の使用量であり、請求・クレジット管理の指標
- 文脈の中身は自動収集＋@指定で変わるため、何を入れるかを制御することが第一歩
注意：｢context used＝プロジェクト全体の何％を読んだか｣ではありません。安全には｢利用可能なコンテキスト窓をどれだけ埋めたか｣の指標として扱います。
3. 増減要因とリスク：高すぎる時/低すぎる時
- 上がる要因
- 長い会話履歴や巨大なログを貼る
- 大きなファイルや多数の関連ファイルが参照される
- 厳格なルールや長文ガイドを常時読み込ませる
- 同一スレッドで生成を重ねる
- 高すぎると起きがち
- 上限到達による履歴の切り詰めや再要約
- 指示や仕様の脱落で一貫性が低下
- 実行時間やコストの増大
- 低すぎると起きがち
- 根拠不足による局所最適の修正
- 既存規約や設計方針を踏まえない提案
4. 実務チューニング：成果に効く5つのレシピ
- 粒度を制御：@file/@code/@folderで必要最小の根拠だけを渡す
- 履歴の整頓：長い往復は要約して差し替え、重要指示はRulesとして固定
- ログは縮約：巨大ログは原因周辺を抜粋し、再現手順は箇条書きで添付
- 段階生成：大きい変更は｢設計→骨格→詳細｣に分け、各ステップの文脈を狭く保つ
- 観測と上限管理：エディタの使用量表示や拡張でモニタリングし、過剰消費を検知
運用仮説と検証方法：｢context used｣を60〜80％に収めると品質とコストのバランスが良いという仮説を置き、代表タスクで①自動収集のみ、②@最小根拠、③@広範囲＋要約の3条件を比較検証します。重要案件向けには｢@最小根拠テンプレート｣を整備し、Rulesと要約の定期メンテナンス日を設定します。
おわりに
｢context used｣は、関連根拠を過不足なく渡せているかを示す先行指標です。@指定で文脈の粒度を制御し、履歴整頓と段階生成で窓を健全に保つことで、出力品質と再現性を安定化できます。
概念は公式ガイドを、挙動の細部はコミュニティの知見を合わせて運用に落とし込んでいきましょう。