Runway Enhance Frame RateがDev APIで提供開始：24～120 fps、NTSC対応

Runwayは2026年9月17日、新しいフレーム補間モデルを開発者向けAPIに投入しました。実際に重要なのは対応範囲の上限ではなく、非整数フレームレートの方です。Runway Enhance Frame Rateは、手持ちの映像を24、25、30、48、50、60、120 fpsのターゲットにリタイムし、放送と映画が実際に採用している3つのフレームレート、23.98、29.97、59.94にも対応しています。Runway自身の開発者向け変更履歴では、このモデルはenhance_frame_rateとして文書化されており、同社がクリエイティブアップスケーラーにすでに使用している同じPOST /v1/video_upscaleエンドポイントを通じて呼び出され、1ジョブあたり入力300秒までに制限され、2秒あたり1クレジットで課金されます。

その課金行は2つ目の驚きです。フレーム補間は通常、出力単位で価格設定されます — Runway自身のMagnific Video Upscalerは、同じエンドポイントで720p/1Kの出力フレームあたり0.7クレジットを課金します — つまり、24 fpsから120 fpsへの変換は、24から25への変換の5倍のコストがかかります。enhance_frame_rateは、秒単位の課金です — 対象は入力。5倍のフレーム乗算と1.05倍のフレーム乗算では、コストがまったく同じです。複数のフレームレートで1本の映像素材を納品することが仕事なら、価格表のそのたった1行が通常の算術を覆します。

タイミングもまた示唆的だ。RunwayのスタンドアロンのFrame Interpolationツールは同社公式の非推奨ツール一覧に掲載されており、その代替としてAnimate Keyframesアプリが挙げられている。Enhance Frame Rateはそのウェブツールの復活ではない。それはAPIモデルとして再構築されたフレーム補間であり、タイムラインをクリックして操作する人ではなく、パイプラインに向けられている。

Enhance Frame Rateが実際に行うこと

これはリタイミングモデルであり、生成モデルではありません。プロンプトも画像も参照クリップもありません。既存の動画——カメラからでも、編集からでも、別の Runway モデルからでも——を渡すと、目標レートに到達するために必要な中間フレームを合成します。Runway の自社 X アカウントでの発表も同じように表現しています。「あらゆる映像を、必要な仕様に変換します」。

仕組みとしては、これはビデオアップスケールエンドポイント上の非同期タスクです。動画URIをPOSTし、model: "enhance_frame_rate" を設定すると、タスクIDが返ってくるので、結果をポーリングします。Runwayのアップスケーラーと同じエンドポイントを共有しているため、すでに /v1/video_upscale と通信しているパイプラインでは、新しい統合ではなくパラメータの変更が必要です。

Runwayの変更履歴には、以下が現在のベンダー公表仕様として記載されています。ただし、そのいずれも独立に検証されたものではありません。このモデルに関するサードパーティのベンチマークは存在せず、執筆時点で公開からわずか1日しか経っていません。

• ターゲットレート — 24、25、30、48、50、60、120 fps、さらに 23.98、29.97、59.94 fps（API では 23_98、29_97、59_94 と表記）

• 入力制限 — ジョブあたり300秒

• 料金 — 入力2秒につき1クレジット、Runway APIクレジットは1つあたり$0.01

• アクセス — Runway Dev で、model: "enhance_frame_rate" を指定して POST /v1/video_upscale

• Runway における先行事例 — 2024-11-06 の API バージョンには frame_interpolation_v1 タスクタイプが存在していた。単体の Web Frame Interpolation ツールは非推奨となっている

• 独立評価 — 公表なし

フレームレートのはしご、そしてなぜ23.98が本当の主役なのか

コンシューマー向けの補間ツールはすべて整数レートを提供しています。ここで興味深いのは分数レートの列です。なぜなら、配信仕様が実際に示しているのは分数レートだからです：

23.98（23.976）— NTSCフィルムレート。ほぼすべてのシネマおよびストリーミングマスター、ならびにDVDとBlu-rayがオーサリングされた際の基準レート。

• 24 — 真のフィルムレートで、現在もDCPや多くの映画祭納品物に使用されています。

• 25 — PALおよびEBU地域：英国、ヨーロッパの大部分、オーストラリア、アジアとアフリカの広範囲。

• 29.97 — NTSC放送、30の端数的な兄弟。

• 30 — 画面キャプチャ、ウェブ、ゲーム映像向けの整数フレームレート。

• 48 — ハイフレームレート映画（『ホビット』三部作が撮影・上映されたフレームレート）。

• 50 — PAL高フレームレート、ちょうど2×25。

• 59.94 — NTSCの高フレームレート。米国と日本における60 Hz放送の送出レート。

