監視アラートをAIでトリアージする

---

はじめに

監視システムから届くアラートの数は、サーバー台数やサービス数に比例して増加します。1日に数十件から数百件のアラートが通知される環境では、重要なアラートが大量の通知に埋もれ、対応が遅れるリスクがあります。この状態は「アラート疲れ」と呼ばれ、インフラ運用の現場で広く認知されている課題です。

とくにオンコール対応では、深夜や休日に限られた情報で素早く優先度を判断しなければなりません。経験の浅いエンジニアにとっては、「このアラートは今すぐ対応が必要なのか、翌営業日でよいのか」の判断自体が負担になります。

この課題に対して、AIOps（AI for IT Operations）という考え方があります。高額な専用ツールの導入を前提とする場合もありますが、この記事では手元のAI（Claude等）で今日から始められるアラートトリアージの方法を扱います。

この記事で扱う3つのステップは以下の通りです。

1. 単一アラートの重要度分類 ― アラート1件に対して、緊急・警告・情報の3段階で分類する
2. 初期対処の方針提案 ― 「次に何をすべきか」をAIに提案させる
3. 複数アラート同時発生時の相関分析 ― 根本原因の推定と対応優先順位の判断

手動トリアージとAI活用の比較は以下の通りです。

項目	手動トリアージ	AI活用トリアージ
判断時間（1件あたり）	2〜5分	30秒〜1分
判断基準	経験と勘（属人的）	プロンプトで定義した基準（統一的）
複数アラートの相関分析	10〜30分	1〜3分
対応方針の提案	過去の記憶に依存	Few-shotで蓄積したパターンに基づく
判断の記録	手動で記録が必要	AIの出力がそのまま記録になる

※AIの判断時間はプロンプト送信からAI応答完了までの目安です。マスキング処理や人間の最終判断の時間は含みません。

この記事を読むと、以下の3つができるようになります。

1. 監視アラートに対してAIで重要度を分類するプロンプトを設計できる
2. アラートに対する初期対処の方針をAIに提案させ、初動を高速化できる
3. 複数アラート同時発生時に、根本原因の推定と優先順位付けをAIで補助できる

---

前提条件

この記事は、以下の前提知識を持つ方を対象としています。

• 記事①のプロンプト設計の基礎知識（4要素の理解）
• Linuxの基本的なシステム監視コマンド（top、df、systemctl、journalctl等）
• 監視ツール（Zabbix、Prometheus等）のアラート通知を受け取った経験があるとなおよい

検証環境

項目	内容
OS	AlmaLinux 10 minimal
AIモデル	Claude Sonnet 4.6（Anthropic公式Web UI）
アラートの入力形式	テキスト形式（メール通知・Slack通知・監視ツールのアラートメッセージをコピー＆ペースト）

記事中のプロンプト例はすべてClaude Sonnet 4.6で動作確認しています。ChatGPTなど他のモデルでも基本的な考え方は共通ですが、XMLタグによる構造化はClaude固有の強みであるため、他モデルでは効果が異なる場合があります。

---

アラートの重要度を分類するプロンプト設計

トリアージの分類基準

アラートトリアージでは、以下の3段階で重要度を分類します。

重要度	定義	対応目安	条件
緊急	サービス停止またはその直前の状態	即時対応（15分以内に着手）	サービス停止、データ損失リスク、セキュリティインシデント
警告	パフォーマンス低下またはリソース閾値超過	計画対応（数時間〜翌営業日）	CPU/メモリ/ディスクの閾値超過、応答時間の増加
情報	正常動作の通知または軽微な変動	経過観察（対応不要の場合あり）	定期バッチの正常終了、閾値以下のリソース変動

分類の判断軸は「業務影響度」と「拡大リスク」の2つです。以下のマトリクスで分類を決定します。

トリアージ判断マトリクス: 業務影響度 × 拡大リスク

	拡大リスク：高 （放置すると被害拡大）	拡大リスク：中 （一定時間は現状維持）	拡大リスク：低 （自然回復 or 影響なし）
