Cursorはソフトウェア開発を加速する？導入後の実態に迫る

本記事では、LLMエージェントアシスタント「Cursor」がソフトウェア開発に与える影響を検証した事例を紹介します。

Cursorのようなエージェント型ツールは開発現場で急速に広まり、期待と同時にコードの品質を不安視する声も根強くあります。

本記事では、GitHub上ののプロジェクトを分析し、Cursor導入の効果を因果的に検証した結果得られた発見を、実務でのヒントとあわせて見ていきます。

背景

LLMの活用がソフトウェア開発で急速に広まっています。

最初はGitHub Copilotのような「コード補完ツール」が主流でした。開発中に次のコード行を提案してくれる仕組みです。

その後登場した「LLMエージェントアシスタント」はさらに進んでいます。代表例のCursorは、プロジェクト全体を把握し、複数ファイルをまたいで修正やテストを自動で行います。単なる補助ではなく、開発全体を支える存在です。開発速度が「10倍になった」といった声もあります（あくまで個人の感想で、科学的な検証は少ないのが現状です）。

しかしLLM生成コードの品質には昔から懸念があります。例えばセキュリティやパフォーマンス、複雑さの問題。また、補完ツールやチャットツールは開発者が主導しますが、エージェントアシスタントは環境に統合され、自律的に大規模な変更を行います。

そのため、エージェント型ならではの影響を改めて検証する必要があります。

こうした状況から、LLMエージェントアシスタントの影響を、プロジェクト単位で長期的に検証する必要性が高まっています。そこで本記事では調査事例を取り上げます。

※この調査は下記に示す通り2025年の8月までのデータを扱っています。モデルや製品の進化や仕様の変更などに注意していただくようお願いいたします。

実際のプロジェクトを使って効果を検証

今回研究者らはCursorを導入すると開発速度やコード品質にどんな影響があるかを調べています。実際のプロジェクトデータを分析し、原因と結果の関係を明らかにする方法を取っています。

GitHubでCursorを導入した807のプロジェクトを特定

Cursorには設定ファイル（.cursorrulesや.cursorフォルダ）があり、開発者がそれをGitHubリポジトリに公開している場合があります。研究チームはGitHubの検索APIを使い、こうした設定ファイルを含むリポジトリを探しました。

2025年3月の時点で3,306件が見つかりましたが、この中には教育用の小規模プロジェクトやスパムも含まれていました。そこで、スター数（GitHubでの「いいね」）が10以上のものに絞り、実際に利用されているリポジトリだけを対象にしました。最終的に、2024年1月から2025年3月の間にCursorを導入した807件を特定しました。

これらのプロジェクトは規模も活動量もさまざまで、導入時期も月によってばらつきがありました。言語別では、TypeScript、Python、JavaScript、Go、Rustの5つが多く使われていました。

開発の速さとコードの質を、月ごとに追って比較

各リポジトリについて、2024年1月〜2025年8月の月ごとのデータを集めました。測定項目は「開発速度」と「コード品質」の2つです。

開発速度は、月ごとのコミット数（変更の記録）と追加された行数で見ました。どちらも一般的な生産性の指標で、数が多いほど活発な開発と見なされます。

コード品質は、将来の保守性に関わる「技術的負債」の観点から3点を測定しました。

いずれもSonarQubeという静的解析ツールで算出しています。

「導入前後の差」を使ってCursorの影響を見分ける

ただ「Cursorを使ったグループと使っていないグループを比較する」だけでは足りません。

なぜなら、Cursorを導入するプロジェクト自体に何らかの特徴がある可能性があるからです。

そこで経済学で因果関係を調べるときによく使われる方法「差分の差分法（Difference-in-Differences, DiD）」という手法が適用されました。

前と後の変化を比べて、Cursorの効果だけを測る

基本的な考え方はこうです。Cursorを使ったプロジェクト（処置群）と使っていないプロジェクト（対照群）を比べ、それぞれの導入「前後の変化」を計算し、その差をとります。これが「差分の差分」です。

たとえば、処置群の開発速度が導入後に20%増え、対照群は5%増えたとすれば、差の15%がCursorの効果と考えられます。対照群の変化は、業界全体の動きや季節的な影響とみなします。

特徴が近い1,380の比較用プロジェクトを選んで比較

ただし、Cursorを導入するプロジェクトは、もともと活発だったり成長中だったりする可能性があります。そうした違いがあると、単純な比較では正確な効果が分かりません。

