AI品質安定化モデルは、AIを単独の作業者として扱うのではなく、工程ごとに作業支援、セルフレビュー、品質ゲート、ナレッジ化の4層へ配置する考え方である。
2.0b AI品質は「モデル」より「経験設計」で決まる
PoC段階でも、LLM/エージェントの振る舞いはどの資料を・どの順序で・どの評価で浴びせるかで変わる（カリキュラム学習の一般論）。本調査の副操縦士モデルは、プロンプト一発ではなく ルール → スキル → アンカー（ADR/REQ/19章マスタ）→ 評価（KPI/eval/drift）→ ログ（PR/BTS） の5層で品質を維持する。
AIに長く・多段に作業させると、過去に合意した設計意図・例外条件・命名規則・責務分離・非対象範囲を見落とす可能性がある。本ガイドでは、判断構造を参照点（アンカー）としてADRへ記録し、PR・CI・AIレビュー・handoff から継続参照する運用をPoC仮説として扱う。
| 観点 | 本パック | 定着後（dev_docs） |
|---|---|---|
| アンカー | 第19章マスタ · 第13章禁止事項 | ADR Quality Anchor · REQ正本 |
| 評価 | 第12章KPI · Agent-native eval（7.0b） | CI QG · semantic-drift-audit |
| 順序 | 00提案→17スキル→11PoCの読み順 | チケットループ · ゲート順 |
| 劣化防止 | ゴールデンevalでスキル退行検知 | ADR Must Preserve · Drift Signals |
研修 — NIST AI RMF / ISO/IEC 25010 / 本パック KPI 対応
PoC の「何を測るか」を外部基準と対応づけると、経営・監査・品質担当への説明がしやすくなる。本表は研修・提案用の対応メモであり、認証・適合宣言ではない。
| NIST AI RMF 特性 | 研修での言い換え | 本パックの実装 | 代表 KPI / 証跡 |
|---|---|---|---|
| Valid & Reliable | 意図どおり・安定して効く | PR前レビュー · 要件ゲート · eval | AI指摘採用率 · 手戻り件数 · eval 合格率（第12章） |
| Accountable & Transparent | 誰が何を判断したか追える | PRテンプレ · AI利用ログ · Human Gate | AI-OPS-LOG · PR の採否理由欄（第13・14章） |
| Secure & Resilient | 機密を守り・想定外に耐える | 投入禁止 · スキル監査 · サンドボックス | 機密投入ゼロ · 公開スキル 13.2d チェック（第13章） |
| Explainable & Interpretable | 指摘の根拠が分かる | レビュー観点の標準化 · 記録様式 | 採用/保留/不採用の理由1行（演習1） |
| Privacy-Enhanced | 個人情報・顧客データを守る | データ分類 · マスキング方針 | 投入可否チェックリスト（第13章） |
| Fair（有害バイアス管理） | 不当な差別・偏り | PoC 範囲外は UNRESOLVED と明記 | —（本パック初回研修では概要のみ） |
| ISO 25010 | AI支援ワークフローでの見方 | 本パック章 |
|---|---|---|
| 機能適合性 | AI指摘が仕様・受入基準に沿うか | 第04章 · 第17章 B-1 |
| 信頼性 | 同種の差分で指摘品質が安定するか | 第12章 eval · 第21章 |
| 使用性 | レビュー時間が増えすぎないか | 第12章 P-1 · 週次 KPI |
| 保守性 | スキル・プロンプト変更が追跡できるか | 第17章 17.0b · 第07章 |
| セキュリティ | 機密・権限・本番変更の統制 | 第13章 · 第09章 |
根拠: NIST AI RMF — Trustworthy AI characteristics · ISO/IEC 25010（ソフトウェア品質モデル）。詳細キュレーション: training_cursor_research_20260713.md
やらないこと: KPI 未実測を「準拠済み」と言う · Installs/Stars のみを品質根拠にする。
2.1 4層モデル
| 層 | 目的 | 対象 | 成果 |
|---|---|---|---|
| 第1層：作業支援 | 作業速度を上げる | コード、設計書、テストケース、手順書 | たたき台作成、比較案作成 |
| 第2層：セルフレビュー | 担当者自身の確認品質を上げる | 実装前後、設計後、テスト前 | 単純ミス・抜け漏れ削減 |
| 第3層：品質ゲート | 成果物を通過判定する | PR、設計書、テスト仕様、IaC、作業申請 | レビュー品質の平準化 |
| 第4層：ナレッジ化 | 組織知を再利用する | 過去障害、レビュー指摘、標準ルール | 属人化防止、再発防止 |
2.2 AIを入れるべき工程
| 工程 | AI活用 | 品質ゲート |
|---|---|---|
| 要件定義 | 曖昧語、未定義語、例外条件、受入条件の不足を抽出 | 要件レビュー会議前にAI指摘を確認 |
| 基本設計 | 画面・帳票・IF・DB・権限・運用の漏れ確認 | 設計レビュー時に指摘採否を記録 |
| 詳細設計 | 処理分岐、例外、トランザクション、ログ、再実行性を確認 | 製造着手前に未解決事項を潰す |
| 実装 | 実装案比較、コード生成補助、セルフレビュー | PR前にAIレビューと単体テスト実行 |
| テスト | 観点生成、ケース作成、回帰候補抽出 | QAが採否判断しテスト管理表へ反映 |
| リリース | 作業手順、切り戻し、影響範囲をレビュー | 作業申請にAIチェック結果を添付 |
| 運用 | ログ要約、障害一次切り分け、再発防止案 | 人間承認後に対応、報告書へ反映 |
2.3 品質ゲートの標準フロー
成果物作成
↓
AIセルフレビュー
↓
担当者がAI指摘を採否判断
↓
機械チェック
↓
人間レビュー
↓
修正
↓
再チェック
↓
承認
↓
証跡化AI出力は成果物ではなくレビュー材料である。AIの提案を採用する場合も、採用理由、修正内容、確認結果を担当者が説明できる必要がある。
2.4 品質ゲートの例
| 対象 | AIチェック | 機械チェック | 人間チェック |
|---|---|---|---|
| コード | Null、例外、重複、テスト不足 | ビルド、単体テスト、Lint、SAST | 仕様整合、設計思想、保守性 |
| 設計書 | 曖昧性、例外、非機能、影響範囲 | 表記ルール、成果物整合 | 顧客要件、業務ルール |
| テスト仕様 | 観点漏れ、境界値、異常系 | テスト管理ツール整合 | 優先度、実行可能性 |
| IaC | 公開範囲、暗号化、タグ、破壊的変更 | validate、tflint、checkov、plan | 運用影響、コスト、承認 |
| 作業手順 | 切り戻し、影響範囲、確認不足 | dry-run、検証環境実行 | 本番影響、作業順序、承認 |
