コーディングは決してボトルネックではなかった

私の仕事は開発者生産性です。私は開発者インフラストラクチャで6年間働いてきたので、この問題に密接に関わっています。私はAI生産性の話が真実であってほしいと願っています。より多くのアウトプット、より短いタイムライン、より幸せで生産的なエンジニア。誰が望まないでしょうか？しかし、私は実際の研究を見続け、次に現実世界で何が起こっているかを見て、それらを一致させることができません。あるいは、一致させることはできますが、それは「生産的」という言葉が最近の議論のほとんどが考えている意味ではないと認める覚悟があればの話です。

最も不快な発見

2025年初頭、研究組織METRはオープンソース開発者を対象に統制実験を実施しました。業界の予想に反して、AIツールを使用したエンジニアは使用しないエンジニアよりも19%長い時間がかかり、信頼区間は+2%から+39%でした。この遅延は統計的に堅牢でした。これは業界の異なる時期でした。ClaudeはOpusモデルをリリースしておらず、業界はAIが何をできて何をできないかを模索していました。しかし、この発見が注目に値するのは遅延そのものではなく、エンジニアが自分たちは約20%速くなったと信じていたのに対し、データは逆の結果を示したこと、つまり認識と現実の間に大きなギャップがあることを明らかにした点です。

この発見は、他の証拠を積み重ねる前に少し立ち止まって考える価値があります。なぜなら、それが他のすべての読み方を変えるからです。

METRは2025年8月から追跡研究を試みましたが、その研究に何が起こったかは、おそらく元の結果よりも示唆に富んでいます。2026年2月、彼らは実験デザインを断念した理由を説明する記事を公開しました。問題は、あまりにも多くの開発者が、すべてのタスクにAIを使用できることを条件に参加を拒否したことでした。残りの参加者の30%から50%は、AIなしで行いたくないタスクの提出を選択的に避けたと報告しています。サンプルは、AIの価値を最も示しにくい開発者とタスクに体系的に偏っていました。

2025年後半の研究データは、傾向の改善を示しています。戻ってきた元の開発者のサブセットでは、推定効果は速度の18%向上（信頼区間：-38%から+9%）にシフトしました。新たに採用された開発者では、速度の4%向上（-15%から+9%）が見られました。しかしMETRは、多くの人が自己選択で脱落したため、これらの数値はおそらく下限であると指摘しました。彼らの結論：AIツールは2025年初頭以来より有用になっているが、選択効果が非常に深刻になり、統制された測定はほぼ不可能になっている。AIに最も熱心な開発者は、もはやAIなしでは仕事をせず、対照群として機能しなくなっています。

これはMETRの方法論の失敗ではありません。これは、私たちがどこにいて、どこに向かっているのかを示すシグナルです。

さらに3つのデータポイント

2025年後半から2026年初頭にかけて、さらにいくつかの研究が発表されました。

Anthropicは2025年後半に社内の132人のエンジニアを調査し、53件のインタビューを実施し、20万件のClaude Codeトランスクリプトを分析しました。従業員は生産性が50%向上したと報告しました。エンジニア組織とClaudeの使用が拡大するにつれて、1人あたりの1日あたりのプルリクエストが67%増加したと主張しています。Anthropicのエンジニアは日常業務の60%でClaudeを使用し、Claudeはより多くのタスクを自律的に実行しています。

CircleCIは数千のチームにわたる2800万のCIワークフローを分析しました。ワークフロースループットは59%増加しましたが、中央値のチームのメインブランチスループットは7%減少しました。ビルド成功率は70.8%に低下し、これは5年ぶりの低さです。これまで以上に多くのコードが存在しますが、本番に到達するコードは少なく、CIがボトルネックになりつつあります。

ハーバードビジネススクールの研究者は、専門外のタスクを実行するために人工知能を使用する78人の労働者を研究しました。AIは全員が平等にブレインストーミングするのを助けましたが、実行においては、スキルがドメインから遠い労働者はドメイン専門家より13%劣っていました。AIが計画段階で埋めたように見えたギャップは、納品段階で再び現れました。

METRの2026年5月の調査（実験デザインが崩壊した後に実施）では、349人の技術労働者を対象に、AIツールによる生産性価値の向上は自己報告で1.4倍から2倍であることがわかりました。しかしMETR自身の研究スタッフ、つまり2025年に記録した認識バイアスについて最も較正されている人々は、その調査のどのサブグループよりも低い利益を報告しました。

