Vercel Flags：プラットフォームネイティブな機能フラグ

Vercel では、機能フラグが私たちのリリース手段です。v0 における新機能やモデルの更新から、フラグを切り替えポイントとした本番環境データベース移行のようなインフラストラクチャの変更まで、すべて機能フラグを通じて行われます。v0 チームだけでさえ、常に数百ものフラグを運用しています。 コードのマージは本番環境へのビルドを送りますが、ユーザーが変更内容を閲覧できるかどうかは機能フラグが制御します。フラグを使えば、自分のスケジュールでリリースでき、準備ができたらセグメントごとに公開し、ソースファイルに触れたり再デプロイしたりすることなく、フラグを切り替えるだけで即座にロールバックできます。 Vercel Flags はプラットフォームネイティブです：デフォルトはサーバーサイドで、ページパフォーマンスへの影響はゼロ、かつすでに使用しているフレームワークと直接統合されています。 Vercel Flags とは何か Vercel Flags を使えば、機能フラグを作成し、ユーザー属性やセグメント、環境に基づいてターゲティングルールを定義し、段階的なロールアウトを実行し、本番環境で問題が発生した場合はキルスイッチを即座に作動させることができます。 コード内では、Flags SDK（Next.js と SvelteKit に対してファーストクラスのアダプターを提供する、私たちが維持するオープンソースのプロバイダー非依存ライブラリ）を通じてフラグを読み取ります。他のフレームワークを使用している場合でも、組み込みの OpenFeature プロバイダーを使用して Vercel Flags を利用できます。 Vercel Flags のダッシュボードはプロジェクトやデプロイメントと並んで配置され、そこでフラグの作成と管理が行えます。 しかし、Vercel Flags が他のフラグサービスと異なる点は、フレームワークとの統合にあります。 なぜフレームワークネイティブが重要なのか 他のフラグプロバイダーは、自分でフレームワークに接続するための汎用 SDK と、フラグを管理するための別々のダッシュボードを提供します。Vercel Flags は Vercel プラットフォームに組み込まれているため、デプロイメントと同じダッシュボードでフラグを管理でき、コードはフレームワークネイティブの Flags SDK を通じてフラグを読み取ります。 サーバーサイド評価 フラグがクライアント側で評価されると、ユーザーはローダー、ちらつき、またはレイアウトシフトを目にします。ブラウザはフラグ値が返ってくるまで正しいビューをレンダリングできません。Flags SDK は代わりにサーバー側で評価を行います。Next.js React Server Components を使用すると、レンダリング時に await でフラグを読み取ることができます。正しいビューはサーバーサイドで決定され、ブラウザはそれを直接レンダリングします（別個のフラグリクエストは不要です）。この値は Vercel Flags から取得され、設定変更は数ミリ秒以内にすべてのリージョンに伝播します。 高度なケースでは、フラグを await する代わりにクライアントコンポーネントにプロミスとして渡すこともできます。これにより、ページはフラグ値が到着する前にレンダリングを開始でき、その間はコンポーネントでフォールバックを表示します。フラグは依然としてサーバー側で解決されるため、ブラウザ側でのリクエストは発生しません。 自動フラグ登録 Vercel Flags はフラグを自動的に登録します。コード内で定義してデプロイすると、ダッシュボードにドラフトとして表示されます。ターゲティングの構成や展開の準備ができたら、そのドラフトをプロモートしてください。コードからフラグを削除すると、ダッシュボードはそれを参照されていないものとしてマークし、常にアーカイブしても安全なものが何であるかがわかります。あなたが記述するフラグが管理対象となるフラグであり、手動で同期させる別の一覧は不要です。 Precompute（事前計算） 静的ページは、あなたやユーザーに最も近い CDN リージョンから配信されるため、高速かつ一貫性があります。しかし、フラグを追加するとページが動的になります。サーバーサイドでレンダリングすれば CDN 配信を失うか、クライアントサイドでフラグを取得すればレイアウトシフトが再び発生します。しかし、Flags SDK にはこれを解決するオプションの高度なパターンが付属しています。Precompute を使用すると、ビルド時にすべてのバリアントを構築し、CDN を経由して配布できます。また、Routing Middleware（Next.js の proxy.ts ファイル）が各ユーザーを適切なバリアントにルーティングします。すべてのページは静的のまま保たれ、レイアウトシフトなしで読み込まれます。 エージェントネイティブなフラグ管理 vercel flags CLI は、ターミナルから同じフラグ管理機能を公開するため、あなたとコーディングエージェントがフラグの作成、ターゲティングの設定、展開の実行、アーカイブを行うことができます。 ブラウザ上でのフラグの上書き Vercel Toolbar に組み込まれた Flags Explorer を使用すると、ブラウザセッション内の任意のフラグを上書きしてバリアントをテストできます。共有設定はそのまま維持され、再デプロイも不要です。 Vercel ships on Vercel Flags Vercel Flags は 2026 年 4 月に一般提供されましたが、私たちは内部ではすでに 1 年以上使用しています。v0 チームは、この仕組みが大規模でどのように機能するかを示す良い例であり、特定の時点で数百ものフラグがアクティブになっています。 チームがフラグの背後に配置するものの例をいくつか挙げます: 開発中の新機能 ユーザーやセグメントごとの AI モデルルーティング 運用上のキルスイッチ（緊急停止機能） データベースマイグレーションとプロバイダーの切り替え 早期顧客または内部チーム向けのベータアクセス v0 のような製品では、追加される遅延はエンドユーザー体験を低下させます。Vercel Flags はサーバーサイドで評価されるため、チームはクライアントサイドでのフラグ評価がもたらす追加の往復通信なしに機能フラグを活用できます。 すべての新機能がフラグの背後で構築されているため、開発者は未完成の作業をリリースすることなくメインブランチへ継続的にマージできます。長期存在するブランチはなく、解決が困難なマージ競合も発生しません。コードのデプロイと機能のリリースは、2 つの独立した意思決定となります。 リリースは制御された段階的進行を経て行われます。まず機能を構築した開発者が確認し、次に内部チームが確認します。その後、フラグは各 6 時間ごとにユーザーの 5%、10%、25%、50% と段階的に拡大し、最終的には全ユーザーに展開されます。どの段階で問題が発生しても、コード変更や再デプロイを行うことなく、チームは機能を即座に停止できます。 また、フラグは v0 の AI モデルトラフィックも制御しており、新しいモデルがリリースされた際に一度に切り替えるのではなく、徐々にシフトします。 v0 は、フラグを使用して本番環境のデータベースマイグレーションを実行したこともあります。古いデータベースと新しいデータベースを同期状態に保ちながら、フラグがどちらのデータベースを使用するかを制御しました。フラグを切り替えること自体が、移行そのものだったのです。ステージング環境で何度もリハーサルを行い、トラフィックを低下させることなく本番環境で実行しました。このフラグにより、リスクの高いインフラストラクチャの変更を、チームが練習し、スケジュールを立て、自信を持ってリリースできるものに転換することができました。 始めるには コードのリリースと機能の公開を別々の工程として扱うことで、プルリクエスト（PR）だけでは得られなかったレベルの信頼性をもって、物事をリリースし始められるようになります。 Vercel Flags はすべてのプランで利用可能です。vercel flags CLI を使用すれば、あなたやエージェントはどこからでもフラグの作成、確認、ロールアウト管理、アーカイブを行うことができます。 始めるには Vercel Flags のドキュメントをお読みいただくか、Flags SDK スキルに関するヘルプをエージェントに依頼してください。 もっと読む

Vercel Flags：プラットフォームネイティブな機能フラグ

背景や根拠まで確認しますか？

このニュースを、実務の判断につなげる

関連記事

調べる

選ぶ

サイト