「AIにコードを書かせれば開発が速くなる」——ここ数年、業界内でほとんど疑いなく語られてきた前提である。だが実際は、AI導入によって費用と成果が見合っていないという声は、今回取り上げる事例に限らずよく聞かれる。2026年に入り、AIコーディングツールを本格導入した企業から、そうした「期待と実態のズレ」を裏付けるデータが相次いで報告されている。AI導入には企業にとってリスクが伴うため、そのリスクに見合うリターンが明確に見えなければ、なかなか踏み切れない。そのリスクを負った上で結果が出ないことは企業にとって重大な問題となる。今回は、Uber・Amazon・METR（AI研究機関）・CodeRabbit（コードレビューツール企業）が公表した具体的な数字をもとに、AIコーディングツールは本当に生産性を上げているのかについて考える。

METR研究が示した「速くなったはずが遅くなる」逆説

AI研究機関METRが2025年に行った調査は、直感に反する結果を示した。AIはコードを書く速度そのものは確かに上げる。プログラミング経験の浅い人でも、AIの力を借りればそれなりに動くコードを書けるようになった、という意味では間違いなく裾野は広がった。しかしその一方で、生成されたコードの誤りを修正したり、AIとのやり取り自体に時間を取られたりする場面も増え、トータルで見ると開発者の作業をむしろ遅くしていたというのだ。現場ごとにコーディング規約や設計の「型」が異なる以上、AIが出してくるコードがそのまま馴染むとは限らない。速くなった部分と、逆に手間が増えた部分、両方があるというのが実態に近いのだろう。

さらに興味深いのは続報である。TechCrunchの報道によると、METRが2026年2月に同じ実験を再度行おうとしたところ、参加予定の開発者たちが「AIなしで作業したくない」と拒否し、研究チームは自己申告形式の調査に切り替えざるを得なくなった。数字の上で明確な速度向上が証明しづらい状況にあってもなお、AIなしでゼロから作業するのはもう考えられない、という開発者は少なくないはずだ。この一件は、良くも悪くも「後戻りできないところまで来た」ことを裏付けているように見える。

Uber: AI予算をわずか4カ月で使い切った代償

配車サービス大手Uberの事例は、コスト面での警鐘としてより具体的である。同社は2026年のAI関連予算を、わずか4カ月（4月まで）で使い切った。Fortuneの報道によれば、UberのCOOであるAndrew Macdonald氏は社内のエンジニアリング責任者との対話を経て、「トークンの消費量と、実際にユーザーへ届く有用な機能の増加との間に、明確な相関を見出すのが非常に難しい」と述べている。

AIは一度の応答で大量の「思考」をこなすため、トークンの消費量は利用者が体感している以上に多くなりがちだ。安価なモデルや無料枠が根強い人気を保っている背景には、こうした事情もあるのだろう。日常的にAIを使い込んでいる人ほど、価格と性能のバランスには敏感になっているように思える。

この反省を受け、UberはClaude CodeやCursorなどのエージェント型コーディングツールに対し、従業員1人あたり月1,500ドルという利用上限を新たに設定した。

ただし、この手の一律の上限には注意も必要だ。AIをうまく使いこなせていない人の「無駄遣い」を抑える効果はあるだろうが、逆にAIを使いこなして相応の成果を出していたヘビーユーザーの生産性まで一緒に下げてしまう可能性もある。「使えば使うほど便利」という前提で青天井の投資をしていたツケを、全員一律のルールで払わされる形になっていないか、という視点は持っておきたい。

コード品質への代償: CodeRabbitが分析した「1.7倍の問題」

コストだけでなく、生成されるコードの品質そのものに疑問を投げかけるデータもある。コードレビューツールを提供するCodeRabbit社は、実際のオープンソースプロジェクトにおける470件のプルリクエスト（AIが関与したもの320件、人間のみによるもの150件）を分析した「State of AI vs Human Code Generation」レポートを公表した。

AIが生成したコードは人間が書いたコードに比べて平均1.7倍多くの問題（AI関与コード10.83件 / 人間のみ6.45件）。ロジック問題**+75%、セキュリティ1.5〜2倍**、可読性3倍以上、パフォーマンス問題は約8倍。

