VoidZeroがViteネイティブのデプロイプラットフォーム「Void」を発表

ViteやRolldown、Vitest、Oxcなどのツールを開発するVoidZeroが、Webアプリケーションのデプロイプラットフォーム「Void」を発表した。2026年3月16日にアーリーアクセスの申し込みが始まった。

ここ1週間のVoidZeroの動き

VoidZeroはここ数日で立て続けに大きな発表をしている。3月13日にRust製バンドラRolldownを採用したVite 8.0、翌日にビルド・テスト・Lint・フォーマットを統合するVite+、そして今度はデプロイプラットフォームだ。

graph TD
    A["3/13 Vite 8.0<br/>Rolldownでビルド統一"] --> B["3/14 Vite+<br/>テスト・Lint・フォーマット統合"]
    B --> C["3/16 Void<br/>デプロイプラットフォーム"]
    C --> D["開発からデプロイまで<br/>Viteエコシステムで完結"]

webpack時代にはwebpack・Jest・ESLint・Prettier・Vercelと別々のツールを組み合わせていたのが、vp dev → vp build → vp test → void deployで一気通貫になる構想だ。VercelがNext.jsに対してやっていることを、Viteエコシステム全体でやろうとしている。

Voidの仕組み

VoidはCloudflareのサービス群の上に構築されている。

サービス	役割
Cloudflare Workers	バックエンドサーバー（エッジ実行）
D1	SQLiteベースの分散データベース
R2	オブジェクトストレージ
KV	キーバリューストア

ユーザーはこれらを直接意識しなくてよい。Cloudflareのアカウントすら不要で、デプロイ後の管理もVoidが担う。ソースコードをスキャンして必要なリソース（DB、KV、ストレージなど）を自動プロビジョニングする仕組みで、設定ファイルも不要。Viteプロジェクトにプラグインを追加してvoid deployを叩くだけだ。

void deploy

ローカル開発にはMiniflare（Workers互換のローカルシミュレータ）が使える。

V8 Isolatesの制約

技術的な基盤がCloudflare Workersである以上、実行環境はV8 Isolatesだ。Node.jsのフルランタイムとは違い、いくつかの制約がある。

制約	内容
CPU時間制限	無料枠で50ms、有料でも上限あり
CommonJS非対応	`require()`は使えない（ESMのみ）
Node.js API	`nodejs_compat`フラグで多くは使えるが、`fs`や`child_process`など一部は利用不可
ファイルシステム	ローカルファイルの読み書きは不可

SSG（静的サイト生成）でHTMLを事前に生成するパターンならこの制約は問題にならない。ビルドはNode.js上で完結し、生成されたHTMLをCDNに配信するだけだからだ。SSRで動的にNode.js APIを叩く構成だと移行のハードルが上がる。

vinextとの合流

先月取り上げたvinext（CloudflareがAIで1週間でNext.jsをVite上に再実装したもの）もvinext deployでCloudflare Workersにデプロイできる。vinextとVoidは別プロジェクトだが、「Vite + Cloudflare基盤」という組み合わせは同じだ。

graph LR
    A[Cloudflare] -->|vinext| B["Next.js APIを<br/>Vite上に再実装"]
    C[VoidZero] -->|Void| D["Viteネイティブの<br/>デプロイ基盤"]
    B --> E["Cloudflare Workers<br/>エッジ実行"]
    D --> E

vinextはVite 8のRolldown統合で本番ビルド4.4倍速を実現している。Voidも同じRolldownベースのビルドパイプラインを使うはずだ。Cloudflare側からはvinext、Vite側からはVoidと、異なる方向からCloudflare + Viteの組み合わせが攻められている。

これが合流するとどうなるか。Next.jsユーザーはvinext経由で、それ以外のViteベースフレームワーク（Astro、Nuxt、SvelteKitなど）のユーザーはVoid経由で、全員がCloudflareのエッジに乗る世界だ。

このブログ（Astro + Vercel）はVoidに移行できるか

ここからは自分ごとの話。このブログはAstro 5系で構築し、Vercelに静的サイトとしてデプロイしている。VoidやCloudflareに移行できるのか、移行したら何が変わるのかを調べた。

現在の構成

実際のastro.config.mjsとpackage.jsonから、Vercelに依存している箇所を洗い出す。

Vercel固有の依存。

依存	用途
`@astrojs/vercel`	Astroアダプタ（`webAnalytics: { enabled: true }`で設定）
`@vercel/speed-insights`	パフォーマンス計測
`vercel.json`	リダイレクト設定（旧URL → 新URLの301リダイレクト5件）

プラットフォーム非依存の依存（移行に影響なし）。

依存	用途
`astro-pagefind`	全文検索（ビルド時にインデックス生成、静的ファイルとして配信）
`@astrojs/partytown`	サードパーティスクリプトをWeb Workerに分離
`rehype-katex` / `remark-math`	数式レンダリング
`rehype-external-links`	外部リンクに`target="_blank"`付与
カスタムrehypeプラグイン	YouTube埋め込み、動画埋め込みの遅延読み込み
`sharp`	画像処理（ビルド時のみ）
`better-sqlite3`	Labツール用（ビルド時のみ）

output: 'static'の完全静的サイトなので、ランタイムでNode.js APIを使う箇所はゼロ。V8 Isolatesの制約は一切関係ない。

Cloudflare Pagesへの移行（Voidを使わない場合）

Astroは公式で@astrojs/cloudflareアダプタを提供しているが、output: 'static'ならアダプタすら不要だ。静的サイトはそのままCloudflare Pagesにデプロイできる。

