公開2026.09.04更新2026.09.27 監視・オブザーバビリティ

PagerDuty料金の実額と落とし穴｜Opsgenie終了後の移行コストを実装目線で解説

PagerDutyの見積もりで最初につまずくのは、公式サイトに並ぶ1ユーザーあたりの単価が請求額の一部でしかない点にあります。Freeは0ドルで使えますが5ユーザーまで、Professionalは1ユーザー月25ドル、Businessは月49ドル。ここにAIOpsやステータスページのアドオンが別建てで乗ります。この記事では、公式価格表の実額を4プランの比較表で確定させたうえで、ユーザー単価に積み上がる費用の内訳、Events API v2でアラートを送る実装手順、Opsgenie終了を起点にした移行コスト、10人・30人規模の年額試算、そして採用しない条件までを順に示します。

まとめ｜PagerDutyの料金を4プランと従量アドオンで見積もる判断軸

PagerDutyの費用は、ユーザー単価×人数では実額に届きません。PagerDuty公式の価格表（2026年9月時点）ではFreeが0ドル・5ユーザーまで、Professionalが1ユーザー月25ドル（年払いなら月21ドル相当）、Businessが1ユーザー月49ドル（年払いなら月41ドル相当）、Enterpriseは個別見積もりという4段構えになっています。そこへAIOpsやステータスページといったアドオンが月額で加算されます。

漏れやすいのは3か所です。オンコールに入らない関係者へ配る席、国際電話とSMSの通知回数、Enterpriseでしか使えないインシデントワークフローの分岐処理。この3点を先に決めれば、Professionalで足りるのかBusinessまで上げるのかは機械的に定まります。

もうひとつの変数が移行です。AtlassianはOpsgenieのサポート終了を2027年4月5日と告知しており、移行先候補としてPagerDutyを比較する場面が増えました。判断を分けるのは月額の差ではなく、エスカレーションポリシーとオンコール表を作り直す工数です。

公式価格表の実額整理｜4プランのユーザー単価と年払い16%割引を適用した月額

まず一次情報で金額を固定します。以下は公式価格ページの記載を、見積書へ落としやすい形に並べ直したものです。通貨は米ドル建てで、日本語版のIncident Management価格ページでも同じ体系が示されています。

Free・Professional・Businessの単価差と年払い16%割引の効き方

年払いを選ぶと16%引きになる割引率が公式に明示されています。月払い25ドルが年払いで21ドル相当、49ドルが41ドル相当という関係です。差額は1人あたり月4〜8ドル。30人規模だと年間で1,440〜2,880ドル動きます。

プラン	月払い	年払い	ユーザー上限
Free	0ドル	0ドル	5ユーザー
Professional	25ドル	21ドル	上限なし
Business	49ドル	41ドル	上限なし
Enterprise	個別見積もり	個別見積もり	上限なし

単価はいずれも1ユーザーあたり月額です。為替の影響を受けるため、円建ての予算を組むなら契約時点のレートと、期中の変動をどちらが負担するかを購買部門と先に握っておきます。

無料プラン5ユーザー上限と月100件の国際電話・SMS通知枠

Freeは検証用と割り切られがちですが、条件を読むと小規模チームの本番運用にも耐えます。公式価格表には、Freeでも国際電話・SMS通知が月100件まで含まれ、オンコールスケジュール1つ、エスカレーションポリシー1つ、750を超える連携先が使えると書かれています。

詰まるのは3か所。ユーザーが5人を超えた瞬間、スケジュールを2系統に分けたくなった瞬間、通知が月100件を超えた瞬間です。逆に言えば、夜間当番が5人以下で単一ローテーション、月間アラートが100件未満なら、Freeのままで問題は起きません。

ProfessionalとBusinessを分ける機能差とカスタムフィールドの線引き

有償プラン同士の差は通知性能ではなく、インシデントの構造化にあります。Professionalで増えるのはSlackやMicrosoft Teamsとのチャット連携、外部ステータスページ（購読者250名まで）、事後レビュー機能。Businessではカスタムフィールドが解禁され、カスタムインシデントタイプを3つまで定義でき、内部向けステータスページが加わります。

