AI支援コーディングの誤った評価方法12選
この記事では、AIコード支援ツールの評価によく使われる誤った指標（コード行数の計測、人工タスクのタイミング、開発者の自己報告への依存など）を批判します。多くの現在の測定方法は誤解を招き、真の生産性や品質を捉えていないと論じています。
来週、上司から会社が契約したAIコーディングツールの価値を証明するよう求められたと仮定してください。生成されたコード行数か、クローズされたチケット数を測定しますか？それとも、開発者がより生産的になったと感じているかどうかを尋ねるアンケートを送りますか？これらのアプローチにはそれぞれ異なる欠陥があります。以下でその理由を説明します。
注：この投稿は、人々がAIをどのように評価しているかについてであり、LLM支援コーディング自体についてではありません。少し言い換えれば、これらの批判はアジャイル開発やテスト駆動開発などの手法についてなされた多くの主張にも当てはまります。過去20年間で何かを学んだとすれば、それは、私たちが人文科学の同業者にこうした事柄を適切に研究する方法を教えてもらうことを厭わなかったなら、ソフトウェア工学は今日もっと進んでいただろうということです。
生成されたコード行数の計測：代理指標は直接測定が難しい概念の代わりとなります。コード行数はその最も古いものの一つです。LLMはより多くのコードを生成しますが、必ずしもより良い結果をもたらすわけではありません。LLMツール導入後、開発者一人当たりのコード行数が40%増加したチームは、生産性ではなく冗長性を測定しています。2000行の複雑なロジックを削除し、200行のクリーンなコードに置き換えることは、損失に見える改善です。より多くのコードは、読み取り、保守、デバッグの負担も増加させ、AIが将来の負担に貢献することは行数に現れません。
人工タスクのタイミング：広く引用された研究では、GitHub Copilotを使用した開発者は使用しなかった開発者よりもタスクを55%速く完了したことがわかりました。タスクは90分でJavaScriptでHTTPサーバーをゼロから実装するというもので、開発者にはその日他の義務はありませんでした。実際のソフトウェア開発には、自分が書いていない大規模なコードベースのナビゲート、チケットに曖昧に記述された要件の理解、同僚との調整、会議への出席が含まれます。グリーンフィールドのおもちゃタスクでの速度は、これらのどれについても速度を予測しません。経験豊富なオープンソース開発者を対象としたランダム化比較試験では、参加者自身の予測とは逆の結果が得られました。AIツールへのアクセスにより、タスク完了時間が19%増加しました。
対照群なしの前後比較：1月にLLMを使い始めました。6月までにプルリクエストの出荷が速くなりました。したがってツールは機能しているはずですよね？しかし、1月から6月の間に、12人のエンジニアを雇用し、CIパイプラインをリファクタリングし、クラウドプロバイダーを切り替えました。ツールを採用しなかったグループがなければ、LLMの効果を同時期に発生した他の変更から分離することはできません。内部妥当性には信頼できる反事実、すなわち、そうでなければ何が起こったかを知る方法が必要です。
開発者に生産性が向上したかどうかを尋ねる：「開発者の87%がAIツールで生産性が向上したと報告」のような調査結果は、ツールが機能している証拠として定期的に引用されますが、自己報告を系統的に誤解させる3つの要因があります。ホーソン効果（観察・評価されていることを知ると人は異なる働き方をする）、新奇効果（新しいツールは新奇性のために速く感じられ、その感覚は通常数週間で薄れる）、社会的望ましさバイアス（回答者は調査が聞きたいと思うことを言う傾向があり、特に経営陣がツールを選択した場合）です。
コミット、プルリクエスト、チケット数の計測：2023年、マッキンゼーはコミット数、プルリクエスト数、コードレビュー数などのアクティビティ数を使用して個人の開発者生産性を測定することを提案しました。グッドハートの法則は、測定値が目標になると、良い測定値でなくなることを述べています。開発者は自分のコミット数が追跡されていることを知ると、より多く、より小さなコミットを行います。チケット数が追跡されると、チケットは分割されます。数値は改善しますが、基盤となる作業は改善しません。活動は成果ではなく、成果は価値ではありません。
簡単な半分だけを測定：LLMはコード生成を高速化し、その半分は測定が容易です。もう半分はより困難です。LLM生成コードの正確性をレビューする時間、自信過剰な誤った提案のデバッグに費やす時間、もっともらしく見えるが安全でないコードによって導入されるセキュリティ脆弱性、即時の問題を解決したが周囲の設計を無視した提案から生じる技術的負債です。GitHub Copilotのコードに関する研究では、生成されたコードのかなりの部分にセキュリティ脆弱性が含まれており、時間的プレッシャーの下で開発者は安全でない提案をより高い割合で受け入れることがわかりました。2025年の5つの主要LLMの評価では、業界のセキュリティ基準を満たすWebアプリケーションコードを生成したものはありませんでした。30万件以上のAI作成コミットの大規模分析では、15%以上が少なくとも1つの品質問題を導入し、それらの問題のほぼ4分の1がコードベースに長期的に残存していることがわかりました。上がっているインプットだけを測定し、同じように上がっているコストを無視することは、測定ではなくマーケティングです。
採用率を成功指標として扱う：「エンジニアリング全体で90%のAIツール採用率を達成しました」というのは、調達の成果であって生産性の成果ではありません。採用率はツールがインストールされ開かれたかどうかを測定します。提案が有用かどうか、開発者が無批判に受け入れているかどうか、受け入れられた提案が正しいかどうかについては何も述べていません。高い採用率と低い提案品質が組み合わさると、ツールから利益を得るのではなくツールの管理に時間を費やす労働力が生まれます。IBMのエンタープライズAIコーディングアシスタントに関する研究では、ツールは純生産性の向上をもたらすことが多かったものの、その利益はユーザーベース全体で均一には経験されなかったことがわかりました。しかし、採用率は利益よりも測定が容易であり、まさにそれが報告される理由です。
ボランティアと非ボランティアの比較：LLMを使用することを選択した開発者と使用しなかった開発者を比較する研究は、2つの条件ではなく2つの異なる集団を比較しています。アーリーアダプターは、レイトアダプターや非アダプターとは、生産性を直接予測する点で異なります。彼らは実験に対してより意欲的で、新しいツールに慣れており、すでにハイパフォーマーである可能性が高いです。選択バイアスにより、観察されたグループ間の差異は、ツールではなく個人の特性である可能性があります。これは業界のAI生産性レポートで最も一般的な設計上の欠陥であり、最も安価に実施できる研究だからです。大規模IT組織におけるCopilot使用の2年間の縦断的研究では、ツールを使用した開発者は、導入前から一貫して非ユーザーよりも活動的であったことがわかりました。
個人ではなくシステムを測定：個人のコーディング速度は最も測定が容易であるため、測定されます。しかし、AIツールが開発者のコード作成速度を30%向上させたにもかかわらず、チームのチケットから本番までの時間が変わらなければ、ボトルネックはコード作成ではありません。より多くのコードが生成されるということは、レビューすべきコードも増えることを意味します。AIがコード量を増やし、レビュー能力を増やさなければ、サイクルタイムは悪化する可能性があります。プロの開発者を対象とした実証研究では、AIツールは経験の浅い貢献者のアウトプットを向上させた一方、上級開発者はAI生成コードからのコードレビュー負荷の6.5%増加を吸収したことで、自身の生産性が19%低下したことがわかりました。パイプラインの1つの段階を最適化し、他の段階を無視することは、生産性研究を装ったシステム思考の失敗です。
新奇期間中の測定：4週間の研究で生産性の向上が見られた場合、それは4週間の生産性の向上を見つけたにすぎません。新奇効果は現実のものです。開発者は初期期間中に新しいツールにより関与し、それが長期的なベースラインと比較して観察されるパフォーマンスを膨らませます。実際に重要な効果は週単位ではなく月単位で現れます。これには、AIに委任されたタスクのスキル低下、誤った提案からの技術的負債の蓄積、チームのコラボレーション方法の変化などが含まれます。短期的利益を検出するように設計された研究は、研究終了後に何が起こるかについて何も教えてくれません。Cursorを採用した807のオープンソースリポジトリの分析では、まさにこのパターンが見られました。採用は開発速度の大幅だが一時的な増加と、コードの複雑さと静的解析警告の実質的かつ持続的な増加をもたらしました。
提案受入率を品質シグナルとして扱う：LLMコーディングアシスタントは通常、開発者が提案を受け入れる割合を報告し、高い受入率はツールが有用である証拠として提示されます。受入率は、生成されたコードが開発者がTabキーを押すのに十分にもっともらしく見えたかどうかを測定します。コードが正しいか、安全か、保守可能かは測定しません。時間的プレッシャーの下にある開発者は、安全でない提案を含むより多くの提案を受け入れるため、締め切りが迫ると受入率はまったく間違った理由で上昇します。400人の開発者を対象としたエンタープライズ研究では、平均受入率33%と高い開発者満足度が見られましたが、受け入れられたコードの正確性やセキュリティの尺度は追跡されませんでした。十分に見えることを報いる指標は、優れていることを報いる指標ではありません。
AIを何もないことと比較：AI支援開発者を何も使用しない対照群と比較する研究は、実際には存在しないベースラインを選択しています。LLMアシスタントを持たない開発者は、ドキュメント、同僚、そして本来問題について考えるために使うであろう時間を利用します。関連する質問は、LLMツールが開発者がすでに持っている代替手段よりも優れているかどうかであり、その比較はめったに行われません。弱いベースラインを選択すると、どんなツールも良く見えますが、ツールが有用になるわけではありません。
これまで時間をかけてこれらのことを説明してくださったすべての方に深く感謝します。私が書いた内容の誤りや単純化しすぎは、すべて私の責任です。