AI生成PRの品質ゲートを自動化する：リスクベースCI設計

TL;DR

• AI生成PRの量に人間のレビューが追いつかないなら、CIで品質ゲートを自動化する
• リスクスコアリングでテスト深度を動的に変える
• 低リスクPRは自動マージ、高リスクPRは重点テスト＋人間レビュー

---

はじめに

本記事は、AI生成コードのテスト戦略を3層で整理した親記事の「層3: リスクベースCI」を深掘りします。 👉 AI生成コードのテスト戦略：品質を「祈り」から「仕組み」に変える

AIエージェントが1日に10本のPRを出す世界では、従来のCI/CD設計が破綻します。

すべてのPRに対してフルテストスイートを回すと、CI待ち時間が数時間になる。かといって、テストを省略すればバグが本番に漏れる。レビュアーは大量のPRキューに埋もれ、レビューが詰まる。

この問題の解決策は「すべてのPRを同じ扱いにしない」ことです。PRのリスクを自動判定し、リスクに応じてテスト深度と承認フローを動的に変える。これがリスクベースCI設計です。

---

1. なぜ「全PRに同じテスト」は破綻するか

CI時間の爆発

典型的なプロジェクトのフルテストスイート実行時間を想定します。

| テスト種別 | 実行時間 | | -------------------- | -------- | | lint + 型チェック | 1分 | | ユニットテスト | 3分 | | 統合テスト | 8分 | | E2Eテスト | 15分 | | パフォーマンステスト | 10分 | | 合計 | 37分 |

AIエージェントが1日10本のPRを出す場合、CI合計は370分（6時間以上）。コスト面でもGitHub Actionsの料金が跳ね上がります。

品質ゲートの形骸化

CI時間が長すぎると、開発者は2つの行動を取りがちです。

1. テストのスキップ: 「この変更は小さいから」とテストを飛ばす
2. 失敗の無視: 「このテストはflaky（不安定）だから」と失敗を放置する

どちらも品質ゲートの形骸化を招きます。

解決の方向性：リスクに応じたテスト深度

すべてのPRを同列に扱うのではなく、変更のリスクに応じてテストの深度を変えます。ドキュメントの修正と、データベースマイグレーションでは、必要なテストの深さが根本的に異なります。

リスクベースリリース運用で定義したリスクレベルの考え方をCI設計に直接適用します。

---

2. リスクベースCI設計

2.1 リスクスコアリング

PRのリスクを自動判定するために、以下の要素をスコアリングします。

# .github/risk-scoring.yml
rules:
  # ファイル種別によるリスク
  file_patterns:
    - pattern: "*.md"
      risk: 0 # ドキュメント
    - pattern: "*.test.*"
      risk: 1 # テストファイル
    - pattern: "src/components/**"
      risk: 2 # UIコンポーネント
    - pattern: "src/api/**"
      risk: 3 # APIエンドポイント
    - pattern: "src/db/migrations/**"
      risk: 5 # DBマイグレーション
    - pattern: ".env*"
      risk: 5 # 環境設定

  # 変更規模によるリスク加算
  size_rules:
    - max_lines: 50
      additional_risk: 0
    - max_lines: 200
      additional_risk: 1
    - max_lines: 500
      additional_risk: 2
    - above: 500
      additional_risk: 3

  # リスクレベル判定
  thresholds:
    low: 0-2 # Stage 1のみ
    medium: 3-5 # Stage 1 + 2
    high: 6+ # Stage 1 + 2 + 3

2.2 段階テスト戦略

リスクレベルに応じて、CIパイプラインを3段階に分けます。

