通知再考 ~ 最高のアラート通知を今改めて考える ~ 髙石諒 / @r_takaishi 2026-05-15 クラウドネイティブ会議 

髙石 諒 / @r_takaishi ● ソフトウェアエンジニア ○ 株式会社フライル ● OSS開発 ○ https://github.com/takaishi/tfclean ○ apply済みのimport/moved/removed blockを一掃できます ● 過去登壇 ○ SRE Kaigi 2025 / どうやればインシデント対応能力を鍛えられ るのか？ 

株式会社フライル ● 膨大なフィードバックを分類・要約しプロダクト・サー ビスの改善へ繋げるSaaSの開発 ○ データウェアハウス・BI・データ加工ワークフロー 

スポンサーセッションもあるので見てください ● https://event.cloudnativedays.jp/cnk/talks/3048 ● まだ見ていなければ是非アーカイブ視聴を！ 

本題 

みなさん 

こんな経験はありますか 🖐 

アラートで夜中起こさ れた、と思ったらたま たまその一瞬だけ閾値 を越えただけで、起き る必要がなかった 

私はあります 🫠 

とにかく大量のアラー ト通知・エラー通知が 届いて疲れてしまった 

私はあります 🫠 

疲れたくないでござる 

今日はアラート通知を改 めて考える話をします 

アジェンダ 1. 通知の3タイプ と メソッドの歴史 2. 通知の難しさ — flyle の現場から 3. 通知を改善する スピーカーの経験をベースに調べた・考えたことを話し ます 

1. 通知の3タイプ と メソッドの歴史 

通知には3タイプありそう ● Event-based ○ 例外・スタックトレース・ログ。1 イベント単位 ○ コードの異常に気づきたい ● Metric-based ○ 時系列の数値が閾値超え。CPU / Memory / Error 率 ○ リソース・サービスの異常に気づきたい ● Symptom-based ○ ユーザーが体験する 症状 で発火。SLO バーンレート ○ ユーザーの困りごとに気づきたい 

メソッドの系譜 ● 〜2010 OK / WARNING / CRITICAL — 外形監視・死活・メトリクス ● 2012 USE Method（Brendan Gregg）— リソース指向 (Utilization / Saturation / Errors) ● 2016 Four Golden Signals（Google SRE Book）— Latency / Traffic / Errors / Saturation ● 2018 RED Method（Tom Wilkie）— サービス指向 (Rate / Errors / Duration) ● 2018 SLO バーンレート（SRE Workbook）— どう判定するか：時間軸を加 味した許容量の消費速度 ● 2022〜 Beyond SLO — Desai 2σ / Rethinking SLOs 

通知先も変遷がありそう ● Email / ポケベル / 任意のスクリプト ● オンコール SaaS（2009〜）— PagerDuty ○ Severity・ローテーション・エスカレーションを SaaS 化 ○ SMSや電話、スマホアプリのプッシュ通知 ● 業務チャット（2010s〜）— IRC → 中略 → Slack/Teams ○ Hubot (2011) で「ChatOps」が定着 ○ スマホアプリでプッシュ通知 ● AIOps / LLM トリアージ（2023〜）— 通知そのものではないが通知前 後で活用 → 通知は「届ける手段」だけでなく「誰がいつ受け取るか」の設計対象に 

積み重ねの歴史 ● 新しい手法は古い手法を完全には置き換えないと考える ● ただし役割は絞られる ○ 全てにCPU利用率80%のアラートを設定、というのは今はあまりや らないだろう ● 自分のシステムで何を使うかは文脈次第 → 各プラクティス・メソッドが何を目的とするかを理解する 

2. 通知の難しさ — flyle の現場から 

flyleの通知史 ● 2020 創業 — 素朴なエラー通知 (CloudWatch → Slack) ● 2023 SLO 導入を検討したが中止 ● 2024 Datadog導入、監視対象のメトリクス増加 ● 2024 コンポーネント毎の通知チャンネル整備 ● 2025 マルチプロダクト化、緊急度毎のチャンネル整備 ● 未来 AIOpsやオンコールSaaSの導入？ 

複雑になっていく構造 ● コンポーネントが増える → 通知先も増える ● 組織拡大 → 通知先の増加・分割 ● 新しいメソッドを採用 → 既存のしきい値モニタと並走 

SLO を導入しなかった理由 ● プロダクトと組織の流動性を考慮すると人間が判断する 方が当時はよかった ○ SLOベースで判断するコストが大きい ● メンテナンスの余裕がなかった ○ 組織規模 ○ 優先順位 ○ 結果として監視・通知が後回しになりがちだったので妥当だったと 思う 

