Sora API 終了、代替は? — Veo 3.1 へのコードレベル移行ガイド

OpenAI の Sora API は、2026年9月24日(2026-09-24)に公式に提供終了(シャットダウン)される予定です。 2026年9月25日以降、Sora の動画エンドポイントへのリクエストは HTTP 410 Gone を返す見込みで、OpenAI から公式の後継は発表されていません。つまり sora-2 / sora-2-pro の上に構築したパイプラインは、この日までに移行先を決める必要があります。

本ガイドでは、最短の移行パスとして Veo 3.1(gemini-veo31)を byesu 経由で使う手順を、コードレベルで解説します。byesu は OpenAI 互換と Anthropic ネイティブの両エンドポイントを備えた AI API ゲートウェイで、1 つのキーで Claude、GPT-5.6、Grok、Gemini とメディアモデルをカバーし、サブスクリプション不要の従量課金です。動画エンドポイントは Sora 連携が既に使っている非同期の形をそのまま踏襲しているため、多くのケースで移行作業は Base URL とモデル名の差し替えに収まります。

提供終了までのタイムライン

時期	何が起きるか
現在 → 2026-09-24	Sora API は稼働中。この期間内に移行を完了させてください
2026-09-24	公式の提供終了日
2026-09-25 以降	動画エンドポイントは 410 Gone を返す見込み。OpenAI API 内に公式後継なし

影響は Sora の動画関連エンドポイント全体に及びます。POST /v1/videos によるタスク作成、ステータスのポーリング、/content でのダウンロード、そしてその下流のパイプラインすべてが停止します。OpenAI の API 内に「アップグレード先」は存在しないため、これはバージョンアップではなくプロバイダ移行です。また、同じプロンプトでもモデルが変わると出力の傾向が変わるので、締め切り当日の一斉切り替えではなく、並行稼働でのサイドバイサイド検証の時間を確保しておくことをおすすめします。

移行先として Veo 3.1 が自然な理由

映像品質 — Google のフラッグシップ動画生成モデル。高精細な描写、シネマティックなカメラワーク、自然なモーションが持ち味です。
1080p 対応 — 1920x1080 を直接指定できます。Sora で一般提供されていたプランでは、多くのサイズでこれより低い解像度が上限でした。
画像からの動画生成 — 先頭フレーム参照を input_reference で指定でき(最大 2 枚)、フィールド名が Sora と同じなので i2v のコードはほぼそのまま移植できます。
同じ非同期ワークフロー — タスク作成 → ポーリング → mp4 ダウンロードという流れが、既存の Sora フローと同じ形です。
公式アップストリーム経由 — byesu はリクエストを公式チャネル経由で処理します(リバースエンジニアリング品やミラーではありません)。失敗したタスクは自動返金されます。

リクエストフィールドのマッピング:Sora → byesu `/v1/videos`

Base URL を https://api.openai.com/v1 から https://byesu.com/v1 に変更します。認証ヘッダーは Authorization: Bearer sk-... のままで構いません。

Sora のフィールド	Sora の値	byesu 経由の Veo 3.1	移行メモ
`model`	`sora-2` / `sora-2-pro`	`gemini-veo31`	2 ティアを 1 モデルで置き換え
`prompt`	自由記述	`prompt` — 変更なし	シーン + 動き + カメラ指定の書き方はそのまま有効
`seconds`	`"4"` / `"8"` / `"12"`	`"4"` / `"6"` / `"8"`	`12` → `8` にマッピング。`4` と `8` はそのまま
`size`	`1280x720`, `720x1280`, `1792x1024`, `1024x1792`	`1280x720`, `720x1280`, `1920x1080`	pro の横長サイズは `1920x1080` へ、縦長は `720x1280` へ
`input_reference`	先頭フレーム画像	`input_reference` — 同名	multipart リクエストのみ。最大 2 枚
ポーリング	`GET /v1/videos/{id}`	`GET /v1/videos/{id}`	変更なし
ダウンロード	`GET /v1/videos/{id}/content`	`GET /v1/videos/{id}/content`	変更なし。mp4 が返ります

