AI動画生成API：ジョブ、モデル、コスト

チャットの応答は400ミリ秒で返ってくるので、動画も同じように処理しようとします。つまり、1回のPOST、待機、バイトの収集です。4分後、接続はタイムアウトし、クリップは結局完成するものの、誰も回収しなかったジョブに料金を支払ってしまいます。

そのギャップこそが、ほとんどのAI動画生成APIプロジェクトが失敗する原因です。ドキュメントは動画を遅いチャットモデルのように見せかけ、料金表は、生成された映像の1秒が常に手元に残る単位であるかのように、1秒あたりのセントを比較するように促します。市場は十分に急速に拡大しており、その間違いが拡大しています。Research and Marketsは、世界のAI動画生成・編集市場を2024年には623百万米ドルと評価し、18.64%の年間平均成長率で2034年までに3.51億米ドルに達すると予測しています (Research and Markets、2024月)。

役立つ問いは、どのAPIが1秒あたり最も安いかではありません。それは、失敗や再試行、そして4回の試行を必要としたモデルを経て、利用可能で、ダウンロードされ、アーカイブされた1つのクリップがいくらかかるか、ということです。

目次

• 動画生成機能とリクエストタイプ
• 動画ジョブが送信からファイルになるまでの流れ
  • 健全なジョブログの様子
• 完了した動画結果のポーリングまたはWebhook
• ユースケースに応じた動画モデルの選択
• 利用可能なクリップあたりのコストと表示価格の比較
  • 料金表に記載されていないこと
• 確認すべきリクエストフィールドと出力メタデータ
  • 完了したタスクごとに保存すべき出力フィールド
• 既存のSDKコードへの動画生成の統合
  • 薄型動画サービスの4つの部分
• 本番環境での障害と重複の防止方法
  • 自動フェイルオーバーがコストを増大させる理由
• コミットする前にモデルのベンチマークを実行する

動画生成機能とリクエストの種類

チャットの返信は1つのメッセージです。動画ジョブは後で届くファイルであり、選択するリクエストの種類によって、プロバイダーが何を生成し、何を返すかが決まります。

テキストから動画へは最も純粋な形式です。プロンプトとモデル識別子を送信すると、モデルが説明からすべてのピクセルを生成します。画像から動画へは参照画像を追加します。そのため、被写体、フレーミング、ライティングは画像から取得され、プロンプトが動きを提供します。このたった1つの変更により、テキストのみのクリップでは製品ショットやキャラクターの作業に利用できないような、アイデンティティのずれのほとんどが解消されます。

動画アップスケーリングは、コンテンツが固定され、解像度のみが変更される唯一の種類です。そのため、コスト計算が最も簡単で、間違いが最も起こりにくいです。音声は2つに分かれます。一部のモデルは、音声をオンにすると映像とともにサウンドトラックを返します。一方、音楽と効果音は、同じリクエスト形式とジョブメカニクスを使用する別のモダリティです。

すべての行に3つの入力が表示されます。プロンプトまたはソースメディア、モデル識別子、および希望する長さと解像度です。これら3つを早期に独自のリクエストスキーマに組み込むことで、後でプロバイダーを交換する際に設定変更で済むようになります。

何かを構築する前に、タイミングの期待値を設定してください。チャットの返信は数秒で届きますが、動画リクエストはまず受け付けられ、後で完了します。通常の実行には30秒から数分かかります。すぐに返される応答はジョブであり、クリップではありません。

動画ジョブが提出からファイルになるまで

実運用可能なすべての動画APIは、ある一つのパターンに従います。それはOpenAIがそのvideo API guideで文書化しているパターンです。ジョブを作成し、そのステータスを読み取り、ステータスが最終的な成功状態に達したらコンテンツを取得します。このフローは非同期ジョブシステムとしてモデル化し、同期的なメディアダウンロードとして扱わないでください。

