先に結論
Vercel の今回の更新で変わったのは、anomaly alert の初動確認を dashboard から terminal へ寄せやすくなったことです。
vercel alerts 自体は alert 一覧を見るコマンドですが、--ai が入ったことで alert title、resolved time、summary、key findings まで CLI で追いやすくなりました。運用チームは dashboard を開く前に、まず terminal で状況を切れます。
特に効くのは、Vercel 上で usage anomaly や error anomaly を見ながら、Slack 通知、bot、runbook につなぎたいチームです。--format json もあるので、一覧取得で終わらず自動化の入口にしやすくなりました。
ただし、ここで見落としやすい前提があります。AI investigation を前提にするなら Observability Plus と Agent Investigation の有効化確認が先です。CLI が便利になっても、運用コストの前提まで消えたわけではありません。
何が変わったのか
2026年5月21日の Vercel changelog では、vercel alerts で anomaly alert を CLI から直接確認できるようになったと案内されました。
一覧取得だけなら、linked project、特定 project、team-wide の alert を terminal から見られます。ここに --ai を付けると、AI investigation の結果が alert ごとに並びます。
CLI docs で確認できる変化点は次の通りです。
- デフォルトは linked project の直近24時間
--projectで特定 project を指定できる--allで team-wide scope に切り替えられる--type、--since、--until、--limitで anomaly を絞り込める--aiで investigation の要点を表示できる--format jsonで bot や script 向けに出力できる
要するに、今回の更新は「alert を見る場所」が dashboard だけではなくなった、という意味があります。Vercel を terminal 中心で運用しているチームほど差が出ます。
まず押さえるべき前提
一番大事なのは、vercel alerts と Agent Investigation を同じものとして扱わないことです。
vercel alerts は CLI から alert を確認する入口です。一方の Agent Investigation は、alert 発火時に logs と metrics を掘って原因候補を出す仕組みです。
Agent Investigation docs では、利用前提として次の2点が明記されています。
- Observability Plus の契約
- 追加 investigation を回すための credits
Observability Plus には 1 billing cycle あたり 10 investigations が含まれます。ただし、それを超える分は固定 0.30 USD に加えて、基盤モデル側の token cost がかかります。
つまり、CLI 導入そのものは軽くても、AI investigation を自動で回す運用は費用ルールまで決めてから入れるべきです。
vercel alerts でできること
linked project を terminal から見る
最初の一歩はシンプルです。vercel alerts は linked project の直近24時間を標準で出します。
dashboard を開く前に anomaly の有無だけ見たいなら、このデフォルト動作で十分です。夜間対応やデプロイ直後の確認にも向いています。
特定 project と team-wide を切り替える
複数 project を持つチームなら、scope 切り替えが実用的です。
--project は linked project を上書きします。特定の本番アプリだけ見たい時に使います。
--all は team-wide の alert をまとめて見るオプションです。Platform チームや SRE が横断で triage するならこちらが効きます。
この2つは併用できません。project 単位の確認と team-wide 監視は、runbook を分けておく方が事故が少ないです。
type、time range、limit で絞る
alert が多いチームでは、一覧だけだと実務で使いにくいです。そこを詰めるのが --type、--since、--until、--limit です。
たとえば usage anomaly だけ見たいなら --type usage_anomaly が使えます。時間帯を incident 直前に寄せたいなら ISO 8601 の --since、--until で切れます。
一覧を bot に渡す前段なら --limit も効きます。最初から全部を流すより、runbook で使う件数に絞った方が扱いやすいです。
--ai は何を変えるのか
今回の主役は --ai です。
CLI docs では、--ai を付けると alert title、resolved time、summary、key findings を出せると案内されています。changelog でも、agent と人が terminal を離れずに alert へ対応できる点が押し出されています。
ここでの価値は、ダッシュボードの完全代替ではありません。初動で「何が起きたか」を短く掴めることです。
特に次の流れと相性がいいです。
- alert 通知を受ける
- terminal で
vercel alerts --type usage_anomaly --aiを実行する - summary と key findings を見る
- 詳細調査が必要なら dashboard へ移る
この順番にすると、調査の最初の一手がかなり速くなります。
--format json が効く場面
もう一つ見逃せないのが --format json です。
CLI docs では、JSON 出力時に groups 配列で alert group payload を返すと説明されています。ここがあるので、vercel alerts は単なる閲覧コマンドで終わりません。
運用で使いやすいのは次のような場面です。
- Slack や Discord へ anomaly summary を流す
- nightly triage の前処理に使う
- internal bot から
usage_anomalyだけ抜き出す - runbook の中で alert の一次確認を自動化する
Vercel と agent workflow をつなぎたいなら、この JSON 出力はかなり大きいです。Vercel 文脈を coding agent 側へ渡す考え方は Vercel plugin vs MCPサーバー vs 素のcoding agent ともつながります。
誰に関係ある更新か
この更新は、Vercel を使っている全員に同じ強さで効くわけではありません。
一番恩恵が大きいのは、dashboard 常駐より terminal 中心で動くチームです。SRE、platform、DevOps、運用自動化を触る開発者には分かりやすく効きます。
逆に、alert の設定自体がまだ固まっていないチームだと、CLI が増えても効果は限定的です。まず alert 設計と権限設計を整えた方が早いです。
Agent Investigation の扱いも、observability 全体の設計に寄ります。Vercel だけで完結するのか、組織横断で New Relic や Datadog まで含めるのかは、AI agent observability 比較 も合わせて見ると判断しやすくなります。
今やるべきこと
今すぐやる価値があるのは3つです。
1. runbook に CLI 初動を足す
まずは vercel alerts を runbook に追加し、linked project と team-wide のどちらを見るかを決めます。
2. --ai を使う前提条件を確認する
Observability Plus、Agent Investigation の有効化、credits の扱いをチーム設定と予算ルールで確認します。ここが曖昧なまま自動 investigation を入れると、運用だけ増えて後で揉めます。
3. JSON 出力の接続先を決める
--format json を Slack、Discord、社内 bot のどこへ流すかを決めると、今回の更新の価値が出ます。単発コマンドで終わらせるより、通知導線までつないだ方が活きます。
まとめ
vercel alerts --ai の価値は、AI がすごいことより anomaly alert の初動を terminal に寄せられること にあります。
特定 project、team-wide、type filter、JSON 出力まで揃ったので、Vercel を incident runbook や bot workflow に組み込みやすくなりました。
その一方で、Agent Investigation には Observability Plus、included investigations、追加課金という前提があります。便利になった入口と、コストが乗る調査部分は分けて設計するのが安全です。