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

AIコーディングがコード品質を低下させているなら、品質管理が正しくできていない Iouri Khramtsov 2026年9月14日 共有 私がよく目にするコーディングエージェントに関する一般的な意見は、「確かにAIはコードの出力を助けるが、品質は低下しないか？」というものです。 PRを盲目的にマージして本番に送るだけなら、確かに品質は低下するでしょう。しかし、品質管理に慎重で多層的なアプローチを取れば、バグの数を安定させるだけでなく、実際には減らすことが可能だと私は考えています。それと同時に、出力は2〜2倍に増加します。 これらの防御層の多くは、Claude/Copilot/Codex/etc.以前とほぼ同じですが（ただし、AIによって容易になっています）、新しいものもあります。ここでは、私のチームや他の場所で実際に成功裏に使用されている防御設定を紹介します。 レイヤー1：要件を正しく定義する 仕様駆動開発を始めた後、新たに書かれたコードのバグが減少したことに最も驚きました。仕様駆動開発以前は、例えば新機能の開発において、チームはしばしば総工数の最大3分の1を開発後の「磨き上げ」、つまり様々なバグの発見と修正に費やしていました。これらのバグの多くは、特定の相互作用やエッジケースを予測できなかったこと、開発者がその日疲れていて十分な思考をしていなかったこと、あるいはデザイナーやPMが特定のシナリオを十分に検討しなかったことによって発生しました。これらのバグの一部は、見落とされて本番環境に届けられました。 仕様駆動開発を使い始めてから、私のコードにおけるこれらのバグの数は急激に減少し、一部の（しかし全てではない）チームメイトでも同様の減少が見られました。私の知る限り、この減少の主な原因は、プロセスの特定のステップにあります。それは、AIに要件や技術設計をレビューさせ、ギャップ、エッジケース、既存コードとの予期せぬ相互作用、その他の類似の問題点を見つけさせることです。 AIは疲れることがなく、適切にプロンプトを与えれば、問題点の発見を諦める可能性ははるかに低くなります。むしろ、時には過剰になることもあり、AIが提案する要件の編集を注意深くレビューして、実際には存在しない問題をAIが作り出していないことを確認する必要があります。 レイヤー2：95%以上のカバレッジを持つ単体テスト コーディングエージェントは現在、テスト駆動開発（TDD）を非常に容易にし、それを行わない理由はありません。ただし、正しく行う必要があります。エージェントに、追加したばかりのコードのバグに対して、単にパスするテストを盲目的に書かせたくないでしょう。そのため、私がこれまで見てきた最良の計画と実装スキルは、通常、次のパターンに従います。 エージェントに、要件に基づいてテストシナリオとテストケースを考えさせる。 テストケースを書く。 実装を書く。 テストケースに対して実装をテストし、発生した問題を修正する。 残りのカバレッジギャップを埋める（ただし、ここでも要件を念頭に置く）。 また、エージェントがテストを書くのであれば、ほぼ普遍的なカバレッジを目指さない、あるいは欠落した単体テストのバックフィルを待つという言い訳は通用しません。 レイヤー3：手動テスト 人間（あなた、QA、PM、あるいは他の誰か）が実際に機能を試用し、すべてのエッジケースを通過させ、すべてが期待通りに機能しているか、あるいは変更が必要かを確認することに代わるものはありません。 これらの手動テストは、テストシナリオの設定に手間がかかる場合、特に時間がかかることがあります。これは、これまでのところ生産性の向上にわずかな効果しか見られなかったステップの1つであり、私の出力が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/その他でこれらのエラーを自動診断し、根本原因を特定し、提案された修正を含むPRを作成することでしょう。 気に入りましたか？さらに多くの情報を受け取るには購読してください。 結論 高品質を維持するための他の重要なコンポーネントを見落としていることは確かですが、主な考え方は、適切な防御層のセットがあれば、出力の増加が信頼性を犠牲にする必要はないということです。むしろ、コーディングエージェントは以前よりも多くの、そしてより深いチェックを安価に追加できるようにしました。より多くのテスト、より多くのレビューパス、本番環境の問題のより迅速な診断です。 したがって、品質に十分に焦点を当てているのであれば、バグを制御下に置きながら配信速度を倍増させることは完全に可能だと私は考えています。あるいは、バグを減らすことさえできるかもしれません。 共有