判断軸はひとつ。インシデントを種別ごとに違う様式で扱いたいかどうかです。障害の種類に応じて記録項目を変えたい、影響範囲を構造化データとして後から集計したいならBusiness。鳴らして、出て、直すだけならProfessionalで止めます。Enterpriseまで上げる理由は価格表上ほぼ一点で、条件分岐・ループ・遅延を含むインシデントワークフローとカスタムインシデントタイプ100件までの拡張です。プロセス設計の考え方はインシデント管理とは？ITIL準拠のプロセスと監視・オンコールの実装で整理しています。

ユーザー単価だけでは足りない月額の内訳とアドオン課金の積み上げ方

請求書はベースプランとアドオンの合算です。アドオンはユーザー数と連動しないものが多く、席を減らしても下がりません。

AIOpsアドオン月額799ドルと年払い699ドルの適用条件

アラートの相関付けやノイズ削減を担うAIOpsは、ユーザー単価とは別建てです。日本語版のAIOps価格ページには月払い799ドル、年間プランでは16%引きの699ドルからと記載され、使用量に応じた課金である旨が添えられています。最低ラインが月799ドルで、イベント量が増えれば上振れます。

10人チームがProfessionalを年払いで契約した場合、ベースは月210ドル。ここにAIOpsを足すと月909ドルとなり、費用構成が逆転します。アラート数が1日数十件で目視で捌けているなら、AIOpsは過剰です。何を自動化する機能なのかはAIOpsとは？IT運用×AIの仕組みと主要機能・MLOpsとの違いで先に押さえておくと、営業提案との突き合わせが速くなります。

ステータスページ1,000購読者あたり月額89ドルの積算方法

外部向けステータスページは購読者数で課金され、日本語版の価格ページでは1,000購読者あたり月89ドルという単位が示されています。Professionalに含まれる外部ステータスページは購読者250名まで。それを超えると別建ての課金に移ります。

BtoCサービスで購読者が1万人規模になると、この行だけで月890ドル。ユーザー単価の議論とは桁が変わります。購読者数の伸びを予算に織り込まないまま契約すると、2年目に予算超過が生じかねません。課金モデルの読み方はオブザーバビリティツール比較｜選定軸と課金モデル・体制別の選び方で横断的に整理しています。

見積書に載りにくい実額｜ステークホルダー席と通知超過分の扱い

実運用で膨らむのは、オンコールに入らない人の席です。障害を知りたいだけの営業・カスタマーサポート・経営層に通常ライセンスを配ると、1人月25〜49ドルがそのまま積み上がります。この用途にはStakeholderライセンスというアドオンが別途あるので、配る前に区分を決めておきます。

もう一系統が通知量。Freeに含まれる国際電話・SMSは月100件で、日本から使う場合はこの国際通知枠に該当するため、深夜のエスカレーションが多い体制では枠を先に食います。AI機能のPagerDuty Advanceも、Professionalが月1,000アクション、Businessが5,000、Enterpriseが20,000と段階が引かれ、超過分は追加購入です。見積もり時点で席・通知・AIアクションの3つに上限を書き込んでおくと、請求書との差分が出ません。

Events API v2でアラートを送信する実装手順と必須フィールドの指定

料金を決めるのは席数だけでなく、どれだけイベントを送り込むかでもあります。送信側の実装を押さえれば、AIOpsの要否を実測で判断できます。以下はPagerDuty公式のOpenAPI仕様に基づく内容です。

enqueueエンドポイントとrouting_keyに指定する統合キーの取得

送信先はEvents API v2のenqueueで、サーバーURLはevents.pagerduty.comのv2配下です。認証ヘッダーではなく、ボディのrouting_keyで宛先を特定します。この値は対象サービスにEvents API V2の連携を追加したときに発行されるIntegration Keyで、公式仕様でも「Events API V2連携の詳細ページに表示されるIntegration Key」と定義されています。