具体的な変更箇所はアダプタの削除だけだ。

import vercel from '@astrojs/vercel';

export default defineConfig({
  adapter: vercel({
    webAnalytics: { enabled: true },
  }),
  output: 'static',
  // ...
});

// adapter行を削除するだけ
export default defineConfig({
  output: 'static',
  // ...
});

移行チェックリスト。

項目	作業内容	難易度
アダプタ	`@astrojs/vercel`を削除	1行消すだけ
Web Analytics	Vercel Web Analytics → Cloudflare Web Analytics（JSスニペット差し替え）	簡単
Speed Insights	`@vercel/speed-insights`を削除（Cloudflareには同等機能なし）	削除のみ
リダイレクト	`vercel.json` → `public/_redirects`ファイルに変換	5件書き換え
DNS	Vercelのネームサーバー → CloudflareのDNS	ドメイン設定変更
ビルド設定	Cloudflare Pagesダッシュボードでフレームワーク「Astro」を選択	自動設定

_redirectsファイルへの変換はこうなる:

/script/k-on-tape /lab/generator-kontape 301
/dojin /doujin 301
/dojin/* /doujin/:splat 301
/ksbiz/generator/kontape /lab/generator-kontape 301
/ksbiz/generator/kontape/ /lab/generator-kontape 301

技術的にはかなり簡単だ。以前VercelのデプロイでハマったときはGitのemail設定という予想外の原因だったが、Cloudflare Pagesへの移行はそういう落とし穴が少ない。静的サイトのCDN配信は単純な仕組みだからだ。

Voidへの移行

VoidはViteベースのメタフレームワークをサポート対象としているが、Astroが明示的にサポートされているかはアーリーアクセス段階で不明だ。AstroはViteを内部で使っているので理論的には対象に入るが、動作確認はできていない。

仮にAstroがサポートされても、静的サイトの場合、Voidの売りである「自動プロビジョニング」（DB、KV、認証など）のメリットはほぼない。Voidが本領を発揮するのはフルスタックアプリケーションで、静的サイトにはオーバースペックだ。

移行したら何が変わるか

コスト

項目	Vercel（Hobby）	Cloudflare Pages（Free）
リクエスト数	無制限	1日10万（月300万相当）
帯域	100GB/月	無制限
エグレス料金	100GB超で課金	なし
ビルド	6,000分/月	500回/月

個人ブログの規模ではどちらも無料枠で収まる。差が出るのはバズったときだ。仮に1記事が大きく拡散されて月100GBを超えた場合、Vercelでは課金が発生するがCloudflareでは帯域無制限なので影響がない。逆にCloudflareはビルド回数500回/月の制限があるので、1日に何度もデプロイするスタイルだと上限に達する可能性がある（このブログの場合、月50回程度なので問題ない）。

パフォーマンス

静的サイトのCDN配信なのでどちらも十分速い。Cloudflareは330以上のエッジロケーションを持ち、Vercelも主要リージョンにエッジがある。日本国内のアクセスが中心ならほぼ差はない。

ただし、このブログはCLAUDE.mdに書いてある通り画像の帯域が将来的な課題で、エスカレーションパスとして「Cloudflare CDNへの切り替え」が挙がっている。Cloudflare Pagesに移行すれば、CDNがCloudflare自体になるので画像配信の最適化がシームレスになる。Vercelのままだと別途Cloudflare CDNを前段に置く構成になるが、Cloudflare Pagesならその必要がない。

Vercelはgit pushでの自動デプロイ、プレビューデプロイ、Web Analyticsが標準装備で、設定なしで使える。Cloudflare Pagesも同等の機能はあるが、Vercelほどの洗練さはない。特にVercel Web Analyticsは軽量で使いやすい。

以前Cloudflare Workersでリアルタイム分析基盤を構築した経験があるので、Cloudflareの管理画面には慣れている。とはいえVercelのダッシュボードのほうが圧倒的にシンプルだ。

今すぐ移行する理由はない

このブログの場合、Vercelで何も困っていない。移行自体は簡単だが、得られるメリットがコスト面（帯域制限の緩さ）と将来の画像配信最適化くらいで、移行コストに見合わない。

移行が検討に値するのは以下のケースだ。

Vercelの帯域100GB/月を超えるトラフィックが発生した場合
画像帯域が問題になり、Cloudflare CDNへの移行が必要になった場合（Pagesにすればそのまま解決）
SSRに切り替えてCloudflare Workersのエッジ実行を活用したい場合
D1やKVなどCloudflare固有のサービスを使いたい機能が出てきた場合

Voidはまだアーリーアクセス

アーリーアクセス段階で、本番利用に耐えるかどうかはまだ不明だ。価格体系も公開されていない。Cloudflare Workers（Workerあたり月$5〜）を基盤にしている以上、完全無料は難しいだろうが、VoidZeroがどの程度の無料枠を提供するかは今後の情報を待つ必要がある。

VoidZeroはa16zなどから累計 $17.1M（シード$ 4.6M + シリーズA$12.5M）を調達しており、Viteエコシステム全体を商業的に持続可能な形にすることが目標の一つだ。Voidがその収益柱になる可能性はある。

Voidは「Viteを使っていれば何も考えずにデプロイできる」体験を目指している。フロントエンドのビルドツールからデプロイ基盤まで一社が垂直統合する流れが、Vercel/Next.jsに続いてVoidZero/Viteでも始まった。ただ、静的サイトを運用している身としては、デプロイプラットフォームの違いよりもCDNの帯域制限やエッジロケーションのほうがよほど実務的な関心事だったりする。