そこで導入したプロジェクトに対して、特徴が似た導入していないプロジェクトを選ぶ方法を使用して調査が行われました。

最終的に、807の導入プロジェクトに対して、1,380の非導入プロジェクトが選ばれ、両者の特徴や導入前の動きがよく似ていることが確認されました。

導入時期のずれにも対応できる方法で、結果の偏りをなくす

研究チームは未導入プロジェクトのデータから「導入しなかった場合の結果」を予測しました。次に、導入済みプロジェクトで実際の結果との差を取り、それを効果としています。

また、平均だけでなく、導入後に時間とともに効果がどう変わるか（動的効果）もあわせて分析しています。

開発が速くなると質が下がり、質が下がると開発が遅れる流れも検証

指標どうしの相互の影響も考えた分析が行われました。

調べたのは次の4つです。

• コードの追加量が警告の数に影響するか
• コードの追加量が複雑さに影響するか
• 警告の多さが、あとから追加されるコードの量に影響するか
• 複雑さが、あとから追加されるコードの量に影響するか

Cursorの設定を公開しているプロジェクトだけが対象という制限あり

ただし、研究チームは、この手法に限界があることを認めています。まず、Cursorの設定ファイルを公開しているプロジェクトしか分析できず、実際の利用全体は捉えきれていません。また、設定があっても使用量は不明で、「導入した意思」の影響しか見ていない可能性があります。そのため、利用が多そうなプロジェクトに絞った追加分析も行われました。

さらに、使っているLLMの種類やCursorのバージョンも不明ですが、ツール全体の効果を見る目的には支障ないと考えられています。他のツールとの併用もあるため、Cursor単独使用との比較分析も行われました。対照群にもLLM利用が含まれる可能性があり、効果は「未使用」との差ではなく「追加導入」の差を示しているかもしれません。

そしてこの研究はオープンソースのみを対象にしており、企業内開発や他の言語には当てはまらない可能性があります。

それでも、現時点では最も包括的な評価の一つといえます。

最初は速くなるが、品質が落ちて速度も下がる懸念

それでは、分析の結果を見ていきます。上述したように、研究チームは、Cursorを導入した807のプロジェクトと、導入していない1,380のプロジェクトを比べて、開発の速さとコードの質への影響を調べました。

導入直後はコードの追加量が約3倍になるが、3か月後には効果が消える

まずは開発の速さについてです。全体として、Cursorを導入するとコードの追加量が平均で約28.6%増えました。ただし、コミットの回数には目立った変化は見られませんでした。

注目すべきは、その効果が時間とともにどう変わるかです。詳しく見ると、ある特徴がはっきりしてきます。開発が速くなるのは、導入後の最初の2か月間だけだったのです。

具体的には、導入1か月目にコミット数が55.4%、コードの追加量はなんと281.3%も増えました。2か月目もそれぞれ14.5%と48.4%の増加が見られました。しかし3か月目以降は、その効果がなくなり、統計的に意味のある伸びは確認できませんでした。

つまり、Cursorを使うと一時的に開発が加速しますが、その勢いは長く続かないということです。最初は大きく伸びても、すぐに元に戻ってしまうのです。

警告が3割増え、コードの複雑さも4割増えたまま続く

一方で、コードの品質には別の傾向が見られました。開発の速さとは違い、品質の悪化は長く続いていたのです。

コードの警告は平均で29.7%増えました。これは、保守や信頼性、セキュリティに関わる問題が増えたことを意味します。コードの複雑さも大きく、平均で40.7%も上がっていました。複雑なコードは読みづらく、ミスが入りやすくなります。

特に重要なのは、こうした品質の悪化が一時的ではなく、導入後も続いていた点です。詳しく見たところ、警告も複雑さも、複数の月にわたって増え続けていました。つまり、開発スピードが元に戻ったあとも、品質の問題は残ったままだったのです。

なお、コードの重複については、大きな変化は見られませんでした。

蓄積した問題が後の開発スピードを最大6割ほど下げる

さらに進んで、開発の速さと品質がどう関係しているかを調べました。

まず、開発の速さが品質に影響するかを見たところ、速度が上がっても警告や複雑さに直接の影響は見られませんでした。Cursorの導入も、警告にははっきりした影響を与えていません。

