主な読者: SEPM
経営層投資対効果とリスク低減の判断材料。全文読む必要はなく、KPIとBefore/Afterで十分。
PM合意・スコープ・未決の管理。正本が1か所なら炎上の早期検知と説明責任が楽になる。
この章 障害時の説明責任・ステークホルダー連絡
この章 障害時の説明責任・ステークホルダー連絡
SE構造・IF・例外の設計品質。MD+Mermaid+OpenAPIでレビューとAI支援の精度が上がる。
この章 Runbook 正本・ADR連携
この章 Runbook 正本・ADR連携
PG実装の迷いが減る。AGENTS.md・型生成・PRテンプレで「聞き直し」工数が減る。
この章 CHANGELOG・監視アラート対応
この章 CHANGELOG・監視アラート対応
Runbook MD：障害時の正本
# RUNBOOK-DB-01 接続プール枯渇 ## 症状 - API 503増加、DB wait_timeout ## 即時対応 1. スケールアウト（手順リンク） 2. 長時間クエリ特定（SQL-id: Q-442） ## エスカレーション - 15分未復旧 → インフラ責任者 ## 関連ADR - ADR-012 コネクション上限
Wikiに散らばった手順は検索に依存します。RunbookをGit管理し、障害ADRとリンクします。
障害対応後は Runbook 更新 → 必要なら ADR / CHANGELOG 追記 → TestDesignDoc の観点へ還流 を行い、週次の PM 運用（第7章）で open-items やゲート判定とあわせて「再発防止が正本に反映されたか」を確認します（観点還流の詳細は第5章）。
6.0b BTS連携 — CI/CD・AI・判断履歴
運用フェーズでは Runbook 正本に加え、Redmine/BTS に判断履歴を残すことが AI×CI 連携の最大価値。単なる自動化ではなく、後から追跡できる記録を残す。
BTSに残すべき必須項目
- なぜこの修正をしたか · どのチケット/仕様に基づくか
- AIが何を指摘したか · CI/CDが何を検出したか
- どの指摘を採用したか · 採用しなかった理由
- 品質ゲート結果 · 例外承認の有無 · 人間の最終判断者
## 対応完了メモ（Redmineコメント例） - 対象PR: #567 · commit: abc1234 - CI結果: 全件成功 · Quality Gate: 通過 - AIレビュー指摘: null handling確認 · テスト不足 - 見送った指摘: ログ追加提案（共通例外ハンドラで記録済み） - 最終判断: 人間レビュー承認済み
詳細事例・API連携: 第4章 CI/CD×AI · ai_quality 第7章
AI運用ログから正本へ改善を還流する
Human Gateで止めた理由を週次レビューし、改善先を正本・ADR・rules・FAQ・承認ルールへ戻す。 着想元は Qiita: AI運用ログを週次レビューし、FAQ・CRM・承認ルールへ戻すGAS実装。GASは必須ではなく、PoC初期は手動記録でよい。
Human Gate / AI利用 → 理由を4項目で記録 → 週次で分類・件数確認 → 改善候補を人間が選択 → Git正本 / ADR / rules / FAQ / 承認ルールへ反映 → 次週のログで効果確認
| 項目 | 用途 | 例 |
|---|---|---|
gate | どの確認点で止まったか | requirements / PR / release |
human_review_reason | 人間へ戻した理由の分類 | missing_context / low_confidence / approval_rule |
blocked_reason | 止まった事実を短く記録 | 対象外範囲が未確定 |
improvement_target | 改善候補 | REQ / FAQ / CRM / ADR / rule / template |
正本境界: ログと確定した改善はGit上のMarkdown/YAMLへ置く。スプレッドシートは一時集計に限り、顧客名・問い合わせ本文・機密情報を保存しない。
自動化条件: 最初の1〜2週間は手動。分類が安定してから集計だけを自動化する。改善チケットの自動起票や未入力による強制ブロックはPoC段階では行わない。
この工程で使う AI（運用）
| 役割 | ツール例 | 優れている点 | 典型用途 |
|---|---|---|---|
| Runbook 初稿 | Claude Code | ログ・手順の構造化 | runbooks/RUNBOOK-*.md |
| ログ分析 | Datadog AI · MCP | MTTR 短縮の傾向（監視ベンダー例） | 障害要約 → ADR / CHANGELOG へ |
| 再発防止 | 人間ゲート + LLM | AI 要約を正本へ反映してから close | 週次 PM チェック（第7章）と接続 |
| PMO AIPC 経由 | MCP Client → ノウハウ蓄積 Server（Hermes+Ollama） | Skill検索 · 指示整形 · lesson draft 蓄積 | ソース・本番鍵は開発PC（第6章） |
開発PC直置き Hermes は非推奨: ノウハウが個人PCに散在し blast radius も大きい。PMO AIPC = セキュアゾーン内 MCP Server を優先。
PMO AIPC — 社内ノウハウ蓄積地（Hermes + Ollama · MCP Server）
結論: Hermes は Cursor/Codex の代替ではなく、セキュアゾーンに置く記憶・整流レイヤーとして扱う。開発 PC 直置きの常時稼働 Hermes は blast radius が大きいため、個人検証に限定する。
| 推奨 | PMO AIPC = Hermes + Ollama を内包した MCP Server。Skill・手順・レビュー観点・失敗パターンを非機密の範囲で蓄積する。 |
|---|---|
| 非推奨 | 開発 PC に Hermes daemon を常駐させ、ソース・鍵・顧客情報へ広くアクセスさせる構成。 |
| 未決 | セキュアゾーンのネットワーク要件、MCP Server 実装方式、Ollama モデル標準。ADR 化待ち。 |
詳細な構成、メリット・デメリット、採用判定は 第10章 Hermes / PMO AIPC に集約。
参考: Hermes Agent · Ollama × Hermes
成果物サンプル一覧
Runbook
🔴 P1 — DB接続プール枯渇
1. スケールアウト（手順#S-12）
2. 長時間クエリ特定:
SQL-id Q-4423. 15分未復旧 → エスカレーション（オンコール担当）
関連: ADR-012 · 障害#INC-2026-014
障害記録（ADR連携）
1# 障害振り返り: 接続プール
2## 原因
3コネクション上限 50 が不足
4## 恒久対応
5→ ADR-012 改訂（上限100）
CHANGELOG
1## [1.4.0] - 2026-06-10
2### Added
3- REQ-042 受注キャンセル API
4### Fixed
5- 在庫戻しの冪等性（TC-118）
運用 — リスト変更の RACI（KEEL-LST 接続）
モデル · MCP · 端末コマンドのリスト変更は、誰が編集できるかを申請書に含める。台帳 ID は LLM GW ガイド第15章の KEEL-LST-001〜007 に準拠。
| イベント | 更新するリスト | 承認 | 証跡 |
|---|---|---|---|
| 新 MCP 利用 | LST-002 · LST-006 | Sec + PM | registry PR · 受講記録 |
| 破壊コマンド事故後 | LST-003 · LST-006 | Sec | インシデント票 · permissions.json diff |
| 新規開発者オンボ | LST-006（プロジェクト） | リポ maintainer | onboarding チェックリスト |
関連リンク
| リンク | 用途 |
|---|---|
| PM | 週次確認 |
| テスト | 観点還流 |
| スターター Runbook | 障害手順 |
