AIコーディングがコード品質を低下させているなら、品質管理が正しくできていない

AIコーディングがコード品質を低下させているなら、品質管理の方法が間違っている

私がよく目にするコーディングエージェントに関する一般的な意見は、次のようなものです。「確かにAIはコードの出力を助けるが、品質は低下しないだろうか？」

PRを盲目的にマージして本番に送り出すのであれば、確かに品質は低下するでしょう。しかし、品質管理に対して思慮深く、多層的なアプローチを取るならば、バグの数を安定させるだけでなく、実際には減らすことも可能だと私は考えています――そして、それでもなお、出力は2〜2倍に増加します。

これらの防御レイヤーの多くは、Claude/Copilot/Codex/etc.が登場する以前とほぼ同じものですが（ただし、AIによって容易になっています）、新しいものもあります。ここでは、私自身のチームや他の場所で実際に成功裏に使用されている防御設定を紹介します。

レイヤー1：要件を正しく定義する

仕様駆動開発を使い始めてからの大きな驚きの一つは、新しく書かれたコードのバグが減少したことでした。仕様駆動開発以前は、例えば新しい機能を構築する際、私が所属していたチームは、開発後の「磨き上げ」、つまり様々なバグを発見・修正するために、総工数の最大3分の1を費やすことがよくありました。これらのバグの多くは、特定の相互作用やエッジケースを予期できなかったため、あるいはその日開発者が疲れていて十分な検討を怠ったため、あるいはデザイナーやPMが特定のシナリオを十分に検討しなかったために発生しました。これらのバグの一部は見落とされ、本番環境に紛れ込みました。

仕様駆動開発を使い始めてから、私のコードにおけるこれらのバグの数は急激に減少し、一部の（しかし全てではない）チームメイトでも同様の減少が見られました。私の知る限り、この減少の主な原因は、プロセスの特定の一歩にあります。それは、AIに要件または技術設計をレビューさせ、ギャップ、エッジケース、既存コードとの予期せぬ相互作用、またはその他の類似の問題を発見させることです。

AIは疲れることがなく、適切にプロンプトを与えれば、問題の発見を諦める可能性ははるかに低くなります。むしろ、時には過剰になることもあり、要件に対する提案された編集を注意深くレビューして、実際には存在しない問題をAIが作り出していないことを確認する必要があります。

レイヤー2：95%以上のカバレッジを持つ単体テスト

コーディングエージェントは現在、テスト駆動開発（TDD）を非常に容易にし、それを行わない理由がないほどです。しかし、正しく行う必要があります。エージェントが追加したばかりのコードのバグに対して、単にパスするテストを盲目的に書かせたくはないでしょう。そのため、私がこれまで見てきた最良の計画と実装スキルは、通常、次のパターンに従います。

• 要件に基づいて、テストシナリオとテストケースを検討するようにエージェントに指示する。
• テストケースを作成する。
• 実装を作成する。
• 実装をテストケースに対してテストし、発生した問題を修正する。
• 残りのカバレッジギャップを後から埋める――ただし、ここでも要件を念頭に置く。

また、エージェントがテストを書くようになれば、ほぼ普遍的なカバレッジを目指さない、あるいは欠落した単体テストの後から埋めるのを待つ、といった言い訳は通用しなくなります。

レイヤー3：手動テスト

人間（あなた、QA、PM、または他の誰か）が実際に機能を試用し、すべてのエッジケースを通過させ、すべてが期待通りに機能しているか、あるいは変更が必要かを確認することに代わるものはありません。

これらの手動テストは、テストシナリオのセットアップに労力がかかる場合、特に時間がかかることがあります。これは、これまでのところ生産性の向上しか modest な成果しか得られていないステップの一つであり、私の出力が10倍ではなく、わずか2〜3倍にしかならなかった主な理由です。もっとも、今考えると、ここで見落としている自動化の機会がいくつかあるかもしれません。

レイヤー4：広範な自動エンドツーエンドテスト

