Seedance API の料金を実測:動画 token の計算式を完全解明
目次
Seedance の動画生成は token 単位で課金される。実際のメーターと一致する計算式は encoded_width × encoded_height × (24 × seconds + 1) / 1024 だ。確認できたドキュメントには、2 つの要素が記載されていなかった。+1 frame が加わることと、エンコード後の解像度が公称値と異なることだ。たとえば 720p は 1280×720 ではなく、1248×704 として課金される。5 つの Seedance モデルと全解像度 tier で 27 回生成したところ、すべての課金 token 数がこの式と 1 token 単位で一致した。この記事では、各モデルの位置付けと 2 リクエストで完結する API の使い方を整理した後、特定した計算式と、そこから導ける 1 秒あたりの料金体系、rate card で誤解しやすい 2 点を解説する。
TL;DR
- Seedance の動画 token 数は、エンコード後の幅 × 高さ × (24 × 秒数 + 1) / 1024。+1 frame とエンコード後の解像度は、ドキュメントの記載ではなく実測に基づく。
- 720p は 1248×704、1080p は 1920×1088 として課金される。アスペクト比は料金に影響しない。
- 同じ 4 秒の動画は、1.5-pro 以上の全 tier で token 数が同じだった。単価は 100 万 token あたり $1.0 から $7.0。
- 4k の単価は $4.0/M で、1080p の $7.7/M より安い。それでも 1 秒あたりの料金は $0.78 対 $0.38 で、4k のほうが 2.1 倍高い。
generate_audioを有効にしても token 数は変わらず、1.5-pro では単価が 2 倍になる。
以下の数値はすべて、2026-07-22 に Synthorai gateway の /v1/videos endpoint で実測した。Seedance ファミリーは ByteDance の list price で提供されており、全数値をタスク単位の生データで検証している。
Seedance の各モデルは何が違うのか
tier を変えてもメーターの計算方法は変わらず、変わるのは単価だけだ。必要な機能でモデルを選び、料金は後続のセクションで計算すればよい。同じ prompt を使った 4 秒の 480p 動画では、Seedance 2.0、2.0-fast、2.0-mini、1.5-pro の token 数がすべて同じだった。各 40,594 token で、1.0-pro-fast だけは pixel grid がわずかに小さいため 39,285 token だった。上位 tier に支払うのは機能差であり、その配分はモデルごとにかなり異なる。
| 解像度 | 長さ | 音声 | 画像入力 | seed / camera_fixed | 単価($/M tokens) | |
|---|---|---|---|---|---|---|
| 2.0 | 480p-4k | 4-15s(+auto) | ✓ ネイティブ | 最初 + 最後の frame | ✗ | $7.0(1080p $7.7・4k $4.0) |
| 2.0-fast | 480p-720p | 4-15s(+auto) | ✓ | 最初 + 最後の frame | ✗ | $5.6 |
| 2.0-mini | 480p-720p | 4-15s(+auto) | ✓ | 最初 + 最後の frame | ✗ | $3.5 |
| 1.5-pro | 480p-1080p | 4-12s(+auto) | 切り替え式($1.2 / $2.4) | 最初 + 最後の frame | ✓ | $1.2-2.4 |
| 1.0-pro-fast | 480p-1080p | 2-12s | ✗ | 最初の frame のみ | ✓ | $1.0 |
選定前に把握しておきたい点が 3 つある。再現性については、一般的な予想とは逆だ。seed と camera_fixed が使えるのは 1.x モデルだけなので、最も安い tier では制御できるが、flagship ではできない。機能ごとの field はモデル単位で厳密に制限される。1.0 モデルに generate_audio を送ると、明示的な 400 エラー(extension_not_supported)が返る。全モデルで共通の request schema を使い回すのではなく、各モデルの機能一覧から request を組み立てる必要がある。2 秒の動画を生成できるのは 1.0-pro-fast だけだ。そのため、以下の計算式の測定では主にこのモデルを使った。新しいモデルはすべて 4 秒からとなる。表に記載した機能以外では、2.0 モデルは、platform 側が対応していれば upstream で参照ファイルも入力できる。上限は画像 9 枚、動画 3 本、音声ファイル 3 個だ。
Seedance API の呼び出し方
動画生成は非同期 job API になっている。POST でタスクを作成すると約 2 秒でレスポンスが返るので、完了するまでタスク URL を polling する。Python での一連の処理は次のとおりだ。
import os, time, requests
BASE = "https://synthorai.io/v1"
auth = {"Authorization": f"Bearer {os.environ['SYNTHORAI_API_KEY']}"}
task = requests.post(f"{BASE}/videos", headers=auth, json={
"model": "seedance-1-5-pro-251215",
"prompt": "A paper boat drifting across a rain puddle, cinematic",
"resolution": "720p", "ratio": "16:9",
"duration": 5, "generate_audio": True,
}).json() # returns in ~2s: {"id": "vid_...", "status": "queued", ...}
while task["status"] not in ("completed", "failed", "cancelled"):
time.sleep(8)
task = requests.get(f"{BASE}/videos/{task['id']}", headers=auth).json()
print(task["data"][0]["url"]) # signed MP4, valid 24h
print(task["usage"]["total_tokens"]) # the billing meter this post is about
polling せず待機したい場合は、作成時に Prefer: wait=60 header を送る。動画が完成するか待機時間を超えるまで response が保留され、時間切れになった場合は通常の polling 用 object が返る。今回の実行では、480p と 720p の生成に 20 秒から 2 分強かかった。完了したタスクの usage.total_tokens field が課金メーターにあたる。以下では、この値が何によって決まるかを説明する。
動画 token とは何か
動画 token は、出力 pixel と時間を一定量に分割した単位だ。課金 token 数は W × H × frames / 1024 で、frame 数は 24 × seconds + 1。W×H には解像度 tier の表記ではなく、encoder が実際に使う解像度が入る。この 2 つの項は、メーターの値から逆算した。各解像度で 3 種類の長さを生成したところ、課金 token 数は誤差ゼロの直線に一致した。直線の傾きから 1 秒あたりの token 数が求まり、切片はすべての解像度で、ちょうど 1 frame 分の token 数になった。480p は 405、720p は 858、1080p は 2,040 だ。傾きから W×H を逆算すると、実際のエンコード解像度は次のようになる。
| 公称 tier | エンコード解像度(実測) | 1 秒あたりの token 数 | 追加される 1 frame |
|---|---|---|---|
| 480p | 864×480(1.0 series)/ 864×496(1.5/2.0 series) | 9,720 / 10,044 | 405 / 418 |
| 720p | 1248×704(1280×720 ではない) | 20,592 | 858 |
| 1080p | 1920×1088(1920×1080 ではない) | 48,960 | 2,040 |
| 4k | 3840×2160(公称値 = エンコード値) | 194,400 | 8,100 |
別のデータでも検算できる。広く出回っている ByteDance の 2.0 向け計算例では、15 秒の動画が約 308,880 token とされている。これは今回実測した 720p の 1 秒あたりの token 数をちょうど 15 倍した値だ。つまり、720p の grid は、計測に使った 1.0 series 以外にも当てはまる。ただし、その marketing 向けの計算では +1 frame が省かれている。
実務上の影響は 2 つある。まず、アスペクト比を変えても料金は変わらない。9 組の比較すべてで、16:9 と 9:16 の token 数は同じだった。縦向き出力を選んでもコストは増えない。また、よく引用される概算式 W × H × 24 × duration / 1024 は 1 frame 分が不足しているうえ、解像度も誤っている。そのため、第三者による見積もりは実際の請求額から数%ずれる。
Seedance の 1 秒あたりの実コスト
実測した 1 秒あたりの token 数に各 tier の list price を掛けると、全モデルの料金は次のように整理できる。
| モデル @ 解像度 | $/秒(実測 token 数 × list price) |
|---|---|
| seedance-1.0-pro-fast @ 480p | $0.0097 |
| seedance-1.5-pro @ 480p、音声なし | $0.0121 |
| seedance-1.0-pro-fast @ 720p | $0.0206 |
| seedance-1.5-pro @ 480p、音声あり | $0.0241 |
| seedance-2.0-mini @ 480p | $0.0352 |
| seedance-1.0-pro-fast @ 1080p | $0.0490 |
| seedance-2.0-fast @ 480p | $0.0563 |
| seedance-2.0 @ 480p | $0.0703 |
| seedance-2.0 @ 4k | $0.778 |
1 秒単位で課金する他社の 2026 年 7 月時点の list price と比較すると、公開されている料金トラッカーの集計では Kling が約 $0.07/s、Sora 2 が約 $0.10/s、Veo 3.1 が約 $0.40/s だ。Seedance 2.0 の 480p は Kling と同水準で、ネイティブの multi-track audio も含まれる。1.0-fast tier なら、視聴に耐える 480p 動画を Kling の約 7 分の 1 の単価で生成できる。2.0 で 15 秒の 720p 動画を作ると約 $2.17、同じ動画を 1.0-pro-fast で作ると $0.31 になる。
4k は安いのか。rate card では安く見えるが、請求額は高い
Seedance 2.0 の 4k は、100 万 token あたり $4.0 で、1080p の $7.7 より単価が安い。それでも、全選択肢の中で最も高額だ。原因は計算式にある。4k は 1 秒あたり約 4 倍の token を生成する。4k が 194,400、1080p が 48,960 だ。そのため、token 単価が安くても 1 秒あたりの料金は $0.778/s 対 $0.377/s となり、4k のほうが 2.1 倍高い。基準として生成した 4 秒の 4k 動画は 785,700 token で、4 秒あたり $3.14 だった。token 単位で課金される動画では、token 単価と請求額が逆方向に動くことがある。per-token の rate card を見る際は、必ずその解像度の 1 秒あたりの token 数と併せて確認する必要がある。
generate_audio で何が変わるのか
変わるのは単価で、token 数ではない。1.5-pro で同じ 5 秒の動画を生成したところ、音声ありでもなしでも 50,638 token だった。一方、list price は音声なしの $1.2/M から音声ありの $2.4/M に倍増する。したがって、音声付き出力の料金は隠れた token 加算なしで、正確に 2 倍になる。2.0 series では音声がモデルの単一料金に含まれているため、toggle による計算は不要だ。別途 music bed を追加する pipeline なら、1.5-pro の音声なしは $0.0121/s で、このカタログ中では特に安い。
非同期動画 API の課金はどう処理されるか
課金は、前述のタスク lifecycle に紐づく。タスクが初めて completed を返した時点で 1 回だけ課金され、polling の回数には影響されない。キャンセルは実際の処理状態に従う。queued 状態なら正常にキャンセルでき、課金も発生しない。一度 running になると upstream が削除を拒否して 409 を返すため、結果が出るまで待つ必要がある。生成に失敗した場合は課金されない。
27 タスクを実行して確認した運用上の注意点は 3 つある。まず、chat の usage.cost とは異なり、動画の response には token usage が含まれるものの、cost field はない。予算は token 数 × tier の単価で計算する。次に、出力は有効期間 24 時間の signed URL で返るため、すぐに自前の storage へ移す必要がある。最後に、作成リクエストの送信ペースを調整する。platform では workspace ごとに 1 分間で 6 件まで動画タスクを作成できる。また、pending の各タスクは残高から最悪ケースのコストを一時的に確保する。upstream が遅延している間に一気にタスクを作成すると、最終的な利用額に問題がなくても、一時的な quota 不足の response が返ることがある。
FAQ
Seedance 2.0 API は本当に利用できるのか
利用できる。2026 年初頭に必要だった中国向け認証情報、waitlist、段階的 rollout といった情報はすでに古い。2.0 を含む全モデルが、Synthorai gateway の /v1/videos endpoint で ByteDance の list price により提供されている。モデルページは Seedance 2.0、1.5-pro、1.0-pro-fast で、ほかにも複数の platform が対応している。Seedance 2.0 は体験用 quota でしか使えないとする情報は、API rollout 前のものだ。
provider によって Seedance の料金が大きく異なるのはなぜか
多くの reseller は token 課金を 1 秒単位または 1 clip 単位の固定料金に変換し、独自の margin と丸め処理を加えている。この変換によって、解像度と長さに応じた token 計算が見えなくなる。すべての見積もりの基礎になるのは、この記事で示した計算式だ。エンコード後の解像度を使って W × H × (24s + 1) / 1024 を計算し、公式単価を掛ければ、各 provider の上乗せ額を正確に求められる。
アスペクト比や縦向き形式で料金は増えるのか
増えない。テストしたすべての解像度と長さで、16:9 と 9:16 の token 数は同じだった。メーターに影響するのは解像度と長さだけで、長さに対しては完全に線形だ。
Seedance 2.5 はどうか
発表済みだが、追跡対象の API ではまだ提供されていない。token の計算式と tier ごとの単価構造はそのまま引き継がれる可能性が高い。提供開始後、同じ測定をやり直す予定だ。
2026-07-22/23 に実測。/v1/videos 経由で 5 つの Seedance モデルを使い、完了した 27 件の生成タスクを計測した。token 数はタスクごとの usage record、単価は ByteDance の list、機能一覧は稼働中の /v1/videos/models catalog に基づく。競合の 1 秒あたりの数値は実測ではなく list price。計測したすべての点で計算式は完全に一致した。エンコード解像度はメーターから逆算しているため、ByteDance が encoder を変更した場合は再検証が必要になる。このシリーズのほかの記事:画像生成、音声認識、音声セッション、テキスト token。