少し前に、こんな記事を書きました。
そこで扱ったのは、かなり単純化すると、
AIが実装し、
AIがテストを書き、
AIがそのテストを通して、
最後にAIが「問題ありません」と判断する。
この構造を、そのまま品質保証として扱っていいのだろうか。
という話でした。
当時は、AI Codingを使う中で感じていた違和感を整理したくらいのつもりでした。
しかし2026年現在、この問題はかなり現実的なものになってきています。
AI Coding Agentは、もう単なるコード補完ではありません。
Issueを読み、コードベースを調査し、実装し、テストを書き、失敗を解析し、自分で修正し、Pull Requestまで作る。
さらに、複数のAgentを並列に動かすこともできる。
つまり今起きているのは、
「Codingの高速化」だけではありません。
変更（Change）を生み出す能力そのものが、スケールし始めています。
そしてChangeを生み出す能力が上がるほど、次に重要になるものがあります。
そのChangeを、どれだけ速く・正しく検証し、信頼できると判断できるか。
自分は、AI Codingの次のボトルネックはVerificationに移っていくと考えています。
Codingの自動化は、かなり先まで来た
少し前まで、AI Codingの中心は補完でした。
人間が考える
↓
人間がコードを書く
↓
AIが補完する
現在はかなり違います。
ここまでを一つのLoopとして回せるようになっています。
GitHubでは、Copilot Coding Agentが作成したPull Request数やMergeされたPull Request数、Copilot Code ReviewがレビューしたPull Request数をRepository単位で計測できるようになっています。
また2026年3月時点で、GitHub上のCode Reviewの5件に1件以上がCopilot Code Reviewによるものとなっています。
AI Codingはすでに、
個人が便利に使う補助ツール
から、
Software Deliveryそのものを構成する仕組み
へ移りつつあります。
だから次に考えるべきなのは、
AIを使うか、使わないか
ではありません。
どこまで任せるのか。
そして、
何をもって結果を信頼するのか。
です。
次に詰まるのはVerification
例えば、これまで一つの機能実装に3日かかっていたとします。
それがAI Codingによって30分になった。
これは素晴らしい改善です。
ただし、
- 要求の確認
- Code Review
- Test Design
- Risk Analysis
- Verification
- Release判断
が従来の速度のままだったらどうなるでしょうか。
単純です。
そこが次のボトルネックになります。
さらにAgentは並列化できます。
Agent A → Feature A
Agent B → Bug Fix B
Agent C → Refactoring C
Agent D → Test追加
Agent E → Dependency Update
Developerが一つずつ実装していた場合とは、Changeの生成量が大きく変わります。
するとSoftware Deliveryを決めるのは、
人間がコードを書く速度
ではなく、
人間とシステムがChangeを検証し、信頼できると判断できる速度
になります。
もちろん、すべての開発で実装がボトルネックではなくなった、という意味ではありません。
複雑なDomain LogicやLegacy Code、要件が曖昧な領域では、今でも実装そのものが難所になることはあります。
ここで言いたいのは、
AI AgentによってChange生成が高速化・並列化できる領域では、実装より先にVerificationの処理能力が制約になりやすくなる
ということです。
Change生成能力にVerification能力が追いつかなくなる状態を、この記事ではVerification Bottleneckと呼びます。
「全部Greenです」は品質保証ではない
AI Coding AgentはProduction Codeだけではなく、Test Codeも書けます。
Testを実行し、失敗を読み、自分で修正することもできます。
これは非常に強力です。
一方で、こういう構造も生まれます。
Production CodeもTest Codeも同じAgentが変更できる。
そこでAgentに、
テストを通してください
というGoalを与えれば、
Goal = GREEN
になり得ます。
しかし、
本当に正しい実装を作ること
と、
実装とテストの辻褄を合わせること
は同じではありません。
これはAI特有の問題でもありません。
人間でも、
自分で実装
↓
自分でTest
↓
自分で確認
↓
まあ大丈夫だろう
は普通に起きます。
AIによって変わったのは、
この自己完結Loopを非常に速く、何度でも回せるようになったこと
です。
GreenはQualityではなくSignal
ここは特に重要だと思っています。
Tests = GREEN
だからといって、
Quality = GOOD
とは限りません。
Greenが意味しているのは、
現在定義されている評価条件を満たした
ということです。
つまりGreenは、
Qualityそのものではなく、Qualityを判断するためのSignal
です。
重要なのは、一番右側のGreenだけではありません。
その前にある、
- どんなRiskを対象にしているのか
- 何を正しい状態と定義しているのか
- どのLayerで保証しているのか
- 失敗した時に本当に検知できるのか
- そのSignalをRelease判断に使ってよいのか
です。
1000件のTestがGreenでも、
本当に止めるべきRiskを一件も見ていなければ、そのGreenは強い保証にはなりません。
逆に、重要なInvariantをStatic AnalysisやIntegration Test一本で確実に止められるなら、その一本の方が価値が高いこともあります。
これはAI以前から存在していた問題です。
AIによってProduction CodeもTest Codeも大量生成できるようになり、
今まで見えにくかった問題が、より大きく見えるようになった
とも言えます。
人間が全部Reviewすれば解決するわけでもない
ここで、
AIが信用できないなら、人間が全部確認すればいい
という考え方も出てきます。
ただ、それも長期的には成立しないと思っています。
AIによるChange生成能力が10倍になっても、人間のReview能力が10倍になるわけではありません。
AI Coding
↓
大量のChange
↓
全部Human Review
↓
Review Queue
これでは、単にボトルネックを人間側へ移しただけです。
必要なのは、
AIを止めることではありません。
必要なのは、
VerificationそのものをEngineeringすること
だと思っています。
「どこで保証するか」を設計する
全てのChangeを、同じ方法で検証する必要はありません。
全部をHuman Reviewにする必要もありません。
全部をE2Eにする必要もありません。
全部をAI自身に判断させる必要もありません。
Riskに対して、
最も安く、速く、再現性が高く、信頼できるFailure Signalが得られる場所
へ保証を配置する。
そして機械的に判断できないものだけ、人間へ上げる。
ここで人間に残したいのは、
作業量ではなくJudgment
です。
自分がここでいう 「検証の設計」 とは、
Riskごとに、何を正しい状態とし、どのLayerで、どのSignalを使って保証し、どこを自動化し、どこに人間の判断を残すかを設計すること です。
AI Reviewだけで解決するわけでもない
AI Review自体も進化しています。
GitHub Copilot Code Reviewは、Agent SkillsやMCPを通じて、
- Coding Standard
- Documentation
- Issue Tracker
- Service Catalog
- Repository固有のContext
などをReviewに取り込めるようになっています。
つまりAI Reviewも、
Diffを見るだけ
から、
組織固有の判断基準を使って検証する
方向へ進んでいます。
一方でGitHubは2026年8月、GitHub Code Qualityを有効化した際にCopilotを自動Reviewerとして追加する仕様を、User Feedbackを受けて取りやめました。
この変更も、AI Reviewerをどこで、どのように使うか自体が設計対象になることを示す一例だと思います。
AI Reviewerを追加する
=
Qualityが保証される
わけではありません。
どこで使うのか。
何を任せるのか。
何をGateにするのか。
結局そこには、
Verification Design
が必要になります。
高速化した現場ほど、Verificationが重要になる
高い信頼性が求められる領域でも、この問題はすでに現実になっています。
SamsungのSystem LSI部門では、Claude CodeをChip DesignやVerificationに活用し、1か月以上かかると見積もられていた作業を、2日まで短縮した事例が報じられています。
一方で、AIが想定範囲を超えてRTL Codeを変更しようとしたケースなどもあり、
AIのOutputについて、EngineerによるManual Reviewを必須
としていると報じられています。
ここで重要なのは、
AIを使わない
という結論になっていないことです。
AIによる高速化は使う。
ただし、
高速化した分だけ、どこで信頼性を担保するかを明確にする。
AIか人間か、ではなく、
AI + Verification
として考える。
これが現実的な方向だと思います。
Test Automationの次はVerification Automation
これまでSoftware Testingでは、
Manual Test
↓
Test Automation
という大きな流れがありました。
AI Codingが進むと、Test Executionの自動化だけでは足りなくなります。
Verificationそのものを仕組み化し、自動化できる部分を継続的に実行できるよう設計する必要があります。
ここでは、便宜上これを Verification Automation と呼びます。
ただし、
テストをさらに自動化する
という意味ではありません。
Test Execution自体は、すでにかなり自動化されています。
これから必要なのは、
- Changeに対して何を確認するのか
- RiskをどのLayerで保証するのか
- Test Oracleをどこに持つのか
- どのSignalをQuality Gateとして扱うのか
- AIの自己検証をどこまで信頼するのか
- どこに人間の判断を残すのか
まで含めて、
「正しさを確認できる仕組み」そのものをEngineeringすること
です。
Coding Speedではなく、Trusted Throughput
AI時代のDeveloper Productivityについて考える時、
どうしても、
何行生成できたか
何Task終わったか
実装時間が何%減ったか
に目が行きます。
もちろん、それも重要です。
ここまで考えると、Developer Productivityで見るべきものも少し変わってきます。
ここで重視したいのが、Trusted Throughputです。
つまり、
どれだけ速くChangeを作れるか
ではなく、
どれだけ速く「信頼できるChange」をProductionへ流せるか。
Generationだけを高速化すれば、Review Queueが増える。
Verificationを雑に高速化すれば、Incident Riskが増える。
だからSoftware Delivery全体として最適化すべきなのは、
Coding Speedだけではなく、Trusted Throughput
なのではないかと思っています。
AIが速くなるほど、「信頼できる速度」が重要になる
AIを信用するか。
AIを信用しないか。
この二択で考える必要はありません。
AIがコードを書く。
AIがテストを書く。
AIがReviewする。
AIがFailureを修正する。
自動化できるところは、どんどん進めればいいと思います。
ただし最後に、
そのGreenは、何によってGreenになっているのか。
ここは設計しなければいけない。
Changeを生み出す能力が上がるほど、
そのOutputを検証する能力がSoftware Delivery全体の速度を決める
ようになります。
だからAI Codingの次のボトルネックは、
Codingではなく、
Verification
になっていく。
これはTest Automationだけで解決する話でもありません。
Developer、Platform Engineering、CI/CD、Security、Observability、Developer Experienceを含めた、
Software Engineering全体の設計課題
だと思っています。
おわりに
前回の記事では、
AIに実装と評価を同時に最適化させる危険性
について書きました。
今回はその一歩先として、
Change生成能力の高速化によって、Verification能力がSoftware Deliveryのボトルネックになる
というところまで考えてみました。
AI Codingは、これからさらに速くなると思います。
だから次に必要なのは、Codingをさらに高速化することだけではありません。
信頼できるChangeを、どれだけ速くProductionへ流せるか。
自分は、このTrusted Throughputをどう高めるかが、次のSoftware Engineeringにおける重要なテーマになると考えています。
参考
-
GitHub Blog
60 million Copilot code reviews and counting -
GitHub Changelog
Repository-level GitHub Copilot usage metrics generally available -
GitHub Changelog
Copilot code review: Agent skills and MCP now generally available -
GitHub Changelog
GitHub Code Quality no longer adds Copilot as a reviewer