10月15日、Addy Osmaniが「Agentic Code Quality」と題した記事を公開した。AIエージェントが大量のコードを生成する時代において、コード品質をどのように担保するかを論じた内容で、従来のコードレビュー中心のモデルから「制約設計」へのパラダイムシフトを提唱している。
なぜ今、この問題が深刻化しているのか
LLMベースのコーディングエージェントの普及は、ここ1〜2年で急速に進んだ。GitHub CopilotやCursorのようなツールにとどまらず、自律的にissueを読み、ブランチを切り、プルリクエストを作成するエージェントが実運用に入り始めている。その結果、1つのチームが1日に生成するコード変更の量は、人間だけが開発していた時代と比較してケタ違いに増加している。
この変化はCI/CDパイプラインにも波及する。人間が書くコードを前提に設計されたレビュープロセスやゲートは、エージェントが秒単位で生成するdiffの量に対応できない。従来の「誰かが書いたコードを人間が読む」モデルは、速度の面でも規模の面でも、根本的に限界を迎えつつある。
「コードレビュー」はもはやスケールしない
エージェントが1日に何十万、何百万もの変更を生成する世界では、人間がすべてのdiffを読むことは現実的ではない。Osmaniはこの問題を端的に表現している。
「ソフトウェアの品質は、エージェントの周囲に設定する制約によって決まる。」
品質保証の責任は、エージェントを囲むハーネス・環境・制約の側に移行する。「誰かが書いたコードを読む」から「エージェントが通過すべきゲートを設計する」へ——これが記事全体を貫く主張だ。
制約＝品質ゲートの設計が核心
Osmaniが提唱するのは「クオリティゲート」という概念だ。エージェントはあらゆる変更を提案できるが、それが実際にプロダクションに到達するかどうかは、制約の群れが決定する。
クオリティゲートの具体的な構成要素：
- ユニットテスト・プロパティテスト・受け入れテスト：基本的な正しさの検証。プロパティテストとは、特定の入出力例ではなく「任意の入力に対して成立すべき性質（プロパティ）」を検証する手法で、エッジケースを広くカバーできる
- ミューテーションテスト：コードの変形バリエーションを生成し、テストが本当にバグを検出できるかを確認する手法
- 循環的複雑度・行長などのメトリクス：可読性の維持
- 型安全性・パフォーマンス・セキュリティスキャン：それぞれ独立した責任を持つチェック
- ESLintなどによるアーキテクチャルール：コードベース固有の規約の自動強制
重要なのは、これらのチェックをパイプラインの末尾だけに置かないことだ。CIでデプロイを弾くだけでは遅すぎる。型チェックや静的解析のように、早い段階からフィードバックループに組み込む設計が求められる。これはCI/CDのシフトレフト原則とも一致する考え方だ。
「自律性は検証ループを通過して初めて得られる」
エージェントに自律性を与えることと、品質を守ることはトレードオフに見えるが、Osmaniの考え方は明確だ。
「自律性はモデルが付与するものではなく、検証ループを通過することで得られるものだ。」
エージェントが失敗する理由の多くは、人間が失敗する理由と共通している。不安定な環境、非決定的なビルド、権限の欠如、弱いテスト。つまり、エージェントを信頼できる環境とは、実際に作業でき、信頼できるフィードバックが得られ、失敗してもダメージが小さい環境のことだ。
記事中に登場する「ソフトウェアファクトリー」とは、このような環境を体系化した概念だ。インテント（意図・要件）が入力され、エージェントが実装し、自動検証によって生成されたエビデンスが出荷可否を決定する——という一連のパイプラインを指す。
人間のレビューはどこに向けるべきか
制約が自動化されると、人間のレビュアーの役割が変わる。Osmaniはこう述べている。
「人間の注意は希少で価値がある。自動化されたガードレールが破綻したときだけ、下流の人間を呼び込むべきだ。」
機械速度で動くシステムの中に人間のレビューステップを挿入すれば、生産性への影響は避けられない。だからこそ、人間の判断が本当に必要な趣味・意図・アーキテクチャの判断に集中させる設計が重要になる。
スケーリングのトリレンマ
変更の生成速度が検証システムの処理能力を超えた場合、取れる選択肢は3つだ。
- 検証システム自体をスケールアウトして処理能力を増やす
- エージェントの変更生成レートを下げて検証に追いつかせる
- 品質基準を下げて検証の厳しさを緩める
Osmaniはこの3つを状況に応じて使い分ける必要があると指摘する。ここで注意が必要なのは、3つ目の「品質基準を下げる」という選択肢だ。これは品質ゲートの全廃を意味するのではなく、どのチェックをクリティカルパスに置き、どれをベストエフォートとして扱うかの優先順位を見直すという文脈で語られている。エージェントのswarms（群れ）や自動化されたソフトウェアファクトリーを活用して個別レビューなしに変更を生成するアプローチを取る場合、すべてのゲートを均等に厳しく保つことは現実的ではない——その前提のもとでのトレードオフの話であり、品質を軽視する方向への転換ではない。
品質は単一のメトリクスではない
最後にOsmaniが強調するのは、品質の多次元性だ。
「ソフトウェア品質は単一のメトリクスではない。重要度の異なるシグナルの集合体だと捉えるべきだ。」
正しさ（correctness）だけでなく、保守性・パフォーマンス・セキュリティ・効率性・理解しやすさが品質を構成する。どこに強い制約をかけ、どこを緩めるか。その判断こそが、エージェント時代のエンジニアリングチームに求められる設計力だ。
詳細はAgentic Code Qualityを参照していただきたい。