1. リクエストを送信する。 プロンプト、モデル識別子、期間、解像度を送信します。レスポンスにはジョブIDと、queued（キュー済み）などの初期ステータスが含まれます。他のことをする前にこれを保存してください。そうしないと、プロセスが再起動した場合に、すでに支払った作業に対する唯一のハンドルを失ってしまいます。
2. ジョブIDを独自のレコードにマッピングする。 内部リクエストID、それが属するユーザーまたはテナント、送信したパラメーター、および販売者またはプロバイダーのルートを保持してください。3日後に請求に関する質問が来た場合、この行がその答えとなります。
3. ステータスリソースを監視する。 ポーリングするか、イベントを待機し、各遷移をタイムスタンプとともに記録します。queued（キュー済み）、running（実行中）、succeeded（成功）、failed（失敗）。queuedとrunningの間のギャップはキュー待機時間であり、モデルとは関係のない「モデルが遅い」という苦情を説明する数値です。
4. 最終状態を待つ。 成功と失敗はどちらも最終状態です。タイムアウトは最終状態ではなく、接続切断も同様です。したがって、どちらも結果として扱わないでください。
5. 成功時のみファイルをフェッチする。 コンテンツの場所をリクエストし、独自のストレージにstreamingし、チェックサムを記録します。失敗時にこれを行うと、呼び出しが無駄になり、実際のエラーをダウンロードの問題として隠蔽してしまう可能性があります。
6. 失敗時にエラーを読み取る。 修正がパラメーターの変更、異なるモデル、またはユーザーへのメッセージのいずれであるかを判断します。コンテンツが拒否された後に同じパラメーターを再送信しても、単にお金を無駄にするだけです。

健全なジョブログの例

1つのジョブID、queuedからrunning、succeededへのクリーンな実行、そして正確に1回のダウンロード。ログ内のそれ以外のものは、測定可能なバグです。2回のダウンロードは、重複排除しなかった重複webhookを意味し、クライアントが諦めた後に記録された成功は、調整（reconciliation）が必要であることを意味します。

独自のジョブレコードで、cancellation（キャンセル）、timeout（タイムアウト）、retry（再試行）、expiration（有効期限切れ）を定義してください。これらのセマンティクスは、クリップをレンダリングしたアップストリームではなく、あなたのgatewayに属します。呼び出し元がレンダリング中に切断した場合でも、ジョブを完了させ、後で調整してください。cancellationは、たまたま閉じたHTTP接続ではなく、あなたが送信する明示的なステータス変更です。

完了動画の結果に対するポーリングまたはウェブフック

どちらのシグナルも同じ疑問を解決しますが、追跡する主体が異なります。ポーリングとは、ジョブがターミナル状態に達するまで、コードがステータスリソースを繰り返し読み取ることを意味します。ウェブフックとは、プロバイダーが完了または失敗イベントであなたを呼び出し、あなたのエンドポイントが反応することを意味します。

数分で完了する生成の場合、イベントはコストとレイテンシーの両方で優れています。数秒ごとにすべてのジョブをポーリングすることによるリクエスト量は、キュー全体で累積され、同じトラフィックが次のインターバルまで検知を遅らせます。直接APIポーリングに対するウェブフックの比較]では、各パターンがどこに適合するかが示されています。

ハンドラーは、以下の5つのチェックをこの順序で実装してください。

1. プロバイダーが署名を提供する場合、署名を検証し、署名されていない配信はエッジで拒否します。
2. ダウンロード、請求、または通知作業が実行される前に、プロバイダーのジョブIDに対してイベントを永続化します。
3. 同じ完了イベントが正当に2回到着する可能性があるため、at-least-once配信を前提とします。
4. 2回目の配信が保存されたターミナル状態を確認し、ダウンロードと請求をスキップするように、ハンドラーを冪等にします。
5. 盲目的に再試行されるタイムアウトとしてではなく、失敗イベントを実際の結果として処理します。

