Vercel Labs が「fx0」をオープンソース公開：極めて高速な HTML アーティファクトビルダー

Vercel Labs は、高速な生成と素早い修正を掲げる Web デザイン Agent「fx0」をオープンソースで公開しました。作りたいページを言葉で伝えると、ブラウザ上でそのまま動作する単一ファイルの HTML を出力し、アイデアをすぐ操作可能な初稿へと具現化します。

fx0 は、基礎となる Agent ライブラリ「libfx」の応用事例でもあり、この実行基盤の速度と、状態を保存しながら実行を続ける仕組みを示しています。主な特徴は次のとおりです。

• 初稿を素早く出力し、局所修正での再出力を抑える。 デフォルトで高速モデルを採用し、Agent にはステップ数の削減を指示。色やテキストの軽微な変更時には、該当コードのみをピンポイントで書き換えます。
• 生成の途中でプレビューを先行確認できる。 HTML がすべて書き終わる前でも、ページの構造やスタイルが順次ブラウザに表示されます。完全にコミットされた段階で、対話的なスクリプトが実行されます。
• スタイル規範や参考資料を引き継いで制作を継続できる。 10 種類のプリセットやユーザー独自の design.md のアップロードに対応するほか、参考 Web ページの検索や取得を行い、作業の途中で追加の指示を与えることも可能です。
• 単一ファイルで納品され、世代ごとのバージョンを保持する。 HTML はそのままコピーやダウンロードができ、過去のバージョンを開き直すことも可能です。実行途中のステップが逐次保存されるため、処理が中断しても途中から再開できます。

なぜ速いのか、いかにして実現しているのか？

fx0 は、モデル選定、生成ステップ、修正方式、プレビュー処理の全工程にスピードを組み込んでいます。初稿での無駄な出力を省き、微調整時に既存コードを極力再出力しないことで、ユーザーはより早い段階で画面を確認できます。なお、今回の検証ではエンドツーエンドの計測や同一条件下での他製品比較は行っておらず、検証可能な具体的な設計仕様を以下に整理します。

初稿：高速モデル、最小限のステップ、コンパクトなファイル

デフォルトのモデルには claude-opus-5.5-fast が採用されています。ゲスト試用版では low effort（低い思考強度）と Fast モードに固定されていますが、ログイン後のチャットではモデル、推論強度、Fast 設定を個別に指定できます。

システムプロンプトも待機時間を削るように設計されています。要件が明確な場合、Agent は妥当な初期値を選択して即座に作業を開始します。色やテキストの変更時には、変更規模に見合った思考量に留め、同一リクエスト内の複数の修正は 1 回のツール呼び出しに集約して完了させます。

新規でページを作成する場合、指示により 1 回の publish_design で完全な HTML をコミットすることが求められ、通常の初稿はできる限り 12 KiB 以内に収めるよう推奨されています。このデザイン Agent にはファイルシステムやシェル、デプロイ環境が存在しません。複数ファイルのプロジェクト構成や依存パッケージのインストール、ビルド工程を経ることなく直接 HTML を納品するため、成果物はブラウザでそのまま開くことができます。コードを簡潔に書くことで、モデルが生成すべきトークン量そのものも削減されます。

今回検証した ORBIT / FORM のオリジナルファイルは 10,854 バイト（約 10.6 KiB）、CHROMA FLOW は 9,028 バイト（約 8.8 KiB）でした。これらの数値はファイル容量であり、生成にかかった所要時間ではありません。12 KiB という値はモデルに対する初稿の目安であり、最終バリデータが強制するファイルサイズのハードリミットは 512 KiB に設定されています。

修正：置換対象の断片のみを送信

たとえば、FORM ポスターのタイトル文字を青色に変え、同時にランダム化ボタンの名称を「SHUFFLE POSTER」に変更したい場合、システムプロンプトは HTML 全体を再出力するのではなく、edit_design を優先して呼び出し、対象となる旧テキストと新テキストを送信するよう指示します。修正箇所が特定できている場合、全文を改めて読み直す必要もありません。

