2026年8月31日に発表されたRunway Solarisは、RunwayがInterface World Modelsと呼ぶシリーズの第1弾です。一言でいうと、ソフトウェアをコードとして作ってから実行するのではなく、Solarisは操作に合わせてインターフェースそのものをフレームごとにライブで生成します。HTMLもCSSもコードも裏にありません。画面に映る画像そのものがアプリケーションです。
RunwayのGen-4.5動画モデルをベースにしており、何を起こすかを決める言語モデルと、それがどう見えるかを描画するワールドモデルを組み合わせ、720pでのリアルタイム操作を目指しています。Runway自身のユーザー調査では、Claude Opus 5が作ったコード製インターフェースに対し、指示への従い方で61%対24%、自然な振る舞いで71%対21%の割合でSolarisが選ばれました。
ただし落とし穴があります。これは製品ではなく研究プレビューです。価格も公開APIもなく、アクセスはリクエスト制のみです。これまでの反応はすべてデモ動画に対するもので、実際に触ったものではありません。最も鋭い懐疑派はすでに2つの妥当な問いを投げています。ストリーミング生成のコストで事業として成り立つのか、そして出力を信頼できるのか、です。サポートの仕事をしているなら、重要なのは後者の信頼の問題であり、ヘルプデスク向けのAIチームメイトが実際の顧客に触れる前に解決しなければならない、まさにその課題です。
Runway Solarisとは何か
まず整理しておきたいのは、発表当日の多くの論評がこの点を曖昧にしていることです。Solarisは新しいテキストから動画へのツールではなく、AIがコードを書いてくれるLovable型のアプリビルダーでもありません。そのどちらよりも奇妙なものです。
AI動画生成で最もよく知られるRunwayは、現在は自らを"building foundational Real-World Intelligence that can understand, simulate and act in the world"と説明しています。SolarisはInterface World Modelsと呼ぶ新ファミリーの第1号で、冒頭の問いかけは本物の思考実験です。オペレーティングシステムが、使っている最中にアプリやウェブサイトを生成したらどうなるか?
通常のアプリでは、デザイナーのアイデアがコードに翻訳され、コードが出荷され、その後アプリは誰かが想定して書き残したことしかできません。Runwayの主張は、この翻訳の工程には損失があるというものです。それは"a lossy compression of the space of possible interactions, frozen before any user arrives." Solarisはこれを飛ばします。中間表現はありません。モデルがインターフェース層を直接描画し、"every frame is synthesized as you interact, allowing the interface to respond continuously to your actions."
デモの例を見ると具体的に分かります。自分の写真にシャツをドラッグして試着できる仮想の衣料品店。材料をボウルにドラッグして作るサラダ。物理的にもっともらしい結果で反応する燃焼のデモ。そして投稿の中で私がいちばん気に入っている"redefining the mouse"という枠組みです。猫をクリックするとその毛並みがブラシになり、絵画をクリックするとその画風で描けます。これらの操作はどれもコーディングされていません。モデルが学習したのです。
Runwayの研究を追ってきたなら、これは汎用ワールドモデルであるGWM-1に続く論理的な次の段階で、Gen-4、Gen-4.5、GWM-1、そしてSolarisという確かな系譜の中にあります。古いモデルのマーケティング上の名称変更ではありません。
Solarisの仕組み:2つのモデルと1つの画面
ここが私にとっていちばん面白い部分です。謎めいた新アーキテクチャではなく、すでにあるものの巧みな再利用だからです。
2つのモデルが2つの仕事をします。言語モデルがリクエストを解釈し、操作が現在のシーンを変更するのか新しいシーンへ遷移するのかを判断して、描画を導くプロンプトを生成します。続いて、Gen-4.5をベースにしたワールドモデルが、その動作が実際にどう見えるかを生成します。Runwayの言葉では、"one decides what the application should do next, while the other generates how that behaviour appears."
録画済みのクリップではなくインタラクティブにしている工夫は、入力の扱い方にあります。クリック、ドラッグ、編集は、テキストや画像と同じように、次のフレームへの条件付けとして入力されます。モデルは起きた後の操作だけを見るので、誰もその関係をプログラムしなくても、操作とその見た目の結果の関係を学習します。
動画モデルをライブに感じられる速さで動かすには、3つの工夫が必要でした。各フレームが過去のフレームだけに依存するよう自己回帰的にフレームを生成させること、遅い多段階のノイズ除去を少ないステップに蒸留すること、そしてその高速版を自身の出力で学習させて、長いセッションでも品質を保つことです。Runwayは、操作が"stop feeling interactive somewhere around half a second of delay,"という地点を基準に置き、リアルタイム化によってSolarisの実行コストが標準的な動画拡散モデルより桁違いに安くなったと主張しています。ただし、公開されていない点も指摘しておくべきです。フレームレート、パラメータ数、コンテキスト長、モデルサイズはいずれも非公開です。分かっているのは設計目標であって、裏付けではありません。
誰もが反応しているデモ
Solarisは研究レポートと限定テストとして公開されたため、反応はデモへの反応であり、感嘆と眉をひそめる反応にはっきり分かれます。
感嘆の側では、日々生成ツールを使っているクリエイターが、Solarisのやっていることをすぐに理解しました。
"Very cool work by Runway. Feels like the best of both worlds -- fine grain control of a WYSIWYG editor with the creativity & speed of generative models."
RunwayのCTOであるAnastasis Germanidisは発表スレッドを投稿し、約1,000件のいいねを集めて議論の中心になりました。Hacker Newsでは、あるコメント投稿者が"one of the most innovative and coolest AI model demos I've seen this year"と評しました。デモに事欠かない年にあっては高い評価です。
しかし、より役に立つのは継ぎ目をつつく意見です。r/UXDesignのあるデザイナーは、「説明するのではなく見せる」という操作は古い発想で、研究者は何十年も前から実演によるプログラミングについて書いてきたと指摘しました。新しいのは描画であって、操作モデルではないということです。そしてHacker Newsからは、私が何度も思い返す最も鋭い分析的な問いが出ました。
"So, instead of inferring intent from an information-dense input (text), they do it w/ just mouse-based gestures? ... I would love to see how this holds up in practice."
この「実際にどう持ちこたえるか」は重い問いで、勘どころは正しいです。デモ動画は選び抜かれた理想の道筋にすぎません。面白いのは最初の30秒ではなく、実際のセッションの10分目です。
Solaris対コード製インターフェース:数字は何を示すか
Runwayは動画と雰囲気だけを出したわけではありません。2つの調査を行っており、その数字が発表の最も強い部分です。
主要な調査では、Solarisを、最先端モデルであるClaude Opus 5が作ったコード製インターフェースと、同じ開始画像と同じ操作リクエストで比較しました。参加者250人、約7,500件の一対比較の結果は次のとおりです。
| 質問 | Solarisが選ばれた割合 | コード製インターフェース | 同等 |
|---|---|---|---|
| どちらが指示によりよく従うか? | 61% | 24% | 13% |
| どちらがシーン内でより自然に振る舞うか? | 71% | 21% | 6% |
2つ目の調査は、Runwayが"the cost of translation,"と呼ぶもので、思想を説明するものです。GPT-4o、Gemini 2.5 Pro、Claude Fable 5を含むマルチモーダルモデルが、1枚のスクリーンショットからどれだけ忠実にインターフェースを再構築できるかを、30のインターフェースで調べました。結果は、どのモデルも翻訳で情報を失い、視覚的な複雑さが増すほど悪化するというものです。これはRunwayの主張全体を1つの実験に凝縮したものです。コードは損失のある中間工程だから、取り除くという考えです。
正直な注意点が2つあります。これらはRunway自身の調査であり、独立したベンチマークではなく、照合できる第三者の数字もまだありません。また、「一対比較のデモで好まれた」ことは「出荷できるほど信頼できる」ことと同じではなく、懐疑派が周りを回っているのはそのギャップです。
懐疑派の指摘が当たっているところ
Solarisには公平でいたいと思います。これは本物の研究で、デモも印象的だからです。ただ、2つの批判は強力で、誇大広告のすぐ隣に置く価値があります。
1つ目は経済性です。私が見つけた最良の批判的コメントはr/accelerateからのもので、全文を読む価値があります。
"I like this a lot but I'm skeptical that people are going to want to pay ongoing generation costs for their app to function versus just having a coded app... if it requires your company stream dolla dolla bills directly to runway at all times to run your app I'm not seeing this as a feasible business model. Your economics would scale up with engagement, not a good situation to be in."
Runwayは、リアルタイム化によってSolarisが標準的な動画拡散より大幅に安くなり、"the cost curve continues to improve."と述べています。しかし、代替手段がほぼ無料で動くコードである以上、「動画生成より安い」というのは低いハードルです。コストは、速度、長いセッション全体での一貫性と並んで、Runway自身が挙げる3つの技術的課題の1つです。
2つ目は信頼で、Runwayが最も率直に認めている点です。自社の制限事項の節にはこうはっきり書かれています。"a convincing wrong answer is worse than no answer." 生成されたインターフェースは、正しく見えるのに正しくないもの、たとえば価格、商品の詳細、見た目どおりに動かないボタンを描画してしまうことがあります。Runwayは、セッションが進む間もSolarisを検証済みのコンテキストに固定し続けることは"an active research focus"だと述べており、これは研究者らしい丁寧な言い方で、まだ解決していないということです。Hacker Newsのある人は、以前のワールドモデルのデモと比べて、実用面をもっとはっきり言いました。
"it looks cool at first but really quickly you'll start to see the gaps"
カスタマーサポートを運営しているなら、Solarisは何を意味するか
ここから、これはAI動画の話ではなく、実際のユーザーにAIを届けるすべての人に関係する話になります。
Runwayは、顧客体験にそのまま当てはまるユースケースを示しています。ストアが生成された環境になり、ブランドのアイデンティティを保ちながら、商品、レイアウト、おすすめを訪問者ごとにリアルタイムで調整するというものです。インターフェースの行き先として本当にわくわくする絵です。しかし、Solarisで最も難しい未解決の問題、つまり誤ったものを自信満々に表示しないよう出力を検証済みデータに結びつけることは、サポート向けAIが最初から向き合ってきた問題そのものです。
私は何年もヘルプデスク向けのAIエージェントを作ってきましたが、最も重要な教訓は、Runwayが自社の制限事項の節に書いたとおりのものです。自信ありげに間違えるサポートボットは、「人間に代わります」と言うボットよりも害が大きいのです。だからこそ、サポートにおけるAIのハルシネーションは最後ではなく最初に対策すべきものであり、私たちは顧客にライブで回答する前に、企業の過去の実チケット数千件でロールアウトごとにシミュレーションしています。答えが根拠に基づいているかは本番で知るのではなく、すでに解決を知っているチケットで確かめます。
だから私はSolarisのようなモデルをこう読みます。魅力的なインフラであり、インターフェースが生成される方法の新しい土台です。しかし、インフラは従業員ではありません。何でも描画できるモデルでも、特定の仕事を任されるには、ガードレール、根拠づけ、ドメインのコンテキストが必要で、それはピクセルを動かすこととは別の領域です。
eeselを試す
この隙間を埋めるために作られているのがeeselです。Runwayがモデル層を作る一方で、eeselは仕事のために採用するAIチームメイトで、現在のラインナップはAIヘルプデスクチームメイトとAIブログライターです。それぞれが自分の役割に必要なスキル、連携、会社のコンテキストを備えた状態で届くため、自分で配線しなければならない素のジェネラリストではありません。
特にサポートでは、ヘルプデスクチームメイトは、Zendesk、Freshdesk、Gorgias、Slackなど、すでに使っているツールに接続し、過去のチケットやヘルプセンターから学習します。そして何より、顧客に一度も返信する前に、実際の過去チケットでシミュレーションできます。これは、Solarisがようやく名前を付け始めたばかりの信頼の問題を、もっともらしい誤答が許されない仕事に対して解決したものです。無料で試せ、数分で自分のチケットに対する実際の回答案を確認できます。