本当にAIでコーディングが速くなりますか？

ここ数年、AIのフロンティア・モデルは大胆な約束を掲げてきました。つまり、コーディング・アシスタントを使うことで、成果が速くなり、バグが減り、開発者の面倒な作業が減るというものです。GitHub CopilotやCursorのようなツールは、ClaudeやGPTのような 大規模言語モデル (LLM)によって動かされ、人間のプログラマーがコードベースのより難しく創造的な問題に集中できるように、煩雑なプログラミング部分を自動化するよう設計されています。

少なくとも、これまではそうでした。しかし、フロンティア・モデルの機能を評価するバークレーの非営利団体であるMETR（Model Evaluation and Threat Researchの略で "メーター "と発音する）は、その主張を裏付ける実際の証拠があるかどうかを確認したいと考えました。彼らの発見は、その物語を覆すものでした。コーディング・アシスタントは、実際には開発者の作業を遅らせる可能性があるのです。

METRの研究者は、数年間にわたって大規模なオープンソース・リポジトリーに貢献していた16人の経験豊富な開発者の作業を観察しました。各開発者は、バグ修正プログラムから新しい機能まで、通常取り組むべき実際のタスクのリストを提供しました。その後、研究者たちはタスクをランダムに2つのグループに分割しました。1つは開発者がAIツールを使用できるグループで、もう1つは使用できないグループでした。

AIが許可されれば、開発者は必要なツールをなんでも選択できますが、ほとんどの回答者はClaude 3.5または3.7 Sonnetと組み合わせたCursor Proを選択しました。彼らは、各タスクを完了した際の画面を記録し、自分が予想した合計実装時間を報告しました。その研究結果は驚くべきものでした。「開発者にAIの使用を許可すると、問題完了にかかる時間は19%長くなります。これは、開発者の考えや専門家の予測に反する大幅な低下です」と論文の著者は述べています。

私たちは、IBMのAIアドボカシー・リードのPJ Hagerty氏と特別エンジニアのChris Hay氏に、METRの調査を見てもらい、感想を共有してもらいました。。

Hagerty氏は、AIアシスタントをめぐる誇大宣伝が、現実世界のユーティリティーを上回っている可能性があると警告しました。「AIが人々の生産性を高めるという約束は、技術リーダーシップとAIの誇大宣伝を利用しようとしている生成AI企業に由来しています」と彼はIBM Thinkに答えました。「実際には、 AIは進みながら学習しており、Stack Overflow、Github、一般的なGoogle検索など、若手開発者が使用するのと同じ参考情報を使用している可能性がありますが、コンテキストはまったくありません。」

「関連性のある成果だと思います」とHay氏は付け加えます。「しかし、私たちが『わあ、 AIは役に立たない』と考えるべきだとは思っていません。『自分でやったほうが早いよ』とね。ただし、特定のタスクについては、 AIを説得するよりも自分でやったほうが早いという点があります。」

調査の成果の残りの半分も同様に興味深いものです。開発者は、開始前にAIが作業を２４％スピードアップすると予想していました。しかし、19% の減速を経験した後でも、AIによって20％スピードアップしたと彼らは信じていました。

では この認識のギャップの背後にあるものは何なのでしょうか？この研究の著者の一人であるMETRのNate Rush氏に話を聞きました。「これは素晴らしい質問ですが、私たちの研究ではまだ十分に答えられていません」と、とラッシュ氏はIBM Thinkに語りました。「理想的には、将来の研究で、開発者がAIの有用性に期待する内容がツールの使用方法にどのような影響を与えるか、 [そして ] この認識のギャップが存在する理由について、さらに探求することです」

認識の問題以外にも、この調査ではいくつかの重要な疑問が提起されています。結局のところ、開発者の生産性を測るには時間の節約だけが唯一の方法なのでしょうか？コードの品質やチームへの影響などの指標は、全体像にどのように適合するのでしょうか？

「私たちの調査は時間の節約についてのみ示しており、これは生産性の一側面の尺度にすぎません」とRush氏は言います。「『1つの正しいメトリクス』は存在しませんが、おそらくAIツールの影響について参考になるメトリクスの集合になっていると考えられます」彼は、この研究では時間に焦点を当てたものの、彼のチームは、開発者生産性の SPACEフレームワーク (SPACEはSatisfaction、Performance、Activity、Communication、Efficiencyの略)が、将来の方向性を考える上で役に立つことを発見したと述べました。

もう1つの質問：モデルのバージョン（この場合はClaude 3.5と3.7 Sonnet）はパフォーマンス時間に影響を与えたのでしょうか？「これが現実です」とHay氏は言います。「バージョンも重要だと思います。Claude 4 Sonnetの方がかなり良いです。Claude 4 Opusは大幅に改善されています。これは、少し良くなったという話ではありません。格段に良くなったという話なのです。」

調査に参加した16人のうちの1人であるクQuentin Anthony氏は、人的要素も重要な考慮事項の1つだといいます。「私たちは、LLMはツールであると言いますが、もっと魔法の弾薬のように扱っています」と彼はXに書いています。「LLMは、問題をワンショットで解決する大きなドーパミンのショートカット・ボタンなのです。あなたは、すべてを解決できる可能性が 1% あるボタンを押し続けますか？少なくとも私にとっては、これは過酷な代替手段よりもはるかに楽しいものです。」(Anthony は、ソーシャルメディアによる注意散漫も、遅延を引き起こしやすくするもう一つの原因だと付け加えた)

では、AIコーディング・アシスタントが進化し改善するにつれて、最も持続可能かつ長期的な影響を与えるのはソフトウェア開発のどの領域でしょうか。「安定性があり、信頼性が高く、便利になると、コード・アシスタントはQAレイヤー（テスト、品質保証、アクセシビリティー）には最適な存在になると思います」とHagerty氏は言います。「制約があり、ルールに基づいたものは、これらのツールの最良の用途です。」

それは、コードを書くこととチェックすることは根本的に異なるからだと、彼は言います。「コーディング自体は創造的な活動です。独自のエコシステムでゼロから何かを構築するということです。AIアシスタントはそのニュアンスを見落としています。しかし、より一般的で普遍的なルール・システムを使ってテストできる可能性は高いでしょう」