AWS Healthからの通知は、障害の連絡やEnd of Supportの告知など、見逃せないものが多くある一方、AWSをマルチアカウントで利用していると、通知数が膨大となってしまってトリアージに苦労するものでもあります。
チームで通知に取り組むことを考えると、Slackのようなオープンな場所で通知を受けつつ、なるべく通知の数は押さえて、運用の負荷は減らしたいところです。
AWS User Notificationsを使えば重複排除が出来るが、配信手段はメールのみ
2025年12月15日より、AWS Healthからのメールによる通知は、AWS User Notificationsの「AWSマネージド通知サブスクリプション」という機能へ移行されることになっています（see: AWS HealthのEメール配信がAWS User NotificationsのAWS管理通知に移行するのでまとめてみた | DevelopersIO）。
こちらの機能の利点としては、AWS Organizationの単位で通知の集約管理ができるようになることと、集約した通知の重複排除が可能になることです。以下は実際に弊社で受信した、重複排除後の通知メールの1つです。タイトルを見ると3つのアカウントに対する通知が「Aggregate（集約）」されたことがわかります。
このような重複排除は非常に便利ではありますが、「メール通知」でしか活用できないという制約があります。AWS User NotificationsではAmazon Q Developerを使ったチャット通知などのオプションもあるのですが、重複排除に対応しているのはメールのみです。
冒頭にも書いたように、弊社としてはSlackで通知を受けたいニーズがあります。もちろん、メールをSlackチャンネルで受信する機能も存在するのは認識していますが、タイトルや全文が折り畳まれた状態でSlack上に表示されるため視認性があまり良くはありません。弊社ではこれまでも様々なメールをSlackに流してはいたのですが、数が多い時期だと見逃される場合も時にありました。
パッと見てもなんのことやら
Zapierで要約してSlackへ通知してもらう
この問題の簡単な解決策として Zapier を使うことにしました。Zapierは、いわゆるノーコードで複数SaaSを連動させるワークフローを作成できるツールであり、あるSaaS上でのイベント発生をトリガーに、そのイベント情報を使って別のSaaS APIを実行する、といった使い方が一般的です。
今回は「New Inbound Email」という、Zapier上で発行した独自のメールアドレスでメールを受信したことをワークフローのトリガーとする機能を活用し、以下のようなフローを組みました。受信したメールを「AI by Zapier」を使って要約し、トリアージしやすい形でSlackへ通知しています。
従来のZapierですと、メールとして受信したタイトルや本文を、単にそのままSlackへ投げるか、せいぜい正規表現等による簡単なテキスト処理を行うぐらいが関の山だったのですが、昨今は「AI by Zapier」が登場したことで、柔軟に入出力の変換ができるようになりました。Premium限定の機能ではありますが、Zapierが用意しているAnthropic、Google、OpenAI等の少し古いAIモデルを使うこともできますし、自身でAPIキーを用意して好きな最新モデルを活用することもできます。
「AI by Zapier」ではプロンプトに対して1対1の出力を行わせるのではなく、複数のOutput fieldsに分けて出力させることが可能です。Slack通知の本文は mrkdwn という若干特殊なフォーマットで作成する必要がありますが、 mrkdwn 全文を直接AIに書かせるより、必要なパーツ単位でAIに出力させて、Slack通知の際にそれらを組み立てたほうが精度が高めやすいです。
具体的には以下のプロンプトを用意しています。
## やりたいこと
AWSからの通知メールを要約してSlackへ投稿し、メールを開かずともSlack上で通知内容がわかるようにしたい。Slack投稿に使う文章などを作成してもらいたい。
## 指示
* 後述するメールのタイトルや本文を参考として文章を作成する。
* 要約は日本語で3文まで、約物として半角ハイフンを使った箇条書きとする。各文は長くなってもよい。
* メールを開かずとも、要約だけを見れば何をするべきかわかるよう、簡潔かつ具体的に要約する。
* 例えば障害連絡やEOLの連絡の場合、影響しているリソース（リソースID、AWSアカウントID、リージョンなど）の記述があれば要約へ含めるのが望ましい。
* ユーザーへ推奨しているアクションがあれば、それも含める。
* 5W1Hを適切に盛り込む。特に時間の情報（いつから障害である、いつまでに行動が必要である）は重要。タイムゾーンも含めて記載する。
### headerについて
headerは、メール内容から判断し、以下のいずれかとしてください。「障害」はAWSが利用できなくなっている、不具合が起きている状況を指します。「End of Support」には、サポートライフサイクルの終了のほか、退役なども含めてください。
:alert: *AWSから障害の連絡メールが来ています*
:warning: *AWSからEnd of Supportのメールが来ています*
:money_with_wings: *AWSからコストに関するメールが来ています*
:information_source: *AWSからメールが来ています*
## 要約するメールのタイトル
{{subject}}
## 要約するメール本文
{{body_plain}}
Output fieldsは以下の通り、パーツごとに分割しています。各fieldには、どのような出力を行えばよいのか指示を書いておくことができます。
Slack通知の際、このようにパーツを組み合わせて通知本文を作成しています。
結果として、以下のような形式でSlack上へ通知されます。先述したSlackネイティブのメール受信機能を使うよりも、かなり視認性が高まりました。
今後の応用
これをさらに発展させれば、Zapier上でそのままGitHub Issueを作成させたり、関係性の低い通知は何もactionさせない、といった複雑な処理を行うことも可能だと考えています。End of Supportの通知は日を改めて複数回同じものが来ることも多かったりするので、何らか工夫をしなければ同じIssueが重複してしまいそうでまだ実現には至っていませんが、さらに負荷の低い通知運用は検討していきたいところです。
Discussion