gemini-omni-1.2-flash 実践：3 つの動画生成ビジネスシーンと実装チェックリスト

まず入力形態とパラメータの境界を確認する

HiAPI が現在接続している公開モデル gemini-omni-1.2-flash は動画を出力し、4 つの生成モードを提供します：テキストから動画、ファーストフレーム画像から動画、ファースト・ラストフレーム遷移、参照画像から動画です。コードを書く前に、「今回何を入力するのか」を先に確定する方が、シーンを先に選ぶよりも効果的です。

現在提供していない機能には、動画編集、動画の続き生成、動画や音声の入力、seed パラメータが含まれます。これらに依存するフローは、このモデルでは実現できません。

リクエストパラメータ

• prompt：唯一の必須項目で、空でない文字列である必要があり、最大 20000 文字です。
• duration：整数で、3～15 秒、デフォルトは 10 秒です。
• resolution：360p / 720p / 1080p / 4k、デフォルトは 720p です。1080p と 4k はアップスケール出力で、4k は音声トラックを含まない場合があります。
• aspect_ratio：16:9 または 9:16、デフォルトは 16:9 です。

画像パラメータと排他関係

• image_urls：1～10 枚の公開 HTTP(S) 参照画像で、参照画像から動画を生成します。1 枚だけ渡しても参照画像のままで、自動的にファーストフレームモードになることはありません。
• first_frame_url：開始画面を指定し、単独で使用でき、ファーストフレーム画像から動画を生成します。
• last_frame_url：first_frame_url と一緒に使用する必要があり、ファースト・ラストフレーム遷移を生成します。ファースト・ラストフレームモードは最長 10 秒で、リクエストに negative_prompt や system_prompt を含めることはできません。
• image_urls と first_frame_url、last_frame_url は排他であり、1 回のリクエストでいずれか 1 つのモードしか選べません。
• すべての画像パラメータは公開アクセス可能な HTTP(S) URL のみを受け付け、Base64 はサポートしません。

事前に持っておくべき期待値：各モードが音声やリップシンク、文字の正確さを備えること、生成結果の主体やブランドが参照と完全に一致することは保証されません。これらはすべて人手による検収が必要です。

コストの基準：解像度別の秒単位料金

このモデルはリクエストの長さで課金され、単価は解像度の段階によって異なります。現在のデフォルト倍率での料金は以下の通りです：

• 360p：$0.0229/秒
• 720p：$0.0343/秒
• 1080p：$0.0343/秒
• 4k：$0.0800/秒

予算の換算は：選択した解像度の単価 × リクエストの長さ × 本数です。同じ仕様、同じ長さであれば、成功タスクが 1 本増えるごとに、通常は予算に 1 タスク分の金額が加算されるのであり、毎回の累計予算が倍になるわけではありません。

実際の請求と適用倍率はサイトの価格パネルに準じます。課金はリクエストの長さで計算され、出力ファイルコンテナ内の小数秒数から逆算することはできません。

予算に直結する 2 つの運用ルール：結果に不満があってタスクを再作成すると、1 タスク分の予算が増えます。ネットワークタイムアウトが発生した場合は、まず既存タスクの状態を照会し、作成が成功していないことを確認してから新規作成するかどうかを決めてください。

シーン 1：テキストによるクリエイティブ試作

適用場面：手元にテキストの brief しかなく、本格制作に入る前に複数のビジュアル方向を比較したい場合。これはテキストから動画の最も直接的な使い方です。

やり方

• brief を視覚化可能な記述に書き換える。「若い女性が早朝の街頭を速足で歩き、コーヒーを手に持つ、カメラは追従」の方が「活力あるライフスタイルを伝える」よりも実行可能です。
• prompt のみを渡し、画像パラメータは一切渡さず、方向ごとに 1 本ずつタスクを送信します。
• 短めの duration で 1 本あたりの予算を抑える。試作段階では長尺は不要です。同じバッチ内では duration と resolution を揃え、横比較しやすくします。
• 構造化して記録する：prompt、duration、resolution、タスク ID、結果 URL を一緒に保存し、次のイテレーションの参照にします。

境界

試作の成果物の用途は方向性の選択を助けることであり、配信素材ではありません。絵コンテの細部、ブランド标识、コンプライアンス字幕は通常、後続の専門制作が必要です。最終画面が既存素材と一致しなければならない場合は、ファーストフレーム画像から動画、または参照画像から動画に切り替えるべきです。

シーン 2：ファーストフレーム画像の動画化

適用場面：高品質な静止画（商品画像、カバー、イラスト、ポスター）がすでにあり、元画像の主体を保ちながら画面を動かしたい場合。