1 回の呼び出しで 1〜20 件の厳密なテキスト置換を指定できます。各旧テキストは対象ドキュメント内で一意に一致しなければならず、指定順に適用された後、まとめて検証されて単一の新バージョンとしてコミットされます。そのうち 1 件でも一致に失敗すると、一連の変更全体が破棄され新バージョンは生成されません。これにより、同じ指示に含まれる変更をまとめて反映しつつ、モデルが既存コードを繰り返し出力したりツールを何度も呼び出したりする無駄を省いています。

プレビュー：コードの記述中に画面が立ち上がる

モデルが publish_design を呼び出す際、HTML はツール引数の html フィールドに格納されます。fx0 のトランスポート層はモデルから返される tool-input-delta イベントを監視し、このフィールドを逐次デコードして、受信済みの HTML を Redis パブサブチャンネル経由でブラウザへプッシュします。ツールの引数がすべて届くのを待たずに、ページの描画が開始されます。

未完成のコードをそのまま実行することはできません。フロントエンドはまずスクリプトタグ、イベント属性、iframe、外部リソースを除去し、script-src 'none' によってスクリプトの実行を遮断します。そのため、生成途中にはテキスト、レイアウト、スタイルを先行して確認でき、Canvas のアニメーションやボタンのインタラクションは完全なコミットを待ってから実行されます。

また、プレビューの更新もコードの断片を受け取るたびにページ全体を作り直すわけではありません。draft-preview.ts が既存の DOM と差分比較を行ってパッチを適用するため、変更のないノードやスクロール位置は保持されます。最終的な HTML のバリデーションが完了した段階で、JavaScript の実行が可能なサンドボックスへと切り替わります。

ここでは 2 種類の待機時間が改善されています。出力量や再書き込みを減らすことはタスク完了に必要な処理自体の削減であり、ストリーミングプレビューは進捗を早期に視認できるようにする工夫です。これら両方を短縮時間として混同してはなりません。また通常のリクエストは、キューを介さずリクエストを受け取った関数から直接実行が開始されます。モデルへのリクエスト前に、課金識別情報の取得、ドラフト監視の準備、本ターンのステップ枠の確保が並行して処理されます。Vercel Queues は、障害時の引き継ぎ、長尺タスクの継続、実行中の割り込み指示といったリクエストをまたぐ処理を担当します。

2回の入力で、3つの操作可能なシーンを作る

今回は fx0 オンラインサービス のゲスト試用版で直接検証を行いました。1 ターン目で ORBIT / FORM の2つの展示空間を生成し、2 ターン目で CHROMA FLOW パーティクルキャンバスを生成しています。画面に表示されたモデルは claude-opus-5.5 であり、各ターンとも追問は行わず 1 回の指示のみで出力させています。

メインビジュアル、キャンバスの描画ロジック、各種コントロールは fx0 が出力したものです。本記事内のデモは表示用の調整版であり、ポスター文字のはみ出し、軌道の表示アスペクト比、一部のタッチターゲットサイズ、および「視覚効果を減らす（prefers-reduced-motion）」設定に対応させています。手を加えていないオリジナルの HTML もそのまま保管されており、各事例の横からダウンロード可能です。

01 ORBIT：Web ページを軌道コントロールパネルに変える

漆黒の宇宙空間、シアン色に輝く軌道、鮮やかなオレンジ色の太陽、そして各種テレメトリ数値が宇宙管制室のコンソールを構成しています。EARTH、MARS、SATURN をクリックすると、選択された惑星とその軌道がハイライト表示され、左側のミッション名、目標半径、公転周期などの数値が同期して切り替わります。3 本の軌道と土星の環はあらかじめ画面内に描画されており、切り替えによって強調対象が変化します。

タイムスケールスライダーをドラッグして、動作速度を 0.1 倍から 5.0 倍まで 0.1 刻みで調節できます。PAUSE をクリックすると一時停止し、ボタン表示は RESUME に変わります。これは芸術的なシミュレーションであり、軌道比率、動き、テレメトリ数値を科学計算として扱うことはできません。

実行例 01

ORBIT 軌道ミッションコントロールパネル

インタラクティブデモを起動 新しいタブで開く オリジナル HTML をダウンロード

