従来の動画理解が高コストで見逃しが多かった理由

静的処理のロジックは非常に単純です。開発者が先に固定のフレーム抽出レートを決め、システムがそのレートで動画全体を処理します。Gemini のデフォルトの静的な設定は 1 FPS、つまり1秒間に一コマを抽出するもので、開発者は API を通じてこの値を調整できます。

固定フレームレートの問題は、それが常に間違っているということではなく、動画のすべての部分を同じ密度で扱うという点にあります。90分の発表会の場合、1 FPS では5,400のサンプル画像になります。より速い動きを捉えるためにサンプリングレートを 5 FPS に上げると、27,000もの画像になります。実際のトークン数は解像度やエンコード方式にも影響されるため、単純にフレーム数をトークン数に換算することはできませんが、フレーム数の増加がコンテキスト量とコストに与える負荷は現実のものです。

また、1 FPS は完全な視聴ではありません。仮にボタンが「オフ」から「オン」に変わるのが0.3秒間だけだった場合、この変化が二回のサンプリングの間に完全に収まってしまう可能性があります。モデルはその画像を見ていないため、たとえその後の推論能力が高くても、コンテキストに入ったことのない視覚的な事実を復元することはできません。

そこで開発者は、次の二つのリスクのどちらかを選択せざるを得ません。

• FPS を上げる：短時間の動作を見逃しにくくなる一方で、動画全体に対して、ごく一部の重要な瞬間のために高いコストを支払うことになります。
• FPS を下げる：コストは抑えられますが、カットの切り替わり、高速な動き、点滅する異常、短時間だけ表示される物体などを捉え損ねる可能性があります。

静的なモードにも依然として価値はあります。数分以内の動画や、低遅延が重視されるタスク、あるいは全編にわたって同一のサンプリングルールを適用しなければならないタスクでは、このモードの方がシンプルで予測しやすいからです。エージェントモードが解決するのは別種の問題です。動画が非常に長く、その答えがごく一部の断片にのみ依存するような場合に、モデル自身が観察のためのリソースをどこに割り当てるかを決定する必要があるのです。

Gemini が自身で視聴箇所を決定する仕組み

Google が公開した仕組みの図では、モデルは「思考」と「観察」を繰り返しています。モデルは、まず動画全体を完全に展開してから回答を始めるのではありません。推論の過程で、字幕の読み取り、指定した時間帯の音声の読み取り、指定した開始・終了時間とFPSでの画像取得という、三種類の内部ツールを呼び出すことができます。

このループを分解すると、おおよそ次の五つのステップとして理解できます。

1. 問題に答えるために必要な証拠を理解する。「発表者が何を発表したか」と「人物が何回ジャンプしたか」では、必要となる情報が異なります。
2. コストの低い手がかりを使って範囲を絞り込む。字幕がある場合は、キーワードやタイムスタンプを検索できます。口調や環境音を確認する必要がある場合にのみ、音声を読み取ります。
3. 具体的な時間枠を選択する。数十分から数時間の動画を、可能性のある少数の断片に絞り込みます。動画全体にわたって高密度なサンプリングを維持するわけではありません。
4. タスクに応じてモダリティとフレームレートを選択する。言語に関する質問は主に字幕に依存するかもしれません。カットの切り替わり、状態変化、動作のカウントには映像が必要であり、局所的に FPS を上げる可能性があります。
5. 証拠が不十分な場合は見直す。モデルは新しい観察結果を得た後も推論を続け、必要に応じて時間枠を変えたり、モダリティを変更したり、サンプリングレートを上げたりして、回答をまとめます。

この同じ仕組みによって、コスト削減と精度向上の両方が同時に実現されます。無関係な時間帯を見る量が減ればトークンは減少し、映像に対する割り当てを重要な時間枠に集中させれば、短時間の細部も捉えやすくなります。この二つの利点は、どちらも同じ観察配分のループから生まれます。