トークンは media グループで作成してください

動画モデルの呼び出しには media / media-gen グループのトークンが必要です。他のグループのトークンを使うと「no available channel」エラーになります。テストの前にコンソールでトークンを作成してください。グループの仕組みはグループの選び方をご覧ください。

Before / After:タスクの作成

bash

# BEFORE — Sora(2026年9月24日に提供終了予定)
curl https://api.openai.com/v1/videos \
  -H "Authorization: Bearer sk-OPENAI_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "sora-2", "prompt": "赤い花の上でホバリングするハチドリ、マクロレンズ、朝の光", "seconds": "8", "size": "1280x720"}'

# AFTER — byesu 経由の Veo 3.1(変更点は文字列 2 つだけ)
curl https://byesu.com/v1/videos \
  -H "Authorization: Bearer sk-YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"model": "gemini-veo31", "prompt": "赤い花の上でホバリングするハチドリ、マクロレンズ、朝の光", "seconds": "8", "size": "1280x720"}'

Python での全体フロー(作成 → ポーリング → ダウンロード)

python

import requests, time

BASE = "https://byesu.com"          # 変更前: https://api.openai.com
H = {"Authorization": "Bearer sk-YOUR_TOKEN"}

# ステップ 1: タスクを作成
task = requests.post(f"{BASE}/v1/videos", headers=H, json={
    "model": "gemini-veo31",        # 変更前: sora-2 / sora-2-pro
    "prompt": "岩に砕ける波、スローモーション、シネマティック、夕暮れの光",
    "seconds": "8",                 # Veo 3.1 は 4 / 6 / 8 に対応
    "size": "1920x1080",            # 1080p — Sora の多くのサイズからのアップグレード
}).json()

# ステップ 2: 完了までポーリング
while task["status"] not in ("completed", "failed"):
    time.sleep(5)                   # 数十秒〜数分かかるのが普通です
    task = requests.get(f"{BASE}/v1/videos/{task['id']}", headers=H).json()

# ステップ 3: mp4 をダウンロード
if task["status"] == "completed":
    mp4 = requests.get(f"{BASE}/v1/videos/{task['id']}/content", headers=H)
    open("out.mp4", "wb").write(mp4.content)

タスクが failed で終わった場合、その費用は自動的に返金されます。手動での申請は不要です。

画像からの動画生成(`input_reference` は同名のまま)

bash

curl https://byesu.com/v1/videos \
  -H "Authorization: Bearer sk-YOUR_TOKEN" \
  -F model="gemini-veo31" \
  -F prompt="フレーム内の葉が風に揺れる中、被写体にゆっくりと寄っていくカメラワーク(スロープッシュイン)" \
  -F seconds="8" \
  -F size="1280x720" \
  -F input_reference=@first_frame.png

ポーリングとダウンロードの手順は、テキストからの生成と同じです。

料金比較

モデル	秒単価	8 秒クリップ
sora-2(OpenAI 公式定価)	$0.10/秒	$0.80
sora-2-pro(OpenAI 公式定価)	解像度により $0.30〜$0.50/秒	$2.40〜$4.00
Veo 3.1(Google 公式定価)	約 $0.40/秒	約 $3.20
byesu 経由の Veo 3.1	$0.01875/秒	約 $0.15

byesu の Veo 3.1 は純粋な秒単位課金です。合計金額は $0.01875 × seconds で決まり、6 秒なら約 $0.1125、8 秒なら約 $0.15 になります(sora-2 / sora-2-pro は OpenAI 公式定価、Veo 3.1 は Gemini API の公式料金ページに基づく概算で、いずれも執筆時点・2026 年 7 月のものです)。コンソールでは公式定価と並べて実際の請求価格をリアルタイムで確認でき、失敗したタスクには課金されません。サブスクリプションは不要で、生成した分だけの従量課金です。チャージ(入金)は Alipay / USDT に対応しています。

移行チェックリスト

