アラート

アラートは現在ベータ版です。

アラートを使用すると、体験の重要なパフォーマンスメトリックを積極的に監視し、定義した閾値を超えたときにリアルタイム通知を受け取ることができます。ダッシュボードを手動で確認する代わりに、クラッシュ率の急増やメモリ使用量の過剰、フレームレートの低下などのメトリックに基づいて自動的に通知するアラートを設定できます。

たとえば、次のワークフローはパフォーマンスのリグレッションをつかむためのアラートの典型的な使い方です。

アラートを作成 - 「クライアントクラッシュ率が5%を超えています」というアラートを5分間の期間で、重大度クリティカルで設定します。
Webhookを追加 - チームのPagerDutyまたはDiscordのWebhookに接続します。
更新をプッシュ - 新しいバージョンをデプロイします。
アラートを受信 - クラッシュ率が5%を超えて5分間連続した場合、あなたのチームはメトリック値とダッシュボードへのリンクを即座に通知されます。
調査し修正 - Webhookペイロード内のダッシュボードリンクをクリックして、パフォーマンスチャートを表示し、問題を診断します。

1つの体験あたり最大20件のアラートを作成できます。アラートを作成するには、アラートの作成と構成の権限が必要です。

アラートページを表示

アラートページにアクセスするには、体験の所有者であるか、すべての分析を表示する権限を持っている必要があります。

Creator Hubであなたの体験を選択します。
構成の下にあるアラートを選択します。

構成タブでは、アラートルールを作成および管理できます。分析ページを使用して、アラートの履歴、アクティブなアラート、およびイベントを確認します。

権限

アラートには、異なるアクションに対して特定の権限が必要です：

アクション	必要な権限
アラートの作成、編集、削除、または切り替え	アラートの作成と構成
アラート分析ページの表示	すべての分析を表示
体験レベルのWebhookの作成	Webhookのリスト作成、更新、削除

アラートを作成

アラートを作成するには、アラート構成ページで作成をクリックします。

アラートフィールド

各アラートには、以下の設定オプションがあります。

フィールド	説明
名前	通知、注釈、ダッシュボードに表示されるアラートの一意の名前。
説明	追加のコンテキストを提供するためのオプションの説明。
メトリック	監視する対象メトリック。
時間の粒度	メトリックが評価される頻度（分、半時間、時間、または日）。
トリガー条件	アラートが発火する条件（例：値 > 500）。
フィルター	メトリックを絞り込むオプションのフィルター、たとえば場所のバージョン、オペレーティングシステム、またはプラットフォーム。ダッシュボードで利用可能なすべてのフィルターがサポートされています。
内訳	条件が各セグメントごとに満たされているかを確認するためのオプションの内訳。
持続時間	条件がアラートが発火する前に連続して満たされなければならない回数（1-10）。
重大度	重大度レベル（クリティカル、中、または低）。
配信チャネル	アラート通知を送信する場所。 Webhook配信を参照してください。

サポートされているメトリック

アラートは、パフォーマンスダッシュボードで利用可能なすべてのパフォーマンスメトリックをサポートしています。

クライアントフレームレート
クライアントクラッシュ率
クライアントメモリ使用量（GB）
クライアントメモリ使用量の割合
意図せぬメモリ不足での終了
サーバーCPU時間
サーバーフレームレート
サーバーメモリ使用量（GB）
同時ユーザー数
セッション時間

トリガー条件

次の2つのトリガー条件タイプのいずれかを設定できます：

メトリック値 - メトリックが静的な数値閾値を超えたときに発火します。値はメトリックと同じ単位（パーセンテージ、ミリ秒、MBなど）を使用します。
期間間の変化 - メトリックの変化率がパーセンテージの閾値を超えたときに発火します。
- 週次 - 先週の同じ時間とのパーセント変化を確認します（例：今週の金曜日の午後5時と先週の金曜日の午後5時）。
- 日次 - 昨日の同じ時間とのパーセント変化を確認します（例：今日の午前9時と昨日の午前9時）。
- 時間毎 - 最も最近の時間と前の時間とのパーセント変化を確認します（例：午前9時05分と午前8時05分）。

たとえば、「クライアントクラッシュ率が5%を超えている」や「時間あたりの変化が50%を超えている」のようにメトリック値条件や期間間の条件を設定できます。

持続時間