curl -X POST https://events.pagerduty.com/v2/enqueue \
  -H "Content-Type: application/json" \
  -d '{
    "routing_key": "YOUR_INTEGRATION_KEY",
    "event_action": "trigger",
    "dedup_key": "srv01/mysql",
    "payload": {
      "summary": "DISK at 99% on prod-datapipe03",
      "source": "prod-datapipe03.example.com",
      "severity": "critical",
      "component": "mysql",
      "group": "prod-datapipe",
      "class": "disk"
    }
  }'

キーはサービス単位で発行されるため、監視対象ごとに分けておくと後から通知先を切り替えられます。1本のキーを全システムで共有すると、エスカレーション先を分けたくなった時点で全監視設定の書き換えが発生します。

payloadの必須3項目summary・severity・sourceの指定内容

公式のOpenAPI仕様では、リクエスト直下の必須がrouting_keyとevent_actionの2つ、payloadオブジェクトの必須がsummary・severity・sourceの3つと定義され、severityに指定できる値はcritical・warning・error・infoの4種類に限定されます。

運用で効くのはsourceの設計です。仕様には「影響を受けるシステムの一意な場所。ホスト名またはFQDNが望ましい」と書かれています。ここにアプリ名だけを入れると、同一アプリが複数ノードで動く環境でどのノードが落ちたか分からないアラートが量産されかねません。component・group・classは必須ではありませんが、AIOpsの相関付けはこれらを手がかりにするため、後から検討する可能性があるなら最初から埋めておきます。

dedup_keyで重複アラートを束ねtriggerとresolveを往復させる設計

同じ障害で通知が連打される問題は、dedup_keyで解決します。仕様上はevent_actionがtrigger以外の場合に必須で、triggerでは省略可。同一キーでtriggerを送り続けても既存アラートが更新されるだけで、新規アラートは増えません。復旧時は同じキーでresolveを送ります。

curl -X POST https://events.pagerduty.com/v2/enqueue \
  -H "Content-Type: application/json" \
  -d '{
    "routing_key": "YOUR_INTEGRATION_KEY",
    "event_action": "resolve",
    "dedup_key": "srv01/mysql"
  }'

キーは「監視対象＋検知条件」の組み合わせで設計します。ホスト名だけにすると同一ホストのディスクとメモリの障害が1本に潰れ、タイムスタンプを含めると毎回別アラートになって束ねる意味が消えます。自前の監視スクリプトから送る場合は、外形監視とは？内部監視との違いと監視項目・実装、導入判断で扱う監視項目の設計とセットで考えると整理しやすいはずです。

202と429のレスポンスで切り分ける送信失敗時のリトライ方針

仕様に定義されたレスポンスは、成功が202、引数エラーが400、レート超過が429、サーバー側障害が5XXです。開発者ドキュメントのEvents API v2リファレンスでも同じ区分が示されています。

切り分けはこう決めます。400はリトライしても通りません。payloadの必須項目漏れかseverityの値違反なので、送信側のログに残して別経路で通知します。429と5XXは指数バックオフで再送。一律リトライにすると障害時に429が連鎖し、肝心の通知が届きません。監視エージェント側に送信キューを持たせ、失敗したイベントを保持して再送する構成が安全です。通知元となる監視SaaS側の選び方はMackerelでサーバーを監視する手順｜agent導入から料金試算と採用判断までで扱っています。

Opsgenie終了2027年4月5日を起点にした移行先比較と切替工数の見積もり

PagerDutyの価格を調べている理由が「Opsgenieの終了」である読者が増えています。移行判断は費用差ではなく、期限と作り直しの工数で決まります。

サポート終了2027年4月5日とJira Service Managementへの移行

AtlassianのOpsgenie移行案内および移行スケジュールのドキュメントでは、サポート終了日が2027年4月5日と示され、標準の移行先としてJira Service Managementのクラウド版が案内されています。アラートルーティング、オンコールスケジュール、エスカレーションポリシーといった中核機能はJira Service Management側で再構成されます。

