SaaS 企業の運用担当が、監視のアラートと外部サービスの障害通知を n8n で集め、前回の連絡からの変化を要約して、お客様向けの状況の連絡の下書きを作る

処理の起点を決める

起点は3つあります。 アラートの受け口、依存先の通知の受け口、15分ごとの定時です。

アラートは、Grafana のアラートの通知先（contact point）に Webhook を足して n8n に送ります。 Grafana は似たアラートをまとめて1回の通知にし、status（firing か resolved）と、アラートごとの labels・startsAt・endsAt・fingerprint などを送ってきます。n8n の Webhook ノードは、公開（publish）したときに本番の URL が有効になります。 テスト用の URL は、エディタで待ち受けている間しか動きません。

依存先の通知は、各社のステータスページの購読で受けます。 Atlassian の Statuspage で作られたステータスページは、運営者が Webhook の通知を有効にしていれば、購読の欄で Webhook を選んで受け口の URL を登録できます。障害の告知の作成と更新、機能（component）の状態の変化のときに送られてきます。 Webhook の購読が無い依存先は、RSS やメールの購読で代わりにします。

依存先の受け口は、すぐに応答を返す設定にします。 Statuspage は受け口に30秒以内に 2xx の応答を求め、3xx は失敗と見なします。Webhook ノードの応答のしかたを「Immediately」にして、記録の処理は応答の後に回します。

要約は15分ごとの Schedule Trigger で動かします。 社内の決まりの30分に対して、15分ごとに下書きを用意しておけば、責任者は手の空いたときに最新の下書きを承認できます。Schedule Trigger はワークフローの時間帯の設定を使い、無ければインスタンスの時間帯（自前で動かす場合の既定は America/New_York）を使います。 時刻を下書きに書くので、ワークフローの時間帯を Asia/Tokyo にしておきます。

入力データを集める

質を決めるのは、下の2つの対応表です。 アラートの名前のままでは、お客様に伝わる文になりません。対応表に無いアラートは、AIに機能を推させず「未対応のアラート」として下書きの外に出し、当番に知らせます。

依存先の対応表は、依存先の通知を自社の機能に結びつける表です。 決済代行の「Card payments」の障害は自社の「決済」に、メール配信の「Email sending」の遅れは「注文確認のメール」に当たる、と書いておきます。

データの取得方法を決める

受け口に届いたものは、すぐに Data table「events」に1件ずつ書き込みます。 n8n の Data table は、行の追加・取得・更新・追加か更新（upsert）・削除ができる表で、取得では条件で絞れます。

endsAt には注意が要ります。 解消していないアラートの endsAt には 0001-01-01T00:00:00Z という仮の値が入ります。これをそのまま時刻として扱うと、西暦1年に解消したことになります。 書き込むときに、この値なら空にします。

要約の段では、Data table「incidents」から前回の連絡の時刻を取り、「events」から received_at がそれより後の行を条件で絞って取り出します。 前回の連絡より前に始まり、いまも続いているアラートは、key ごとの最新の状態で拾います。

AIへ渡す前に整形する

1. 同じアラートをまとめる … Code ノードで、fingerprint が同じ行を1つにまとめ、最新の state を残します。Grafana では、同じラベルのアラートは同じ fingerprint を持ちます
2. 機能ごとに数える … 機能ごとに、続いているアラートの数、前回の連絡の後に新しく出た数、解消した数、最も早い開始の時刻を数えます
3. 依存先の通知を並べる … 前回の連絡の後に届いた依存先の通知を、時刻の順に並べ、本文を短く切ります
4. 時間の重なりを印にする … 依存先の通知の機能と、自社のアラートの機能が同じで、時刻が重なっていれば overlap: true の印を付けます
5. まとめて1件にする … Aggregate ノードで、機能ごとの行を1つの一覧にまとめ、AIに1回で渡します
6. アラートの通知が切り詰められていないかを見る … Grafana の通知先の「Max Alerts」で上限を設けていると、超えた分は落とされ、truncatedAlerts に数が入ります。0でなければ、数が実際より少ないことを下書きの注記に入れます

2番目と4番目は、AIに任せたくなるところです。 「何件続いているか」「時間が重なっているか」は数と時刻の比較で、プログラムなら毎回同じ答えを出します。 Code ノードは JavaScript か Python で書けます。なお、Code ノードの中ではファイルの読み書きや HTTP の呼び出しはできないので、Data table の読み書きはノードで行います。

4番目の印は「重なっている」だけです。 原因かどうかは、この段でも次の段でも決めません。

AIに処理させる

させるのは、前処理の結果を、機能ごとの変化として要約し、続報の下書きを作ることだけです。

変化の判断は、数の比較を言葉にするだけです。 前回の連絡の時点で「決済」のアラートが3件続いていて、いま5件なら worse、1件なら better です。その数は前処理で出してあり、AIはそれを見て選ぶだけです。 数が変わらず、新しい材料も無ければ same と書き、続報には「状況に大きな変化はありません。引き続き調査しています」と書かせます。無理に変化を作らせないことが、続報の信頼を保ちます。

4行目が気づきにくい失敗です。 「決済のアラートが10台のうち3台」を、生成AIは「約3割のお客様で決済に失敗」と書きます。サーバーの台数とお客様の割合は別のもので、そう書かれた続報は後で訂正することになります。

指示内容を固定する

あなたは SaaS 企業の障害対応で、お客様向けの続報の下書きを作る係です。
前回の連絡の後に届いた情報を、機能ごとの「変化」として要約します。
原因の判断はしません。

【材料】
- 前回の連絡の時刻と本文: {last_notice}
- 機能ごとの集計（前処理で数えたもの）: {feature_stats}
  各機能に、前回の時点で続いていた数、いま続いている数、新しく出た数、解消した数、
  最も早い開始の時刻があります。
