先に結論
vercel flags split が入ったことで、AI機能や新UIの段階投入を dashboard の手作業ではなく CLI の運用へ寄せやすくなりました。
一番分かりやすい使いどころは、本番でいきなり全量公開したくない更新です。たとえば新しい要約モデル、agent 向けの新UI、checkout 改修を 5% だけ流し、残り 95% は既存 variant に残せます。
しかも Vercel の docs では、同じユーザーを同じ bucket に寄せる --by user.id、bucketing できない時の default variant、rollout との使い分けまで整理されています。だから今回の更新は、単なる CLI 追加ではなく、小さく出して確かめる手順を terminal 側へ寄せる更新 です。
何が公開されたのか
Vercel は 2026 年 5 月 21 日、Vercel CLI に vercel flags split を追加しました。
changelog で示された例はかなり実務的です。
vercel flags split redesigned-checkout \
--environment production \
--by user.id \
--weight off=95 \
--weight on=5これで production の中でも 95/5 の配分を作れます。新機能を全ユーザーへ一気に出すのではなく、少量トラフィックから本番で試す前提が最初から見えています。
Vercel Flags 自体は以前から dashboard 上で feature gate、A/B テスト、progressive rollout を扱えました。今回増えたのは、その split 操作を CLI から直接更新できる入口 です。
いちばん大きいのは、release 手順を runbook に寄せやすいこと
feature flag の運用で詰まりやすいのは、機能そのものより変更手順のばらつきです。
誰かが dashboard を開いて比率を変え、別の人が Slack に結果を書き、あとから理由が追いにくい。これでは段階投入を増やすほど運用が重くなります。
vercel flags split があると、少なくとも変更の入口を terminal 側へ寄せられます。revision message も一緒に残せるので、runbook や release 手順書と相性がいいです。
特に AI機能は、モデルの切り替え、新しい agent UI、生成結果の見せ方のように、deploy は済んでいるが全量公開はまだ怖い 更新が多いです。今回の CLI 追加は、この中間状態をかなり扱いやすくします。
set と split と rollout はどう違うか
ここを混ぜないほうが運用しやすいです。
set
set は、その環境で返す variant を 1 つに固定します。
preview では candidate、production では stable のように、環境ごとに明確に切りたい時に向いています。
split
split は、同じ環境の中でトラフィックを複数 variant に配分します。
つまり production を丸ごと candidate に変えるのではなく、production の中で 95/5、50/50 を作る操作です。A/B テストや canary release なら、今回の split が一番しっくりきます。
rollout
rollout は、時間経過に沿って比率を進める機能です。
5% を 6 時間、次に 10%、その次に 25% といった段階をあらかじめ決めたい時はこちらです。段階計画まで自動化したいなら rollout、まず固定配分で反応を見たいなら split と覚えると迷いません。
先に知っておきたい3つの注意点
1. --by user.id は dashboard 側の準備が前提
CLI docs では、--by には user.id のような entity.attribute 形式を使うと説明されています。
ただし、これをその場で自由に書けるわけではありません。先に dashboard 側で entity と attribute を定義しておく必要があります。ユーザー単位で安定して同じ variant を返したいなら、この準備を飛ばせません。
2. weight は割合そのものではなく比率
docs では、stable=1 と candidate=1 は stable=50 と candidate=50 と同じ配分になると案内されています。
つまり重要なのは絶対値ではなく比率です。0 を入れればその variant を split から外せますが、少なくとも 1 つは 0 より大きい weight が必要です。
3. non-boolean flag では --default-variant を忘れない
boolean flag では default fallback が false ですが、string、number、JSON flag では --default-variant を明示する必要があります。
これは bucketing に使う属性が取れなかった時の返し先です。AIモデル切り替えや pricing UI のように variant が 2 つ以上ある flag ほど、ここを曖昧にしないほうが安全です。
AI機能の段階投入でどう効くか
今回の更新が刺さるのは、AI機能を deploy と同時に全量公開したくないチームです。
たとえば、要約モデルを stable から candidate に一部だけ切り替えたい、agent 用の新しい画面を社外ユーザーの 5% だけ見せたい、pricing 説明の新UIを conversion を見ながら試したい、という場面です。
Vercel Flags の docs では、Flags は dashboard、targeting、experiments、Web Analytics と一体で扱える基盤として整理されています。つまり split は単独の CLI コマンドではなく、本番で少量トラフィックを流し、その影響を見る流れの一部 として使うのが自然です。
Vercel の AI 関連更新を追っているなら、モデル追加側の例として Vercel AI Gateway に Qwen 3.7 Max 追加 もつながります。モデル追加を知る記事と、どう安全に出すかの運用記事で役割が分かれます。
まず何から始めるべきか
最初の一歩はシンプルです。
- 本番で段階投入したい flag を 1 つ選ぶ
- dashboard 側で entity と attribute を確認する
vercel flags inspectで variant を見直すsplitで 95/5 など小さい配分を作る- 指標を見て、必要なら
rolloutへ進める
この順なら、いきなり大きい rollout を組まずに済みます。まず固定配分で反応を見るほうが、判断の切り分けがしやすいです。
向いているチームと、まだ急がなくていいチーム
向いているチーム
- Vercel で本番運用している
- AI機能や新UIを少量トラフィックから出したい
- release 手順を dashboard 作業ではなく CLI や runbook に寄せたい
- A/B テストや canary release を今後増やしたい
まだ急がなくていいチーム
- flag の entity 設計がまだない
- boolean の on/off だけで十分
- Vercel 専用の flag 運用に深く寄せる前に、OpenFeature などの標準を先に決めたい
まとめ
vercel flags split が入ったことで、Vercel Flags の段階投入はかなり現場寄りになりました。
- production の中でも 95/5 のような配分を CLI から作れる
--by user.idで安定した bucketing を前提にできるsetより柔らかく、rolloutより小さく始めやすい- AI機能や新UIの canary release を runbook に乗せやすい
要するに、今回の更新は「feature flag でできること」が増えたというより、feature flag を雑にせず運用へ組み込みやすくなった 更新です。Vercel で AI機能を本番に出しているなら、まず 1 本の flag から試す価値があります。