10月28日、James Shoreが「Are You Getting Your Money's Worth From AI?」と題した記事を公開した。AI投資のROIをエンジニアリング組織がどう正しく測定すべきか、そして陥りがちな誤った指標の使い方について詳しく論じた内容だ。なかでも衝撃的なのが、METRの研究が示した「体感49%向上→実測19%低下」という知見であり、AIが生産性を高めているという自己申告がいかに当てにならないかを端的に示している。

「体感」は信用できない

METRの研究では、経験豊富なエンジニアたちが「AIによって49%速くなった」と感じていた一方、実際の計測では19%遅くなっていたという結果が出た。自己申告による生産性評価は系統的にバイアスがかかっており、信頼できない。測定しなければ、AIから何を得ているかは本当にわからない。

この乖離は偶発的なものではない。AIが「作業している感」を生み出す一方で、生成されたコードのレビューや修正、想定外の副作用への対処といった見えないコストが積み上がっているためだ。

AIのコストは「今だけ」ではない

あるCIOはこう語った。170人の組織でAIを導入したところ、生産性が2.1倍になった。しかしそのコストは、AIのトップユーザーが月21,000ドルのトークン費用を消費するほどのものだった。別のエンジニアリングリーダーは1人あたり月6,000〜8,000ドルを支出しているという。

これだけの額になると、予算はいずれ人件費から捻出されることになる。AIへの投資は、単なる技術選定の話ではなく、実際の雇用に影響する意思決定だ。

コスト計算でもう一つ注意すべき点が補助金（サブシディ）だ。市場シェア獲得のために、AnthropicやOpenAIは大幅な割引を提供している。あるエンジニアリングリーダーによれば、チームメンバーが月200ドルのサブスクリプション料金で、実際には数千ドル相当のトークンを消費しているケースもあるという。これらの補助がいつ終わるかは誰にもわからない。

一方で、オープンウェイトモデル（重みが公開されており、手元の環境で動かせるモデル）やローカル推論（端末上でモデルを動かす手法）、専用推論チップの登場がトークン単価を押し下げる方向に働いてもいる。ROIを試算する際は、「現在の価格が将来も続く」と仮定するのではなく、楽観シナリオと悲観シナリオの両方をモデル化することを著者は推奨している。

さらに、AI導入は「スイッチを入れる」ように即効性があるわけではない。習熟にかかる時間や変化管理のコストを無視すると、導入初期の測定値が実態を誤って伝えるリスクがある。

「使ってはいけない指標」が核心

この記事で最も実用的な部分は、よく使われるが誤った指標を明確に否定している点だ。

コード行数（Lines of Code）はNG

エンジニアリングの世界では半世紀以上前から、コード行数は生産性と対応しないことが知られている。同じ機能でも、1,000行で実装したほうが10,000行より保守しやすくバグも少ない。AIは冗長なコードを大量生成することで有名であり、行数を測定することは「質」ではなく「雑さ（slop）」を測定することになる。

プルリクエスト数もNG

プルリクエスト（PR）は、コードレビューを依頼するチェックポイントであり、その粒度は完全に任意だ。10行のPRも10,000行のPRも、どちらも「1件」としてカウントされる。

従来、エンジニアが出すPRには一定のリズムがあり、PR数がある程度の開発ペースを反映していた。しかしAIは膨大なコードを一瞬で生成するため、そのリズムが崩れる。エンジニアのレビュー能力を超えた速度でコードが量産されれば、PR数はもはや生産性の指標として機能しない。さらに、PR数が評価基準になれば、**Goodhartの法則**が働く。

「ある指標が目標になった瞬間、それは良い指標でなくなる」
— Robert D. Austin『Measuring and Managing Performance in Organizations』

Goodhartの法則とは、もともと経済政策の文脈で提唱された原則で、「測定値を目標に設定すると、人々はその数値だけを最適化し始め、本来の目的から外れてしまう」という現象を指す。PR数やコード行数を評価指標にした瞬間、エンジニアはそれを増やすことに最適化し、実際の成果とは無関係なゲーミングが始まる。

アプローチを測定する、人を測定しない

著者が最も強調するのは、これらの指標を個人やチームの評価に使ってはいけないという点だ。測定の目的は「どのAI活用アプローチが機能しているか」を判断することであり、人事評価ツールではない。指標を目標に変えた瞬間、ゲーミングが始まり、測定値は実態から乖離していく。

測定したら、学んで、測定をやめる。これが著者の推奨するサイクルだ。特定のアプローチの効果を確認し終えたら、その指標への執着を手放し、次の問いに移ることが重要だという。

速度だけでは不十分

短期の生産性向上だけを見るのも危険だ。機能を2倍速く出せても、保守コストが2倍になれば生産性は長期的に急落する。加えて、スペック駆動開発（Spec-driven development：仕様書を先に整備し、それをもとにAIにコードを生成させる手法）を採用しているあるエンジニアリングリーダーは「すべてのチームがバーンアウトを報告している」と語った。疲弊したエンジニアは問題を報告しなくなり、最終的に組織を去る。速度の数字だけを追うことで、こうした組織的な劣化が見えなくなるリスクがある。

本稿はシリーズの第1部であり、続く記事ではデリバリー速度の測定手法、AI利用の意図しない副作用の計測、そしてビジネス成果のモデル化が順に解説される予定だ。

詳細はAre You Getting Your Money's Worth From AI?を参照していただきたい。