Cursorを使っていると、ダッシュボードに表示されるTokensや利用金額が気になる場面があります。
ただ、数字だけを見ても「どこで消費されているのか」「どうすれば抑えられるのか」は分かりにくいものです。
この記事では、CursorでのLLMトークン消費の基本的な仕組みと、日々の使い方の中で無理なく節約するための工夫を整理します。
トークン消費の仕組み
1. トークンとは
トークンは、LLMがテキストを処理するときの最小単位です。
感覚としては「単語に近い単位」ですが、実際には単語そのものとは限りません。
たとえば、helloは1トークンとして扱われることがありますが、understandingのような語はunder stand ingのように複数のトークンに分かれることがあります。
ここで大事なのは、LLMの利用量は文字数ではなくトークン数で数えられるという点です。
課金もこのトークン数をもとに計算されるため、プロンプトや返答が長くなるほど、利用量も増えやすくなります。
2. 消費の内訳（ダッシュボードの「Tokens」詳細）
Cursorのダッシュボードでは、トークン消費がいくつかの項目に分かれて表示されます。
| 項目 | 意味 | 課金の目安 |
|---|---|---|
| Input | あなたが送るプロンプト・コード・会話履歴など | 入力単価（例: $1.25/100万トークン） |
| Output | モデルが生成した返答・コード | 出力単価（例: $6.00/100万トークン、入力の数倍） |
| Cache Read | キャッシュから読み出したコンテキスト | 入力より安い（例: $0.25/100万トークン、約1/5） |
| Cache Write | 新たにキャッシュに書き込んだ部分 | 入力と同様の単価 |
| Total | 上記を合わせた「利用量」 | 課金のベース |
- Total ＝ Cache Read ＋ Input ＋ Output（＋ Cache Write がある場合はそれも）の合計値です。ダッシュボードでは「120.8万」のように表示されます。
- Type: Included ＝ 正常に処理され、使用量にカウントされたリクエスト。
- Type: Errored ＝ エラーで完了しなかったリクエストで、トークンは0と記録され、課金されません。
「何を送ったか（Input/Cache）」「何を返したか（Output）」の両方でトークンが消費され、出力の方が単価が高いのが基本です。
特に意識したいのは、Output の単価は Input より高いことが多いという点です。
そのため、「長い返答を毎回もらう」使い方は、思った以上にコストが膨らみやすくなります。
3. キャッシュの役割
Cursorでは、同じプロジェクトや同じ会話の流れの中で、過去のコンテキストの一部がキャッシュされます。
このキャッシュが効くと、毎回すべての文脈をフルで送り直すのではなく、既に保持されている内容をCache Readとして安く再利用できます。
そのため、同じテーマを継続して扱う場合は、新しいチャットを毎回立ち上げるよりも、同じスレッドで続けた方が効率的なことがあります。
Cache Readが100万トークン超になる場合は、長いコンテキストを無駄なく再利用できている状態と捉えると分かりやすいです。
消費量を抑えるための工夫
コンテキストを絞る（Input / Cacheを減らす）
1. 必要なファイル・範囲だけを渡す
関連するコードだけを見てもらえば十分な場面で、プロジェクト全体を広く参照させると、その分だけトークンを消費します。@ファイル名 や選択範囲を使って、必要な部分だけを明示するのが基本です。
2. 会話をテーマごとに分ける
ひとつのチャットで複数の話題を長く続けると、会話履歴が膨らみ、毎回読み込まれる文脈も増えていきます。
バグ修正、設計相談、文書作成のように、話題ごとに会話を整理するだけでも無駄を減らせます。
3. 大きなログやデータをそのまま送らない
長いログや大量データを丸ごと送ると、それだけで入力コストが増えます。
必要な行だけ抜き出す、先に要点をまとめる、といった前処理をしてから渡す方が効率的です。
出力を抑える（Outputを減らす）
4. 返答の粒度を指定する
LLM は指示が曖昧だと、丁寧に長く答えようとする傾向があります。
そのため、「Be concise」「箇条書きで」「該当箇所だけ」のように、返答の粒度を先に指定するのが有効です。
説明の質を落とさずに出力量を抑えやすくなります。
5. 一度に大きな変更を頼みすぎない
大きな依頼は、回答も長くなりがちです。
また、広い範囲を一気に変更させると、不要な提案や差分まで含まれやすくなります。
実務では、小さな単位で依頼して、必要な箇所だけ順番に進める方が、精度とコストの両方で安定しやすいです。
キャッシュを活かす
6. 同じチャットで続きの質問をする
新規チャットを乱発するとキャッシュが効きにくくなります。関連する話題であれば、同じスレッドでやり取りを続けた方がCache Readが増え、実質コストを抑えられる可能性があります。
7. プロジェクト構成を大きく変えすぎない
同じファイル群、同じ領域で継続して作業すると、キャッシュの恩恵を受けやすくなります。
逆に、毎回まったく異なる領域へ飛ぶような使い方だと、再利用できる文脈が減りやすくなります。
無駄なリクエストを減らす
8. エラーになる操作を避ける
Type: Erroredは0トークンですが、やり直しで結局もう一度Includedのリクエストをすることになり、トータルの利用料は増えます。
あいまいな依頼や、何をしてほしいか不明確な指示は避け、再現しやすい形で依頼するのが大切です。
9. タブ補完やAgentの役割を分ける
Proならタブ補完は無制限です。何をどこまで任せるのかを明確にして、必要以上に大きな処理を走らせないことが、無駄な消費の抑制につながります。
モデル・モードの選択
10. Auto / 軽いモデルで足りる場面は使い分ける
簡単な質問や軽微な修正まで、常に重いモデルで処理すると消費は大きくなります。
内容に応じて、軽いモデルで十分な場面は切り替えることが効果的です。
11. 長いコンテキストが必要なときだけMaxを使う
長いコンテキストを扱えるモードは便利ですが、その分だけ消費量も増えやすくなります。
大規模な設計確認や横断的なコード読解のように、本当に必要な場面に絞って使うと無駄が減ります。
まとめ
Cursorでのトークン消費は、単純に「質問した回数」だけで決まるわけではありません。
入力した文脈の量、返答の長さ、キャッシュの使われ方によって、利用量は大きく変わります。
特に意識したいのは次の5点です。
- 送る情報を必要な範囲に絞る
- 返答は簡潔に指定する
- 同じ文脈はキャッシュを活かして再利用する
- やり直しが増える曖昧な依頼を減らす
- モデルやモードを用途に応じて使い分ける
ダッシュボードの数字をただ眺めるだけでなく、どの使い方が消費を増やしているのかを理解できるようになると、Cursorをより実務的に運用しやすくなります。
コストを抑えること自体が目的ではなく、必要な場面でしっかり使い、無駄な消費だけを減らすという考え方で捉えるのがよさそうです。
