Seedance 動画 API の請求額は、「生成本数 × 固定価格」になることはほとんどありません。同じ 5 秒の動画でも、解像度、モデルの階層、動画入力の有無、失敗時の再試行、結果の保存によって実際の支出は変わります。表示価格だけで予算を組むと、稼働後の請求額が高くなります。原因は単価の上昇ではなく、これらの変数が見積もりに含まれていないことにある場合が大半です。
本記事では課金を 4 つの軸に分解します。尺、解像度、再試行、保存です。あわせて見積もり式、試算の手順、予算管理の方法を示します。具体的な単価と基準は変更されるため、モデル料金および提供元の公式課金ドキュメントを基準にしてください。
注記:Seedance は ByteDance 傘下の動画生成モデルです。Seedance、Doubao、Volcano Engine、BytePlus などの名称は、各権利者(ByteDance およびその関連会社)の商標です。本記事は技術的な説明のみを目的としており、関連する権利者と資本関係、代理関係、提携関係はありません。価格、インターフェース、課金ルールは公式ドキュメントとサイト内の料金ページを基準にしてください。
一、動画 API が「本数」で予算を組めない理由
テキスト API の課金単位は比較的統一されていますが、動画 API はそうではありません。1 回の「動画を 1 本生成する」リクエストの背後には、少なくとも 4 つの変数があります。尺、解像度、モデルの階層、入力方式です。どれか 1 つが変わっても請求額は変わり得ます。
さらに厄介なのは、1 回送信しても、そのまま使える完成動画が 1 本得られるとは限らないことです。審査での拒否、タイムアウト、映像として使えない結果は再試行につながります。結果リンクの有効期限が切れれば、再生成や転送保存が必要です。「本数 × 単価」だけで予算を組むと、体系的に過小評価になります。
二、4 つの課金軸
| 軸 | コストへの影響 | 見積もり時に記録する項目 | 制御方法 |
|---|---|---|---|
| 尺 | 秒単位または換算トークンで累積し、長いほど消費が増える | 送信した尺、完成動画の尺、分割の有無 | まず短い尺で試し、完成後に結合する |
| 解像度 | 画素数が解像度とともに増え、通常はフレームレートも影響する | 出力解像度、フレームレート、アスペクト比 | 下書きは低解像度、最終版で上げる |
| モデルと入力 | 世代、階層、入力方式によって単価が異なる | モデル名、最初のフレームや参照動画の有無 | 難易度で振り分け、既定で最高階層を使わない |
| 失敗と再試行 | 重複送信で二重課金になる場合があり、失敗時の規則も異なる | タスク状態、エラーコード、再試行回数 | エラー分類、冪等化、再試行制限 |
| 保存と転送 | 結果の転送、保持、配信で追加費用が発生 | ファイルサイズ、保存日数、アクセス量 | ライフサイクル削除、必要時の配信 |
比較的新しい Seedance シリーズは公式ドキュメントでトークン単位の計量となっており、消費量は解像度、尺、入力場面に関係します。一部のゲートウェイでは秒単位や本数単位に換算して表示されます。契約前に請求単位を確認してください。
三、尺と解像度が消費を大きくする仕組み
尺は最も分かりやすい変数です。一般的な階層は 5 秒と 10 秒ですが、10 秒がちょうど 5 秒の 2 倍とは限りません。最低課金単位を設けているプラットフォームもあれば、端数を切り上げた秒数で課金する場合もあります。予算は請求書の実際の控除額を基準にし、完成動画の尺から逆算しないでください。
解像度の影響はより分かりにくいです。720p から 1080p では、画素総数はおよそ 2.25 倍になります。フレームレートも同時に上げると、消費はさらに増えます。ただし最終的な請求額が必ずこの倍率で変わるわけではありません。モデルの階層、割引、課金の端数処理も影響します。正しい方法は、プロンプトと尺を固定し、解像度だけを変えて比較し、請求額の差を記録することです。
アスペクト比も画素総数に影響します。縦向きと横向きでは、同じ「解像度階層」でも実際の画素数が異なる場合があります。それぞれ別に予算を立て、月間平均値を共有しないことをおすすめします。
四、再試行と保存が見落とされやすい理由
失敗時の再試行は、動画コストで最も制御しにくい部分です。パラメータエラーは再試行すべきではありません。審査拒否を繰り返し送信しても通常は無駄で、再試行してよいのはレート制限と一部のサーバーエラーだけです。
タスク ID をデータベースに保存し、送信前に冪等性を確認し、再試行時は同じ業務レコードを再利用することをおすすめします。そうしないと、スクリプトのループが数分で同じタスクを数十回送信し、請求額が現実離れしたものになります。
保存コストも見落とされがちです。結果リンクには通常有効期限があり、期限切れ後は再生成が必要です。オブジェクトストレージに転送すると、保存費、リクエスト費、下り通信費が発生します。成功後に転送し、削除ルールを設定することをおすすめします。下書きは 7 日保持、完成動画はプロジェクト単位でアーカイブし、不要な素材は速やかに削除します。
五、1 本あたりのコストを式にする
「単価 × 尺」より信頼できる指標は、利用可能な動画 1 本あたりのコストです。
利用可能な動画 1 本あたりのコスト =(成功タスクの費用 + 失敗したが課金されたタスクの費用 + 保存と通信 + 人手による確認)÷ 審査を通過し、そのまま利用できる動画本数
分母は利用可能な完成動画であり、送信回数ではないことに注意してください。次の Python コードで換算します。金額は請求書から読み取り、コードに固定しないでください。
def cost_per_usable_video(task_costs, usable_count, storage_cost=0.0, review_cost=0.0):
"""task_costs: 各タスクの請求金額。usable_count: 利用可能な完成動画数"""
if usable_count == 0:
raise ValueError("利用可能な完成動画がありません。プロンプト、素材、パラメータを確認してください")
total = sum(task_costs) + storage_cost + review_cost
return total / usable_count
# 請求書から金額をエクスポートしてプレースホルダーを置き換える。単位は揃える
weekly_task_costs = [0.0] * 40
print(cost_per_usable_video(weekly_task_costs, usable_count=28))
レスポンスの利用量フィールドには、モデル、尺、解像度、状態、所要時間もあわせて記録してください。基準を揃えて初めて週単位で比較でき、異なる経路のデータを混ぜないようにできます。
六、小規模試算の標準手順
- モデルの階層、尺、解像度をそれぞれ 1 つに固定し、ベースラインとする。
- 実際の業務プロンプトと最初のフレーム画像を 20〜30 本用意する。うまく通るサンプルだけを使わない。
- タスクごとに状態、エラーコード、所要時間、請求額の控除を記録する。
- 失敗タスクも総コストに含め、利用可能な動画 1 本あたりのコストを計算する。
- 7 日間連続で観察し、日平均から月間コストを外挿する。保存、通信、確認工数も加える。
- 一度に 1 つの変数だけを変える。たとえば解像度を 1 段階上げて、コスト感度を測る。
- 結果に基づいて「テスト用の階層」と「完成用の階層」を決め、チームのルールに明記する。
小規模試算の価値は数字を 1 つ得ることだけではありません。コストがどの変数に最も敏感かを知ることです。
七、予算管理の具体的な方法
- 1 プロジェクトに 1 キー。テストと本番を分け、費用が混ざらないようにする。
- コンソールでキーに上限額を設定し、日次または週次の利用量アラートを設定する。
- 送信前に現在のパラメータで試算し、1 本あたりのしきい値を超えたら人による確認に回す。
- 同時実行数と最大再試行回数を制限する。特にバッチスクリプトでは重要です。
- 下書きはすべて低解像度にし、審査を通過したカットだけ高解像度版を生成する。
- 結果は速やかに転送し、ライフサイクルを設定する。毎週プロジェクト、モデル、解像度単位で照合する。
ゲートウェイ側では通常、キー単位の上限、モデルの許可リスト、利用量のエクスポートを提供しています。詳細はコンソールを基準にしてください。アラートは人に届くようにしてください。グループに送っても誰も見なければ、設定していないのと同じです。
八、コスト削減の順序と 3 つのよくある誤解
コスト削減は影響の大きい順に進めます。まず成功率を上げ、次に無駄な再試行を減らし、解像度の階層化と尺の短縮を行い、続いて保存を整理し、最後に経路の変更を検討します。順序を逆にすると、単価は下がったのに失敗率と総コストが上がるという結果になりがちです。
よくある 3 つの誤解は次のとおりです。
- 表示価格だけを見て、成功率と再試行を見ない。安くても頻繁に失敗する経路は、利用可能な 1 本あたりのコストが高くなる可能性があります。
- 最短の尺でテストし、本番では最長の尺と高解像度を使う。当然、予算は合いません。
- 結果リンクの有効期限を無視し、期限切れ後に再生成する。2 回支払うのと同じです。
よくある質問
Seedance API は回数、秒、トークンのどれで課金されますか?
比較的新しい Seedance シリーズは公式にトークン単位で計量され、消費量は解像度、尺、入力方式に関係します。一部のゲートウェイでは秒単位や本数単位に換算して表示されます。接続前に請求単位を確認し、モデル料金を基準にしてください。
解像度を 720p から 1080p に上げると、コストは 2 倍になりますか?
画素総数はおよそ 2.25 倍になりますが、実際の請求額はモデルの階層、最低課金単位、割引の影響も受けます。単純に 2 倍にはなりません。同じプロンプトで比較テストするほうが信頼できます。
失敗したタスクや審査で拒否されたタスクは課金されますか?
プラットフォームと失敗原因によって規則が異なります。課金されないシステムエラーもあれば、タスク作成後に課金される場合もあります。接続前にテスト注文で確認し、失敗コストを 1 本あたりのコストに含めてください。
テスト時は安かったのに、稼働後に請求額が速く増えるのはなぜですか?
よくある原因は、テストが 5 秒の低解像度で、本番が 10 秒の高解像度であること、失敗による再試行の増加、転送と配信の追加費用、複数人でのキー共有による帰属不能です。プロジェクトごとにキーを分け、タスク単位の請求を記録してください。
動画生成に予算上限を設定するには?
少なくとも 3 層が必要です。キー単位の上限、プロジェクト単位の予算、タスク送信前の試算です。しきい値に達したら重要度の低いタスクを停止し、担当者に通知してください。月末の請求書だけに頼らないでください。
次のステップ
まずZSQH AI Gateway でテストキーを作成し、最低構成で 20〜30 本のタスクを実行して、成功率、所要時間、請求額の控除を記録します。その後、モデル料金で月間予算に換算してください。非同期タスクの流れを先に理解したい場合は、サイト内の接続ガイドを続けてお読みください。
関連記事:
