Cursor の「トークンがすぐ尽きる」という不満は、モデル性能の問題というより、どの情報を、どのモードで、どの順番で渡すかという運用設計の問題である。2026年3月4日時点の Cursor 公式ドキュメントでは、現行の中心概念は `Agent`、`Ask`、`Custom`、`.cursor/rules`、`AGENTS.md`、`@Files/@Folders`、`/summarize` であり、`.cursorrules` はレガシー扱いである。したがって、X 上で語られがちな「Composer vs Chat」の論点は、現行 UI では実務上ほぼ「Agent で編集する前に Ask で探索を済ませるべきか」と読み替える方が正確である。

重要なのは、Cursor のトークン消費が「打ち込んだ文章」だけで決まらない点である。Max Mode の課金は、公式 pricing によれば、メッセージ、添付したコード、フォルダ、ツール呼び出し、そのほかモデルへ渡したコンテキスト全体に対して発生する。しかも各チャットタブは独立したコンテキスト履歴を持つため、長い会話を一つのタブに積み増し続けると、同じ前提を繰り返し背負う。月額課金ユーザーが上限に当たりやすいのは、この構造を理解しないまま「大きなフォルダを渡す」「長い会話を継続する」「毎回同じ指示を書く」を重ねるからである。

本稿の結論を先に置く。`.cursor/rules` を短く分割し、探索は Ask、編集は Agent、タブは一案件一目的、`@Folders` の Full Folder Content は例外運用に切り替えるだけで、典型的なマルチファイル改修ではトークン消費を約40%圧縮しうる。以下ではその根拠を、Cursor 公式ドキュメントに基づく実装パターンとして整理する。なお「40%」は、公式の token accounting ルールに沿って構成した具体ワークフローの試算値であり、全ユーザー一律の実測値ではない。

なぜ Cursor はすぐ重くなるのか: 消費されるのは文章量ではなく「渡した状態総量」である

Cursor の Models ドキュメントは、コンテキストウィンドウを「入力と出力を含め、モデルが一度に考慮できるトークン全体」と説明している。そして各チャットは独自のコンテキストを保持する。つまり、過去の会話、添付ファイル、応答、ルール、追加したフォルダが蓄積されるほど、次の1回も重くなる。価格面でも、Cursor の Team Pricing と Usage ドキュメントは、Max Mode では入力・出力・キャッシュを含めたトークン量で消費が決まり、ダッシュボードで token breakdown を見られると明示している。

この仕様から分かるのは、トークン最適化の第一歩が「短く質問すること」ではなく、状態総量を小さく保つことであるという点である。例えば、同じ「バグを直してテストも更新してほしい」という依頼でも、次の二つはコストが大きく違う。

依頼方法 Cursor が背負うもの 消費傾向
1つの長い Agent タブで、@Folders に大きなディレクトリを付けて進める 会話履歴、関連外ファイル、前段の試行錯誤、ツール出力 高い
Ask で候補ファイルを絞り、新しい Agent タブで必要ファイルだけ渡す 最小限の履歴と対象ファイル 低い

さらに `@Folders` は設定次第で Full Folder Content を有効化でき、公式 docs はこれが有効な場合、フォルダ内ファイルの内容をできる限り丸ごとコンテキストへ含めると説明している。大規模フォルダでこれを常用すれば便利である反面、Max Mode ではそのまま高コスト化する。Cursor が「賢く見える」瞬間ほど、裏では多量の状態が注入されていると理解すべきである。

したがって、トークン節約は次の順で考えるのが妥当である。ルール化できる反復指示を切り出す、関連ファイルだけを選ぶ、会話を分割する。この順序を逆にすると、いくらモデルを替えても焼け石に水になる。

`.cursorrules` ではなく `.cursor/rules` を設計する: 長い共通プロンプトを毎回打つ運用をやめる

2026年3月4日時点の Cursor Rules ドキュメントでは、Project Rules は `.cursor/rules` に置くのが推奨であり、`.cursorrules` は「still supported, but deprecated」である。加えて、Rules は適用されるとモデルコンテキストの先頭に含まれる。ここが実務上の分岐点である。毎回同じ開発規約をチャット本文に書く運用は非効率であり、逆に巨大なルールを常時適用する運用もやはり無駄である。ルールは短く、役割別に分割し、必要時だけ付与される構造にすべきである。

