はじめに

ベンジャミンのクワバラです。

弊社のインフラチームでは、お客様の AWS 環境を横断的に監視しています。今回から数回にわたって、その運用を生成 AI と自動化でどう改善してきたかを「AIOps の取り組み」としてシリーズでご紹介していきます。

第 1 弾は、Slack に流れてくるアラート通知の話です。複数の AWS アカウントを横断して監視・運用している方、アラート通知の運用改善を検討している方を想定しています。

結論から言うと、私たちは通知に対して次の 2 つを行いました。

1. アラートの内容を Amazon Bedrock で日本語に要約する
2. AWS アカウント ID から 案件名・お客様名・担当者を自動で引き当てる（名寄せ）

今回掘り下げるのは、後者の名寄せの仕組みです。

※なお、この記事で「名寄せ」と呼んでいるのは、12 桁のアカウント ID を案件名・お客様名・担当者に変換することです。

そのまま Slack に流していた頃

最初の構成はとてもシンプルでした。CloudWatch アラームを SNS に飛ばし、AWS Chatbot（現 Amazon Q Developer in chat applications）でそのまま Slack に通知するだけです。

構築は簡単ですし、これで「気づける」ようにはなりました。ただ、運用を続けるうちに、届いた通知を見た担当者が毎回同じところで止まることに気づきます。

たとえば CPU 使用率の高騰アラートが鳴ったとき、Slack に流れてくるのはこんな内容です。

ALARM: "xxxx-prod-web-CPUUtilization" in Asia Pacific (Tokyo)
Account: 123456789012
Threshold Crossed: 1 out of the last 1 datapoints [92.4] was greater than
or equal to the threshold (90.0).

英語で、しかも機械的です。これを見た人の頭の中には、だいたい次の 3 つが浮かびます。

分からないこと	実際にやっていたこと
どの AWS アカウントか（12 桁の数字しかない）	AWSアカウント台帳(スプレットシート)を開いて番号を検索する
誰に連絡すればいいか	案件の担当者を人づてに探す
どう対処すればいいか	英文を読み解いて調べる

アラートが鳴るたびに、この 3 つを人力で埋めていたわけです。通知は届いているのに、動き出すまでが遠い。これが当時の課題でした。

「どう対処すればいいか」は生成 AI で解決

このうち「どう対処すればいいか」は、Amazon Bedrock による要約で解決しました。アラートの原文を Claude（Anthropic 社の大規模言語モデル）に渡し、「何が起きたか / 考えられる影響 / 必要なアクション」の 3 点に日本語で整理させています。

これは想像しやすい使い方だと思います。実際、効果もすぐ出ました。

ただ、残りの 2 つは生成 AI では解決しません。「このアカウント ID はどの案件か」「担当者は誰か」は推論する情報ではなく、社内の事実を引いてくる情報だからです。ここで必要になったのが名寄せの仕組みでした。

名寄せの仕組み

やりたいことは一言で表せます。12 桁のアカウント ID を、案件名・お客様名・担当者に変換する。

全体像は次のとおりです。細部はこのあとの図で説明するので、ここでは 2 つの仕組み（名寄せ側／アラートを要約して届ける側）の関係だけつかんでいただければ大丈夫です。

通知側で 1 点だけ補足します。SNS から直接 Lambda を呼ばず、SQS でいったん受けてから Step Functions に渡しているのは、障害時にアラートが大量に押し寄せても取りこぼさないためです。処理が詰まってもキューに溜まるだけで、順に消化されます。

Step Functions 側は「正規化 → 名寄せ → AI 要約 → 配信」の 4 ステップに分けています。監視イベントは CloudWatch・GuardDuty・Health・コスト異常などサービスごとに構造がばらばらなので、最初の正規化で共通の形に整えてから後段に流す作りです。ステップを分けておくと、どこで落ちたかが実行履歴から一目で分かり、失敗したステップだけリトライできます。

案件情報はどこにあるか

幸い、社内には案件情報を持つ仕組みがすでにありました。社内で利用している工数管理システムです。
ここに案件名・お客様・担当部門・PM の情報が入っています。

問題は、これが監視基盤とは別のアカウントの Aurora にあることでした。監視基盤から本番 DB へ直接つなぐ経路を常設するのは、権限管理の面でも本番影響の面でも避けたいところです。

そこで、次のような流れでデータを持ってくることにしました。

Aurora（工数管理システム）
   ↓ 日次エクスポート（毎日 4:00）
S3 → Glue Data Catalog → Athena
   ↓ 平日朝 6:00 のバッチ
DynamoDB「AWS アカウント台帳」

