Vercel Observability にカスタムモニターが追加。クエリ結果からアラートを作る方法と使い分け
2026年10月26日、Vercel が Observability のクエリ結果をもとに通知を出す「カスタムモニター」を公開しました。これまでの組み込みアラート (エラー異常・使用量異常) では拾えなかった指標、たとえば AI Gateway のコストや Core Web Vitals、Workflow と外部 API の失敗率、Vercel Sandbox の CPU 時間などを、自分で定義した条件で監視できます。利用条件は Pro / Enterprise プラン + Observability Plus で、料金はスキャンしたデータ 1GB あたり $0.0035。従来の組み込みアラートは引き続き Observability Plus に含まれます。
カスタムモニターで設定できること
1 つのモニターが追うのは、単一のメトリクス (レスポンスタイムなど) か、2 つのメトリクスの比率 (エラー数 ÷ 総リクエスト数など) のいずれかです。公式のスクリーンショットでも、HTTP 500 を総リクエストに対する割合として監視する例が示されています。
検知方法は 2 種類から選びます。固定しきい値は「5 分間のエラーが 20 件を超えたら」のように基準が明確な指標向け。統計的な異常検知は、絶対値の基準を決めにくい指標や、トラフィック量によって正常値が動く指標向けです。加えて、検知ウィンドウ (評価する時間幅)、フィルタ、グルーピングを設定できます。グルーピングを使えば、ルートやリージョンごとに個別評価でき、全体では埋もれてしまう特定経路の劣化を検知できます。
組み込みアラートとの使い分け
組み込みアラートは、Vercel 側が定義した検知ロジックで動きます。エラー異常はルート単位の 5 分間のエラー数を直近のベースラインと比較し、使用量異常は 5 分間の使用量が 24 時間平均 + 4 標準偏差を超えた場合に発火します。いずれも Vercel が定めた最小活動量のしきい値があり、低トラフィックによるノイズを抑える仕組みです。重大度 (Low / Medium / High) も z スコアやエラー率の影響度から自動算出されます。
つまり組み込みアラートは「設定不要で主要な障害を拾う」ための仕組みで、チューニングの自由度は高くありません。一方カスタムモニターは、監視したい指標・基準・粒度をこちらで決めます。実務上の判断としては、5xx の急増や関数の使用量スパイクのような汎用的な異常は組み込みに任せ、カスタムモニターはサービス固有の指標 (決済 API の失敗率、LLM の呼び出しコスト、特定ルートの LCP など) に絞るのが無駄が少ない設計です。
作成手順はダッシュボードと CLI の 2 通り
ダッシュボードからは、(1) Observability でチャートのクエリを開いてそこからモニター化する、(2) プリセットから始める、(3) チームの Settings > Alerts から作る、の 3 つの入口があります。まず Query タブで監視したい指標を可視化し、ノイズが出ない条件を目視で確かめてからモニターに落とすのが安全です。
CLI では JSON ファイルにモニターを定義し、vercel monitors add --project my-app --body ./monitor.json で作成します。スキーマと検証済みのサンプルは vercel monitors schema --type custom で確認でき、JSON を書く前に vercel metrics schema <メトリクス名> で現在のメトリクス名・集計方法・ディメンションを取得しておくと、存在しないフィールドを指定する失敗を避けられます。body の構造は type、name、severity、評価条件の evaluation (ウィンドウとクエリ)、発火条件の trigger (しきい値や演算子) という形です。
CLI 運用で押さえておきたい制約が 2 点あります。カスタムモニターは --project が必須で、組み込みモニターのように --all でチーム全体へ一括適用はできません。また vercel monitors は旧 vercel alerts rules を置き換えたコマンドで、旧形式の customAlert や queryJsonString を含む body は受け付けられません。過去にスクリプト化していた場合は、evaluation.query と trigger の新しい形へ書き換えが必要です。
定義をファイルで管理できる以上、モニターはリポジトリに置いてレビュー対象にするのが実用的です。アラートのしきい値変更は障害対応の質に直結するため、誰がいつ緩めたのかを追える状態にしておく価値があります。
通知先と、Vercel Agent 向けのコンテキスト
通知はメール、Slack、Vercel Inbox、プッシュ通知、チームレベルの Webhook から選べます。Slack はチャンネルごとにルール単位で購読でき、Webhook はチーム設定側で管理する仕組みです。既存のインシデント管理ツールへつなぐなら Webhook が入口になります。
特徴的なのは、アラート調査時に Vercel Agent が参照するコンテキストをモニターに付けられる点です。「この指標が上がるときは主にどこを疑うべきか」といった運用上の前提は、通常ドキュメントやチームの暗黙知に埋もれます。それをモニター定義に併記できるのは、一次調査を自動化する前提での設計と言えます。
コストは「スキャンしたデータ量」で決まる
カスタムモニターの課金はスキャンデータ 1GB あたり $0.0035 です。Observability Plus 自体はイベント課金 (100 万イベントあたり $1.20) で基本料金は撤廃済みのため、モニター分は別軸の従量課金が上乗せされる形になります。
単価は小さいものの、評価は検知ウィンドウごとに繰り返し走ります。対象期間が長いモニターやフィルタの広いモニターを大量に作れば、スキャン量はその分積み上がると考えるのが自然です (公式が公開しているのは GB 単価のみで、具体的な試算式は示されていません)。最初から網羅を狙わず、対応アクションが決まっている指標だけをモニター化し、請求額を見ながら広げる進め方が無難です。
最初に作るなら何から手をつけるか
優先度は「鳴ったときに誰かが必ず動く指標か」で決めるのが現実的です。具体的には次の順序を推奨します。
- 収益や主要機能に直結するルート (決済・ログイン・検索 API) のエラー率を、総リクエスト数との比率で監視する
- LLM を使うアプリなら AI Gateway のコストを固定しきい値で監視し、予算超過を早期に検知する
- 外部 API や Workflow の失敗率を、依存先ごとにグルーピングして監視する
- レイテンシや Core Web Vitals は基準値が決めにくいため、異常検知モードから始める
なお、Vercel の Observability はプラットフォーム上の挙動を対象とします。データベースや外部サービスまで含めた全体監視が必要なら、既存の APM と併用する前提で、Vercel 側はエッジ・関数・ゲートウェイの層に絞って設計するほうが重複が少なくなります。
まずは Observability の Query タブで監視したい指標を可視化し、過去データでノイズが出ない条件を確認してから、vercel monitors schema --type custom で JSON 化して 1 本だけ作ってみるのが現実的な第一歩です。通知先とエスカレーション先を先に決めておけば、鳴りっぱなしで無視されるアラートを増やさずに済みます。