実際の状況

これは一部の読者にとっては馴染みのあるシナリオでしょう。

エンジニアのアクティビティ指標は表面上は素晴らしく見えます。プルリクエストは増加し、コードコミットは増え、ベロシティポイントはチームが何年も達成していないペースでクローズされています。リーダーシップチームは満足し、エンジニアはより生産的だと感じています。そして誰か（おそらくPM）が、6週間前に「進行中」とマークされたロードマップ項目がまだ進行中なのはなぜかと尋ねます。

全員が同時に同じことに気づきます。機能のタイムラインは実際には変わっていないのです。

何が起こったかというと、AIは作業を開始するコストを劇的に削減しましたが、本番品質に仕上げることは依然として課題です。初稿の関数、ボイラープレート、スキャフォールディング、馴染みのないコードのテスト記述の説明はすべて大幅に安くなりました。しかし、出荷のボトルネックは決してこれらのタスクではありませんでした。それらはプロダクト決定、デザインレビュー、QA、コンプライアンス、インフラストラクチャ、リリースプロセスでした。コーディングを高速化すると、同じ下流のボトルネックに対してより多くの進行中の作業が詰め込まれることになります。2800万のワークフローに関するCircleCIのデータは、その一部を大規模に示しています。つまり、機能ブランチでの大量のアクティビティと、メインブランチでのスループットの横ばいまたは低下です。

これは集計データのパターンだけではありません。AnthropicのClaude Codeのエンジニアリングディレクターは、2026年6月の講演で明確に述べました。コードの記述、テストの記述、リファクタリングは彼女のチームをほとんど遅くしなくなりましたが、ボトルネックは消えませんでした。検証、コードレビュー、セキュリティがその地位を引き継ぎました。彼女は特にCIを指摘しました。チームがより多くのコードを生成するにつれて、ビルドシステムとCIパイプラインは追いつくのに苦労する可能性があります。これは、世界で最もAIで加速されたエンジニアリング組織の1つを運営するチームが、CircleCIデータが説明するのと同じ制約の壁にぶつかっていることを示しています。天井はコード作成速度ではなく、実際にはこれまで一度もなかったのです。

Anthropicの調査結果である「AI支援作業の27%は他の方法では行われなかったであろう」というのは、両刃の剣です。その作業の一部は真に価値があります。例えば、実際の意思決定に情報を提供するプロトタイプの探索、実際に書かれるドキュメントなどです。一部は、単に十分に重要ではなかったため誰も優先順位を付けなかった作業です。今では、それらはレビューサイクルとCIリソースを消費しています。なぜなら、それらを構築することはほぼ無料になった一方で、レビュー、テスト、保守はそうではないからです。

能力と自信のギャップ

HBSの研究は、正確に名前を付ける価値のある特定のメカニズムを特定しています。彼らの枠組みでは、AIは初心者と専門家の間の自信のギャップを埋めます。それはすべての人に計画、説明、初稿への平等なアクセスを与えます。しかし、能力のギャップは埋めません。バックエンドエンジニアがAI支援でフロントエンド機能を構築する場合、彼らは正しく見えるものを生成します。問題は表面の下にあり、彼らが疑問を持とうとしなかった決定と、テストしようとしなかったエッジケースにあります。

初期のMETRの結果は、これが自分のドメインで働く経験豊富な実務者にも及ぶことを示唆しています。AIは彼らを無能にするのではなく、実際には自分のアウトプットが正当化する以上に有能に感じさせます。そして、METRの追跡調査の崩壊が示したように、開発者がAIを深く統合すると、研究者が「自動化バイアス」と呼ぶものにおいて、AIなしで作業する能力を失います。

これはエンジニアリングリーダーが懸念すべき部分です。見えないものは修正できません。チームのすべてのエンジニアが自分たちは50%生産性が向上したと心から信じているのに、出荷日が変わっていない場合、誰も存在しないと思っている問題が存在します。

人工知能ネイティブ開発を持続可能にする方法

コードレビューをより厳格に、より速くではなく。AI生成コードは表面上のチェックを簡単に通過します—きれいなフォーマット、一貫した規則、リンターの警告なし—それがまさに危険な理由です。問題は、レビューアが差分をざっと読んだだけでは気づかない種類のものです。

