Wan 2.6 API 本番ガイド:非同期タスク、予算ガードレール、エンジニア向け統合
TL;DR
- Wan 2.6 はリアルタイムツールではなく、非同期動画ワークフロー として扱う。
- 実務上のルート分割は以下のとおり:
- テキスト to ビデオ:アイデアファーストな生成
- 画像 to ビデオ:先頭フレームが重要な場合
- リファレンス動画:既存クリップからのアイデンティティ継続が重要な場合
- 現在のリポジトリドキュメントでは、テキスト to ビデオと画像 to ビデオは 2〜15 秒、リファレンス動画は 2〜10 秒 としてドキュメント化されています。
- 本番チームにとって難しいのは、たいていプロンプトライティングではなく、タスクハンドリング、支出コントロール、そしてルート固有の仮定を、現在のエンドポイントドキュメントが実際にサポートしている範囲内でのみ置くこと です。
1. 正しい Wan 2.6 ルートを選ぶ
Wan 2.6 を最もクリーンに考える方法は、1 つの汎用「動画モデル」ではなく、3 つの本番エントリポイントとして捉えることです。
| ルート | 最適な用途 | 注意点 |
|---|---|---|
| テキスト to ビデオ | アイディエーション、ストーリーボード、スクリプトファーストな生成 | プロンプトを構造化して保ち、duration を慎重に予算化する |
| 画像 to ビデオ | プロダクトショット、キービジュアル、ブランドセーフな先頭フレーム | 入力アセットの品質とアスペクト比がより重要になる |
| リファレンス動画 | キャラクターの継続性、継続登場するスポークスパーソン、アイデンティティ引き継ぎ | リファレンス動画のロジックは独自のコストパスなので、別枠で予算化する |
本番における最大のミスは、これらを 1 つのメンタルモデルに押し込めてしまうことです。ファミリー名は共有していますが、同一ルートとしては振る舞いません。
2. 統合モデル:非同期ファースト
- 生成リクエストを送信する
- タスク ID を即座に永続化する
- ステータスをポーリングするか、コールバックを消費する
- 生成リンクには時間制限があるため、最終出力を速やかに保存する
これにより、本番での関心事は予測可能になります。
- 繰り返し送信に対する冪等性
- ポーリングのバックオフ
- 結果の永続化
- ユーザー向けの進捗ステート
- ジョブがバックエンドを離れる前の予算コントロール
内部設計が依然として「ユーザーがボタンを押すとすぐに動画が返ってくる」という前提に立っているなら、トラフィックをスケールさせる前にその前提を修正してください。
3. 現在の Evolink 上のルート形状
このリポジトリ内の現在の Evolink 向けサンプルは、統一エンドポイントを使用しています。
POST https://api.evolink.ai/v1/videos/generations代表的なモデル名は以下のとおりです。
wan2.6-text-to-videowan2.6-image-to-videowan2.6-reference-video
この統一ルートが、このコードベースでアプリケーションコードが基準とすべき面です。
例:テキスト to ビデオ
curl --request POST \
--url https://api.evolink.ai/v1/videos/generations \
--header 'Authorization: Bearer YOUR_API_KEY' \
--header 'Content-Type: application/json' \
--data '{
"model": "wan2.6-text-to-video",
"prompt": "A cinematic multi-shot sequence of a runner crossing a neon-lit city bridge at night",
"aspect_ratio": "16:9",
"quality": "720p",
"duration": 10,
"prompt_extend": true
}'例:リファレンス動画
curl --request POST \
--url https://api.evolink.ai/v1/videos/generations \
--header 'Authorization: Bearer YOUR_API_KEY' \
--header 'Content-Type: application/json' \
--data '{
"model": "wan2.6-reference-video",
"prompt": "character1 walks into a bright cafe, orders a drink, then turns and smiles to camera",
"video_urls": [
"https://your-cdn.example.com/reference-character.mp4"
],
"duration": 5
}'4. Duration とパラメータの規律
このリポジトリで現在ドキュメント化されている内容は以下のとおりです。
- Wan 2.6 テキスト to ビデオ:
2-15秒 - Wan 2.6 画像 to ビデオ:
2-15秒 - Wan 2.6 リファレンス動画:
2-10秒
これが重要なのは、「5 / 10 / 15 のみ」といった古い前提が以下を歪めかねないからです。
- 予算計算機
- フロントエンドのバリデーション
- キュー計画
- ユーザー向けコピー
5. コストモデルと予算ガードレール
最低限、以下を行います。
- サーバーサイドで最大 duration を上限設定する
- 用途が 1080p を正当化しない場合は、最大 quality を上限設定する
- 標準の t2v/i2v 予算とは別枠で リファレンス動画 の予算を立てる
- ユーザー、機能、ルート単位で支出を追跡する
- リトライを冪等にして、不安定なクライアント 1 つが生成を二重課金しないようにする
リファレンス動画は特にここで重要です。同じファミリーに属していても、運用コストロジックは通常のテキスト to ビデオ利用とは同じではないため、別の予算パスとして扱うべきです。
6. チームが実際に直面する信頼性の問題
プロンプトのアドバイスよりも、いくつかの繰り返し発生するエンジニアリング問題のほうが重要です。
ルートドリフト
プロバイダファミリーは進化します。アプリが現在のルートドキュメントではなく古いブログ記事からの前提をハードコードしていると、サポートされる duration、パラメータ名、価格ロジックについて、やがて同期が取れなくなります。
アセットハンドリング
画像 to ビデオとリファレンス動画のルートは、渡すアセットの質に依存します。悪いアップロード、期限切れの URL、一貫性のないソース素材は、「モデル品質」の問題に見えて実際にはパイプラインの問題である失敗を生みます。
非同期ステートハンドリング
ユーザーの痛みの大半は、弱いジョブハンドリングから来ます。
- タスクの永続化漏れ
- 貧弱なタイムアウト挙動
- 重複送信
- 明確な「pending / running / failed / completed」ライフサイクルの欠如
これらを修正すれば、Wan 2.6 はエンドユーザーに対して劇的に本番対応に感じられるようになります。
7. 推奨エンジニアリングパターン
堅牢な統合のために:
- 送信前に duration、quality、ルート選択をバリデーションする。
- リクエストペイロードのハッシュをタスク ID と共に保存する。
- ポーリングにバックオフを使用するか、キュー駆動のコールバックを使う。
- 完了後ただちに最終メディアのメタデータを永続化する。
- プロダクトチームが誤ってリファレンス動画を安いデフォルトルートのように扱えないよう、ルート固有の予算上限を追加する。
実トラフィックがシステムに到達し始めると、このパターンはほぼあらゆるプロンプトトリックよりも重要になります。
8. FAQ
どの duration を前提に設計すべきですか?
2-15 秒、リファレンス動画は 2-10 秒としてドキュメント化されています。Wan 2.6 の普遍的なオーディオ契約を 1 つドキュメント化できますか?
いいえ。公開している正確なルートページとエンドポイント挙動を検証していない限り、オーディオに関する主張はルート固有に保ってください。
本番で最も安全なデフォルトは?
プロダクトゴールを満たす範囲で最安の quality と最短の duration を使用し、ワークフローがそれ以上を必要とすると証明された場合にのみ選択的に引き上げてください。
リファレンス動画はいつ使うべきですか?
既存クリップからの継続性がプロダクト要件の一部である場合に使用します。そうでないなら、デフォルトで複雑さのコストを払う必要はありません。
Next steps
- ルート選択の比較は Wan API ファミリーコレクション で
- ワークホースとシネマティックティアでまだ迷っている場合は Wan 2.5 vs Wan 2.6 意思決定ガイド を
- 現在の概要と価格の入口は Wan 2.6 モデルページ から
