Googleは2026年6月30日、Gemini APIでgemini-omni-flash-previewを公開した。テキスト、画像、音声、動画を入力として扱い、短尺動画の生成と会話形式の編集をInteractions APIで行える。

初期出力は3〜10秒、720pの動画が中心である。前の生成結果をprevious_interaction_idで参照し、「背景だけ変える」「照明を暗くする」「特定要素を消す」といった追加指示を重ねられる。

この方式は、1回のプロンプトで完成品を得る生成から、AIとの対話を制作工程として扱う生成へ移る変化である。一方、制作状態がAPI側のInteraction履歴へ依存するため、従来の「プロンプトと最終ファイルだけを保存する」運用では再現性と監査性が不足する。

確認できた主な仕様

項目内容
モデルgemini-omni-flash-preview
提供状態パブリックプレビュー
主な出力3〜10秒、720pの短尺動画
入力テキスト、画像、音声、動画
編集previous_interaction_idによる会話型編集
来歴生成動画にSynthIDを付与
大容量出力4MBを超える場合はURI配信を推奨
プロビジョンドスループット非対応
主な非対応動画延長、補間、音声編集、複数動画推論など
設定制約system instruction、temperature、top_p、stop sequence等は非対応
言語英語は正式対応、その他は評価未完了

プレビュー機能は、仕様、品質、料金、提供地域、制限が変更される可能性を前提に導入する必要がある。

対話型編集で状態管理が変わる

従来の動画生成では、次を保存すれば再生成の手掛かりを得られた。

  • モデルID
  • プロンプト
  • シードまたは設定
  • 入力素材
  • 出力動画

Omni Flashの会話型編集では、各ターンが前のInteractionへ依存する。

Interaction 1: 商品を机の上に配置
  -> video v1
Interaction 2: 背景を夜景に変更
  -> video v2
Interaction 3: ロゴを右下へ移動
  -> video v3

最終ターンの「ロゴを右下へ移動」だけを保存しても、v3を再現できない。必要なのは編集履歴全体である。

最低限、次を1つの制作案件として保存する。

{
  "asset_id": "campaign-2026-summer-014",
  "model": "gemini-omni-flash-preview",
  "interactions": [
    {"id": "...", "prompt": "...", "parent": null},
    {"id": "...", "prompt": "...", "parent": "..."},
    {"id": "...", "prompt": "...", "parent": "..."}
  ],
  "source_assets": ["sha256:..."],
  "approved_output": "sha256:...",
  "review": {"status": "approved", "reviewer": "..."}
}

Interaction IDだけに依存せず、入力、指示、出力の原本を自社側へ保存する。

store=falseは速度と再編集性の交換条件

公式資料では、background=falsestore=falsestream=falseによる同期処理が高速化の選択肢として案内されている。一方、store=falseを設定すると、生成動画を後続ターンでprevious_interaction_idから編集できない。

したがって、すべての処理で機械的にstore=falseを使うべきではない。

用途推奨方針
一回生成して破棄するプレビューstore=falseを検討
会話型に複数回編集する制作状態保存が必要
機密素材を扱う保持条件と契約を確認し、必要最小限にする
監査対象の完成品自社側に完全な履歴と成果物を保存

速度、データ保持、編集可能性の三つを明示的に選択する必要がある。

再現性は「同じ動画」ではなく「説明可能性」で設計する

生成動画は確率的であり、同じ入力から完全に同じ結果が得られるとは限らない。さらにOmni Flashではsystem instruction、temperature、top_p、stop sequenceなど、一般的な生成制御の一部が使えない。

そのため、監査で保証すべきものを分ける。

再現できるもの

  • 使用モデル
  • 入力素材
  • 素材のハッシュ
  • 各ターンの指示
  • Interactionの親子関係
  • 生成日時
  • API設定
  • 出力ファイル
  • 承認結果

完全再現を保証しにくいもの

  • 同じ画素列の再生成
  • 同一の人物動作
  • 同一のカメラ運動
  • 同じ生成時間

「後から同じ動画を再生成できる」ことより、「何を入力し、どの変更を行い、誰がどの成果物を承認したか」を証明できることが重要である。

SynthIDだけでは社内来歴管理にならない

すべての生成動画には、検出可能な不可視のSynthIDが付与される。これは生成物の来歴確認に有用である。

ただし、SynthIDは次を単独で説明しない。

  • 誰が生成したか
  • どのプロンプトを使ったか
  • どの素材を入力したか
  • 素材の利用権があったか
  • どの編集ターンを経たか
  • 誰が公開を承認したか
  • どのキャンペーンで使ったか