むしろ、コードの量（全体の行数）が、警告や複雑さに強く関係していました。コードが増えれば、自然と問題も増えるということです。

ただ、重要な発見があります。コードの量を考慮しても、Cursorの導入はコードの複雑さを9.0%増やしていました。つまり、Cursorが書くコード自体が複雑になりやすいということです。

次に、品質がその後の開発にどう影響するかを見ました。結果は大きなもので、コードの複雑さが2倍になると、開発の速さは約65%下がり、警告が2倍になると約50%下がりました。

つまり、品質の悪化は、あとから開発を遅らせる要因になります。これはまさに「技術的負債」と呼ばれる現象です。

一方で、Cursorの導入には一時的に開発を速くする効果（追加行数84%増）がありますが、この効果も品質の悪化で打ち消されていきます。研究によれば、警告が5倍、または複雑さが約3.3倍になると、速度向上は完全に相殺されます。

実際の平均増加（警告30%、複雑さ41%）ではそこまでにはなりませんが、品質の悪化が将来的に開発を遅くする圧力になっているのは確かです。そしてこの影響が積み重なることで、Cursorの効果が2ヶ月で消える理由の一部が説明できます。

よく使う開発者ほど品質の悪化が大きく、この関係が確認された

結果の信頼性を確かめるために追加分析が行われました。

まず、導入前の傾向が両グループで似ていたかが検証され、ほとんどのケースで条件が満たされていると確認されました。次に、Cursorの使用頻度による違いが調べられました。設定を継続して更新していたプロジェクトや、ユーザーの活動が多かったプロジェクトでは、効果が強く現れました。

また、他のツールの併用についても確認されましたが、Cursor単独使用とのあいだに大きな差は見られませんでした。さらに活動量や時期の違いに応じた条件で再分析も行われましたが、主な結果は変わりませんでした。

なぜこうなったのか、どう向き合うべきか

調査の結果から見えてきたのは、「AIを使えば速くなる」という単純な話ではありません。最初に生産性が大きく上がり、その後に失速し、品質の問題が残る。この流れが何を意味するのかを考えていきます。

技術的な負担と開発者の期待外れが、2か月後の失速を引き起こす

まず、なぜ初期の加速が2か月で止まってしまうのか。研究チームは3つの理由を挙げています。

1つ目は、技術的な負担（技術的負債）が増えることで、開発が遅くなることです。
今回の分析では、コードが複雑になり、警告が増えることで、将来の開発スピードが落ちることが確認されました。ただ、これだけで説明はつきません。速度の低下を完全に説明するには、実際よりずっと多くの問題が生じている必要があります。つまり、他にも原因があるということです。

2つ目は、開発者の期待と現実のギャップです。
最初は新しいツールへの期待から、簡単な作業をAIに任せて生産性が急上昇します。しかし、使い続けるうちにAIの限界に気づきます。複雑な修正や細かな調整には向いていないため、失望して使わなくなる人も出てきます。AIの出力を確認・修正する作業も負担になり、徐々に敬遠されていく可能性があります。こうした話は開発者の聞き取り調査やオンラインの声とも一致しています。

3つ目は、Cursorの設定ファイルがあっても、実際の使われ方までは分からないという点です。一部の人が短期間だけ試しただけで、継続的には使われていなかった可能性もあります。

LLMは動くコードを書くが、構造が複雑になりやすい

次に、コードの質、とくに複雑さの増加について見ていきます。ここには小さくても重要な発見があります。

コード量を調整しても、Cursorの導入だけで9%の複雑さ増加が見られました。つまり、AIが書くコードは、人間よりも構造が複雑になりやすいのです。

その理由の1つは、LLMが「動くコード」を重視して学習されており、人間にとって読みやすいコードまでは意識していないことかもしれません。

この複雑なコードは、一見問題なく動くため見過ごされがちですが、将来的な修正や機能追加を難しくし、結果的にAIの性能も落ちやすくなります。

こうした複雑さが、使いにくさやストレスにつながり、ツールの利用減少を招いている可能性もあります。

自由に参加できるオープンソース環境が、影響をさらに強めている

この研究の結果は、オープンソース開発という特殊な環境で得られたものです。企業とは異なる前提が影響している可能性があります。

オープンソースでは、ツールの使用は自由で、期待外れならすぐに使われなくなります。レビュー体制も一様でなく、AI生成コードの問題が見逃されやすい面があります。一方、企業では導入が義務づけられたり、レビューやテスト体制が整っていたりと、継続的な使用や品質維持がしやすい環境にあります。

