Cursor の AI コーディング統計データに関する興味深い分析

こんにちは、Pragmatic Engineer ニュースレターの特別無料号をお届けします。Gergely です。毎号、シニアエンジニアやエンジニアリングリーダーの視点から、ビッグテックとスタートアップを取り上げています。今回は、過去の『The Pulse』記事 4 本のうち 1 つを再掲しています。フルサブスクライバーには、5 週間前に以下の記事を配信しました。このメールを転送された方は、こちらから購読できます。

Cursor は過去 2 年間の集約利用データに基づいた新しいレポートを発表し、いくつかの興味深い発見がありました：

パワーユーザーは、中央値と比較してコード行数が 10 倍生成します

image出典：Cursor

Cursor を使用している開発者の中央値（p50）は、週あたり約 700 行のコードを生成しますが、上位 90 パーセンタイル（p90）では約 9,000 行に達します。

上位 1% のユーザーが驚異的な量のコードを作成

p99 データは非常に印象的です：

imageCursor ユーザーの上位 1%（p99）と上位 10%（p90）

Cursor ユーザーの上位 1% は、週あたり約 3 万〜4 万行のコードを生成します！これは、同じ期間に「中央値」の開発者約 45 人が生成する量に相当します。

これらの上位 1% のユーザーがどのように異なるのかを問う価値があります。彼らはグリーンフィールドコードをより多く書いているのでしょうか、ライブラリを使用しない傾向があるのでしょうか、リーダーボードの上位にランクインするためにトークン数を最大化しているのでしょうか？それともバグを 45 倍も生成しているのでしょうか、そして何よりも重要なのは、彼らがリリースするソフトウェアで多くのビジネス価値を生み出しているのでしょうか？

Cursor は、出力トークンの数に対して入力トークンを 10 倍消費します。

これは驚くべきことです：Cursor のトークン使用量の 90% が入力トークスです！つまり、使用されるトークンの大部分は既存のコードベースとドキュメントを読むために使われています。コードの生成は少数派の使用法に過ぎません：

image 入力トークン（コードベースを読むための Cursor）がトークン使用量の大部分を占めています

ある意味で、この使用法は理にかなっています：開発者として、私たちがタイピングしたコード行数と比較して、コードを読むことに費やす時間は常に遥かに多かったです。「読み書きの比率 10:1」というのは古典的な知見です。2008 年、ロバート・C・マーティン（通称「アンクル・ボブ」）が著書『クリーンコード』でこの観察を共有しています：

「確かに、読むことと書くことに費やす時間の比率は 10:1 を遥かに超えています。私たちは新しいコードを書く努力の一環として、常に古いコードを読み続けています…[したがって] 読みやすくすることは、書きやすくすることにもつながります。」

AI エージェントにおけるトークン使用の「読み書き比率 10:1」が今になって現れていることに、私は面白さを感じています。

入力トークスが主な AI トークンコストとなる

入力トークンは出力トークンの一部のみで価格設定されています：例えば、Opus 4.7 は出力トークンに対して入力トークンの 5 倍の料金を請求します（100 万トークンあたり入力トークンで 5 ドル、出力トークンで 25 ドル）。それでもなお、入力トークンがトークン使用量の大部分を占めているため、Cursor では AI コーディングエージェントのコストのうち入力トークンが約 70% を占めています：

image 入力トークンが Cursor のコストを支配する

コンテキストのキャッシュを使用しない場合、トークンコストは 10 倍になります

Cursor は、新しい入力トークンを追加しても古いコンテキストを再生成しないよう、文脈のスマートなキャッシング（cache）を実装しています。このキャッシュ利用を考慮すると、Cursor が出力トークンに費やすのはトークンのわずか 0.6% に過ぎません。残りの 99% は、キャッシュ読み込み（90%）、キャッシュ書き込み（2.5%）、および入力トークン（7%）の間で配分されています：

image キャッシュ読み込みと書き込みを考慮すると、出力トークンはトークン使用量のわずか 0.6% に過ぎません

