Runway Media Router、単一エンドポイントで画像・動画・音声生成モデルへのリクエストを振り分け

Runwayは、開発者向けプラットフォームRunway DevでMedia Routerの提供を開始した。これにより、従来はアプリケーション側でモデルを指定していた生成リクエストが、「制約を設定し、単一のエンドポイントを呼び出し、プラットフォームにモデル選択を任せる」フローへと変わる。初期バージョンは動画、画像、音声をすべてカバーし、RunwayのGen-4.5、Aleph 2.0、Act-Twoに加え、Seedance、GPT Image 2、ElevenLabsなどのサードパーティモデルにも振り分けられる。

開発者はまず、再利用可能なルーティング設定を作成し、生成1回あたりの価格上限、モデルまたはプロバイダーのallow/deny listを指定したうえで、コスト、品質、レイテンシーの優先度を設定する。リクエストには設定IDを含めるだけでよく、モデル名をハードコードする必要はない。ルーターは最初にモダリティ、必須機能、ハード制約に基づいて不適格なモデルを除外し、残った候補をスコアリングする。レスポンスでは生成結果に加え、実際に使用されたモデルと選択理由も返される。制約によってすべての候補が除外された場合、APIは明示的にエラーを返し、価格やプロバイダーに関するルールを独断で緩和することはない。

注目すべき点として、Media Routerは生成を実行せず、コストも発生しないdry-runモードを提供する。これにより、チームはデプロイ前に、特定のリクエストがどこへ送信されるかを確認できる。これは、データレジデンシー、承認済みプロバイダー、予算制約が関わる企業のワークフローで特に重要であり、モデルカタログの頻繁な更新に伴うアプリケーション改修コストの削減にもつながる。プレビューと最終出力に異なる設定を使うこともできる。前者では低レイテンシーを重視し、後者では品質の重みを高められる。

メディアのルーティングは、テキストモデルよりも検証が難しい。「品質」がプロンプト、ビジュアルスタイル、キャラクターの一貫性、時間的安定性、音声と映像の同期によって変化するためだ。Runwayは、評価器がルールベースなのか、人間の選好を学習したモデルなのか、オンラインフィードバックシステムなのかを明らかにしていない。また、固定的なモデル選択と比較したルーティングの成功率、コスト削減率、テールレイテンシーも公表していない。そのため、エンジニアリングチームはモデル選択理由を品質保証とみなすべきではない。本番導入前に、基盤モデルのID、入力、出力を引き続き保存し、独自のオフライン評価とフォールバック戦略を構築するとともに、サードパーティモデルの更新が既存ワークフローの再現性を変化させないか確認する必要がある。