利用しているクラウドサービスのステータスページの RSS を集め、自社が使うサービスと地域に関係する障害だけを日本語で要約して社内に知らせる

処理の起点を決める

n8n の Schedule Trigger で、5分おきに動かします。 公式ページでは、Schedule Trigger は秒・分・時間・日・週・月の間隔か cron の式で動かせ、ワークフローを保存して公開しないと動かないとされています。AWS の RSS には ttl が5（分）と書かれていて、それより短い間隔で取りに行く理由はありません。

n8n 2.45.0 以降の分の間隔の動き方に注意します。 公式ページでは、既定の durable scheduler のもとで、秒と分の間隔は時計の区切りではなく、ワークフローを公開した時点から一定の間隔で動くとされています。「毎時0分・5分・10分」に揃えたいなら cron の式を使います。この構成では揃える必要が無いので、分の間隔のままにします。

夜間と休日も動かします。 障害は時間を選びません。夜間に起きた障害は、情報システムのチャンネルに投稿されるだけで、全社へのお知らせは翌朝に当番が判断します。

入力データを集める

質を決めるのは、使うサービスと地域の台帳です。 「AWS を使っている」では見分けられません。東京の EC2・RDS・S3、大阪の S3（控え）のように、サービスと地域の組で書き、それぞれで動いている自社の業務（ECサイト、受注の連携、商品画像）を添えます。要約に「自社で影響しうる業務」を書けるのは、この列があるからです。

地域の表記の対応表は、混ざったフィードの見分けに効きます。 提供元ごとに地域の書き方が違うので、同じ地域を指す書き方を一覧にして、AIへの指示に添えます。

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

RSS は、提供元ごとに RSS Read ノードで取ります。 公式ページでは、RSS Read ノードはインターネットに公開された RSS フィードを読むノードで、URL を指定します。

AWS は、サービスと地域ごとのフィードを使います。 確認した時点では、rss/ec2-ap-northeast-1.rss のように、サービスと地域の名前を並べたフィードがあり、題名は「Amazon Elastic Compute Cloud (Tokyo) Service Status」でした。台帳の組の数だけフィードを読めば、ほかの地域の障害は入ってきません。 AWS の項目のリンクはどれもステータスページのトップなので、障害の単位は guid から作ります。

Google Cloud は、1つの障害の更新ごとに項目が分かれます。 確認した時点のフィードでは、項目の id が「障害のID.更新のID」の形で、リンクは障害ごとに同じでした。リンクから障害のIDを取り、同じ障害の更新をまとめます。

GitHub と Slack のフィードは、障害ごとに1項目で、本文に更新が積み上がります。 確認した時点の GitHub のフィードでは、本文の中に更新ごとの時刻（協定世界時）と「Resolved」などの状態が並び、Slack のフィードでも本文の冒頭に現在の状態が書かれていました。この形では同じ guid のまま本文だけが変わりうるため、この2社は guid に加えて本文の長さや公開の日時が変わったかも見て、更新として扱います。

新しい項目の判定は、guid（Atom では id）が台帳に無いかで行います。 Data Table の「If Row Does Not Exist」で照らします。公式ページでは、Data Table は n8n の中に構造化されたデータを持ちワークフローをまたいで使え、「行が存在するか」「存在しないか」で入力を振り分ける操作があるとされています。

AIへ渡す前に整形する

1. 新しい項目だけを残す … guid／id が既知の項目に無いものだけを残します
2. 障害の単位のキーを作る … 提供元ごとの規則で、同じ障害の更新に同じキーを付けます
3. 時刻を日本時間に直す … 公開の日時を、提供元の書き方（米国太平洋時間・協定世界時）から日本時間に変換します。本文中の時刻も、「all times are US/Pacific」のような記載があれば変換した値を添えます
4. 本文を整える … HTML のタグを外し、定型の謝罪文や問い合わせ先の段落を外します
5. 関係の有無を規則で決められるものを決める … AWS のサービスと地域のフィードから来たものは、台帳で「関係あり」とします
6. 状態の語を取り出す … 題名の先頭の「RESOLVED」「Resolved」などを、復旧済みの印として持たせます

3番目を AI に任せないのが、この構成の決まりです。 米国太平洋時間は夏時間で協定世界時との差が変わります。変換は日付と時刻のライブラリで行い、要約にはその結果を渡します。 AIには「時刻を書き換えない」と指示します。

5番目で、AIに渡す量が大きく減ります。 AWS の分は見分けが要らないので、AIは要約だけを行います。 見分けが要るのは、Google Cloud のように全地域が1つのフィードに入っている分です。

AIに処理させる

Basic LLM Chain に、関係の見分けと日本語の要約をさせます。 公式ページでは、Basic LLM Chain はプロンプトを決め、出力の形を求めるときは Structured Output Parser などをつなぐとされています。

「自社への影響の候補」は、断定ではなく台帳から引いた候補です。 東京の RDS の障害なら、台帳でその組に書かれた業務（受注の連携）を挙げます。影響が出ているかどうかは書かせません。

指示内容を固定する

Basic LLM Chain のシステムメッセージに、次のように書きます。

あなたは情報システム部の当番として、クラウドサービスの公開の障害情報を読み、
社内向けに日本語で短く要約します。