本当に必要だったもの ● アプリエラー発生時の判断高速化 ○ 当時はアプリエラーの方が圧倒的に発生が多かった ● 全体のどこで、どんな問題が起きているのか把握したい ● スタックトレースをパッと見たい ● 通知先の分割 ○ コンポーネント毎にSlackチャンネルを準備 

アプリエラー通知、難しい ● 「正常」「異常」の境界が曖昧 ○ 例：404 Not Found は単発なら正常、特定 URL で頻発なら異常 ● コンテキスト依存性が高い ○ 同じ TimeoutError でも、情報取得 API なら軽い、決済 API なら重い ● 新種が常に現れる ○ リリースごとに新しい例外型 ● あまり把握していない領域からのエラーは調査自体が難し い 

どのメソッドを使うか ● USEメソッド？ ● REDメソッド？ ● SLO? 対象/組織規模/組織成熟度で使い分けるのがよさそう フライルでも今後SLOや別手法の導入はありえる 

3. 通知を改善する 

いい通知とは？ 

動ける通知がいい通知 ● 通知の周辺を育てる ○ Runbook/ダッシュボード/オブザーバビリティ ● 通知を受ける人がそれを活用できるか？ ○ 啓蒙、足並みを揃える ● 顧客が本当に必要だった物 ● 監視・通知も一つのプロダクトとして捉えられそう 

監視・通知を育てる 

監視・通知を育てる 

監視・通知を育てる ここに目が行きがちだが… 

監視・通知を育てる ここが重要 

学習・改善の駆動エンジン2つ 育てる運用 ● 起点：発火履歴 ● トリガー：定期 ● ノイズをキャッチ ポストモーテム改善ループ ● 起点：個別インシデント ● トリガー：インシデント 発生時 ● 検知漏れをキャッチ 

監視・通知は育てるもの 監視は一度設定して終わりではなく、運用しながらより適切な状 態に近づけていく — Mackerel ブログ 

銀の弾丸も金の弾丸も ない 

時間をかける ● 通知改善に特効薬はない ● むしろ一気にやりすぎるのは逆効果ではないか ○ 足並みを揃える ● 時間をかけて変化を加え続けることが大事そう 

まとめ ● 通知の3タイプ ○ Event-based/Metrics-based/Symptom-based ● メソッド採用時の考慮 ○ 対象/組織規模/成熟度 ● 3つの指針 ○ 動ける通知がいい通知/監視・通知を育てる/時間をかける 

We are hiring! ● フライルはSRE/SWE採用中！ ● https://recruit.flyle.io/ 

スポンサーセッションもあるので見てください ● https://event.cloudnativedays.jp/cnk/talks/3048 ● まだ見ていなければ是非アーカイブ視聴を！ 

Thank you ! おいしいビールの店を探しています ご存じの方はask the speakerコーナーで教えてください セッションについても話しましょう 

参考文献 (1/2) ● Rob Ewaschuk「My Philosophy on Alerting」(2013) ○ https://docs.google.com/document/d/199PqyG3UsyXlwieHaqbGiWVa8eMWi8zz An0YfcApr8Q/edit ● Google『Site Reliability Engineering / The Site Reliability Workbook』(2016 / 2018) ○ https://sre.google/ ● Brendan Gregg「The USE Method」(2012) ○ https://www.brendangregg.com/usemethod.html ● Tom Wilkie「The RED Method」(Grafana, 2018) ○ https://grafana.com/blog/2018/08/02/the-red-method-how-to-instrument-yo ur-services/ 

参考文献 (2/2) ● Narayan Desai「Principled Performance Analytics」(SREcon22 Americas) ○ https://www.usenix.org/conference/srecon22americas/presentation/desai ● Google SRE Prodcast「Rethinking SLOs」(S1E4, 2022) ○ https://sre.google/prodcast/transcripts/sre-prodcast-01-04/ ● iwamot「SLOベースの監視は廃れるのか」(SRE Magazine 12号, 2026) ○ https://sre-magazine.net/articles/12/iwamot/ ● jacopen「間違いだらけのポストモーテム」（CloudNative Days Winter 2024） ● https://speakerdeck.com/jacopen/jian-wei-itarakenohosutomotemu-hontoniyi-li-turehiyuhakouta ● Mackerel ブログ ○ https://mackerel.io/ja/blog/