したがって、SynthIDを内部の資産台帳、C2PA等のメタデータ、承認履歴の代替と考えてはならない。

公開時は、生成物ハッシュ、制作案件ID、モデル、生成日時、素材権利、承認者を社内台帳へ紐付ける。

入力素材の権利確認が先に必要

対話型編集では、自社または第三者の動画、画像、音声をアップロードして変形できる。技術的に入力できることと、契約上利用できることは別である。

確認する項目は次の通りである。

  • 著作権
  • 出演者の肖像・パブリシティ権
  • 音楽・音声の利用許諾
  • 商標
  • ストック素材のAI加工可否
  • 顧客から預かった素材の利用目的
  • 未成年者を含む素材
  • 実在人物の編集
  • 地域別の規制

Googleの制限には、特定の実在人物を含む画像編集、欧州経済領域・スイス・英国での未成年者画像のアップロード・編集など、地域や対象に関する制約がある。

素材管理システムに次の属性を追加するとよい。

ai_edit_allowed: true/false
allowed_regions: [JP, US]
recognizable_person: true/false
minor_present: true/false
license_expires_at: ...
approval_required: legal

プレビュー品質をどう評価するか

動画生成では、1本の見栄えだけでは運用品質を判断できない。

画質・内容

  • 指示した対象が維持されるか
  • 商品形状やロゴが変形しないか
  • 人物の顔、手、動作が破綻しないか
  • カメラワークが意図通りか
  • テキスト表示が正しいか
  • 背景変更で前景が崩れないか
  • ターンを重ねても未指定要素が保持されるか

安全・ブランド

  • 禁止表現が含まれないか
  • ブランドガイドに沿うか
  • 競合ロゴが出ないか
  • 誤解を招く合成になっていないか
  • 実在人物の発言や行動を捏造していないか

運用

  • 生成時間
  • 失敗率
  • タイムアウト率
  • 再試行成功率
  • URI有効期限
  • 生成物の取得失敗
  • 同時実行時の待ち時間
  • 地域別エラー

制作効率

  • 初回採用率
  • 平均編集ターン数
  • 再生成率
  • 人手修正時間
  • 承認却下率
  • 完成までの経過時間
  • 承認済み素材1件当たりの総費用

単価が安くても、5回再生成し、人手で30分修正するなら総コストは高い。

非同期処理と冪等性

動画生成は入力長、解像度、負荷により時間が変動する。HTTPリクエストのタイムアウトを、そのまま生成失敗と見なして再送すると、同じ制作依頼が重複実行される可能性がある。

内部ジョブには冪等キーを付ける。

idempotency_key = asset_id + revision + prompt_hash

状態を明示する。

queued
submitted
processing
generated
downloaded
validated
review_pending
approved
rejected
failed_retryable
failed_terminal

再試行前に既存Interactionと出力を確認し、生成成功後のダウンロード失敗と、生成自体の失敗を分ける。

URI配信とファイル保存

4MBを超える動画では、レスポンスへBase64を直接含めるよりURI配信が推奨される。URIを受け取っただけでジョブを完了してはならない。

確認する項目は次の通りである。

  • URIから取得できたか
  • HTTPステータス
  • Content-Type
  • ファイルサイズ
  • 動画の長さ
  • 解像度
  • コーデック
  • ハッシュ
  • ウイルス・マルウェア検査
  • 保存先
  • URI失効前の取得

ダウンロード後は、自社のオブジェクトストレージへ保存し、元URIと取得日時を記録する。

Provisioned Throughput非対応の影響

Omni Flashは現時点でProvisioned Throughputに対応しない。一定の専有処理能力を前提にSLAを設計できないため、広告公開直前の大量生成や締切が厳しいバッチには注意が必要である。

実務上は次を用意する。

  • 生成締切に余裕を持つ
  • キューと同時実行上限
  • バックプレッシャー
  • 容量不足時の受付停止
  • 別モデルまたは人手制作へのフォールバック
  • 重要案件の事前生成
  • 待ち時間の利用者表示

リアルタイムの対話UIに組み込む場合でも、動画完成までの待機を業務フローへ織り込む必要がある。

非対応機能を前提に企画しない

現時点では、複数動画を横断した推論、動画延長、最初と最後のフレーム間を作る補間、音声編集などは非対応である。また、短い参照動画がAPIスキーマ上受理されても正しく処理されない場合があるとされる。

企画段階で「将来できるかもしれない機能」を要件へ含めず、現行の公式制約で成立する制作工程を設計する。