graph TD
    A["PR作成"] --> B["リスクスコア算出"]
    B --> C["Stage 1: 基本チェックlint + 型 + ユニットテスト（全PR、3分）"]
    C --> D{"リスク = Low?"}
    D -->|はい| E["自動マージ判定へ"]
    D -->|いいえ| F["Stage 2: 統合チェック統合テスト + Contract Testing（中リスク以上、10分）"]
    F --> G{"リスク = Medium?"}
    G -->|はい| H["CODEOWNERSレビュー"]
    G -->|いいえ| I["Stage 3: フルチェックE2E + パフォーマンス（高リスク、25分）"]
    I --> J["シニアエンジニアレビュー必須"]

    style C fill:#d4edda,stroke:#28a745
    style F fill:#fff3cd,stroke:#ffc107
    style I fill:#f8d7da,stroke:#dc3545

Stage 1（全PR、約3分）:

• ESLint / Prettier
• TypeScript型チェック
• ユニットテスト（振る舞い駆動 + プロパティベース）

Stage 2（中リスク以上、追加約10分）:

• 統合テスト
• Contract Testing（LLM境界のスキーマ検証 + セマンティック検証）
• スナップショットテスト

Stage 3（高リスクのみ、追加約25分）:

• E2Eテスト（Playwright / Cypress）
• パフォーマンステスト（Lighthouse CI）
• セキュリティスキャン

2.3 自動マージ条件

低リスクPRについては、以下の条件をすべて満たした場合に自動マージを許可します。

# .github/workflows/auto-merge.yml
auto_merge_conditions:
  # すべてを満たす場合に自動マージ
  - risk_level: low
  - stage1_passed: true
  - codeowners_approved: true
  - no_security_alerts: true
  - branch_up_to_date: true

GitHub Actionsでの実装イメージ:

ポイントはrisk-scoreジョブの出力をもとに、後続のstage2/stage3をif条件で制御することです。needs.risk-score.outputs.level != 'low'でStage 2をゲートし、== 'high'でStage 3をゲートします。これにより、低リスクPRはStage 1のみ（3分）で完了し、高リスクPRだけがフルテスト（37分）を実行します。

---

3. 品質ダッシュボードと改善ループ

リスクベースCIを導入したら、その効果を計測し、継続的に調整します。

3つの指標

| 指標 | 計測方法 | 目標 | | -------------------- | ----------------------------- | ------------------------------ | | テストカバレッジ | Stage 1通過後のカバレッジ率 | 80%以上を維持 | | CI平均時間 | PRオープンから全Stage完了まで | Low: 5分以内、Medium: 15分以内 | | 自動マージ率 | 自動マージされたPR / 全PR | 30〜50%を目標 |

週次調整サイクル

品質ゲートの閾値は固定値ではなく、運用データに基づいて調整します。

1. 毎週月曜日: 先週のCI指標をレビュー
2. 自動マージ率が低すぎる（20%以下）: リスクスコアの閾値を緩める（ファイルパターンの再分類）
3. 本番バグが増えた: リスクスコアの閾値を厳しくする、またはStage 2の対象を拡大
4. CI時間が長すぎる: テストの並列化、キャッシュ戦略の見直し

AI開発KPIと学習ループで解説したKPI設計の考え方を、CIパイプラインにも適用します。指標を計測し、フィードバックループを回すことで、品質ゲートの精度は継続的に向上します。

テスト設計の基本に立ち返りたい場合は、ユニットテスト層の3つの型を確認してください。 👉 AI生成コードの「意図不明」に立ち向かう：テスト設計3つの型

---

まとめ

AI生成PRの量と速度に対応するには、「すべてを同じ扱い」から「リスクに応じた段階テスト」への転換が必要です。

• リスクスコアリング: ファイル種別と変更規模で自動判定
• 段階テスト: Low/Medium/Highの3段階でテスト深度を変える
• 自動マージ: 低リスク + Stage 1パス + CODEOWNERS承認で自動化

全部のPRにフルテストを回す必要はありません。リスクに応じた最適な品質ゲートを設計し、その精度を週次で改善していく。これがAI時代のCI/CD設計です。

• AI生成コードのテスト戦略：品質を「仕組み」に変える
• AI生成コードの「意図不明」に立ち向かう：テスト設計3つの型
• LLM出力は毎回変わる：Contract Testingで「変動に強い」テストを作る
• AI開発KPIと学習ループ
• リスクベースリリース運用