Runway Solarisは画面を毎フレーム生成、コード不要にはまだ壁

Runwayは2026年8月31日、クリックやドラッグなどの操作に応じてインターフェースをフレーム単位で生成する研究モデル「Solaris」を発表した。RuntimeWireの同日報道 が確認した通り、現段階は早期アクセスを募集する研究プレビューで、一般公開日、API、価格、必要なハードウェア、具体的な遅延値は示されていない。

8月31日の発表で示されたのは、通常のWebアプリのようにコードで定義済みの画面を更新するのではなく、Solarisが操作を受けながら画面そのものを生成し続ける仕組みだ。ただし、視覚的な反応をコードなしで作れることと、データ処理やアクセシビリティまで備えたアプリをコードなしで提供できることは同じではない。

Interface World Modelは操作を次のフレームへ渡す

Runwayの公式技術紹介 によると、Solarisは同社が「Interface World Model」と呼ぶモデル群の第1弾で、Gen-4.5動画生成モデルを操作理解とリアルタイム応答へ適応させている。開始画面と、それまでに起きたクリック、ドラッグ、文字入力などを次のフレームの条件にし、720pの視覚品質を保つことを開発目標としている。

処理は単一モデルだけで完結しない。言語モデルが利用者の要求を解釈し、現在の場面を変更するのか別の場面へ移るのかを判断する。その指示を受けたワールドモデルが、結果を新しい映像フレームとして描画する。推論と描画を分担しながら、画面を連続出力する構成だ。

フレーム生成には自己回帰方式が使われ、各フレームは過去の出力に基づいて作られる。通常の動画拡散モデルが複数回行うノイズ除去も少数の処理へ蒸留したという。公開デモでは、衣服を人物画像へドラッグする仮想店舗、家具の位置や色が変化する商品空間、材料を直接動かせるシミュレーションなどが示された。

同じ開始画面と同じドラッグでも異なる反応を作れる点は、Solarisの開放性を示す一方、結果が事前定義された一つの遷移に固定されないことも意味する。公開資料が実証しているのは、視覚的な場面を操作に合わせて連続生成できることまでであり、一般的な業務アプリの機能を代替できることではない。

コードUIとは状態を更新する場所が違う

通常のWebアプリでは、画面上のボタンや入力欄に対応する要素、状態、イベント処理がコードで定義される。操作を受けるとロジックが状態を変更し、ブラウザが必要な部分を再描画する。保存されたデータと画面表示を分けられるため、処理結果のテスト、監査、再現が可能になる。

Solarisの公開説明から読み取れる処理経路は、次のように整理できる。

1. 開始画面と過去の生成フレームを文脈として保持する。
2. クリック、ドラッグ、文字入力などを次の生成条件へ加える。
3. 言語モデルが、場面の変更か遷移かを判断して描画内容を指示する。
4. ワールドモデルが画面全体を次のフレームとして生成し、連続出力する。

この方式なら、開発者が画面内のすべての動きを個別のイベント処理として書かなくても、視覚的な文脈に合う反応を作れる。しかし、画面上で商品がカートへ入ったように見えても、その表示だけでは在庫、価格、利用者の注文データが正しく更新されたとは確認できない。映像上の状態と永続データを確実に同期させる統合仕様は、今回の発表に含まれていない。

したがって「コード不要」が直接指すのは、表示される画面と個々の視覚的反応の生成経路である。認証、決済、データ保存、権限管理、エラー処理まで不要になるという意味ではない。こうした処理を既存システムへどう接続するかが示されなければ、Solaris単独で完成したWebアプリを出荷できるとはいえない。

実測遅延と継続コストは判断材料が足りない

生成UIの実用性を左右する第一の条件は、入力から画面更新までの時間だ。Solarisは「リアルタイム」「インタラクティブな速度」を目標として説明されているが、平均遅延、遅い応答の分布、フレームレート、同時接続時の性能は公開されていない。選別されたデモ映像だけでは、利用者の回線や端末を含む実環境の応答性を評価できない。

費用の構造も通常のWeb配信とは異なる。コードUIは、一度生成したHTML、画像、スクリプトやキャッシュを再利用できる。Solarisは操作中に新しいフレームの推論を続けるため、セッション時間、解像度、同時利用数が計算量へ影響すると考えられる。フレーム生成は構築済みページの配信より高価だと説明されているものの、課金単位と実行環境が未公表であり、本番運用の継続費用は算定できない。

720pも、製品の出力仕様として保証された上限ではなく、現在の開発目標として示された品質だ。細かな文字や多数の入力欄を持つ業務画面について、読みやすさや応答速度を同時に維持できるかは公開情報から判断できない。APIとハードウェア要件が出るまでは、既存サービスへの組み込み方法も不明のままだ。

文字、正確性、アクセシビリティが本番利用を隔てる

Solarisは周囲の動き、クリックとドラッグ、場面転換のような視覚的操作を得意とする一方、安定して読める文字は未解決の課題とされる。生成が続く間にラベル、価格、数値、配置が変化すれば、見た目が自然でも情報システムとしての信頼性は保てない。長いセッションでは小さな誤差が蓄積し、視覚上の状態と意味上の状態がずれる可能性もある。

正確性の問題は、開始画面に実在の商品画像や参照資料を与えるだけでは解消しない。セッション中の生成結果を、検証済みの商品データや文書へ継続的に結び付ける方法は研究段階にある。商取引や操作手順では、もっともらしい反応よりも、表示と実際の処理結果が一致していることが優先される。

アクセシビリティにも別の実装層が必要だ。スクリーンリーダーなどの支援技術は、画面のピクセルだけでなく、見出し、ラベル、入力欄、フォーカス順序といった構造化情報を利用する。RunwayもアクセシビリティAPIや既存ソフトウェアとの統合を課題に挙げており、公開された構成には支援技術へ安定した構造を渡す具体的な仕様がない。

Solarisが現在示している価値は、定義済みのページ遷移を超え、操作に応じて変化する視覚的な空間を生成できる点にある。利用範囲として見通しやすいのは、体験型プロトタイプ、商品や空間の表現、変化する画面を使ったAIエージェントの研究だ。一方、決定論的な処理、永続データ、監査、読みやすい文字、支援技術への対応が必要なアプリでは、コードUIや既存システムとの統合が依然として欠かせない。

現段階のSolarisは、画面を毎フレーム生成する技術経路を示した早期アクセス前提の研究モデルである。一般公開、API、価格、実測性能、外部データとの接続、長時間の一貫性、アクセシビリティ対応が明らかになるまで、コード不要の完成したアプリ基盤ではなく、生成UIの可能性と限界を同時に示すプレビューと位置付けるのが正確だ。