PagerDuty MCPを使ってTerraformリソースの差分を解消してみた

PagerDuty MCPを使ってTerraformリソースの差分を解消してみた

2026.02.15

こんにちは。たかやまです。

最近PagerDutyを触る機会があり、普段からAIツールを活用していることもあって、PagerDutyもAIエージェントから操作できないかと調べてみたところ、MCPサーバーが公開されていることを知りました。

今回はこのPagerDuty MCPを使って環境情報を取得し、Terraform運用に活用してみたので紹介します。

さきにまとめ

  • PagerDuty-Hosted(リモート)とSelf-Hosted(ローカル)の2種類が提供されている
    • 管理の手軽さならHosted版、書き込みツールの制御やカスタマイズが必要ならSelf-Hosted版
  • API User Tokenの作成で簡単に利用開始できる
  • PagerDuty MCPサーバーは64のツールを提供しており、Read-only中心でリソース情報の取得に強い
    • リソース情報の取得はMCP、環境の更新はTerraformやPagerDuty APIと使い分けるのが実用的

PagerDuty MCPサーバーについて

PagerDuty MCPサーバーはPagerDuty更新が公開しているMCPサーバーです。

https://support.pagerduty.com/main/lang-ja/docs/pagerduty-mcp-server-integration-guide

PagerDuty MCPサーバーはPagerDuty-Hosted MCP Service(リモートMCPサーバー)とSelf-Hosted Open Source Server(ローカルMCPサーバー)が公開されています。

それぞれの特徴は以下のとおりです。

基本的には運用管理面で楽なPagerDuty-Hosted MCP Serviceを利用すると良いと思いますが、ガバナンス的にコントロールしたいケースや書き込みツールの利用を制限したいケースではSelf-Hosted Open Source Serverを利用すると良いと思います。

PagerDuty-Hosted MCP Service Self-Hosted Open Source Server
運用形態 PagerDutyが管理するマネージドサービス 自組織でデプロイ・運用するオープンソースサーバー
エンドポイント https://mcp.pagerduty.com/mcp ローカルまたはプライベートクラウド上で起動
インフラ管理 不要(PagerDuty側で管理) 自組織で管理が必要
アップデート 自動で最新バージョンに更新 手動でアップデート
カスタマイズ 不可 ソースコードの変更が可能
書き込みツール デフォルトで有効 --enable-write-tools フラグで明示的に有効化が必要

本記事ではPagerDuty-Hosted MCP Serviceを使用します。

利用可能なツール一覧

PagerDuty MCPサーバーでは64のツールが提供されています。

Read-only列が「✓」のツールは読み取り専用、空欄は書き込み可能なツールです。