持続時間の設定は、トリガー条件がアラートが発火する前に連続して満たされなければならない期間を制御します。これにより瞬間的な変動からのノイズを減らします。1を選択した場合、条件を満たすデータポイントが1つでもあるとアラートが発火します。5を選択した場合、5つの連続したデータポイントが条件を満たさなければなりません。分粒度のアラートでは、最小の持続時間は5分で、ノイズを減らします。

重大度レベル

各アラートには、アラートメッセージに含まれ、異なる色で表示される重大度レベルがあります。

重大度	使用例
クリティカル	直ちに対応が必要な緊急の問題、たとえばクラッシュ率の急増。
中	すぐに調査すべき重要なリグレッション。
低	追跡する価値のある小さな変更ですが、すぐに対処する必要はない。

Webhook配信

アラートは体験レベルのWebhookを介して届きます。アラートが発火または復帰すると、設定されたWebhook URLにHTTP POSTリクエストがJSONペイロードとともに送信されます。メッセージ自体もJSONであり、AlertMessageフィールド内に単一の文字列としてラップされています。


{
  "NotificationId": "11111abc-111a-1a2a-ab1a-abc1a1a111a1",
  "EventType": "AnalyticsAlert",
  "EventTime": "2026-06-15T22:05:10.8590762Z",
  "EventPayload": {
    "TargetType": "Universe",
    "TargetId": "1234567890",
    "AlertMessage": "{\n  \"summary\": \"[♟️] ゲームが回復しました\",\n  \"metric\": \"PeakConcurrentPlayers\",\n  \"universe_id\": \"1234567890\",\n  \"evaluation_time_utc\": \"2026-06-15T22:04:47Z\",\n  \"alert_history\": \"https://create.roblox.com/dashboard/creations/experiences/1234567890/alerts?tab=AlertConfiguration-Analytics&utm_medium=webhook&utm_campaign=alert_resolved\"\n}"
  }
}

AlertMessage.summaryフィールドには、アラートがトリガーされたときには「発火」、メトリックが正常な状態に戻ったときには「回復」のいずれかの単語が含まれています。

Webhookを使用して、PagerDutyやSlackなどの外部ツールと統合して、チーム全体の可視性を向上させることができます。

Webhookの設定

Creator Hubであなたの体験を選択します。

構成の下にあるWebhooksを選択し、Webhookを追加をクリックします。

Webhook URLは、あなたのプロバイダーから取得します。たとえば、SlackのURLは次のようになります：


https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX

Webhook URLと名前を入力します。
(オプション) リクエストがRobloxから来たことを確認するための秘密を含めることができます。
(オプション) テストレスポンスボタンを使用して、サービスがサンプルリクエストを受け取れるかどうかを確認します。
変更を保存をクリックします。
アラートを作成または編集するときに、配信チャネルフィールドの下にあるWebhookを選択します。

体験レベルのWebhookを作成するには、Webhookのリスト作成、更新、削除の権限が必要です。

アラートを監視

アラートページの分析タブは、アラートの履歴と現在のステータスを集中して表示します：

トリガーされたイベント - 時間にわたるアラートの発火数を示すグラフ。時間範囲を調整したり、アラート名で検索したり、重大度でフィルタリングできます。
アクティブなアラート - 現在アクティブ（発火中）のアラートを示すテーブル。
履歴 - 選択した時間範囲内のすべてのアラートイベントの時系列ログ。

持続時間で偽の警報を防ぐ - セッション時間のような非常に変動の大きいメトリックに対して、持続時間を1に設定しないでください。プレイヤーが突然参加したり、アセットを同時に読み込むと、一時的な急増が発生する可能性があります。持続時間を5に設定することで、問題が持続しているときのみアラートが発火するようにします。
セグメント内訳を効率的に使用 - Android、iOS、PCの各プラットフォームに対して個別のアラートを複数作成するのではなく、1つのアラートを作成し、内訳機能を使用できます。アラートは各プラットフォームを別々に評価し、Webhookペイロードで問題が発生している場所を特定します。
まずベースラインを確立する - 閾値を設定する前に、過去7日から14日の既存の分析チャートを確認します。通常のクラッシュ率が約1.2%である場合、アラート閾値を2.5%または3%に設定することを検討してください。メトリックに自然な変動の余地を与えることで、偽の警報を防ぎます。
説明的で構造的な名前を使用 - アラート名は直接Webhookペイロードや注釈に挿入されるため、メトリック - コンテキスト（例：高いクライアントクラッシュ率 - モバイル）のような明確なフォーミュラを使用することで、チームが一目で問題をトリアージしやすくなります。