Tomoyaこんにちは。個人開発ブログ「tomyunser.com」の運営者です。
Cursor Proの利用枠を、1回の作業で50%も消費してしまいました。
原因は、入力や出力のトークンではなく、単価が安いからと気にしていなかった「キャッシュリード」。
29回の依頼で、読み込み量は約7,200万トークンに積み上がっていました。
入力と出力のトークン量には気をつけているつもりだった私と同じように、キャッシュリードまでは見ていない方も多いのではないでしょうか。
この記事では、何が起きたのかと、同じ失敗を防ぐために私が決めたルールをまとめます。
- 原因:キャッシュ済みの文脈を読み直す「キャッシュリード」が、約7,200万トークンに積み上がった
- 規模:29件の依頼で、API料金換算は約20〜25ドル。利用枠の約50%を消費した
- 対策:依頼は2つまで/利用枠の20%でいったん止まる/作業ごとに新しいチャットを始める
この記事でいう「利用枠」は、Cursorの利用状況ページ(Usage)に表示される、月ごとのモデル利用量の枠のことです。
作業環境と経緯
Tomoyaまずは当時の私の作業環境と経緯について説明します。
当時の作業環境(使ったモデルとスキル)
| 項目 | 内容 |
|---|---|
| プラン | Cursor Pro |
| メインモデル | GLM 5.3(推論レベルはMax) |
| サブエージェント | Grok 4.7(high) |
| スキル | pstackの「poteto-mode」 |
- GLM 5.3
-
Z.aiのコーディング向けモデルです。比較的低コストで使える万能モデルとして、普段から頼りにしていました。
Cursorの公式ドキュメントによると、推論レベルはLow・High・Maxの3段階で、標準はHighです。
Tomoyaテーブルは最大のMaxで使っていました(旧プランの「Max Mode」とは別の設定です)。
単価は、100万トークンあたりInputが$1.4、Cache Readが$0.26、Outputが$4.4です。
- スキル
-
Lauren Tanさん(poteto)が作成したCursor向けスキル集「pstack」の中の「poteto-mode」を使っていました。
私の理解では、タスクに合わせた手順書を選び、必要に応じてサブエージェントも使いながら、計画から検証までを段階的に進めてくれるスキルです。抜け漏れなく進めてくれる、頼りにしていた切り札でした。
なお、Cursorの公式ドキュメントでは、サブエージェントのGrok 4.7は別枠の「Cursor Models」に分類されています。今回大きく増えたのは、サードパーティモデルの枠(公式表記は「Other Models」。
私は「フロンティアモデルの枠」と呼んでいます)で、中心はGLM 5.3でした。
何を頼んだのか(経緯)
この日は、パフォーマンスに関する技術的負債の改善やサイトの整理に関する要件を、5つほどまとめて依頼しました。どの要件も細部が固まっておらず、「低コストのモデルだから任せてしまおう」と軽い気持ちで頼んだのが、最初の間違いでした。
私は普段からpoteto-modeやGLM 5.3をよく使っていたので、利用枠が増えても10〜20%くらいだろうと甘く見ていました。ところが確認してみると、月の利用枠の半分(50%)を消費していました。
原因は「キャッシュリード」の積み上がりでした
原因を調べるため、Cursorの利用履歴(CSV)をエクスポートして、モデルごとに集計しました。
同じ手順で、ご自身の利用状況も確認できます。
(cursor.com/dashboard/usage)を開く。エディタの設定画面でも、各枠の消費量を確認できます。
2026年10月4日の作業分を集計した結果が、次のとおりです。
| 項目 | 内容 |
|---|---|
| 対象モデル | GLM 5.3(CSV上の表記は glm-5.3-max) |
| 履歴の件数 | 29件 |
| Cache Read | 71,833,969トークン(約7,183万) |
| Input / Output | 1,472,849トークン(約147万) |
| 合計 | 73,306,818トークン(約7,330万) |
Cache Readは、Input/Outputの合計の約49倍でした。
Tomoyaたった29件で、約7,200万トークン…?
キャッシュリードとは?
AIは、作業の1ステップごとに、これまでの会話や読み込んだファイルをもう一度読み直しています。
保存済み(キャッシュ)の部分を読む分が「キャッシュリード」です。
本を最初から読み直してから1行だけ書き足す作業を、何十回も繰り返すイメージです。
単価は安い一方で、読み込み量は「ステップ数 × 文脈の長さ」で積み上がります。
たとえば、文脈が約10万トークンの状態で作業が25ステップ進むと、読み込みだけで250万トークンです(あくまで計算上の例です)。
「1件あたり約250万トークン」の意味
29件の平均は、1件あたり約250万トークンでした。ただ、GLM 5.3のコンテキスト上限は1Mトークン(公式ドキュメント)なので、250万トークンを一度に送ったわけではありません。
1件の作業の中でAIが何度もステップを踏み、そのたびに履歴を読み直した合計だと考えられます。
今回、ステップが増えた理由は2つあると考えています。
- 不明確な要件が5つあり、確認と検証の回数が増えた
- poteto-modeが計画と検証を段階的に進め、サブエージェントも動かした
単価が安くても、量が大きいと総額は大きくなる
GLM 5.3の単価で計算すると、今回の消費はAPI料金換算で約20〜25ドル(1ドル=160円で約3,300〜4,000円)です。
Input/Outputの内訳で幅が出るため、範囲で示しています。Cursorでは、サードパーティモデルの枠はモデルのAPI価格で消費される仕組みです(公式ドキュメント)。
| 項目 | トークン数 | 単価(100万あたり) | 概算 |
|---|---|---|---|
| Cache Read | 71,833,969 | $0.26 | 約$18.7 |
| Input / Output | 1,472,849 | $1.4 / $4.4 | 約$2.1〜$6.5 |
| 合計 | 73,306,818 | — | 約$20.7〜$25.2 |
費用の約7〜9割が、キャッシュリードでした。単価が安いことと、総額が安いことは別でした。
Tomoya気になる追加料金は、約$6程でした。
この分はクレジットを持っていたのでそこで相殺されてオンデマンドにはなりませんでした。
Cursorでは、枠を超えるとオンデマンド(同じAPI単価の従量課金)を追加するか、プランを上げるかを選ぶ仕組みです。
補足: 履歴に『Free』と表示されていた分について
履歴には、コストが「Free(0円)」と表示された行がありました。私の場合、手持ちのクレジットが消えていたため、この分はクレジットで充当されたものと考えています。【約$6:減ったクレジット額】
Cursor公式にこの表示の説明は見つけられていないので、あくまで私の推測です。そのため、利用枠の50%という数字は、実質的な消費の一部しか表していない可能性があります。
次回からの対策(6つのルール)
今回の学びを、「依頼の出し方」と「運用・環境」に分けて、6つのルールにしました。
A.依頼の出し方(3つ)
対策1:依頼は最大2つに絞り、先にPlan Modeで要件を固める
今回は、不明確な要件を5つまとめて頼み、確認と検証が膨らみました。
次回からは、依頼を最大2つに絞ります(2つは私の目安です)。
依頼が曖昧なときは、先にCursorのPlan Mode(Shift+Tab)で要件を整理します。
Plan Modeは、コードを書く前にAIが質問をして計画を作り、承認を待ってくれる機能です(公式ブログより)。
依頼を絞れば、キャッシュリードが多くなっても全体の作業量が小さくなり、50%もの消費は避けられると考えています。
対策2:思考はGLM、実装はCursor Modelsに分担し、モデルは明示する
私は、GLM 5.3には「コードの編集ではなく、思考をメインにする」とプロンプトに明記しました。すると、入出力は小さく、予測しやすい範囲に収まりました。
実装は、Cursor独自のモデル(公式ドキュメントでは「Cursor Models」。Grok 4.7やComposer 2.5など)に任せます。低コストで十分な能力があり、フロンティアモデルとは別枠で管理されるため、消費の増え方も分かりやすいからです。Cursor Modelsの枠は、含まれる利用量がかなり多いと案内されています。
モデルを指定しないと、AIが「最適」と判断したモデルで作業を進め、利用枠が思わぬ減り方をすることがあります。メインもサブエージェントも、使うモデルは明示しましょう。
対策3:プロンプトに「読み込みを減らす行動」を具体的に書く
私は「cache readの読み込みを、効率的に無駄なく行うこと」とプロンプトに明記して、効果を感じています。ただ、この書き方は抽象的なので、モデルが実行しやすい行動に書き換えると、より確実だと考えています。
コピペ用の例です(回数は目安です)。
- 作業前に不明点を質問し、依頼は2件ずつ進めること。
- 同じファイルを繰り返し読まず、必要な範囲だけ読むこと。
- 大きなファイルやログは丸ごと読まず、検索で対象を絞ること。
- ツール呼び出しが約20回を超えたら、進捗をまとめて一度止まること。B. 運用・環境のルール(3つ)
対策4:利用枠の20%でいったん止まる
作業前に現在の利用状況(%)をメモし、区切りごとに確認して、+20%に達したら、進捗をまとめて一度止まります。
20%は、今回の私の見込みの上限(10〜20%)と同じ数字です。追加料金が心配な場合は、ダッシュボードでオンデマンド(追加課金)の設定も確認しておくと安心です。
対策5:作業の区切りごとに新しいチャットを始める
1つの機能実装や修正が終わったら、新しいチャットを始めます。
Cursor公式ブログでも、別のタスクに移るときや、1つの区切りが終わったときは、新しい会話を始めることが勧められています。さらに、読み込み量は会話の長さに応じて増えるので、キャッシュリードを抑える面でも有効だと考えています。
前の内容が必要なときは、会話をコピーせず、@Chatsで参照すると効率的です(公式ブログより)。
対策6:要約ファイルとピンポイント指定で、読み込み対象を絞る
コードベース全体を毎回読み込ませるのではなく、
ディレクトリ構造や仕様をまとめた軽量なMarkdown(architecture.mdなど)を用意し、編集対象のファイルだけを指定します。
毎回自動で読み込まれるルールファイルに入れる場合は、短く保つのがコツです。公式ブログも、中身を丸ごと写さず、ファイルを指す形を勧めています。
小さな修正は、エディタのインライン編集(Cmd+K / Ctrl+K)にすると、読み込み対象を限定できます。
対策後の結果
今月は利用枠がいっぱいになったので来月に実践して検証していこうと思います！
よくある質問
まとめ：単価の安さより「量」を管理する
今回の失敗は、もっと早く経験しておくべきだったと思います。ただ、今回起こって良かったとも考えています。
入出力のトークンに気を取られ、超低コストに見えるキャッシュリードには何も配慮していなかったのは、私の確認不足でした。
欲張って「あれもこれも」と依頼すると、AIは作業をやり切ろうとして手数を増やします。コストの上限は、こちらから伝えない限り、AIは意識してくれません。
AIを使いこなすには、お願いするだけでなく、人間の管理能力・ディレクション能力が問われると感じました。
- 単価が安くても、「ステップ数 × 文脈の長さ」で総額は大きくなる
- 依頼は2つまで、モデルは明示、利用枠の20%でいったん止まる
- まずは、ご自身のUsageページでCache Readの量を確認する
コメント