Cursor をヘビーに使っていると突然やってくる
「This conversation is too large. Token limit reached.」
何もできない…。
モデルは返事してくれない…。
作業は止まる…。
悔しい…。
というわけで、怒りのままに Cursor の Usage ログ（CSV）を解析して、
「自分はどんな使い方をしていて、なぜトークンリミットに到達してしまうのか？」
を可視化してみた。
同じ症状で悩んでいる方の参考になればと思う。
なぜトークンリミットに到達するのか？
結論から言うと、原因は非常にシンプルだった。
1つのタスクウィンドウで長時間作業しすぎていた
Cursor はタスクウィンドウ内の文脈を “すべて” モデルに渡すため、
- チャット履歴
- 大量のMarkdown
- PRD
- コード
- 過去の返答のキャッシュ
- ワークスペースの内容
などが積み重なるほど Cache Read が爆発 する。
実際のデータでは…
Usageログ解析結果
解析に使ったCSVは Cursor の Usage 画面から export したもの。
軽く pandas で読み込んでみた。
1. 1回あたりの総トークンは「平均 67 万トークン」
平均：676,790 tokens / 実行
中央値：200,434 tokens
最大：15,457,040 tokens
※ 桁を間違えていない。本当に1500万トークンの実行があった。
2. 1回の実行の 70％以上が Cache Read
Cache Read の平均：489,624 tokens
ほぼ毎回、
「過去にやりとりした内容（数十万〜百数十万トークン）」
を読み返していることが判明。
3. Outputはそこまで多くない
出力トークンの平均はわずか 3,395 tokens。
つまり原因は出力ではなく、
巨大な過去コンテキストを毎回丸ごと読み込んでいたこと。
4. モデル利用割合も特徴的
| Model | Count | Percentage |
|---|---|---|
| gpt-5.1-codex-high | 186 | 40.4% |
| claude-4.5-sonnet-thinking | 79 | 17.2% |
| gemini-3-pro-preview | 60 | 13.0% |
| composer-1 | 40 | 8.7% |
| gpt-5 | 38 | 8.2% |
| その他 | 57 | — |
高性能モデルを使う比率が圧倒的に高い。
そりゃトークンも消える。
なぜ Cache Read がこんなに多くなるのか？
Cursor の仕組みを整理すると理由が明確になる。
原因1
過去のチャット履歴を丸ごと読み込む
同じタスクウィンドウを開いたままにすると、
- 昨日の対話
- その前の対話
- 数万文字のビジネスプラン
- 分析ログ
- サンプルコード
など “全部” が復元される。
原因2
巨大なMarkdownや仕様書を読み込ませていた
仕様書や事業計画の生成を多くやっていたため、
- 3万字
- 5万字
- 10万字
などのファイルをそのままワークスペースに置いていた。
Cursor は “必要そうに見えるファイル” を自動取得するため、
それらが 毎回キャッシュとして再読み込みされる。
原因3
自分の使い方が「長期的な巨大コンテキスト前提」だった
- 長文の研究
- 分析の深掘り
- ビジネスアイデアの連続展開
- エージェント仕様の相談
- PRFAQ の反復改善
- 構造化 → 分析 → 再構造化 のループ
こういう使い方をすると、
“文脈のつながり” が重要になるため、
Cursor はあえて多くの情報を保持する。
結果として、Cache Read が雪だるま式に増えた。
トークンリミットに到達しないための改善方法
この経験から導いた改善策をまとめる。
① タスクを「明確に分ける」
長期タスクをそのまま続けるのは危険。
- 「仕様作成用ウィンドウ」
- 「コードレビュー用ウィンドウ」
- 「考察・調査用ウィンドウ」
こんな感じでウィンドウを分けるだけで Cache Read は劇的に減る。
② いらないファイルを workspace context から外す
- 大型Markdown
- 生成後の仕様書
- 長文ログ
は .cursorignore に入れるか、別フォルダに退避する。
③ モデルを使い分ける
- 思考・構造化：
claude-4.5-sonnet-thinking - コード補完：
gpt-5.1-codex-high - 軽作業：
gpt-4.1かo1-mini
重いモデルばかり使わないことでトークン消費が半減する。
④ 長文は「分割して」読ませる
1ファイル20,000文字を一度に読ませるのは危険。
- 分割
- 要約
- セクション化
などでコンテキスト量をコントロールできる。
⑤ 過去ログに依存しすぎない
必要な文脈は「自前で要約保存」しておく。
- 「このタスクの前提」
- 「この仕様のルール」
などをテキスト化して別管理。
Cursor にずっと覚えていてもらう必要はない。
結論
トークンリミットに到達したのは、Cursor のせいではなく、ほぼ自分の使い方の問題だった。
- 巨大な過去ログ
- 大量のMarkdown
- 高性能モデルの連発
- 1つのタスクウィンドウで延々と作業
- 分析・調査の反復で文脈膨張
これらがすべて積み重なり、
Cache Read が爆発し、
1回の実行で 50万〜1500万トークンが溶けていた。
AIツールも賢く使っていきましょう。