Geminiの新しい動画解析は、質問に応じて見る場所を選ぶ

2時間の講義の録画から、ある用語を説明している場面だけを探したい。人が最初から見直すと時間がかかるので、動画と質問をAIへ渡して、該当する時刻を答えてもらう機能を作りたくなる。

Googleは2026年9月1日、質問に合わせて動画の必要な箇所を調べるagentic video understandingを発表した。動画のどこを見るかを質問に応じて決めるため、長い録画から特定の場面を探す用途で試しやすい。 従来の方式と何が違い、どこで差が出るのかを、講義の録画を探す例で見ていく。Googleの発表

staticは等間隔で見て、agenticは質問に応じて調べる

公式ガイドの既定はstaticという方式で、標準では1 FPS、つまり1秒につき1枚の画像を抽出して取り込む。公式ガイドの処理方式

この方式では、取り込む量が質問ではなく動画の長さで決まる。2時間の講義なら7200秒あるので、1秒に1枚なら7200枚分を取り込む計算になる。探しているのが1か所の説明であっても、動画全体を等間隔に見ていくことになる。

agenticでは、モデルが質問をもとに動画内を調べ、読む範囲や画像の細かさを変える。講義の録画で、ある用語を説明した場面を探す場合なら、次のように進む。用語が口にされた場所は、音声や文字起こしをたどれば絞り込める。候補が見つかったら、その前後で図を出しているかを映像で確かめる。必要な情報に応じて映像、音声、文字起こしを調べるのが、今回の方式だ。関係のない90分を1枚ずつ見る必要はない。これは使い方を説明する例で、手元の録画で精度を検証した結果ではない。

帯は動画の先頭から末尾までを表す。staticの細い線は取り込む位置、agenticの濃い部分は質問に応じて調べた場所にあたる。方式の違いは公式ガイドの「Agentic video understanding」による模式図で、実際に調べた箇所の数や幅を測ったものではない。

差が出るのは、質問が動画の一部だけを指している場合だ。逆に、動画のすべての場面を確認したい仕事では、見る場所を選ぶこと自体が取りこぼしにつながりうる。会議の録画から特定の発言を探すのと、映像に不適切な場面が混ざっていないかを最初から最後まで点検するのとでは、向いている方式が変わる。公式ガイドが挙げる目安を、作りたい機能ごとに整理した。

作りたい機能	最初の比較候補	実際の動画で確かめること
長い講義から特定の説明を探す	agentic	回答した時刻に目的の説明があるか
短い動画への回答を早く返す	static	必要な内容を答え、待ち時間に収まるか
短い動画の全場面を細かく調べる	staticも比較する	抜かしてはいけない場面を拾えるか

方式の目安は公式ガイドの「Choose a processing mode」、右列は確認項目としての提案だ。

真ん中の行が意外に見えるかもしれない。動画が短ければ、全体を等間隔で取り込んでも量は多くない。そこへ、どこを見るかを決める工程が加われば、その手間のほうが上回ることもありうる。ガイドは理由まで書いていないので、これは方式の説明からの推測になるが、短い動画で待ち時間を重視するならstaticも候補に残る、という目安と整合する。

削減率より先に、正しい場面を返したかを見る

Googleは評価課題で、トークンの消費を最大88%、費用を最大66%減らしたと報告している。トークンはモデルが処理する情報量を数える単位で、消費量の削減率と料金の削減率は別の指標だ。いずれも発表元の評価における最大値になる。発表の「Benchmarks」

この数字が自分の動画でもそのまま出るとは限らない。削減が生まれるのは、質問に関係のない場面を細かく見ずに済むからだ。だとすれば、削減の幅は質問がどれだけ絞り込めるかで変わる。特定の用語を説明した場面を探す質問なら、調べる範囲は狭くなる。講義全体を要約してほしいという質問なら、結局は広く見ることになる。これは仕組みからの見立てで、Googleが条件別の内訳を示しているわけではない。

そして、録画検索を作るなら、費用の差を調べる前に確かめたいことがある。安く回答できても、同じ用語が出てくる別の場面を返していたら、利用者は結局探し直すことになるからだ。講義の中で用語が3回出てきて、図で説明しているのが2回目だけ、という状況は珍しくない。返ってきた時刻を再生し、その前後が質問した説明になっているかまで見ると、判断しやすい。

時刻が合っていても内容を取り違えることはある。時刻の一致だけを合格にせず、質問への答えになっているかを先に判定したい。そのうえで使用量と回答までの時間を比べれば、削減率が自分の動画でも成り立つかを確かめられる。

使えるモデルと、比べるときに揃える条件

2026年9月5日に確認したガイドでは、agenticに対応するのはGemini 3.8 Flash、3.7 Flash、3.6 Flash、3.5 Flash-Liteだ。対応モデルでも既定の動画処理はstaticなので、使うには処理方式の指定が要る。動画ガイドの対応モデル表 Interactions APIでは動画入力の processing に agentic を指定し、応答の interaction.steps に processing_call と processing_result があるかで、その方式が使われたことを確認できる。公式ガイドの設定と応答

既定がstaticのままである点は、比較のときに効いてくる。対応モデルへ切り替えただけでは動画の処理方式は変わらないので、指定を忘れると両方の実行がstaticになり、差が出ないという結果だけが残る。応答の interaction.steps を確認するのは、そのための手順でもある。

提供時期は、9月1日のAPI更新履歴に3.7 Flashなどへの提供、翌2日に3.8 Flashの一般提供が記載されている。Gemini APIの更新履歴 いずれもAPIの話で、発表ではAPIでの提供とGeminiアプリへの今後の展開が分けて書かれている。普段使うアプリで動画を添付したときに同じ方式になったとは、この発表からは判断できない。発表の「Getting started」

比べるときは、方式以外の条件を揃える。人が答えの場面を知っている動画を1本用意し、探したい説明と正解の時刻を先に決める。同じモデル、同じ動画、同じ質問でstaticとagenticを実行し、回答の時刻と内容を照合してから、使用量と所要時間を見る。

正解を先に決めておくのは、答え合わせをする人が回答に引きずられないようにするためだ。回答を見てから「この場面でも間違いではない」と判断すると、方式の差が見えなくなる。質問の文面も揃える。同じ動画でも、質問を変えれば調べる範囲が変わるので、方式の比較にならない。

使う側から見ると、この区別は問い合わせの受け方にも関わる。社内でGeminiアプリに動画を添付している人がいても、その動作が今回の方式かどうかは分からない。自分が作る機能で試すなら、APIで方式を指定して確かめることになる。

今回、APIは実行していない。日本語の録画での精度、待ち時間、請求額は未確認だ。長い録画から特定の場面を探す機能を作るなら、まず答えの分かっている動画で両方式を試し、利用者が探し直さずに済むかを確かめるところから始めたい。動画のどこを見るかを質問に応じて決める方式が効くのは、質問が動画の一部を指しているときだ。自分が作る機能の質問がその形になっているかが、最初の判断材料になる。

まとめ

• staticは動画の長さに応じて等間隔に取り込み、agenticは質問に応じて見る場所と細かさを変える。差が出るのは、質問が動画の一部を指している場合。
• Googleが示した最大88%のトークン削減と最大66%の費用削減は、発表元の評価における最大値。まず回答した時刻と内容が質問の答えになっているかを確かめる。
• 対応モデルでも既定の処理はstatic。比較するときはモデル・動画・質問を揃え、方式の指定と応答の interaction.steps を確認する。