ClaudeとPagerDutyを連携してインシデント対応を自動化する

Claude PagerDuty連携でできること

Claudeの会話からPagerDutyのインシデント対応・オンコール変更・チーム管理を直接実行できます。PagerDuty Connectorとは、ClaudeからPagerDutyのインシデント・オンコールスケジュール・チームをやり取りするMCPベースの接続機能です。画面を切り替えず、インシデントの作成から根本原因ノートの追記まで会話の中で完結します。

コネクターのディレクトリ上では、PagerDutyが提供する「Anthropic verified」の開発者ツールとして2026年3月に追加されました。接続先はhttps://mcp.pagerduty.com/mcpで、サインインが必須です。

書き込み系の22個はPagerDuty側のデータを実際に変更します。どの対象にどんな書き込みがあるかは、末尾の表で対象別に並べています。事後の振り返りはincident.ioコネクタの記事にまとめています。

接続前に確認すること

接続にはPagerDutyアカウントと、ユーザーAPIトークンまたはOAuthクライアントのどちらかが必要です。アカウントにはAdvanced Permissionsが有効であることも条件です。Claude側のクライアントはリモート(HTTPベース)のMCPサーバーに対応している必要があります。

APIキーは2種類あり、権限の範囲と発行場所が違います。

OAuthを使う場合は、PagerDuty側でOAuthクライアントを作成しておきます。クライアントの認証情報を渡す方法のほか、App OAuth TokenのようなトークンをAuthorization: Bearerヘッダーで直接渡す方法もあります。PagerDutyのホスト型サーバーはOAuthとAPIキーの両方に対応しており、チームや企業環境への展開もしやすい作りです。

claude.aiやClaude Desktopから使う場合は、PagerDuty Connectorのページで「Add to Claude」を押すと接続が始まります。Claude CodeではCLIから直接MCPサーバーを追加します。APIキーで接続するコマンドは次のとおりです。

PAGERDUTY_API_KEY=YOUR_API_KEY claude mcp add-json pagerduty \
  '{"type":"http","url":"https://mcp.pagerduty.com/mcp","headers":{"Authorization":"Token token=${PAGERDUTY_API_KEY}"}}'

