動画生成AIを数十本まとめて回す──CLIとWebの使い分けと、接続が切れた時の実ログ

動画生成AIを数十本単位で回すとき、ブラウザで1本ずつ生成ボタンを押す進め方が破綻するのは、生成が遅いからではなく、待ち時間と人間の注意が直列につながってしまうからです。そしてこの直列を切る根拠は、感覚ではなく公式仕様の側にあります。OpenAIの「Video generation」ガイドを2026年8月14日に確認したところ、動画生成は POST /videos がジョブのIDと状態を即座に返し、実際のレンダリングはサーバ側で進む非同期ジョブとして設計されています。つまり「投げる作業」と「受け取る作業」は最初から分離できる。この記事は、その公式仕様と、当サイト運営者が実際に27体分を一度に発射し、CLIの待機オプションが途中で切れた時に何が起きたかの制作ログを突き合わせて、CLI/APIとWeb UIをどう分担させるかを整理したものです。

• OpenAI公式「Video generation」（2026年8月14日確認）は、ジョブの状態を queued / in_progress / completed / failed の4つとし、GET /videos/{video_id} で状態と進捗（progress）を取得する形を示している【一次ソース】
• 当サイトの制作ログでは、27体分を一度に並列発射した回で、CLIの --wait がシェル側で2分ほどで切れてもジョブはサーバ側で生きており、一覧取得コマンドで回収できた【実証済み／自社実測】
• Higgsfield公式ドキュメント（同日確認）は状態を queued / in_progress / completed / failed / nsfw / canceled の6つとし、「Output URLs are retained for at least seven days」と保持期間を明記している【一次ソース】

ブラウザで1本ずつ回すと、何が直列になるのか

問題は生成の待ち時間そのものではありません。ブラウザ主体で進めると、待ち時間の間ずっと「そのタブを見ている人間」が拘束され、次の1本を投げる操作が前の1本の完了に依存します。10本なら気合いで押し切れますが、当サイトが妖怪の動画で扱ったような27体分となると、この依存関係が全体の所要時間をそのまま決めてしまいます。

一方、APIやCLI経由なら、投げる操作は完了を待ちません。以下は作業の構造の違いを並べたものです。

注意したいのは、右の列にも破綻点があることです。一斉に投げるやり方は、ジョブIDを自分の手元に残していないと、投げた本人が何本投げたか分からなくなるという別の失敗モードを持ちます。ここは後述します。

非同期ジョブであることの一次根拠

OpenAIの「Video generation」ガイドと「Videos」APIリファレンスを2026年8月14日に確認した範囲で、動画生成の流れは次のように定義されています。

状態値は、同ガイドの記述で queued（順番待ち）、in_progress（処理中）、completed（完了）、failed（失敗）の4つです。APIリファレンス側の status の定義も同じ4値でした。

ここから読み取れる実務上の意味は一つです。ジョブの寿命は、あなたの接続の寿命と無関係である。ブラウザのタブを閉じても、ターミナルのプロセスが死んでも、サーバ側のジョブはそれとは別の場所で進んでいます。逆に言えば、手元の画面が「終わった」ように見えても、それはジョブが終わった証拠ではありません。

同じ設計は他社にもあります。Higgsfieldの公式ドキュメント（同日確認）は「a successful submission creates a request and returns immediately while the work continues in the background」と明記し、状態として queued / in_progress / completed / failed に加えて nsfw と canceled を持ちます。安全性判定の結果を独立した状態として持っている点が、OpenAIの4値との実務上の差です。

結果の保持期間は差が大きいので、ここは押さえておく価値があります。OpenAI公式ガイドはダウンロードURLの有効期間を最大1時間とし、長期保存が必要なら速やかに自分のストレージへコピーするよう記しています。Higgsfield公式は「at least seven days」です。いずれも2026年8月14日確認時点の記述です。一斉に27本投げて翌朝回収する運用は、前者ではそのままでは成立しません。

CLIの待機が切れた時、ジョブはどうなっていたか

当サイトの制作ログに残っている実例です。CLIの --wait（完了まで待つオプション）を付けて発射したところ、シェル側が2分ほどでタイムアウトして戻ってきました。画面上は待機が中断された状態です。