ここで誤解されやすい点があります。エージェントモードは「動画を劣化なく全て見る」という意味ではありません。このモードも依然として選択、サンプリング、範囲の絞り込みを行うため、選択を誤ると時間枠を外して情報を取りこぼす可能性があります。その利点は、開発者が事前に指定した単一の FPS に全てを委ねるのではなく、モデルが問題に応じて観察戦略を動的に修正できる点にあります。

三つの動画デモがそれぞれ示すもの

Google は発表ページに、三つの比較デモを掲載しています。これらは独立した三つの機能ではなく、「長尺動画のコスト」「高速な動き」「長尺動画の検索」という、三つの異なる観察配分の課題をそれぞれ示しています。

1. LongVideoBench：同じ長尺動画のタスクで、見るコマ数を大幅に削減

最初のデモでは、Gemini 3.7 Flash が静的モードとエージェントモードで LongVideoBench を処理する際の違いを比較しています。ここで注目すべきは、「モデルが動画をスキップした」という点ではなく、一様なサンプリングを、問題に基づいた対象を絞った調査へと変更した点です。つまり、関連性のありそうな断片をまず特定し、それからその断片に観察リソースを投入しています。

LongVideoBench 自体が、長時間にわたるマルチモーダルな動画コンテンツの処理をモデルに要求するため、長いコンテキスト内でイベントの順序、オブジェクト間の関係、問題の手がかりを維持できるかどうかを検証するのに適しています。Google のデモでは、エージェントモードでは入力トークンが明らかに少なく、かつ回答品質が高いことが強調されています。

2. ジャンプの回数カウント：必要な時に FPS を上げて再確認

二つ目のデモでは、高速で繰り返されるジャンプ動作を Gemini がカウントします。固定の 1 FPS では、一回の完全な動作の開始点と終了点が同じサンプリング間隔に押し込まれ、カウント漏れや、半端な動作を一回と数えてしまう可能性が高くなります。

エージェントモードでは、まず動作が発生している断片を特定し、その後、異なる FPS でスキャンして再確認します。この例は、「動的 FPS」が真に価値を発揮する場面を示しています。動画全体で常に高いフレームレートを維持するのではなく、数秒間の重要な時間枠に限って一時的に観察密度を高めるのです。

3. 干し草の山から針を探す：まず位置を特定し、それから複雑な質問に答える

三つ目のデモでは、長尺動画に関する複雑な質問に答える際の、二つのモードのトークン消費量を比較しています。エージェントモードでは、まず字幕、音声、または低密度の映像を使って手がかりを探し、その後、コストの高い視覚的な読み取りを、可能性のある少数の候補時間帯に集中させることができます。

この方法は、発表会、講義、会議の記録、スポーツの映像、数時間に及ぶマテリアルライブラリなどに特に適しています。これらの場合、質問が関係するのは、たいてい特定の一つのイベント、一つの発言、または短時間だけ現れる物体だけであり、すべての映像を同じ密度でコンテキストに入れる必要はありません。

三つの実測データの読み方

Google が示した三つのデータ群は Gemini 3.7 Flash によるもので、静的な 1 FPS とエージェントモードを比較しています。テストはすべて、高い thinking level と低いメディア解像度で統一されています。ベンチマークごとに利得の差が大きいため、「最大88%削減」という数字だけを見ると、最も重要な情報を見落とします。つまり、タスクの構造によって、エージェントによる観察がどれだけの削減と精度向上をもたらすかが決まるということです。

この表からは、次の三つの結論が読み取れます。

• トークン削減率が最も高いからといって、精度の向上が最も大きいわけではない。1H-VideoQA と LVBench はどちらも88%の削減ですが、相対的な精度向上はそれぞれ1.1%と4.1%に留まります。
• MINERVA は削減率が低いものの、品質向上は最大。この種の複雑な推論タスクには、より多くの有効な観察が必要です。エージェントモードは、単に視聴量を減らすことだけを追求するのではなく、十分な証拠を確保する必要があります。
• 「最大7%」という数字は、相対的な向上を示す値。図では MINERVA が73.7%から79.0%に上昇しており、絶対的な向上は5.3ポイント、相対的な向上は約7.2%です。この二つの指標を混同してはなりません。

