- 2025年初頭のAIツールがオープンソース開発者の実際の生産性に与える影響について、無作為化比較試験を実施
- 研究の結果、AIツールを使うと作業完了時間が平均19%長くなることが判明
- 開発者はAIによって24%速くなると期待していたが、実際の体感とは異なり速度低下が発生
- ベンチマークと日常的な経験におけるAIの能力と実際の効果のギャップが非常に顕著
- 研究はAIの生産性への影響を正確に理解することと、多様な評価方法の重要性を強調
概要
- 本研究は、2025年初頭（Early-2025）のAIツールが経験豊富なオープンソース開発者の生産性に与える影響を確認するため、**無作為化比較試験（RCT）**を実施
- 予想に反して、AIツールを使うと開発者の作業時間が19%長くなる現象が確認された
- この結果は、AI研究の自動化がソフトウェア開発に実際に与える影響を測定した一例として解釈できる
- 本手法に基づき、AIの研究開発加速の現実的な効果を継続的に推定する計画を示している
研究動機
- 既存のコーディング／エージェント系ベンチマークには、実務状況を十分に反映できていない限界がある
- 自己完結型テスト、文脈のない単発課題、自動採点構造などにより、AI能力を過大評価する可能性がある
- 逆に、人間の適応的介入がない場合には、実際のAIモデル性能が過小評価される可能性もある
- こうした限界を補うため、実際のオープンソース開発者の生産性への影響を実験し、AIの現実的な影響を測定した
実験方法
- 16人のベテランのオープンソース開発者を募集し、各自が数年にわたり活動してきた大規模リポジトリ（平均2万2千超スター、100万超コード行）から実際のイシュー246件を選定
- 各イシューごとに、AI使用を許可するか禁止するかのグループへ無作為に割り当て
- AI許可時は、開発者はCursor ProやClaude 3.5/3.7 Sonnetなどの最新モデルを自由に使用し、禁止時は生成AIの支援なしで作業を実施
- 参加者は各イシュー（平均2時間）を解決する過程を録画し、所要時間を自己申告した
- 実験参加者には時給150ドルの報酬を支給
主な結果
- AIツールを使うと、イシュー解決時間は平均19%長くなる
- 開発者はAIが実際に生産性を24%高めてくれると期待しており、実験後もなお20%の速度向上を体感したと回答
- このように認識と実際の成果の間に大きな乖離が見られた
- 特定の誤解を避けるため、本研究は次の内容についての証拠を提供するものではない:
- すべての開発者、またはソフトウェア開発全体でAIが遅くするという一般化
- 他分野や別の設定におけるAI効果の規定
- 近い将来も同じ結果が続くと断定すること
- 既存のLLMやプロンプト手法の最適化が不可能だという主張
影響要因の分析
- 作業遅延を説明しうる20の要因を分析し、そのうち5つが実際に影響したと判断
- 実験条件、モデル、イシュー難易度、PR品質などの主要変数は、実験結果に有意な影響を与えなかったことが確認された
- 遅延現象は、さまざまなデータ部分集合や推定手法でも一貫して観察された
- 詳細な分析内容は論文本文で確認できる
結果の解釈と議論
証拠の衝突と原因
- AIベンチマークのスコア／事例報告／実際の実験の間で結果の差が明確に見られる
- ベンチマークは自動採点可能な狭い問題を中心にAI能力を測定している
- SWE-Bench: テストベースのオープンソースPR、RE-Bench: アルゴリズム評価が可能な問題
- 実際のRCTでは、20分〜4時間かかる複雑で現実的な作業において、人間のほうがむしろ遅くなった
- 一方で、産業現場やコミュニティでは、AIが長時間の業務にかなり有用だという定性的報告が多い
解釈フレームワーク
- それぞれの方式には、「実際の能力」を異なる形で測定する特性がある
- 事例ごとのアプローチ方法:
- RCTの過小評価問題: 私たちの実験設定に特有の事情が存在する可能性
- ベンチマーク／事例の過大評価可能性: 実際の解法との乖離、自己報告根拠の信頼性不足
- 3つの方式すべてが、実際の一部の下位問題にしかうまく適合していない可能性
- 異なる出所の結果と実際の能力値の乖離は、**測定誤差・バイアス（赤）、測定範囲の差（青）**として解釈できる
実験の追加的示唆
- RCTの結果は、数百回または数千回にわたってAIの結果をサンプリングする環境には当てはまらない可能性がある
- CursorなどのAIツールを数十〜数百時間使って初めて能率向上が現れる可能性がある
- 高品質なコードや暗黙の要求事項（文書化、テスト、フォーマットなど）が多い環境では、AIの能力が制限される可能性がある
- ベンチマークは問題範囲が狭く、実際の業務の難しさを適切に反映できていない
- 定性的な体感報告は、過大評価や自己錯覚の効果により信頼性が低下する可能性がある
- どの単一の評価方法も完全ではないため、相補的に使う必要があることが強調される
今後の展望
- 本手法を継続的に改善し、AIツールが開発者の生産性を実際にどの程度変えるのかを定量的に追跡する予定
- もしAIツールが現場の開発者の能率を大きく高めるなら、AI研究開発全体の急速な加速／監視の失敗／権力集中のリスクなども同時に生じうる
- 実環境に適した評価フレームワークの開発は、今後のAI発展と産業全体にとって非常に重要である
2件のコメント
時給150ドル？の時点で、もう変数統制からしてｗｗｗｗｗ
Hacker Newsの意見
Simon Willisonのコメント:
論文全文には要約で省かれていた細部がかなり多く含まれている 論文リンク
私個人の考えでは、LLMベースのAIツールで実質的な生産性向上を得るには、人々が想像するよりはるかに急な学習曲線が存在する
今回の研究には、さまざまなAIツール活用経験を持つ16人が参加しており、56%はCursorを初めて使っていて、主にCursorに関する研究だった
各参加者は合計で約15件のイシューを扱い、イシューごとにAIの使用可否がランダムに割り当てられた
つまり、1人の開発者がAIありの課題とAIなしの課題を混在させて進めた
参加者のうち1/4だけが性能向上し、3/4は性能が低下した
AI使用の上位層は Cursorを50時間以上使ったことがある人 だった
研究チームも、Cursorの経験が十分な開発者には性能向上があったと認めている
私の直感では、この論文はAI協調開発における学習曲線が高いため、実務で既存ワークフローにすぐ混ぜるとかえって性能が落ちることを示したのだと思う
LLMについて「君がちゃんと使えていないだけだ」というありがちな反応があるが、これはあまりにもユーザーに責任を押しつける言い訳に見える
ほとんどの技術製品では、ユーザーが価値を感じられないなら製品設計自体が悪いと考える。AIにだけなぜこの論理が適用されないのか疑問だ
Simonに感謝、そして論文を丁寧に読んでくれてありがとう - OSSプロジェクトのファンとして、いくつか重要な点を指摘したい
1) 既存研究の一部では、ツール経験が少なくても性能向上 が見られており、つまり「急な学習曲線」理論だけでは今回の結果をすべて説明できない
2) 研究前に参加者の90%以上がLLMプロンプト経験を持っており、プロンプトこそ主要スキルと見なされていた。VSCodeに慣れていればCursorも簡単に使えるというのが通説 だった
3) 全員がAIに慣れていたなら、AIなしの状況では逆にうまくできないかもしれない（少なくとも私は共感する）。むしろその場合、AIがより良く見える錯覚が減点効果になる
4) 経験情報は事前に予測専門家たちと共有されていたが、それにもかかわらず 予測者たちは生産性向上への期待値を過大に見積もっていた
5) 数百時間の使用によるロングテールなスキルが実際に存在する可能性はあるが、本研究ではそこまでは言いづらい
論文が驚くような結果を出しているので、読んだ人は1つの要因を取り出して「これが原因だ！」と簡単に結論づけがちだ
実際には複合的な原因かもしれない（少なくとも5つ、多ければ9つは排除できず、11ページの表を参照）
1つ本当に重要な示唆は、開発者の自己申告による満足感は実際との乖離が大きく、これは使っているツールの種類と無関係 だということ
生産性の測定には現場での実データが必須だ（論文C.2.7参照: 「平均以下のAIツール活用」セクションで詳しく扱っている）
参加者の75%にLLM経験があるにもかかわらず、AIを使うと作業速度がむしろ遅くなったと解釈できるが、1つの解釈はLLMの学習曲線が非常に急だということ、もう1つは現在のLLMの実際のプログラミング補助効率が過大評価されており、人々が一貫して性能予測を取り違えているという点だ
LLMをうまく扱えるようになっても、自分が書いたコードへの理解度は下がるかもしれない
開発者は時間が経つほどコードに精通していくが、LLMはむしろだんだん悪くなる可能性がある
LLMで素早くコードを生成できても、十分に注意しなければコードへの熟練は蓄積されない
序盤は軽快で速い開発になるが、実際には裏側で理解が不足し、LLMも最初は使い物になっても次第に改善されず、ある時点でLLMもそのユーザーも扱いきれない混沌としたコードになる
誘惑を避けつつ、LLMがよりきれいなコードを出すよう粘り強く管理し、自分自身も必ずコードを勉強すべきだと思う。自力で理解しようとする努力が必要だ
AIツールによって生産性が上がった人もいれば、そうでない人もいることがわかる
私の推測では、長いテキストやコードを素早く読み取れる人がかなり有利だ
役に立たない提案をすばやく見抜き、良い答えが出るまで繰り返す能力が非常に重要だ
高速にスキャンする能力は経験者と相関があるが、意外にも新人の中にもこれが速い人はいる
検索能力に優れた人はLLM活用でも有利かもしれず、ググる能力と似た文脈に見える
80/20の法則を改めて思い出させる - 作業全体の80%を20%の時間で解決してくれる一方で、残り20%のために80%の時間を消費する
常に「もうほとんど終わった」という感覚があるので、サンクコストの誤謬に陥りやすい
最近試した方法としては、AIを「解決者」ではなく「摩擦の除去者」として使うやり方だった
プログラミングは自分でやりつつ、ちょっとした忘れた構文のようなものだけをAIに聞いて作業速度を上げる
コード全体の直接提案はほとんど見ない。常に自分で考えながらコードを書いて、理解度や実力の低下を防ぐ
昔は80%の作業に80%の労力、残り20%にもさらに80%の労力がかかる逆パレート方式だった
「小さな障害物」だけを解決するAI活用には同意する
昨日もJava stream APIでListを処理していてConcurrentOperationsExceptionに苦しめられた
自分でメソッドを書いてもうまくいかず、AIに「スレッドセーフなリスト変換メソッド」を任せたら、そのAPIにすでに組み込みメソッドがあると教えてくれた
こういう雑多な問題にはAIが最高だ - 複雑だが定義が明確なときに
Stack Overflowをもっと強力に使うような場面で特に有用だ。自分が何をすべきかはだいたい分かっているが、具体的に自分の環境に合わせてどうするかが分からないとき、そしてデバッグやラバーダッキングにも役立つ
「最後の20%のために80%の時間を消費する」というのはAI導入前から私の経験でもあった。初動の時間だけでも減るなら良い。関係者から聞いた最高のAI評は、「自分のスキルの90%は無価値になり、残り10%は1000倍重要になった」というものだった。誇張ではあるが、核心は気に入っている
「いつもほぼできている」という錯覚のせいで、かえって時間の浪費が生まれる。AIは何か役立っているように見せることに特化しているので、本当に生産性向上なのか見極めるには高度な批判的思考が必要だ
既存コードベースに機能を追加するときに特に有用だ。「既存の検索パラメータに加えてfooを追加する」とか「xに関連するコードを削除してほしい」といった作業に向いている
HNユーザーの皆さんへ、論文著者です - 昔からのHNユーザーで、今日コメントに質問やフィードバックが付けばできる限り答えています。時間がないなら論文全文より紹介ブログ記事や x.comの発表スレッド をおすすめします
論文の方法論と著者のコミュニケーションの仕方はとてもプロフェッショナルで印象的だ。良い研究だ
この研究はクリックベイトなしで正直に結果を示し、読みやすくよく整理されていて、最高クラスの研究の1つだと思う
AIで処理するチケットが本当にAI向きのタイプだったか考慮しましたか？ 「このチケットをAIで処理してみて」という形は現実的ではあるが非効率かもしれない。AIに向いた使い方をすれば本当に役立つが、逆効果な場合も多い。研究参加者に十分なAI経験があったならこの区別はできたはずだが、論文を読んでもその点が明確ではない
可能であれば匿名化された生データセットの公開や、少なくとも開発者ごとの絶対的な作業時間情報を論文に追加できるか気になる。Cursor経験が多い参加者が実際に他の人より速いのか、それとも元々遅い人でAIによる上昇幅が大きかっただけなのかが知りたい。Hawthorne effect（観察者効果）まで考慮した本当に良い実験的評価が見られてうれしい
（論文は読まずポストだけ見た）主観的疲労度（subjective fatigue）が、AIの方が速いと誤解する原因を説明する指標として測定されたのか気になる。開発者から管理職に移った後、脳が疲れている状況ではAIの方が楽で良い
この研究結果、とくに「開発者はAIが速度を24%上げると期待したが、実際には遅くなったにもかかわらず、体験後も20%速くなったと信じていた」という部分が非常に興味深い。実際と認識の乖離がこれほど劇的に大きい理由は何だろうか？ もしかすると脳が『精神的努力』を時間の体感と取り違えているのかもしれない
根拠はないが怖い考えがある。コーディング時のAIとの相互作用は、ある種のソーシャルメディア的ドーパミンループのように脳を刺激しているのではないか（程度は違うとしても）。AIが繰り返し答えを提示することで、脳が肯定的な評価を受けているように感じ、そのため開発者がAIを実際以上に好意的に評価する現象が起きているのではないか。もしこれが中毒的な現象まで引き起こすなら、実際の生産性効果を過大評価してしまうのではないか
この現象は、市場で多くの人がAIツールを実際以上に優れていると信じるようにする巨大なキャンペーンの結果かもしれない。経済専門家やML専門家の集団自体がAI企業の利害関係者と重なっていて、経営陣がそれを鵜呑みにして大きな成果を約束する。それが結局ベースラインの期待値を全体的に押し上げ、経験豊富な開発者にまで影響している。経験的に立証するのは難しいが、AI生産性に関する集団的な錯覚が広く広がった理由かもしれない
HNコメント欄の多くのAI熱狂派もこの現象に陥っている可能性があるのではと思う。実際、自分で性能を測定しない限り、AIが本当に自分の生産性を上げているのか疑わしい
ときどき正反対の体験をすることもある。今日Claude codeでサンプルのデモアプリのコードを作ろうとしてみたが、見ている間はすごくてSFっぽくて楽しかったのに、15分で頭がぼんやりして退屈になった
「開発者はAIが24%速くなると期待し、実際には遅くなったのに20%速くなった気がすると信じていた」という点を見ると、ここには2つの問題があると感じる
1つは、同じ人物が同じ文脈でAIありとAIなしで作業したときの所要時間を正確に比較するのが難しいこと
もう1つは、PRオープンやマージまでの期間のような表面的指標でAI効率を測りがちだが、実際にはAI導入によってリファクタリング、テスト、イシュー解決などの後処理により多くの時間が割かれることだ
「PRが早く開いた」だけを見てAIは速いと錯覚しやすいが、その後の作業が増えることを見落としやすい
特定の技術や慣行が生産性に与える影響を測るのは本当に難しい。自己申告（anecdote）だけを信じて結論づけるのは危険だと思う。誰でも簡単に自己暗示に陥り得るからだ。研究自体も限界を認めているのだから、生産性に関する議論では大きな誤差幅を意識すべきだ。AIという技術は人生で見た中でも最も奇妙で、断片的事例や怪しいベンチマークから因果関係を読み取るのはほとんど占いのようなものだ
論文では、AI許可/不許可の状況でPR品質の低下は観察されなかった。参加者の大半はリポジトリ基準に慣れていて、「とりあえず出してPRを立てる」ようなスタイルではない。研究内のPRの中間レビュー時間は約1分だった。あなたの言うとおり時間の使い方は完全に変わる。論文10ページにAI使用/未使用ごとの時間分布があるので参照してほしい。AI活用時にはコーディング時間は減り、AIとの対話時間は増える
「同じ人が同じ文脈でAIあり/なしで作業したとき、それぞれにかかった時間差を正確に知ることは不可能だ」という指摘については、実験設計上ランダム割り当て（random assignment）によりAI群と非AI群の効果を分離している。個人、状況、環境などの差はランダム化で相殺される。標本数と効果量が十分大きければ、統計的に意味のある差を取り出せる
Figure 21を見ると、初期実装（PRまでの時間）自体も増加しており、PRレビュー後の時間がさらに増えたとしても、全体としては大きな影響はなさそうだ。Figure 18で確認できるように実コーディング時間は減ったが、プロンプト作成や結果待ち、出力レビューなどで節約効果が相殺されている。5分以下の単純作業では、むしろLLMを使わない方が良かった可能性もある
各ワークフローごとのPR内容を比較してみたい。Copilotは自分でやるより多くのコードを提案するが、不要なチェックや重複、過剰なコード量になりがちだ。私の個人的な仮説では、LLMが大量のコードを書き出すのを見ると、問題解決にどれだけ時間がかかるかの体感が歪められるように思う
LLMを活用して大規模コードベースで作業するときの本当の難しさは、やるべき作業を正確に記述することだ。多数のコード相互作用の中にある問題を説明するだけで、むしろ手で直接処理するより時間がかかることが多い。一方で、新規プロジェクトでボイラープレートコードを作るときにはLLMと最も相性が良いように思える
参加開発者の募集費だけで300 x 246 = 約73Kを使っているのに、論文は学術誌にも載っておらず、査読もない。論文は見た目には整っていてAI生成っぽくもないが、どうやってこういう資金が可能だったのか気になる
最大の資金提供元はThe Audacious Projectで、公式発表 で確認できる。また2025年4月まではAI企業から評価の対価を受け取っていないと ウェブサイトの脚注 に明記されている
企業はこういう類いの「ホワイトペーパー」をよく出す。技術報告、政策提言、広報物が混ざった形だ
学術誌掲載や査読の有無だけを気にするのは意味がないと思う。科学で重要なのは誰が出版したかではなく、再現性と反復的成果だ。心理学の再現性危機の事例のように、ジャーナル掲載自体は信頼性を保証しない
ほとんどの国には研究への公的支援金がある。米国は以前もっと支援していたが、近年は大幅に削減された
財団紹介ページ を見ると、AI企業や政府などさまざまなところから資金を受けているようだ
趣味のOSSプロジェクトではAIはむしろ邪魔にしかならない。コード生成やスキャフォールディングは心配事ではなく、むしろコードレビューやコミュニティ運営の方が重要だ。AIツールでできることにははっきり限界がある。それなのに誰かが私のオープンPRにAIコードレビュー工具を投入して、30行のPRにまで絵文字と整った箇条書き付きの2ページ分の要約を吐き出してくる。不要なノイズになっていて、今ではそういうコメントを削除したり隠したりするぶん、本当の保守時間だけがさらに減っている
学習曲線さえ越えれば速くなるが（あるいは誰かが言ったように「今度はAIなしで働く方法を忘れるまで」）、本当に測るべきなのは……午前3時にPagerDutyのアラートが鳴ったとき、そのコードをデバッグするまでに本当にどれだけ時間がかかるかだ。そしてそのコードの長期的品質がどうなのかも気になる。私はビジネスロジックを共有フォルダへ引き上げ、呼び出しチェーンを上位にまとめてAPIをすっきりさせ、ロジック/API/表示の分離やカプセル化など、長い時間をかけてコード構造を改善してきた（依存性注入で結合度を下げるなど）。AIコードは長期的により良い品質、移植性、拡張性を持つのだろうか？ それとも結局、質の低いコードが少しずつ積み上がって絡み合ったゴミ捨て場になり、最終的にはバグ修正に時間の半分を費やすことになるのだろうか?