次に、セーフティネットを追加します。測定されたレイテンシーから設定された期限までにイベントが到着しない場合、15秒から開始し、60秒に向けて延長しながら、バックオフを伴ってジョブIDをポーリングします。起動前に両方の失敗パスをテストしてください。重複イベントを強制的に発生させ、次にイベントを完全に抑制し、ユーザーが最終的に1つの動画と1回の請求で終わることを確認します。

実用的なルール： ウェブフックはハッピーパスのための最適化です。システムを正しくするのは、あなたの調整ポーリングです。

ユースケース別ビデオモデルの選択

リーダーボードを見る前に、必要なモダリティ、最大の長さと解像度、音声サポート、測定された生成時間、そしてプロバイダーが請求するコスト単位という5つの基準で候補を絞り込みましょう。これら5つは、どんな品質ランキングよりも速く、ほとんどの候補を除外できます。

コスト単位は数値と同じくらい重要です。秒あたりの価格は可変長のクリップに適しており、長いクリップには不利ですが、ジョブあたりの価格は固定長のクリップを予測可能にし、より長いクリップを無料にします。同じ長さと解像度で2つのモデルを比較しないと、その比較は意味がありません。

生成時間は、そのモデルをユーザーの前に提示できるかどうかを決定します。2026年10月29日でのテストでは、5秒のKling 3.0クリップの生成に約80秒かかりました。これは短いクリップとしては立派ですが、進捗状況のないスピナーの裏に隠すことは不可能です。80秒かかる5秒のクリップには、目に見えるステータス、推定待ち時間、そしてページを離れて後で戻る方法が必要です。

この順序で2つか3つのモデルに絞り込みましょう。まずモダリティ、次に解像度とオーディオ、そして許容できる速度とコスト単位です。デフォルトを選んだ後でも、少なくとも1つのフォールバックを候補リストに残しておきましょう。視覚スタイルに合うモデルでも、インターフェースには遅すぎる場合があります。そのような事態になったときのために、代替案はすでにベンチマーク済みであることが望ましいです。9つのベンダーアカウントを開設するよりも、単一のエンドポイントを通じて利用可能なAIモデルの全リスト]から候補を絞り始めるのが妥当です。

利用可能なクリップあたりのコストと広告価格の比較

広告されている1秒あたりの料金は、1回の試行にかかる費用を示しています。しかし、利用可能なクリップ1つにかかる費用については何も語っておらず、それはあなたの財務チームが気にする数字です。

具体的なケースで計算してみましょう。1秒あたり$0.10で、5秒のクリップは1回の試行あたり$0.50かかります。4回の試行のうち1回が品質基準を満たす場合、承認されたクリップのコストは**$2.00です。競合他社は1秒あたり$0.07で、1回の試行あたり$0.35かかり、2回の試行のうち1回が利用可能であれば、承認されたクリップのコストは$0.70**です。見た目には安価なモデルが約3倍の差で勝ち、1秒あたりの料金表とは逆の順位を示しました。

料金表が省略しているもの

AI動画APIのRunwayの料金比較]によると、公開されている料金は生成された1秒あたりおよそ**$0.02から$1**の間に集中しており、その差は実際の予算を決定するコストを考慮する前に測定されています。同じ分析では、安価なモデルでも1回ではなく4回の試行が必要な場合、最終的にはより高価になる可能性があると指摘しています。これらをあなたのモデルに追加してください。

• 失敗したジョブとモデレートされたジョブ。 拒否されたジョブはリクエストを消費し、利用可能なものを何も返さないため、成功率の分母に含めるべきであり、除外すべきではありません。
• あなたが選択した再試行。 すべての再提出は別の試行コストであり、そのため試行回数は別途メモするのではなく、計算式に含めるべきです。
• 料金を変動させる設定。 解像度とオーディオは1秒あたりの価格を変更するため、デフォルト設定で実行されたベンチマークは、あなたが実際に支払うことのない価格を提示している可能性があります。
• あなたが設定しなかったデフォルトの長さ。 5秒を希望したのにプロバイダーのデフォルトが8秒だった場合、クリップあたりのコストは60%増加します。
• ストレージと再ホスティング。 結果リンクは一時的なものです。ファイルを自分のバケットにコピーすることは、承認されたクリップのコストの一部です。