操作のポイント：画面下部で EARTH、MARS、SATURN のミッションを切り替えることができ（軌道のハイライトとシミュレーション数値が連動）、タイムスケールスライダーもドラッグ可能です。初期状態は静止画キャプチャで、「インタラクティブデモを起動」をクリックするとオンデマンドでサンドボックスが読み込まれます。

02 FORM：スライダーを動かし、キネティックポスターを再構成する

同一の HTML 内で FORM タブに切り替えると、温かみのあるアイボリーの背景、黒とオレンジの大見出し、高密度の波紋からなるまったく異なるビジュアルへと変化します。うねる波状のラインの上に「MAKE SOME NOISE」の文字がレイアウトされ、画面そのものが調整可能なポスターとして機能します。

波の周波数を上げると起伏が細かくなり、密度を変更すると画面内のライン本数が変化します。オレンジ、黒、青、赤の 4 色のインクは即座に切り替え可能です。RANDOMIZE COMPOSITION をクリックすると、周波数、密度、カラー、位相、文字のオフセットがランダムに再構成されます。

オリジナルのコードでは、ランダムオフセットの数値によって頭文字が画面外にはみ出す場合があったため、展示用調整版ではオフセット範囲を制限しフォントサイズを微調整しました。これは、デザイン性の高いページが生成された後でも、コントロールの極端な入力状態を実際にテストして検証する必要があることを示しています。

実行例 02

FORM キネティックタイポグラフィポスタースタジオ

インタラクティブデモを起動 新しいタブで開く オリジナル HTML をダウンロード

操作のポイント：ケース 01 と同じ生成セッションから作成。波の周波数や密度のスライダーを動かしたり、オレンジ/黒/青/赤の4色のインクを切り替えたり、「RANDOMIZE COMPOSITION」をクリックしてレイアウトを再ランダム化できます。展示用調整版では文字のオフセット範囲を制限し、小型画面でも文字が途切れないようにしています。

ORBIT と FORM は、1 回のプロンプトから同時に生成されました。初回のプロンプトでは、2 つのシーンそれぞれのビジュアルの方向性、具体的な操作要素、そして「操作によって画面が実際に変化すること」という要件を同時に指示しています。

Create a spectacular interactive exhibition called ORBIT / FORM with TWO distinct full-screen exhibits accessible through clear persistent tabs and URL hashes #orbit and #form. Exhibit 1 ORBIT: a cinematic orbital mission-control scene, near-black space, glowing cyan orbital trajectories and a vivid orange sun rendered with Canvas/SVG/CSS (no external assets). Hundreds of subtle animated stars, planet orbit paths, small telemetry panels with clearly labelled SIMULATED data. Visitors can pause/resume motion, adjust time speed, and switch between Earth/Mars/Saturn missions; selection must visibly change orbit and readouts. Exhibit 2 FORM: a completely different Swiss editorial generative kinetic typography poster studio, warm ivory background, huge black/orange type saying MAKE SOME NOISE, sculptural parametric ribbon or moire geometry, controls for wave frequency, density and ink color, plus a randomize composition button; all controls must change the live artwork. Polished art direction, intentional typography, no generic SaaS cards. Both scenes need distinct strong composition, responsive layout that works on a 390px phone, keyboard-accessible real controls, prefers-reduced-motion support, and a small plain-language instruction visible on each scene. All content and code in one self-contained HTML, no CDN, no external network requests, no mock buttons. This is a design exploration: use only fictional/simulated data, no real account or backend. Make it beautiful and publish the finished design.

「ORBIT / FORM」という名称の見事なインタラクティブ展示を作成してください。明確な常設タブおよび URL ハッシュ（#orbit と #form）を通じてアクセス可能な、完全に独立した2つのフルスクリーン展示を含める必要があります。展示 1 ORBIT：シネマティックな軌道ミッションコントロールシーン。ほぼ漆黒の宇宙空間、Canvas/SVG/CSS で描画された光り輝くシアン色の軌道トラジェクトリと鮮やかなオレンジ色の太陽（外部アセットは使用不可）。かすかにアニメーションする数百の星々、惑星の公転軌道、および「SIMULATED（シミュレーション）」と明記されたテレメトリデータパネル。訪問者は動きの一時停止/再開、タイムスピードの調整、Earth/Mars/Saturn ミッション間の切り替えが可能です。選択によって軌道のハイライトと表示数値が視覚的に変化しなければなりません。展示 2 FORM：まったく異なるスイス・エディトリアルスタイルのジェネレーティブ・キネティックタイポグラフィポスタースタジオ。温かみのあるアイボリーの背景、「MAKE SOME NOISE」と描かれた巨大な黒とオレンジの文字、彫刻的なパラメトリックリボンまたはモアレ幾何学パターン、波の周波数・密度・インクカラーのコントロール、さらに構図をランダム化するボタンを備えます。すべての操作盤はリアルタイムにアートワークを変化させなければなりません。洗練されたアートディレクションと意図的なタイポグラフィを求め、ありきたりな SaaS 風カードは禁止とします。両シーンともに際立った力強い構図、390px 幅のスマートフォンでも機能するレスポンシブレイアウト、キーボード操作可能な本物のコントロール、prefers-reduced-motion（視覚効果の抑制）への対応、および各シーンに表示される簡潔で平易な操作説明が必要です。すべてのコンテンツとコードを完全に自己完結した単一の HTML ファイルに収め、CDN や外部ネットワークリクエストは使わず、機能しないダミーボタンも配置しないでください。これはデザインの探求です。架空/シミュレーションデータのみを使用し、実際のアカウントやバックエンドは不要です。美しく仕上げ、完成したデザインを公開（publish）してください。

03 CHROMA FLOW：マウス操作で発光パーティクルを撹乱する

2 ターン目ではダークトーンのジェネレーティブアート作品を生成しました。マゼンタ、シアン、蛍光イエローグリーンの光点が黒いキャンバス上に光の帯やライン網を形成します。マウスの侵入やドラッグ、キャンバスへのタッチによってグラフィックがインタラクティブに乱れます。

3 種類のモードの違いは視覚的に明確です。

• VORTEX（渦流）：パーティクルが 3 つの移動中心の周囲を流れ、残光の尾を引きます。ポインターが入ると回転する撹乱の中心が追加されます。
• WAVES（波陣）：曲線群が正弦波状の起伏を重ね合わせ、ポインター周辺に拡散・減衰する波紋が現れます。
• CONSTELLATION（星座）：光点が緩やかに移動し、距離が一定以内に近づいた点同士が線で結ばれ、絶えず変化するネットワークを構成します。

TURBULENCE で撹乱の強度を調整し、FREEZE / RESUME で画面を静止・再開させ、RESEED で初期配置を再生成できます。左右の矢印キーによるモード切り替えやスペースキーでの一時停止にも対応しています。これはジェネレーティブアートであり、実際の流体力学方程式を解いているわけではありません。

オリジナルのコードは、OS の「視覚効果を減らす」が有効になっている場合でも動作を継続し、時間パラメータを遅くして初期の撹乱度を下げる仕様になっていました。展示用調整版では、初期状態で静止した星座を表示し、ユーザーが必要に応じて手動でアニメーションを開始できるように変更しています。

実行例 03

CHROMA FLOW 粒子アート装置

インタラクティブデモを起動 新しいタブで開く オリジナル HTML をダウンロード

操作のポイント：2回目のプロンプトによる生成物。画面下部で 01 Vortex（3中心の渦状バンド）、02 Waves（多層正弦波干渉）、03 Constellation（近傍動的結線スターネットワーク）を切り替え可能。カーソルのドラッグ操作で撹乱を与えられ、乱流スライダーの調整やスペースキーでの一時停止にも対応しています。

