Opsgenie でアラートを扱いやすくするには、「alias で重複をまとめる」「優先度とタグで仕分ける」「チームとルーティングで担当へ届ける」「復旧したら自動でクローズする」の4点を押さえるのが近道です。ただし Opsgenie は Atlassian が新規販売を終了し、サポート終了日も告知されているため、今使っている人は日々の運用と並行して移行の準備も進める必要があります。この記事では、現在 Opsgenie を使っている人向けに、アラート管理の基本と API の使い方、移行前に棚卸ししておく項目を説明します。
最初に確認：Opsgenie の提供状況
Atlassian の告知では、Opsgenie は2025年6月4日に新規販売を終了し、2027年4月5日にサポート終了（製品へのアクセス終了）となる予定です（2026年10月現在）。移行先としては Jira Service Management と Compass が案内されています。新規にアカウントを作って使い始めることはできないため、この記事の手順は既存の契約者を前提にしています。
日程や移行条件、未移行データの扱いは変更・追記されることがあるため、Atlassian の公式告知と移行ガイドで最新情報を確認してください。サポート終了日の間際は移行作業が集中しやすいので、検証期間を含めて早めに計画するのが安全です。
アラートのライフサイクルを理解する
Opsgenie のアラートは、おおむね次の状態をたどります。
- Open：作成された直後。通知ルールとエスカレーションに従って担当者へ通知される
- Acknowledged：担当者が「対応中」と応答した状態。エスカレーションが止まる
- Closed：対応が終わった状態
このほか、一時的に通知を止めるスヌーズや、メモ（ノート）の追加ができます。アラート管理で大事なのは、「人が対応すべきものだけが Open で残る」状態を保つことです。対応不要なアラートが Open のまま積み上がると、本当に重要なものが埋もれます。
手順1：alias で重複をまとめる
同じ障害について監視ツールが何度もアラートを送ると、そのたびに新しいアラートができては困ります。Opsgenie では alias が同じアラートが Open のまま残っている場合、新しいアラートは作られず、既存アラートの件数（count）が増えます。
alias は「障害の種類と対象」で決めるのがコツです。
- 良い例：
example-com-http-500、db01-disk-usage - 悪い例：時刻やランダムな値を含める（毎回別のアラートになってしまう）
監視ツールの連携機能を使う場合は、そのツールが alias をどう作るかを確認しておきます。
手順2：Alert API でアラートを作成・クローズする
スクリプトや自作の監視から送るときは Alert API を使います。API キーは連携（インテグレーション）設定で発行されるもので、GenieKey という形式で送ります。
curl -sS -X POST https://api.opsgenie.com/v2/alerts \
-H 'Content-Type: application/json' \
-H 'Authorization: GenieKey your-api-key' \
-d '{
"message": "example.com がHTTP 500を返しています",
"alias": "example-com-http-500",
"description": "外形監視で3回連続HTTP 500を検知",
"priority": "P2",
"tags": ["wordpress", "production"],
"entity": "example.com",
"source": "uptime-monitor"
}'ポイントは次のとおりです。
messageは必須で、長さに上限があります（ドキュメント上は130文字）。一覧で見て内容が分かる短い文にしますpriorityは P1〜P5 で、指定しなければ P3 になります- EU リージョンのアカウントでは、エンドポイントが
api.eu.opsgenie.comになります - 応答は「受け付けた」という意味で、アラートの作成自体は非同期に処理されます。応答に含まれる
requestIdで処理結果を確認できます
復旧したら、alias を指定してクローズします。
curl -sS -X POST 'https://api.opsgenie.com/v2/alerts/example-com-http-500/close?identifierType=alias' \
-H 'Content-Type: application/json' \
-H 'Authorization: GenieKey your-api-key' \
-d '{"note": "監視で復旧を確認"}'監視側で「異常 → 作成」「復旧 → クローズ」を対にしておくと、人が手で閉じ忘れたアラートが残りません。API キーは秘密情報なので、スクリプトに直接書かず、環境変数や権限を絞った設定ファイルから読み込んでください。
手順3：優先度とタグで仕分ける
アラートの数が増えてきたら、優先度とタグで仕分けます。
- 優先度：P1 は「今すぐ人が動く必要があり、利用者に影響が出ているもの」に限定する。P1 が多すぎると、P1 の意味がなくなります
- タグ：環境（production / staging）、サービス名、種類（http / disk / backup）などを付けると、絞り込みやルーティングの条件に使えます
- entity と source：何が壊れていて、どこから送られたかを残すと、後から傾向を調べやすくなります
ステージング環境のアラートを本番と同じ扱いにしないことも重要です。タグで区別し、ステージングは通知しないか、チャットへの通知だけにします。
手順4：チーム・スケジュール・エスカレーションで担当へ届ける
アラートを「誰に届けるか」は、チームに設定するルーティングで決まります。一般的な構成は次のとおりです。
- チームごとにオンコールスケジュールを作る
- エスカレーションで「第1段階はスケジュールの担当者、一定時間応答がなければ次の担当者」を決める
- ルーティングルールで、タグや優先度に応じてエスカレーションを選ぶ（例：P1/P2 は電話まで、P3 以下は勤務時間内だけ）
各ユーザーは自分の通知ルール（メール、SMS、電話、モバイルアプリ）を設定します。設定したら、テスト用のアラートを作って、意図した人に意図した方法で届くかを確認してください。画面の項目名は更新で変わることがあるため、迷ったら Atlassian のサポートドキュメントで現在の名称を確かめます。
手順5：ハートビートで「来ない連絡」を検知する
Opsgenie には、定期的に ping が来なければアラートを作るハートビート機能もあります。cron ジョブや WordPress のサーバー cron の実行確認に使えます。
# 例: 5分ごとのWP-Cron実行後にハートビートを送る（名前は事前に作成しておく）
curl -fsS -m 10 -o /dev/null -X POST \
-H 'Authorization: GenieKey your-api-key' \
https://api.opsgenie.com/v2/heartbeats/wp-cron-prod/ping移行を控えている場合、ハートビートは移行先で同じ仕組みがあるかを確認する必要がある機能の一つです。Healthchecks.io のような専用サービスに切り出しておく方法もあります。
移行に向けて棚卸ししておくこと
移行作業そのものは Atlassian の移行ガイドに沿って行いますが、その前に「何が Opsgenie につながっているか」を一覧にしておくと、切り替え時の通知漏れを防げます。
- 連携（インテグレーション）：監視ツール、メール連携、チャット連携の一覧と、それぞれの API キー
- API を直接呼んでいる箇所：シェルスクリプト、監視サーバー、WordPress のプラグインやコードなど。
api.opsgenie.comで検索すると見つけやすい - チーム・スケジュール・エスカレーション・ルーティングルール：移行後に同じ動きになっているかを比べるため、現状の画面や設定をエクスポート・記録しておく
- ハートビート：名前と期間
- ユーザーの通知ルール：移行後に各自で確認してもらう
移行先によって API のエンドポイントや認証方法、機能の名前が変わる可能性があります。移行後は、手順2のテスト送信と同じ要領で、各経路から実際にアラートが届くかを1つずつ確かめてください。移行期間中は、旧環境と新環境の両方へ送る並行運用期間を設けると、切り替え時の空白を避けられます。
まとめ
- Opsgenie は新規販売を終了しており、サポート終了日（告知では2027年4月5日）までに移行が必要
- alias を「障害の種類と対象」で決め、重複アラートを1件にまとめる
- Alert API では作成とクローズを対にし、Open のまま残るアラートを減らす
- 優先度は P1 を絞り込み、タグで環境やサービスを区別してルーティングに使う
- 移行前に連携・API 呼び出し・スケジュール・ハートビートを棚卸しし、移行後は経路ごとに送信テストする