第4章：運用の5層モデル

この章で分かること

検知→証拠→分析→実行→学習の5層
各層の責任主体
障害対応フローとの対応
自社ツールのマッピング方法
監視とAIの障害ドメイン分離

たとえ話

火災対応: ①煙感知 → ②映像保存 → ③状況整理 → ④消火判断 → ⑤防火訓練改善。
AIは主に③の強化。①のセンサー置き換えではありません。

全体構成図 · ソース: ../diagrams/overall_architecture.mmd

%% 全体構成図: 既存監視 + AI分析 + 人間統制
flowchart TB
  subgraph Sources["監視・観測ソース"]
    APP["アプリケーション\nOpenTelemetry"]
    SRV["サーバー / ホスト"]
    NET["ネットワーク機器"]
    CI["CI/CD\nGitHub Actions等"]
    LLM["LLM利用ログ"]
  end

  subgraph Collect["収集チャネル"]
    OTEL["OTel / APM"]
    SNMP["SNMP Polling"]
    TRAP["SNMP Trap"]
    SYS["Syslog"]
    CW["クラウド監視"]
    CILOG["CIログ取込"]
  end

  subgraph Store["証拠保存基盤"]
    PROM["Prometheus / メトリクス"]
    LOKI["Loki等 / ログ"]
    TEMPO["トレース基盤"]
    INC["インシデント管理"]
    CHG["変更・デプロイ履歴"]
    RB["ランブック / 過去事例"]
  end

  subgraph Detect["検知・アラート基盤\n決定論的"]
    AL["閾値判定 / 死活 / SLO"]
    AM["通知制御\n重複排除・抑制"]
  end

  subgraph AI["AI分析層\nL0〜L2中心"]
    AICOL["証拠収集・相関"]
    AIANA["仮説・反証・次アクション"]
  end

  subgraph People["人間・承認"]
    OPS["運用担当"]
    DEV["開発担当"]
    APR["承認者"]
  end

  APP --> OTEL
  SRV --> SNMP
  SRV --> SYS
  NET --> TRAP
  NET --> SYS
  CI --> CILOG
  LLM --> PROM
  LLM --> LOKI

  OTEL --> PROM
  OTEL --> LOKI
  OTEL --> TEMPO
  SNMP --> PROM
  TRAP --> AL
  SYS --> LOKI
  CW --> AL
  CILOG --> LOKI

  PROM --> AL
  LOKI --> AL
  AL --> AM
  AM --> INC

  INC --> AICOL
  PROM --> AICOL
  LOKI --> AICOL
  TEMPO --> AICOL
  CHG --> AICOL
  RB --> AICOL
  AICOL --> AIANA

  AIANA --> OPS
  AIANA --> DEV
  OPS --> APR
  DEV --> APR
  APR -->|承認付き実行| Sources

図が見えないときのテキスト版

ソース→収集→検知/証拠→インシデント→AI分析→人間承認→実行改善

1. 五層の定義

検知 … SNMP/Syslog/Prom/APM/SLO/CI/SIEM等。監視基盤
証拠保存 … ログ・メトリクス・トレース・変更・AI実行履歴。ログ／監査
分析 … 相関・仮説・反証・次確認。AI＋運用
意思決定と実行 … ロールバック、顧客通知等。運用／開発＋承認
学習 … ポストモーテム、ルール・ランブック更新。責任者ほか

障害対応フロー · ソース: ../diagrams/incident_response_flow.mmd

%% 障害対応フロー
flowchart TD
  A["異常発生"] --> B["既存監視が検知\nSNMP / Syslog / Prom / APM / SLO / CI"]
  B --> C["アラートルール判定\n重複排除・抑制・ルーティング"]
  C --> D["インシデント起票"]
  D --> E["AIが証拠を収集\nログ・メトリクス・トレース・変更履歴"]
  E --> F["AIが状況を構造化\n事実 / 仮説 / 反証 / 不足情報"]
  F --> G["人間が判断\n影響・リスク・手順選択"]
  G --> H{"承認が必要か?"}
  H -->|いいえ・低リスク| I["承認済み/許可済み手順を実行"]
  H -->|はい・高リスク| J["承認者レビュー"]
  J --> I
  I --> K["復旧確認\n復旧ゴール照合"]
  K --> L["ポストモーテム"]
  L --> M["監視・ログ・手順・AI評価を改善"]

  style B fill:#1e3a5f,stroke:#7dd3fc,color:#fff
  style E fill:#134e4a,stroke:#5eead4,color:#fff
  style F fill:#134e4a,stroke:#5eead4,color:#fff
  style G fill:#7c2d12,stroke:#fdba74,color:#fff
  style J fill:#7c2d12,stroke:#fdba74,color:#fff

図が見えないときのテキスト版

異常→検知→判定→起票→AI→構造化→判断→承認実行→復旧→振り返り→改善

2. 自社マッピングのやり方

層	書く欄	例
1	製品名とルール置き場	Alertmanager, クラウドアラーム
2	保存先と保持期間	ログ基盤、トレーシング
3	AIツール名と権限	読取MCPのみ、等
4	承認者と実行手段	変更管理、runbook実行
5	振り返りの場	週次／インシデント後

設計のコツ: ①と③の障害ドメインを分ける。AI用クラウドが落ちても閾値アラームは鳴り続ける。

運用担当者付箋マッピングを主催する

PGAI分析に必要な証拠を実装ログに残す

SE証拠保存層の保持期間・検索キー・権限を設計する

PM④の承認者表を先に作る

経営層⑤に時間を投資しない運用は同じ障害を買い続ける

ふりかえり

自社部品を5層に貼れたか
①が無いのに③だけ導入しようとしていないか