やり方

• first_frame_url で開始画面を指定し、prompt では主体を再記述するのではなく、動きとカメラ（軽いプッシュイン、ゆっくりした回り込み、光と影の流れ）だけを記述します。
• 終了画面を指定する場合は、first_frame_url と last_frame_url を同時に渡し、ファースト・ラストフレーム遷移を生成します。このとき duration は 10 秒を超えてはならず、リクエストに negative_prompt や system_prompt を含めることはできません。
• 画像は先に公開場所に置く：公開アクセス可能な HTTP(S) URL のみを受け付け、内部ネットワークアドレスや Base64 は使用できません。
• 1 件ずつデータベースに記録する：ソース画像 URL、prompt、duration、resolution、タスク ID を記録し、遡及や二次利用を容易にします。

参照画像モードとの違い

first_frame_url は「どこから始まるか」を決め、image_urls はスタイルとコンテンツの参照を提供します。両者は排他であり、同じリクエストで同時に使用できません。image_urls を 1 枚だけ渡してもファーストフレームモードにはなりません。

シーン 3：参照画像によるビジュアル制約

適用場面：一批の素材が色調、質感、構図の習慣において既存のビジュアルに近づく必要があり、単体の品質が主な課題ではない場合。

やり方

• image_urls で 1～10 枚の公開参照画像を渡し、目標スタイルを最もよく代表する少数の素材を選びます。目標が互いに衝突する参照画像を混用せず、実際の生成結果を確認します。
• これは参照画像モードであることを明確にする：1 枚だけ渡しても参照画像から動画であり、ファーストフレームやファースト・ラストフレームには関与しません。
• 固定のチェック項目を設ける：主色调、光の傾向、画面密度、テキスト領域について、新しく生成したバッチを横比較します。
• ズレを発見したらまず参照素材を確認し、その後に prompt を調整します。闇雲に再実行しないでください。再実行は秒単位で課金されるタスクを追加します。

境界

参照画像はスタイルの制約に使えますが、主体やブランドが完全に一致することは保証されず、人手による抜き取り検査が必要です。「スタイルの保険」ではなく「スタイルのベースライン」と理解すれば、期待値は実際に近づきます。

実装チェックリスト

作業前に項目ごとに確認することで、入力パラメータと予算の問題を早期に発見できます。

機能とパラメータ

• 今回どのモードを使うか明確か：テキストから動画、ファーストフレーム画像から動画、ファースト・ラストフレーム遷移、参照画像から動画？
• prompt は空でなく、20000 文字を超えていないか？
• duration は 3～15 秒の整数か？ファースト・ラストフレームモードでは 10 秒以内に収めているか？
• resolution と aspect_ratio は用途に応じて選定されているか（デフォルト 720p、16:9）？
• 画像ソースは image_urls または first_frame_url/last_frame_url のいずれか一方のみか？
• すべての画像が公開 HTTP(S) URL で、Base64 はないか？
• ファースト・ラストフレームのリクエストから negative_prompt と system_prompt を削除済みか？
• 動画編集、続き生成、動画/音声入力、seed を使用していないか？これらは現在提供していません。

コスト

• 選択した解像度の単価 × 長さ × 本数で予算を算出しているか、感覚で決めていないか？
• 予算は「納品本数」ではなく「候補本数」で見積もっているか？
• 同じ仕様、同じ長さであれば、成功タスクが 1 本増えるごとに 1 タスク分の予算が増えることを理解しているか？
• 実際の請求はファイルコンテナの小数秒から推測するのではなく、サイトの価格パネルと適用倍率に準じているか？

エンジニアリング

• タスク送信は非同期化され、リクエスト側が動画をブロックして待たないか？
• タスク ID を保持してデータベースに記録し、prompt、duration、resolution、結果 URL を含めているか？
• 明示的な状態機械と冪等キーがあり、重複送信を避けているか？
• ネットワークタイムアウト時は、いきなり再作成せず、まず既存タスクを照会しているか？
• 並列度を制限し、バッチタスクをキューで待機させているか？

品質と検収

• 検収基準を事前に固定しているか：主体の完全性、ブランド要素、テキスト領域、音声が期待通りか？
• 人手による抜き取り検査の割合を保持し、量産時にも下げていないか？
• 1 日または 1 バッチの予算にサーキットブレーカーとアラートを設定しているか？

4 つのモードは同じインターフェース形態を共有し、違いは入力パラメータだけです。モードを正しく選び、排他関係をパラメータ検証に書き込み、予算を本数単位で明確に計算してからバッチに進めば、実装の道筋は明確になります。