Cursorの「Context Used」とは？意味と活用のコツ

こんにちは、Hodaです。

Cursorでエージェントに指示を出していると、画面のどこかに表示される「Context Used」という数値が気になったことはありませんか。会話が長くなるにつれてじわじわ増えていくあの数字、「一体何のパーセンテージなのか」「上がりすぎると何が起こるのか」を正しく理解している方は意外と少ない印象です。

今回は、Cursorにおけるコンテキストの基本的な考え方から、「context used」の実際の見方、そして最近追加されたコンテキスト使用量の内訳表示機能まで、実務目線でまとめてみます。

そもそも「コンテキスト」とは何か

AIモデルは、皆さんが送った指示（プロンプト）だけでなく、ツール開発者があらかじめ設定した指示、これまでの会話のやり取り、添付されたファイルやコードなど、あらゆる入力を「コンテキスト」としてひとつの作業メモリのように保持しています。

Context = 英語だと「前後関係」という意味でも使用されます

Cursorのようなコーディングツールでは、開いているファイルやターミナルの出力、リンターのエラーといった情報も自動的にこのコンテキストへ取り込まれます。そして会話を重ねるほど、このリストはどんどん長くなっていきます。人間の記憶と同じで、一度に保持できる量には上限があり、上限に近づくと会話の要約や圧縮が発生してしまう、という仕組みです。

Cursorにおける「context used」とは

「Context Used」は、そのリクエスト1回でコンテキストウィンドウをどれだけ消費したかを示す目安の表示です。会話履歴、貼り付けたコード、Cursorが自動で取り込んだ情報、@file や @folder で明示的に指定した内容など、そのやり取りに関わる入力の総量がここに反映されます。

注意したいのは、これが「プロジェクト全体のうち何%を読み込んだか」ではないという点です。あくまで「今回使える窓（コンテキストウィンドウ）のうち、どれだけを埋めているか」を示す指標として捉えるのが安全です。

また、Cursorには月次の利用量を示す「Usage Summary」という別の指標もありますが、こちらは請求やクレジット管理のための数字であり、context usedとは全く別物です。混同しないよう注意しましょう。

新機能：コンテキスト使用量の内訳表示

Cursorでは、エージェントのコンテキスト使用量の内訳を確認できる機能が追加されました。これにより、ルール・スキル・MCP・サブエージェントといった設定ごとに、どれだけコンテキストを消費しているかを個別にチェックできるようになっています。

これまでは「なんとなく重そうなファイルを外してみる」といった感覚的な対処しかできませんでしたが、内訳が見えることで、どの設定がコンテキストを圧迫しているのかを具体的に特定し、改善につなげやすくなりました。

コンテキストが高すぎる・低すぎるとどうなるか

コンテキストの消費量は、多ければ良い、少なければ良いという単純な話ではありません。それぞれ次のようなリスクがあります。

消費量が高すぎる場合

• 上限に達して会話履歴が切り詰められたり、再要約されたりする
• 重要な指示や仕様が抜け落ち、一貫性が下がる
• 実行にかかる時間やコストが増える

消費量が低すぎる場合

• 根拠となる情報が不足し、局所的な最適解しか提案されない
• 既存のコーディング規約や設計方針を踏まえない提案が出やすくなる

増えやすい要因としては、長い会話履歴や巨大なログをそのまま貼り付けること、大きなファイルや関連ファイルを多数参照させること、厳格なルールを常に読み込ませ続けることなどが挙げられます。

実務で使えるコンテキスト最適化の5つのコツ

1. 粒度を絞る：まずは @file で必要なファイルだけを渡し、足りない場合に @code でピンポイントに指定する。最初から @folder で広げすぎない
2. 履歴を整理する：長いやり取りは要約して差し替え、重要な指示は都度伝えるのではなくRulesとして固定しておく
3. ログは要約して渡す：巨大なログをそのまま貼らず、原因周辺だけを抜粋し、再現手順は箇条書きにする
4. 段階的に生成する：大きな変更は「設計→骨格→詳細」の順に分けて、各ステップで扱うコンテキストを狭く保つ
5. 消費量を観測する：内訳表示や使用量の表示をこまめにチェックし、想定より消費が多い箇所がないか確認する

目安としては、コンテキスト消費を60〜80%程度に収めるくらいが、品質とコストのバランスが取りやすいという考え方もあります。重要な案件では、最小限の根拠だけを渡すテンプレートをあらかじめ用意しておくと安定します。

知っておきたい既知の不具合・仕様

公式フォーラムでは、添付したファイルの全文がすぐにコンテキストへ入るわけではなく、まず概要（アウトライン）だけが渡され、モデルが必要と判断した部分をツール呼び出しで追加取得する、という仕様についてのやり取りが見られます。これは、会話の早い段階でコンテキストウィンドウを使い切ってしまい、要約が頻発するのを防ぐための設計とされています。

また、Max Modeで1Mトークンのオプションを選んでいても、表示上はコンテキスト上限が約30万トークン程度に留まってしまう不具合も報告されています。Cursor側もこれを既知の不具合として認識しており、対応を進めているとのことですが、修正時期は明言されていません。大きめのモデルを使っていて「思ったより早く要約が入るな」と感じた場合は、こうした表示上の制限が影響している可能性も頭に入れておくとよさそうです。

まとめ

Cursorの「context used」は、そのリクエストがコンテキストウィンドウをどれだけ占めているかを示す実務的な指標です。単体で見るというより、@file / @code / @folder による粒度のコントロールや履歴整理、そして今回追加された内訳表示機能とあわせて活用することで、出力の品質と再現性を安定させやすくなります。

まずは自分のプロジェクトで内訳表示をのぞいてみて、想定より重い設定がないかを確認するところから始めてみてください。