注意点がひとつ。公式の移行ツールが対応するのはAtlassianのクラウド製品への移行で、Data Centerへの移行には対応しないとドキュメントに明記されています。オンプレミス寄りの運用を続ける前提なら、Jira Service Managementへの横移動という選択肢が成立しません。そこでPagerDutyを含む他製品の比較が現実的になります。

移行で作り直しになるエスカレーションポリシーとオンコール表の再定義

移行工数の中身は、データ移送ではなく定義の作り直しです。エスカレーションポリシーの段数、各段の待ち時間、休日と平日で切り替わるローテーション、代理設定。これらは製品ごとに表現が違うため、機械的な変換では落ちます。

進め方は、まず現行のオンコール表を「誰が・いつ・何分で・誰にエスカレーションするか」の表に書き出し、製品を触る前に紙の上で確定させること。この工程を飛ばして両方の管理画面を突き合わせると、移行後に誰にも鳴らない時間帯が残ります。切替直後は旧環境と新環境の両方へイベントを二重送信する期間を2週間ほど設け、実際に鳴ることを確認してから旧環境を止めます。

オンコール10人と30人規模の年額試算と削減できるライセンスの見極め

ここまでの単価を実際の体制に当てて年額に直します。数字は公式価格表の記載に基づく計算値で、為替と個別条件は含みません。

オンコール10人でProfessional年払いを選んだ場合の年額試算

1ユーザー月21ドル×10人＝月210ドル、年間2,520ドル。月払いなら月250ドル・年間3,000ドルで、差は年間480ドルです。この規模ではアドオンを付けない構成が現実的で、外部ステータスページも購読者250名までならProfessionalに含まれます。

逆にこの規模でAIOpsを足すと年間8,388ドル（月699ドル×12）が上乗せされ、総額は3.3倍を超えます。10人体制でアラートノイズに悩んでいるなら、まず送信側のdedup_key設計と閾値の見直しで削るほうが費用効率は上。効果はMTTRの推移で測れます。指標の定義と計算式はMTTRとは？計算式・MTBFとの違いと稼働率への影響、短縮策にまとめています。

30人規模でBusinessとAIOpsを併用した場合の年額と内訳

1ユーザー月41ドル×30人＝月1,230ドル、年間14,760ドル。ここにAIOpsの年払い最低ライン（月699ドル）が加わって年間8,388ドル、合計23,148ドル。さらに外部ステータスページの購読者が3,000名いれば月267ドル（89ドル×3）で年間3,204ドルが乗り、総額は26,352ドル規模になります。

内訳はベースプランが約56%、AIOpsが約32%、ステータスページが約12%。削減余地が大きいのはベースプランの席数で、次がAIOpsの要否です。ステータスページは購読者数に連動する固定費として扱います。

全員に有償席を配らない運用設計とステークホルダー席の使い分け

30人のうち夜間の呼び出しを受けるのは何人でしょうか。多くの現場で深夜に電話が鳴る対象は5〜8人、残りは状況を見たい人です。後者に通常ライセンスを配ると年間1万ドル前後の無駄が出ます。

設計としては、オンコール当番と一次対応者だけに有償席を割り当て、閲覧と共有はステークホルダー用のライセンスかステータスページと連携チャンネルで代替します。席を減らすとエスカレーション先が足りなくなるという懸念は、ポリシーを人ではなくスケジュールに紐づければ解消可能です。この線引きを含む監視・オンコール体制の設計や内製化を外部と組んで進めるなら、保守運用・内製化支援のように運用設計から入れる体制で相談すると、ライセンス構成と当番表を同時に詰められます。

PagerDutyを採用しない条件と無料枠・他ツールで足りる運用規模の線引き

費用対効果が成立しない条件は明確に存在します。玉虫色にせず、条件付きで言い切ります。

5人以下・夜間対応なしの体制でPagerDutyを見送る判断条件

次の3条件をすべて満たすなら有償プランは見送ります。エンジニアが5人以下。夜間・休日の即時対応をSLAとして約束していない。月間アラート件数が100件未満。この場合はFreeの5ユーザー・スケジュール1本・国際通知月100件の枠に収まり、支払いは0ドルのままです。