• 60 — 整数の60 Hz。滑らかなWeb再生のための一般的な目標値です。

• 120 — スローモーション、およびハイリフレッシュ配信。

24 と 23.976 の差は取るに足らないように見えるが、そうではない。1時間の再生時間で、両者はおよそ3.6秒ずれる。24.000のマスターを23.98の納品チェーンに投入すると、音声同期のドリフトとケーデンスエラーが発生し、放送QCで不合格になる——だからこそポストプロダクションは歴史的に、レートをリサンプリングするために別途コンフォーム工程を実施してきたか、その仕事を断ってきた。小数レートを直接出力するツールは、そのチェーンから1工程を取り除く。それは「120 fps」よりもはるかに狭く、はるかに退屈な主張だが、放送局に納品する人なら誰にとっても、気にかける理由はそこにある。

48と120という目標値は、実際には懐疑的に見るべきものだ。24 fpsの素材を120 fpsに補間することは、実フレーム1枚につき4枚のフレームを作り出すことを意味し、速い動き、オクルージョン、強いモーションブラーでは、あらゆる種類の補間器がゴースティングやワーピングを生じる。Runwayはアーティファクト分析も、他のどの補間器との比較も、ショットごとの品質ガイダンスも公開していない。したがって正直な立場は、仕様上は120をサポートしているということであり、あなたの映像で120がどのように見えるかは未検証だ。

費用はいくらか、計算して説明します

計算が異常なほどすっきりしているのは、単位が入力秒数だからだ。Runwayの開発者向けAPIでは2秒あたり1クレジット、1クレジットあたり$0.01（前払い、1,000クレジットで最低$10）という条件では：

• 10秒のクリップ、任意のターゲットレートで — 5クレジット、約$0.05

• 30秒のクリップ — 15クレジット、約$0.15

• 60秒のクリップ — 30クレジット、約0.30ドル

• 5分のクリップ、上限は300秒 — 150クレジット、約1.50ドル

• 90秒のクリップ、24 → 25 fps — 45クレジット、約$0.45

• 同じ90秒のクリップ、24 → 120 fps — 45クレジット、約0.45ドル

最後の2行が価格設定の議論のすべてだ。出力フレーム単位のモデルでは、2番目のジョブはフレーム数が5倍になり、したがって請求額もおよそ5倍になる。ここでは無料だ。

同じエンドポイント上の隣接サービスとの比較が、その点を具体的に示している。Magnific Video Upscaler は出力フレームごとに課金され、720p/1K で 0.7 クレジット、2K で 0.9、4K で 1.2、1 回の生成につき最低 1 クレジットが必要だ。10 秒、30 fps のクリップは 300 出力フレームになるため、720p/1K の料金では 210 クレジット、約 $2.10 になる。同じクリップを enhance_frame_rate で処理すると 5 クレジット、約 $0.05 だ。より大きな映像ではなく、より高いフレームレートを求める場合、アップスケーラーに手を伸ばすとおよそ 40 倍のコストがかかる。また、アップスケーラーのオプションである fps ブーストを有効にすると出力フレーム数が変わり、その請求額がさらに上がることにも注意してほしい — Runway の料金ドキュメントにも明記されている。

コスト面で一つ注意しておきたい点があります。ここで正式な情報源となるのは本記事ではなく、Runwayの開発者向け価格ページです。また、クレジット価格は2026年8月以降、カスタム価格への移行に向けて検討中と報じられています。大量のバッチを予算計上する前に、ポータルを確認してください。

300秒の上限と、その回避方法

すべてのジョブは入力が300秒に制限されています。ショットには十分な長さで、リールには短いため、それより長いものは分割する必要があります。そして、どのように分割するかは、上限そのものよりも重要です。

固定クロックではなく、シーン境界でカットする。補間器は隣接フレーム間の動きを推論する。ハードカットでは、ショットAの最終フレームとショットBの最初のフレームに動きの関係がまったくなく、カットを検出しないモデルはその間に平然とモーフをでっち上げる。Runwayの変更履歴には、このモデルの自動シーン検出についての記載がないため、存在しないと想定するのが安全だ。カット位置でチャンク化し、各チャンクを補間し、新しいレートでタイムライン上に再構成する。

その助言はRunwayに固有のものではない——それはどこでもAIリタイミングに関する標準的な注意事項だ。2025年のSMPTE論文は、AI支援ポストプロダクションに関するもので、23.976 → 25や29.97 → 23.976のような変換向けのTensorRT最適化補間パイプラインについて述べているが、同じ点を指摘している。フレーム変換されたコンテンツにはシーンカットでのフレームブレークと、その後のQCが必要であり、そうしなければモデルはつなぎ目をまたいでハルシネーションを起こす。最初のパスでは、難しいトランジション周辺で手動によるフレーム置換が必要になると想定してください。

