第7章：DevSecOps・セキュリティ向け活用

7.0b Agent-native CI/CD — スキル・プロンプト変更のゲート

第7章の DevSecOps 原則を、エージェント設定変更にも拡張する（Zylos 2026）。コードが緑でも、プロンプト1行で本番挙動が変わる。

7.0c SASTスタック選定 — CodeQLとSemgrepの使い分け

第7章 7.1 の SAST フローを具体化。CodeQLはデータフロー脆弱性、Semgrepは社内禁止実装・高速カスタムルール向き。両方をCIに載せ、AIは修正案提示のみ（7.2）。

価格は相対評価（5=低コスト/OSS中心）。正式導入時は各公式のライセンスを再確認。

セキュリティ重視構成

事例D-1との接続

本章 Before/After 事例D-1（High修正 4.2→2.1日）は、再スキャン必須のゲート化とセットで効いた。AI修正案採用率71%でも、残り29%は人間修正＋再スキャン。

7.0d 既存 CI/CD と AI の協調動作 — 事例集

第7章 DevSecOps の SAST/CI 原則を、既存 Jenkins · GHA · GitLab CI と AI レビュー/ログ要約の組合せに拡張する。Agent-native CI/CD（7.0b · スキル eval）とセットで、コード変更とエージェント設定変更の両方をガードする。

本節の主旨: AIを開発の自動操縦役にせず、既存の CI/CD · Git · Redmine 等と連携し、人間が判断可能な形で品質情報を整理する補助レイヤーとして使う。

AIに全部任せるのではない。
CI/CDが事実を検出し、
AIが読み解き、
Redmine/Gitに経緯を残し、
人間が判断する。

多層パイプライン（推奨）

Lint/Formatter → Semgrep/SAST → Unit Test → SonarQube QG
  → AI PRレビュー（参考）→ 人間レビュー → merge
CI失敗時: Webhook → AIログ要約 → Slack + Redmine追記 → 人間判断

事例キュレーション（16件）

導入優先: ★5=既存CIを壊さず効果が見えやすい · ★4=PoC第2段 · ★3=閉域/ベンダー縛りあり。正式導入時は各公式ライセンス・データ送信範囲を再確認。

実装パターン A / B / C

パターンA — CI失敗 → AI要約 → BTS追記

1. Jenkins / GHA / GitLab CI が失敗
2. Webhook → n8n / Lambda / 自前Bot
3. ログ末尾 · 失敗ステージ · commit · PR番号を取得（秘密情報マスク）
4. AIが要約: 原因候補 · 該当ステージ · 関連ファイル · 次に見る箇所 · 暫定対応案
5. Redmine APIで既存チケットへコメント追記
6. Slack/Teams通知
7. 人間が「対応」「保留」「誤検知」「別チケット化」を判断

パターンB — PR/MR → AIレビュー → 品質ゲート → 人間承認

1. Redmine番号つきブランチ/PR作成
2. CI: build / test / lint / SAST / coverage
3. AIがPR差分を一次レビュー（参考情報）
4. SonarQube / Qodana / Semgrep の Quality Gate で客観判定
5. AI指摘はPRコメント · 対応/見送り理由を記録
6. 人間レビュアーが最終判断
7. BTSに「対応経緯」「CI結果」「判断理由」を残す

パターンC — 品質ゲート中心（AI生成コード向け）

導入優先度 · セキュリティ · チェックリスト

セキュリティ境界

運用チェックリスト

定着フェーズ: dev_docs_guide 第4章 · 正本MD: references/ci_cd_ai_collaboration_guide.md

品質アンカー — AI協調CI/CDでの劣化防止

AI協調CI/CDでは、ADRを単なる設計判断の記録ではなく、後続のAI作業・レビュー・CIが参照する品質アンカーとして扱う。AIは全体として自然な成果物を生成できる一方、作業が長期化・多段化すると、過去に合意した局所的な設計意図や品質基準を失いやすい。重要な設計判断・例外条件・非対象範囲・責務分離・品質ゲートをADRに固定し、PR、CI、AIレビュー、handoffから継続的に参照する。

AIに長く・多段に作業させると、過去に合意した設計意図・例外条件・命名規則・責務分離・非対象範囲を見落とす可能性がある。本ガイドでは、判断構造を参照点（アンカー）としてADRへ記録し、PR・CI・AIレビュー・handoff から継続参照する運用をPoC仮説として扱う。

• 作業順序: チケット/REQ → 関連ADR読込 → スキル実行 → PR（ADR欄必須）→ CI → 人間判断
• カリキュラム: いきなり実装させず、品質定義・ADR・受入条件を先にアンカー化（チケットループ）
• 評価ループ: CI失敗・PR指摘・BTS記録を次のルール/スキル/ADR更新に還流

設計仮説の正本: dev_docs_guide/research/quality_anchor_ai_ops.md · ADRテンプレ: 第2章 2.0b