音声を含む完成動画が必要な場合は、映像生成と音声制作を分離し、同期、権利、安全確認を別工程として設ける。

推奨する本番アーキテクチャ

利用者
  -> 制作受付API
     -> 権利・地域・データ分類チェック
        -> ジョブキュー
           -> Omni adapter
              -> Interactions API
           -> 出力取得・検証
           -> 素材台帳
           -> 人間レビュー
           -> 公開ストレージ

重要な点は、利用者からモデルAPIを直接呼ばせないことである。入力素材の権利、地域、サイズ、禁止対象を受付時に検証する。

モデルアダプターには次を集約する。

  • モデル名
  • API設定
  • Interaction履歴
  • 再試行
  • エラー分類
  • メトリクス
  • 将来のモデル切り替え

導入段階

第1段階: 閉じた検証

公開予定のない素材で、品質、失敗、遅延、保存方式を確認する。実在人物や顧客素材は使わない。

第2段階: 社内制作

社内プレゼン、モック、アイデア検討など低リスク用途へ限定する。生成物には明確なラベルを付ける。

第3段階: 人間承認付き外部公開

法務、ブランド、制作担当の承認を必須にする。自動公開は行わない。

第4段階: 限定自動化

定型、低リスク、権利確認済みの用途だけを自動化する。却下率や苦情率が基準を超えた場合に停止する。

プレビュー期間中に、無人での大量外部公開を前提とするべきではない。

よくある誤判断

最終Promptだけ保存する

会話型編集では、前のターンと生成状態が必要である。全履歴を保存する。

SynthIDがあれば監査できる

生成AI由来の検証には有用だが、素材権利、生成者、指示、承認は別途管理する。

APIが成功したので動画も保存できた

URI取得、ファイル検証、永続保存まで完了を確認する。

1本の成功例で品質を判断する

再生成率、編集ターン数、却下率を多数の代表案件で測る。

プレビューを本番SLAへ直接組み込む

仕様変更、容量、地域制限、非対応機能を考慮したフォールバックが必要である。

プロンプトで禁止事項を書けば安全

system instructionやnegative prompt専用設定が使えない制約がある。入力チェック、権限、人間承認を外部制御として設ける。

編集部分析

Gemini Omni Flashの重要性は、動画生成速度だけではない。制作物を会話の状態として編集できる点にある。

これまでの生成動画は、毎回プロンプトを書き直して新しい候補を作る工程になりやすかった。状態を引き継ぐ編集では、採用した構図や人物を維持しながら差分指示を重ねられる。これが安定すれば、AIは「動画を作る機能」から「制作セッションを管理する機能」へ変わる。

同時に、制作資産の単位も変わる。完成MP4だけではなく、入力素材、Interactionグラフ、各ターンの出力、レビュー、公開版を一つの系列として管理する必要がある。

企業にとって本当の評価指標は、生成1回当たりの料金ではない。承認される素材を1件得るまでに要した、API費用、待ち時間、再生成、人手修正、法務確認を合算した総コストである。

また、SynthIDの標準付与は生成物の透明性を高めるが、社内の説明責任を外部ウォーターマークへ委ねる理由にはならない。生成の来歴と公開判断を自社側で保持する組織ほど、将来のモデル変更や規制強化へ対応しやすい。

プレビュー段階で優先すべきなのは、大量生成の自動化ではなく、失敗を観測できる制作基盤を作ることである。

実務チェックリスト

  • [ ] gemini-omni-flash-previewを本番安定版と区別している
  • [ ] 入力素材の著作権、肖像、音声、商標を確認している
  • [ ] 地域、未成年者、実在人物の制限を確認している
  • [ ] Interaction IDと親子関係を保存している
  • [ ] 各ターンのPrompt、入力、出力を保存している
  • [ ] store=falseと再編集不可の関係を理解している
  • [ ] 生成動画を自社ストレージへ取得している
  • [ ] ファイルサイズ、長さ、解像度、ハッシュを検証している
  • [ ] 重複生成を防ぐ冪等キーがある
  • [ ] 非同期状態と再試行を分けている
  • [ ] Provisioned Throughput非対応をSLAへ反映した
  • [ ] SynthIDとは別に社内来歴を記録している
  • [ ] 人間による法務・ブランド・品質承認がある
  • [ ] 初回採用率、再生成率、編集ターン数を測定している
  • [ ] 承認済み素材1件当たりの総費用を計測している
  • [ ] 代替モデルまたは人手制作へのフォールバックがある

一次情報