業務影響度：高 （サービス停止・データ損失）	緊急 即時対応 例: DB接続不能＋データ破損リスク	緊急 即時対応 例: Webサーバー停止（冗長化あり）	警告 1時間以内に対応 例: 一時的なサービス再起動で復旧
業務影響度：中 （パフォーマンス低下・一部機能停止）	緊急 即時対応 例: ディスク使用率95%＋増加傾向	警告 計画対応 例: CPU高負荷（ピーク時間帯のみ）	情報 経過観察 例: メモリ使用率一時的に上昇
業務影響度：低 （運用上の通知・定期処理結果）	警告 計画対応 例: ログローテーション失敗	情報 経過観察 例: バッチ処理の実行時間が通常より長い	情報 対応不要 例: cronジョブ正常完了通知

• 業務影響度 ― ユーザーやサービスに現時点でどの程度影響があるか
• 拡大リスク ― 放置した場合に被害が拡大する可能性があるか

Before/After: 分類方法の比較

改善ポイント: 分類基準（業務影響度×拡大リスクのマトリクス）をプロンプトに組み込み、AIに統一的な基準で判断させます。判断根拠も合わせて出力させることで、人間が検証しやすくなります。

プロンプト設計

以下は、単一アラートの重要度を分類するためのプロンプトです。記事①の4要素（役割・状況・ログ・出力形式）をベースに設計しています。ログ解析ではログデータを渡しましたが、アラートトリアージではアラート情報を渡します。

<role>
あなたは監視アラートのトリアージを支援するアシスタントです。
Linux/Windows混在環境のインフラ運用を担当するチームに所属しています。
</role>

<triage_criteria>
以下の基準でアラートの重要度を分類してください。

【緊急】即時対応（15分以内に着手）
- サービス停止またはその直前の状態
- データ損失のリスクがある
- セキュリティインシデントの可能性がある
- 業務影響度が高く、放置すると被害が拡大する

【警告】計画対応（数時間〜翌営業日）
- リソース（CPU/メモリ/ディスク）の閾値超過
- パフォーマンスの低下（応答時間の増加等）
- 冗長構成の一部コンポーネント障害

【情報】経過観察
- 定期バッチの正常終了通知
- 閾値以下のリソース変動
- 計画メンテナンスに伴う一時的な通知
</triage_criteria>

<alert>
（ここにアラート情報を貼り付け）
</alert>

<output_format>
以下の形式で分類結果を出力してください:

1. 重要度: 【緊急/警告/情報】
2. 判断根拠: アラート情報のどの要素からその重要度と判断したか
3. 業務影響度: 高/中/低（判断理由を1文で）
4. 拡大リスク: 高/低（判断理由を1文で）
5. 推奨アクション: 次にとるべき行動（1〜3項目）

アラートに記載のない情報は推測しないでください。
判断に必要な情報が不足している場合は「判断に必要な追加情報」として列挙してください。
不明な点は「不明」と回答してください。
</output_format>

【実演】単一アラート分類の3パターン

3種類のアラートをプロンプトに入力し、分類結果を確認します。

パターンA: サービス停止アラート → 緊急

アラート入力:

<alert>
[PROBLEM] nginx service is down
Host: web-server-MASKED
Severity: Disaster
Time: 2026-03-13 03:14:22
Details: Process nginx is not running
Status: PROBLEM
</alert>

AIの期待出力例:

1. 重要度: 【緊急】

2. 判断根拠:

• Severity が「Disaster」に設定されている
• 「Process nginx is not running」により、Webサーバーのプロセスが停止している
• nginxはHTTPリクエストを処理するサービスであり、停止はサービスダウンを意味する

3. 業務影響度: 高 ― Webサービスがダウンし、ユーザーがアクセスできない状態と推定される

4. 拡大リスク: 高 ― 放置するとサービス停止時間が延長し、ユーザー影響が拡大する

5. 推奨アクション:

1. サーバーにSSHで接続し、systemctl status nginx でサービス状態を確認する
2. journalctl -xu nginx.service --no-pager でエラーログを確認する
3. 原因を特定し、systemctl start nginx でサービスを復旧する

パターンB: ディスク使用率85%アラート → 警告

アラート入力:

