AI支援コーディングを評価する際に陥りがちな12の誤り

 (third-bit.com)
9 ポイント 投稿者 GN⁺ 2 시간 전 | 1件のコメント | WhatsAppで共有
  • AI支援コーディングの価値は、コード行数、チケット数、満足度のような分かりやすい数字に還元しにくく、評価方法によって結論が歪められうる
  • コード行数やコミット数・Pull Request数・チケット数は活動量を測る値にすぎず、目標になった瞬間に簡単に操作され、品質を見分けられない
  • 受諾率と導入率は、提案がもっともらしかった、あるいはツールが展開されたというシグナルにすぎず、正確性・安全性・保守性を保証しない
  • おもちゃのような課題、対照群のない前後比較、自発的ユーザー比較、弱いベースラインは、LLMの効果と選択バイアスを切り分けにくくする
  • 生産性の判断には、レビュー・デバッグ・セキュリティ・技術的負債・チームのボトルネック・長期的な変化を含むシステムレベルの指標が必要になる

評価対象と前提

  • AI支援コーディングツールのサブスクリプション費用に見合う価値を証明しようとするとき、生成コード行数、完了チケット数、開発者満足度アンケートは、それぞれ異なる形で誤った結論を導きうる
  • 中心的な論点は、LLM支援コーディングの価値そのものではなく、その効果を評価する方法がどれほど簡単に的外れになりうるかにある
  • 同じ批判は、アジャイル開発、テスト駆動開発、その他のソフトウェア開発プラクティスに関する主張にも、少し言い換えるだけで当てはめられる
  • ソフトウェア工学が人間科学分野の研究方法をきちんと取り入れていれば、この種の現象研究ははるかに先に進んでいただろう、という結論につながる

誤った生産性指標

  • 生成されたコード行数を数える

    • コード行数は、直接測定しにくい生産性を代替する代理指標として、昔から使われてきた
    • LLMはより多くのコードを生み出せるが、より良い結果を保証するわけではない
    • LLM導入後に開発者1人あたりのコード行数が40%増えたチームは、生産性ではなく冗長さを測っていた可能性がある
    • 絡み合ったロジック2000行を整理された200行に置き換える改善は、コード行数指標では損失のように見える
    • コードが増えるほど、読む・保守する・デバッグする量も増え、AIが残す将来の負担は行数の計算には表れない

  • コミット、Pull Request、チケットを数える

    • 2023年のMcKinseyは、コミット、Pull Request、コードレビューのような活動数で個々の開発者の生産性を測る方法を提案した
    • グッドハートの法則のとおり、測定値が目標になると、それはもはや良い測定値として機能しなくなる
    • コミット数が追跡されれば、開発者はより小さく、より多いコミットを作り、チケット数が追跡されれば、チケットは細分化される
    • 数字が良くなっても、土台となる作業が改善されているとは限らない
    • 活動は成果物ではなく、成果物もそのまま価値になるわけではない

  • 提案受諾率を品質シグナルとみなす

    • LLMコーディングアシスタントの高い提案受諾率は、ツールが有用である根拠としてしばしば提示される
    • 受諾率は、生成コードが開発者にTabキーを押させるほどもっともらしく見えたかを測るだけで、正確性・安全性・保守性は測っていない
    • 時間的プレッシャーを受ける開発者は、より多くの提案を受け入れ、その中には安全でない提案も混ざる
    • 400人の開発者を対象にした企業研究では、平均受諾率33%と高い開発者満足度が確認されたが、受け入れられたコードの正確性や安全性は追跡していなかった
    • もっともらしく見えるものを報いる指標は、実際に良いものを報いる指標ではない

  • 導入率を成功指標とみなす

    • 「エンジニアリング組織全体でAIツール導入率90%を達成した」という言葉は、購買・展開の成果であって、生産性の成果ではない
    • 導入率は、ツールがインストールされて開かれたかしか測らず、提案が有用か、開発者が無批判に受け入れていないか、受け入れられた提案が正しいかは分からない
    • 高い導入率と低い提案品質が組み合わさると、開発者は恩恵を得るどころか、ツールの管理に時間を費やすことになる
    • IBMの企業向けAIコーディングアシスタント研究では、ツールがしばしば純生産性の向上をもたらしたが、その利益は全ユーザーに一様ではなかった
    • 導入率は便益より測定しやすく、まさにその理由で報告されやすい

