AI は開発のボトルネックをどこへ移すのか？

AI によって、思いついたものがすぐに形になり、動くようになりました。個人的には、またコンピュータで遊ぶのが面白くなってきたと感じています。

一方、テストエンジニアとして開発工程を下から眺めてきた立場からすると、気になることもあります。コードを書く時間が短くなれば、次はレビューや検証がボトルネックになる。そう考えるのは自然です。しかし、その検証自体も AI によって安くなるとしたら、どうでしょうか。

開発者の生産性に関する調査や、AI による検証の研究を手がかりに考えてみます。

リソースの暴力が変えてきた開発の常識

かつては PC 向けのソフトウェアでも、メモリ管理や細かな高速化を意識する場面が多くありました。ハードウェアが進歩すると、これまで手間をかけていた問題の一部を、計算資源の投入で解決できるようになります。リソースの暴力が、何を工夫すべきかの線引きを動かしてきました。

もちろん、最適化が不要になったわけではありません。組み込みや大規模なシステムなど、現在も厳しい制約はあります。

重要なのは、ある制約が安く解決できるようになると、開発者が時間をかけるべき問題が変わるということです。AI は、実装や検証に必要な人的コストの一部について、似た変化を起こそうとしています。

AI はコードを書くコストをどこまで下げたか

AI の効果は、作業内容や環境によって異なります。「生成が速い」と「タスク完了が速い」も同じではありません。

METR は2026年2月の追跡報告で、最新ツールを対象とした実験について、参加者の選択バイアスなどから現在の速度向上効果を信頼できる形で推定できなかったと説明しています。

AI の進歩を過小評価する必要はありません。ただし、開発全体の変化を見るには、コード生成以外の工程も測る必要があります。

コードが増えたら、どこがボトルネックになるか

個人の作業が速くなっても、チーム全体の開発が同じだけ速くなるとは限りません。

この調査では、タスク処理量の増加とともに、レビューなどの下流工程への負荷が観測されました。ただし、すべての開発組織で同じことが起きているとは限りません。Google のDORA 2025も、AI の効果は開発基盤や組織の能力によって左右されると報告しています。

コードを書く能力が高まるほど、それを安全に取り込む仕組みが重要になります。 では、レビューや検証は、次のボトルネックであり続けるのでしょうか。

検証もまた、AI によって安くなる

AI はテストケースや期待結果の生成、コードレビューにも利用され始めています。

実装と検証を別々の工程として見るより、次のループ全体のコスト低下を考える必要があります。

flowchart TD
    A["複数の実装案を生成"] --> B["テスト・静的解析・シミュレーション"]
    B --> C["結果を分析し、修正"]
    C -->|再試行| B
    C --> D["基準を満たした候補を比較・採用"]

これまで時間や人手の制約から諦めていた試行錯誤を、計算資源で補える領域は増えるでしょう。

ボトルネックは「実装から検証へ」と移るだけではありません。実装と検証を含むサイクルそのものが安くなる可能性があります。

100万回テストしても、正しいとは限らない

仕様を誤解した AI がコードとテストをまとめて生成した場合、テストがすべて通っても、利用者が期待した動作とは限りません。

2026年7月、OpenAI はコーディング AI の評価に使われる SWE-Bench Pro を監査し、約30%のタスクに評価上の問題があると推定しました。監査結果には、仕様にない実装方法を要求するテストや、不完全な修正を通してしまうテストが挙げられています。

これは AI 評価用ベンチマークの話で、一般的なソフトウェアテストの不備率を示すものではありません。ただし、評価基準自体の妥当性という問題は共通しています。

評価基準の設計も AI が支援できます。しかし、判断に必要な情報が欠けていれば、計算量を増やすだけでは解決できません。問われるのは、何を根拠に正しさを判断できるかです。

次のボトルネックは、現実から学ぶ能力か

ここからは調査を手がかりにした私の仮説です。実装・検証・修正を何度も繰り返せるようになっても、現実からフィードバックを得る速度が同じように上がるとは限りません。

flowchart TD
    A["実装する能力"] --> B["検証する能力"]
    B --> C["現実から学ぶ能力"]
    C --> D["次の開発を判断"]
    D -.-> A

AI に仮想ユーザーを演じさせたり、過去のデータから反応を予測させたりはできます。しかし、その予測が現実に合うかは、別途確かめる必要があります。

開発のボトルネックは、作る能力から、実際のユーザーや環境で何を試し、何を学び、次の判断にどうつなげるかへ移っていくのではないでしょうか。 Google のDORA 2025が重視するユーザー中心の開発やフィードバックループとも整合的な、現時点での仮説です。

ボトルネックを一つに決めつけることはできません。それでも、ある工程のコストが大きく下がれば、それまで目立たなかった制約が表面化します。

誰もが作れる時代の価値

作ることが簡単になるのは純粋に面白い。一方で、計算資源、実際のユーザー、業務データ、検証環境などへのアクセスには差があります。その違いが、新たな格差につながる可能性もあります。

テストエンジニアとしては、検証の重要性が増すかどうかより、検証そのものがどう変わるかに興味があります。

実装も検証も安くなった先で、現実から何を学び、次の開発につなげるのか。 そこに新しい制約が生まれます。

参考資料

• 2025年前半の開発者生産性実験metr.org
• 追跡実験の設計変更（2026年2月）metr.org
• AI Engineering Report 2026faros.ai
• DORA 2025dora.dev
• Do LLMs Generate Useful Test Oracles?homes.cs.washington.edu
• Separating signal from noise in coding evaluations（2026年7月）openai.com