AI研究機関のMETRは2026年2月、開発者のAIコーディング生産性を再測定しようとして予想外の壁にぶつかった。開発者たちが「AIなしでは作業したくない」と実験への参加そのものを拒否したのだ。この一件は、AIツールへの依存がエンジニアの働き方の根幹にまで浸透しつつあることを如実に示している。

METRが直面した衝撃の現実

METRは2025年末、AIツールが開発者を「実際には遅くしていた」という驚くべき研究結果を発表していた。開発者はAIによって生産性が上がったと感じていたが、実態はコード生成後のエラー修正・AIの誘導・待ち時間のせいで手作業より時間がかかっていた。

その研究のフォローアップとして再実験を試みたところ、今度は開発者が参加を拒否した。AIなしで一時的にでも作業することを、多くの開発者が受け入れられなくなっていたのだ。

METRはやむなく自己申告式の調査に切り替えた。結果、開発者たちは「AIによって自分の価値が2倍になった」と回答した。だがこの数字をそのまま信じていいのか、というのがその後の一連の研究が問いかけていることだ。

「トークンマキシング」の功罪——AmazonとUberが学んだ教訓

2026年のエンジニア界で流行したのが「tokenmaxxing（トークンマキシング）」——AIのトークン消費量を生産性の代替指標として使う手法だ。使えば使うほど生産的、という発想だが、これが裏目に出た企業事例が相次いでいる。

Amazonは社内でAI利用量を競わせる「Kirorank」というランキングシステムを導入したが、従業員がランキングを操作するためにAIエージェントを過剰に使いコストを浪費し始めたため、Financial Timesの報道によれば廃止を余儀なくされた。

Uberは2026年の年間AI予算をわずか4カ月で使い切ったと報じられた。COOのAndrew Macdonaldはポッドキャストで「その支出がプロジェクト数や生産性の明確な向上につながっていない」と率直に認めた。

数字だけを追った結果が何をもたらしたか、両社の経験は雄弁に語っている。

AIコードは「負債」を生む——3つの研究が示す維持コストの増大

速く書けるから何でもいい、では済まない現実がある。

プログラマー・著者のJames Shoreのブログ記事がHacker Newsで話題を呼んだ。彼の指摘はシンプルだ。「コードを2倍速く書けるようになった？ならメンテナンスコストも半分になっていなければ意味がない。そうでなければ一時的なスピードアップと引き換えに永遠の負債を背負うことになる」。

具体的なデータもある：

  • Entelligence AI（信頼性エンジニアリング企業） のCEO・Aiswarya Sankarによれば、企業はトークンの44%をAI自身が生み出したバグの修正に費やしている
  • コードレビューツールのCodeRabbit が分析したオープンソースPRでは、AIが生成したコードは人間のコードより1.7倍多くの問題を引き起こしていた
  • シンガポール経営大学（SMU） の2026年4月の独立研究では「AI生成コードは実際のソフトウェアプロジェクトに長期的なメンテナンスコストをもたらす」と結論づけた

なお、CodeRabbitとEntelligence AIはAIコードレビューツールを販売する企業であり、利益相反の観点から割り引いて見る必要はある。ただしSMUの独立した研究が同様の懸念を裏付けている点は重要だ。

実務への影響——日本のエンジニア・IT管理者が今すぐ考えるべきこと

生産性指標を「トークン量」から「成果」へ切り替える

「AIをどれだけ使ったか」ではなく「何を達成したか」を測る指標に移行する時期だ。Amazonのランキング廃止は他人事ではなく、社内でAI活用を推進している組織すべてが向き合うべき設計課題だ。

AI生成コードのレビューゲートを設ける

速く書けても品質の検証プロセスがなければ技術的負債が急速に積み上がる。既存のコードレビューフローがAI生成コードの量増加に対応できているか確認したい。レビューをAIに任せる選択肢も含めて、ゲートの設計が今後の鍵になる。

「AIなしでは動けない」状態を組織的に把握する

特定ツールへの過度な依存はベンダーリスクでもある。基礎的な開発スキルとAI活用の両立を意識し、どのプロセスでどの程度AIに頼っているかを可視化しておくことが組織のレジリエンスにつながる。

AIエージェントの能力を正しく見積もる

Cognition社の「Devin」のようなAIコーディングエージェントは、同社CEOですらジュニア〜ミッドレベル相当と評している。「任せっきりで完結する」という期待は禁物で、人間による監督・修正のコストを必ず見込んだ工数計画が必要だ。

筆者の見解

この一連の研究が示す問題の本質は、AIそのものではなく評価の設計と使い方の設計にある。

トークン消費量でエンジニアを競わせたAmazonのKiorankは、失敗が最初から見えていた仕組みだ。人間は計測されたものをハックする。これはAIに限らず、あらゆるKPI設計における古典的な罠だ。だからといって「AIを積極的に使わなくていい」という方向へ振れるのは、もっと危険な誤りだ。指標が悪かっただけで、AIを活用すること自体の方向性は正しい。「どう使えば効果的か」を組織として設計・支援することが本質であり、そこを飛ばしてツールだけ導入するから現場が迷子になる。

METRの「開発者がAIなしで実験参加を拒否した」という発見は悲観的な文脈で語られることが多い。だが見方を変えれば、それだけAIが開発ワークフローの中核に組み込まれているということでもあり、うまく設計すれば巨大な価値を生み出せるポテンシャルの裏返しだとも読める。

維持コスト増大の問題は、AIを単なる「コード生成の末端ツール」として使う限り構造的に解決しない。エージェントが自分で生成・検証・修正のループを回す設計——いわゆるハーネスループの発想——が現実解になる。AIに「書かせる」だけでなく「確かめさせ、直させる」フローを組み込むことが、次のフェーズでの競争力を左右する。

「2倍速く書けるなら、2倍の量をこなせ」ではなく「2倍速く書けるなら、同じ量を2倍の品質で仕上げよ」——この発想の転換が今、エンジニア組織全体に求められている。

出典: この記事は Coders are refusing to work without AI — and that could come back to bite them の内容をもとに、筆者の見解を加えて独自に執筆したものです。