Gemini Omni Flash は、Gemini API で提供されているプレビュー版のマルチモーダル動画モデルです。モデル名は gemini-omni-flash-preview です。高速な動画生成、動画編集、ショット制御を目的としており、単に「一文のプロンプトから動画を生成する」だけでなく、テキスト、画像、音声、動画、複数ターンのやり取りを同じワークフローに入れられる点が重要です。
特に注目したいのは、動画生成が一回限りの出力から、反復的な編集へ進み始めていることです。開発者はまず動画を生成し、その後のプロンプトで光、背景、物体、文字、スタイルを修正できます。さらに previous_interaction_id を使うことで、モデルに前回の動画状態を引き継がせることができます。短尺動画ツール、広告素材、製品デモ、教育コンテンツ、クリエイティブな試作では、毎回最初から生成し直すより実際の制作フローに近くなります。
最初に押さえておくべき点があります。Gemini Omni Flash は現在もプレビュー版です。実験、プロトタイプ検証、社内ツールへの組み込みには向いていますが、代替策なしで重要な本番フローを任せるべきではありません。
Gemini Omni Flash でできること
公式ドキュメントでは、Gemini Omni Flash は高性能なマルチモーダルモデルとして位置づけられています。主な機能は次の 3 つです。
- テキストから動画:テキストプロンプトを入力し、音声付きの動画を生成する。
- 画像から動画:参照画像をアップロードし、動き、カメラ、雰囲気をプロンプトで指定する。
- 状態を引き継ぐ動画編集:前回生成した動画をもとに編集を続け、すべての画面要素を説明し直さずに済ませる。
従来の動画モデルとの違いは、主に「インタラクション」にあります。Gemini API の Interactions API では、1 回の生成や編集が 1 つの interaction になります。後続のリクエストは以前の interaction を参照できるため、モデルは文脈を理解し、変更を要求されていない内容をできるだけ維持できます。
最小の呼び出し方
Gemini Omni Flash は interactions.create で呼び出します。最もシンプルなテキストから動画のリクエストでは、モデル名とプロンプトだけを指定します。
|
|
REST API を直接使う場合は、レスポンス構造が SDK と異なる点に注意してください。SDK では interaction.output_video のような便利なフィールドが用意されていますが、REST レスポンスでは通常、steps 配列内の model_output から動画コンテンツを探す必要があります。
アスペクト比と出力を制御する
デフォルトの出力は横長の 16:9 です。縦長動画を生成したい場合は、response_format で aspect_ratio を設定します。
|
|
これは短尺動画、広告素材、モバイル向けコンテンツで特に重要です。プロダクト側では、横長と縦長を明確な選択肢として用意するほうがよいです。自然言語プロンプトだけに任せるより、パラメータのほうが安定します。
画像から動画を組み込む
画像から動画では、画像とテキストを組み合わせて入力します。画像は、動きの参照、被写体の参照、スタイルの参照、または開始フレームとして使えます。基本的な入力構造は次のとおりです。
|
|
実際に使うときは、「動かして」とだけ書かないほうがよいです。より良いプロンプトでは、動き、ショット、場面、ライティング、保持すべき要素を明確にします。たとえば製品画像から短い動画を生成する場合、製品の外観とブランドロゴを変えないこと、カメラをどう動かすか、背景をどう変えるかを指定します。
入力に複数の画像がある場合は、video_config.task でタスク種別を明示し、モデルの推測を減らすのがおすすめです。
|
|
task は text_to_video、image_to_video、reference_to_video、edit を区別するために使えます。アプリ開発では、上級ユーザーや社内テンプレートシステムに公開する価値のあるパラメータです。
状態を引き継ぐ動画編集
状態を引き継ぐ編集は、Gemini Omni Flash を単発の生成 API ではなく、制作ツールらしく見せる部分です。1 回目で動画を生成したあと、2 回目のリクエストでは previous_interaction_id で前回の結果を参照できます。
|
|
ここで大事なのは長いプロンプトを書くことではなく、変更点を正確に書くことです。公式のプロンプトガイドでも、動画編集では短い指示のほうが適していることが多いとされています。局所的な要素を変更するときは、Keep everything else the same. を追加すると、関係ない画面まで変わってしまう可能性を下げられます。
自分の動画を編集する
ユーザーがアップロードした動画を編集する場合、公式ドキュメントでは、まず Files API で動画をアップロードし、そのファイル URI を Gemini Omni Flash に渡す方法が推奨されています。理由は単純です。動画ファイルは大きくなりやすく、base64 を直接リクエストに入れると、サイズと安定性の面で扱いづらくなるからです。
この機能を組み込む場合、プロダクト層では少なくとも次の 4 点を扱う必要があります。
- アップロード後にファイル状態をポーリングし、
PROCESSINGではなくなったことを確認する。 FAILED状態を処理し、ユーザーが理解できる失敗理由を表示する。- 大きなファイル、長い動画、高解像度素材に明確な制限を設ける。
- アップロード動画の編集に対応していない地域では、この機能を非表示または縮退させる。
公式ドキュメントでも、すべての地域でアップロード動画の編集がサポートされるわけではないと説明されています。グローバル向けのプロダクトでは、「モデルが生成した動画を編集できる」ことと「ユーザーがアップロードした動画を編集できる」ことを同じ機能として扱わないほうがよいです。
大きな動画では URI 配信を使う
生成される動画が 4MB を超える場合は、response_format で delivery: "uri" を使うのがおすすめです。これにより、レスポンスには Google がホストする URI が返り、クライアントは状態をポーリングして動画をダウンロードできます。巨大な base64 を JSON に埋め込む必要がありません。
Web アプリでは特に便利です。フロントエンドはタスク進行状況を表示し、バックエンドがポーリングとダウンロードを担当できます。ブラウザで巨大なインラインレスポンスを処理する必要がなくなります。ただし注意点があります。公式ドキュメントによると、GET /v1beta/interactions/{id} は現時点で data フィールドに埋め込み base64 を返す場合があり、uri フィールドが保証されるのは初回作成レスポンスまたは SSE ストリームです。URI に依存するフローでは、作成レスポンスの段階で関連情報を保存しておくべきです。
プロンプト:ショットを明確にする
Gemini Omni Flash はデフォルトで複数ショットを生成することがあります。単一ショットが必要なら、明確に書きます。
- 単一の途切れないシーン。
- 連続したショット。
- シーンカットなし。
テンポを制御したい場合は、「3 秒後に人物がフレームに入る」のように自然言語で時間を説明できます。[0-3s]、[3-6s] のような時間範囲を書いてもよいです。広告、チュートリアル、製品紹介では、画面だけを説明するより制御しやすくなります。
動画内に文字を表示したい場合も、文字内容を明確に書くべきです。モデルは読める文字のレンダリングを試みますが、看板、字幕、画面上のテキストをプロンプトで定義していないと、不安定または意味のない文字が生成されることがあります。
現在の制限
Gemini Omni Flash プレビュー版には、導入前に確認すべき制限があります。
- 欧州経済領域、スイス、英国では、未成年者を含む画像のアップロードと編集はサポートされません。
- 識別可能な人物が含まれる一部の画像は、アップロードと編集に対応していません。
- 欧州経済領域、スイス、英国のユーザーは、現時点でアップロード動画を編集できません。ただし、モデルが生成した動画は編集できます。
- 現在の API は、音声参照のアップロードをサポートしていません。
- 複数の動画をまたいだ参照や推論はサポートされません。
- 動画の延長、動画補間、音声編集はサポートされません。
- provisioned throughput はサポートされません。
- システム指示、temperature、
top_p、停止シーケンス、ネガティブプロンプトなどの一般的な生成パラメータはサポートされません。 - YouTube 動画をメディアソースとして使うことはできません。
これらの制限はプロダクト設計に直接影響します。企業向けに提供する場合は、地域、人物素材、アップロード動画、審査ポリシー、失敗時の表示をワークフローに組み込むべきです。入力欄と生成ボタンだけで済ませるべきではありません。
開発者向けの導入ポイント
Gemini Omni Flash を自分のアプリに組み込むなら、次の順番が現実的です。
- まず
16:9と9:16だけをサポートするテキストから動画の MVP を作る。 - 画像から動画を追加し、アップロード形式とサイズを制限し、プロンプトテンプレートを用意する。
- 状態を引き継ぐ編集を追加し、各ターンの
interaction.idをタスク記録に保存する。 - 大きな動画では URI 配信を有効にし、base64 レスポンスでフロントエンドやバックエンドを圧迫しないようにする。
- 地域制限、コンテンツ安全性による失敗、ファイル処理失敗、タイムアウトを明確な状態として扱う。
- 最後に、複数画像参照、タイムコード、文字レンダリング、より複雑なショットテンプレートを開放する。
現時点では、通常のチャットインターフェースよりも「クリエイティブなワークフローツール」に向いています。よいプロダクト体験は、短い広告を作る、製品画像を動かす、背景を差し替える、光を変える、字幕を追加する、縦長版を作る、といったタスクを軸に整理するべきです。すべての機能を 1 つの自由入力欄に詰め込むべきではありません。
まとめ
Gemini Omni Flash の価値は、動画生成、画像参照、複数ターン編集を同じ Interactions API ワークフローに入れられることです。最も堅牢な本番級の動画パイプラインではありませんが、クリエイティブな試作、素材生成ツール、社内自動化にはすでに有用です。
実際に導入するときの要点は、gemini-omni-flash-preview を呼び出せることだけではありません。タスク状態、ファイルアップロード、地域制限、プロンプトテンプレート、失敗処理をまとめて設計することです。動画モデルが強くなるほど、プロダクト層は境界をより明確に示す必要があります。