将来、コンテキストの再利用やキャッシングが AI の効率化における重要な要素となるでしょうか？AI トークンの生成にはコストがかかるため、どのような形での再利用も非常に理にかなっています。特に、既存の文脈を多く再利用するコーディングのようなワークフローではその傾向が強まります。

もちろん、Cursor がこの詳細を共有しているのも理にかなっています。なぜなら、効率的な AI エージェント・ハネス（harness）の構築は決して簡単なことではないと、全員に思い出させるからです。実際、独自のエージェント・ハネスを開発する場合も、Cursor のようなツールの効率性に匹敵する効率的なキャッシング層（caching layer）を整備する必要があります。

Opus は最も高価なモデルであり、Anthropic に悪影響を与える可能性も

公開時点では、Opus 4.7 が最も能力の高いコーディング・モデルと見なされていました。しかし、非常に高価でもあり、Cursor の自社データによると、同社の Composer 2.5 モデルと比較して約 10 倍の費用がかかることが示されています：

imageOpus 4.7 は GPT-5.5 の約 2 倍の費用がかかり、Composer 2.5 と比較するとほぼ 10 倍です。Cursor が単一のエージェント・リクエストのコストを比較している点は重要です。これはトークン同士の直接比較ではありません。また、このベンチマークを共有しているのが Cursor である点にも注意が必要です。Cursor には、自社の Composer モデルが最も低コストに見えるよう動機があるからです。

それでも、10 分の 1 の費用で同等の十分な結果が得られると仮定すれば、これは無視できない節約になります。特に中規模以上の企業にとってはなおさらです。より多くのテック企業が、重要度の低い作業には能力は劣るものの安価なモデルをデベロッパーに使用する方法を見つけることになっても驚きません。

高価なモデルほど採用率が高くなる

Cursor が共有する興味深い指標の一つが、モデルごとの「追加行あたりのコスト」です：

この指標は出力と相関するより現実的なコストです。「賢い」モデルは高価ですが、生成したコードが頻繁に採用される場合、エージェントリクエストあたりのコストという指標ではペナルティを受けますが、ここではそのような扱いを受けていません。

実際、Opus 4.7 は、GPT-5.5 と同じ「1 行あたり採用されたコードのコスト」を持ちながら、エージェントリクエストあたりのコストは半分です。この比較において、Cursor の Composer モデルは「わずか」5 倍の効率性しか持っていません。

両方のリストから欠落しているのは Google の Gemini モデルで、これは Cursor による奇妙な省略です。私は Cursor に問い合わせたところ、Gemini が除外された理由は単に、同社のプラットフォーム上でこのモデルの使用頻度が極めて低いこと、および同様に使用頻度の低い Grok モデルと同様の状況であるためだと説明を受けました。

開発者が手動レビューなしで AI による変更をほぼ半数が採用

私は最も興味深い部分を最後に残しました：わずか 1 か月で、Cursor を使用する開発者の間で、AI エージェントが手動ステップを経ずにコミットを作成することを許可していた割合は 10% から、開発者自身がコードを直接確認しなくなった人が約 40% にまで増加しました。

この急増は、Opus 4.7 と GPT-5.5 のリリース時期と一致しており、多くの開発者がこの世代のモデルによるコード生成能力を実感した結果、「手動でコードを書くことは死に絶えている」と結論付けた時期とも重なります。

詳細は Cursor の完全版レポートをご覧ください。このデータを公開してくれたチームに感謝します！

この抜粋が含まれる『The Pulse』の完全号をお読みいただくか、今日の最新号をチェックしてください。今日の号では以下を取り上げています：

Fable による Bun の Rust 書き換えから何を学べるか？

Anthropic の Fable、OpenAI の GPT-5.6 Sol、Cursor の Grok 4.5、Meta の Muse

北朝鮮のハッカーがフルリモート企業への侵入を試み続けています

業界パルス：Meta のキーロギングで機密データが露見、Xbox で大規模な人員削減、Google から十分な AI 容量を確保できなかった Meta、Qualcomm が Modular を買収、メモリ価格の高騰が Apple 製品に打撃。