AIでコード品質が下がるのは「品質管理の設計」が間違っているから — スペックレビューからE2Eまで多層防御で開発速度2〜3倍を実現する方法（著者実績）

9月14日、i-kh.netが「If AI coding is lowering your code quality, you're not managing quality right」と題した記事を公開した。AIコーディングで品質が下がると感じているなら、それは品質管理の設計が間違っているという主張だ。

「AIを使うとコードの品質が落ちる」——この懸念は、GitHub CopilotやCursor、ClaudeといったAIコーディングツールの普及とともに多くの現場で聞かれるようになった。実際、GitHubの調査ではAIツールが開発速度を高める一方、コードレビューの負荷増大を懸念する声も報告されている。しかし記事の著者は、適切な多層防御を設計すれば、バグを増やさずに開発速度を2〜3倍に上げることは十分可能だと主張する。盲目的にPRをマージすれば当然品質は落ちる。問題はAIではなく、品質管理の仕組みだ。

最も効いた改善：要件レビューへのAI投入

著者が「最大の発見だった」と表現するのが、スペック駆動開発（spec-driven development）の導入だ。

従来、新機能開発では総工数の最大3分の1を「開発後のバグ修正・調整フェーズ」に費やしていた。原因の多くは、エッジケースの見落とし、疲弊した開発者の判断ミス、設計者が想定しきれなかったシナリオだった。

スペック駆動開発では、実装前にAIが要件・技術設計をレビューし、ギャップ、エッジケース、既存コードとの予期しない干渉を洗い出す。AIは疲れないし、適切なプロンプトを与えれば問題を見逃しにくい。むしろ「存在しない問題を作り出す」ほど積極的すぎることがあるため、AIが提案した要件の修正は慎重に確認する必要がある。この1ステップだけで、記事執筆時点でバグ数が大幅に減ったという。

TDDが「やらない理由」のない当たり前になった

コーディングエージェントの登場で、テスト駆動開発（TDD）のコストはほぼゼロになった。ただし、正しい手順を踏むことが重要だ。著者が推奨するフローはこうだ：

要件に基づきテストシナリオとテストケースをエージェントに考えさせる
テストケースを書く
実装コードを書く
テストケースに対して実装を検証し、問題があれば修正する
カバレッジのギャップを補完する（ただし要件に基づいて）

「エージェントが書いたバグに対して通過するテストを盲目的に書かせる」ことを防ぐため、テスト先行のこの順序は崩してはならない。またエージェントがテストを書くなら、ほぼ全カバレッジを目指さない理由もなくなる。

人間のマニュアルテストは依然として不可欠

著者が正直に認めているのが、マニュアルテスト（人間が実際に機能を触って確認する作業）はまだ大幅に効率化できていないという点だ。

「この工程こそが、私の生産性向上が10倍ではなく2〜3倍にとどまっている主な理由だ」

エッジケースの手動確認、テスト環境のセットアップ——これらはAIによる代替が難しく、現時点では生産性向上への貢献は限定的だ。ただし著者は「自動化できる余地をまだ見逃しているかもしれない」とも述べており、今後の改善余地として挙げている。

E2Eテスト・AIコードレビュー・本番監視

E2Eテストは「エンドユーザー視点で既存機能が壊れていないことを確認する最重要テスト」と位置づけ、PR・ステージング・本番デプロイ後のすべてで実行するのが理想だとする。AIはE2Eテストの作成を助けるが、テスト失敗をデバッグするためにブラウザツールやMCP（Model Context Protocol）サーバーへのアクセスが必要になる。

AIコードレビューについては、著者のチームではClaudeとCursorの両方をPRに対して走らせており、それぞれが異なる問題を検出するという。セキュリティ・効率性・他リポジトリとの干渉など複数の観点でカスタムレビューを追加することも可能だ。ただしAIは細かいことを過剰に指摘しがちなため、「無意味なAI生成コメントを別のエージェントで間引くパス」を設けることを推奨している。

本番監視については、SentryやGCPのError Reportingによるエラー検知にとどまらず、ClaudeやCursorがエラーを自動診断してroot causeを特定し、修正PRを作成するところまで自動化するのが理想形だとしている。

「AIに複雑な指示を守らせる」より「専用パスを追加する」

AGENTS.mdやCLAUDE.mdに複雑なルールを書き込んでも、エージェントはなかなか従わない。効果的なのは、特定の問題を検出・修正する専用パスを実装フローに追加するアプローチだ。対象として挙げられているのは：

セキュリティ上の問題
過度に複雑なコードや重複コード
命名規則・ファイル構成・フォーマットの遵守
「AI語（AI-ese）」で書かれた冗長なコメント

これらのパスを計画・実装フローに組み込めば、追加の注意を払わずとも1パスあたり5〜15分の追加コストで済むという。

多層防御を正しく設計すれば、AIコーディングは品質を下げるどころか、より多くのテスト、より深いレビュー、より速い本番問題の診断を実現する手段になる。「AIは品質を下げる」という前提自体を疑うべきだというのが、この記事の核心だ。

詳細はIf AI coding is lowering your code quality, you're not managing quality rightを参照していただきたい。