こうした違いが、品質悪化やツール離れを加速させている可能性があります。ただし、これは仮説に過ぎず、企業でも同じ傾向が見られるかは今後の検証が必要です。

開発の速さに応じて、品質チェックも強化する必要がある

それでは、この研究結果から実務にどんなヒントが得られるでしょうか。

まず大事なのは、開発が速くなるほど品質保証も強化する必要があるという点です。技術的負担が積み重なると、開発がかえって遅くなってしまうからです。

たとえば、コードの質が落ちてきたら整理の時間を取る、追加したコード量に応じてテスト範囲を広げる、Cursorの設定で品質基準を厳しくするなどの対策が考えられます。

こうした工夫なしに開発スピードだけが上がると、結果的に手に負えないコードが増えてしまうおそれがあります。スピードと品質はセットで考えることが大切です。

これからのツールは、コード生成と同じくらい品質管理も重視すべき

次に、AIコーディングツールの設計に関するヒントです。今のLLMエージェントは「コードを作ること」が優先され、品質のチェックは後回しにされています。次の世代では、コードと一緒にテストを提案したり、無駄な複雑さをその場で指摘したり、品質が落ちたら整理（リファクタリング）を促す仕組みが求められます。

つまり、「ただコードを出す相棒」ではなく、「品質も見守る相棒」になる必要があります。

さらに、思い切った発想として、ツールが「コードを減らす方向」に動く仕組みも考えられます。たとえば、プロジェクトの複雑さが一定以上になると、自動で提案の頻度を下げたり、まず整理するよう促したりします。こうすることで、ツールの目的が「とにかく書く」から「長く保てるコードを支える」方向へ変わっていきます。

読みやすいコードを重視する訓練と、しっかりしたレビューが複雑さへの対策になる

コードの複雑さが25%増えたという結果は、単なる品質の話ではなく、人が理解する負担――いわば「理解のコスト」に関わる重要な問題です。見た目は正しく動いていても、意味がつかみにくいコードは、人にとって扱いづらくなります。

この原因のひとつは、LLMが「テストに通ること」を重視して学習されており、「人にとって読みやすいか」をあまり考慮していない点にあります。これに対処するには、可読性を重視した追加学習や、生成後にコードを簡素化する仕組み、そしてなぜ複雑な実装が選ばれるのかを明らかにする研究が求められます。

実務の場では、AIが書いたコードは「特に注意が必要なもの」として扱うべきです。レビューでは、同じ機能をもっとシンプルに書けないかを意識して確認することが大切です。

技術の進歩と文脈への適応が進めば、今後の改善が期待できる

これまでの内容は厳しく見えるかもしれませんが、研究チームはそこまで悲観する必要はないとも述べています。

第1に、この研究は2024〜2025年という急成長中の時期を切り取ったものです。LLMやエージェントの技術、開発の現場は急速に進化しており、将来のツールでは今回の問題が改善される可能性があります。

第2に、使われた指標は伝統的なソフトウェア工学に基づいていますが、AIによる開発の特徴を十分に捉えていないかもしれません。たとえば、機械的には正しいが構文が複雑なコードを、過剰に低く評価している可能性があります。

第3に、オープンソースという環境が、放棄や品質への懸念を強めている可能性があります。企業などの整った開発体制では、違った結果になることも考えられます。

これらを踏まえると、結果の受け取り方には注意が必要ですが、重要な発見自体は変わらず、今後も継続的な検証と研究が必要です。

まとめ

本記事では、LLMアシスタントが実際の開発にどう影響するかを、807のCursor導入プロジェクトと1,380の対照プロジェクトを比べて検証した実証研究を取り上げました。

結果は、楽観にも悲観にも寄らない現実を示しています。Cursor導入で開発速度は大きく上がりますが、その効果は2ヶ月ほどで減少すると示されています。一方、コードの複雑さや警告の増加は続き、将来的な速度を下げる要因になります。

ただし、この結果は変化の速い2024〜2025年のもので、今後のツール進化で改善される可能性もあります。また、対象はオープンソース環境であり、企業内開発では違う結果になることも考えられます。

それでも、方向性ははっきりしています。LLMをうまく使い続けるには、開発スピードに応じた品質管理や、品質を重視したツール設計が必要そうです。