AIはコードを書いた。では、そのコードは良かったのか
AIエージェントが数分で1,000行のコードを生成した。しかし、CIは何度も失敗し、既存の機能で代替できるライブラリが追加され、レビュー担当者が実装の大半を書き直した。この変更を「生産性が上がった」と評価してよいのでしょうか。
生成行数や補完回数は、AIをどれだけ使ったかを示す活動量です。変更が安全だったか、チーム全体の仕事が減ったかまでは示しません。DORAの2025年の調査も、AIは組織の強みと弱みを増幅し、堅牢なテストや短いフィードバックループがなければ、変更量の増加が不安定性につながり得ると説明しています。DORAの2025年調査
この記事では、品質を次のように定義します。
AI生成コードの品質とは、同じ条件で検証結果を再現でき、既存の品質基準を通過し、必要な人手介入が許容範囲に収まり、マージ後の手戻りが少ない状態である。
つまり、中心となる測定対象は生成量ではなく、変更を安全に受け入れるためのコストです。
1. 生成行数を品質指標にしてはいけない
生成されたコードは、採用される前に削除、再生成、手動修正されます。冗長な抽象化や重複したテストでも行数は増えるため、多いほど価値が高いとは限りません。むしろ大きな差分は、レビュー対象や欠陥の混入箇所を増やすことがあります。
AI利用率を目標にすることにも副作用があります。本来は短い手修正で済む場面でもAIを使う、不要なコードまで生成する、といった行動を促しかねません。
生成量を捨てる必要はありません。ただし、KPIではなく文脈として使います。同じ30分のレビューでも、設定ファイルの50行と認証ロジックの50行は同じではありません。差分規模だけでなく、変更種別、対象モジュール、リスク区分と組み合わせて解釈します。
測るべきなのは、AIがどれだけ書いたかではなく、チームがその変更をどれだけ低コストかつ安全に受け入れられたかです。
2. 評価単位は「生成コード」ではなく「変更セット」
どの行をAIが生成し、どこから人間が編集したかを厳密に追跡するのは困難です。そこで、評価の基本単位をPull Requestにします。コミット、開発タスク、エージェントの1実行、本番リリースも候補ですが、PRには差分、CI、レビュー、マージ後の履歴を結び付けやすいという利点があります。
PRごとに最低限、次を保持します。
- AI利用の有無と利用形態
- 変更種別、対象モジュール、差分規模
- 認証、決済、データ移行などのリスク区分
- AIの再実行回数と作成者の手動修正区分
- 初回を含むCI結果
- 直接・推移的依存関係の差分
- レビュー実作業時間と修正ラウンド数
- マージ後のリバート、ホットフィックス、関連修正
AI利用PRと非利用PRをそのまま比較してはいけません。難しいタスクだけにAIを使っていれば、AI利用側が不利になります。変更種別、規模、リスク、対象システム、担当者の経験、新規開発か保守かを揃え、同じ層の中で比較します。
3. 品質ゲート① テスト：通ったかではなく、信頼できるか
テスト成功は必要条件ですが、十分条件ではありません。AIが仕様を誤解した場合、実装とテストの両方に同じ誤解を反映することがあります。カバレッジや生成テスト件数だけを成果指標にすると、その問題を見逃します。
ハードゲート
次は、原則としてマージ条件に向いています。
- キャッシュを前提としないクリーン環境でビルドできる
- 既存テスト、静的解析、型チェックが成功する
- 仕様変更に対応するテストが追加・更新されている
- 境界値、異常系、権限、並行実行など、変更のリスクに対応したケースがある
- 同じコミットを再実行しても結果が安定する
再現可能性の確認では、ソースだけでなく、ビルドツール、設定、依存関係、タイムゾーン、ロケールなども入力として扱います。Reproducible Buildsの文書も、環境の定義と、時刻、順序、乱数、ビルドパスなどの変動要因の管理を挙げています。Reproducible Buildsの文書
観測指標
初回CI成功率は、PRの最初のCI実行が成功した割合です。最終的に通ったかだけでなく、最初の変更セットがどこまで完成していたかを見ます。
CI再実行率は、コードを変更せず再実行したPRの割合です。同一コミットで成功と失敗が入れ替わるなら、生成コードより先にテスト基盤の不安定性を疑うべきです。Googleのテスト解説も、同じコードで成功と失敗の両方を示すテストは信頼性を失うと説明しています。Google Testing Blog
テストゲートの誤検知率は、ゲートが止めた変更のうち、調査後にコード欠陥ではないと分類された割合です。
誤検知率 = 誤って停止した変更数 ÷ ゲートが停止した変更数
マージ後の不具合流出率は、ゲートを通過した変更のうち、定めた観測期間内に関連不具合が見つかった割合です。成功率が高いのに流出率も上がる場合は、テストの量ではなく、仕様への対応力を見直します。重要ロジックでは、テストが意図的な変異を検出できるか確かめるミューテーションテストも選択肢になります。
4. 品質ゲート② 依存関係：動くコードが保守できるとは限らない
AIは、既存のユーティリティを探す代わりに新しいパッケージを追加して、局所的に問題を解くことがあります。しかし依存追加は、脆弱性、ライセンス、更新、ビルドサイズ、廃止対応という将来コストも追加します。
依存関係のレビューでは、次を確認します。
- 新しい直接依存と、それに伴う推移的依存
- 既存機能や標準ライブラリで代替できない理由
- メンテナンス状況と更新方針
- 既知の脆弱性、ライセンス、配布条件
- 意図しないメジャー更新や大規模なロックファイル変更
- 固定可能なバージョンと再現可能な取得方法
ハードゲートには、重大度がチームの拒否基準以上の既知脆弱性、禁止ライセンス、出所不明のパッケージ、再現不能なバージョン指定などを置きます。新規依存の必要性やロックファイルの大規模変更は、理由の記載を求めるソフトゲートが適しています。GitHubの公式ドキュメントにも、PR内の直接・間接依存の差分を調べ、脆弱性の重大度やライセンスに応じて失敗させる例があります。GitHub Dependency Review
運用指標として、PR当たりの新規依存数、依存追加への指摘数、脆弱性による差し戻し、追加後に短期間で削除・置換された依存の割合を記録します。最後の指標は、AIが不要な複雑性を持ち込んだ可能性を示しますが、単独で失敗とは判定しません。
5. 品質ゲート③ 人手介入：AIが書いた量ではなく、人間が直した量を見る
AIの価値は、人間の仕事をどこに、どれだけ残したかに現れます。介入は作成者側とレビュアー側に分けます。
作成者による介入
- AIへの修正依頼と再実行の回数
- 生成後の手動編集量
- 生成コードを破棄して再実装した回数
- AIから人間の実装へ切り替えた割合
レビュアーによる介入
- 修正ラウンド数とレビューコメント
- レビューに費やした実作業時間
- 設計変更を求めたか
- レビュアー自身が再実装したか
最重要なのは、PR作成からマージまでの経過時間ではなく、レビューの実作業時間です。経過時間には、順番待ち、営業時間外、他タスクによる中断が含まれます。計測は、レビュー開始・終了の明示操作、IDEやレビュー画面のアクティブ時間、短い自己申告などから始められます。ただし、個人評価に流用すると計測が歪むため、チームの工程改善を目的に集計します。
厳密な行単位の書き直し率が取れない場合は、次の順序尺度で十分です。
- ほぼそのまま採用
- 軽微な修正
- 部分的に再実装
- 大半を再実装
- 全面的に破棄
人手介入が多いことを直ちに失敗とみなしてはいけません。認証やデータ移行の設計では、人間の介入が期待されます。比較は同じリスク層で行い、実装時間、レビュー時間、修正対応時間を合算します。
6. 最終的に見るべき4つの結果指標
テスト、依存関係、人手介入は先行する品質ゲートです。本当に機能したかは、次の結果指標で確認します。
6.1 再現可能性
同じコードと明示された設定から、クリーンな別環境でも同じビルド・テスト結果を得られた割合です。依存関係の再取得、複数回実行、実行順序、タイムゾーン、外部API、ローカルファイルへの暗黙依存を含めて確認します。
6.2 誤検知率
品質ゲートが停止した変更のうち、実際には欠陥ではなかった割合です。停止数だけでなく、実欠陥を止めた数と正常な変更を誤って止めた数を分けます。誤検知が多いゲートは、警告の無視や迂回を招くため、ハードゲートからソフトゲートへ戻す判断も必要です。
6.3 手戻り率
マージ後の所定期間内に、リバート、ホットフィックス、同一原因の追加PR、仕様漏れの再実装、依存削除、性能・セキュリティ修正が必要になった変更の割合です。DORAも、即時介入が必要なデプロイの割合と、障害に起因する計画外デプロイを安定性の指標として扱っています。DORAのソフトウェアデリバリー指標
6.4 レビュー時間
実装者が30分短縮しても、レビューと修正対応がそれ以上増えれば、チーム全体の受け入れコストは下がりません。次をセットで追います。
受け入れ時間 = 実装時間 + レビュー実作業時間 + 修正対応時間 + マージ後の手戻り時間
金額換算する場合は、役割ごとの時間単価やCIコストも加えられます。ただし、単一スコアだけで判断せず、どの工程にコストが移動したかを残します。
7. 品質ゲートをチームに導入する方法
一度にすべてをマージ条件にすると、誤検知や入力負荷によって形骸化します。観測、ソフトゲート、ハードゲートの順に進めます。
フェーズ1：観測する
最初の2〜4週間を初期案とし、初回CI成功率、新規依存数、レビュー時間、修正ラウンド、手戻り、AI利用の有無を収集します。この期間はマージを止めず、リポジトリとリスク層ごとのベースラインを作ります。
フェーズ2：ソフトゲートにする
新規依存、重要ロジックのテスト不足、大きな差分、必要なレビューの未実施などに警告を出し、マージ時に理由を記録します。例外理由は、後でルールの精度を改善するためのデータになります。
フェーズ3：安定した項目だけハードゲートにする
ビルド・テスト成功、重大な脆弱性や禁止ライセンスがないこと、クリーン環境での再現、必須レビュアーの承認など、判定が明確で誤検知の少ない項目だけを必須化します。
レビュー時間、コメント数、AI再実行回数、書き直し区分、手戻り率は観測指標のままにします。これらに一律の閾値を設けると、難しい変更を分割せず避ける、コメントを残さないといったゲーム化を招くためです。
運用開始後は月次など一定周期で、ゲートが防いだ欠陥、誤検知、例外、計測負荷を確認します。NIST SSDFも、固定チェックリストではなく、組織のリスク許容度や資源に合わせて段階的に改善する基盤として実践項目を位置付けています。NIST Secure Software Development Framework
まとめ：生成量から「受け入れコスト」へ
生成行数や利用回数は導入状況を示しますが、品質は保証しません。確認すべきなのは、テスト結果を再現できるか、不要・危険な依存を増やしていないか、人間の修正とレビューが許容範囲か、マージ後の手戻りが増えていないかです。
AI生成コードの品質とは、AIがどれだけ多く書いたかではなく、チームがその変更をどれだけ安全かつ低コストで受け入れられたかで決まる。