AIによる障害予兆検知
予兆検知の勘所：何を“前兆”とみなすか
予兆検知は「将来の障害を当てるAI」ではなく、「障害の種が芽を出しかけた瞬間を、運用に使える形で捉える技術」です。鍵は“前兆の定義”と“可観測性データの粒度”にあります。CPU高騰やエラーレート増加は分かりやすい指標ですが、単発のスパイクは運用を疲弊させます。過去の障害直前5〜60分の時系列パターン、相関関係、季節性（曜日・時刻）を前兆として捉えると、誤検知を抑えつつ先手を打ちやすくなります。
監視データの粒度と窓
粒度は1分か30秒が現実的です。5分粒度だと変化を平均化しすぎて検知が遅延します。学習や推論で用いる「窓」は15〜45分が使いやすく、スライド幅は1〜5分。サービスのRTTやスパイク特性で調整します。複数メトリクス（CPU/メモリ/GC/キュー長/スロークエリ/ネットワーク再送/エラーログ頻度）を同一窓に揃え、欠損や異常値（NaN、∞、観測抜け）を埋める前処理が必須です。
ラベル設計（障害の定義）
「アラートが鳴った」を障害とみなすと循環参照になります。SLOに基づく顧客影響（例：5分間のp95レイテンシ2倍、エラーレート>1%が10分継続）を障害判定にし、そのT0の30分前などを「予兆期間」としてラベル化します。軽微イベントも含めると再現率は上がりますが、運用は重くなりがちです。まずは重大障害（SEV1/SEV2）から。
先行指標の例
- GC回数とヒープ使用率の同時増加＋レイテンシ分散の拡大
- DB接続待ち行列の微増とキャッシュヒット率の徐々な低下
- パケット再送率の上昇とSYN待ちの積み上がり
- ログ中のWARN比率増加と例外メッセージの多様化（ユニーク度）
実装ステップと現場の落とし穴
データパイプライン
- 収集：メトリクス、トレース、ログを同一タイムゾーンと共通ホストIDで取得
- 正規化：z-scoreや分位点でスケール合わせ。季節性は曜日×時間のダミーで吸収
- 特徴量：移動平均/分散、勾配、自己相関、相互相関、急峻度、ログのn-gram頻度
- ラベル結合：障害チケットとSLO違反のタイムレンジを突合し、予兆窓に1を付与
可視化とスライス（サービス、AZ、デプロイ版）で偏りを確認します。デプロイ後のデータは分布が変わるため、週次でドリフト検知を回します。
モデル選択と精度の考え方
- 異常検知（Isolation Forest、One-Class SVM）：ラベルが乏しい初期に有効。誤警報を減らすにはメトリクスをクラスタ別に分けるのがコツ
- 教師あり（ツリーモデルや軽量なRNN）：障害履歴が月10件以上あれば候補。推論はCPUで十分、学習のみGPUを検討
評価指標はPrecision/Recallだけでなく「平均リードタイム（通知から障害T0までの余裕）」と「1日あたり有効アラート数」を見ると運用に直結します。初期はPrecision 0.5以上、平均リードタイム15分以上を目安に、サービスごとにしきい値を調整します。
アラート運用とSLO整合
予兆アラートは本番アラートと別チャンネルに分け、抑止（snooze）とエスカレーション条件を分けます。推奨は段階化です。Level1はダッシュボード強調のみ、Level2で当番に通知、Level3で自動緩和（スケールアウト、キャッシュフラッシュ）を発火。変更管理と連携し、直近30分以内のデプロイやフラグ切替を特徴量に入れると精度が伸びます。
LLMは運用補助に有効です。ChatGPTやClaudeでアラートに関連する過去の障害記録から「まず試す診断手順」を自動生成、Geminiで長文ログの要約、Copilotでクエリやパーサの実装支援を行うと、対応の初動が速くなります。機密ログは要マスキング運用です。
身近な企業活用例：中堅ECの転び方と立て直し
夜間のAPIタイムアウトが月2回発生し、オンコールが疲弊。最初は「CPU>80%で通知」という単純しきい値に頼り、誤警報が多発しました。失敗の要因は、週末のキャンペーンや深夜バッチの季節性を無視していたことと、ログを活用していなかった点です。
改善では、1分粒度でCPU/GC/DB待ち/ネットワーク再送/エラーログ頻度を集約し、30分窓の勾配・分散・相互相関を特徴量化。初期はIsolation Forestで部門別にスコアリングし、誤検知の多いサービスを分割しました。障害履歴が溜まった3カ月後、ツリーモデルに切替え、閾値を「Precision 0.6、平均リードタイム18分」を満たすようサービスごとに最適化。アラートはLevel2以上のみ当番通知にし、Level1はダッシュボード強調に留めました。
運用面では、ChatGPTで過去インシデントの要約とRunbookの初稿を作り、CopilotでログパーサとPromQLクエリを実装、Geminiでログバースト時の要約を自動返信。結果、誤警報は月45件から18件に、重大障害の平均検知リードタイムは8分から19分へ、MTTDは40%短縮。夜間の当番工数は週6時間から2時間に減りました。コストは学習用に小型GPUをスポットで利用し月3万円、推論は既存の監視サーバCPUで十分でした。
導入判断のチェックリストと費用感
- データ：1分粒度のメトリクスとログを90日以上保管、障害履歴のタイムレンジが取れる
- 頻度：重大障害が月1件以上（教師あり）／ほぼ無いなら異常検知から開始
- 指標：Precision/リードタイム/1日あたり通知数をSLOと紐付けて設計
- 運用：予兆チャンネルを本番アラートと分離、段階化、自動緩和は限定的に
- 体制：モデルオーナーとオンコール責任者を分け、週次で誤検知レビュー
- セキュリティ：LLM活用時はPII/秘匿情報のマスキングと監査ログを必須化
費用は小規模（数十サービス）なら、学習用に一時的なGPUを使っても月数万円、推論はCPU常設で足ります。ログの取り込み量が最大コストになりやすく、特徴量は「効くもの10個」を厳選し、保持期間をクラス分けして抑制します。PoCは1サービスに限定し、「精度＞0.5」「リードタイム＞15分」「通知/日＜5件」の3条件をゲートに本番展開へ段階移行すると、現場負担を最小化できます。
サーバ監視運用事業では、24/7の監視にこの予兆検知を重ねることで、単なる“見張り”から“先回りの保全”へ質を高められます。アラートの静けさは仕事の成果であり、AIはその静けさを設計するための道具です。現場の目とSLOに沿った小さな成功を積み重ねることが、安定運用の最短距離になります。
