Sora APIを利用するシステムには、2026年9月24日という移行期限があります。一方、Runwayが8月31日に発表したSolarisは、操作に応じて画面を生成し続ける「Interface World Model」という方向を示しました。

この2つのニュースを、単純な動画モデルの交代として捉えると、必要な作業を見誤ります。Soraを使う既存機能には代替経路の検証が必要です。Solarisを検討するなら、生成された画面とアプリケーションの状態をどう対応させるかが問題になります。

以下は2026年9月8日時点の公開資料に基づく整理です。Solarisの実機検証や移行の実績報告ではありません。

Soraの終了日とデータの書き出しを分けて確認する

OpenAIの公式資料では、SoraのWeb版・アプリは4月26日に終了しています。Videos APIと、一覧に記載されたSora 2のモデルは9月24日に停止予定です。Deprecationsの推奨移行先欄には、代替モデルが指定されていません。

確認対象は、コード中の sora-2 と sora-2-pro だけではありません。日付付きのモデル指定、定期実行ジョブ、社内ツール、設定ファイルも含めて洗い出します。

動画の保存も別の作業です。APIで作った成果物が自社のストレージに残っているかを確認し、SoraのWeb版・アプリで作成したコンテンツは公式案内に沿って書き出します。最後の書き出し期間が設けられる場合はメールで通知されるため、「9月24日まで待てる」とは判断しない方がよいでしょう。

動画ファイルと生成式インターフェースでは、完了の意味が違う

通常の動画生成では、出力されたファイルを確認し、採用するかどうかを決められます。途中の生成に試行錯誤があっても、納品する時点で結果を固定できます。

Runwayの説明では、Solarisはクリックやドラッグを次のフレームの生成条件として扱います。言語モデルが振る舞いを導き、動画モデルが画面を描く構成です。

この違いを設計上の問いにすると、次のようになります。

これはSolarisの公開仕様表ではなく、2種類の機能を評価するための整理です。後者では、見た目を確認した直後にも、次の操作によって新しい問題が起こり得ます。

仮に、生成された売り場の画面で商品を選び、購入する機能を考えます。

画面に「購入完了」と表示されても、それだけでは注文レコードが保存された証拠になりません。ここで確認したいのは、表示と処理結果の対応です。

仮のテストケース	確認したい結果
商品を2点入れ、1点を削除する	保存された明細と画面上の数量・合計が一致する
確認操作の直後に接続が切れる	再接続後も処理結果を確定でき、意図せず二重注文にならない
マウスを使わず操作する	キーボードや支援技術からも同じ操作と結果確認ができる

これらは実施済みのテストではありません。生成式インターフェースを業務に使うなら、試作段階から確認したい条件です。

試作する場合、まず操作を受け付ける範囲を絞り、確定したデータと生成表示を照合できるようにします。失敗時に通常の確認画面へ戻れる設計にしておけば、何が改善し、何が不安定になったかを評価しやすくなります。

既存の動画生成機能については、まず入力から保存までの経路を確認します。代替候補に同じ参考画像を渡せるか、必要な音声や尺を指定できるか、待機中・失敗時の処理を実装できるか。画質の比較だけでは決められません。

例えば、reAPIの統合AI APIは画像・動画などのモデルをプログラムから利用するための接続先です。ただし、共通のAPIを使う場合でも、モデルごとの入力条件や出力の違いは検証する必要があります。APIをまとめることと、生成結果の互換性を保証することは別の話です。

一方、人が画面上で動画を作り、編集して仕上げる作業なら、ClipDanceのブラウザ型AI動画生成ツールのような制作画面が比較対象になります。プログラムによる一括処理が必要なのか、手動で選んだ1本を納品できればよいのかで、試す項目も変わります。

代替候補を試す際は、代表的な依頼を少数選び、採用条件を先に書いておくと判断しやすくなります。必要な成果を同じにして、送信形式は各モデルの仕様に合わせます。古いリクエストをそのまま送れたかどうかだけを評価基準にしないことが大切です。

RunwayはSolarisについて、文字の安定性、情報への根拠付け、長いセッション、アクセシビリティなどを課題として挙げています。公開ページでは早期アクセスの申請を受け付けていますが、既存APIの移行手順が示されたわけではありません。

検討を始めるなら、予約や購入の確定処理よりも、間違いを取り消せる限定的な操作から試したいところです。例えば家具配置の試作なら、選んだ家具が途中で別の商品に変わらないか、操作を取り消せるか、最後に選択内容を確実に確認できるかを評価します。これは導入時期の予測ではなく、試すための条件です。

Sora APIの終了に向けて必要なのは、いまの機能を継続できる経路を確保することです。Solarisをきっかけに考えたいのは、生成された画面を、どこまで操作と結果の確認に使えるかという設計の問題です。先にこの区別をつけると、移行作業と研究用の試作に、それぞれ明確な完了条件を置けます。