Aurora から S3 への切り出しには Aurora のスナップショットエクスポートを使い、S3 上のデータは AWS Glue Data Catalog にテーブルとして登録して Amazon Athena から SQL で読んでいます。

本番 DB を直接触らず、分析用に切り出したデータを参照する構成です。本番 DB に負荷をかけずに済むうえ、Athena は S3 上のデータをスキャンした分だけの従量課金なので、分析基盤を低コストで維持できています。

台帳をつくる

こうしてできたのが、AWS アカウント台帳DBです。現在、かなりの数（ご想像におまかせします）のアカウントが登録されています。

1 件のレコードには、アカウント ID と紐づけて次のような情報が入っています。

• アカウント名・お客様名・案件名
• 案件コード、案件担当部門、案件ステータス（運用保守 / 開発中 など）
• 担当者、PM

これで「12 桁 → 案件」の変換ができるようになりました。「どの AWS アカウントか」はここで解決です。

最初の紐づけは、人がやる

「このアカウントはこの案件」という最初の紐づけは、人が管理画面（社内では Ops Portal と呼んでいます）から設定しています。 自動判定にはしていません。
アカウント名と案件名は必ずしも一致しませんし、1 つの案件に開発・検証・本番と複数のアカウントがぶら下がることもあります。逆に、案件に紐づかない社内共有のアカウントもあります。ここを機械に推測させると、間違った担当者に通知が飛ぶという一番やってはいけない結果につながります。

そこで、こう切り分けました。

	誰がやるか	頻度
アカウントと案件の紐づけ	人（管理画面から選ぶ）	アカウントごとに初回 1 回だけ
案件名・PM・担当者の追随	日次バッチ	平日毎朝、自動

バッチが見に行くのは「すでに紐づけ済みのアカウント」だけです。紐づいていないアカウントには何もしません。判断は人が 1 回、その後の変化の追随は機械が毎日、という分担です。

実際、案件の PM が交代したときは翌営業日の通知から自動で新しい担当者名に変わります。人が触るのは最初だけです。

管理画面には「未連携」で絞り込むフィルタも用意していて、新しいアカウントが増えたときに紐づけ漏れを見つけられるようにしています。

担当者は「チェーン」で決める

やっかいだったのが「誰に連絡すればいいか」でした。

最初は「案件の PM を担当者にすればいい」と考えていました。しかし実際のアカウントを見ていくと、そう単純ではありませんでした。請求代行だけのアカウント、社内利用のアカウント、親アカウント、PM が未設定の案件……。

そこで担当者は、アカウントの種類を上から順に判定していくチェーンで決める方式にしました。

順	どんなアカウントか	決まる担当
1	手動で担当者を指定したアカウント（例外）	指定された人
2	親・支払い用のアカウント	AWS グループ（当社の運用チーム宛）
3	請求代行だけのアカウント	AWS グループ
4	社内利用のアカウント	AWS グループ
5	お客様案件のアカウント	その案件の PM（複数いれば副担当も）
6	上記で判定できなかったアカウント	既定担当 → アプリ担当 → 要確認

判定していることは、突き詰めると「そのアカウントは特定のお客様案件のものか、そうでないか」の一点です。2〜4 は「そうでない」パターンを具体的に並べたもので、いずれも案件の担当者がいないのでチーム宛にしています。5 がその裏返しです。

1 番目を最優先に置いているのは、例外を先頭に逃がすためです。自動判定ではどうしても正しくならないアカウントが少数あり、そこに手で担当者を貼り付けておけば、下のルールを一切いじらずに個別対応できます。

※ 補足をいくつか。「AWS グループ」は当社の AWS 運用チームを指す社内の呼称です。「請求代行だけのアカウント」は、当社が請求を代行しているだけで構築・運用は担当していないものを指します。5 で PM が決まるのは工数管理システムに PM が登録されている場合で、案件には紐づいていても PM が未登録なら 6 に落ちます。6 の「既定担当 → アプリ担当 → 要確認」は、社内で定めた既定の宛先に順に落としていき、最後まで決まらなければ人の確認待ちにする、という意味です。

上から順に判定し、最初に当てはまったところで確定します。実際のデータでは 5 番の「PM から決まる」がいちばん多く、全体の 6 割ほどを占めています。

そして最終段の 6 番に落ちたアカウントは、いまのところ 0 件です。登録済みのアカウントはすべて 1〜5 番のどこかで担当が確定していて、「誰に振ればいいか分からない」状態のものは残っていません。最初にチェーンを設計したときは 6 番がもっと使われると思っていたので、これは想定より良い結果でした。

そして地味ですが効いているのが、「どの条件で決まったか」を一緒に記録している点です。運用中に「なぜこの人が担当になっているのか」と聞かれたとき、根拠をすぐ示せます。

