AIコーディングは、いつ開発を速め、いつ遅くするのか

査読前プレプリントであるMaierらのメタ分析は、2019年から2025年までの研究を系統的に探索し、23研究・27効果量を統合しました。生産性については16効果量を分析し、生成AI支援の統合効果をHedgesのgで0.33、95%信頼区間0.09〜0.58と推定しています。一方、研究間の異質性はI²=99%でした。[1] 平均値が正であることと、自社の特定業務で正になることは別の問いです。

同じメタ分析では、統制された実験室課題の効果はg=0.73で有意でしたが、企業環境はg=0.19、OSS環境はg=0.01で、後二者はゼロとの差を確認できませんでした。[1] 研究環境だけで異質性の約36%を説明します。短く構造化された課題の改善率を、既存システムの保守、調整、レビューを含む開発全体へ移すと、期待値を過大に置くおそれがあります。

• 課題の境界と合格条件を事前に固定できるか
• AIが必要な仕様・依存関係・組織ルールを参照できるか
• 生成結果をテストや型検査で低コストに検証できるか
• 実装後のレビュー、差し戻し、保守まで同じ計測窓に入るか

Cuiらは、Microsoft、Accenture、匿名のFortune 100企業で、計4,867人の開発者にGitHub Copilotへのアクセス時期を無作為に割り当てました。無作為なアクセス割当を操作変数にした推定では、週次プルリクエストが26.08%増え、コミットは13.55%、ビルドは38.38%増える方向でした。[2]

ただし企業別推定は不精確で、統合した主要指標のうち通常の有意水準に達したのはプルリクエストです。これは全員へ配れば出力が26%増えるという推定ではなく、実験によって利用を始めた人に近い効果です。

査読前ワーキングペーパーであるPengらの初期RCTでは、Upworkで募ったプロ開発者95人を無作為化し、JavaScriptのHTTPサーバーを作らせました。課題を完遂した各群35人だけを比較すると、平均時間は71.17分対160.89分で、AI群が55.8%短時間でした。一方、成功率の7ポイント差は統計的に有意ではありませんでした。[4]

小さく自己完結し、自動テストで正否を確認できる新規課題では大きな短縮が起こり得ますが、未完遂者と長期品質を含まない点が重要です。

• 定型コード、雛形、テスト作成など、出力の形が明確な仕事
• 未知のAPIや不慣れなコードを探索し、候補を早く得る仕事
• テスト、型、静的解析で、誤りをすぐ機械検証できる仕事
• 担当者が提案を採用せず、自力実装へ戻る判断をしやすい仕事

査読前プレプリントであるBeckerらの研究は、成熟したOSSを継続的に保守する熟練開発者16人に、実在する246件の課題を割り当て、課題ごとにAI利用可否を無作為化しました。参加者は対象リポジトリで平均5年の経験を持ち、主にCursor ProとClaude 3.5／3.7 Sonnetを使いました。AIを許可した課題では、実装とレビュー後修正を含む完了時間が平均19%増え、95%信頼区間も2%増から39%増でした。[3]

興味深いのは知覚とのずれです。参加者は開始前に24%の短縮を予想し、研究後も20%短縮したと推定していました。[3] しかし画面記録と聞き取りでは、大規模コードの暗黙文脈、低い生成信頼性、出力の確認・修正が負担になった可能性が示されました。機序分析は探索的ですが、熟練者が記憶から正確に解ける仕事では、AIへの説明、待機、検証が新しい作業として加わるという解釈と整合します。

• 担当者だけが知る設計理由や例外が多い
• 局所的に正しい変更でも、別領域へ副作用が及ぶ
• レビュー基準が厳しく、説明可能性や保守性まで求める
• 誤った候補を見抜くまでの時間が、自力実装より長い

開発者がAIを使う案件を自分で選ぶと、利用案件と非利用案件の難しさや不慣れさが最初から違う可能性があります。単純な利用者比較では、その差をAI効果と誤認しかねません。推奨する社内検証では、利用可否を事前に割り当てる期間と、自由選択の期間を分け、割当、実利用、途中離脱を別の変数として保存します。これは新しい効果量の主張ではありません。

割当を実施できない場合は、同じ開発者、近い課題類型、同程度のコード範囲、同じレビュー基準で案件を組にします。それでも未観測の難しさは残るため、因果効果と断定せず条件付きの差として報告します。AIが許可されても使わなかった理由と、禁止されても別経路で使った可能性を確認し、アクセスと利用を同じ扱いにしません。

仮想例です。不慣れな領域だけAIを使い、既知の保守は自力で行うチームでは、AI利用案件の完了時間が長くても害とは言えません。反対に簡単な定型案件だけAIへ送れば効果を過大に見せます。割当前の難度見積りと担当者の熟知度を固定し、結果を見た後に分類を変更した場合は、新しい比較版として再評価します。

成熟OSSの実験で観測された完了時間の増加について、AIへの説明、待機、検証が追加作業になったという解釈は研究結果と整合しますが、個々の要因の因果寄与が確定したわけではありません。[3] 自社では、作成者の入力時間だけでなく、レビュー待ちと他者の確認時間を分けて観測し、この説明が再現するかを確かめます。

作成者が速くPRを出しても、変更が大きくなり、レビュー列が伸び、後続案件が待つなら、個人の短縮がチームの完了量へ移っていません。推奨する計測では、AI利用PRと非利用PRの作成、初回レビュー待ち、指摘対応、再承認を同じ時計へ置きます。レビュー者がAI出力かどうかを知ることで確認行動が変わる可能性も記録します。

仮想例です。実装時間が短くなった一方、二人のレビュー時間が増えた場合、単純に相殺せず、どの指摘類型が増えたかを調べます。形式やテスト不足なら生成条件、設計意図の説明不足なら引継ぎ、広い副作用なら適用範囲が修正候補です。変更量を減らして再試験し、待ち時間が戻らない区分は自動拡大しません。

• 作成工程：理解、生成、検証、自力修正に使った時間を分ける
• 待ち行列：初回レビューまでの時間と同時滞留件数を記録する
• 他者負荷：レビュー、質問、差し戻し、再承認の担当時間を結ぶ
• 裁定：指摘類型ごとに生成条件・引継ぎ・適用範囲の修正先を決める

全社共通の改善率を置く代わりに、業務を検証容易性、コードベース熟知度、文脈量、失敗影響で層別します。各層でAIあり・なしの比較期間を設け、issueの着手からマージ、レビュー、再作業までを同じ時計で測ります。PR数が増えても、分割が細かくなっただけなら顧客価値は増えていません。

継続条件も導入前に決めます。例えば、完了時間が短縮しても差し戻しや障害が増えた層は対象外にし、探索や定型実装だけへ用途を狭めます。逆に、不慣れな領域の立ち上がりが速くなり、品質が維持された層は教育と標準手順へ組み込みます。ROIはアカウント数ではなく、品質調整後の完了量から確認します。

開発責任者は、業務層・課題群・ツール版を導入判定票に固定し、品質調整後完了量の下限と、差し戻し・障害・重大脆弱性・確認時間の上限を層ごとに定めます。上限超過または下限未達の層だけ利用を止め、直前の標準工程へ戻します。教育または工程の変更後、同じ課題群で二回の観測期間にわたり全条件を満たしたことをDevEx責任者とAppSec責任者が承認してから再開します。

• 速度：着手からマージまでのリードタイムと人間の実作業時間
• 品質：レビュー指摘、差し戻し、欠陥、障害、後日の修正量
• 利用：提案の採用率、破棄率、自力実装へ戻った時点
• 能力：AIなしでも説明、デバッグ、変更できる状態を保てたか