PagerDuty Tech Hub-鳴らすけれど、人は動かない

PagerDuty Tech Hub 2026（2026年9月29日）での登壇資料です。
より詳しい内容はこちらのblogにも掲載しています!
https://iret.media/209555

私たち MSP 一次対応チームは、多数のお客様環境のアラートを PagerDuty に集め、24時間365日で一次対応しています。その中には、お客様のご要望で「鳴らして報告はするが、対応はしない」と決めたアラートがあります。社内ではこれを「静観」と呼んでいます。静観にあたるインシデントは月に約6,900件あり、これまでは人が1件ずつ手で閉じていました。

この資料では、静観の判定を Event Orchestration に、クローズを Incident Workflow に任せた仕組みを紹介します。誤って閉じないために決めた設計のポイントは、次の3つです。
・キー名と値の完全一致で判定する
・実データで試し、依頼した本人が承認してから登録する
・判定できないものは、人の手順に戻す

この仕組みで、年間約1,380時間（約8.6人月）の手作業がなくなる見込みです。

Transcript

1. PagerDuty Tech Hub 2026 2026.09.29 鳴らすけれど、 人は動かない 「対応しなくていいアラート」の扱いを、設計し直した話 江崎 真二 KDDIアイレット株式会社
2. SPEAKER 登壇者 江崎 真二 えざき しんじ KDDIアイレット株式会社 クラウドイノベーション本部 サービスプラットフォーム事業部 MSPセクション セクションリーダー CAREER｜経歴 監視運用セクションのリーダー。 チームのマネジメントおよび、運用関連サービスの企画・設計・導入・改善を担当。 お客様のシステムを24時間365日守る「現場の最前線」に従事。 鳴らすけれど、人は動かない 02 / 20
3. 所在地 事業内容 資本金 設立 従業員 株主 グループ会社概要 KDDIアジャイル開発センター株式会社 株式会社フライウィール 株式会社ELYZA 株式会社KDDIウェブコミュニケーションズ Scrum Inc. Japan株式会社 東京都港区虎ノ門１丁目１７番1号 虎ノ門ヒルズビジネスタワー29F AI インテグレーション・活用支援、 IT コンサルティング、システム開発、 運用保守、および AI 駆動開発の推進 7,000万円 2003年10月 1,698名(2026年4月時点) KDDI株式会社100％ アジャイル開発事業および保守事業 データおよび人工知能を活用した サービスソリューションの開発・提供 AIリサーチ＆ソリューション事業、 AI SaaS事業 クラウド・ホスティング事業、ウェブ サービス事業、プラットフォーム事業 Scrum Inc.認定資格セミナーの開催、 組織変革コンサルティング
4. KDDIアイレット発足 強固な通信基盤 クラウドインテグレーション 技術での国内トップクラスの実績
5. CONTEXT 前提 私たちの PagerDuty の使い方 多数のお客様環境のアラートを PagerDuty に集め、 MSPチームが 24時間365日で一次対応しています。 CUSTOMER ENVIRONMENTS AGGREGATE 運用・保守サービス cloudpack お客様・案件ごとに、 監視の構成が違います。 AWS Google Cloud Azure OCI ほか アラートを1か所に集める アラートの一次対応を担当します。 解決しなければ、 二次対応へ引き継ぎます。 PagerDuty お客様環境 約 10,000 台 アラート 同じ内容のアラートをまとめて インシデントとして起票し、 MSPチームへ通知します。 を運用・保守 MSPチーム 通知 24 時間 365 日 交代制で一次対応 NOTE cloudpack は、私たちが運用保守サービスを提供しているブランドです。 鳴らすけれど、人は動かない 05 / 20
6. PROBLEM 問いかけ 「鳴るけど、対応しなくていいもの」 今日も人が手で閉じていませんか。 WE CALL IT 静観 お客様のご要望で、鳴らして報告はするが、対応自体はしないと決めたアラートを、私たちは「静観」と呼んでいます。 静観にあたるインシデントは月に約6,900件あり、これまでは人が台帳と照らし合わせ、1件ずつ手で閉じていました。 鳴らすけれど、人は動かない 06 / 20
7. PROBLEM 止められない 止めてしまえばいい。 ただ、止められない。 お客様への報告は必要だからです。 お客様からのご要望 「鳴ったことは報告してほしい。ただ、対応はしなくていい」 鳴らさない設定にすると、このご要望に応えられません。理由は次のページの仕組みにあります。 鳴らすけれど、人は動かない 07 / 20
8. WHY 止められない理由 なぜ、止められないか アラート発報 監視ツール 監視 監視対象サービス ① アラート通知・解析 ⑤ アラートクローズ、 一次対応結果を出力 ④ エスカレーション 二次運用担当者 ② 動作確認、情報取得 ③ 復旧対応、復旧確認 一次対応依頼 お客様への報告は、PagerDuty のインシデントをトリガーに、AMS が自動で行っています。 止めてしまうと、報告ができません。 鳴らすけれど、人は動かない お客様 想定外のケースや、オペレーションを 引き継ぐケースは、一次運用担当者に 一次対応を移譲 一次運用担当者 AMS は、一次対応を自動で行う私たちの基盤です。 インシデントが起票されると、確認・報告・エスカレーションまでを 進めます。 ④ エスカレーションは、条件によってお客様か二次運用担当者に 分かれます。 08 / 20
9. APPROACH 方針 静観かどうかの判定を、PagerDuty に任せることにしました これまで MANUAL いま 本番稼働中（2026年10月時点） 人が、台帳と照合する Event Orchestration が判定する 人が、判断する Incident Workflows が自動で閉じる 人が、閉じる 人は、判定できなかったものだけを見る アラートが上がるたびに、1件ずつ。 静観について人が見るのは、例外だけになります。 アラートは止めずに鳴らし、インシデントは自動で閉じる。 鳴らすので、お客様への報告は止まりません。 鳴らすけれど、人は動かない 09 / 20
10. PRINCIPLE 大事なこと 静観にしてはいけないものを、 静観にして、閉じてしまう。 これだけは、1万回に1回でも起こせません。 お客様のシステムが止まっているのに、誰も気づかない状態になるからです。 この先の設計は、すべてこの1点を防ぐために決めています。 鳴らすけれど、人は動かない 10 / 20
11. DESIGN POINTS 設計 3つのポイント 「静観にしてはいけないものを閉じない」ために、設計で決めたことが3つあります。 自動化を考えるとき、どの現場でも悩むところです。 01 02 キーバリューのペアで、 完全一致で判定する 送信しても、 すぐには登録しない 防ぐこと 防ぐこと 似ているだけのインシデントには、 当てない。 文字が似ているだけの、別のインシデントを 閉じてしまう。 鳴らすけれど、人は動かない 試した結果を、依頼した本人が 承認してから。 意図しないものまで当たる条件が、確認なしで 有効になる。 03 迷ったら、人へ 人がやっていたことを、意図的に残す。 防ぐこと 判定できないものまで、自動で閉じてしまう。 11 / 20
12. DESIGN POINT 01 ポイント① キーバリューのペアで、完全一致で判定する 似ているだけのインシデントには、当てない 私たちの環境では、インシデントのタイトルは「キー名 : 値」の並びで標準化されています。 ここでいう完全一致は、「キー名 : 値」の組がそのままタイトルに含まれることを指します（PagerDuty の matches part）。 例 DB「db-0012」のアラートを静観にしたい場合 STRING ONLY INCIDENT 実際に上がってくるインシデント 静観にしたい DB の監視 RDS 接続エラー … target:db-0012 静観にしたくない EC2 の監視 ログ監視 エラー … target:i-0a91c3 「db-0012 に接続できません」 鳴らすけれど、人は動かない KEY : VALUE 文字列だけにした場合 キーバリューのペアにした場合 db-0012 target:db-0012 静観になる 意図どおり 静観になる EC2 の障害に気づけない 静観になる 意図どおり 当たらない 文字はあるが、target の値ではない 12 / 20
13. DESIGN POINT 02 ポイント② 送信しても、すぐには登録しない 必ず、依頼した本人の承認を通す リリース前、現場から多く上がったのは「本当にそれで当たるのか」という声でした。 送信すると、この確認が返ってきます。「この内容で登録」を押すまで、静観は有効になりません。 承認の画面で見るところ 登録内容を確認してください 1 PDサービス: sample-service (PXXXXXX) Backlogプロジェクト: PRJKEY AMS稼働案件: あり ／ 課題起票: 必要 入力した条件 書いた内容の読み合わせ 2 試した結果 3 作られる判定ルール 4 過去のインシデント（直近100件）に当てて、該当した一覧 PagerDuty に実際に登録される条件 登録する 押すまで有効にならない。意図しないものが 入っていないかを、本人が見る 1 条件 ・AMSシナリオ: check-log ・ターゲット: i-0623xxxx ・期間: 2026-09-18 22:00 〜 2026-09-25 06:00 2 直近100件のうち 3件 が静観対象になります ・[162947] AMS scenario:check-log target:i-0623xxxx ・[162950] AMS scenario:check-log target:i-0623xxxx ほか1件 3 生成ルール (event.summary matches part 'AMS scenario:check-log') and (event.summary matches part 'target:i-0623xxxx') and (now >= 2026-09-18 22:00 and now <= 2026-09-25 06:00) 4 ※ 画面はイメージです。値はダミーです。 鳴らすけれど、人は動かない Slack 入力に戻る キャンセル この内容で登録 13 / 20
14. DESIGN POINT 03 ポイント③ 迷ったら、人へ 判定できないものは、人へ いちばん怖いのは、静観にしてはいけないものを静観にしてしまうことです。 条件に一致したものだけを自動で閉じ、それ以外はこれまでどおり人の手順に落とします。 条件に一致 PAGERDUTY 自動で閉じる Incident Workflows が閉じる 目印を残す 仕組みが壊れたとき、人が気づけるように PagerDuty が判定 キー名と値の完全一致 一致しない／ 閉じられない 人へ これまでどおりの手順 人がやっていたことを、意図的に残す 自動化率100%は、あえて目指しません。 完璧な自動判定はできませんでした。間違えないことを優先したからです。 鳴らすけれど、人は動かない 14 / 20
15. ENTRY POINT 入口 入口は Slack ひとつ 守ってもらう、ではなく。通れば守られる形に 判定ルールも PagerDuty の画面も、誰も直接は触りません。依頼する人は、Slack のフォームに キー名と値と期間を入れて出すだけです。ポイント①②は、この入口の中に組み込んであります。 静観登録 Slack PDサービスID Backlogプロジェクトキー PXXXXXX 条件 1行に1つ。インシデントのタイトルの「キー名 : 値」に当てる AMSシナリオ ターゲット 条件は必ず、キー名と値の組で出てくる i-0623xxxx ほかに アラート種別・タグ名・任意のキー（キー名と値を自分で書く） 期間 2026-09-18 22:00 いろいろな人がいろいろな書き方で依頼すると、正しく設定されません。 書き方が揃う PRJKEY check-log 入口をひとつにすると、できること 〜 2026-09-25 06:00 期間を追加 理由・備考（任意） 定期メンテナンスのため ※ 画面はイメージです。項目は一部、値はダミーです。 鳴らすけれど、人は動かない キャンセル 確認へ 記録が残る 誰が・いつ・何を静観にしたか。 解除まで同じ場所に 必ず関門を通る 試して、本人が承認する手順を 飛ばせない おぼえることがない 依頼から解除まで Slack で完結。 部署が違っても同じ形 入口がひとつだから、全員が同じ道を通る。 15 / 20
16. OVERVIEW 全体像 Slack で投げると、この流れで動く 人と自動化の、共同作業 本番稼働中（2026年10月時点） 依頼する人が見るのは Slack だけです。判定と閉じる処理は PagerDuty が行います。 1 2 3 4 Slack で依頼 試して、承認 ルールを自動生成 PagerDuty が判定 項目ごとに値を入れる 過去の実データに当てた 結果を本人が見る ポイント② Event Orchestration に登録 キー名と値の完全一致 ポイント① 人が触るところ 自動で動くところ 5 自動で閉じる Incident Workflows が閉じる 一致しない 閉じられない 人が確認する関門（②）と、 人に戻る道（③）を、意図的に残しています。 鳴らすけれど、人は動かない 人へ これまでどおりの手順に落ちる。 自動で閉じたものにも目印を残す。 ポイント③ 16 / 20
17. UNDER THE HOOD 裏側 Slack で投げた後の動き 依頼1件ごとに、作って、消す Google Cloud で動くアプリが、PagerDuty の API でルールを足し引きします。人は画面から触りません。 登録するとき 1 Slack で条件を入れて、承認する Google Cloud Cloud Tasks BigQuery Cloud Scheduler タスク登録 6 監査ログ 3 結果を返信 7 Slack 2 タスク実行 1 登録・解除 番号は、右の手順の番号と対応しています 鳴らすけれど、人は動かない ・ 2 3 掃除 期限で削除 Cloud Run 5 台帳に記録 Google Sheets 4 4 ルール登録・削除 順番待ちの列に並べ、1件ずつ処理する 同時に書くと、片方の変更が消えるため Cloud Tasks PagerDuty にルールを登録する 〜7 台帳と記録に残し、Slack に結果を返す 5 PagerDuty Slack PagerDuty API Sheets・BigQuery 削除するとき 〜4 早く止めたい：Slack で解除すると、同じ流れで削除 1 掃除 期限が来たら：毎日の掃除で自動で削除 Slack Cloud Scheduler 17 / 20
18. IMPACT 効果 これで、どれだけ変わるか（見込み） 115 1,380 約 8.6 PagerDuty に上がるインシデント（約9割は AMS が自動で処理） 約18.5万 件 / 月 時間 / 月 そのうち、有人で対応しているインシデント 18,000 件 / 月 6,900 そのうち、対応しないと決まっていたもの（静観） 静観 6,900件 件 /月 この手作業が、人の手を通らなくなる見込みです。 有人対応 計18,000件 全部は自動にできません。それでも、この大きさです。 鳴らすけれど、人は動かない 時間 / 年 人月 / 年 6,900件 × 1件 約1分 115時間 × 12か月 1,380時間 ÷ 1人月 160時間 ※ 本番稼働中です。数字は、稼働前の件数から出した見込みです。 ※ 時間はシフト全体に散らばっている時間の合計で、1人減らせるという意味では ありません。 ※ 自分たちの環境でも 月の件数 × 1分 × 12 ÷ 60 で、年間の時間を出せます。 18 / 20
19. TAKEAWAYS まとめ 持ち帰っていただきたいこと 01 止めずに、鳴らして自動で閉じる 止められないアラートは、止めない。判定する役目と閉じる役目を分けて、PagerDuty に任せる。 02 「間違えて閉じない」設計を、先に決める（3つのポイント） 1 03 確実に判定できる方法を決める。 2 実データで試し、本人が承認するフローを 作る。 3 迷ったら人へ。誤判定ゼロを目指す。 入口をひとつに揃える 通れば守られる形にする。書き方が揃い、関門を必ず通り、記録が残る。 鳴らすけれど、人は動かない 19 / 20
20. ご清聴ありがとうございました 江崎 真二｜KDDIアイレット株式会社 PagerDuty Tech Hub 2026｜2026.09.29