Tool Area Description Read-only
list_alert_grouping_settings Alert Grouping アラートグルーピング設定の一覧をフィルタリング付きで取得
get_alert_grouping_setting Alert Grouping 特定のアラートグルーピング設定を取得
create_alert_grouping_setting Alert Grouping 新しいアラートグルーピング設定を作成
update_alert_grouping_setting Alert Grouping 既存のアラートグルーピング設定を更新
delete_alert_grouping_setting Alert Grouping アラートグルーピング設定を削除
list_change_events Change Events 変更イベントの一覧をフィルタリング付きで取得
get_change_event Change Events 特定の変更イベントを取得
list_incident_change_events Change Events 特定インシデントに関連する変更イベントの一覧を取得
list_service_change_events Change Events 特定サービスの変更イベントの一覧を取得
list_escalation_policies Escalation Policies エスカレーションポリシーの一覧を取得
get_escalation_policy Escalation Policies 特定のエスカレーションポリシーを取得
list_event_orchestrations Event Orchestrations イベントオーケストレーションの一覧をフィルタリング付きで取得
get_event_orchestration Event Orchestrations 特定のイベントオーケストレーションを取得
get_event_orchestration_global Event Orchestrations グローバルオーケストレーション設定を取得
get_event_orchestration_router Event Orchestrations オーケストレーションのルーター設定を取得
get_event_orchestration_service Event Orchestrations サービスオーケストレーション設定を取得
update_event_orchestration_router Event Orchestrations オーケストレーションのルーター設定を更新
append_event_orchestration_router_rule Event Orchestrations オーケストレーションルーターに新しいルールを追加
list_incidents Incidents インシデントの一覧を取得
get_incident Incidents 特定のインシデントを取得
get_outlier_incident Incidents 外れ値インシデント情報を取得
get_past_incidents Incidents 特定インシデントに関連する過去のインシデントを取得
get_related_incidents Incidents 特定インシデントの関連インシデントを取得
list_alerts_from_incident Incidents 特定インシデントの全アラートをページネーション付きで取得
get_alert_from_incident Incidents インシデントから特定のアラートを取得
list_incident_notes Incidents 特定インシデントの全ノートを取得
create_incident Incidents 新しいインシデントを作成
manage_incidents Incidents ステータス、緊急度、担当者、エスカレーションレベルを変更
add_note_to_incident Incidents インシデントにノートを追加
add_responders Incidents インシデントにレスポンダーを追加
list_incident_workflows Incident Workflows インシデントワークフローの一覧をフィルタリング付きで取得
get_incident_workflow Incident Workflows 特定のインシデントワークフローを取得
start_incident_workflow Incident Workflows インシデントのワークフローインスタンスを開始
list_log_entries Log Entries アカウント全体のログエントリを時間フィルタリング付きで取得
get_log_entry Log Entries IDで特定のログエントリを取得
list_oncalls On-Call オンコールスケジュールの一覧を取得
list_schedules Schedules スケジュールの一覧を取得
get_schedule Schedules 特定のスケジュールを取得
list_schedule_users Schedules スケジュール内のユーザー一覧を取得
create_schedule Schedules 新しいオンコールスケジュールを作成
update_schedule Schedules 既存のスケジュールを更新
create_schedule_override Schedules スケジュールのオーバーライドを作成
list_services Services サービスの一覧を取得
get_service Services 特定のサービスを取得
create_service Services 新しいサービスを作成
update_service Services 既存のサービスを更新
list_status_pages Status Pages ステータスページの一覧をフィルタリング付きで取得
list_status_page_impacts Status Pages ステータスページで利用可能な影響レベルの一覧を取得
list_status_page_severities Status Pages ステータスページで利用可能な重大度レベルの一覧を取得
list_status_page_statuses Status Pages ステータスページで利用可能なステータスの一覧を取得
get_status_page_post Status Pages 特定のステータスページ投稿の詳細を取得
list_status_page_post_updates Status Pages 特定のステータスページ投稿の全更新を取得
create_status_page_post Status Pages ステータスページにインシデントまたはメンテナンス投稿を作成
create_status_page_post_update Status Pages 既存のステータスページ投稿に新しい更新を追加
list_teams Teams チームの一覧を取得
get_team Teams 特定のチームを取得
list_team_members Teams チームのメンバー一覧を取得
create_team Teams 新しいチームを作成
update_team Teams 既存のチームを更新
delete_team Teams チームを削除
add_team_member Teams 特定のロールでユーザーをチームに追加
remove_team_member Teams チームからユーザーを削除
list_users Users PagerDutyアカウントのユーザー一覧を取得
get_user_data Users 現在のユーザーのデータを取得

見ていただくとわかるとおりPagerDuty MCPサーバーからRead-onlyツールは多く提供されているものの書き込みツールは少ない印象です。

実際のユースケースでは情報取得にPagerDuty MCPサーバーを利用しつつ、環境の更新にはPagerDuty APIを使うかTerraformを使うなどの方法が良さそうです。

今回は読み取り操作を中心に、Terraform importに必要な情報を取得する使い方を紹介します。

やってみた

API User Tokenの作成

まずPagerDutyのAPI User Tokenを作成します。

PagerDuty Web UIにログインし、右上のユーザープロファイルアイコンから「My Profile」 > 「User Settings」に移動します。

「API User Tokens」セクションで「Create API User Token」をクリックします。

CleanShot 2026-02-15 at 11.59.47@2x.png

トークンに適当な説明をつけて作成します。
作成されたトークンは一度しか表示されないため、必ず控えておいてください。

CleanShot 2026-02-15 at 12.01.47@2x.png