- 依存先の通知（時刻の順）: {vendor_updates}
- 時間の重なりの印: {overlaps}
- 当番が書いた確定事項（あれば）: {confirmed_facts}

【やること】
1. 機能ごとに change を worse / same / better / recovered から選び、
   根拠にした数を evidence に書いてください。
2. 依存先の通知を、自社の機能の名前で vendor_note に短くまとめてください。
3. お客様向けの続報の下書きを draft に書いてください。
   - 前回の連絡から変わったことを先に書きます。
   - 変化が無ければ「状況に大きな変化はありません」と書きます。
   - 最後に「次回は {next_time} ごろにお知らせします」と書きます。

【厳守事項】
- 数は【材料】の集計をそのまま使い、数え直さないでください。
- 原因を書かないでください。依存先の障害と時刻が重なっていても、
  「〜が原因」「〜の影響で」と書かないでください。
- draft に依存先の会社名やサービス名を書かないでください。「外部のサービス」とします。
- アラートの数を、お客様の割合や人数に言い換えないでください。
- 復旧の見込みは、確定事項に書かれている場合だけ書いてください。
- アラートの名前やサーバー名を draft に書かないでください。機能の名前で書きます。
- 材料に無いことを書かないでください。

「変化が無ければ変化が無いと書く」を明記しないと、AIは何かしら進展を書こうとします。 「調査が進んでいます」「対応を進めています」のような、材料に無い進展です。お客様は次の続報でそれが何だったのかを期待します。

「〜の影響で」を禁じているのは、「原因」という言葉を避けても因果を書けるからです。 「決済代行の障害の影響で決済が遅れています」は、原因を断定した文です。時間の重なりは当番への注記に書き、お客様向けの文には入れません。

出力形式を固定する

Structured Output Parser で、次の形の JSON を受け取ります。

{
  "features": [
    {
      "feature": "決済",
      "change": "worse",
      "evidence": "続いているアラート 3→5、新規 2、解消 0",
      "overlap": true
    },
    {
      "feature": "注文確認のメール",
      "change": "recovered",
      "evidence": "続いているアラート 2→0、解消 2",
      "overlap": false
    }
  ],
  "vendor_note": "決済で使う外部サービスが 14:05 にカード決済の部分的な障害を告知",
  "draft": "【続報 14:30】決済の処理で、エラーとなる事象が引き続き発生しており、14:00 以降に発生の範囲が広がっています。注文確認のメールの遅れは解消しました。…次回は 15:00 ごろにお知らせします。",
  "notes_for_oncall": ["未対応のアラート: batch-export-lag（機能の対応表に無し）"]
}

1つ目の理由は、責任者が要約と下書きを分けて見られることです。 features の evidence を見れば、下書きの「広がっています」の根拠が数で分かります。下書きだけを見せると、責任者はその根拠を確かめに監視の画面を開くことになります。

2つ目は、notes_for_oncall を下書きと分けて置けることです。 時間の重なりや未対応のアラートは当番が知るべきことで、お客様に出すものではありません。

Structured Output Parser の形は、JSON の例から作るか、JSON Schema で書きます。例から作ると、すべての項目が必須になります。 JSON Schema の $ref（参照）は使えないので、入れ子の形は直接書きます。

システムへ連携する

受け口は守りを固めます。 Webhook ノードは、Basic 認証・ヘッダーの認証・JWT などで呼び出し元を確かめられ、IP の許可リストも設定できます。Grafana からの受け口は、Grafana の通知先の認証（Basic 認証か Authorization ヘッダー）と合わせます。 Grafana は送る内容に HMAC-SHA256 の署名を付けることもできます。Statuspage の送信元の IP は固定されておらず、決まった範囲もないとされているので、IP の許可リストでは絞れません。 受け口の URL を推測されにくいものにし、届いた内容のページの ID が登録した依存先のものかを確かめます。

Slack の Send and Wait for Response は、送った後に相手の返事を待ってから先へ進みます。 責任者は Slack の上で承認でき、承認を受けて「前回の連絡」の記録を更新します。ステータスページへの掲載は、この構成では行いません。 掲載はカスタマーサポートが行い、その時刻を Slack で返してもらって記録します。

人が確認する

下書きはすべて、対応の責任者が見て承認します。 確かめるのは3つです。

1. 変化の向き … worse・better が、当番の把握と合っているか。監視の数と、実際のお客様への影響がずれていることがあります
2. 書いてよいこと … 依存先のことを書くか、復旧の見込みを書くか。依存先の障害が明らかに原因と確かめられた場合だけ、責任者が書き足します
3. 言葉づかい … 社内の決まりの言い回しに合っているか

当番は、下書きの材料を足せます。 Slack から「確定事項」を書き込むと、Data table「incidents」に残り、次の要約の材料に入ります。「原因は決済の処理の設定の誤りと特定」のような確定した事実だけを書きます。 推測は書きません。

例外に対処する

5行目と6行目の「集計だけを送る」が大事です。 AIが動かなくても、機能ごとの数と依存先の通知が並んでいれば、当番は第3章の1番目と2番目を省いて続報を書けます。 AIの段を、この構成の止まる場所にしません。

記録を残す

• Data table「events」の全行（アラートと依存先の通知、受けた時刻）
• 15分ごとの前処理の集計と、AIの出力の全文
• 責任者が直した下書きと、直す前の下書き
• 掲載した続報の本文と時刻
• 障害ごとの、連絡の間隔（前回の連絡から次の連絡まで）
• 未対応のアラートが出た回数

3つ目の「直す前と直した後」は、指示を直す材料です。 責任者が毎回「〜の影響で」を消しているなら、禁止が効いていません。5つ目の続報の間隔は、障害の後の振り返りの材料になります。