画像から動画生成 API ワークフロー：Runway、Wan 2.7、Vidu、そして本番環境の API パターン

手元に静止画像がある——製品レンダリング画像、承認済みのキービジュアル、キャラクター設定画——これを動かす必要がある。大まかに似た新しいシーンを生成するのではなく、そのフレーム自体を動かすのだ。これこそが画像から動画生成（i2v）が行うことであり、「プロンプトを入力してモデルが頭の中の映像を描いてくれることを期待する」のとはまったく異なる統合手法である。本記事は実践版である：ソース画像を準備し、動きの開始位置と終了位置を制御し、映像を再描写するのではなくアニメーションを駆動するプロンプトを書き、数分に及ぶレンダリングがバックエンドを圧迫しないようポーリングとコールバックを適切に処理する。

まだ i2v を使うべきかテキストから動画生成を使うべきかで悩んでいる？本記事はすでに決断した読者を想定し、i2v をうまく使いこなすことを目的としている。

画像から動画生成が適する場面

開始フレームに妥協できないとき、i2v を使うべきである。モデルは被写体をゼロから創造しているのではなく、你的图片を受け取って動きを加えている。そのため、ブランドの一貫性や造形の一貫性を保たなければならないあらゆるコンテンツは、テキストから動画生成では保証できない安全策を得られる——実在 SKU の製品画像、承認済みキービジュアルをページヘッダーのループアニメーションに変換、顔の一貫性を保つキャラクター設定画、あるいは開始フレームと終了フレームを固定してモデルに遷移過程を埋めさせる before→after 効果などである。被写体が柔軟であれば、テキストから動画生成の方が通常は作業量が少ない。i2v の核心的価値は、静止画像が固定されていることにある。

2026 年の画像から動画生成の勢力図

i2v 領域は競争が激しく、ハードルも高い。背景として知っておく価値はあるが、以下の呼び出し可能なワークフローは厳選されたモデルセット上で動作する：

• Runway Gen-4 / Gen-4.5。 Gen-3 Alpha の後継であり、カットをまたぐ「ワールド一貫性」や物理ベースの動きと意図的なカメラワークを推進した。Gen-4.5 の i2v は、広告やクライアント納品物においてタイトなクリエイティブ制御を求める最良の選択肢と広く見なされている（Runway Research，「Introducing Runway Gen-4」，2026；ZNIX モデルまとめ，2026）。Gen-4.5 画像から動画生成も HiAPI で提供されており、モデル ID は runway-gen-4.5/image-to-video である。詳しくは Runway Gen-4.5 API ガイドを参照。
• Vidu Q3。 先頭フレームと末尾フレームの条件付けを中心に構築されており、開始フレーム・目標終了フレーム・プロンプトの変化を指定すると中間を埋める。最大 16 秒の 1080p 音声付きに対応（Vidu，「AI Image to Video」，2026）。
• Kling 3.0。 参照静止画像からの複雑な人体動作の生成に優れ、4K とリップシンクをネイティブサポートする（TeamDay.ai，「Best AI Video Models 2026」，2026）。
• Seedance 2.0。 バイトダンスのモデル（2026 年 2 月 12 日）で、フレーム間で製品のディテール、ロゴ、文字を安定して保つ——まさに e コマースの i2v に必要な機能である（opencreator.io，「AI Video Models Comparison 2026」，2026）。

強力なモデル間のパターンは一貫している：先頭フレーム制御は基本要件であり、末尾フレーム制御はもはや珍しくなく、両端を固定することはクリップが最後の一秒でドリフトするのを防ぐ最も信頼できる方法である。以下のワークフローはまさにこの原則を中心に構築されている。HiAPI 上で呼び出せる 2 つの i2v モデルは Seedance 2.0（バイトダンス）と Wan 2.7 画像から動画生成（阿里巴巴）である。

ステップ 1——ソース画像を準備する

これは人々がしばしば飛ばして、その後モデルのせいにするステップである。i2v を使う場合、最初のフレームこそが品質の上限である。何かを送信する前に、3 つのことを済ませておく必要がある：

• アスペクト比を出力に合わせる。 4:3 でソース画像をレンダリングしながら 16:9 のクリップを要求すると、モデルはクロップまたはパディングせざるを得ず、最終的に何が残るかの制御を失う。まず出力比率を決め、その比率で静止画像を作る。Seedance は adaptive 比率も受け付け、ソース画像のサイズに自動で合わせる。
• 希望する出力解像度でレンダリングする。 480p のソース画像が鮮明な 1080p クリップになることはない。ぼやけた入力のアップスケーリングは、ぼやけを動かすだけである。
• 被写体をクリーンに構図する。 明確で雑然としない被写体は、モデルの誤解を減らす。雑然とした背景とぼやけたエッジこそが奇妙な動きの原因である。

次にホスティングする。API はソース画像を URL（first_frame_url）として受け取り、ファイルアップロードではないため、HTTPS でアクセス可能でなければならない——あなたのストレージバケット、CDN、署名付きオブジェクトストレージなどである。localhost パスや API が取得できないリンクはタスクの失敗につながる。