OAuthクライアントで接続する場合は、リダイレクトURLに固定ポート(例としてhttp://localhost:8080/callback)を使い、そのポートをJSON設定のoauthオブジェクトのcallbackPortに指定します。--client-secretはシークレットをマスク入力で尋ねるフラグで、環境変数MCP_CLIENT_SECRETにシークレットを入れておくと、対話入力を省いて渡せます。

MCP_CLIENT_SECRET=YOUR_CLIENT_SECRET claude mcp add-json pagerduty \
  '{"type":"http","url":"https://mcp.pagerduty.com/mcp","oauth":{"clientId":"YOUR_CLIENT_ID","callbackPort":8080}}' \
  --client-secret

EUリージョンのアカウントは接続先が異なります。mcp.pagerduty.com/mcpではなくmcp.eu.pagerduty.com/mcpを指定します。Connector全般の追加手順や他サービスとの違いはClaude Connectorsとはにまとめてあります。Better Stackで監視する構成はClaudeとBetter Stackの連携を参照してください。

接続を確認するには、まず読み取りだけで済む質問を投げてみます。「今開いている高緊急度のインシデントを教えて」のように尋ねて一覧が返ってくれば、認証とツール呼び出しの両方が機能している証拠になります。読み取りで動作を確かめてから書き込みを試す順番が安全です。

会話でインシデントを作成し対応を進める

会話でのインシデント対応は、Connectorの中心になる操作です。「payments serviceに高緊急度のインシデントを作成して」と話しかければ、サービス名と緊急度を指定したインシデントがその場で作成されます。ノートの追記と担当者の追加をあわせて頼めば、フェイルオーバー対応のような一連の作業を1回のやり取りで進められます。

典型的な対応は、次の5段階で進みます。

過去のインシデントを調べる読み取りツールも用意されています。get_past_incidentsは過去のインシデント、get_related_incidentsは関連インシデント、get_outlier_incidentは外れ値のインシデントを返します。障害が再発かどうかを判断したいときの起点になります。

重複を避けたいときは、「databaseサービスで直近1時間に発生したインシデントを一覧して」と聞いてから作成に進めます。

オンコール担当を会話から一時的に交代させる

「週末のオンコールを交代したい」という単発の依頼は、専用アプリを使わなくても会話だけで完結します。「スケジュールPXXXXXXで、2026-09-20T09:00:00Zから17:00:00ZまでユーザーPYYYYYYをオンコールにして」と伝えれば、その時間帯だけカバーする一時的な上書き(override)が作成されます。裏側のツールはcreate_schedule_overrideです。

現在の担当者を確認したいときは「今誰がオンコールか教えて」と聞くだけです。list_oncallsが全スケジュール・全エスカレーションポリシーを横断した一覧を返します。シフトの引き継ぎ用の文章を作らせる使い方もあります。

スケジュール自体を作るcreate_scheduleと、更新するupdate_scheduleもあります。層や繰り返しを画面で見ながら組みたい場合は、専用の管理アプリが向いています。設定画面から操作したい人向けの使い方はPagerDutyのオンコールスケジュールをClaudeで管理するにまとめました。

チームとエスカレーション経路を管理する

チームの追加・メンバーの入れ替え・エスカレーションポリシーの確認も同じ会話の流れで扱えます。「platformチームにユーザーPXXXXXXをresponderとして追加して」と伝えると、指定した役割でメンバーが追加されます。

チームに関する書き込みは5種類あります。名前や説明の更新から、チーム自体の削除、離任したメンバーの除外まで、いずれもPagerDuty側のデータを変更します。

エスカレーションポリシーのツールはlist_escalation_policiesとget_escalation_policyだけで、一覧と取得に限られます。対応の最中に「正しい経路はどれか」を確かめる用途です。層の追加や通知ルールの変更を行うツールはないので、ポリシー自体を直すときはPagerDutyの管理画面を使います。

対応の記録を根本原因ノートとして残す

インシデント対応の最中にとった行動は、ノートとして残しておくと後から振り返りやすくなります。「インシデントP123456に、データベースのフェイルオーバーを開始した、というノートを追加して」と伝えれば、そのままインシデントのタイムラインに記録されます。

根本原因分析の下書きも、記録済みのノートを土台に組み立てられます。対応完了後に「このインシデントのノートをすべて時系列でまとめて」と頼むと、list_incident_notesで取得したノートをもとに、対応の流れを追った要約が得られます。

要約を残す先は、PagerDutyのノート(add_note_to_incident)か社内のドキュメントツールのどちらかです。ポストインシデントレビュー専用の保存ツールは、ツール一覧にありません。

ステータスページ向けには、投稿を作るcreate_status_page_postと、投稿へ更新を足すcreate_status_page_post_updateがあります。取得側にはlist_status_pages・list_status_page_statuses・list_status_page_severities・list_status_page_impactsが並びます。インシデントのタイムラインに書くノートと、ステータスページへの投稿は別のツールです。

接続がうまくいかないときの確認点

接続が急に切れた、あるいはツールの呼び出しが失敗するときは、まず認証の有効期限を疑います。APIトークンやOAuthの認可が失効していないかを確認し、失効していれば再発行します。

次に確認するのは、使っているMCPクライアントがリモート(HTTPベース)のMCP接続に対応しているかどうかです。クライアントがリモート(HTTPベース)のMCP接続に対応していないと、https://mcp.pagerduty.com/mcpに接続できません。両方を確認しても解決しない場合は、PagerDuty Developer Portalで最新のエンドポイントURLと要件を調べます。

権限の面では、ユーザートークンが「自分の権限の範囲」に縛られる点が効きます。参照できても変更できない操作があれば、PagerDuty側の権限が理由で403 Forbiddenになっている可能性があります。

OAuthで接続する場合は、クライアントを事前に登録しておく必要がある点にも注意します。PagerDutyはDynamic Client Registration(接続時の自動登録)に対応していません。初回接続でエラーになったら、OAuthクライアントを手動で作成済みかをまず疑います。

書き込み権限を渡す前に見ておくこと

22個の書き込みツールを対象別に並べると、影響の大きさが見えてきます。

削除系のツールはチームとアラートグルーピングの設定に限られ、インシデントやサービスやスケジュールを消すツールは並んでいません。一方で、ステータスページへの投稿やイベントオーケストレーションのルール追加は、通知やアラート振り分けの経路に関わります。対象の絞り込みを誤ると影響範囲が広がるので、実行内容を確かめてから承認する運用が現実的です。

書き込みだけを止めたいとき、PagerDutyのホスト型サーバーにはツール単位のフィルタリング機能がありません。代わりに、スコープを限定したOAuthクライアントを使うと、成功するツールを絞れます。全般アクセスキーなら、前述の「Read-only API Key」でGET呼び出しだけのキーにする手もあります。Claude Codeのようにサーバー名とツール名の単位で権限を制御できるクライアントを使う方法もあります。設定の書き方はClaude Code MCP権限ルールにまとめてあります。

ツールの名前は、資料によって粒度が違います。Claudeのコネクターページは64個の個別動詞(create_incident・add_respondersなど)を並べています。PagerDutyのサポートページは、browse_incidentsとmanage_incidentsのような集約ツールにアクションをぶら下げた形で案内しています。たとえばmanage_incidentsのアクションは、create・update・add_note・add_responders・start_workflowの5つです。名前の粒度が資料ごとに異なるので、名前よりも「何ができるか」で読むほうが確実です。

自前でサーバーを動かす旧来の構成は、すでに非推奨です。GitHubのリポジトリはアーカイブされて読み取り専用になっており、PagerDutyはホスト型への移行を案内しています。このリポジトリの既定は読み取り専用のツールだけを公開する動作で、--enable-write-toolsを付けたときに書き込みが有効になりました。ホスト型にはこの切り替えがないため、上の絞り込み方法が制御の手段になります。

まとめ

PagerDuty Connectorは、インシデント対応・オンコール変更・チーム管理・記録の4系統を会話で扱えます。書き込み系を任せるかどうかは、キーの種類(ユーザートークンか読み取り専用キーか)とクライアント側の権限設定で決めることになります。

定期監視やSLA超過時の自動エスカレーションのように無人実行させたい処理は、対話型とは別の構成が向いています。PagerDuty×CoworkでSLA監視とエスカレーションを自動化するに、Scheduled Tasksを使った組み方をまとめてあります。