Build CHROMA FLOW, an extraordinary interactive liquid-light instrument, as one complete self-contained HTML file. Make it look like a physical creative instrument / experimental museum exhibit: almost-black background, enormous vivid magenta/cyan/acid-lime luminous flowing particle ribbons or fluid-like interference field on Canvas, editorial condensed CHROMA FLOW headline, delicate numbered scales, small generous controls. The artwork must fill most of the page and react to pointer/touch movement with attractive ripples or swirls. Provide three visually very different working modes (VORTEX, WAVES, CONSTELLATION), a turbulence/intensity slider, a real freeze/resume toggle, and an actual reset/reseed button. Each mode should change the algorithm/composition, not only color. Keep readable visible instructions and mode description, do not overclaim physical fluid simulation; label it generative art. Ensure attractive initial composition without interaction. No external assets, libraries, fonts, CDN or network. Use Canvas and inline JS/CSS only. Make it responsive at 390px width and large desktop with all controls readable, no clipped headline or overlapping instructions, min 44px touch targets, keyboard-accessible controls and prefers-reduced-motion support. Respect safe particle counts for mobile. Strong composition, bold visual identity, no SaaS cards. This is fictional artwork, no backend. Publish the completed design.

完全に自己完結した単一の HTML ファイルとして、光の流れを操る卓越したインタラクティブアート装置「CHROMA FLOW」を構築してください。物理的な創作ツールや実験的な博物館の展示物のような外観に仕上げてください。ほぼ漆黒の背景、Canvas 上に描かれる巨大で鮮やかなマゼンタ/シアン/アシッドライムの発光する流体パーティクルリボンまたは流体のような干渉フィールド、エディトリアルでコンデンス（長体）な CHROMA FLOW の大見出し、繊細な目盛りスケール、小ぶりでゆとりのあるコントロールを備えます。アートワークはページの大部分を占め、ポインターやタッチの動きに対して魅力的な波紋や渦となって反応しなければなりません。視覚的に大きく異なる3つの動作モード（VORTEX、WAVES、CONSTELLATION）、乱流/強度のスライダー、実際に動作する一時停止/再開トグル、およびリセット/再シードボタンを提供してください。各モードは単に色を変えるだけでなく、アルゴリズムと構図そのものを変更する必要があります。読みやすく明瞭な説明文とモード解説を維持し、物理的な流体シミュレーションであると過剰に主張せず、ジェネレーティブアートと表記してください。操作を行わない状態でも初期構図が美しく成立していることを保証してください。外部アセット、ライブラリ、フォント、CDN、ネットワークリクエストは一切禁止します。Canvas とインラインの JS/CSS のみを使用してください。390px 幅のモバイルから大型デスクトップまでレスポンシブに対応させ、すべてのコントロールが明瞭に読め、見出しの途切れや説明文の重なりがなく、最小 44px のタッチターゲット、キーボード操作可能なコントロール、prefers-reduced-motion への対応を施してください。モバイル環境では安全なパーティクル数を遵守してください。力強い構図、大胆なビジュアルアイデンティティを確立し、SaaS 風カードは排除してください。これは架空のアートワークであり、バックエンドは不要です。完成したデザインを公開（publish）してください。

再現し、成果物を持ち出す手順

1. fx0 を開き、入力欄に 1 回分の完全なプロンプトを貼り付けます（英語原文または日本語訳のどちらでも可）。
2. 送信後、プレビューの完了を待ちます。ミッションの切り替え、スライダー、ランダムボタンを操作し、画面が正しく連動することを確認します。
3. ヘッダーメニューから copy HTML または download HTML を選択し、単一ファイルを保存します。ダウンロードした HTML をローカルのブラウザで開くだけで閲覧でき、事前に完全な fx0 サーバーを立ち上げたり、publish with Drop を利用したりする必要はありません。
4. さらに調整を加えたい場合は、同一セッション内で「色だけを変更する」「ボタンの位置を調整する」といった具体的な修正を指示します。fx0 の局所修正ツールが既存ドキュメントに対してテキスト置換を実行します。各ターンのデザインは固有のバージョンとして保持され、過去の版を再度開いて出力することも可能です。

生成にはランダム性があり、同一のプロンプトであってもまったく同一の構図が得られるとは限りません。今回の 2 つの入力内容は、再現やカスタマイズの出発点として利用できます。

リポジトリで任意に有効化できるゲスト試用機能は、IP あたり累計 5 回の入力に制限されており、定期的なリセットはありません。今回の検証開始時点では残り 2 回と表示されており、使い切るとログインを求められました。この残り回数は新規ユーザーの初期付与枠ではありません。ログイン後のモデル呼び出しは AI Gateway を経由してユーザー自身の Vercel Team に課金され、料金は選択したモデルと使用量に応じて変動します。