ステップ 2——先頭フレーム付きでタスクを送信する

HiAPI では、すべてのモデル（動画を含む）が非同期タスク APIを通じて動作する。タスクを作成するとすぐに taskId が返され、レンダリングはサーバー側で行われる。テキストから動画生成を画像から動画生成に変えるには、フィールドを 1 つ追加するだけでよい：first_frame_url である。以下は Seedance 2.0 を使った最小限の呼び出しである：

curl -X POST https://api.hiapi.ai/v1/tasks \
  -H "Authorization: Bearer sk-<your-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "seedance-2-0",
    "input": {
      "prompt": "Slow cinematic push-in, a soft light sweep travels across the surface, the subject holds steady and in focus",
      "first_frame_url": "https://cdn.your-domain.com/assets/product-front.jpg",
      "aspect_ratio": "16:9",
      "duration": 5,
      "resolution": "720p",
      "generate_audio": false
    }
  }'

これが完全な画像から動画生成リクエストである。重要な入力フィールドは以下の通り：

• first_frame_url — アニメーション化する静止画像であり、この存在こそが i2v の鍵である。
• aspect_ratio — ソース画像に合わせる（または adaptive を使用）。
• duration — 出力秒数。長いほどコストが高く、動きがドリフトする余地も大きくなる。
• resolution — 480p / 720p / 1080p。主要なコスト調整項目である。
• generate_audio — 無音ループや製品画像ではオフにする。

完全なリクエストとレスポンス構造はドキュメントを参照。Wan 2.7 画像から動画生成も同じ作成・ポーリング・ダウンロードのフローに従うが、入力が異なる——media 配列にソースフレームを格納し、720p または 1080p を出力する——そのため、Seedance のリクエストボディをそのまま再利用するのではなく、正確な構造についてはドキュメントを参照されたい。

ステップ 3——結末が重要な場合は末尾フレームを追加する

先頭フレーム制御はクリップがどこから始まるかを決め、モデルにどう終わるかを委ねる——まさにここでドリフトが静かに現れる。モデルが後半を即興で作るからである。最後のフレームを通じた連続性が重要なら、それも固定しよう：

{
  "model": "seedance-2-0",
  "input": {
    "prompt": "The product rotates a quarter turn and settles, light resolving to a clean studio key",
    "first_frame_url": "https://cdn.your-domain.com/assets/product-front.jpg",
    "last_frame_url": "https://cdn.your-domain.com/assets/product-three-quarter.jpg",
    "aspect_ratio": "16:9",
    "duration": 5,
    "resolution": "720p"
  }
}

これで両端が固定され、モデルはその間の動きだけを埋める。これは製品お披露目や before→after 遷移の主力パターンであり、「最後の一秒まで良かったのに」という問題を解決する最も効果的な単一の修正方法である。2 つのフレームは同じ被写体と構図に保つこと——開始画像と終了画像の差が大きすぎると、モデルはその間に経路をゼロから創造せざるを得ず、また推測の状態に戻ってしまう。

ステップ 4——静止画像のためのモーションプロンプトを書く

i2v ではプロンプトが異なる役割を担い、間違えるとレンダリングを無駄にする。テキストから動画生成では、プロンプトがシーン全体を構築する。画像から動画生成では、モデルはすでにシーンを見ている——あなたが与えたフレームの中にある——ため、プロンプトの役割はコンテンツではなく時間を通じた変化である：

• カメラワークから始める。 「Slow dolly-in」「gentle pan left」「push-in then hold」。モーションモデルはカメラワーク動詞を確実に従うため、明示的に 1 つ与える。
• 被写体が何であるかではなく、どのように動くかを描写する。 「Steam begins to rise」「the fabric sways」「the screen wakes and glows」。アニメーションを演出しているのであり、物体を再列挙しているのではない。
• 画面を再描写しない。 ソース画像から明らかな内容を繰り返すとモデルと対立し、アニメーション化ではなく再生成へと引きずられる可能性がある。
• 動きを時間内で合理的にする。 5 秒のクリップに 20 秒の物語は収まらない。

良い i2v プロンプトは、画家へのシーン描写ではなく、カメラマンへの動作指示のように読める。

ステップ 5——ポーリングするかコールバックを受け取る

動画は GPU 分を消費し、ミリ秒ではない。レンダリングは意図的に非同期に設計されているため、接続を開いたままにすることは決してない。タスクを作成した後、完了を知る方法は 2 つある。

ポーリングして終態に達するまで待つ——スクリプトやプロトタイプ向け：

curl https://api.hiapi.ai/v1/tasks/<taskId> \
  -H "Authorization: Bearer sk-<your-key>"
# data.status: queued -> handling -> archiving -> success (or fail)
# on success, read data.output[0].url and download it promptly — the URL expires