エンドツーエンド（E2E）テストは、新しい変更がエンドユーザーが経験する既存の機能を壊していないことを検証するため、コードベースの中で最も重要なテストと言えるでしょう。理想的には、PR、テスト/ステージ環境、そしてデプロイごとの本番環境で実行されるべきです。理想的には、通常のコードを書く開発者と同じ開発者によって保守されるべきですが、一部の組織がそのように設定されていないことは理解しています。

AIはE2Eテストの作成を容易にしますが、効果的に行うためには、テストの失敗をデバッグできるツールやMCPサーバー（例：ブラウザツールやログへのMCPアクセス）にアクセスする必要があります。しかし、E2Eテストは手動テストの代替にはならないことを念頭に置くことが重要です。なぜなら、それらは重要な機能が壊れていないことの、ラフで不完全なチェックにすぎないからです。

レイヤー5：AIによるコード品質チェック

コーディングエージェントは、AGENTS.md や CLAUDE.md の複雑な指示に従うのが得意ではないと私は考えています。しかし、特定の問題を見つけて修正するための個別のパスを追加すれば、かなりうまく機能します。これらは次のようになります。

• セキュリティ上の問題。
• 複雑すぎる、または重複したコードの発見。
• 名前付け、ファイル構成、またはフォーマット規則への準拠。
• ロジックの問題を見つけるための一般的なコードレビューパス。
• 通常の英語ではなく、AI特有の言葉で書かれた長すぎるコメント。
• 見つけて修正したいその他の特定のこと。

これらを計画または実装スキルに追加すると、ほとんど「無料」で追加でき、実装時間に5〜15分程度しかかからず、追加の注意は不要です。

PRレビューに追加して、修正を適用する前にコメントを確認することもできます。

レイヤー6：人間とAIによるPRレビュー

軽微な修正や単純なバグ修正については、人間のレビューはオプションになる可能性があると確信し始めています。ただし、他の防御レイヤーが依然として配置されていることが前提です。

しかし、複雑な変更については、AIが書いたコードをレビューすることが依然として必要だと感じています。私は今でも、大局的な間違い、他の機能との見落とされた悪影響、複雑すぎる、または最適ではない実装、その他の問題を発見することがよくあります。たとえば、「生成」の代わりに「ミント」や「設定」の代わりに「スタンプ」といった奇妙な言葉遣いは言うまでもありません。

AIコードレビューも非常に素晴らしい追加機能です。現在のチームでは、PRに対してClaudeとCursorの両方のレビューを実行しており、驚くべきことに、それぞれが異なる問題を発見します。また、セキュリティ、効率、他のリポジトリとの連携など、さまざまな角度から他のカスタムレビューを追加することもできますが、AIはレビューで過度に細かくなる可能性があるため、意味のないAI生成PRコメントを削除する別のパスを持つことも重要です。

レイヤー7：監視とアラート

コードが本番環境に入ったら、最低限、誰かが定期的にログをスクロールしたり、Fullstoryのようなツールでユーザー録画を視聴したり、エラー率、レイテンシ、その他の問題を追跡するさまざまなダッシュボードを確認したりすることが良いでしょう。

さらに良いのは、SentryやGCPのエラーレポートのようなエラー追跡サービスで、エラーを検出し、重複を排除することです。

しかし、最善のアプローチは、Claude/Cursor/whateverにこれらのエラーを自動診断させ、根本原因を特定し、提案された修正を含むPRを作成することでしょう。

結論

高品質を維持するための他の重要なコンポーネントをいくつか見落としているかもしれませんが、主な考え方は、適切な防御レイヤーのセットがあれば、出力の増加が信頼性を犠牲にする必要はないということです。むしろ、コーディングエージェントは以前よりも多くの、そしてより深いチェックを安価に追加できるようになりました。より多くのテスト、より多くのレビューパス、本番環境の問題のより迅速な診断などです。

したがって、品質に十分に焦点を当てているのであれば、バグを管理下に置きながらデリバリー速度を倍増させることは完全に可能だと私は考えています。あるいは、バグを減らすことさえできるかもしれません。