実験設計の誤り

  • 人為的な課題の所要時間を測る

    • 広く引用されるGitHub Copilot研究では、ユーザーは非ユーザーより課題を55%速く完了した
    • 課題はJavaScriptでHTTPサーバーをゼロから実装することで、制限時間は90分、開発者にはその日の他の義務はなかった
    • 実際のソフトウェア開発には、自分が書いていない大規模コードベースの探索、曖昧なチケット要件の理解、同僚との調整、会議が含まれる
    • グリーンフィールドのおもちゃ課題での速度は、こうした実務の速度を予測しない
    • 熟練したオープンソース開発者を対象にしたランダム化比較試験では、参加者の予想に反して、AIツールへのアクセスを与えた場合に課題完了時間が19%増加した

  • 対照群のない前後比較

    • 1月にLLMを使い始め、6月にPull Requestがより速くデプロイされたなら、ツールが効果を上げたように見えるかもしれない
    • 同じ期間にエンジニアを12人採用し、CIパイプラインをリファクタリングし、クラウドプロバイダーを切り替えていたなら、原因を切り分けることはできない
    • ツールを導入していない集団がなければ、LLMの効果と同時に起きた他の変化の効果を区別しにくい
    • 内的妥当性には、ツールがなかったら何が起きていたかを示す信頼できる反事実が必要である

  • 志願者と非志願者を比較する

    • LLM利用を選んだ開発者と選ばなかった開発者を比較すると、2つの条件ではなく、異なる2つの集団を比較することになる
    • 早期導入者は、後期導入者や非導入者より実験意欲が強く、新しいツールに慣れており、すでに高い成果を上げている可能性が高い
    • 選択バイアスのため、観察された差はツールの性質ではなく、人の性質かもしれない
    • この方式は実施コストが最も低いため、産業界のAI生産性レポートでよく見られる設計上の欠陥になっている
    • 大規模IT組織でCopilot利用を2年間追跡した縦断研究では、ツール導入前からユーザーは非ユーザーより一貫して活動的だった

  • AIと「何もない状態」を比較する

    • AI支援開発者を何のツールも使わない対照群と比較すると、実務には存在しないベースラインを選ぶことになる
    • LLMアシスタントがない開発者も、ドキュメント、同僚、自分で問題を考える時間を使っている
    • 重要な問いは、LLMツールが開発者の既存の代替手段より優れているかどうかであり、この比較はめったに行われない
    • 弱いベースラインを選べば、どんなツールでも良く見えるが、それが実際の有用性を意味するわけではない