Claude CodeへPagerDuty MCPを追加

今回はClaude Codeを使って設定をしたいと思います。

作成したAPI User Tokenを使って、Claude CodeにPagerDuty MCPサーバーを追加します。

<YOUR_API_USER_TOKEN> の部分は先ほど作成したトークンに置き換えてください。

claude mcp add --transport http pagerduty-hosted https://mcp.pagerduty.com/mcp \
  --header "Authorization: Token <YOUR_API_USER_TOKEN>" \
  --scope user
Claude DeskitopやCursorに追加したい場合はこちら
{
  "mcpServers": {
    "pagerduty-hosted": {
      "url": "https://mcp.pagerduty.com/mcp",
      "headers": {
        "Authorization": "Token <YOUR_API_USER_TOKEN>"
      }
    }
  }
}

PagerDuty MCP Server Integration Guide

コマンド実行後、Claude Codeを再起動するとPagerDuty MCPサーバーがConnectedであれば利用可能です。

❯ claude mcp list
Checking MCP server health...

pagerduty-hosted: https://mcp.pagerduty.com/mcp (HTTP) - ✓ Connected

PagerDutyのリソース情報を取得してみる

Claude Codeを起動して、PagerDutyのリソース情報を取得してみます。

ここではエスカレーションポリシーの一覧を取得してみます。

> エスカレーションポリシー一覧を見せてください

⏺ PagerDutyのエスカレーションポリシー一覧を取得します。