Google はまた、これらのテスト全体で分析コストを最大66%削減できると報告しています。コスト削減率がトークン削減率に直接一致しないのは、異なるモダリティ、推論プロセス、ツール呼び出しが最終的な請求額に影響するためです。

「パレート最前線」とは、このテストされたモデルのグループ内で、コストを増やさずに高い精度を達成する、または精度を下げずにさらにコストを削減する、他の方法が見つからない状態を指します。これは特定のテスト群における相対的な位置を示すものであり、動画理解市場全体における永続的なランキングを意味するものではありません。

初期パートナー企業の実際の活用事例

Google はまた、四社の初期パートナー企業による報告も紹介しています。これらのデータはベンダーによる事例であり、独立したベンチマークではありませんが、ラボでの評価ではカバーされていないワークロードを補完するものです。

• Ponder は Gemini を使用して、ソース資料から利用可能なクリップを探します。同社によれば、同等の再現率を維持しつつ、新しい単一呼び出しで使用する入力トークンは約3.5倍少なくなったとのことです。
• Revyl はクラウド上のデバイスを使用して iOS および Android アプリをテストしています。同社が注目しているのは、スクリーンショットによる検証では見逃されがちな、高速なアニメーションや状態変化です。
• Resemble AI は、約1,000本のラベル付き動画とリアルタイムのディープフェイク検出ワークロードでテストし、入力トークンが57%削減され、長尺動画の説明とコンテキストの精度が向上したと報告しています。
• Mosaic は、プロダクション向け動画編集の評価において、入力トークンが中央値で97%削減され、制約のカバレッジがほぼ二倍になったと報告しており、エージェントモードが4.5時間のポッドキャスト事例を完了できた唯一のモードであると述べています。

これらの結果は、企業が実際に価値を見出しているのは「動画の理解」そのものではなく、従来はエンジニアリングチームが手作業で書いていた検索、セグメンテーション、リサンプリング、再確認といったプロセスを、一回のモデルとのやり取りに圧縮できる点にあることを示しています。ただし、これらのパートナー企業による数値には、公開された統一されたテストプロトコルがなく、上記の標準的なベンチマークと直接比較することはできません。

最適なユースケース

サブ秒単位の瞬間の検索

動画のラフカット、カット点の検出、インターフェースの状態変化は、1秒未満で発生することがあります。エージェントモードでは、まずおおよその時間範囲を特定し、次にその時間枠の FPS を上げることで、より正確なカット点に絞り込むことができます。これにより自動編集の実現性は高まりますが、公式には動画の種類を横断したフレームレベルの誤差分布は公表されていないため、これを普遍的な「産業レベルの精度」と表現することはできません。

長尺動画からの特定情報の検索

90分の講義、会議、または数時間に及ぶ録画において、モデルはまず字幕や音声の手がかりを使って検索し、その後、近辺の映像を確認することができます。このモードは、「特定の発言がいつされたか」「特定の物体がいつ出現したか」「どの部分が特定の機能を示しているか」といった、ポイントを絞った質問に最も適しています。

異常検知

監視カメラや品質検査の映像における異常は、通常数秒しか続きません。モデルはまず低コストで全体をスキャンし、怪しい時間帯だけ再サンプリングすることで、素早い動きや点滅、映像のノイズを捉えることができます。ただし、これはセキュリティシステムに求められる「見逃しゼロ」の保証にはなりません。リスクの高い現場では、専用の検出器、明確なしきい値、そして人手による再確認が今も必要です。

動作・物体のカウント

エクササイズの回数や、工場ラインのワーク数、スポーツの動作などには、明確な反復構造があります。固定の1 FPSでは見逃していた中間の状態も、局所的にFPSを上げることで補えます。さらに、再生して見直すことで、カウントの境界を確認できます。ただし、動作の定義が曖昧だったり、遮蔽が激しかったり、複数の対象が交錯する場合は、カウントを誤る可能性が残ります。