ここで実際に起きていたのは、ジョブの失敗ではなく、待機している側だけが切れたという状況でした。一覧取得コマンド（generate list --json 相当）を叩くと、該当ジョブはサーバ側で進行しており、その後 completed になったものを回収できています。前節の「ジョブの寿命は接続の寿命と無関係」が、そのまま観測された形です。

この場面で最も危険な反応は、切れた画面を見て「失敗した」と判断し、同じプロンプトをもう一度投げることです。元のジョブは生きているので、同じものが2本生成される。生成が成功してしまう以上、これは失敗ジョブとは扱いが別になります（失敗時のクレジットの扱いはAI動画の生成に失敗したらクレジットは戻るのかで公式4社の原文を確認しています）。

症状ごとの判断を表にします。

運用として最低限必要なのは、--wait に依存しない設計にすることです。具体的には、発射時に返ってきたジョブIDを1行1件でローカルのファイルに書き出しておき、回収は別プロセスで一覧を叩く。待機オプションは「短い1本を試すときの便利機能」と位置づけ、数十本の本番発射では当てにしない、という切り分けになります。

CLIとWebをどう分担させるか

CLIに全部寄せる、という結論にはなりませんでした。当サイトの実運用は「CLIで量産・Webで本番」という分け方です。理由は品質ではなく、画面録画という別の要件です。制作過程を動画素材として残す必要がある最終生成は、Web UIで回さないと録画対象になりません。

もう一点、並列化と「本数を増やすこと」を混同しないことが重要です。当サイトの制作方針は「1設計＝1発」で、保険や変種で枚数を水増ししません。並列発射が短縮するのは待ち時間であって、必要な生成回数そのものではないからです。実際に1本の完成に何回かかったかはAI動画は1本何回で仕上がるのかでファイル単位に数え直しています。

正直な但し書き

• 所要時間の実測を取っていません。 「27体分を一度に発射した」は制作ログにある事実ですが、同じ内容を1本ずつ直列で回した場合との時間差は計測していません。したがって本記事では「何倍速くなる」という数字を出していません。
• --wait が切れた挙動は、当サイトが使った1つのCLIでの観測です。 他社CLIで同じ挙動になるかは確認していません。また、切れたのがシェル側のタイムアウトなのか、CLI内部の待機上限なのかを厳密には切り分けていません。ログ上「シェル側で2分程度」と記録されている範囲の事実です。
• Runwayの状態値は確認できませんでした。 APIリファレンスのナビゲーション上に GET /v1/tasks/{id}（Task management）が存在することは確認しましたが、状態値の一覧は取得したページ内容が途中で切れており読めていません。本記事の表に載せていないのはそのためです。
• ポーリング間隔の推奨値は、確認した公式ページ内に明記を見つけられませんでした。 何秒おきに叩くべきかは各社のレート制限を読んで決める必要があります。
• Webhookは当サイトでは運用していません。 video.completed / video.failed はOpenAI公式ガイドの記述として引用しているだけで、自分で受けて動かした実測ではありません。
• 生成できる秒数の値については、OpenAIの公式ページ間で記載が割れています。 本記事では秒数に触れていません。詳細はSora 2の4秒・8秒・12秒に何を入れられるかで公式3ページの食い違いをそのまま併記しています。
• 失敗ジョブの課金の扱いは本記事の範囲外です。上記の関連記事に分離しています。
• 公式ドキュメントの記述はいずれも2026年8月14日の確認時点のものです。エンドポイントや状態値は変更されうるため、実装前に原文を確認してください。

出典

• Video generation - OpenAI API: https://developers.openai.com/api/docs/guides/video-generation （2026年8月14日確認）
• Videos - OpenAI API Reference: https://developers.openai.com/api/docs/api-reference/videos （2026年8月14日確認）
• Requests and lifecycle - Higgsfield API Documentation: https://docs.higgsfield.ai/docs/concepts/requests （2026年8月14日確認）
• Runway API Reference（Task management のエンドポイント存在のみ確認）: https://docs.dev.runwayml.com/api/ （2026年8月14日確認）