【入力】
- 提供元、題名、本文（英語）、日本時間に変換済みの公開日時と本文中の時刻
- 判定が要るかどうか（needs_relevance: true / false）
- 使うサービスと地域の台帳（提供元、サービス、地域、動かしている自社の業務）
- 地域の表記の対応表

【やること】
1. needs_relevance が true のときだけ、本文に書かれたサービスと地域が
   台帳の組に当てはまるかを判断してください。
2. 要約を日本語で3文以内に書いてください。
   何が起きているか、影響するサービスと地域、状態の順に書いてください。
3. 台帳から、影響しうる自社の業務を挙げてください。

【厳守事項】
- 時刻は入力の日本時間の値をそのまま使ってください。換算し直さないでください。
- 本文に地域が書かれていないときは、地域を推測しないでください。
  relevance を "unsure" にしてください。
- 台帳に無いサービスや地域を、似ているからといって当てはめないでください。
- 自社のシステムに影響が「出ている」とは書かないでください。
  「影響しうる業務」として候補を挙げるだけにしてください。
- 復旧の見込みや回避策は、本文に書かれていなければ書かないでください。
- 地域とサービスを判断した本文の一文を、evidence に英語のまま写してください。

「地域が書かれていなければ推測しない」が最も大事な一文です。 書いておかないと、AIは障害の規模や過去の傾向から地域を補います。推測で「東京にも影響」と書かれた要約は、当番を不要な調査に走らせます。 決められないものは unsure として当番に回します。

「影響が出ているとは書かない」も効きます。 情報システムのチャンネルの投稿は、ほかの部署の人も見ます。「受注の連携に影響」と書けば、実際に止まっていなくても止まったものとして扱われます。

出力形式を固定する

Structured Output Parser で、次の形に決めます。

{
  "incident_key": "ec2-ap-northeast-1",
  "provider": "aws | gcp | azure | github | slack",
  "relevance": "relevant | not_relevant | unsure",
  "status": "investigating | identified | monitoring | resolved | unknown",
  "services": ["Amazon EC2"],
  "regions": ["ap-northeast-1"],
  "summary_ja": "",
  "possible_business": ["ECサイト"],
  "evidence": "",
  "published_jst": "2026-10-14 09:05"
}

1つ目の理由は、relevance で投稿するかを規則で決められることです。 relevant と unsure は情報システムのチャンネルに出し、not_relevant は記録だけにします。unsure には「地域が書かれていません」と添えます。

2つ目は、incident_key で同じ障害のメッセージを書き換えられることです。 既知の項目の台帳から、そのキーで前に投稿したメッセージを引き、更新のときは新しく投稿せずに書き換えます。

3つ目は、published_jst をワークフローが入れることです。 AIには空で返させ、変換済みの値をワークフローが上書きします。 時刻がAIの出力を通らない形にします。

情報システムのチャンネルには、次の形で投稿します。

システムへ連携する

Slack ノードには、メッセージの送信・更新・承認待ちの操作があります。 公式ページでは、Message の操作に Send・Update・Send and Wait for Response が並び、Send and Wait for Response は相手の返事を待ってから続け、承認する人は Slack の中で直接返事ができるとされています。最初の投稿で返ってくるメッセージの識別子を、障害の単位のキーとともに Data Table に残し、更新のときは Update で書き換えます。

全社へのお知らせは、当番の承認を経て出します。 情報システムのチャンネルへの投稿と同時に、当番に「全社に知らせる」「知らせない」を Send and Wait for Response で聞きます。承認されたものだけを、全社チャンネルに投稿します。 全社のお知らせの文は、要約をもとに当番が直せるよう、承認の前に下書きとして見せます。

人が確認する

情報システムのチャンネルまでは確認なしで流し、全社へは当番が判断します。

1. 自社の監視を見る … 情報システムのチャンネルに投稿が来たら、該当する業務の監視で異常が出ているかを確かめます
2. unsure を開く … 地域が書かれていないものは、提供元のページで確かめます
3. 全社に知らせるかを決める … 影響が出ている、または問い合わせが来始めているなら承認します
4. お知らせの文を直す … 要約の下書きを、社員向けの言い方に直します

3番目の基準を、先に決めておいてください。 「公開の障害情報が自社の地域に出た時点で知らせる」か「自社の監視で異常が出てから知らせる」かで、お知らせの数と早さが変わります。 最初は後者で始め、問い合わせの数を見て決めます。

目標は、1件ならして5分です。 ステータスページを探して英語を読む作業が、日本語の要約と自社の監視を見比べる作業に変わります。

例外に対処する

2行目を誤ると、毎回の実行が失敗に見えます。 Azure のフィードは、確認した時点で項目が1つも無い状態でした。空のフィードと取得の失敗を同じ扱いにすると、障害の無い日ほど警告が出ます。 取得の応答が返ったかどうかで分けます。

記録を残す

• 取得した項目の guid／id、提供元、公開の日時（元の書き方と日本時間）
• 障害の単位のキーと、投稿したメッセージの識別子
• AIの出力（関係の見分け、要約、根拠の一文）
• 当番の判断（全社に知らせた／知らせない）と時刻
• 提供元ごとの取得の失敗の回数

4つ目を残すのは、基準を見直すためです。 全社に知らせなかった障害で問い合わせが多かったなら、知らせる基準が厳しすぎます。