Opsgenie EOL：2027年の終了日と代替サービス

Opsgenieは 2027年4月5日 に終了します。この日以降、製品にはアクセスできなくなり、連携機能とREST APIは停止し、移行されていない顧客データは削除されます。

多くのチームにとって、Jira Service Managementが最も安全な完全移行先です。一方、Opsgenieを主に「監視イベントを緊急モバイル通知に変えるため」に利用しているなら、インシデント管理プラットフォーム全体が必要か、より小さな通知レイヤーで足りるかを見直す機会でもあります。

Opsgenieの終了スケジュール

日付	変更内容
2025年3月4日	AtlassianがOpsgenieの販売・サポート終了を発表。
2025年6月4日	新規販売を終了。プラン変更や新規サイト追加も停止。
2027年4月5日	Opsgenieを停止。未移行データを削除。

既存顧客は終了日まで利用できますが、最後の数週間まで待つのは危険です。最新情報は公式移行ページとライセンスFAQで確認してください。

2027年4月5日以降に停止するもの

Opsgenieが停止すると、依存している以下の機能や経路が使えなくなります。

Opsgenieのアラートとオンコールワークフロー
Opsgenieモバイルアプリ
残っているOpsgenie連携
Opsgenie REST API
移行されていないデータと設定

監視ツールが障害を検知し続けても、古いOpsgenie連携は通知先のない経路になります。Atlassianの停止後に起きることでは、すべてのアラートとオンコールワークフローを先に移行するよう案内しています。

公式移行先：Jira Service Management

アラート、スケジュール、エスカレーションポリシー、インシデント対応、履歴データを維持する必要がある場合、Jira Service Managementが標準的な選択です。

Opsgenieのオーナーは Settings → Plan your move から推奨プランを確認し、移行日を設定できます。移行先とプランの承認後、多くのデータと設定は自動的に同期されます。

ただし、すべてが同じ形で移るとは限りません。Atlassianの機能変更・廃止一覧で、プラン依存の通知手段、廃止機能、再設定が必要な連携、更新が必要なAPIを確認してください。

また、アプリ内移行ツールが対応するのはAtlassian Cloudのみで、Jira Service Management Data Centerへの直接移行には対応しません。詳細は移行スケジュールガイドに記載されています。

軽量なOpsgenie代替が向くケース

すべてのチームがローテーション、エスカレーションツリー、インシデントタイムライン、分析を使っているわけではありません。小規模チームでは、実際の用途が次の3段階だけの場合があります。

監視ツールが重大イベントを検知する。
連携がイベントを転送する。
スマートフォンが確実に知らせ、担当者が対応する。

この使い方なら、プラットフォーム全体を置き換える必要はないかもしれません。EchobellはWebhookまたはメールを受け取り、通常、時間指定、着信形式のモバイル通知を送る配信レイヤーです。

Echobellは Opsgenieの完全互換製品ではありません。高度な当番表、エスカレーションポリシー、インシデント指揮、事後レポートは置き換えません。これらが必要なら、Jira Service Managementなどの総合的な製品を選んでください。

Echobellが適するのは、次のような場合です。

監視元が重大度をすでに判定している
少人数の固定チームがオンコールを担当する
監視は残し、Webhookからスマートフォンまでの配信だけを変えたい
critical、warning、infoで緊急度を分けたい
システム全体を変える前に通知経路だけを検証したい

詳しくはEchobellとOpsgenieの比較をご覧ください。

終了前にEchobellを並行テストする方法

1. 重要なアラート元を1つ選ぶ

責任者と通知量が明確な本番サービスから始め、一度にすべてを移行しないでください。

2. Echobellチャンネルを作成する

サービス用チャンネルを作り、対応者に共有します。購読者は各自の端末で通知方法を選べます。

3. 2つ目のWebhook送信先を追加する

Opsgenie経路を残したまま、監視元にEchobellのWebhookを追加します。

curl -X POST https://hook.echobell.one/t/<channel-token> \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Production API is down",
    "body": "Health check failed in us-east-1",
    "severity": "critical",
    "externalLink": "https://status.example.com/incidents/123"
  }'

実際のWebhook URLをソース管理にコミットしないでください。Webhookドキュメントで変数とテンプレートを確認できます。Webhook非対応の監視元ではメールトリガーを利用できます。

4. 緊急度を慎重に割り当てる

着信形式は即時対応が必要なイベントだけに使い、重要な警告は時間指定通知、情報イベントは通常通知にします。

5. 実際のオンコール期間で並行運用する

配信時間、内容の明確さ、誤検知、対応行動を比較します。障害だけでなく復旧通知もテストしてください。

6. 置き換えない要件を記録する

当番表、エスカレーション、確認、監査、レポートの担当を明確にします。必須要件は完全なインシデント管理システムに残します。

Opsgenie移行チェックリスト

すべての連携、Heartbeat、APIクライアント、メール連携を棚卸しする
必要な履歴データをエクスポートまたは移行する
スケジュール、エスカレーション、通知ルール、所有者を記録する
手動置換が必要な廃止機能と連携を特定する
opsgenie.com / opsgenie.net を呼ぶスクリプトを更新する
アラート、復旧、確認、時間外通知をテストする
少なくとも代表的なオンコール期間を並行運用する
対応者が新経路を確認してから旧経路を削除する