⏺ pagerduty-hosted - list_escalation_policies (MCP)(query_model: {})
  ⎿  {
       "response": [
         {
     … +212 lines (ctrl+o to expand)

⏺ PagerDutyのエスカレーションポリシー一覧を取得しました(4件)

  1. Default (PXXXXXX)

  - エスカレーション先: Test User A
  - 遅延時間: 30分
  - 関連サービス: Default Service

  2. production-ep (PYYYYYY)

  - 説明: 本番環境用エスカレーションポリシー
  - エスカレーション先: Test User B
  - 遅延時間: 30分
  - 関連サービス: production-service

  3. development-ep (PZZZZZZ)

  - 説明: 開発環境用エスカレーションポリシー
  - エスカレーション先: Test User C
  - 遅延時間: 30分
  - 関連サービス: development-service

  4. staging-ep (PWWWWWW)

  - エスカレーション先: Test User A
  - 遅延時間: 30分
  - 関連サービス: staging-service

  特定のポリシーの詳細が必要な場合は、IDを指定してください。

無事PagerDuty MCPを使ってエスカレーションポリシーの一覧が取得していることが確認できました。

他にもドキュメント上で以下のようなプロンプト例が紹介されています。

共通コマンド

- 「自分に割り当てられたオープン中のインシデントを見せて」
- 「過去24時間の高緊急度インシデントは?」
- 「APIサービスに 'Database connection timeout' というタイトルでインシデントを作成して」
- 「インシデント #PD12345 を確認済みにして、根本原因を調査中というノートを追加して」
- 「プラットフォームチームの現在のオンコール担当者は?」
- 「Webサービスのエスカレーションポリシーを見せて」

高度なクエリ

- 「直近1週間に作成されたインシデントを解決時間付きで一覧表示して」
- 「最近インシデントが発生していないサービスを教えて」
- 「過去1ヶ月間に解決されたデータベースサービス関連のインシデントを検索して」

Terraform運用に活用してみる

直近Webコンソール上でEvent Orchestrationを更新していたものがあったのでそちらをPagerDuty MCPを使って情報を取得しTerraform側で差分を修正していきます。

CleanShot 2026-02-15 at 13.19.10@2x.png

まず、PagerDuty MCPのを使って、実環境のEvent Orchestration一覧を取得します。

> Event Orchestrationの一覧を見せてください

⏺ PagerDutyのEvent Orchestration一覧を取得します。

⏺ pagerduty-hosted - list_event_orchestrations (MCP)(query_model: {})
  ⎿  {
       "response": [
         {
           "id": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
           "name": "project-a",
           "description": "プロジェクトA案件",
           "routes": 0,
           "created_at": "2026-02-13T08:48:27Z"
         },
         {
           "id": "11111111-2222-3333-4444-555555555555",
           "name": "project-b",
           "description": "プロジェクトB案件",
           "routes": 1,
           "created_at": "2026-01-29T07:47:52Z"
         }
       ]
     }

⏺ Event Orchestrationが2件見つかりました

  1. project-a (aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee)
     - 説明: プロジェクトA案件
     - ルート数: 0
     - 作成日: 2026-02-13

  2. project-b (11111111-2222-3333-4444-555555555555)
     - 説明: プロジェクトB案件
     - ルート数: 1
     - 作成日: 2026-01-29

Claude Codeがlist_event_orchestrations ツールを使ってEvent Orchestration一覧を取得してくれているのがわかります。

一方、既存のTerraformコードでは以下のようにEvent Orchestrationが1つだけ定義されていました。

resource "pagerduty_event_orchestration" "old_project_a" {
  name        = "project-a"
  description = "旧プロジェクトA案件"
}

MCPで取得した実環境の情報とTerraformコードを比較すると、2つの差分が見つかりました。

1つ目は、Terraformコードで定義している project-a の名前やdescriptionが、実環境では変更されていて一致しないことです。

これはPagerDuty Web UIからdescriptionを変更されていたため、Terraform側のコードとstateを実環境に合わせて修正する必要があります。

項目 Terraformコード 実環境
name project-a project-a
description 旧プロジェクトA案件 プロジェクトA案件
resource名 old_project_a

2つ目は、project-b がPagerDuty Web UIから手動作成されたEvent Orchestrationで、Terraformの管理下にないことです。
このリソースを terraform import でTerraform管理に取り込む必要があります。

次に、Terraform管理外のリソースである project-b の詳細情報をMCPで取得します。importに必要なIDやルーター設定を確認します。

> project-bの詳細を見せてください

⏺ pagerduty-hosted - get_event_orchestration (MCP)(orchestration_id: "11111111-2222-3333-4444-555555555555")
  ⎿  {
       "id": "11111111-2222-3333-4444-555555555555",
       "name": "project-b",
       "description": "プロジェクトB案件",
       "integrations": [
         {
           "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
           "label": "project-b Default Integration",
           "parameters": {
             "routing_key": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
             "type": "global"
           }
         }
       ]
     }

ルーター設定も確認します。

> project-bのルーター設定を見せてください

⏺ pagerduty-hosted - get_event_orchestration_router (MCP)(orchestration_id: "11111111-2222-3333-4444-555555555555")
  ⎿  {
       "orchestration_path": {
         "sets": [
           {
             "id": "start",
             "rules": []
           }
         ],
         "catch_all": {
           "actions": {
             "route_to": "unrouted"
           }
         }
       }
     }

⏺ ルーターにはルールが定義されておらず、catch-allは「unrouted」に設定されています。
  まだルーティング先のサービスが設定されていない初期状態です。

このように、Claude Code側でMCPから適切にツールを呼び出しOrchestration IDやルーター設定の詳細を取得してくれています。

ここでClaude Codeに差分の解消を依頼すると、MCPで取得した情報をもとにTerraformコードの修正を提案してくれました。

まず、既存リソース(project-a)のresource名とdescriptionを実環境に合わせる修正です。

event_orchestration.tf の修正(差分)

-# Global Event Orchestration for Project A
-resource "pagerduty_event_orchestration" "old_project_a" {
-  name        = "project-a"
-  description = "旧プロジェクトA案件"
+resource "pagerduty_event_orchestration" "project_a" {
+  name        = "project-a"
+  description = "プロジェクトA案件"
 }

event_orchestration_router.tf の修正(差分)

-resource "pagerduty_event_orchestration_router" "old_project_a" {
-  event_orchestration = pagerduty_event_orchestration.old_project_a.id
+resource "pagerduty_event_orchestration_router" "project_a" {
+  event_orchestration = pagerduty_event_orchestration.project_a.id

続いて、project-b 用の新規リソース定義も生成してくれました。

# Global Event Orchestration for Project B
resource "pagerduty_event_orchestration" "project_b" {
  name        = "project-b"
  description = "プロジェクトB案件"
}

ルーター設定もMCPで取得した内容に合わせた定義が生成してくれます。

# Global Event Orchestration Router for Project B
resource "pagerduty_event_orchestration_router" "project_b" {
  event_orchestration = pagerduty_event_orchestration.project_b.id

  set {
    id = "start"
  }

  catch_all {
    actions {
      route_to = "unrouted"
    }
  }
}

Claude Codeが生成したTerraformコードを確認して問題なかったので、続けてstate操作もClaude Codeに実行してもらいます。

⏺ terraform state操作を実行します。
  まず terraform state mv で既存リソースの名前を変更し、
  その後 terraform import で project-bリソースを取り込みます。

⏺ Bash(terraform state mv pagerduty_event_orchestration.old_project_a pagerduty_event_orchestration.project_a)
  ⎿  Move "pagerduty_event_orchestration.old_project_a" to "pagerduty_event_orchestration.project_a"
     Successfully moved 1 object(s).

⏺ Bash(terraform state mv pagerduty_event_orchestration_router.old_project_a pagerduty_event_orchestration_router.project_a)
  ⎿  Move "pagerduty_event_orchestration_router.old_project_a" to "pagerduty_event_orchestration_router.project_a"
     Successfully moved 1 object(s).

⏺ 成功しました。続けてproject-bのimportを実行します。

⏺ Bash(terraform import pagerduty_event_orchestration.project_b 11111111-2222-3333-4444-555555555555)
  ⎿  pagerduty_event_orchestration.project_b: Importing from ID "11111111-2222-3333-4444-555555555555"...
     pagerduty_event_orchestration.project_b: Import prepared!
       Prepared pagerduty_event_orchestration for import
     pagerduty_event_orchestration.project_b: Refreshing state... [id=11111111-2222-3333-4444-555555555555]

     Import successful!

⏺ Bash(terraform import pagerduty_event_orchestration_router.project_b 11111111-2222-3333-4444-555555555555)
  ⎿  pagerduty_event_orchestration_router.project_b: Importing from ID "11111111-2222-3333-4444-555555555555"...
     pagerduty_event_orchestration_router.project_b: Import prepared!
       Prepared pagerduty_event_orchestration_router for import
     pagerduty_event_orchestration_router.project_b: Refreshing state... [id=11111111-2222-3333-4444-555555555555]

     Import successful!

⏺ 全4つのstate操作が成功しました。terraform planで確認します。

⏺ Bash(terraform plan)
  ⎿  pagerduty_event_orchestration.project_a: Refreshing state... [id=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee]
     pagerduty_event_orchestration.project_b: Refreshing state... [id=11111111-2222-3333-4444-555555555555]
     pagerduty_event_orchestration_router.project_a: Refreshing state... [id=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee]
     pagerduty_event_orchestration_router.project_b: Refreshing state... [id=11111111-2222-3333-4444-555555555555]

     No changes. Your infrastructure matches the configuration.

     Terraform has compared your real infrastructure against your configuration
     and found no differences, so no changes are needed.

⏺ No changes が確認できました。

terraform state mv でproject-aのresource名を変更し、その後 terraform import でproject-bを取り込む流れで実行してくれました。

最終的にterraform plan まで実行してくれ、無事差分がないことを確認できました。

PagerDuty MCPを使い「実環境の現状把握」と「Terraform mv / import対応」を対話的に完結することができました。

最後に

今回はPagerDuty MCPサーバーを使って、実環境のリソース情報を取得し、Terraform運用に活用する例を紹介しました。

MCPを使うことでリソースの一覧取得から詳細情報の確認、importに必要なIDの特定までをClaude Code上で対話的に完結することができました。

PagerDuty MCP自体での作成系のツールは少ない印象ですが、TerraformやPagerDuty APIでの操作と組み合わせることで有効に活用できると思います。

PagerDutyをTerraformで管理している方や、これから既存リソースをTerraform化しようとしている方は、ぜひPagerDuty MCPサーバーを試してみてください。

以上、たかやま(@nyan_kotaroo)でした。

この記事をシェアする

FacebookHatena blogX

関連記事