私はこれを「合理的疑いのレビュー」と呼んでいます。実践は、信頼ではなく懐疑から始めることです。質問は「これは正しく見えるか？」ではなく、「ここで差分からは気づかない何が間違っている可能性があるか？」です。具体的には、モデルが出力に見えないどのような仮定をしたのか？これはどのエッジケースで静かに失敗するのか？これは作者が考えていなかったかもしれない何かに結合しているか？

これは遅くなります。それがポイントです。また、無限にスケーラブルではないため、判断を必要としないものには自動化を組み合わせ、判断が必要なところに人間の注意を集中させる必要があります。

Claude Codeチームのアプローチは適切な指標を示しています。スタイル、リンター、バグキャッチ、テスト生成はAIに任せてファーストパスとし、セキュリティに敏感なコード、信頼境界、法的リスクに関わるものはすべて直接ドメイン専門家に回します。区分は「AIが小規模/低リスクの変更をレビューし、人間が大規模/高リスクの変更をレビューする」ではなく、「AIが表面の正確性を処理し、人間が重大な判断を担当する」です。これは意味のある違いです。多くのチームは前者を行いながら、後者を行っていると思っています。

新しい障害モードに合わせてCIを適応させる。CircleCIのビルド成功率が5年ぶりの低水準に落ち込んだ一方でスループットが急増したことは、ほとんどのチームがAI生成コードの破壊の仕方を捉えるようにパイプラインを更新していないことを示唆しています。AI生成コードは人間が生成したコードとは異なる方法で失敗します。局所的には正しいがアーキテクチャ的に一貫性がない、単体テストに合格するが統合テストに失敗する、関数シグニチャを尊重するがそれらの関数が構築された前提に違反する可能性が高いです。統合テスト、契約テスト、およびパイプラインでシステムの制約を強制するアーキテクチャフィットネス関数は、リンターや型チェッカーよりもこれらを多くキャッチします。AI生成コードがパターンに違反する場合、レビューアが差分を開く前にビルドがそれをキャッチするべきです。これはレビューの問題とインフラの問題の両方に対処します。

フィーチャーフラグの背後に出荷し、積極的に監視する。デプロイ前にすべてをキャッチできないことを受け入れてください。マージ前の品質に完全に賭けるのではなく—証拠はそれが感じられるよりも評価が難しいことを示唆しています—1%のユーザーにデプロイし、ダッシュボードを監視し、何か問題があればすぐにロールバックします。このアプローチはまた、観測可能性への投資を強制し、これはAIの問題とは独立して報われます。

AI支援コードには人間が書いたテストを要求する（AIが確定的テストを自信を持って生成できるようになるまで）。特にエッジケースと境界条件に対する人間が書いたテスト。テストを書くという規律は、開発者に出力を額面通りに受け入れるのではなく、動作を考えさせることを強制します。エンジニアがテストを書けない場合、おそらくコードを十分に理解しておらず、出荷するべきではありません。それは有用なシグナルであり、失敗状態ではありません。

意図的な知識共有の時間を保護する。Anthropicの研究は、Claudeがエンジニア同士が以前持っていた会話を置き換えるにつれて、メンターシップが静かに侵食されていることを発見しました。これはデータにおける長期的リスクです。アーキテクチャ決定記録、ローテーションシステムウォークスルー、シニアとジュニアが一緒に問題を解決するペアリングセッション—これらはAIに尋ねるのに比べて非効率的に感じられます。しかし、これらこそがチームが共有理解を構築する方法であり、これにより同じ間違いがよりフォーマットされたコードで6ヶ月ごとに再構築されるのを防ぎます。

測定の問題

では、これはAIの使用をやめることを意味するのでしょうか？いいえ。AIを使用し、それが面倒なタスク、プロトタイピング、探索的作業、迅速に検証できるものに明らかに役立つ場合には積極的に使用してください。範囲が明確で独立して検証可能な作業に対する利益は現実のものです。

しかし、生産性の実際の向上を測定しようとするならば、自己報告データには注意してください。実際の結果—機能の出荷、インシデント数、コードレビューのサイクルタイム—が重要です。そしてこれまでのデータは、AIが仕事の性質を変えつつあるが、私たちが出荷する速度を根本的に変えていないことを示しています。それはボトルネックの位置を変えましたが、ボトルネックを排除したわけではありません。そしてその違いを無視するチームは、決して出荷されない大量のコードを生成することになります。

解決策はAIを減らすことではなく、より賢く使うことです—そして私たちがまだ解決する必要のあるボトルネックについて正直になることです。