Runway Solarisとは？AIがインタラクティブなアプリ画面をリアルタイム生成

Runwayの「Solaris」は、ソフトウェアの作り方と使い方を変える可能性を示す実験的なモデルです。従来のアプリやWebサイトは、開発者がHTML、CSS、JavaScriptなどで画面と状態をあらかじめ実装し、ブラウザーがそれを表示します。

Solarisはその流れを逆転させます。画面を固定されたコードの結果として表示するのではなく、ユーザーがクリック、ドラッグ、文字入力、自然言語による指示を行うたびに、AIが次の画面を生成します。つまり、アプリの画面自体が、操作に応じて連続的に生成される「動く視覚世界」になります。38

この発想は、単なるノーコード開発ツールとは少し違います。Solarisが目指すのは、あらかじめ用意された画面を切り替えるUIではなく、ソフトウェアの状態を映像のような連続フレームとして生成する「インターフェースのワールドモデル」です。

Runway Solarisとは？

Runwayは8月31日、Solarisを実験的な「Interface World Model（インターフェース・ワールドモデル）」として発表しました。通常のソフトウェア開発では、コードを書き、ブラウザーがそのコードを画面に変換します。Solarisでは、コードを介して画面を描画するのではなく、見えているインターフェースをモデルが直接生成することを目指します。

体験は、商品画像やブランドを表すビジュアル環境など、何らかの視覚的な出発点から始まります。Solarisはそのイメージをもとに画面を生成し、ユーザーの操作に合わせて状態を更新します。開発者があらゆる画面や遷移を事前に一つずつ作り込むのではなく、「次に何が表示されるべきか」をモデルがその場で合成する仕組みです。

この方式の利点としてRunwayが挙げているのが、視覚情報の保持です。画像やコンセプトをいったんコードへ変換してからUIに戻す場合、複雑なレイアウトや自然なビジュアル表現が失われる可能性があります。Solarisは視覚的なシーンを主な出力として扱うことで、操作中の画面全体の一貫性や自然な振る舞いを保とうとしています。

Solarisはどのように画面を生成するのか

Solarisでは、ユーザーの操作を解釈する役割と、その結果を視覚的に描画する役割が分かれています。大まかな流れは次のとおりです。

1. ユーザーが指示や操作を入力する
   オブジェクトをクリックする、要素をドラッグする、文字を入力する、自然言語で変更を依頼するといった操作が起点になります。
2. 言語モデルが意図を解釈する
   現在のシーンをどう変えるべきか、操作によって何が起こるべきかを判断し、ビジュアルモデルに渡す動作や指示を組み立てます。38
3. インターフェース・ワールドモデルが次の状態を描画する
   コード化されたページを返すのではなく、直前までのフレームとユーザーの操作を条件に、次の視覚的な状態を生成します。
4. この処理を繰り返す
   新たな操作と生成結果が次の文脈に加わり、画面は固定された画面遷移ではなく、連続的に変化していきます。

ビジュアル面の基盤には、Runwayの動画生成モデル「Gen-4.5」が使われています。Runwayの開発者向け資料では、Gen-4.5はテキストからの動画生成と画像からの動画生成に対応するモデルと説明されています。Solarisは、この動画生成の基盤をインタラクティブで自己回帰的な環境に応用します。46

リアルタイム動作を支える技術

操作のたびに新しい視覚状態を生成する処理は、短い動画クリップを作ることとは異なります。長時間のセッションで画面の品質を保ちながら遅延を抑えるため、Solarisには複数の工夫が組み込まれています。

フレームを順番に生成する

Solarisは、過去のフレームを条件にして次のフレームを生成する自己回帰方式を採用します。毎回まったく別の画面を作り直すのではなく、現在のシーンを引き継ぎながら、ユーザーの操作に対応する変化を続けていく考え方です。

高速モデルへの蒸留

Runwayによると、まず低速な拡散モデルを「教師モデル」とし、それを少ないデノイズステップで動作する高速モデルへ蒸留しています。1回の応答に必要な計算量を減らし、インタラクティブな用途で使える速度を目指すためです。

モデル自身の出力で学習する

Runwayは、高速モデルを自らの生成結果でも学習させたと説明しています。連続するフレームが長く続くと、小さな視覚的な誤差が積み重なって画面が崩れる可能性があります。自身の出力を使った学習は、こうした長時間の品質劣化を抑える狙いがあります。

Runwayが示す設計目標は、おおむね0.5秒未満の操作遅延、セッション全体を通じた一貫性、720pのビジュアル品質です。ただし、これらは研究上の目標であり、すべての操作で保証される性能ではありません。

コードで作ったUIとの比較結果は？

Runwayは、250人の参加者が30種類のインタラクション例を評価し、約7,500件のペア比較を行ったユーザー調査を報告しています。参加者は、Solarisが生成したインターフェースと、Claude Opus 5がコードとして生成したインターフェースを比較しました。

報告された結果では、参加者がSolarisを選んだ割合は次のとおりです。

• 指示への追従：61％
• 自然な振る舞い：71％

この結果は、特定の操作場面では、生成されたUIのほうが視覚的に一貫していたり、物理的な動きが直感的に感じられたりする可能性を示します。

一方で、Solarisが従来のソフトウェア全般より優れている証明と受け取るべきではありません。調査が比較したのは主に主観的な操作体験であり、信頼性、正確性、安全性、保守性、コスト、性能、アクセシビリティを検証したものではありません。提示された資料だけでは、調査の詳細な方法や統計分析を独立に確認することもできません。

Solarisの主な限界

Solarisの柔軟性を生む仕組みは、同時に実用化を難しくする要因でもあります。

生成テキストはまだ安定しない

