リアルタイムプレビュー:VULKがアプリをライブでレンダリングする仕組み

2026年7月18日更新——現在のアーキテクチャを軸に書き直し:Firecracker microVM、Flutterビルドサービス、そして2026年7月にライブになったPHP + Pythonランタイム。

VULKはアプリをどうやってライブでレンダリングする?

完全な答え:AIが生成ファイルをストリーミングすると同時に、VULKはそれを専用プレビューサービスにプッシュし、あなたのアプリをFirecracker microVM内で実行します——独自のカーネル、ファイルシステム、ネットワークを持つ本物の分離された仮想マシンで、ウォームプールから引き当てられるため数秒でアタッチされます。microVM内では本物のVite開発サーバーがホットモジュールリプレースメント付きでReactアプリを実行し、動いているアプリはエディタのiframeにプロキシされます。Flutterアプリは別のbuild-then-serveパイプライン(flutter build web、ビルドごとに約20〜60秒)を通り、2026年7月からはPHPとPythonのアプリも専用microVMランタイムでライブに動きます。

これはシミュレーションでもブラウザサンドボックスでもありません:本物のサーバーインフラで動くあなたの実際のアプリケーションが、画面にストリーミングされているのです。この速度こそがプラットフォームを定義する数字を可能にします——中央値のビルダーはサインアップから動く生成アプリまで47秒で到達します(VULKプラットフォームデータ、2026年7月、N = 11,355プロジェクト)。

なぜプレビューがAIアプリ生成の難問なのか?

AIジェネレーターがコードを生成したら、結果をすぐに見る必要があります。ほとんどのプラットフォームは2つの方法のどちらかを取ります:静的スクリーンショットか、WebContainersやSandpackのようなツールでブラウザ内コンパイルか。どちらにも大きな限界があります。

静的スクリーンショットは明らかに不十分——操作もスクロールもボタンクリックも機能テストもできません。ブラウザ内コンパイルはましですが独自の問題を抱えます:ツールチェーンの大きなダウンロード、限定的なNode.js APIサポート、バックエンド実行不可、遅いコールドコンパイル、重いメモリ使用、多くのnpmパッケージを壊すサンドボックス制限。

VULKは第三の道を取ります:分離されたmicroVM上のサーバーサイドプレビューです。運用コストは高い——ユーザーのブラウザではなく本物のインフラが必要——ですが、「プレビューが動く」が確実に「アプリが動く」を意味する唯一のアプローチです。

生成から目に見えるアプリまでの間に何が起こる?

ステップ1:コード生成。 AIモデルがレスポンスをストリーミングし、vulkAction XMLタグに包まれたファイルを生成。各ファイルが完成するたびにVULKがパスと内容を抽出します。

ステップ2:microVMの割り当て。 ファイルはプレビューサービス(webapp.vulk.dev)に送られ、事前起動済みウォームプールのFirecracker microVMにプロジェクトがアタッチされます。各microVMは正真正銘の仮想マシン——共有コンテナではなくハードウェアレベルの分離——で、プロジェクトのニーズに合ったrootfsイメージ(基本ウェブイメージ、3D対応イメージ、重い依存関係をプリインストールしたフルイメージ)を持ちます。

ステップ3:依存関係とサーバー起動。 VM内で依存関係は事前キャッシュ済みのnode_modulesレイヤーに対してインストールされます——コールドプレビューで最も遅いステップが、一般的なスタックでは数秒に短縮。React + ViteプロジェクトではVite開発サーバーが、他のスタックでは適切なランタイムが起動します。

ステップ4:iframeレンダリング。 動いているアプリケーションは一意のURLを通じてプロキシされ、VULKエディタのiframeに表示されます。部分的なレンダリングではなく、完全に動くアプリケーションが手に入ります。

ステップ5:編集時のホットリロード。 フォローアッププロンプトがファイルを変更すると、変更されたファイルだけがVMにプッシュされます。Viteのホットモジュールリプレースメントがフルリロードなしにiframeを更新——変更は1秒以内に見え、通常コンポーネントの状態も保持されます。

ステップ6:サスペンドとレジューム。 アイドル状態のプレビューはリソース解放のためサスペンドされ、必要に応じて再開されます——プロジェクトに戻ってもゼロから再構築にはなりません。

各プラットフォームは実際どうプレビューされる?

スタックごとに本当に異なるパイプラインを通ります——プラットフォーム別のマップがこちら:

React Native + ExpoはExpo GoでiOSとAndroidのプレビューとテストを行います。 Shopifyのテーマとアプリは、標準ツールを使ってShopify環境で動作します。

なぜサーバーサイドがブラウザ内コンパイルに勝つ?

バックエンドコードが実際に動く。 VULK生成のフルスタックアプリは本物のAPIとデータベースアクセスを含みます——そして全生成アプリの62%がSQLスキーマを含みます(VULKプラットフォームデータ、2026年7月)。ブラウザサンドボックスはそのバックエンドを実行できず、モックするか省略します。VULKのプレビューでは全フローをテストできます:登録、ログイン、データ作成、APIコール。

サンドボックスの制限なし。 ブラウザベースのツールはService Worker内でNode.jsをエミュレートします;一部のnpmパッケージは静かに失敗し、ネイティブモジュールは動かず、ファイルシステムアクセスは制限されます。microVMは本物のLinux環境——それらの制限は存在しません。

デバイス間で一貫。 ビルドはサーバーで実行されるため、格安ChromebookとMacBook Proが同一のプレビュー性能を得ます——そしてブラウザ内コンパイルが苦痛から不可能まであるモバイルブラウザでも問題なく動きます。

ハードウェアレベルの分離。 Firecracker microVMは仮想化レイヤーで分離します——AWS Lambdaと同じ技術です。あるユーザーの無限ループが別のユーザーのプレビューに触れることはなく、クラッシュしたVMは自動的にリサイクルされます。

忠実なレンダリング。 iframeは本物のサーバーが配信する本物のURLから読み込まれます——プレビューで見えるものは本番でユーザーが見るものと一致します。

生成中には何が見える?

VULKは生成全体が終わるのを待たせません。プレビューは段階的に更新されます:基本ファイル(index.html、main.tsx、package.json)ができた瞬間に開発サーバーが起動し、コンポーネントファイルが流れ込むたびにファイルウォッチャーがホットアップデートをトリガーします。アプリが組み上がるのをリアルタイムで見られます——まずレイアウト、次にコンポーネント、そしてスタイル。

この段階的レンダリングは早期のフィードバックを与えます。AIが間違った方向に進んでいれば数秒で分かり、待たずに生成を止められます。そして生成後、VULKのレンダーゲートが同じ動いているプレビューを本物のChromiumインスタンスで読み込み、空白ページやエラーバウンダリをレンダリングする生成を失敗させます——プレビューはあなたの目のためだけでなく、検証の一部なのです。

プレビューと本番の間には何がある?

プレビューはアプリの別ビルドではなく、開発環境で動く同じコードです。Deployをクリックすると、VULKはその同じコードで本番ビルド(vite build)を実行し、出力を10〜30秒でyour-project.vulk.spaceに公開します。テストしたものがユーザーに届くもので、そこにミニファイ、ツリーシェイキング、アセット最適化が加わります。