<alert>
[PROBLEM] Disk space usage is high
Host: db-server-MASKED
Severity: Warning
Time: 2026-03-13 10:30:00
Details: /dev/sda1: 85% used (17GB/20GB), threshold: 80%
Status: PROBLEM
</alert>

AIの期待出力例:

1. 重要度: 【警告】

2. 判断根拠:

• ディスク使用率85%は閾値（80%）を超過しているが、残容量3GBがあり即座にサービス停止には至らない
• Severity が「Warning」に設定されている

3. 業務影響度: 中 ― 現時点でサービスに影響はないが、容量が枯渇するとサービス停止につながる

4. 拡大リスク: 高 ― ログやデータの増加により、使用率が100%に達する可能性がある

5. 推奨アクション:

1. df -h でディスク使用状況の詳細を確認する
2. du -sh /var/log/* | sort -rh | head -10 で容量を消費しているファイルを特定する
3. ログローテーションの設定を確認し、不要なファイルの削除を計画する

パターンC: cron実行完了通知 → 情報

アラート入力:

<alert>
[OK] Scheduled backup job completed
Host: backup-server-MASKED
Severity: Information
Time: 2026-03-13 04:00:15
Details: Daily backup job finished successfully. Duration: 45min. Size: 12GB.
Status: OK
</alert>

AIの期待出力例:

1. 重要度: 【情報】

2. 判断根拠:

• Status が「OK」であり、正常終了している
• Severity が「Information」に設定されている
• バックアップジョブが正常に完了したことを報告する通知である

3. 業務影響度: 低 ― 正常動作の通知であり、業務に影響なし

4. 拡大リスク: 低 ― 正常終了のため、拡大リスクなし

5. 推奨アクション:

1. 対応不要。記録として保管する
2. 所要時間（45分）やサイズ（12GB）が通常と大きく異なる場合は、傾向を確認する

---

初期対処の方針をAIに提案させる

重要度の分類ができたら、次は「何をすべきか」の初期対処方針をAIに提案させます。アラートの分類だけではなく、確認コマンド・想定原因候補・エスカレーション判断までを出力させることで、初動のスピードが上がります。

初期対処提案プロンプト

<role>
あなたはLinuxサーバーの障害対応を支援するアシスタントです。
監視アラートから初期対処の方針を提案します。
</role>

<alert>
（ここにアラート情報を貼り付け）
</alert>

<output_format>
以下の形式で初期対処の方針を出力してください:

1. アラート概要（1〜2文で要約）
2. 確認コマンド（サーバーにログインして最初に実行すべきコマンドを3〜5個、実行順に列挙）
3. 想定原因候補（確信度: 高/中/低 を付記、最大3つ）
4. エスカレーション判断
   - 即時エスカレーションが必要か（はい/いいえ/条件付き）
   - エスカレーション条件（条件付きの場合）
5. 記事①のログ解析への接続（次に取得すべきログとその取得コマンド）

アラートに記載のない情報は推測しないでください。
不明な点は「不明」と回答してください。
</output_format>

記事①で扱ったログ解析プロンプトとの連携を意識しています。アラートを受信したら、このプロンプトで初期対処方針を確認し、次に記事①のログ解析プロンプトで原因を特定する、という流れです。

Few-shotプロンプトの活用

初期対処の提案精度を上げるには、Few-shot（少数例提示）が有効です。自チームの過去の対応パターンを「例」としてプロンプトに含めることで、AIが組織固有の対応ルールを反映した提案を返すようになります。

Few-shotの構造は以下の通りです。

<role>
あなたはLinuxサーバーの障害対応を支援するアシスタントです。
以下の過去事例を参考に、新しいアラートに対する初期対処方針を提案してください。
</role>

<past_examples>
【事例1】
アラート: CPU使用率95% / web-server-01
対応: top -bn1 でプロセスを確認 → PHPワーカーの暴走を特定 → 該当プロセスをkill → php-fpmを再起動
エスカレーション: なし（15分以内に復旧したため）

【事例2】
アラート: ディスク使用率95% / log-server-01
対応: du -sh /var/log/* で原因特定 → 古いログを圧縮・削除 → logrotateの設定を修正
エスカレーション: なし（データ損失リスクなし）

【事例3】
アラート: SSH接続不可 / production-db-01
対応: コンソールからログイン → firewalld設定確認 → ssh サービスが停止していた → systemctl start sshd
エスカレーション: あり（本番DB接続不可のため、DBAチームに即時連絡）
</past_examples>

<alert>
（ここに新しいアラート情報を貼り付け）
</alert>

<output_format>
以下の形式で初期対処の方針を出力してください:
1. アラート概要
2. 過去事例との類似性（該当する事例番号と類似点）
3. 確認コマンド（実行順に列挙）
4. 想定原因候補（確信度付き、最大3つ）
5. エスカレーション判断（過去事例の判断基準を踏まえて）

アラートに記載のない情報は推測しないでください。
不明な点は「不明」と回答してください。
</output_format>

過去事例の数は2〜3件で十分です。事例が多すぎるとプロンプトが長くなり、トークンを消費します。代表的なパターン（サービス停止・リソース枯渇・接続不可）を1件ずつ含めるのが実用的です。

【実演】CPU使用率95%アラートへの初期対処提案

アラート入力:

<alert>
[PROBLEM] CPU usage is critically high
Host: web-server-MASKED
Severity: High
Time: 2026-03-13 14:30:00
Details: CPU user time: 95.2%, CPU system time: 3.1%, CPU idle: 1.7%
Trigger: CPU usage > 90% for 5 minutes
Status: PROBLEM
</alert>

AIの期待出力例:

1. アラート概要
web-server-MASKEDでCPU使用率が95.2%に達し、5分以上継続しています。CPU idleが1.7%のため、ほぼすべてのCPUリソースが消費されている状態です。

2. 確認コマンド（実行順）

# 1. CPU使用率の高いプロセスを特定
top -bn1 | head -20

# 2. プロセスごとのCPU使用率を降順で表示
ps aux --sort=-%cpu | head -10

# 3. ロードアベレージの確認
uptime

# 4. 直近のシステムログを確認
journalctl --since "10 min ago" -p warning --no-pager

3. 想定原因候補

• 候補1（確信度: 中） ― 特定のプロセスがCPUを大量に消費している（アプリケーションの暴走、無限ループ等）。根拠: CPU user time が95.2%と高いため、ユーザー空間のプロセスが原因の可能性が高い
• 候補2（確信度: 中） ― 急激なアクセス増加によるWebサーバーの負荷上昇。根拠: ホスト名が「web-server」であり、HTTP負荷が原因の可能性がある
• 候補3（確信度: 低） ― マルウェアや不正プロセスによるCPU消費。根拠: アラート情報だけでは判断できないが、想定外のプロセスがないか確認する必要がある

4. エスカレーション判断

• 即時エスカレーション: 条件付き
• エスカレーション条件: 確認コマンドの結果、原因プロセスの特定・停止が15分以内にできない場合、またはサービスの応答が停止している場合

5. ログ解析への接続

# アプリケーションログの取得（記事①のログ解析プロンプトに渡す）
journalctl -u nginx.service --since "30 min ago" --no-pager
tail -100 /var/log/nginx/error.log

---

複数アラート同時発生時の相関分析

複数アラートの根本原因パターン

インフラ障害では、1つの根本原因が複数のアラートを連鎖的に誘発することがあります。

例：ディスク容量の枯渇

1. ディスク使用率100%のアラートが発生
2. PostgreSQLがログファイルへの書き込みに失敗し、FATALエラーのアラートが発生
3. PostgreSQLに依存するバッチ処理が失敗し、ジョブ異常終了のアラートが発生

この3件を個別に見ると、3つの別々の問題に見えます。しかし根本原因はディスク容量の枯渇1つであり、対応すべきは「ディスク領域の確保」です。個別対応では、PostgreSQLの再起動やバッチの再実行を先に行ってしまい、根本原因の解消が遅れることがあります。

シナリオ: 5分以内に3件のアラートが同時発生

#	アラート内容	単体での分類
1	ディスク使用率100% / db-server-01	緊急
2	PostgreSQL: FATAL: could not write to log file	緊急
3	バッチ処理失敗: 日次集計ジョブ異常終了	警告

複数アラート一括分析プロンプト

<role>
あなたは監視アラートの相関分析を支援するアシスタントです。
複数のアラートが同時に発生した場合に、根本原因の推定と対応優先順位の判断を行います。
</role>

<alerts>
以下のアラートが5分以内に発生しました。

【アラート1】
（1件目のアラート情報を貼り付け）

【アラート2】
（2件目のアラート情報を貼り付け）

【アラート3】
（3件目のアラート情報を貼り付け）
</alerts>

<output_format>
以下の形式で分析結果を出力してください:

1. 根本原因の推定（確信度: 高/中/低 を付記）
   - 推定の根拠（どのアラートのどの情報から推定したか）
2. アラート間の関連性
   - 各アラートが根本原因とどう関連するかを説明
   - 因果関係の方向（原因→結果）を明示
3. 対応優先順位（番号と理由）
4. 各アラートへの個別対応（根本原因の解消後に追加対応が必要か）
5. 確認すべきポイント（相関関係の検証方法）

アラートに記載のない情報は推測しないでください。
根本原因が1つに絞れない場合は、複数の可能性を併記してください。
不明な点は「不明」と回答してください。
</output_format>

【実演】3件同時発生シナリオ

以下の3件のアラートが5分以内に発生したケースを分析します。

アラート入力:

<alerts>
以下のアラートが5分以内に発生しました。

【アラート1】
[PROBLEM] Disk space usage is critical
Host: db-server-MASKED
Severity: Disaster
Time: 2026-03-13 02:00:05
Details: /dev/sda1: 100% used (20GB/20GB), threshold: 95%
Status: PROBLEM

【アラート2】
[PROBLEM] PostgreSQL fatal error
Host: db-server-MASKED
Severity: High
Time: 2026-03-13 02:00:30
Details: FATAL: could not write to log file "pg_log/postgresql-2026-03-13.log": No space left on device
Status: PROBLEM

【アラート3】
[PROBLEM] Batch job failed
Host: batch-server-MASKED
Severity: High
Time: 2026-03-13 02:03:15
Details: Daily aggregation job failed. Error: connection to db-server-MASKED:5432 refused
Status: PROBLEM
</alerts>

AIの期待出力例:

1. 根本原因の推定（確信度: 高）
db-server-MASKEDのディスク容量枯渇（/dev/sda1 が100%使用）が根本原因と推定されます。

推定の根拠:

• アラート1で /dev/sda1 が100%使用と報告されている（02:00:05）
• アラート2でPostgreSQLが「No space left on device」によりログ書き込みに失敗している（02:00:30）。アラート1の25秒後に発生しており、ディスク枯渇が直接の原因
• アラート3でバッチ処理がdb-server-MASKEDへの接続を拒否されている（02:03:15）。PostgreSQLがFATALエラーで停止または接続を受け付けなくなった結果と推定

2. アラート間の関連性

アラート1: ディスク容量枯渇（根本原因）
   ↓ （ディスクに書き込みできない）
アラート2: PostgreSQLのログ書き込み失敗 → サービス異常
   ↓ （DBが接続を受け付けない）
アラート3: バッチ処理のDB接続失敗 → ジョブ異常終了

3. 対応優先順位

1. アラート1（ディスク容量枯渇） ― 根本原因のため最優先。ディスク領域を確保しないと他の2件も解消されない
2. アラート2（PostgreSQL） ― ディスク領域確保後、PostgreSQLの状態を確認し、必要に応じて再起動
3. アラート3（バッチ処理） ― PostgreSQL復旧後、バッチジョブを再実行

4. 各アラートへの個別対応

• アラート1: du -sh /var/* | sort -rh | head -10 で容量消費元を特定し、journalctl --vacuum-size=500M や古いログの削除で領域を確保する
• アラート2: ディスク確保後に systemctl status postgresql で状態確認。停止していれば systemctl start postgresql
• アラート3: PostgreSQL復旧を確認後、手動でバッチジョブを再実行する。実行コマンドはアラート情報だけでは不明

5. 確認すべきポイント

• アラート1と2が同一ホスト（db-server-MASKED）で発生しているか → 同一ホストであり、因果関係は成立する
• アラート3のbatch-server-MASKEDからdb-server-MASKEDへの接続経路にネットワーク障害がないか → ネットワーク障害が原因の可能性も排除すべき
• ディスク枯渇の原因が一時的なもの（ログ肥大化）か恒常的なもの（容量不足）かを判断する

人間が確認すべきポイント

AIの相関分析結果を受け取ったあと、以下の4点を必ず確認してください。

1. AIが推定した相関関係が実際に成立するか ― アラートのタイムスタンプを確認し、因果関係の時系列が正しいか検証する
2. 見落としているアラートがないか ― AIに渡していない別のアラートが同時刻に発生していないか、監視ダッシュボードで確認する
3. 根本原因が本当に1つか ― AIは「1つのストーリー」にまとめる傾向がある。実際には複数の独立した問題が同時に発生している場合もある
4. 対応優先順位が自組織のルールに合っているか ― 特定の顧客システムは最優先、といった組織固有のルールはプロンプトに明示しない限り反映されない

---

トリアージワークフローの構築

アラート受信からAI活用までの6ステップ

アラートを受信してからAIを活用するまでの具体的なフローを整理します。

ステップ	作業内容	ポイント
1	アラート受信（メール / Slack / 監視ツール画面）	複数件の場合はすべて収集する
2	アラート文面をコピーし、機密情報をマスキング	記事①のマスキング方法を適用
3	AIにトリアージプロンプトを送信	1件なら分類プロンプト、複数なら相関分析プロンプトを使用
4	AIの分類結果と対処提案を確認	判断根拠が妥当か、確認コマンドが正しいかを検証
5	人間が最終判断し、対応を開始	AIの「緊急」判断でも、状況によっては「警告」に変更する場合がある
6	対応完了後、AIの判断が適切だったかを振り返る	不適切だった場合はFew-shotの事例を更新する

記事①（ログ解析）との連携フロー

フェーズ	対応記事	作業内容	AI活用箇所
1. トリアージ	本記事（③）	アラートを受信し、AIで重要度を分類する	重要度分類・初期対処提案
2. 判断分岐	本記事（③）	「緊急」→ログ解析へ進む / 「警告・情報」→計画対応or経過観察	―
3. ログ解析	記事①	ログを取得→マスキング→AIで原因特定	ログ解析プロンプト（4要素）
4. 対処実施	記事①	特定した原因に基づいて対処を実施	対処手順の提案

トリアージで「緊急」と判断したアラートについて、記事① ログ解析プロンプトの実践設計の手法で原因を特定する流れです。2つの記事のプロンプトを組み合わせることで、アラート受信から原因特定までをAIで一貫して補助できます。

テンプレートプロンプト（コピー＆ペースト用）

以下は、単一アラートのトリアージと初期対処提案を一度に行うテンプレートです。分類プロンプトと対処提案プロンプトを統合しています。

<role>
あなたは監視アラートのトリアージと初期対処を支援するアシスタントです。
</role>

<triage_criteria>
【緊急】即時対応（15分以内に着手）
- サービス停止またはその直前の状態
- データ損失のリスクがある
- セキュリティインシデントの可能性がある

【警告】計画対応（数時間〜翌営業日）
- リソース閾値超過（CPU/メモリ/ディスク）
- パフォーマンス低下
- 冗長構成の一部コンポーネント障害

【情報】経過観察
- 正常終了の通知
- 閾値以下のリソース変動
- 計画メンテナンスに伴う通知
</triage_criteria>

<alert>
【ここにアラート情報を貼り付け】
</alert>

<output_format>
以下の形式で出力してください:

■ トリアージ結果
1. 重要度: 【緊急/警告/情報】
2. 判断根拠:
3. 業務影響度: 高/中/低
4. 拡大リスク: 高/低

■ 初期対処方針
5. 確認コマンド（実行順に3〜5個）:
6. 想定原因候補（確信度付き、最大3つ）:
7. エスカレーション判断:
8. 次に取得すべきログ（記事①のログ解析に接続）:

アラートに記載のない情報は推測しないでください。
判断に必要な情報が不足している場合は「判断に必要な追加情報」として列挙してください。
不明な点は「不明」と回答してください。
</output_format>

テンプレートのカスタマイズ方法

このテンプレートを自チームの運用に合わせてカスタマイズする際の変更箇所は以下の3点です。

カスタマイズ箇所	変更内容	例
<triage_criteria>	自チームの分類基準に合わせて条件を追加・変更	「特定顧客のシステムは常に緊急扱い」等の組織固有ルールを追加
<role>	担当するシステムの構成情報を追加	「nginx + PostgreSQL + Redis構成のECサイトを運用」等
<output_format>	出力項目を追加・変更	「インシデント番号の採番」「Slack通知テンプレート」等を追加

---

注意点とベストプラクティス

AIトリアージの限界

AIによるアラートトリアージには以下の制約があります。これらを理解した上で活用してください。

制約	内容	対処方法
リアルタイムメトリクス不可	AIは渡されたテキスト情報のみで判断する。現在のCPU使用率やメモリ使用率をリアルタイムに参照できない	アラート情報に加えて、直近のメトリクスをテキストで貼り付ける
組織固有ルールの未反映	「この顧客のシステムは最優先」等の暗黙のルールは、プロンプトに明示しないと反映されない	<triage_criteria> に組織固有ルールを追記する
セキュリティアラートの取り扱い	不正アクセスの検知アラートなど、アラート文面自体に攻撃元IPや手口の情報が含まれる場合がある	セキュリティアラートはマスキングの範囲を広げ、情報の外部送信可否を事前に確認する
ネットワーク構成の不可知	AIはシステム間の依存関係やネットワークトポロジを知らない	相関分析時はシステム構成情報をプロンプトに追加する

ベストプラクティス

#	項目	内容
1	分類基準を文書化する	トリアージ基準をプロンプトに記述すると同時に、チームのドキュメントとしても管理する。プロンプトが「分類基準の正式な定義書」を兼ねる
2	Few-shotの事例を定期更新する	新しい障害パターンを対応するたびに、Few-shotの事例に追加する。月1回程度の頻度で見直しを行う
3	AIの判断精度を定期評価する	過去1か月のトリアージ結果を振り返り、AIの分類と実際の対応結果を照合する。不一致があればプロンプトの分類基準を修正する
4	テンプレートをすぐ取り出せる場所に保管する	オンコール時にプロンプトを組み立てる余裕はない。テンプレートをSlackのブックマーク、社内Wiki、またはテキストファイルに保管し、コピー＆ペーストで即座に使える状態にする

---

まとめ

この記事で扱った3つのステップを整理します。

ステップ	内容	使用プロンプト
ステップ1	単一アラートの重要度分類（緊急・警告・情報）	分類プロンプト
ステップ2	初期対処の方針提案（確認コマンド・原因候補・エスカレーション判断）	対処提案プロンプト
ステップ3	複数アラート同時発生時の相関分析と優先順位付け	一括分析プロンプト

アラートトリアージにAIを組み込む際の原則は2つです。

1. AIは「分類と提案」を担い、「最終判断と責任」は人間が担います。 AIの出力はトリアージの補助であり、対応の判断と結果に対する責任は担当エンジニアにあります。
2. Few-shotで自チームのパターンを蓄積するほど、提案の精度が上がります。 障害対応のたびにFew-shotの事例を1件追加し、プロンプトを継続的に改善する運用が効果的です。

次にやること

1. 自チームで過去1か月に受信したアラートから5件を選び、分類プロンプトで分類する。 AIの分類結果と実際の対応を比較し、分類基準の妥当性を評価する
2. 自チームの過去対応パターンから3件をFew-shotの事例としてテンプレートに追加する。 代表的なパターン（サービス停止・リソース枯渇・接続不可）を1件ずつ選ぶ
3. テンプレートプロンプトをSlackのブックマークまたは社内Wikiに保存し、オンコール時にすぐ使える状態にする

次の記事では、IaCテンプレート（Ansible、Terraform等）をAIと共同で作成する方法を扱います。

---

前の記事: ② 構成管理ドキュメントをAIで自動生成する
次の記事: ④ IaCテンプレートをAIと共同作成する