Suno SDK シリーズ 02：ポーリングとダウンロードの落とし穴、404/502 から audio_url 成功まで

Suno のような音楽生成 API では、タスクが succeeded になっても、最終ファイルがすぐに取得できるとは限りません。今回の実測では、公開 /content URL は 404/502 になりましたが、上流の audio_url は正常にダウンロードできました。

実測結果

対象タスク：

task_ac90b23619334516

ポーリング結果：

{
  "status": "succeeded",
  "format": "mp4",
  "url": "https://crazyrouter.com/v1/videos/task_ac90b23619334516/content"
}

公開 content URL の検証：

HEAD crazyrouter.com content URL: HTTP 404
HEAD api.crazyrouter.com content URL + Authorization: HTTP 404
GET api.crazyrouter.com content URL + Authorization: HTTP 502

この時点だけを見ると、「生成結果のダウンロードは使えない」と判断しがちです。しかし、管理側のタスク詳細には上流の実メディア URL が含まれていました。

data.data.resultJson.data[0].audio_url
data.data.resultJson.data[0].image_url

audio_url の検証結果：

HEAD audio_url: HTTP 200, Content-Type: audio/mp3
GET audio_url: HTTP 200, Content-Type: audio/mp3, 412326 bytes

何が失敗し、何が成功したのか

項目	結果
タスク送信	成功
タスクポーリング	成功、`succeeded`
公開 `/v1/videos/{task_id}/content`	失敗、404/502
上流 `resultJson.data[0].audio_url`	成功、MP3 を取得
実用可否	生成結果は可用。ただし公開プロキシは修正または補完が必要

この違いをログに残さないと、原因を誤って「Suno の生成失敗」と分類してしまいます。正しくは「生成は成功、公開 content プロキシが上流 audio_url を解決できていない」です。

実装で必要なチェック

ダウンロード処理では、少なくとも次を確認します。

HTTP status: 200 または許容する 206
Content-Type: audio/* などのメディア型
Content-Length または実ダウンロードサイズ: エラーページより十分大きい
必要なら ffprobe などで再検証

エラーページを .mp3 や .mp4 として保存してしまう実装は避けるべきです。

推奨リトライ戦略

1回目: succeeded 直後にダウンロード
2回目: 10 秒後
3回目: 30 秒後
4回目: 60 秒後
最後: resultJson.data[0].audio_url を再確認

それでも失敗する場合は、task_failed ではなく content_unavailable のように分類すると、運用上の切り分けがしやすくなります。

まとめ

今回のポイントは単純です。

公開 /content の失敗 = Suno 生成失敗

ではありません。

Suno の実メディアは resultJson.data[0].audio_url にあり、そこからは正常に MP3 を取得できました。プロダクションでは、この URL を明示的に解析し、必要に応じて自社ストレージへ保存するのが安全です。