モデル設定、実行中の割り込み指示、バージョン履歴により、その後の微調整をきめ細かく制御できます。

モデル、推論強度、Fast モードは個別に選択可能。 単純な色変更と複雑なロジックの実装で同一の思考設定を使う必要はなく、タスクに応じて切り替えられます。Fast は速度に関するオプションであり、無料を意味するものではありません。実際の利用料はモデルとトークン消費量に応じて発生します。

生成の途中で追加指示を出せる。 有料のテキストチャットでは、Agent が処理を実行している最中でも「構図はそのまま、色だけ調整して」といった追加要件を送信できます。libfx は現在のツール実行が完了した段階でこの割り込み指示をモデルへ引き渡すため、ターン全体の完了を待つ必要がありません。画像を含むメッセージは次のターンとして処理され、無料試用版での各入力もそれぞれ独立したターンとして扱われます。

過去のターンのバージョンを取り出せる。 該当するターンのバージョン履歴から過去のデザインを開き直し、変更内容を比較したうえで、その時点の HTML をコピーまたはダウンロードできます。たとえば色調整の結果が思わしくなかった場合でも、過去のファイルは保持されているため、記憶を頼りに以前の状態を説明し直す必要はありません。

なぜ単一の HTML でアニメーションが動くのか？

FORM ポスターを例にとると、単一の HTML 内に 3 つの要素が共存しています。HTML のマークアップがスライダーやボタンを提供し、CSS がカラー、フォントサイズ、配置を定義し、JavaScript が操作イベントを受け取ってグラフィックを再描画します。

密度のスライダーを 44 から 80 へ動かすと、スクリプトが新しい値を読み取り、次の描画フレームでキャンバスにより多くのラインを描き出します。青色を選択すれば、ライン描画に使用されるカラーが変更されます。連続したアニメーションはブラウザの requestAnimationFrame を介してフレームごとに角度、パーティクル座標、波紋の位相を更新します。モデルはコードの記述を担当し、完成品を開いた後の操作や描画処理はブラウザが直接実行するため、スライダーを動かすたびにモデルへ問い合わせが発生することはありません。

今回の 3 つのシーンはいずれもブラウザの標準機能のみで動作しています。fx0 の制約は「特定のフロントエンドフレームワークを禁止する」ことではなく、「完全に自己完結した単一ファイルを納品する」という点にあります。CSS やスクリプトはインラインで記述され、画像などのアセットもファイル内に埋め込む必要があり、外部 CDN からリソースを読み込むことはできません。

リクエストから完成まで、Agent はどう動くのか？

Web ページ内のスライダーはブラウザによって実行されますが、それらのコードを書き出す処理はバックエンドの Agent が担っています。具体的な呼び出しフローは以下のとおりです。

1. フロントエンドから Next.js の POST /api/prompt へ要件が送信されます。fx0 はメッセージを保存し、そのターンで使用される試用版または有料版の課金識別情報を記録します。
2. libfx セッションが AI Gateway を経由してモデルへリクエストを送り、モデルの応答に含まれるツール呼び出しを fx0 へ渡して実行させ、その結果を受け取ってタスクを継続します。
3. 初稿は publish_design が完全な HTML として納品し、局所修正は edit_design が厳密なテキスト置換として提出します。生成されたコードはバリデータへ送られ、ドキュメント構造、リソース制限、および 512 KiB のサイズ上限が検証されます。
4. 検証を通過すると現在のデザインが更新され、フロントエンドが隔離された iframe 内にコードを読み込んでブラウザにスクリプトを実行させます。完了したターンの記録とデザインバージョンは、プロジェクション層を介して Neon へ書き込まれます。

個々のサーバープロセスにおいて、fx0 は createFxAgent() を用いて Agent インスタンスを生成・再利用し、チャットごとに独立したセッションを持ちます。独立したサブタスクを委任する必要がある場合、ツールの内部で createFxEngine() を呼び出してインメモリのサブエンジンを起動します。両者の責務は異なり、前者はセッションと永続タスクの進行を管理し、後者は個別のサブタスクの実行を受け持ちます。