請求ルールも計算に影響を与えます。動画は生成が完了すると最終価格で請求され、リクエストへの返答には動画が開始する前にジョブにかかる最大費用が記載されます。これにより、ジョブごとおよびテナントごとに予算上限を設定できます。これら2つのルールにより、漠然とした月間見積もりが、コードで強制できるリクエストごとの上限に変わります。

承認を厳密に定義してください。成功を報告するジョブは、利用可能なクリップではありません。プロンプトへの準拠、時間的な一貫性の維持、被写体の一貫性、そして明らかな動きや物理的なエラーがない場合にのみ、それをカウントしてください。ルートごとの1秒あたりおよびジョブあたりの料金がどのように比較されるかの詳細については、AI料金モデルの仕組み]のガイドで請求単位を説明しています。

成功ステータスは、レンダリングが完了したことを意味します。それはクリップが出荷に値することを意味するものではなく、後者のみが分子に入ります。

リクエストフィールドと確認すべき出力メタデータ

動画リクエストには、プロンプト以上の情報が含まれます。各フィールドは、ルートを選択したり、価格に影響を与えたり、後で良い結果を再現できるかどうかを決定したりします。以下の7つのフィールドを送信してください。

1. モデル識別子。プロバイダーのルートを選択します。識別子には構造があり、fal-ai/kling-video/v3/standard/text-to-videoはプロバイダー、ファミリー、バージョン、ティア、モダリティを1つの文字列にエンコードします。これは設定ファイルに保持し、リクエストロジックにハードコードしないでください。
2. プロンプト。画像から動画への変換の場合は、参照画像またはそのアップロード場所。
3. 秒単位の期間。価格と生成時間の両方がこれに比例するためです。
4. 解像度とアスペクト比。どちらも1秒あたりの料金に影響するためです。
5. オーディオ設定。モデルがオーディオをサポートしている場合。
6. シード。モデルが受け入れる場合、良い結果を再現できるようにするためです。
7. あなた自身のリクエストID。プロバイダーのジョブがあなたの記録にマッピングされるようにするためです。

完了したタスクごとに保存すべき出力フィールド

コンテナ形式、ビデオコーデック、寸法、フレームレート、期間、オーディオの有無とコーデック、利用可能な場合はビットレート、ファイルサイズ、および永続的なコンテンツURLまたはオブジェクト識別子。ファイルだけでは、次の四半期にどの設定で生成されたかを判断できないため、メタデータをファイルの横に保存してください。

すべての結果が同等であると仮定するのではなく、そのメタデータを記録してください。同じ期間の2つのクリップが、異なるコーデック、異なるビットレート、オーディオトラックの有無にかかわらず届くことがあります。W3C WebCodecs specification]は、コーデックやエンコード方法を義務付けることなく、オーディオとビデオのエンコードおよびデコードのインターフェースを定義しているため、2つのレンダリングが同じ形式で返されることを保証するものはありません。

ブラウザやアプリ向けには保守的なMP4プロファイルを提供し、後で編集する際に品質が重要となる場合は、プロバイダーネイティブのファイルを保持してください。その後、成功する前に検証を行います。デコードされた期間とフレーム数をリクエストと照合してください。なぜなら、APIが成功を報告しても、長さが間違っているファイルは失敗だからです。5秒を要求したのに4秒のクリップが届くのは、失敗したジョブと同じくらいタイムラインを壊し、それに気づくのははるかに困難です。

既存のSDKコードに動画生成を組み込む

