PagerDuty×CoworkでSLA監視とエスカレーションを自動化する

未解決のPagerDutyインシデントを一定間隔で見に行き、SLA超過が近いものだけ人に確認を求めてからエスカレーションする。この動きはCoworkのScheduled TasksとPagerDutyの読み取り専用ツールの組み合わせで作れます。実際に相手へ通知やエスカレーションを行う書き込み操作だけを承認制にしておけば、監視は自動で回りながら、実際の連絡は人の目を通した上で送られます。人手で毎時PagerDutyの画面を巡回する運用を、判断だけ人に残したまま巡回部分だけ自動化する構成です。

前提条件

CoworkのScheduled TasksはPro・Max・Team・Enterpriseの有料プランで使え、PagerDutyのConnectorが接続済みであることが前提です。Team・Enterpriseでは、管理者がCowork自体の利用可否を組織設定で切り替えられる点も先に確認しておきます。Scheduled Tasksが使えるのは接続済みのコネクタとプラグインだけなので、PagerDuty Connectorが未接続の状態ではこの監視タスク自体を組めません。先にConnectorを繋ぎ、テスト用の会話でPagerDutyのツールが呼び出せることを確かめてから、監視タスクの作成に進みます。

Scheduled Taskのプロンプトを設計する

まず「Scheduled」→「New task」→「Set up manually」で、頻度と実行内容を指定します。プロンプトには監視のロジックを手順として書きます。

1. list_incidentsで、ステータスがtriggeredまたはacknowledgedの未解決インシデントを取得する
2. 各インシデントの作成時刻から経過時間を計算し、priorityがP1のものは30分、P2は2時間を超えているものを抽出する
3. 抽出したインシデントのID・タイトル・経過時間・現在の担当チームをまとめる
4. 超過が近いものだけ、担当チームへの追加とインシデントノートへの追記を提案する(実行前に確認を求める)

具体的な閾値(P1は30分、P2は2時間など)を決める前に、list_escalation_policiesで組織に登録済みのエスカレーションポリシーを一覧し、対象サービスに紐づくget_escalation_policyの内容を確認しておきます。返却フィールドの詳細は公式ドキュメントに記載が無いため、まずはポリシーの存在と対象範囲を突き合わせる目的で使い、閾値の数値そのものはこの2つのツールからは得られません。インシデントの生データからは「何分で超過とみなすか」が決まらないため、プロンプトに閾値を明記しておかないとClaudeは判断の基準を持てません。

Scheduled Tasksの作成自体は「Claudeと会話しながら作る」方法でも進められます。「PagerDutyの未解決インシデントを1時間おきに見て、SLA超過が近いものだけ教えて」と話しかけると、Claudeが頻度や承認モードを選択式で確認しながらタスク定義を組み立て、最後に内容を提示してから「Schedule」の確定を求めます。プロンプトを自分で書き切る自信がないうちは、この対話形式のほうが抜け漏れに気づきやすくなります。

頻度は「時間単位」までしか組めない

Scheduled Tasksの実行頻度は、Claudeと会話しながら決める方法でも手動設定でも、時間単位・日単位・週単位・平日のみ・手動実行のいずれかから選びます。分単位の指定はありません。SLAの猶予が1時間を切るような対応では、この監視タスクだけで間に合わせるのは無理があります。時間単位のインシデント巡回はScheduled Tasksに任せ、分単位で緊急性の高いインシデントはPagerDuty自体の通知(電話・プッシュ通知)に任せる、という役割分担が現実的です。

承認が必要なツールだけをApproval Gateで絞る

Coworkの承認は、個人が選ぶモードとコネクタごとのツール権限の掛け合わせで決まります。この監視タスクでは、読み取り系のツール(list_incidentsやget_incidentなど)はPagerDuty Connector側の権限を「常に許可」にしておき、無人でも定期実行が止まらないようにします。一方、実際に対応者を追加したりノートを書き込んだりする書き込み系のツールは「要承認」に設定し、Scheduled Taskの承認モードもManualのままにしておきます。こうすると、監視自体は毎時走り続けながら、人への通知に相当する操作の直前で必ず立ち止まります。

Team・Enterpriseでは、この個人設定の上に組織設定がもう1層重なります。組織側で「メンバーが書き込み系ツールをタスクごとの承認なしに全許可できるか」がオフになっていれば、コネクタ側を「常に許可」にしていても承認ダイアログは省略されません。部門ごとの承認設計の考え方はCowork Approval Gatesを部門ごとに設計する考え方にまとめてあります。

実行結果を確認し、通知を承認する