Cursor は `Always`、`Auto Attached`、`Agent Requested`、`Manual` の4種をサポートする。トークン最適化の観点では、全部を `Always` にするのが最悪である。最も再利用しやすいのは、次のような三層構成である。

層 置き方 役割 分量の目安
中核ルール Always 出力形式、禁止事項、レビュー姿勢など全案件共通の短い契約 10〜20行
技術別ルール Auto Attached app/** や *.test.ts など対象ファイルにだけ自動適用 20〜40行
作業手順ルール Manual または Agent Requested リリース手順、移行手順、例外運用など頻度の低い文脈 必要最小限

この設計だと、毎回チャットで「TypeScript は厳格に」「テストを更新」「既存デザインを壊さない」「不用意にリネームしない」と打ち直す必要がない。一方で、Rules ドキュメントはベストプラクティスとして「ルールは500行以内」「大きなルールは分割」と勧めている。つまり、ルールはメモ帳ではなく、繰り返し使う短い実行契約として扱うべきである。

AGENTS.md はこの観点で有用である。公式 docs は `AGENTS.md` を `.cursor/rules` の簡易代替として位置づけている。チームが MDC メタデータまで要らず、まずは「この repo で Cursor に何を守らせるか」を素早く定着させたいなら、AGENTS.md で共通方針を書き、細かな自動適用だけ `.cursor/rules` に逃がす構成が実用的である。

コンテキストを絞る: Ask で探索し、Agent で編集し、`@Folders` は原則として最後に使う

Cursor の Modes ドキュメントでは、Ask は読み取り専用の探索、Agent は自律探索と複数ファイル編集を担う。ここから導ける最も実践的な原則は、探索フェーズと編集フェーズを分けることである。旧来の「Composer vs Chat」論争を現行 UI に落とすなら、「いきなり Agent で大きく触らず、先に Ask で候補ファイルと変更方針を固める」が正しい。

実際には、次の順番が安定する。

  1. Ask で「この変更に関係するファイルを3〜5個だけ挙げて」と依頼する。
  2. 返ってきた候補から @Files で必要ファイルだけを明示投入する。
  3. 新しい Agent タブで「この4ファイルだけを編集対象にして」と範囲を固定する。
  4. 追加変更が別論点になったら新規タブへ切る。

これは単なる好みではない。`@Files & Folders` ドキュメントは、ファイル単位参照とフォルダ単位参照を分け、Full Folder Content が有効なフォルダ参照は大きなコスト増を招くと明示している。したがって、@Folders は「全体監査」「広域リファクタ」「探索の入口」に限り、通常改修では @Files を優先するのが合理的である。

加えて、Codebase Indexing と Ignore Files のドキュメントは、`.cursorignore` と ignore 設定でインデクシング対象を制御でき、大きな無関係コンテンツを除外すると精度が上がると説明している。 monorepo では特に、生成物、巨大なログ、スナップショット、ベンダー化した成果物、古い設計書を除外するだけで探索ノイズが減る。これは精度改善であると同時に、不要なファイルを Agent が拾いにくくするため、結果としてトークン節約にも効く。

ただし、Ignore Files の docs には重要な但し書きがある。`.cursorignore` はインデクシングや `@` 参照、Tab/Agent/Inline Edit からのアクセスを制御するが、Agent が起動する terminal や MCP サーバーのツール呼び出しまでは完全には遮断しない。よって、秘密情報の保護は `.cursorignore` だけに頼らず、実ファイル配置、権限分離、環境変数管理を別途行う必要がある。この点を見落とすと、節約のつもりで巨大な秘密ファイルを除外しても、別経路で触られる設計が残る。

マルチファイル編集と長い会話の扱い: 1タスク1タブ、長くなったら `/summarize`、必要なら Background Agents

Cursor の Tabs ドキュメントは、各タブが独立した会話履歴、コンテキスト、モデル選択を持つと説明している。ここから逆算すると、トークン節約の基本は「全部を一つのタブでやらない」である。1つのタブにバグ解析、実装、テスト、レビュー、ドキュメント更新まで積み上げると、後半の小さな修正でも前半の長い履歴を背負う。

推奨パターンは次の通りである。

  • タブA: Ask で調査だけ行う。
  • タブB: Agent で実装だけ行う。
  • タブC: テスト補修やレビュー観点だけを扱う。

Tabs の docs は、他タブや過去セッションの文脈を `@Past Chats` で参照できるとしている。したがって、完全にゼロから説明し直す必要はないが、必要な要約だけを引く設計にできる。これが「長い1本の会話」を「短い複数会話」へ置き換える鍵である。

それでも会話が長くなった場合、Summarization ドキュメントにある `/summarize` を早めに使うべきである。Cursor は長い会話を自動要約するが、重要な節目で手動要約した方が、以後の前提が整理されやすい。特に、実装方針が固まった後、詳細な探索ログや迷走した案はノイズになりやすい。「決定事項を残して探索ログを圧縮する」のが `/summarize` の正しい使い方である。

マルチファイル編集をさらに分離したい場合、Background Agents も候補になる。公式 docs では、Background Agents は隔離された Ubuntu ベースのリモート環境で非同期に動作し、API は1つの API key あたり最大256アクティブエージェントをサポートするとされる。ただし、これは並列性と分離性を高める機能であって、トークン消費そのものを魔法のように減らす機能ではない。使いどころは、長時間タスクを本体チャットから切り離し、主会話の文脈肥大を防ぐことである。

40%削減の試算: 月額課金ユーザーが再現しやすい運用パターン

以下は、Cursor の Max Mode pricing、context window、tabs、rules、files/folders の仕様に基づく試算である。対象は、中規模の TypeScript リポジトリで、API ハンドラ、UI、バリデータ、テストの4〜6ファイルにまたがる修正を1件行うケースである。数値は説明用の概算だが、どこで差が出るかは実務に近い。

運用 主な流れ 概算トークン
非最適化 1つの Agent タブで開始し、@Folders の Full Folder Content を有効化。会話を継続しながら実装・テスト・説明まで同一タブで処理 約182k
最適化 Ask で対象ファイルを絞る。新規 Agent タブで @Files を4件だけ投入。ルールへ共通指示を外出しし、節目で /summarize。テスト更新は別タブ 約108k

この差は約40.7%である。内訳として大きいのは次の3点である。

  • 同じ共通指示を毎回本文へ書かない: 反復指示をルールへ移す。
  • フォルダ全体ではなく必要ファイルだけを渡す: Full Folder Content を常用しない。
  • 長い会話を分割する: 一案件一タブ、節目で要約する。

月額課金ユーザーがまず試すべき実装パターンは、極論すると次のテンプレートで十分である。

1. Ask:
「この変更に関係するファイルを最大5件、理由付きで挙げて」

2. Agent新規タブ:
「対象は @files のみ。不要な横展開はしない。
ルールに従って最小差分で実装し、最後に変更点と未解決点を要約して」

3. 節目:
/summarize

4. テスト専用タブ:
「実装は触らず、失敗テストの修正だけ行う」

Cursor の token burnout は、モデルの豪華さを落とさないと解決できない問題ではない。むしろ、探索、編集、検証、要約を混ぜないこと、そして永続指示は Rules へ、都度状態は最小限の Files へという設計へ移すことで、月額課金の上限問題はかなりの範囲で技術的に緩和できる。Cursor を重い道具にするか、鋭い道具にするかは、プロンプトの文才ではなくコンテキスト設計で決まる。

FAQ

.cursorrules を使い続けてもよいのか

使えはするが、2026年3月4日時点の公式 docs では `.cursorrules` は legacy であり、推奨は `.cursor/rules` である。新規運用なら Project Rules へ寄せた方がよい。

トークン節約のために Ask だけ使うべきか

そうではない。Ask は探索に向き、Agent は実装に向く。最も無駄が少ないのは、Ask で対象を絞ってから Agent に渡す二段構えである。

`@Folders` は使わない方がよいのか

全面禁止ではない。広域監査や構造把握には有効である。ただし Full Folder Content は Max Mode で高コストになりやすいため、通常改修では `@Files` 優先が安全である。

`.cursorignore` を設定すれば秘密情報は完全に守れるのか

完全ではない。公式 docs でも、terminal や MCP 由来のツール呼び出しは別である。秘密情報はファイル配置、権限、環境変数分離を併用して管理すべきである。

長い会話を続けるか、新しいタブを切るか迷う

目的が変わった時点で新しいタブを切るのが原則である。実装からテスト、レビュー、ドキュメント更新へ論点が移ったら、同一タブ継続より分割の方がトークン効率も再現性も高い。

参考文献