既存のテキスト統合は書き換えなしで適応します。テキストと動画を別々のルートに保つことで、両方が1つのAPI key、1つのbase URL、1つの残高を共有でき、SDK wrapperはそのままにしておけます。OpenAIまたはAnthropic互換のクライアントを移行する場合、endpointと認証情報の変更で済み、モデルを切り替える場合は識別子の変更で済みます。

薄い動画サービスの4つの部分

作成関数は入力を検証し、生成ルートを呼び出し、すぐに独自の内部ジョブIDを返します。呼び出し元はプロバイダーIDを見ることはなく、これにより後のフェイルオーバーが彼らにとって見えないものになります。

ジョブテーブルは内部IDをプロバイダーのジョブID、ステータス、ルート、タイムスタンプ、出力メタデータにマッピングします。請求調整のための信頼できる情報源として扱い、プロバイダーのダッシュボードではありません。

ワーカーはポーリングまたはwebhookを受信し、ステートマシンを進め、定義したリトライおよびデッドラインルールを適用します。1つのワーカーが両方のシグナルを処理するため、見逃されたイベントと遅いポーリングが同じコードパスに収束します。

ストレージステップは完成したMP4を独自のバケットにコピーし、チェックサムを計算し、メタデータ行を書き込みます。これは、チームがスキップしがちで、最初の期限切れリンクの後で再構築することになるステップです。

各API keyを1つの環境にスコープし、キーを失効可能に保つことで、漏洩したステージングキーが本番環境の容量にアクセスできないようにします。大容量のソース画像や動画ファイルの場合、リクエストボディにバイトを埋め込むのではなく、署名付きURLを介してアップロードしてください。数メガバイトのJSON payloadはそれ自体が障害モードとなるためです。

次に、シニアエンジニアが尋ねるであろうテストを実行してください。クライアント側でタイムアウトするリクエストを送信し、システムが正確に1つの保存されたタスク、1つの最終的なダウンロード、そして重複した送信なしで終了することを確認します。そのテストがパスすれば、残りの統合は詳細に過ぎません。

本番環境での障害と重複を防ぐ方法

生成APIは関数呼び出しではありません。関数呼び出しのように扱うと、重複が発生します。同期テキストAPIの場合、タイムアウトはほとんどの場合、作業が実行されなかったことを意味します。しかし、動画の場合、タイムアウトは単にあなたが聞き取りを停止したことを意味するに過ぎません。ジョブはまだキューに入っている可能性があり、まだ実行中であり、完了した瞬間に最終価格で請求される可能性があります。下の画像は、そのアイデアの運用版を示しています。誰も監視していないキューではなく、誰かが所有し、自己修復するパイプラインです。

動画統合バグのほとんどは7つの症状に起因し、それぞれが1つの原因と1つの修正策に対応しています。

自動フェイルオーバーがコストを増大させる理由

フェイルオーバーはテキストの習慣であり、動画にはきれいに適用できません。チャットのendpointでは、タイムアウトしたリクエストを再試行するのは安価であり、どちらの方法でも回答は同じです。動画のendpointでは、再送信ごとに新しい課金対象のジョブが発生し、出力1秒あたりで課金されます。また、異なるmodelへの再ルーティングは、動き、IDの一貫性、安全性の結果、またはクリップのdurationを変更する可能性があります。最高のAI動画生成APIに関する比較レポートでは、プロバイダー間の大きな違いとして、concurrency limits、rate limits、queue behaviour、および遅い外れ値を挙げており、平均latencyはインタラクティブな製品を破壊するテール遅延を正確に隠してしまいます。

したがって、再試行とフェイルオーバーは、無料の安全策ではなく、コストと一貫性のリスクとして扱ってください。重複する送信はすべて、承認率を上げることなく、承認されたクリップあたりのコストを上昇させます。一致する必要がある一連のクリップにはmodelを固定し、ご自身のpromptで同等とテストしたmodel間でのみフェイルオーバーを許可してください。モデレーションによる拒否は、一時的なエラーではなく結果として扱ってください。コードを読み、promptを変更し、同じ入力を自動的に再送信しないでください。