コールバックを受け取るのはプロトタイプ以外のあらゆる場面に適している。ポーリングループに座っている代わりに、コールバックを渡して HiAPI に終態をプッシュさせる：

{
  "model": "seedance-2-0",
  "input": { "prompt": "...", "first_frame_url": "https://cdn.your-domain.com/assets/product-front.jpg", "aspect_ratio": "16:9", "duration": 5, "resolution": "720p" },
  "callback": { "url": "https://your-domain.com/hooks/hiapi", "when": "final" }
}

どちらの場合も、出力 URL には有効期限がある。タスクが success になったらすぐに data.output[0].url を自分のストレージにダウンロードすること——ページにホットリンクしたり、クライアントに渡したりしてはいけない。期限切れになるからである。

本番環境で耐えうるパターン

いくつかの習慣が、デモスクリプトと大規模に運用できるものを分ける：

• 規模が大きい場合はポーリングよりコールバックを優先する。 タスクごとのポーリングループは計算とレート制限の負荷を浪費する。結果をダウンロードしてレコードを更新するコールバックエンドポイント 1 つは、数百のポーラーよりもはるかにスケールする。
• 送信を冪等にする。 リトライと少なくとも 1 回のコールバックは発生する。レンダリングごとに安定した ID（ソース画像 + プロンプト + パラメータをハッシュ化）を設定し、リトライが気づかないうちに重複クリップを生成——そして課金——しないようにする。
• コストは解像度 × 時間である。 動画は秒単位で課金され、レートは解像度とともに上がるため、1080p 10 秒クリップは 480p 5 秒クリップよりはるかに高い。480p で反復し、プロンプトとカメラワークを固め、その後は保持したクリップだけを納品解像度で再レンダリングする。リアルタイムのレートは料金ページを参照——変動するためコードにハードコードしないこと。
• レンダリング回数ではなく利用可能なクリップで予算を組む。 3 つのクリップのうち 1 つだけを保持するなら、納品可能なアセットごとの実コストは表示価格の 3 倍になる——1 秒あたりのレートではなくこの比率が予算を決める。だからこそ 480p でプロンプトを固めることがコストを回収するのである。
• ソース URL を早い段階で検証する。 API が取得できない先頭フレームは最も一般的な回避可能な失敗である——送信前に HTTPS でアクセス可能か確認する。

よくある質問

リクエストにおいて、画像から動画生成とテキストから動画生成はどう違うのか？ フィールド 1 つである。タスク呼び出しは他の点ではまったく同じで、first_frame_url（ソース画像）を追加すればテキストから動画生成から画像から動画生成に切り替わる。HiAPI ではどちらも同じ POST /v1/tasks エンドポイントを通じて動作する。

先頭フレームと末尾フレームを同時に制御できるか？ できる。first_frame_url が開始フレームを固定し、last_frame_url を追加すると終了フレームが固定され、モデルは 2 つの固定端点間の動きだけを埋める。両端を同時に固定することは、遷移を制御しクリップ終盤のドリフトを防ぐ最も信頼できる方法である。

Runway Gen-3/Gen-4 API は画像から動画生成をサポートしているか？ Runway の Gen-3 および Gen-4 シリーズは画像から動画生成をサポートし、映画級の制御に優れている——これがより広い勢力図である。本ガイドの呼び出し可能なワークフローは Seedance 2.0 と Wan 2.7 画像から動画生成上で動作し、HiAPI はそれらを 1 つのタスク API の背後でホストしている。Runway Gen-4.5 画像から動画生成も同じ API 上で動作する。Runway Gen-4.5 API ガイドに動作するリクエスト例がある。

画像から動画生成のレンダリングにはどれくらいかかるか？ 数分であり、数秒ではない——動画は実際の計算である。だから API は非同期なのである：タスクを作成し、ポーリングするかコールバックを受け取るため、長時間のレンダリングがリクエストをブロックすることは決してない。

要点まとめ

画像から動画生成は、特定の静止画像がそのまま画面に現れてから動き出す必要がある場合に適している。品質の上限は最初のプロンプトを書く前に、ソース画像の解像度・アスペクト比・構図によってすでに決まっている——だからまずそれを準備し、安定した場所にホストする。先頭フレームを固定してクリップが始まる位置を制御し、結末が着地する必要がある場合は末尾フレームを追加し、プロンプトはモデルがすでに見ている画面を再描写するのではなく、動きとカメラワークの指示として書く。そしてそれを本来の非同期タスクとして扱う：ポーリング、あるいはより良いのはコールバックを受け取ること；送信を冪等にする；URL が期限切れになる前にダウンロードする；納品解像度で利用可能なクリップに基づいて予算を組む。

準備ができたら、ソース画像を Seedance 2.0 モデルページまたは Wan 2.7 画像から動画生成で実行し、上記のタスク API に接続し、規模を拡大する前に料金ページでリアルタイムの 1 秒あたりレートを確認する。（先にキー不要のオプションを探したい場合は、無料テキストから動画生成オプションを参照。）