このコーナーでは、2014年から先端テクノロジーの研究を論文単位で記事にしているWebメディア「Seamless」(シームレス)を主宰する山下裕毅氏が執筆。新規性の高いAI分野の科学論文を山下氏がピックアップし、解説する。
X: @shiropen2
米国のAI研究機関であるModel Evaluation & Threat Research(METR)に所属する研究者らが発表した論文「Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity」は、コーディングにおいて、AIツールを使うとどれくらい開発が効率化するかを調査した研究報告だ。
実験では、16人の経験豊富なオープンソース開発者が参加した。開発者らは過去に平均5年間で、大規模リポジトリ(平均2万3000スター、110万行のコード)において246のタスクを完了している。これらの課題には、バグ修正、機能追加、リファクタリングなど、通常の開発業務で扱うような多様なタスクが含まれていた。
実験対象の各課題は無作為にAI使用可能群か、AI使用不可群に割り当てられた。AI使用可能群では、開発者は任意のツールを選べ、主にClaude 3.5 SonnetとClaude 3.7 Sonnetを搭載したCursor Proを使用。これらは実験時点での最先端モデルであった。
AI使用不可群では、生成AI支援なしで作業を行った。各タスクの平均所要時間は約2時間で、開発者は作業中画面を録画し、実装に要した総時間を自己申告した。
開発者たちは実験前、AIが24%作業を高速化すると予測していたが、実際には課題の完了に19%多くの時間を要した。さらに実際に遅延を経験した後でも、AIが20%高速化したと信じていた。
研究チームは20の要因を分析し、5つの要因が速度低下に寄与していることを発見した。第1に、開発者のAIツールに対する過度の楽観主義がある。開発者は実際には遅くなっているにもかかわらず、AIが役立っていると信じ続けていた。
第2に、開発者がリポジトリに高い習熟度を持っていたことだ。経験を持つ開発者にとって、場合によってはAIに頼らない方が効率的でAIの支援は限定的だった。第3に、リポジトリの規模と複雑性だ。平均10年の歴史を持つ大規模で複雑なコードベースは、AIの性能が制限された。
第4の要因はAIの信頼性の低さだ。開発者はCursorが生成したコードの44%未満しか受け入れず、受け入れた場合でも大幅な修正が必要だった。画面録画の分析によると、開発者は作業時間の約9%をAI生成コードのレビューと修正に費やしていた。
第5に、リポジトリ固有の暗黙知の存在がある。例えば「このコードは一見不要に見えるが、5年前のバグ対応で追加したもので、削除すると特定の状況で問題が起きる」といった知識がある場合、長年の貢献者が持つ文書化されていない知識をAIは活用できず、その結果として有用性が低下した。
Source and Image Credits: Joel Becker, Nate Rush, Beth Barnes, David Rein. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
1週間、人力コーディング禁止→結果は“成果半減” それでも「やってよかった」とCTOが言い切るワケ
「@grok ファクトチェック」は本当に正しい? 迫る参院選、偽情報に踊らされないSNS・AIの付き合い方
「バグの特定や修正はAIの方が早い」──DMMがAIエージェント試験導入の結果を公開、評価は?
AIで「月1000時間」の業務効率化――サイバーエージェントのAI活用率いるエンジニアが頼る、“6つのAIツール”とは
LINEヤフー、生成AI活用を義務化 「任意の会議は出席せず、AI議事録で把握」などCopyright © ITmedia, Inc. All Rights Reserved.