経験豊富なチームを悩ませる失敗モードは、より微妙です。クライアントのリクエストがすでにタイムアウトした後でも、ジョブが成功に達することがあります。保存されたジョブを調整する代わりに再送信すると、同じクリップに2回課金されます。結果リンクも一時的で期限切れになる可能性があるため、完了したファイルをすぐにダウンロードし、checksum付きで保存し、アーカイブ行を書き込んでください。このステップは管理であり、単なる整理整頓ではありません。UberLLMは、動画または音楽ジョブの完了後、約3時間結果ファイルを保持します。これは再試行ループには十分な長さですが、ご自身のbucketを置き換えるには到底足りません。

正確に1回だけ課金する仕組みは、それぞれが単独では小さい部品から構成されています。ユーザーリクエストごとのidempotency key、永続的なタスク状態、検証済みwebhook、期限後の調整ポーリング、完了したメディアのchecksum、そしてすべての完了ファイルの不変なアーカイブです。そのうちのどれか一つでもスキップすると、いずれかのエッジケースがその隙間を見つけるでしょう。

**初日のルール：**すべての動画ジョブには、課金や作業の再送信なしに調整できる保存された状態が必要です。ご自身のデータベースから「このジョブの費用はいくらで、配信されたか」に答えられない場合、その統合は完了していません。

コミットする前にモデルベンチマークを実行する

午後で終わるテストでモデルの選択を決定できます。異なるコスト単位または速度プロファイルを持つデフォルトモデルを1つとチャレンジャーモデルを1つ選びましょう。テキストからビデオ、画像からビデオの最初の実用的なデフォルトはKling 3.0 Standardであり、Veo 3.1 Fastは有用なコストチャレンジャーになります。その後：

1. コストモデルからの固定プロンプト、期間、解像度、オーディオ設定、および承認ルールを再利用します。入力が同一であることだけが、比較に意味を持たせる唯一の方法です。
2. モデルごとに少なくとも10ジョブを実行し、偶然の成功ではなく、失敗率を確認するのに十分な数を確保します。
3. 4つの数値だけを持ち帰ります。成功率、中央値レイテンシー、テールレイテンシー、承認済みクリップあたりのコストです。
4. 呼び出すルートのレートを確認します。サウンドなしの1080pの同じテキストからビデオのプロファイルの場合、Veo 3.1 FastはUberLLMでは1秒あたり$0.075、fal.aiでは1秒あたり$0.10かかり、そのようなサイズの差が、どのモデルが勝つかを左右します。
5. 配管は分離したままにします。1つのAPI keyと1つのbase URLが両方をカバーする場合でも、ビデオリクエストは/v1/video/generationsに、チャットリクエストは/v1/chat/completionsに送ります。

候補を変更することは、モデル識別子の変更です。そのため、ベンチマークにかかるのはプロンプトと時間であり、移行ではありません。レイテンシーと品質の基準を満たしつつ、承認済みクリップあたりのコストが最も低いルートを選択し、一致させる必要があるシリーズについてはそれを固定し、価格やキューの状態が変動するたびに、毎月同じ10ジョブセットを再実行します。

UberLLMは、1つのOpenAIおよびAnthropic互換のendpointの背後で、プロバイダー全体にビデオ生成をルーティングします。そのため、ジョブを一度送信するだけで、ゲートウェイが販売者、ジョブID、およびコールバック契約を処理できます。テキストからビデオ、画像からビデオ、およびアップスケーリングモデルは、チャットモデルと同じkeyとプリペイド残高で利用でき、失敗した生成には料金はかかりません。次のビデオベンチマークをUberLLM](UberLLM](https://uberllm.dev))に向けて、1秒あたりのコストではなく、承認済みクリップあたりのコストを比較してください。