// 簡略化したイメージ：設定オブジェクトは fx0 が提供するものであり、単体でそのまま実行できるコードではありません。
const agent = createFxAgent(agentOptions)
const session = agent.session(sessionId, sessionOptions)
session.prompt(message, { messageId })
const engine = await createFxEngine(subtaskOptions)

持ち出しやすさがもたらすトレードオフ

バックエンドのバリデータは、単一のデザインファイルを 512 KiB 以内に制限し、外部リソース、フォーム送信、インラインフレームのネストを禁止しています。さらに fx0 は生成されたページをサンドボックス化された iframe 内に配置し、ブラウザの Content Security Policy（CSP）によってネットワークリクエストを制限することで、アプリケーションの Cookie、ローカルストレージ、認証情報への直接アクセスを防止しています。

そのため、Agent はページ制作時に外部 Web ページを参照できますが、生成されたページそのものが fx0 のプレビュー環境から業務 API を呼び出したり、外部データベースを読み込んだり、Web フォントをロードしたりすることはできません。通常の HTTPS 参照リンクは、ユーザーが別のタブで個別に開くことが可能です。

これらはブラウザ実行環境における隔離措置であり、成果物に脆弱性やバグが一切存在しないことを保証するものではありません。単一ファイルはオフラインでの確認が容易である反面、異なる画面サイズ、ブラウザ、デバイスへ移行した際には、レイアウト、インタラクション、描画パフォーマンスを改めて検証する必要があります。

生成が中断した際、バックグラウンドはどう継続するのか？

Agent がパーティクルキャンバスを記述している最中に、リクエストを処理していたクラウド関数が突然停止したと仮定します。チャット履歴を保持しているだけでは不十分であり、システムはどのステップまで完了しているのか、現在のデザインはどうなっているのか、そして次回どこから処理を再開すべきかを把握している必要があります。

fx0 はこれらの責務を明確に分離しています。fx0 自身がチャット、プレビュー、アカウント、デザインの世代管理を担当し、libfx がモデルの呼び出し、ツールの実行、リトライ、各ターンのタスク進行を管理します。Redis がチャット履歴とリアルタイムのデザインを保持し、Neon がアカウント、所有権、完了したターンおよびバージョンを記録します。実行途中のステップごとのログは Workflow World に逐次書き込まれます。処理の引き継ぎが必要になると、Vercel Queues が新たな関数インスタンスを起動し、libfx は保存されたステップから処理を再開します。

ユーザーが送信したメッセージはまず Redis に保存され、libfx が受理した段階で確定されます。実行結果はストリーミングで返却され、完了したターンごとにデザインのバージョンが残されます。復旧タスクにおいても当初の課金識別情報が引き継がれるため、試用版のリクエストが誤って特定の有料アカウントに課金されるといったトラブルを防ぎます。

また、復旧時にすべてのツール呼び出しが無条件で再実行されるわけではありません。デザインの読み込みや Web ページの取得といった安全で冪等な操作は再実行されますが、コードの編集、ユーザーへの質問、サブ Agent の起動などは無秩序に再実行されません。モデルは中断の通知を受け取ったうえで、どのように処理を継続すべきかを自律的に判断し、同一箇所の重複修正を防ぎます。

なぜ送信後、復帰までに約13分待たされる場合があるのか？

Vercel の実行環境において、libfx は元のリクエストが完全にクラッシュしたのか、あるいは単に時間のかかる処理を継続しているのかを即座に判別できません。2 つの実行主体が同一セッションを同時に変更する競合を防ぐため、元のリクエストはタイムリミットである 800 秒が経過するまでセッションのロックを保持し続けます。バックアップキューは、さらに 5 秒経過した段階で処理を引き継ぎます。

したがって、初期リクエストが不意にクラッシュした場合、復旧処理が動き出すタイミングはプロンプトを最初に送信してから約 805 秒後となります。クラッシュが発生した時点からさらに 13 分待たされるという意味ではありません。正常に稼働しているものの所要時間が長いタスクについては、制限時間の 30 秒前に状態が自動保存されて引き継がれるため、このフォールバック用の待機時間を迎えることなく継続されます。