測定範囲の欠落

  • 簡単な半分だけを測る

    • LLMはコード生成をより速くし、この部分は測定しやすい
    • より難しい半分は、LLM生成コードのレビュー時間、自信満々に間違った提案によって失うデバッグ時間、もっともらしいが安全でないコードが生むセキュリティ脆弱性、周辺設計を無視した場当たり的な解決策が生む技術的負債である
    • GitHub Copilotコード研究では、生成コードのかなりの部分にセキュリティ脆弱性があり、時間的プレッシャーを受けた開発者ほど安全でない提案を高い割合で受け入れた
    • 2025年の主要LLM 5種の評価では、どのモデルも業界のセキュリティ標準を満たすWebアプリケーションコードを生成できなかった
    • AIが書いた30万件超のコミットを大規模分析した結果、15%以上が少なくとも1つの品質問題を持ち込み、そのうちほぼ4分の1はコードベースに長期的に残った
    • 増えた入力だけを測り、同時に増えたコストを無視するなら、それは測定ではなくマーケティングである

  • 個人ではなくシステムを測るべき

    • 個人のコーディング速度は最も測りやすいため、よく測定される
    • AIツールが開発者にコードを30%速く書かせても、チームのチケットから本番反映までのリードタイムが変わらないなら、ボトルネックはコード記述ではなかった
    • 生成コードが増えれば、レビューすべきコードも増え、AIがコード量だけを増やしてレビュー能力を増やせなければ、サイクルタイムは悪化しうる
    • 専門開発者を対象にした実証研究では、AIツールは経験の浅い貢献者のアウトプットを増やした一方で、シニア開発者はAI生成コードによるコードレビュー負荷が6.5%増え、自身の生産性が19%低下した
    • パイプラインの1段階だけを最適化し、残りを無視するなら、それは生産性研究のように見えるシステム思考の失敗である

時間による効果の歪み

  • 開発者に生産性が上がったかを尋ねる

    • 「開発者の87%がAIツールでより生産的だと感じる」というアンケート結果は、ツールが機能している証拠としてよく引用される
    • 自己申告は3つの理由で体系的な誤解を生みうる
    • ホーソン効果により、人は観察・評価されていると知ると普段と異なる働き方をする
    • 新しいツールは新しいがゆえに、より速くなったように感じる新奇性効果を生み、この感覚は通常数週間で薄れる
    • 社会的望ましさバイアスにより、回答者は、特に経営陣がツールを選んだとき、アンケートが聞きたがっていると自分が信じる答えを返しがちである

  • 新奇性効果の期間だけ測る

    • 4週間の研究が生産性向上を見つけたとしても、それは4週間の生産性向上しか見つけていないということだ
    • 開発者は初期期間に新しいツールへより深く関与するため、観察された成果は長期ベースラインより水増しされている可能性がある
    • 本当に重要な効果は、数週間ではなく数か月にわたって現れる
    • AIに委任した作業でのスキル劣化、誤った提案から蓄積する技術的負債、チームの協業方法の変化には、長期観察が必要である
    • 短期的な利得を検出するよう設計された研究は、研究終了後に何が起きるかを教えてくれない
    • Cursorを導入した807件のオープンソースリポジトリ分析では、導入後に開発速度が大きく、しかし一時的に増加し、コード複雑度と静的解析警告は大幅かつ持続的に増加した

より良い解釈のための結論

  • 生産性測定は、単一の数字や簡単な代理指標に還元しにくい
  • LLM支援コーディングの効果を判断するには、コード記述速度だけでなく、レビュー、デバッグ、セキュリティ、保守性、技術的負債、チームのボトルネック、長期的変化まで併せて見る必要がある
  • 対照群、現実的なベースライン、選択バイアスの統制、長期観察、システムレベルの指標がなければ、AIツールの効果と他の変化の効果を切り分けにくい
  • 測定しやすい値は報告されやすいが、簡単な値が重要な値の代わりになるわけではない
  • ソフトウェア開発プラクティスを評価するには、人間科学の研究方法をより真剣に受け入れる必要がある

引用された主要資料

関連記事

