ここから先を読まない人向けの短いまとめ。 Gemini Omni 1.1 FlashはGoogleのオールインワン動画モデルだ。テキスト、画像、またはクリップを入力すると、音声付きの動画が出力される。バージョン1.1（2026年8月27日）では、実作業に不可欠な2つの機能、40秒までのシーン延長と1080p/4K出力が追加された。現在Popcraftで利用できる。1日使ってみて、最も役に立った発見は、5秒のクリップから「20秒に延長」すると25秒になるということだった。
| Googleの発表 | 実測結果 | |
|---|---|---|
| 最長クリップ | シーン延長で40秒、10秒刻み | 1つのプロンプトで40.0秒、実時間23分 |
| 延長 | 「最大10秒の事前コンテキストを分析」 | 5秒ソース → 25.0秒ファイル、オリジナルはフレーム単位で保持 |
| 解像度 | 360pから4K、「プロフェッショナル制作に対応」 | 1080pトレーラー、720pテスト。4Kのチェーンは30秒で停止 |
| 音声 | 映像に合わせたセリフ、音楽、効果音 | トレーラーにはオーケストラスコア、延長部分には嵐の環境音 |
| 物理 | 「重力、運動エネルギー、流体力学などの力を直感的に理解」 | 3つの流体が正しく振る舞う30秒の水中インク作品（下記） |
| カメラ | パートナーのコメント：「ダイナミックなカメラモーション」 | ドローンとオービットは毎回成功。ウィップパン、クレーン、ドリーズームは柔らかくなる |
水曜日、10:41。いよいよ開始だ。
Batch AIは前日の夜、テストゲートウェイでこのモデルを有効にした。まずは先方から伝えられた2つの事実から。この2つがモデルの使い方を左右するからだ。解像度の文字列は「4K」で、実際に3840×2160が返ってくること。そしてextensionはプロンプト上の小細工ではなく、APIレベルの正式なモードであること。以下はすべて、こちらがボタンを押して確かめた結果だ。
最初のタスクはあえて退屈なものにした。螺旋階段の灯台守、縦向き、5秒、720p。約2分で5.01秒の動画が返ってきたが、誰も頼んでいない風と雨の音声がトラックに入っていた。これがOmniのデフォルトだ。Googleの開発者ガイドには「モデルは動画に適した音声トラックを生成しようとします」と書かれており、こちらから指示しない限り毎回そうなる。
11:20。頼んだより5秒長かった延長
ここがこの記事を読む価値を生んでいる部分だ。5秒のクリップを添付し、「灯台守がランプギャラリーに出てランプに火を灯す」と1行だけ書いて、合計20秒を指定した。
返ってきたファイルは25.0秒の長さだった。
バグではない。Googleのローンチ記事には「10秒単位で最大累計40秒まで動画を延長できます」と書かれており、これは丸ごとの単位を意味している。5秒に10秒、さらに10秒だ。新ファイルの最初の5秒は元の動画がバイト単位でそのまま残っており、嵐の音声も継ぎ目を越えてそのまま続いている。仕上がりは素晴らしい。ただ20秒ではないだけだ。
そこで、このモデルを使って構築するすべての人へのルール、そしてPopcraftの延長パネルが5秒のソースに対してきりの良い10/20/30/40ではなく15、25、35を表示する理由：着地できるのは、ソースに丸ごとの区切りを足した長さだけだ。課金対象は、入力した数値ではなく返ってきた秒数だ。
「10秒単位で最大累計40秒まで動画を延長できます。」— Google、Omni 1.1 Flashローンチ記事
12:05. 40秒、1つのプロンプト
そして実際にやりたかったこと：ハリウッド風トレーラー「Pirates of the Cranberries」、16:9、1080p、40秒、リクエストは1回だけ。Popcraftが延長処理を自動でチェーンしてくれる。プロンプト1つで、40秒のファイルが1つ出力される。
23分かかった。こちらの推定では15分だったので、調整が必要だ。結果はちょうど40.0秒、1920×1080で、おおむね適切な場面で盛り上がるオーケストラスコア付き。同じ船長、同じ船、4つの区切りすべてにわたって同じティールとアンバーのカラーグレーディング。この一貫性こそ、ローンチ記事で言及された10秒のコンテキストウィンドウが機能している証拠であり、このモデルの最も強力な売りだ。
何がうまくいかなかったのか、そしてなぜそれがこちらの落ち度だったのか。プロンプトは240語の密な段落で、5つのビートを詰め込んでいた。嵐、船長、クランベリー満載の宝箱、ライバル船、大砲のフィナーレ。Omniはすべての要素を保持しつつ、順序を入れ替えた。クランベリーの飛沫は、それを放出するはずの宝箱より先に8秒目で現れ、宝箱がはっきり開くことは最後までない。密なプロンプトはこのモデルでは失敗しない。圧縮されるのだ。
15:10。よし、物理演算の主張をちゃんと検証しよう
トレーラーは物理演算のテストとしては不適切だ。同時に多くのことが起きすぎていて、クランベリーが正しく跳ねたかどうか誰も判断できない。そこで私たちはその日で最も地味なプロンプトを書いた。静かな水を湛えた黒い水槽。10秒の区切りごとに1つの流体表現。オレンジの水滴が落ち、インディゴのインクが広がり、そして背後から照らされた白い顔料の雲。人物なし、ストーリーなし、ゆっくりとしたカメラのアーク1つ、1080pで30秒、1つのリクエスト。
これはこの日モデルが生成したものの中で最高の出来だ。水滴が着水し、クラウンスプラッシュが上がって水本来の動きで崩れ落ちる。インディゴのインクの煙がその後ろから巻き上がり、先に落ちたオレンジのインクの中へ折り込まれていくが、どちらの色もぼやけて滲むことはない。白い雲が現れるとバックライトがその中を通って散乱し、それまでの流体はまだ下層に残って動き続けている。カメラのアークは3つの区切りすべてを通して維持され、リセットされることはない。10秒と20秒の継ぎ目を見てほしい。見つけられない。
まず安価なドラフトから。これがおすすめするワークフローだからだ。10秒720pの4つのバリエーション（インク、ハチミツ、ドミノ、ニュートンのゆりかご）はそれぞれ約2分かかった。インクとゆりかごは良かったが、ハチミツは少し動きすぎで、ドミノは正しい順に倒れたが重みがなかった。インクが勝ち、30秒版を書き出したところ、30秒版はドラフトより良い出来だった。トレーラーの場合はそうではなく、長さが伸びた分ストーリーの圧縮が強まった。圧縮すべきストーリーがなければ、延長は純粋にプラスでしかない。
この証拠を見る限り、流体力学に関するGoogleの一文はマーケティング文句ではない。
16:40。そしてカメラの主張
Googleのローンチ資料で繰り返し目にしたもう1つの主張は、カメラに関するものだった。モデルページのパートナー引用では「ダイナミックなカメラモーション」が称賛されており、Vertexのプロンプトガイドにはモデルに教え込まれた語彙がリストアップされている。drone、dolly、pan、tilt、tracking、crane、orbit、whip pan、そして「dolly zoom」は上級者向けで公式にはサポートされていないとされている。
そこで私たちは、朝と同じ灯台を舞台にした30秒の1ショットで、プロンプトのビートごとに1つの動きを指定し、それらすべてをリクエストした。
プロンプトに対して、動きごとに採点した結果：
- ドローンアプローチ。 成功。波頭を掠め、玄武岩を登り、指定した秒数ちょうどでランタンに到着。この日モデルが見せてくれた最高の10秒間のカメラワーク。
- オービット。 成功。最後の10秒で灯台守の背後から回り込み、横顔を経て遠側のワイドショットへ。灯台は最後まで同じ灯台のまま。
- ボートへのウィップパン。 失敗。ボートは水平線上に小さく写ってはいるが、カメラは素早く振り切るのではなく、ゆっくり流れるようにそこへ寄っていく。速い動きをモデルが緩やかな動きに均してしまった。
- ランタン上方へのクレーンアップ。 半分。上昇が起きたのは要求していない1つ目の区切りで、要求した2つ目の区切りでは起きなかった。
- ローアングルのプッシュインとラックフォーカス。 失敗。代わりにワイドショットで終わった。
- ドリーズーム。 わざと30秒プロンプトから外した。以前の10秒テストでは通常のプッシュインとして返ってきており、Google自身のガイドでも「公式にはサポートされていない」に分類されているので、これは妥当。
頼んでもいないものが2つ。1つ目と2つ目の区切りの間で、カメラはランタンのガラスを突き抜けて中の灯台守を捉え、そのまま彼女についてドアからランプギャラリーへと出ていく。ファイル内にはカットが一切存在しない（シーン検出器にかけて確認済み）ので、モデルはドローンの位置から彼女の位置へ移動するためのトランジションを自力で発明したわけだ。これはなかなか良い発明である。あまり良くない点：ランタンの内側では髪をアップにしているのに、数秒後のランプギャラリーでは髪を下ろしている。Googleのモデルカードには「編集全体の一貫性」と「複雑なモーション」が既知の制限として挙げられているが、まさにこれがそれだ。
10秒テストと30秒テストの両方を通じて見えたパターンは、ゆっくりとした大きな動き（ドローン、オービット、アーク、ドリー）は信頼できるが、速い動きや光学的な動き（ウィップパン、ドリーズーム）はより穏やかなものに丸められてしまうということだ。ショットにキレが必要な場合は、それだけを短いクリップとして生成し、編集でつなぎ合わせよう。
プロンプトの教訓はトレーラーと同じだ。Google独自のガイドの語彙を使い、ビートごとに1つずつ動きを指定すれば、遅い動きも時間通りに実行される。「sweeping」や「dynamic」といった感覚を説明すると、どちらにせよゆっくりとしたプッシュインになる。
Omni Flash 1.0から実際に何が変わったのか？
Googleのモデルページでは両バージョンに同じ機能表を使っているため、差分は異例なほど正直だ：
| 機能 | Omni Flash（2026年5月） | Omni 1.1 Flash（2026年8月） |
|---|---|---|
| テキストから動画 | 対応 | 対応 |
| 画像から動画 | 非対応 | 対応 |
| 参照画像 / 動画 | 非対応 | 画像最大10枚、動画3本 |
| 最初と最後のフレーム | 非対応 | 対応 |
| 動画編集 | 対応 | 対応 |
| 動画の延長 | 非対応 | 対応、最大40秒 |
| 出力解像度 | 720pのみ | 360p、720p、1080p、4K |
| サウンド生成 | 音声、音楽、効果音 | 音声、音楽、効果音 |
| 出所証明 | SynthID、C2PA | SynthID、C2PA |
元の「Introducing Gemini Omni」投稿にあった物理法則と世界知識に関する主張（「重力、運動エネルギー、流体力学といった力に対する直感的理解の向上」）はそのまま引き継がれており、意図的にその点を戻ってテストしてみた。結果は下記のとおりだ。ただしGoogleが最も前面に打ち出しているのは記憶力だ：「すべての指示が前の指示の上に積み重なる。キャラクターは一貫性を保ち、物理法則は破綻せず、シーンはそれまでに起きたことを覚えている。」トレーラーを見た後、この文の後半については予想以上に納得できた。
モード切り替えなしでどうやって指示を出すのか？
出さない、というのが答えで、これに慣れるには少し時間がかかる。Googleのガイドはこう言っている：「主にプロンプトに頼り、プロンプトでうまくいかない場合にのみtaskパラメータを使うことを推奨します。」何を添付し、何を書くか。それ自体がスイッチだ。
- 何も添付しない：テキストから動画。
- 画像1枚：それが最初のフレームになる。
- 画像2枚に「first frame」「last frame」という言葉を添える：2枚の間の補間。これらの言葉がない場合、2枚の画像は被写体参照として扱われる。
- 画像最大10枚：被写体参照。人物やオブジェクトの一貫性が保たれる。
- 動画に「make it snow」を添える：ショット、長さ、フレーミングを維持した編集。
- 動画に「extend this video」を添える：シーンの延長。
最後の2つはユーザーが引っかかりやすいポイントだ。クリップを添付してextendという単語を使わずに続きを記述すると、モデルはそれを編集として扱い、同じ長さで返す。Popcraftでは動画延長パネルでキーワードが自動で追加されるが、APIやMCPからは自分で記述する必要がある。
初めての40秒レンダリングの前に同僚に伝えておきたいこと
Tipsリストではない。3つのこと、問題になりやすい順に。
1区切りにつき1つのアクション。 Googleのガイドにはタイムコード構文が記載されており、10秒の区切りに完璧に対応している。これが私たちが送るべきだったトレーラーのプロンプトだ：
夕暮れの嵐の中をゆく海賊ガレオン船、骸骨の旗、破れた黒い帆。単一の連続ショット、シーンカットなし。 [0-10s] 船は波を突き破って進む。カメラは甲板へと上昇。 [10-20s] 髭面の船長が舵輪の傍らで命令を叫ぶ。乗組員が吼え返す。 [20-30s] 船首の鉄の宝箱を開けると、赤いクランベリーが溢れ出る。 [30-40s] 敵船が発砲。彼がカットラスを振り上げる中、クランベリーがスローモーションで飛び散る。 ルック：アナモルフィックフレア、ティール＆アンバーのカラーグレーディング、オーケストラスコア、画面上のテキストなし。
聞きたいものを指定する。無音も含めて。 無音も1つのリクエストだ。「セリフなし」「音楽なし、風と水の音のみ」はガイド自身が示すシンプルな否定形の例であり、効果がある。プロンプトで音に触れないことは、無音を指定することと同じではない。
編集は物足りないくらい少ない言葉で。 Googleから直接のアドバイス：「動画編集にはシンプルなプロンプトが最も効果的です。過度に説明的なプロンプトは意図しない変更を引き起こす可能性があります。」変更内容を指定し、「他はすべてそのままにして」と付け加えたら、そこで入力をやめる。
Seedance 2.5やVeo 3.1との立ち位置
複数の動画モデルを提供しているのは、どのモデルもあらゆるショットで勝てるわけではないからだ。Omniの強みは、1つのリクエストで最大40秒、最大4Kの長いクリップを独自のサウンド付きで生成できることだ。Seedance 2.5ははるかに多くの参照（画像30枚、動画10本）を受け取り、領域単位の精密な編集ができる。Veo 3.1は8秒で厳密なフレーム制御を提供する。目玉となるクリップ1本と劇伴で完結する案件なら、Omniから始めよう。12ショットにわたって同一に見えなければならない製品を扱う案件なら、Seedanceから始めよう。
Popcraftの料金は解像度別に、納品された秒数に対して課金される。720pはドラフト用、1080pは納品用、4Kは目玉カット用で、チェーンは30秒が上限だ。長さはスライダーで3秒から40秒まで自由に選べる。延長のチェーンはPopcraftが裏側で自動的につなぎ、スライダーにはモデルが到達できる長さしか並ばない。そして生成前に表示される数字が、そのまま支払う数字だ。
自分で使って限界を試そう
Gemini Omni 1.1 Flashは動画ジェネレーター、Canvasボード、MCPコネクターですでに使える。100クレジット付きで無料、カード登録も不要だ。こちらがやったのと同じようにやってみてほしい。まず720pで10秒生成して判断し、それから延長する。あるいは、すでに気に入っているクリップを持ち込んで、それを延長する。トレーラーと延長版はモデルページに、未編集で音声もそのまま置いてある。30秒のテスト2本は、先ほど見てもらったものだ。
出典：Googleの「Introducing Gemini Omni」および「Gemini Omni 1.1 Flash lets you build with more control」投稿、Google DeepMindのGemini Omni Flashモデルカード、Gemini Enterprise Agent PlatformのOmni FlashおよびOmni 1.1 Flashモデルページ、Gemini API開発者ガイド。測定値は当社によるもので、2026年9月3日時点。