正本と「公開用」を分ける

もう 1 つ工夫したのが、台帳を 2 段構えにしたことです。

台帳の正本には、クロスアカウントで使うロール情報など、見せたくない項目も含まれています。一方で、アラート通知や管理画面の閲覧者に必要なのは案件名や担当者だけです。

そこで、正本が更新されたら DynamoDB Streams をトリガーに、機微な項目を落とした「公開用の台帳」を自動生成するようにしました。通知の振り分けも、管理画面の閲覧権限ユーザーも、参照するのはこちらです。

権限で守るだけでなく、そもそも機微な項目が入っていないデータを見せる。この分離は入れておいてよかったと感じています。

この考え方は Slack 通知そのものにも効いています。通知にはお客様名・案件名・担当者名が載るので、通知先は必ずプライベートチャンネルにしています。そのうえで、通知処理が参照するのは公開用の台帳だけなので、仮にチャンネルの設定を誤ってもロール情報のような項目が流れることはありません。「どこに出すか」と「そもそも何を持たせるか」の二重で守る形です。

名寄せは「通知のたび」には計算しない

ここまでが台帳をつくる話です。では、実際にアラートが届いたときには何をしているのか。

答えは「台帳を 1 回引くだけ」です。担当者を決めるチェーンの判定は、平日朝のバッチが台帳を更新するときに済ませてあり、結果はレコードに保存してあります。通知処理は保存済みの値を読むだけで、その場でチェーンを再計算することはありません。

この作りにしたのには理由が 2 つあります。

• 速い。通知のたびに工数管理システム側のデータを引き直すと、その分だけ Slack に届くのが遅れます。アラート通知で数秒の遅れは無視できません
• 壊れにくい。名寄せ側（エクスポート・Athena・バッチ）が止まっても、台帳には前回の結果が残っているのでアラート通知は流れ続けます。担当者名が少し古くなるだけで済みます

代わりに、PM が交代した当日の通知には旧担当が載ります。ここは「通知が止まるリスク」と引き換えに受け入れた設計判断です。監視基盤にとっては、少し古い情報が載ることより、通知そのものが届かないことのほうが重大だと考えました。

なお、バッチが動くのは平日の朝だけです。金曜の朝以降に PM が交代した場合、土日のアラートには金曜時点の担当者が載り、実時間では 3 日近く古い情報になります。ただし私たちは休日の一次受けを行わず、営業日に対応する運用にしています。実際に人が動き出す月曜の朝には、その日のバッチがすでに走っているため、この古さが実務に影響することはありません。バッチの頻度は、データの鮮度そのものではなく「人がいつ見るか」に合わせて決めています。

導入してどう変わったか

いま Slack に届く通知には、日本語の要約に加えて アカウント名・案件名・担当者が入っています。

12 桁の数字を検索するところから始まっていた運用が、通知を見た時点で「誰が動くか」まで分かる状態になりました。人力で埋めていた 3 つの空欄が、そのまま埋まった形です。

まとめ

今回は、アラート通知の「分からない」を埋めるために構築した名寄せの仕組みをご紹介しました。ポイントを振り返ります。

技術的なポイント

• 生成 AI で解ける課題（対処方法）と、社内の事実を引くしかない課題（アカウント・担当者）を分けて考えた
• 案件情報は工数管理システムから分析基盤を経由して取り込み、AWS アカウント台帳に集約した
• 最初の紐づけは人が 1 回だけ、その後の変化への追随は日次バッチ、と役割を分けた
• 担当者は決め打ちではなく優先順位つきのチェーンで決め、判定根拠も残した
• 台帳は正本と公開用に分け、機微な項目を持たないデータを参照させた
• 名寄せは書き込み時に計算して保存し、通知処理は台帳を 1 回引くだけにした
• バッチの頻度は、データの鮮度ではなく「人がいつ見るか」に合わせて決めた

運用メリット

• 案件担当は変わることがあるため、案件 DB をマスタにして日次更新することにより、アラート通知すべき担当者を最新化する運用工数を削減できた
• アラートを確認するインフラ担当者が、このアラートを誰に連絡したら良いのか分からないという状態に陥らなくなった（エスカレの速度向上も見込める）

今回のネタは非常に地味な内容ですが、インフラチームはこのような日々の作業を地道に自動化しています。コーディングエージェントを利用することでアイデアを形にすることもやりやすくなったと感じています。

次回のブログでは、アラート調査をDevOps Agentで自動化した方法について紹介します。

---

※ 本記事の内容は執筆時点（2026 年 8 月）のものです。AWS の各サービスの仕様・名称は変更される場合があります。