「同じAIモデルで請求額が29倍差」Cursorの使用額非表示化とツール間トークン消費の格差

「同じAIモデルで請求額が29倍差」Cursorの使用額非表示化とツール間トークン消費の格差

aiコーディングコストcursor

データソース:HN + web research · HN

8月1日、人気のAIコーディングツールが静かに設定を変更し、ユーザーが自分が実際にいくら消費したかを確認できなくなった。

そのツールは「Cursor」。ここ2年で最も注目されているAIプログラミング助手の一つで、エディタ上で日本語や英語の自然言語で要望を伝えるだけでコードを修正してくれる。ユーザーは月額20ドルのサブスクリプションを支払い、定額枠を超えた分は従量課金される仕組みだ。以前の使用量ページには、当月消費した「文字数(トークン数)」と「換算金額」の双方が表示されていた。しかし8月1日、金額欄が消え数字のみとなり、CSV出力した請求データからも金額列が失われていることがユーザーによって発見された。

「毎日このページで支出をチェックしていたのに、今日突然金額がトークン数に変わってしまった」とCursor公式フォーラムに投稿された。このトピックはすぐにプログラマーコミュニティHacker Newsに転載され、24時間以内に291ポイントの支持と125件のコメントを集めた。数百ポイントはこのコミュニティで爆発的とまでは言えないが、多くのエンジニアの日常的な痛みを突いていた。「自分のAI利用料金がどう計算されているか誰も明確に説明できない」という問題だ。Cursorのスタッフを名乗るアカウントが回答に訪れ、アカウント全体の使用額ページでは引き続き課金を確認できること、CSV出力の金額欠落は「旧機能の整理時に誤って破損したもので修正済み」であること、そして金額グラフについては「定額枠内の利用価値を実際の請求額と誤認するユーザーがいたため削除した」と説明した。

Cursorの支出ページスクリーンショット 図:議論の中でユーザーが投稿した支出ページ——使用量データのみが表示され、対応する金額が見当たらない。出典:pasteboard.co

この説明で疑問が完全に解消されたわけではない。ユーザーからは、コンテキスト使用量の横にあった円形のコストインジケータも一緒に撤去されたとの指摘が上がった。「高額なモデルを誤って有効にしたままにしても、定額枠を使い切るまで気づけなくなった」。これら二つの変更は同じ方向を指している。ユーザーは「使用量」を見ることはできるが、「使用量」を「金額」に換算することが著しく困難になったのだ。

まさに同じ日、さらに衝撃的な実測データがコメント欄に登場した。toshという開発者が、同一のLLMモデル、同一の仮想マシン上で、全く同じ10個のタスク(ファイルのチェックサム計算、スプレッドシートの統合、ビルドパイプラインの修正)を、6種類の異なるAIコーディングツールを使って実行した。結果は、最も効率的なツールが17.3万トークンしか消費しなかったのに対し、最も消費の激しいツールは507万トークンを消費し、その差は29倍に達した。すべてのツールがタスクを正常に完了しており、成果物の品質に違いはなく、違いはコストだけであった。

トークン消費量実測比較表 図:同一モデル・同一タスクによる6ツールの使用量実測比較——最小17.3万、最大507万トークン。出典:news.ycombinator.com

この背景を理解するために2つの用語を整理する。トークンとはAI課金の最小単位であり、おおまかに「文字数」と理解できる。AIは応答を生成するたびに、ユーザーの質問、ツールの仕様書、過去の対話履歴全体を再読み込みする必要があり、読み込んだ文字数すべてに対して料金が発生する。そしてここでの「ツール」とは、AIモデルを包む外枠全体——システムプロンプト、ツール一覧、メモリファイル、プロジェクト設定、対話に挿入される各種中間生成物を指す。

この29倍という大差が意味するのは、「モデル自体が高いのではなく、ツールによるモデルの使い方が高い」ということだ。データを詳細に見ると、6つのツールが「書き出した」出力トークン数はどれもほぼ同等(3万〜5万トークン)であり、差のほぼすべては「読み込ませた」入力トークン数に起因していた。最も節約志向のツールはシステムプロンプトすら持たずモデルにターミナルのみを提供していたのに対し、最も消費の激しいツールは「記憶システム」だけで1万字を超え、毎ターンの対話にそれをそのまま付加していた。あるユーザーの試算では、こうした初期プロンプトだけで単一タスクのコストが倍増するという。

大量のコンテキストを詰め込むことは、コスト高につながるだけでなくパフォーマンスも低下させる。LLMの動作スペース(コンテキストウィンドウ)には上限があり、現在は数十万から100万トークン程度が主流だ。コンテキストが一杯になると、ツールは過去の対話を要約圧縮(詳細が失われハルシネーションの原因となる)するか、コンテキストをリセットせざるを得ない。さらに興味深いことに、あるコメント者は「一見親切に見える補助資料がモデルの思考を脱線させ、余計な推論ステップを踏ませて処理を遅くさせる」と指摘している。

もちろん、29倍という数値は極端な検証条件下での上限であり、すべてのユーザーの日常的な請求に当てはまるわけではない。大型ツールの投入する資料の多くはプロンプトキャッシュにヒットし、キャッシュ利用時は単価が最大9割安くなるという反論もある。一方、極減ツールはキャッシュ有効化の閾値(1024トークン未満)に達する前に処理を完了するため、割引を受けられない場合がある。実測者本人も、自身の簡易ツールは複雑なタスクのオーケストレーション能力に欠けると認めている。これらの指摘は妥当であるが、「同一作業のトークン消費量は、ユーザーの需要ではなくツールの設計に左右される」という構造的事実は変わらない。

プログラミングをしない一般ユーザーにとっても、この出来事は重要だ。AI時代において、課金単位は「目に見える金額」から「目に見えない文字数(トークン)」へと移行しつつある。サブスクリプション枠は本質的にトークンのプールであり、超過分は従量課金される。ツールベンダーが画面から「金額」を消し「トークン数」のみを残すとき、ユーザーは他ツールとの価格比較能力を失う。同じ作業でもツール次第で数十万トークンで済むこともあれば数百万トークンかかることもあり、自分がどちらに属しているか判断できない。あるユーザーの計算によれば、API原価ベースで月額100ドルのプランで消費されたトークンは約5000ドル分に相当していた。サブスク価格がコスト原価と乖離している以上、ツールベンダーがプロンプトの無駄を削減する動機は薄い。

Cursor側はCSV出力の不具合は修正済みとしているが、金額グラフが戻ることはない。議論は続いており、自身で軽量なツールを自作し始める開発者も現れている。観察者にとっての教訓は明確だ。請求書の中身が見えにくくなったとき、余分に支払っている費用はまさにその「不透明さ」の中に隠されているのだ。

参考リンク:

  • Cursor 公式フォーラム:Usage page to token amount
  • HN 議論 (item?id=49135257)
  • 実測者 tosh の X 投稿(比較データ)