1 ターンあたり、親 Agent とサブ Agent を合計して最大 64 回のモデル呼び出しステップに制限されており、無限ループによる暴走を防止しています。これは利用料金の上限を定めるものではありません。またチャット履歴は自動切り詰めされないため、ターン数が非常に長くなると画面を開く動作が遅くなります。なお今回の検証はページの生成とインタラクションの確認に焦点を当てており、意図的にクラウド関数をクラッシュさせたり、実際の課金請求額を検証したりはしていません。

スタイル規範でデザインを律し、適したタスクから始める

fx0 には、Apple、Vercel、Stripe、Linear などを冠した 10 種類の design.md が標準で組み込まれており、独自のテキストファイルをアップロードして使用することも可能です。これらのプリセットは VoltAgent が各ブランドの公開サイトを分析して策定したものであり、各社が公式に公開しているガイドラインではありません。

スタイル定義ファイルは、その後のすべての修正ターンを制約する。 このファイルにはプライマリカラー、文字スケール、余白、コンポーネント設計のルールが自然言語で記述されており、その全文が該当チャットにおける後続のモデルリクエストへ注入されます。たとえば同じトーンのページを連続して作成したい場合、それらの要件を独自の design.md にまとめておくことで、指示を毎回入力し直す手間が省けます。アップロードできるファイルサイズの上限は 100 KB であり、超過した場合は自動圧縮されず拒否されます。

参考 Web ページを Agent に読み込ませることができる。 Agent は web_search で検索を行い、web_fetch で公開 Web ページを取得できます。取得ツールはスクリプト、スタイル、HTML タグを除去し、テキスト情報のみをモデルへ渡して参照させます。この経路で取得されるのはテキストとしての参考情報であり、参照元サイトの画像、フォント、フレームワーク一式がそのまま成果物へ移植されるわけではありません。生成されるページは依然として単一ファイルのリソース制約を遵守する必要があります。

サブタスクをサブ Agent に委譲できる。 たとえば参考資料の要点整理やスタイル要件の抽出を単独で処理させることが可能です。サブ Agent は同種のデザインツールを使用できますが、さらに下位の Agent を再帰的に生成することはできません。また親 Agent と共通の枠組みである「1 ターン 64 ステップ」を共有するため、タスクを分割してもステップ上限を迂回することはできません。既存の永続化・復旧機構により、処理が中断した際に、これらの作業内容を保持して再開します。

今回の検証結果を踏まえると、fx0 はインタラクティブな展示作品、1 ページのビジュアルコンテンツ、モーションプロトタイプ、教育用ミニアプリといった用途の探索に非常に適しています。生成後すぐにブラウザ上で操作でき、ダウンロードすればソースコードの確認や編集も自由に行えます。一方で、そのプレビュー環境はユーザー認証、リアルタイムデータベース、業務 API との連携を必要とする本格的な Web アプリケーションを直接動作させる構造にはなっていません。エクスポートしたページを実際の業務システムへ組み込むには、それらのインフラを別途構築する必要があります。また 512 KiB の容量制限があるため、大量の高解像度画像や動画、重厚な 3D アセットを取り扱う用途には適していません。

成果物の閲覧は手軽だが、完全なセルフホストには相応の準備が必要

ダウンロードした HTML をブラウザで開くことと、自分自身のサーバー環境で fx0 システム全体を運用することは、まったく性質の異なる作業です。後者を実現するには Node.js 24 に加え、「Sign in with Vercel」アプリケーション、Neon Postgres、Upstash Redis の 3 つの外部サービスが必要となります。

git clone https://github.com/vercel-labs/fx0.git
cd fx0
cp .env.example .env.local

npm ci
npm run db:migrate
npm run dev

これら 3 つの事例から得られる最大の価値は、デザイン要件として提示された一文のアクションが、検証可能な具体的なフィードバックへと具現化されている点にあります。ミッションを切り替えると数値が連動するのか、密度を上げると実際に描画本数が増えるのか、モードを変えるとグラフィックの描画ルールそのものが切り替わるのか。初期画面の見栄えだけで判断するのではなく、こうした入力に対する忠実な応答をもって成果物を評価することが極めて重要です。