動画コンテンツの制作・素材管理

編集チームにとって、より具体的な価値は、「何十時間もの素材の中から使えるカットを三つ見つける」という作業を、自然言語での検索に置き換えられることでしょう。モデルがまず候補のクリップを絞り込み、それを編集者が確認するという流れは、モデルに最終編集まで任せるよりも現実的で、信頼性の高いレビュー工程を築きやすくなります。

開発者の呼び出し方

この機能は、Gemini API を通じて Google AI Studio と Gemini Enterprise Agent Platform に提供されており、動画の直接アップロードと YouTube 動画に対応しています。現在、Gemini 3.7 Flash、3.6 Flash、3.5 Flash-Lite をサポートしており、料金は標準の Gemini トークン価格に基づき、追加の機能料金は発生しません。

呼び出し時の重要な変更点は、動画入力に "processing": "agentic" を追加することです。

from google import genai

client = genai.Client()

interaction = client.interactions.create(
    model="gemini-3.7-flash",
    input=[
        {
            "type": "video",
            "uri": "https://youtu.be/7Z5Vy9JBANs",
            "processing": "agentic",
        },
        {
            "type": "text",
            "text": "What are the 3 most important announcements in this keynote?",
        },
    ],
)

print(interaction.output_text)

開発者は interaction.steps を確認することもできます。レスポンスに processing_call と processing_result が含まれていれば、モデルが動画処理ツールを実際に呼び出して動的にナビゲーションを行ったことを示します。つまり、単に動画を静的に読み込んだわけではありません。この点はコスト監査やデバッグにおいて重要です。設定フィールドが正しく記述されていても、すべてのリクエストがまったく同じツールパスで実行されるとは限らないからです。

モードを選ぶ際の、シンプルな判断基準は以下の通りです。

依然として存在する限界

一つ目は、エージェントモードが減らすのは無関係な観察のみであり、動画分析が無料になるわけではないということです。質問の範囲が広く、確認すべきクリップの数が多いほど、モデルは依然として大量の画像・音声・推論ステップを呼び出す可能性があります。

二つ目は、能動的な選択によって、新たな失敗の形が生まれることです。静的なモードの欠点は、固定サンプリングによるフレーム落ちですが、エージェントのモードでは、検索の手がかりの誤り、時間枠の選択ミス、あるいは観察の早期終了などが欠点となり得ます。重要なタスクでは、ツールの実行結果を確認し、サンプリングによる再チェックや、別の検出経路を用意しておく必要があります。

三つ目は、三つのベンチマークとパートナー事例だけでは、監視、医療、セキュリティ、生産品質検査といったあらゆる現場での信頼性を証明するには不十分だということです。長尺動画のベンチマークは方向性の有効性を示していますが、実際のシステムは、遮蔽、低照度、圧縮ノイズ、字幕の誤り、ドメイン分布の変化などに直面します。

四つ目は、プロダクトへの展開には時間的な区切りがあるということです。Google は、この機能がまもなく Gemini アプリの Flash ユーザーと Flash-Lite ユーザーに提供され、今後数ヶ月以内に YouTube の視聴ページで Ask YouTube に使われる予定であると述べています。これらはあくまでリリース計画であり、すでにすべての一般ユーザーがフルに利用できる状態であると表現すべきではありません。

今回のアップデートが本当に変えたのは、動画がモデルに入力される方法です。これまでは、開発者が先に「どこまで見るか」を決め、モデルは取得済みの映像の中で推論するだけでした。しかし現在は、モデルが「次にどこを見るべきか」という判断も推論の一部にできます。長尺動画の場合、これはつまり、コンテキストウィンドウが単なる受け身の入れ物ではなくなり、繰り返し検索し、拡大し、確認できる作業台のような役割を持ち始めたということです。