Cursorは開発者の効率を低下させるのか？

こんにちは、Pragmatic Engineer Newsletter の特別無料号をお届けするゲルゲーです。毎号、シニアエンジニアやエンジニアリングリーダーの視点から、ビッグテックとスタートアップについて取り上げています。今回は先週の「The Pulse」号で扱った4つのトピックのうち1つを取り上げます。この記事を7日前にフルサブスクライバーにお送りしました。このような記事を毎週あなたのメールボックスにお届けするには、こちらから購読してください。 多くの購読者が、このニュースレターを学習・開発予算として経費処理しています。そのような予算をお持ちの場合は、上司に送れるメールの例をご紹介します。 非営利団体「Model Evaluation and Threat Research (METR)」が興味深い研究を発表しました。この研究では、大規模なオープンソースリポジトリで作業した経験豊富な開発者 16 名を募集し、実在する 136 の課題を修正させる実験を行いました。報酬は時間あたり 150 ドルです。一部の開発者には AI ツールの使用が割り当てられ、他の開発者には割り当てられませんでした。研究では開発者の画面を記録し、その後 146 時間にわたる映像を検証・分析しました。 その結論は以下の通りです： 「驚くべきことに、開発者が AI ツールを使用すると、使用しない場合に比べて所要時間が 19% 長くなることが分かりました。AI は彼らを遅くするのです。(…) この認識と現実の間のギャップは際立っています。開発者は AI が自身の作業速度を 24% 向上させると予想していましたが、実際に速度低下を経験した後でも、なお AI が 20% の加速をもたらしたと信じていました。」 この結果は非常に驚くべきものです！しかし、何が起きているのでしょうか。研究論文を注意深く見てみましょう： この研究は、Cursor が開発者の生産性に与える影響についてのものである。参加者のほぼ全員が選択した AI ツールは Cursor であり、Sonnet 3.5 または 3.7 を使用していた。開発者のうち 44% はこれまで Cursor を一度も使ったことがなく、残りの多くも最大で 50 時間程度しか利用経験がない。 AI を活用したグループは、作業完了のためにコーディングに要する時間は短縮されたものの、全体としてはより多くの時間を要した。また、調査やテストに費やす時間も減少していた。しかし、AI の待機、その出力のレビュー、「IDE オーバーヘッド」、およびプロモーションには、AI を使用しないグループよりも長い時間がかかっていた。最終的に、この研究では、AI に費やされた追加時間が、コーディング・調査・テストで節約された時間を相殺してしまったことが明らかになった。 この発見は Cursor に限らず、すべての AI ツールに当てはまることを指摘しておく必要があります。本調査では単に Cursor が選ばれただけのことです。 ![image](https://blog.pragmaticengineer.com/content/images/2025/07/image-1.png)AI を利用することでコーディングにかける時間は短縮されましたが、全体としては作業に要する時間が長くなりました。出典：METR 開発者は AI の生産性への影響について、少なくとも初期段階では楽観的な見積もりをしがちです。調査より: 「専門家も開発者も、ツールを何時間も使用した後も、AI が開発者の生産性に与える有用性を過大評価しています。これは、専門家の予測や開発者へのアンケートに頼るだけでなく、堅牢な成果指標を用いた現場実験を行うことの重要性を浮き彫りにするものです。」 Cursor を 50 時間以上使用した一人の開発者は、著しい速度向上を実感しました！この研究では、過去に Cursor を合計 50 時間以上使用した開発者が一人だけ含まれていました。その開発者は、非常に印象的な 38% の速度向上を達成しています。しかしながら、サンプルサイズが一人だけでは、16 人のグループ全体を代表するものとしてはあまり適切ではありません： ![image](https://blog.pragmaticengineer.com/content/images/2025/07/image-2.png)Cursor で 50 時間以上の経験を持つ一人の開発者が、はるかに速く作業を完了しました。出典：METR ソフトウェアエンジニアのサイモン・ウィリソン氏（私は彼を AI 開発ツールに関する中立的な専門家とみなしています）はこの調査結果を以下のように解釈しています： 「私の直感では、この研究は主に、AI 支援開発の学習曲線が十分に急峻であることを示していると考えられます。つまり、既存のワークフローにそれを組み込むよう開発者に求めることは、その学習曲線を登っている間、彼らのパフォーマンスを低下させることになるのです。」 確かに、彼は『Pragmatic Engineer』ポッドキャストのエピソードでも同様の指摘を行っています：「習得し、探索し、実験し、使い方を学ぶために、非常に多くの努力を払わなければなりません。そして、何のガイダンスもありません。」 本誌が実施した AI ツールに関する研究（約 200 人のソフトウェアエンジニアからの入力に基づく）でも、これを裏付ける証拠が見つかりました：AI ツールを 6 ヶ月以上使用していない開発者は、それらに対して否定的な認識を持つ傾向が強かったのです。AI ツールを使用しなかったエンジニアから非常に頻繁に寄せられたフィードバックは、「試してみたが期待に応えなかったのでやめた」というものでした。 非 AI デベロッパーと比較して 38% の「速度向上」を報告したエンジニアは、興味深い見解を持っています。Cursor を 50 時間以上使用しているこの一人のエンジニアは、博士課程学生であるクエンティン・アンソニー氏です。彼がこの研究について語ること、そして AI ツールがデベロッパーの効率にどう影響するかを以下に示します： 「1. AI による速度向上は、誰かのデベロッパーとしての能力と非常に弱い相関しかありません。この研究に参加したすべてのデベロッパーは非常に優秀です。私はむしろ、LLM（大規模言語モデル）の能力における失敗モードや、人間のワークフローにおける失敗モードに陥っていることの方が関係していると思います。私は素晴らしい事前学習済みデベロッパーたちと多く働いていますが、人々は多くの同じ問題に直面していると信じています。 私たちは LLM をツールだと言いたがりますが、実際にはそれを魔法の弾丸のように扱っています。 実際に、難解な問題を最後にデバッグした時の満足感を、どのデベロッパーも証明できるでしょう。LLM は、一度であなたの問題を一挙に解決する可能性のある大きなドーパミンのショートカットボタンです。すべてを 1% の確率で修正するボタンを押し続けますか？少なくとも私にとっては、その過酷な代替手段よりもはるかに楽しいものです。 2. 今日の LLM は、能力分布が非常にスパイク状（偏在）しています。これは主に以下の要因によるものだと考えられます：どのようなコーディングタスクに対して大量のクリーンなデータがあるか、そして成功を測定するために LLM 研究所が使用しているベンチマークや評価指標です。 例として、LLM は低レベルシステムコード（GPU カーネル、並列処理/通信など）においてすべてひどく苦手です。これは、そのコードデータが相対的に稀であり、モデルの能力を評価することが難しいからです（この点についてはここでより詳しく議論しています）。 これらのタスクは、プリトレーニング開発者としての私の業務の大きな部分を占めているため、LLM が対応可能な部分（テスト作成、見慣れないコードの理解など）とそうでない部分（カーネル作成、通信同期セマンティクスの理解など）を把握しています。私は、LLM が確実にタスクを処理できると確信できる場合のみそれを使用します。 新しいタスクが LLM に対応可能かどうかを判断する際、私は LLM との作業に時間を過度に費やしてしまわないよう、積極的にタイムボックスを設定するように心がけています。"もうすぐ完成しそう！"という瞬間から LLM から離れるのは難しいものです！ 3. LLM が生成を行っている間の待ち時間に気が散りやすいことです。ソーシャルメディアの注目を集めるための経済競争は過酷であり、人々は 30 秒程度の生成を"待っている間"に 30 分もスクロールしているのだと思います。 これについては一言だけ言えるのは、私たちは自分自身の落とし穴を知り、LLM の生成時間を生産的に活用するよう努めるべきだということです。もしタスクが高集中力を必要とするものであれば、この時間はサブタスクに取り組むか、次の質問について考える時間に充ててください。モデルが私の質問にワンショットで回答したとしても、まだ理解できていないことは何があるでしょうか？もしタスクが低集中力で済むものであれば、その間に別の小さなタスク（メールや Slack の返信、他の段落の読書や編集など）を行ってください。 いつも通り、デジタル衛生に関する小さなステップ（ウェブサイトブロッカー、電話を DND モードにするなど）がこれに役立ちます。おじさんくさいようですが、私には効果があります :)" クエンティンは結論としてこう述べています： 「LLM はツールであり、その落とし穴を学び始め、自己認識を持つ必要があります。アンドレイ・カルパティ氏の講演が多くの人の支持を得ている大きな理由は、彼が非常に内省的な LLM ユーザーであるからです。これは、一部のモデルの事前トレーニング（pretraining）に関与したことで、やや早く到達した結果です。 この新しいツールをうまく使いこなすためには、その欠点（そして私たち自身の欠点！）を理解し、それらに適応する必要があります。」 AI コーディングツールの弱点が「コンテキストスイッチ」になるのではないかと思っています。開発者として最も生産的な作業ができるのは、「ゾーン」に入っている時です。問題に没頭し、一切の気晴らしがない状態で、仕事に集中している時です。一度その状態から外れた後、再びゾーンに戻るのにどれほどコストがかかるかを知っています。 しかし、時間節約型の AI コーディングツールを使用している間は、その「ゾーン」にいることはできません。コードが生成されている間に別のことをしなければならないため、コンテキストスイッチ（context switch）を強制的に行わなければならず、それぞれが私の速度を遅らせます。それは気晴らしです。 もしコードを書く際の「ゾーン」にいるという制約が、バグではなく機能であるとしたらどうでしょうか？また、AI ツールを使用しない経験豊富な開発者が、意識的に「ゾーン」に留まり、より集中することで、AI を使用する他の人々よりも優れた成果を出しているとしたらどうでしょうか？AI ツールによって繰り返されるコンテキストスイッチを強いられている開発者よりも、AI ツールを使用していない人々が「ゾーン」にいて、より高いパフォーマンスレベルで作業していた可能性はないでしょうか？ ソフトウェア構築において、コーディングに要する時間が節約されたからといって、自動的に生産性が向上するわけではないという点について、考えるべきことがここにあります。 これは先週の『The Pulse』から取り上げられた4つのトピックのうちの一つです。今回の完全版では以下も扱っています: 業界の動向。1.1.1.1 が1時間ダウンした理由、マイクロソフトがより多くの GPU を購入するために人員削減を行った件、メタの驚異的な AI データセンターへの支出、そして北朝鮮からの偽物の求職者という「業界全体の問題」について。 Windsurf の売却：OpenAI、Microsoft、Google、Cognition による複雑な物語。OpenAI は Windsurf を買収したかったが、マイクロソフトの存在により実現しなかった。その後 Google が Windsurf の創設者とコアチームを雇用し、Devin の開発元である Cognition が残りの会社を買収しました。これはカリフォルニア州でなければ起こり得ない奇妙な物語です——非競争条項禁止法があるおかげで。 VC（ベンチャーキャピタル）に依存したトークンの終焉の始まり？Cursor は、その「無制限」プランに対して制限を黙って課すことで開発者を怒らせました。私たち開発者は、LLM（大規模言語モデル）の利用コストが高騰しており、VC からの資金がトークンの実質的なコストを補助し続けることはおそらくないという現実に向き合わされています。 今週の『The Pulse』誌（フルサブスクライバー向けに配信）では以下を取り上げています: 6月10日の障害の原因に関する謎が解明されました。Heroku は Ubuntu Linux 上の systemd プロセスの更新により1日間ダウンしました。実は OpenAI、Zapier、GitLab など数十社も同様の影響を受け、最大6時間にわたる障害が発生していました。 Replit AI が本番環境を秘密裡に削除 – おっと！バイブコーディングアプリがまだ本番対応していない理由の教訓から、ソフトウェアエンジニアリングの専門知識を伴わずに出荷される本番耐性のあるアプリを予測することがいかに困難かが浮き彫りになる。 業界の動向。Windsurf の売却に関する最新詳細、Zed エディタがすべての AI 機能をオフにできる機能の実装、Microsoft SharePoint を使用している政府機関がハッキングされた件、GitHub がバイブコーディングツールをリリースした件など。 OpenAI で過ごした1年への考察。ソフトウェアエンジニアの Calvin French-Owen は OpenAI に対する自身の印象をまとめ、同社が Slack と Azure で運営されている様子、OpenAI Codex のローンチにおけるキャパシティプランニングの課題、大規模な Python コードベースでの作業から得た教訓などについて語っている。 The Pulse の各号はこちらで読むことができる。

Cursorは開発者の効率を低下させるのか？

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト

背景や根拠まで確認しますか？

関連記事

ニュースの次に確認する

調べる

選ぶ

サイト