目的: 問題をゼロにするのではなく、気付けるようにする
PoCでは、AIが役立ったかを感想ではなく検知可能なシグナルで判定する。 Quality Signals LoopはAI専用監視ではなく、要件不足、承認不足、テスト不足、文書の同期漏れ、AI挙動の退行を同じ改善ループで扱う。
設計原則: 決定的に検査できるものはCI、人の判断理由はPR、非決定的なAI挙動はeval、傾向は週次、重大事象はポストモーテムで扱う。
5段のQuality Signals Loop
最小構成
| 場所 | 最初に入れるもの | 検知できる問題 |
|---|---|---|
| PR | 要件ID、ADR/handoff更新要否、差し戻し理由 | 文脈不足、承認不足、追跡漏れ |
| CI hard gate | build、test、lint、secret、OpenAPI | 再現可能な違反 |
| eval | 代表10〜20ケース | prompt、rules、model変更による行動退行 |
| 週次 | DORA系指標、理由別件数、eval失敗 | チーム全体の劣化傾向 |
| 重大時 | blameless postmortem | Gateをすり抜けた根本原因 |
止め方を3段階に分ける
| 段階 | 用途 | 例 |
|---|---|---|
| Warn | 誤検知率を測る | ADR更新候補、要件ID不足 |
| Soft gate | 理由付き承認で通過可能 | カバレッジ低下、文書同期候補 |
| Hard gate | 例外なく停止 | build/test失敗、secret混入 |
チェックを一度に増やさない。Warnで精度と負荷を確認し、事故防止効果が明確な項目だけHard gateへ昇格する。
導入順と拡張条件
- Phase 1: PR理由分類 + 既存CI
- Phase 2: Required Checks + 代表eval
- Phase 3: 週次Quality Signalsレビュー
- Phase 4: 本番AIアプリだけLLM Observability / OpenTelemetry
| 追加機能 | 導入条件 | まだ不要な状態 |
|---|---|---|
| LLM Observability | 本番Bot/RAG/Agentに実トラフィックがある | 開発支援・文書PoCのみ |
| OpenTelemetry | API/分散処理の実行時問題を追う | PR・文書品質だけを扱う |
| ポストモーテム | 本番影響、セキュリティ、重大なGateすり抜け | 軽微な差し戻し |
週次15分の判断
- 増えた理由分類とeval失敗を見る
- 改善候補を1〜3件に絞る
- REQ / ADR / rules / CI / templateの更新先を決める
- 翌週のシグナルで改善したか確認する
禁止: 個人評価への利用、ログ項目の無制限追加、改善タスクの無審査自動起票、機密本文の保存。
