ビールを捧げよ：AI 生産性議論における「量」と「結果」の偽像

15 年前から業界に携わってきた私にとって、開発者の評価は長年変わってきました。今回は、AI 採用（AI Adoption）に関する現状と課題、そして何より重要なのは**「成果」をどう測るか**について考察します。

📉 コード行数という時代錯誤な指標

かつての業界常識はもう通用しません。開発者の評価における以下の要素は不適切です。

• コード行数: 15 年前から学ばれているように、単純な量での評価は時代遅れです。
• プルリクエストの数: 提出回数自体が能力の証明にはなりません。
• 適切な評価基準:
  • 実際にリリースされた実績
  • クスタマーへの付与される価値
  • 収益向上への貢献
  • システムの信頼性向上

今日、AI ベンダーが主張する「コード出荷量」という指標は、単なる「量の主張」に過ぎません。これは広告効果（Publicity）によるものではなく、実質的な優劣を測るには無意味です。

💡 重要: 「採用拡大」こそがベンダーにとっての真の目的であり、彼らはそのためだけに誇張した数字を発表しています。

🚀 業界における「量の暴走」とその本音

今年（2026 年）に各主要プレイヤーから発表された主な主張は以下の通りです。これらはすべて**「ビラ板に掲げている」**事実ですが、実体とは異なります。

• Google: 新規コードの 75% が AI によって生成
• Anthropic: マージされた本番コードの約 80% を Claude が執筆、出荷量を 8 倍に
• OpenAI: 同様に約 80% の比率を主張
• Cursor: エンタープライズコードで 1 日あたり 1 億行 の作成実績

「かつて主張していたもの」との違い

かつては「Copilot を活用するとタスク完了速度が 55% 向上」など、**検証可能で価値に焦点を当てた「成果」**に関するデータでした。

時代	主張の性質	特徴
過去	結果志向	開発速度向上、検証可能性あり
現在	量志向	事実上正しいが、品質・成果とは無関係な数字

現在の「量の指標」は、生産性が向上していなくても採用量だけが上がれば数値は良くなるという致命的な欠陥を持っています。この種の主張は大きくなりすぎて逆に何も言えなくなっている状態です。

🔍 「誰も発表していない真実」と研究結果の複雑性

成果に関する証拠は複雑化しており、単純なプラスまたはマイナスではなく、以下のような現実が見えてきます。

1. 一見良いデータも裏側には...

• Cui らの研究 (5,000 名): タスク完了率が +26% 向上（若手開発者で顕著）。ただし、これは事実。
• GitClear の指摘: Copilot の採用が深まるにつれ、コードの移動率（Churn）が増加し、リファクタリングの質が低下した。
• METR 研究グループ (初期): 経験豊富な開発者が「AI を使えば 20% 速い」と思い込んでいるが、実際にはベースラインに対して 19% 遅い と評価された（矛盾）。

2. メトリカス（METR）の撤回と見直し

• 2026 年 2 月、METR は事実上の撤回を行いました。
• 理由: 誤差範囲が広すぎるため測定不能であり、開発者が AI がなければ働かなくなるなどのバイアスで自己報告が歪んでいるから。
• 現在の結論: 「AI は速度を向上させているかもしれないが、どの程度かは測定できない」

3. 企業レベルの実態（NBER 調査：6,000 名の経営者）

• 69% の企業が AI を実際に活用している。
• そのうち約 10/9 が「測定可能な生産性への影響がない」と報告している。
• 組織的な成果: 研究ごとのコンセンサスはわずか 10% に留まる。

⚠️ 注意点: 「19% 遅い」という引用のみを行うのは、選択的データ提示（Cherry-picking）であり誤解を招きます。

🎭 「虚飾的な指標」の AI バージョン

公平を期すために、AI ベンダーだけが罪人ではありません。企業やコンサルティングファームも同様の手法を採用しています。

• カリフォルニア大学コロンビア校 SEI と Accenture:
  • 「AI 採用成熟度モデル」を販売。
  • 組織の 95% が成果を得ていないという統計に基づき、5 つのレベル・8 つの次元で分類する。
• Steve Yegge の「AI 補助開発 8 レベル」:
  • ツールの実行量や監督レベルでランク付け。
  • **最高位は常に「我々の製品をより多く使うこと」**です（成熟度ではなく採用率の計上）。

Anthropic: 両面を持つ例

• 「出荷量が 8 倍増」という主張: マーケティング部門による量のカウント。
• RCT ランダム化比較試験: AI 支援開発者がコード理解度のスコアで 17% 低い という事実を公表（最も厳格な研究の一つ）。
• 結論: 製品は優秀であるが、マーケティングと研究の結果は両方とも真実であり、矛盾しているように見える。

🧐 皮肉: 「AI ネイティブなエンジニアリング」の定義を聞いた際、219 名のリーダーから出た答えがなんと219 の異なるものだった。

⚡ なぜ「虚飾的な指標」に懸念すべきか

これらの数字は単なるお遊びではありません。予算配分、パフォーマンス評価、人員計画を動かす強力な要素です。

具体的な事例

• Block (Jack Dorsey): AI を核心テーゼとして労働力を 40%（4,000 名以上）削減。「少ないチームで質の高い成果を出す」と主張。
• Atlassian: 10%（約 1,600 名）の人員削減を実行。
  • 「AI がスキルミックスや役割を変えている」と認めつつ、
  • **「事業は健全で粗利益は成長している」**と並べている。

企業の真意とは？

企業が「AI で全員が生産性が高まったため人間はいらない」と言う際、以下の証拠を求めても存在しません。

1. X% の労働者が本当に無能（または未利用）になっていることの証明。
2. 余剰人員を顧客価値の加速に回さずレイオフする理由。
   • もし人手不足が解消されれば、その余力は MAU や収益向上として現れるはず。

🎰 本質: 生産性の主張だけで人員を減らすことは、「化粧を施したロトリー（宝くじ）」を選ぶのと同じです。それは過剰採用や投資家の圧力によるものであり、AI の恩恵ではありません。

正しい効率化とは

• エンジニアリングロードマップは永遠に続くものではありません。
• 効率化が必要なら、**「誰が快適に働いていて、誰が関与していないか」**という従来のパフォーマンス評価システムを使うべき。
• 指標はトークン数や「AI コード作成率」ではなく、実質的な成果に基づくべきです。

💡 私たちの結論：どうあるべきか

この議論を「AI 反対」と誤解しないでください。私はエンジニア全員が毎日 AI を使うべきだと考えています。

エンジニアリングへの姿勢

• 好奇心を持つ: 新しいツールを試し、最新モデルを検証する。
• AI ファースト / AI プロフィシエントを目指す（如何なる呼称でも）。
• 変化の加速: クラウド移行は数年かけて可能でしたが、AI は数ヶ月単位で変わります。逆戻りは不可能です。

評価基準に戻ろう

エンジニアリングが価値を交付しているかを測るには、以下の戦場で試された頑固なメトリクスを使用します。

• DORA メトリクス
• システムの信頼性
• 意味のある変化の頻度
• 収益および顧客価値

ビジネスへの問いかけ

ベンダーとの交渉や経営陣へのレビューで問うべき核心は：

❓ 「これは『成果』なのか、それとも『量』なのか？」

この問いを投げかければ、立場や主張がいかに脆いかが一瞬で見破れます。

最終的な推奨事項

• 働き方: AI ファーストに臨む。
• 測定方法: 戦場で試された実績ベースのものを選ぶ（トークン数ではない）。

変化は続きますが、ツールも良質です。「すでに測定すべきもの」は知っていますし、それは単なる数字ではありません。

Cheers, Dave