1件のコメント

 
GN⁺ 2 시간 전
Lobste.rs の意見

  • 筆者は Software Carpentry の創設者の一人で、LLMが登場するはるか以前から、ソフトウェア生産性の測定をより良く行う方法を考えてきた人物である。
    引用されているMETRの研究は、よくある受け取られ方よりもずっと興味深い。多くの人にとって見出しは「AIが人を遅くした」だったが、これは2025年型のLLMは今も改善中だ、という形で反論できる。
    しかしさらに興味深い結果は、事後に本人たちが推定した値が、実際の結果と方向性すら一致していなかった点である。ここには、ほとんどの企業が無視している、あらゆる測定を根本的に難しくする要素があるように思える。
    ツールが人をより生産的にするという漠然とした感覚ですら信頼できない。人は自分でもわかっていない。
    続く後続研究は、選択バイアスのため事実上失敗している。

    The primary reason is that we have observed a significant increase in developers choosing not to participate in the study because they do not wish to work without AI
    開発者がAIなしで働くことを拒否するのは、ツールがうまく機能していることを意味するのかもしれないし、ツールへの依存が進んで、より難しい作業をこなす能力が完全に衰えてしまったことを意味するのかもしれない。

    • 私の仮説では、人は実際にやりたくない部分ほどLLMに頼る傾向があり、やりたくない作業をしているときは、時間は常にずっと遅く感じられる。

  • 「新しいツールは新しいというだけで速く感じられ、その感覚はたいてい数週間で消える」という話は、逆のように思える。
    新しいツールは慣れていないので、いつも私を遅くする。もちろん、より速くなる可能性は見えるが、まだ効果的に使えていないからである。

    • これに関連する効果がもう一つある。特に新しいツールを自ら進んで試す人は熱意があるので、不足を埋めようとして勤務時間外にもさらに働く。
      しばらくは印象的に見えるが、最終的には通常の働き方に戻るにつれて自然に消えていく。

  • 測定は難しい。ある意味では、AI支援コーディングを測定しようとすること自体が間違いなのかもしれない。
    ある種の作業を速くするのは確かであり、より速くなる使い方もほぼ確実に存在するはずである。
    より重要な問いは、その方法が何であり、その過程で何を失うのか、ということになる。

    • 生産性と作業速度の向上は別物である。ある作業が速くなっても、その作業がボトルネックでなかったり、速度向上にコストが伴ったりするなら、生産性にプラスの影響がない可能性がある。
      原文でもこれを「簡単な半分だけを測定すること」として扱っている。

  • 「来週、マネージャーが会社で契約しているAIコーディングツールが購読料に見合う価値があることを示せと言ってきたら、生成されたコード行数を測るのか、クローズしたチケット数を測るのか？」という問いについて、Claudeはすでに請求明細でコード行数、受け入れ率、トークン使用量を測定している。
    クローズしたチケット数はチームのベロシティだろうが、AIの出力はその一部の要素にすぎず、Jiraがスプリント速度を測定している。
    いずれにせよこの問いは、マネージャーが求める成果物を何だと考えるか次第で簡単に操作できるし、おそらくすでにそうなっている可能性が高い。

  • 筆者は非常に重要な問いを落としているように思える。それは「AI利用はどんな害を引き起こすのか？」である。
    私はこの問いのほうが、他のどの問いよりも根本的だと思う。害のほうが、測定するのがずっと簡単だからだ。Git forgeを一つ立てて、クローラーたちが血の匂いを嗅ぎつけたサメのように群がるのを見ればよい。
    スクレイパーがインターネット全体にDDoSを仕掛けるのは測定可能な問題であり、セルフホストしている人にとってはそれぞれが肌で感じる現実である。
    私たちがまともに測定することすら難しいAIのいわゆる利点は、クローラーが引き起こす非常に現実的な害を受け入れるだけの価値があるのだろうか？
    クローラーの運用とそのリクエスト処理にかかるエネルギー、学習コスト、推論コスト、さらにますます大規模になるデータセンターの必要性まで加えたらどうだろうか？
    AIのそうしたいわゆる利点が、これらすべてを犠牲にするだけの価値があるのかを問うほうが、はるかに重要な問いだと思う。

    • この種の「私たちはXについて語るべきだ」という問題でいつももどかしいのは、生態学的被害を扱う文章では、その正反対の主張を目にしたことがある点だ。
      「たとえこれらがエネルギーを使わなかったとしても、依然としてひどいコードを生み出すのだから、その話のほうがはるかに重要だ」とか、「なぜコーディングの話をするのか、本当の害は監視に使われることだ」といった具合に、延々と話がずれていく。