Wan 3.0 API エラー一覧：拒否ごとの実際のレスポンス

以下のエラーはすべて、2026 年 9 月 4 日に Wan 3.0 動画エンドポイントから取得した実際のレスポンスボディです。 言い換えも、作り出したエラーテキストもありません。リクエストが失敗しているなら、code フィールドをこのリストと突き合わせてください。

model_not_found         → モデル文字列が存在しない
unsupported_parameter   → 値が範囲外、または許可されていない
invalid_request         → 必須フィールドが欠けている
invalid_api_key         → キーが誤り、未設定、または失効

エラーと実際のボディ

duration が範囲外

{"error":{"code":"unsupported_parameter","message":"duration 45 out of range [2, 30]"}}

Wan 3.0 は 2 から 30 秒の整数を受け付けます。 その外は両方向とも失敗します。1 秒を要求しても同じ形が返ります。

{"error":{"code":"unsupported_parameter","message":"duration 1 out of range [2, 30]"}}

これはアップグレード後に最も起こりやすいエラーで、理由は 2 つあり、方向は逆です。

• Wan 2.7 や 2.6 から来た場合、コードはおそらく 15 秒に丸めています。それが上限だったからです。これはエラーにはならず、Wan 3.0 が提供する範囲の半分で静かに頭打ちになるだけです。ほかに何が動いたかは Wan 3.0 対 Wan 2.7 の比較にあります。
• Seedance 2.5 から来た場合、コードはおそらく下限 4 秒を強制しています。それが Seedance の下限だからです。Wan 3.0 では、理由もなく 2 秒と 3 秒のクリップが届かなくなります。

見落としやすいルールが 1 つあります。継続のために入力動画を渡す場合、Alibaba の API リファレンスは入力の尺と出力の尺を合わせて 30 秒を超えられないと定めています。この 30 は総予算であって、入力に上乗せされる出力枠ではありません。

aspect_ratio が非対応

{"error":{"code":"unsupported_parameter","message":"aspect_ratio \"21:9\" not supported; allowed: [16:9 4:3 1:1 3:4 9:16 adaptive]"}}

Wan 3.0 に 21:9 はありません。 エラーは親切にも許可される集合を全部出力します。近隣のモデルとの違いが双方向にあるので、よく読む価値があります。

つまり Wan 3.0 と Seedance 2.5 の間で振り分けるパイプラインは、ハードコードした 21:9 を共有できません。Wan で 16:9 をレンダリングして切り、垂直解像度を失うか、シネマティックなジョブを Seedance に送るかです。逆方向を見ると、4:3 と 3:4 は Wan 3.0 では動くが Wan 2.7 では動かないので、アップグレードの経路が壊れないところでダウングレードの経路が壊れます。

resolution が非対応

{"error":{"code":"unsupported_parameter","message":"resolution \"4k\" not supported; allowed: [480p 720p 1080p]"}}

480p、720p、1080p のみです。 この世代に 4K はなく、Seedance 2.5 も 1080p が上限です。4K の要件が本物なら、どちらのモデルでもパラメータの調整では満たせません。カタログで 4K を挙げている唯一のモデルは古い bytedance/seedance-2.0 のフラッグシップで秒 $0.07、Seedance 2.0 と Wan の比較で扱っています。

なお resolution を省くと Wan 3.0 は 1080p を、Seedance 2.5 は 720p を既定にします。この違いはエラーを投げないので、並べてテストするときに危険なのです。比較するときは両方で解像度を固定してください。

model_not_found

{"error":{"code":"model_not_found","message":"model not found"}}

その文字列はカタログに存在しません。 Ofox で有効な Wan 3.0 の文字列は次のとおりです。

• alibaba/wan-3.0
• alibaba/wan-3.0-prime
• 日付付きエイリアスの wan-3.0-20260824 と wan-3.0-prime-20260824

罠は Alibaba 自身のモデル文字列が別物であることです。Alibaba Cloud Model Studio では wan3.0-video と wan3.0-video-prime で、wan のあとにハイフンがなく -video の接尾辞が付きます。Alibaba のドキュメントからモデル名をそのままゲートウェイの呼び出しにコピーすると、まさにこのエラーになります。迷ったら GET /v1/models を確認してください。何が呼べるかの拠り所はそこです。

invalid_request

{"error":{"code":"invalid_request","message":"prompt is required"}}

必須フィールドが欠けています。 存在はするが許可されない値を送ったことを意味する unsupported_parameter とは別物です。リトライのロジックを書くときこの区別が効きます。どちらもそのまま再試行する価値はありませんが、直し方が違います。フィールドの欠落はリクエスト組み立て側のバグ、範囲外の値はたいてい設定またはユーザー入力の検証漏れです。

invalid_api_key

{"error":{"code":"invalid_api_key","message":"invalid API key"}}

キーが誤っている、未設定、失効している、または別アカウントのものです。 Authorization ヘッダーが Bearer <key> になっているか、キーが環境変数から読めていて黙って空になっていないかを確認してください。変数が空のときはヘッダー欠落のエラーではなくこのエラーが出るので、人は間違ったところを探しに行きます。

エラーではないもの

動画生成は非同期です。 作成が成功するとタスクが返り、それをポーリングするか callback_url を渡して完了時に通知を受けます。pending や in-progress は失敗ではなく、そこにアラートを出すとノイズが本物の失敗を埋めてしまいます。呼び出すに値するのは終了状態の失敗と上記のコードだけです。待ち時間の挙動と妥当なポーリング間隔については動画 API ポーリングガイドを参照してください。

通るリクエスト

自分のエラーを上で突き合わせたあと、このモデルですべての検証を通る形はこれです。

curl -X POST https://api.ofox.ai/v1/videos \
  -H "Authorization: Bearer $OFOX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "alibaba/wan-3.0",
    "prompt": "A paper boat drifting down a rain gutter, close on the water line",
    "duration": 5,
    "resolution": "1080p",
    "aspect_ratio": "16:9"
  }'

ここのすべてのフィールドが受け入れ範囲の中にあります。モデル文字列は存在し、5 は [2, 30] の中、1080p は許可される解像度の集合に、16:9 は許可されるアスペクト比の集合に入っています。どれか 1 つを範囲外の値に変えれば対応するエラーが返るので、本当に必要になる前にエラー処理が動くことを確かめる手早い方法になります。

リクエストが成功したあとにこのモデルがいくらかかるか、一律の秒単価が Alibaba の解像度別価格とどう比べられるかは、Wan 3.0 の料金とアクセスのガイドを参照してください。

出典

• https://help.aliyun.com/zh/model-studio/wan3-video-generation-api-reference
• https://ofox.ai/models/alibaba/wan-3.0

本記事のエラーボディはすべて、2026 年 9 月 4 日に Ofox /v1/videos エンドポイントへの実際のリクエストから取得しました。Alibaba Cloud を直接呼ぶ場合を含め、他の経路のエラーテキストは別のエンベロープと別のコードを使います。