1つでも外れたら有償を検討します。とくにSLAで一次応答時間を約束しているなら、通知が届かないリスクがそのまま契約違反につながるため、席数が少なくてもProfessionalへ上げる価値があります。

失敗パターン｜通知先を増やしただけで応答率が上がらない導入例

効果が出ない典型は、エスカレーションポリシーを作らずに全員へ同報する設定です。全員宛の通知は「誰かが見るだろう」を生み、応答率が下がります。価格に見合う効果は、1段目で誰か1人に確実に到達し、5分で応答がなければ2段目へ自動で上がる構造から生まれます。

もうひとつの失敗は、監視側の閾値を触らないまま繋ぐケース。既存の監視が1日200件のwarningを出していれば、深夜に200回鳴ります。結果として通知を切る運用が定着し、契約だけが残りかねません。導入前に送信イベントをcriticalへ絞り、warning以下はチャットに流す振り分けを決めておきます。

内製の通知スクリプトで足りる条件と限界が来る運用規模の判断目安

Slack通知とcronで組んだ自前の仕組みでも、当番が1人で固定なら回ります。限界が来るのは、当番表がローテーションし始めたとき、代理交代が発生するとき、エスカレーションの段数が2段を超えたときの3つ。これが揃うと当番表の管理コストが月数時間単位で発生し、有償プランの単価を上回ります。祝日と代休を手作業で反映し始めた時点が移行の検討時期です。

よくある質問

料金と契約条件でよく問われる論点を5つに絞って回答します。金額は公式価格ページの記載（2026年9月時点）に基づきます。

PagerDutyは無料で使えますか？

Freeプランがあり、5ユーザーまで0ドルで使えます。公式価格表によれば、オンコールスケジュール1つ、エスカレーションポリシー1つ、国際電話・SMS通知が月100件まで、750を超える連携先が含まれる内容です。単一ローテーションで月間アラートが100件未満なら、Freeのまま本番運用に耐えます。6人目のユーザーが増える、スケジュールを平日と休日で分ける、通知が月100件を超える、のいずれかでProfessionalを検討します。

ProfessionalとBusinessはどちらを選ぶべきですか？

インシデントを種別ごとに構造化したいかどうかで決めます。Businessで解禁されるのはカスタムフィールドとカスタムインシデントタイプ（3つまで）、内部向けステータスページの3点。障害の種類に応じて記録項目を変えたい、後から影響範囲を構造化データで集計したい場合はBusinessです。単価差は1ユーザー月20〜24ドルなので、30人規模では年間7,200ドル前後の差になります。

AIOpsは追加でいくらかかりますか？

日本語版のAIOps価格ページには、月払い799ドル、年間プラン（16%オフ）で699ドルからと記載され、使用量に応じた課金と説明されています。ユーザー数ではなくアドオンの月額なので、10人体制でも30人体制でも下限は変わりません。10人でProfessional年払いなら、ベースの月210ドルに対してAIOpsが月699ドル。費用の主役が入れ替わります。

Opsgenieからの移行先としてPagerDutyは妥当ですか？

Atlassian公式が案内する標準の移行先はJira Service Managementのクラウド版で、サポート終了日は2027年4月5日と示されています。ただし公式の移行ツールはAtlassianのクラウド製品への移行のみに対応し、Data Centerへの移行には対応しません。Jiraを使っておらずクラウド前提でもない組織なら、PagerDutyを含む他製品の比較が現実的です。

PagerDutyの料金は日本円で支払えますか？

公式価格ページの表示は米ドル建てです。国内の正規代理店経由なら円建ての契約形態が用意されており、価格表も公開されています。直販のドル建てより単価は上がる傾向にあるため、年額の差を計算したうえで、為替変動の吸収と国内請求書対応の手間を天秤にかけて選びます。差額が年10%以内に収まるなら、経理処理の簡便さから円建てを選ぶ判断で支障ありません。