AIバニティ指標の台頭：なぜコード行数が生産性の代理指標として復活しているのか

ソフトウェアエンジニアリング業界は現在、AI コーディングアシスタントの導入とインパクトを正当化するために、ボリュームベースの指標、特にコード行数（LoC）の復活を経験しています。業界は何十年も LoC を開発者の生産性指標から遠ざけてきましたが、現在の AI ベンダーやテックエグゼクティブの主張は、ビジネス成果よりも生成されたコードの量にほぼ焦点を当てています。

ボリューム主張 vs. 成果主張

現代の AI 生産性主張は、成果（何が達成されたか）からボリューム（どれだけ生産されたか）へとシフトしています。GitHub Copilot のようなツールに対する初期の主張は、タスク完了速度に焦点を当て、たとえば「開発者はタスクを 55% 速く完了した」というものでした。対照的に、2026 年の業界主張は AI が書いたコードの割合に注目しています。

Google: 新規コードの 75% が AI 生成であると報告。
Anthropic: マージされた本番コードの約 80% が Claude によって作成され、エンジニアは「四半期あたり 8 倍のコード」を出荷していると主張。
OpenAI: 同様にコードの約 80% が AI 生成であると主張。
Cursor: 「1 日あたり 1 億行以上のエンタープライズコード」が書かれていると報告。

これらのボリューム指標は実質的に「バニティ指標」です。ソフトウェアの品質、信頼性、ビジネス価値が向上しなくても増加し得るからです。AI が書いたコードの割合が高いことは、必ずしもデリバリーの高速化、インシデントの減少、収益の増加と相関しません。

AI 生産性エビデンスの複雑さ

AI が生産性に与える実際のインパクトを測定することは複雑で、研究はしばしば矛盾した結果を示します。この不一致が、多くの組織がシンプルなボリュームカウントに戻る理由です。

矛盾する研究結果

ポジティブな効果: Cui らの研究などはタスク完了が 26% 増加したと示し、特にジュニア開発者で顕著な効果が見られました。
品質への懸念: GitClear の調査では、Copilot の採用が深まるにつれてコードの churn が増加し、リファクタリングが崩壊していることが示唆されています。
パフォーマンスのパラドックス: METR の研究は当初、経験豊富なオープンソース開発者は自分のコードベースで AI を使用すると 19% 遅くなると報告しましたが、本人は 20% 速くなっていると信じていました。その後 METR は結果を更新し、スピードアップを示唆しましたが、開発者が AI なしでは作業を拒否するようになり、クリーンな測定がほぼ不可能になったと指摘しています。
組織への影響: NBER の約 6,000 人のエグゼクティブを対象とした調査では、69% の企業が AI を使用しているものの、約 90% が測定可能な生産性インパクトを報告しておらず、組織的な利益はおおむね 10% 前後という合意が得られました。

理解力のギャップ

ボリュームが増加しても、コード理解力は低下する可能性があります。Anthropic が実施した RCT では、AI 支援開発者は出荷したコードの理解度で 17% 低いスコアを示し、統計的に有意な生産性向上は見られませんでした。

AI を人員削減の正当化材料として利用

ボリュームベースの指標は、大幅な人員削減を正当化するために利用されています。例として、ジャック・ドーシーは 2026 年 2 月に Block の従業員を 40% 超（4,000 人以上）削減し、AI が「小規模なチームでもより多く、より良くできる」という核心的な仮説を根拠に挙げました。同様に Atlassian も約 10% のスタッフを削減し、AI が必要とするスキルミックスと役割数を変えることを認めています。

批評家は、もし AI が本当に大幅な生産性向上をもたらすのであれば、企業はその「余剰人員」をロードマップの加速や顧客価値（MAU や収益）の向上に使うべきであり、単に人員を削減すべきではないと指摘します。AI をレイオフの正当化に用いることは、生産性主張が実はパンデミック期の過剰採用や投資家圧力といった他の要因に基づく意思決定の PR にすぎない可能性を示唆しています。

コミュニティ視点の総合

LoC 指標の復活に関する技術的議論は、いくつかのシステム的リスクを浮き彫りにしています。

コードの負債性

多くのエンジニアは、コード行数は資産ではなく負債とみなすべきだと主張しています。あるコミュニティメンバーが指摘したように、長期的な保守負担を減らすために、必要最小限のコードで機能を実装することが目標です。

「ディーゼルキーボード」誤謬

一部は LLM を「ディーゼル駆動のキーボード」と見なし、タイピング速度は上がっても問題解決速度は変わらないと主張します。実際のプログラミングの大部分はタイピングではなく、ソフトウェア開発ライフサイクル（SDLC）全体へのインパクトは、官僚的レイヤーや人間のレビュー必要性によって制限されます。

レビューのボトルネック

AI が生成するコードが増えるにつれ、人間によるレビュー工程が主要なボトルネックとなります。リスクは「品質を犠牲に量を追求」する方向へシフトし、コード量は増えても人間が実際に理解・レビューするコードの割合が減少することです。

結論：本当に重要な指標を測る

AI ツールの導入は現代開発者にとって実務上の必須事項ですが、導入はスタートラインであり、スコアボードではありません。バニティ指標の落とし穴を避けるため、組織は実績のあるエンジニアリング指標に立ち返るべきです。

DORA 指標（デプロイ頻度、変更リードタイム、変更失敗率、サービス復旧時間）。
本番環境の信頼性と安定性。
意味のある変更率（ビジネス価値を生む機能）。
収益と顧客価値（最終的な成功指標）。

AI 生産性主張を評価する際の重要な質問は、提示された指標が成果（価値の測定可能な向上）か ボリューム（どれだけ生産されたか）か、という点です。