代替案と比較した位置づけ

フレーム補間はしばらく前から、ある程度解決済みの問題でした。2つの形態があり、どちらもこれとは異なる見え方をします。

• デスクトップスイート — Topaz Video AIのApolloおよびChronosモデルは、品質重視のリタイミングにおけるリファレンスです。永続ライセンス、自分のGPU、秒単位の課金メーターなし、そして見るべきものを理解している人に報いるチューニングパス。

• オープンソースのインターポレータ — RIFEや類似のモデルなど — はセルフホスト型で、ハードウェアさえ持っていれば追加コストは実質ゼロであり、ポストプロダクション企業が自ら構築したカスタムパイプラインの大半の基盤となっている。

• Runway Enhance Frame Rate — ローカルでの計算は不要、API呼び出し、入力秒単位の課金、そして他の2つがこれまでずっと手作業でコンフォームさせてきた分数NTSCレート。

取引は明快だ。すでに所有しているワークステーションでの単発の作業なら、ローカルの補間ツールのほうが安く、Runway が公開していない調整項目も使える。自動化パイプラインの中で入ってくる素材や、同じクリップをある地域向けには23.98で、別の地域向けには25で出力しなければならない納品マトリクスの場合は、小数のフレームレートを直接返すAPIがあればコンフォームの工程を1つ削れる——しかも入力秒あたりの課金なので、複数レートの出力に追加費用はかからない。

それを取り巻くルーティング層

リタイミングは、どこかに言語モデルのステップが近くにあるパイプラインの1工程である。ショットリストとコンフォームノート、新しいフレームレートに合わせてリタイミングしなければならない字幕とキャプションの工程、地域ごとの配信メタデータ、QCログ——それはテキスト作業であり、ビデオパイプラインの中で誰も予算を取っていない部分である。

そのレイヤーはOrcaRouterカタログの200モデル全体にわたる1つのキーで動作し、プロバイダーの定価は0%のマークアップでそのまま渡され、プロバイダー間の自動フェイルオーバーも行われるため、より新しく、あるいはより安価なモデルを、本番経路をそれに賭けることなくライブトラフィックで試すことができます。範囲を正確に言うと、Runway Enhance Frame RateはRunway Dev APIのモデルであり、Runway自身のエンドポイントで呼び出され、OrcaRouterはそれを提供していません。私たちがカバーするのは、その周辺のすべてです。

まだ知られていないこと

品質についてはほとんど何も触れていない。このモデルは執筆時点でおよそ1日前に登場したばかりであり、その挙動について上述したことはすべて Runway 自身の変更履歴と発表に基づいている。具体的に未検証なのは次の点である:

• 高速モーション、オクルージョン、モーションブラー、低ビットレートソースにおけるアーティファクトの挙動 — 誰も公開されたテストを行っていない

• シーンカットを自動的に検出するのか、それともそれらをまたいでブレンドするのか

• フレームレートが変更されたときに、オーディオがそのまま通されるか、リサンプリングされるか、破棄されるか

• 品質面で RIFE、Apollo、Chronos とどう比較されるか — 直接比較は存在しない

• 目標レートが上昇しても入力1秒あたりの価格が据え置かれるのか、それとも後から段階が再設定されるのか

120 fpsと48 fpsのターゲットは、自分の映像を実際に通してみるまでは主張として扱い、最初に送るクリップでカット処理を確認してください。

今、誰が動くべきでしょうか

放送や複数地域の仕様に納品していて、現在コンフォーム工程に費用を払っているなら、今すぐ移行を。映像がすでに自動パイプラインを通っていて、API呼び出しをもう1回吸収できるなら、あるいはハイスピード撮影をしていないカメラからスローモーションを得たいのにGPUを回したくないなら。

1回のジョブで5分を超える必要があり、カットで分割できない場合、解像度も上げる必要がある場合——それはアップスケーラーで、価格はフレーム単位——あるいはすでにデスクトップ用の補間ツールを持っていて、これが一度きりのショットなら、待とう。そして、利便性よりも品質が決め手なら待とう。Runway以外の誰も数値を公表しておらず、最初の独立した比較こそ、待つ価値があるものだ。

注目すべきパターンは、Runwayがこのエンドポイントをモデルごとに拡張し続けるかどうかだ。すでにクリエイティブ・アップスケーラーを搭載し、今度はリタイマーも加わった。どちらも POST /v1/video_upscale 上にあり、料金体系はまったく異なる単位に基づいている。配信パイプラインを構築する人にとって、設計の軸にすべきは、出力フレームではなく入力秒数という単位だ。