読みやすく正確な文字をリアルタイムの画像・動画生成で表示することは、現在も難しい課題です。見た目は魅力的な画面でも、ラベル、数字、メニュー、説明文などが誤って描かれる可能性があります。

Runwayもテキスト生成を未解決の問題として挙げています。将来的な方法として、文字量の多い静的な場面は画像モデル、連続的な操作は動画モデルが担当するハイブリッド構成を示しています。

説得力のある間違いを表示する可能性がある

見た目が本物らしいことと、内容が正しいことは別問題です。Solarisは現時点では主に開始時の画像や与えられた参照情報に基づいて動作するため、誤った回答、商品情報、視覚表現を自信ありげに提示する可能性があります。

Runwayは今後の研究課題として、検証済みのデータや文書、より豊富な参照資料によるグラウンディングを挙げています。

長時間の利用で一貫性が失われる

各状態が、それ以前に生成された状態とモデルの判断の連鎖に依存するため、長く自由に操作するほど誤差が蓄積する可能性があります。シーン、オブジェクトの属性、指示、操作履歴を長時間にわたって整合させることは、依然として研究上の課題です。

すべてのフレームを生成するためコストがかかる

一般的なWebサイトは、コードや画像などのアセットを配信し、ユーザーの端末が画面を描画します。Solarisは表示内容を継続的に生成するため、画面を出すたびに生成処理が必要です。

Runwayは最適化によって通常の動画拡散より大幅に安価になったと説明していますが、固定されたコードページを配信するより負荷の大きい方式であることに変わりはありません。プロトタイプが掲げる画質目標も720pです。

アクセシビリティとソフトウェア連携は未完成

生成された画像は、それだけでスクリーンリーダーや支援技術が必要とする構造化された意味情報を提供するわけではありません。また、多くのソフトウェアが必要とする検査可能な状態、イベント構造、予測可能なインターフェースも自動的には備わりません。

従来のDOMやアクセシビリティ層が存在しないことは、アクセシビリティへの配慮や監査可能性が特に求められる環境で導入する際の大きな障壁だと分析されています。

Solarisは利用できる？

Solarisは、広く提供される本番向けのアプリ開発プラットフォームではなく、実験的な研究として発表されました。報道では、一般公開されたアプリ作成サービスというより、研究プレビューや申請制の早期アクセスとして扱われています。

したがって、現時点での重要性は、実用サービスとしての完成度よりも、ソフトウェアの新しい方向性を示した点にあります。従来型のコードアプリをそのまま置き換えられる段階にあることを示す証拠は、まだありません。

SolarisとRunwayのGWM-1の関係

Solarisは、Runwayが進めるワールドモデル研究と関係していますが、対象は異なります。RunwayはGWM-1を、環境、アバター、ロボット操作などをリアルタイムにシミュレーションする汎用モデルとして説明しています。一方のSolarisは、その「世界」の対象をアプリやWebサイトといったソフトウェア・インターフェースに絞ったものです。12

言い換えれば、SolarisはRunwayの関心をメディア生成から、操作に反応する視覚環境の生成へ広げる試みです。そこにあるのは、ただ視聴する動画ではありません。ユーザーの行動を受け、操作が続く間、次の状態を再生成するシーンです。

RunwayがSolarisに期待すること

ソフトウェア制作の別ルート

この方式が十分に信頼できるものになれば、制作者は想定されるすべての状態や操作をコードで実装する代わりに、ビジュアル環境、商品、目的、振る舞いを自然言語で指定できるようになります。特に、空間的・視覚的・探索的な体験では、従来の固定的なUIレイアウトより魅力的な選択肢になる可能性があります。

ただし、柔軟性の源が明示的なプログラムロジックではなく生成に移る点には注意が必要です。本番ソフトウェアには、予測可能な動作、テスト可能性、データの完全性、アクセシビリティ、他システムとの連携が求められます。Solarisがこれらを従来のソフトウェア開発の代わりに担えることは、まだ示されていません。

AIエージェント向けの新しいインターフェース層

Solarisは、AIエージェントが未知のビジュアル環境を操作する方法にもつながる可能性があります。固定されたAPIやハードコードされた手順だけに依存するのではなく、エージェントがインターフェースを動的な世界として解釈し、操作し、変化した状態を観察しながら次の行動を選ぶという発想です。

既知の自動化スキーマを前提に設計されていない画面を扱うエージェントにとって、この方向性は大きな意味を持ちます。ただし、これはあくまで研究段階の構想です。監査可能性、精度、再現性が必要な処理では、信頼性の高い構造化APIや、従来型のアクセシブルなソフトウェアが依然として重要な利点を持ちます。

結論：Solarisは「コードの終わり」ではなく、生成UIの実験

Solarisは、アプリのコードを完全に終わらせる製品というより、生成型ソフトウェア・インターフェースの可能性を示す研究プレビューとして理解するのが適切です。

最大の特徴は、インターフェースそのものをモデルの出力にしたことです。言語モデルがユーザーの意図を解釈し、Gen-4.5を基盤とするビジュアルモデルが、操作に応じた次のフレームを生成します。

Runwayが報告した調査では、指示への追従や自然な操作感でSolarisが選ばれる場面がありました。しかし、文字の正確さ、事実性、長時間の一貫性、生成コスト、アクセシビリティ、システム連携といった問題は、単なる仕上げの課題ではありません。実際のソフトウェアに求められる中核的な要件です。

Solarisが示しているのは、インターフェースが「決められた画面」ではなく「その場で生成される世界」になり得るという未来です。同時に、なぜ従来のコード、状態管理、API、アクセシビリティの仕組みを置き換えるのが難しいのかも、はっきり浮かび上がらせています。