byesu で media / media-gen グループのトークンを作成する。
Base URL を差し替える:https://api.openai.com/v1 → https://byesu.com/v1。
モデル名を差し替える:sora-2 / sora-2-pro → gemini-veo31。
seconds をマッピングする:12 → 8(4 と 8 はそのまま)。
size をマッピングする:1792x1024 / 1024x1792 → 1920x1080 / 720x1280。
作成 → ポーリング → /content のループはそのまま維持する。Webhook に依存していた場合は、完了検知を GET /v1/videos/{id} のポーリングに切り替える。
プロンプト集をサイドバイサイドで再検証する(同じ文言でもモデルが違えば描画は変わるため)。
multipart の input_reference リクエストで画像からの動画生成をテストする。
両プロバイダを並行稼働させたうえで、2026年9月24日より十分前に切り替えを完了する。

よくある質問

Sora API はいつ終了しますか?

OpenAI の Sora API は 2026年9月24日(2026-09-24)に公式に提供終了となる予定です。2026年9月25日以降、Sora の動画エンドポイントへのリクエストは HTTP 410 Gone を返す見込みで、OpenAI から公式の後継動画 API は発表されていません。sora-2 / sora-2-pro 上に構築した連携は、この日までに他プロバイダへの移行が必要です。

Sora API の代替として何が有力ですか?

Veo 3.1 は、現在主流のテキスト動画生成モデルの中でも有力な移行先のひとつです。高い映像品質、1080p 対応、先頭フレーム参照による画像からの動画生成、非同期タスクワークフローを備えています。AI API ゲートウェイの byesu では gemini-veo31 として OpenAI 互換の /v1/videos エンドポイントで提供されており、Sora 連携は Base URL とモデル名の差し替えで移行できます。

Sora から Veo 3.1 への移行で必要なコード変更はどの程度ですか?

ごくわずかです。byesu の動画エンドポイントは、Sora 連携が既に使っている非同期の 3 ステップをそのまま踏襲しています。POST /v1/videos でタスクを作成し、GET /v1/videos/{id} でステータスをポーリングし、GET /v1/videos/{id}/content で mp4 をダウンロードします。Base URL を https://byesu.com/v1 に向け、model を gemini-veo31 に変更し、seconds と size を Veo の対応値にマッピングするだけです。

Veo 3.1 の料金は Sora と比べてどうですか?

byesu の Veo 3.1 は秒単位の課金で $0.01875/秒、8 秒クリップは約 $0.15 です。比較として、執筆時点の OpenAI 公式定価は sora-2 が $0.10/秒、sora-2-pro が解像度に応じて $0.30〜$0.50/秒です。byesu では失敗した動画タスクは自動的に返金されます。

Veo 3.1 は Sora の input_reference のような画像からの動画生成に対応していますか?

はい。しかもフィールド名は同じです。作成リクエストを multipart/form-data で送り、先頭フレーム画像を input_reference ファイルフィールドに添付します(Veo 3.1 は最大 2 枚まで)。モデルはその画像を起点に動画を生成し、ポーリングと mp4 のダウンロードはテキストからの生成と同じ手順で動きます。

Sora API 終了、代替は? — Veo 3.1 へのコードレベル移行ガイド ​

提供終了までのタイムライン ​

移行先として Veo 3.1 が自然な理由 ​

リクエストフィールドのマッピング:Sora → byesu /v1/videos ​

Before / After:タスクの作成 ​

Python での全体フロー(作成 → ポーリング → ダウンロード) ​

画像からの動画生成(input_reference は同名のまま) ​

料金比較 ​

移行チェックリスト ​

関連リンク ​

よくある質問 ​

Sora API はいつ終了しますか? ​

Sora API の代替として何が有力ですか? ​

Sora から Veo 3.1 への移行で必要なコード変更はどの程度ですか? ​

Veo 3.1 の料金は Sora と比べてどうですか? ​

Veo 3.1 は Sora の input_reference のような画像からの動画生成に対応していますか? ​