🛡️ AI が書いたコードは「品質ゲート前提」で運用する
AI コーディングツールは高速でコードを量産します。しかしそのままリリースすると、型別テスト漏れ・TDD 違反・スペック逸脱・「TODO のまま」が混ざります。 人間の感覚レビュー では拾いきれません。
CTS-EC ではステアリング駆動開発のすべてのフェーズに 自動品質ゲート を挟んでいます。本記事ではシリーズ第 6 回として、ドキュメントレビュー → テスト品質 → 実装検証 → ミューテーションテスト → push 前統合ゲートまでの運用を解説します。
🧭 ゲートの配置：ステアリングのどこに何を挟むか
壁打ち → 規模判定 → ステアリング作成
↓
doc-reviewer（完全性・具体性・一貫性） ← ゲート①
↓
design-reviewer（DDD・集約・BC） ← ゲート②
↓
オーナー承認 → 実装開始
↓
Phase 完了ごと：
/test + /check-test-quality ← ゲート③
implementation-validator ← ゲート④
↓
全 Phase 完了 → /pre-push ← ゲート⑤
（code-reviewer + validator 再実行）
↓
Push → MR各ゲートは責務が異なり、重複なく連携するよう設計しています。
📝 ゲート①: doc-reviewer（ドキュメント完全性レビュー）
doc-reviewer サブエージェント（Sonnet 4.6）は、ステアリング作成完了時にドキュメントを詳細レビューします。最大 1000 行、3〜5 分で完了します。
7 観点のチェック
| # | 観点 | 代表的な指摘 |
|---|---|---|
| 1 | 完全性 | 必須項目（背景・目的・受入条件・データモデル・API 定義）の欠落 |
| 2 | 具体性 | 「適切に」「必要に応じて」「など」「高速に」の検出 |
| 3 | 一貫性 | glossary.md と用語が一致しない |
| 4 | 測定可能性 | 「パフォーマンスが向上する」→ 数値基準なし |
| 5 | 依存関係 | specs/INDEX.md の参照先が存在するか |
| 6 | 実装可能性 | 「AI で自動判定」だけで手段不明 |
| 7 | TDD 準拠 | tasklist.md でテスト→実装の 2 ステップ分離がない |
NG 表現の具体例
❌ 「適切にエラー処理する」
→ 「エラー時は 400 を返却し、メッセージに理由を含める」
❌ 「100 件程度の処理」
→ 「商品数が 100 件を超える場合」
❌ 「応答が高速」
→ 「100 ms 以内に応答」優先度「高」の指摘は 実装前に必ず解消 します。
🏛️ ゲート②: design-reviewer（ドメイン設計レビュー）
doc-reviewer の後、M / L 規模では design-reviewer を必須化（2026-04-18〜）しています。異なる視点で 2 段レビューすることで死角を減らします。
| レビュー観点 | 内容 |
|---|---|
| ユビキタス言語の適切性 | glossary.md との一致 |
| 集約境界の妥当性 | 集約ルート・値オブジェクトの分離 |
| Bounded Context の責務分離 | BC 間の依存方向 |
| DDD パターンの正しい適用 | エンティティ / 値オブジェクト / 集約の誤用 |
スキップ可の条件
- S 規模（バグ修正・軽微な変更）
- 製品ドメインを含まないメタタスク（Claude Code 設定変更など）
両者 PASS で初めてオーナー最終承認に進めます。doc-reviewer のみで次に進むのは禁止です。
🧪 ゲート③: /check-test-quality による型別網羅性
test-quality-checker サブエージェントが、Phase 完了時に 型別基準 でテスト網羅性を検証します。
.NET（xUnit + Theory/InlineData）の型別基準
| 検出した型 | 必須テストケース |
|---|---|
bool | true と false 両方の InlineData |
enum | enum の全値 + 不正値 |
int / long / decimal | 0, 正数, 負数, 境界値 |
string | "", null, 通常値, 特殊文字 |
DateTime / DateTimeOffset | 月末（28/29/30/31）、うるう年（2/29）、年跨ぎ（12/31→1/1）、TZ |
T?(nullable) | null と非 null 両方 |
List<T> / T[] | 空, 1 件, 複数件 |
Guid / ID 系 | 存在する値, 存在しない値, 空 |
分岐カバレッジ推定
| パターン | 必須テスト |
|---|---|
if / else | 条件式の true / false 両方 |
switch / match | 全ケース + default |
?. / ?? | null / 非 null 両方 |
| 早期リターン（ガード） | ガードに引っかかるケース |
不足があれば 具体的な追加案 がレポートされ、テスト追加 → 再実行 → PASS のループに入ります。
✅ ゲート④: implementation-validator（7 観点 + 完全性）
implementation-validator は Phase 完了時に 実装完全性 を最優先でチェックします。
最優先：実装完全性チェック（1 件でも ❌ FAIL）
| 検出対象 | 検出コマンド |
|---|---|
| TODO / FIXME / HACK / TBD | Grep "TODO|FIXME|HACK|TBD" |
| 未実装例外 | Grep "NotImplementedException|NotImplementedError" |
| stub 実装 | Grep "throw new NotImplementedException" |
| 空テスト | Grep "public.*void.*Test.*\{\s*\}" |
「方向性は合っている」で PASS にしない のが原則です。
7 観点チェック
| # | 観点 | 責務 |
|---|---|---|
| 1 | コーディング規約・命名 | implementation-validator |
| 2 | エラーハンドリング | implementation-validator |
| 3 | テスト可能性・網羅性 | implementation-validator |
| 4 | 既存パターン整合性 | implementation-validator |
| 5 | セキュリティ・パフォーマンス | implementation-validator |
| 6 | スペック準拠（メソッド / I/F レベル） | implementation-validator |
| - | TDD 準拠・DDD・SOLID・CLAUDE.md 準拠 | code-reviewer（別エージェント） |
2026-04 の責務分割で、implementation-validator と code-reviewer は 観点が重複しないため並列実行可能 になりました。これにより Phase 完了時の待ち時間が短縮されます。
🧬 ミューテーションテストで「テストの穴」を検出
mutation-tester は Stryker.NET で カバレッジでは見えないテストの質を検証します。CTS-EC では以下のドメインロジックを対象にしています。
| プロジェクト | 対象 |
|---|---|
CTS.EC.Catalog | カテゴリ、商品のドメインロジック |
CTS.EC.Store | 店舗、在庫のドメインロジック |
除外：Tests / Infrastructure（DB・外部 API）/ Api（Controller の最小ロジック）
スコア判定
| スコア | 判定 |
|---|---|
| 80% 以上 | ✅ 良好 |
| 60〜80% | ⚠️ 要改善（テスト追加） |
| 60% 未満 | ❌ 本番投入ブロック |
実行時間が長いため バックグラウンド実行 と --since main オプションで差分のみ検証する運用を推奨しています。
🔍 Evidence Gate：記憶ベースの品質判定を禁止
品質ゲートの運用で最も重要なのが Evidence Gate スキルです。「確認」「再確認」「思い出して」「進捗を確認」等のキーワード検出時に、 記憶依存の回答を禁止 し、ツール実行で証拠を取ってから回答することを強制します。
| キーワード | 必須実行ツール |
|---|---|
| 「設定を確認」 | Read .claude/settings.json |
| 「ステアリングを確認」 | Read .steering/ACTIVE.md + 該当ファイル |
| 「実装を確認」 | Grep / Read で対象コード |
| 「進捗を確認」 | Read tasklist.md |
| 「過去のステアリング」 | ls .steering/archive/ + 該当 Read |
| 「比較」 | 両対象を Read してから比較 |
品質レビューで「以前確認した内容では〜だったはず」は 信頼度ゼロ として即撤回します。
🚧 ゲート⑤: /pre-push 統合ゲート
Push 前の最終ゲートです。以下の順序で実行し、失敗したら即中断します。
Step 1: ブランチ確認（main なら即中断）
↓
Step 2: 未コミットファイル確認
↓
Step 3: /test（test-runner 経由。スタンプが最新ならスキップ可）
↓
Step 3.5: ドキュメントのみ変更の判定
↓ （コードを含む場合）
Step 4: code-reviewer（TDD/DDD/SOLID/CLAUDE.md 準拠）
↓
Step 5: implementation-validator（7 観点 + 完全性）
↓
Step 6: スタンプ発行 → push 可能省略禁止の原則
Step 4 / 5 は 「変更量が少ない」「シンプルな変更」は省略理由にならない と明記されています。コードを含む変更であれば例外なく実行します。
📏 受入テスト消化ゲート
/steering-complete 時に requirements.md の AT-*（受入テストシナリオ） と実装テストを突合します。未消化シナリオがあれば完了を保留します。これがないと「テストは通っているが受入条件を満たさない」状態が放置されます。
フロントエンド変更を含む場合、AT-* に対応する *.spec.ts（E2E）が存在することも必須です。
⚠️ 品質ゲートでやってはいけないこと
- doc-reviewer のみで Step 5 に進む（design-reviewer スキップ）
/check-test-qualityを通さずに Phase 完了にするTODO / FIXME / NotImplementedExceptionが残ったまま PASS 判定- Evidence Gate を無視して「〜のはず」で回答する
/pre-pushの Step 4 / 5 を「シンプルな変更だから」省略する- 受入テスト AT-* の突合をスキップしてステアリング完了
📚 シリーズ記事
| # | タイトル | 内容 |
|---|---|---|
| 1 | 概要 | ステアリング駆動開発の全体像 |
| 2 | 壁打ち・規模判定編 | 壁打ちの進め方、ADR の書き方、規模判定の基準 |
| 3 | ステアリング作成編 | M/L 規模のドキュメント作成、TDD タスク分解 |
| 4 | 実装・完了編 | TodoWrite 連携、進捗管理、アーカイブ運用 |
| 5 | コンテキスト設計編 | AI に渡すコンテキストの最適化、skills 設計 |
| 6 | 品質ゲート編（本記事） | doc-reviewer、テスト品質チェック、受入テスト |
| 7 | Claude Code ベストプラクティス | CLAUDE.md 設計、hooks、commands、rules、skills |
| 8 | Agent Teams 編 | agents 定義、チーム構成、マルチエージェント協調 |
| 9 | Remote Control 編 | スマホ・Web から CLI セッションを操る席拘束からの解放 |
🔗 関連記事
- Claude Code 7層ハーネスエンジニアリング — ハーネス全体像
- 実装・完了編 — Phase 検証と pre-push の位置づけ
📖 関連用語
- ハルシネーション — Evidence Gate と完全性チェックで検出する失敗モード
- ハーネスエンジニアリング — 品質ゲートを支える恒久的な運用基盤