ただ、この数字を一概に「AIが悪い」と読むのは早計かもしれない。AIをどう使うかによって、セキュリティインシデントを量産することにもなれば、逆に自分のスキルを底上げしながら堅牢なコードを書くことにもつながる。基礎力のあるエンジニアが補助的に使う場合と、経験の浅い若手や一般ユーザーが「便利屋」としてAIに丸投げする場合とでは、リスクの現れ方がまったく違うはずだ。そして厄介なことに、この問題はAI自体の能力にかなり依存する部分が大きく、使う側の工夫だけで完全にカバーできるものでもない。コーディングの速度が上がっても、レビューにかかる時間が同じだけ短縮されない限り、この問題が根本的に解決することはないだろう。

Amazon社内で起きた「AIエージェント乱用」問題

コスト管理の難しさは、Amazon内部でも表面化していた。同じTechCrunchの報道によると、Amazonは社内でAIツールの利用状況をランキング化した「Kirorank」という制度を運用していたが、社員がAIエージェントを過剰に使ってコストを吊り上げ、ランキングを「稼ぐ」行動が横行したため、この制度自体を閉鎖する事態になった。

ランキング上位を狙って無駄にAIを使い倒す人がいれば、その分だけ真面目に、必要な範囲でAIを使っていた人たちの評価や立場が相対的に割を食うことになる。評価のベースが人間である以上、こうした構図は完全にはなくならないのかもしれない。実務にきちんと向き合っていた人からすれば、なんとも気の毒な話である。

それでも開発者はAIを手放せないという矛盾

ここまでの内容は、AIコーディングツールに否定的な材料ばかりに見えるかもしれない。しかし実態はもっとねじれている。METRの調査が示したとおり、生産性向上が数値で証明しづらい状況にあってもなお、開発者自身は「AIなしでの作業」を拒否するほど手放せなくなっている。

ここ数年でAIは、エンジニアにとって日常のツールとして浸透しすぎたと言っていいだろう。これまで面倒だった作業の一部を、AIによってはるかに効率的にこなせるようになった以上、電気やインターネットの普及と同じように、もう「なかった頃」には戻れない段階に来ているという見方もできる。そうなると、下手に規制で縛ろうとすることは、かえって企業や個人の競争力を弱めてしまうリスクの方が大きいのかもしれない。

AIコーディングツールとどう付き合うべきか

Uber・Amazon・METR・CodeRabbitの事例に共通しているのは、「AIを使えば自動的に生産性が上がる」という前提そのものへの再検証である。ここまでの内容を踏まえると、単純な利用量の上限設定よりも、使用用途そのものを絞り込むアプローチの方が理にかなっているように思える。何にでも使える便利なツールとして扱うのではなく、本当に効果を発揮する場面に用途を特化させることで、無駄なコストを抑えつつ、AIの強みをしっかり引き出せるはずだ。

レビュー体制については、正直なところ簡単な答えは出ない。AIにレビューを任せても見落としがなくなるわけではなく、かといって人間がすべて確認するのは時間的にも精神的にも負荷が大きい。CodeRabbitのデータが示すような「前提を変えたレビュー工程」を組めば負荷は増える一方だが、それをしなければ問題に気づけないリスクが高まる——これはジレンマとしか言いようがない。それでも多くの企業が、負荷の大きい方（人間によるレビュー強化）を選ばざるを得ない状況にあること自体が、この問題の根深さを物語っているように思う。

一方で、「使用量イコール成果の量ではない」ことはすでに明らかだ。Amazonのランキング制度のような「ゲーム化」を招く仕組みは、今後は避けるべきだろう。評価のものさし自体も見直しの時期に来ているのかもしれない。これまでは「どれだけ多くの成果を出したか」が評価の中心だったが、これからは「どれだけ少ないリソースで、どれだけの成果を出したか」というコスト効率が、企業の利益に直結する評価軸として重視されていく可能性がある。

AIとどこまで距離を置くか、何を最も重視するかによって、AIとの向き合い方は人それぞれ変わってくるものだ。私の使用方法を一例として紹介する。私は業務では安全性を重視して補助的にとどめ、必ず自分の目でコードを確認する。逆に個人的な利用では、事前にルールをしっかり決めておいて、その範囲内では思い切って任せる——このようにして最低限のリスクマネジメントはしているつもりだ。万が一問題が起きても個人開発の範囲なら自分の責任でどうにかなることが多いため、リスクを許容して進めている。これが正解だとは思わないが、考えることをやめてAIに全て任せてしまうという行為自体が今の最もリスクになり得る行為であると考えている。

いつか人間がまったく手を出さなくても完璧な成果物ができあがる時代が来るのかもしれない。ただ、少なくとも現時点でのさまざまな事例を見る限り、その日が来るまでは、人間の役割がなくなることはなさそうだ。