Scheduled Tasksは独立したCoworkセッションとしてリモートで実行されるため、デスクトップアプリを閉じていても定期実行は止まりません。実行結果は左サイドバーの「Scheduled」から確認でき、書き込み系ツールの呼び出しが発生したタイミングで承認プロンプトが表示されます。誤検知が多くて承認プロンプトが頻発するようなら、閾値をプロンプト側で見直すか、Cowork承認プロンプトが多すぎて止まるときの対処法を参考に運用を調整します。

同じ「Scheduled」画面からは、過去の実行結果と次回実行予定の一覧に加えて、タスクの一時停止・再開・削除・即時実行ができます。障害対応の当番が変わるタイミングでいったん止めたい、逆に今すぐ最新状況を見たいといった場面では、次の定期実行を待たずに「Run a task on demand」でその場で走らせられます。

SLAという言葉の限界

ここまでの構成は、PagerDuty自体が持つ「SLA」という公式概念を監視しているわけではありません。PagerDutyのMCPツールが公開しているのはインシデントの作成時刻・優先度・状態といった生データまでで、SLA超過そのものを判定する専用フィールドはありません。「超過が近い」という判断は、プロンプトに書いた閾値とClaudeの計算に委ねられています。組織の実際のSLA基準がPagerDuty側の優先度定義と一致しているかは、list_prioritiesで確認してからプロンプトに反映しておくと、判定のずれを防げます。

list_incidentsはステータス・緊急度(urgency)・サービス・チーム・期間などで絞り込めますが、この緊急度は高い/低いの2段階だけで、優先度(priority、P1〜P5)とは別の軸です。プロンプトで「P1は30分」のように書くときは、緊急度ではなく優先度のフィールドを指しているとClaudeに伝わるよう、名称を混同しないように書きます。この2つを取り違えると、緊急度は高いが優先度は低いインシデントまで巻き込んで抽出してしまうことがあります。

よくあるつまずき

• チーム絞り込みが効かない: list_incidentsをチーム単位や自分の担当分だけに絞る操作は、アカウント単位のAPIキーでは動かず、ユーザー単位の認証が必要です。組織共有のAPIキーで動かしている場合、絞り込みだけ意図通りにならないことがあります
• ローカルファイルには紐づけられない: Scheduled Tasksは接続済みのコネクタとClaudeアカウントに保存されたファイルだけを対象にし、手元のPCのフォルダには紐づきません。PagerDutyの監視自体はConnector経由なので問題になりませんが、監視結果を手元のスプレッドシートへ書き出すような追加処理を組む場合は影響します
• 誤検知の閾値を固定しすぎない: インシデントの優先度体系は組織側で変わることがあります。プロンプトに書いた閾値を一度作って放置せず、エスカレーションポリシーの見直しに合わせてタスクの指示文も更新します
• 書き込み権限が読み取り専用のままだと承認プロンプトすら出ない: Connector側のツール権限が「ブロック」になっていると、承認を求める以前にツール呼び出し自体が失敗します。想定通り確認が来ないときは、まず権限設定を疑います

週次のSLA遵守状況をまとめる使い方

この監視タスクをそのまま拡張すると、日々のエスカレーション判断だけでなく振り返り資料も作れます。別のScheduled Taskを週次で走らせ、その週に超過が近いと判定されたインシデントの件数・平均経過時間・実際にエスカレーションまで至った件数を集計させれば、オンコール負荷の把握や優先度設定の見直し材料になります。定型レポートをScheduled Tasksで自動化する組み方はCowork Scheduled Tasksで定型レポートを自動化する実践パターンにまとめてあるので、監視タスクと合わせて読むと構成の幅が広がります。

インシデント作成やオンコール変更は別記事で

インシデントの作成・対応者の追加・根本原因ノートの追記や、オンコール担当の確認・週末のオーバーライド設定は、PagerDutyのConnectorとMCPサーバーが直接提供するツールで行います。Connectorの権限設計はClaude Connectorの権限設定でやりがちな失敗を参照してください。

まとめ

未解決インシデントの定期監視は、読み取り専用のPagerDutyツールを「常に許可」にしたCowork Scheduled Tasksだけで無人化できます。実際に人へ通知する書き込み操作だけをApproval Gateで止めておけば、監視は自動で回りながら実際の連絡は人の判断を経て送られる構成になります。SLA超過の判定はPagerDuty側の機能ではなくプロンプトに書いた閾値に依存する点と、時間単位の頻度でしか監視できない点は、導入前の設計段階で織り込んでおく前提です。