Gemini のエージェント的動画理解 — トークン最大88%減、コスト最大66%減、しかも精度が上がる

要約

2026-09-01、Google が agentic video understanding（エージェント的動画理解） を Gemini の最新モデル群へ導入しました。

従来の動画処理は、固定フレームレートで動画全体を一律に処理していました。 1時間の動画を扱うなら、問いに関係のある3分間も、関係のない57分間も、同じようにフレームへ分解してトークン化する。関係のない部分にも同じコストが掛かっていたわけです。

今回の方式では、モデル自身が「どの区間を、どの速度で、どのモダリティで調べるか」を動的に決めます。 モダリティとは、フレーム（映像）、音声、文字起こしのことです。公式の表現では「対象となる動画区間を動的に検索・スキャン・検査する」。

人間が長い動画から情報を探すときの動きに近い、と考えるとわかりやすい。 全編を等速で見るのではなく、早送りして当たりをつけ、関係のありそうな箇所で止めてじっくり見る。音声だけで足りるなら映像は見ない。

公式が挙げている効果は3つで、いずれも数字が出ています。

トークン消費が最大88%減。コストが最大66%減。品質が最大7%向上。

コストと精度が同時に改善している点が重要です。 通常、コスト削減は品質とのトレードオフになります。しかしここでは、「関係のない区間を読まない」ことがノイズの削減にもなっているため、両方が良くなる。 一律処理では、無関係な57分間がモデルの注意を薄めていた、ということです。

対応モデルは Gemini 3.7 Flash / Gemini 3.6 Flash / Gemini 3.5 Flash-Lite の3つ。 Flash 系に絞られています。

開発者の使い方は、拍子抜けするほど簡単です。 Gemini API の設定に "processing": "agentic" を指定するだけ。動画 URI を渡す既存の呼び出しに、パラメータを1つ足す形になります。利用経路は Google AI Studio と Gemini Enterprise Agent Platform。

そして課金です。標準の Gemini API トークン単価のままで、機能追加料金はありません。 つまり、トークン消費が減った分が、そのままコスト削減になります。

提供状況は、API 経由が即日利用可能。 Gemini アプリのユーザーには「まもなく」、YouTube の「Ask YouTube」機能への統合は「今後数か月のうちに」とされています。

何が変わったか

• agentic video understanding を導入。 モデルが区間・速度・モダリティ（フレーム / 音声 / 文字起こし）を動的に選択する
• 従来は固定フレームレートでの一律処理だった
• 効果: トークン消費 最大88%減 / コスト 最大66%減 / 品質 最大7%向上
• 対応モデル: Gemini 3.7 Flash、Gemini 3.6 Flash、Gemini 3.5 Flash-Lite
• 有効化: API 設定に "processing": "agentic" を指定するだけ
• 利用経路: Google AI Studio、Gemini Enterprise Agent Platform
• 課金は標準のトークン単価。機能追加料金なし
• 提供: API は即日。Gemini アプリは「まもなく」、YouTube の Ask YouTube は「今後数か月のうちに」

業務インパクト（一般企業向け）

動画を扱う実装があるなら、これは即座に検証対象です。

理由は単純で、リスクが極めて小さいからです。 パラメータを1つ足すだけ。追加料金なし。うまくいかなければ外せばいい。 これだけ試すコストが低い変更は珍しい。

逆に言えば、試さないまま従来方式で払い続けるコストが、そのまま損失になります。 最大66%減という数字が自社のワークロードで再現するとは限りませんが、測らなければ何もわかりません。

検証の仕方は2段階にしてください。

まずコスト。 同じ動画・同じ問いで、agentic の有無を比較してトークン消費を測る。公式の数字は「最大」なので、自社の実測値がそれより小さいのは当然です。 重要なのは「どのくらい減ったか」であって、公称値に届くかではありません。

次に品質。 ここは注意が要ります。エージェント的処理は、モデルが「見る区間を選ぶ」わけです。 つまり、選ばれなかった区間の情報は落ちます。

公式は品質が最大7%向上すると言っていますが、これは平均的な傾向です。 「動画全体を通して散在する情報を集める」ような問いでは、区間選択が裏目に出る可能性があります。 逆に「特定の場面を探す」「特定の発言を見つける」といった問いでは、明確に有利です。

したがって、自社のユースケースが「探索型」なのか「網羅型」なのかを見極めてください。 探索型なら迷わず有効化。網羅型なら、精度の実測を丁寧にやる価値があります。

用途としては、いくつか具体的な適用先があります。

会議録画の要約と検索。 1時間の会議から「予算の話をしていた部分」を探す——典型的な探索型で、この方式が最も効く用途です。

監視カメラ映像の確認。 長時間の映像から特定の事象を探す。従来は全編をトークン化するコストが非現実的だった領域です。

研修動画・講義動画からの情報抽出。 「この手順の説明箇所」を特定する。

カスタマーサポートの通話録画。 音声モダリティが選ばれれば、映像のコストを払わずに済みます。

いずれも「長い素材から必要な部分を探す」という構造で、まさにこの方式の想定用途です。

注意点として、Flash 系モデルに限られる点は押さえてください。 Pro 系での提供は現時点では言及されていません。**「Gemini で使える」ではなく「Gemini 3.7 Flash / 3.6 Flash / 3.5 Flash-Lite で使える」**が正確な理解です。モデル選定を Pro で固めている実装では、そのままでは使えません。

副業・個人活用視点

動画を扱う受託や個人開発をしているなら、これは直接効きます。

動画処理は、これまで「やりたいが単価が合わない」領域でした。 1時間の動画を1回処理するコストが、案件の予算感に対して重すぎる。トークンが最大88%減るということは、その計算が変わるということです。

具体的には、これまで見送っていた案件が成立しうる。 会議録画の自動要約、講義動画の索引作成、長時間素材からのハイライト抽出——「技術的にはできるが採算が合わない」で止まっていたものを、もう一度計算し直す価値があります。

提案の作り方としては、実測値を持っていくのが強い。

「Google は最大88%減と言っています」ではなく、「あなたの動画1本で試したら、こう減りました」——後者を出せるかどうかで、提案の重みがまったく変わります。試すコストがパラメータ1つ分なので、事前検証のハードルも低い。 サンプル動画を1本もらって実測してから提案する、という進め方が現実的です。

そして、精度の話を先に出してください。

「区間を選ぶ」ということは「選ばれなかった区間は見ていない」ということです。 これを説明せずに導入すると、「動画に映っていたはずのものが出てこない」というクレームで信頼を失います。

探索型の問いには強く、網羅型の問いには注意が要る——この線引きを最初に共有しておけば、期待値のずれが起きません。 制約を先に言うことが差別化になる、という原則がここでも同じ形で当てはまります。

もう1つ、学びとして持っておく価値のある視点があります。

この改善の本質は、モデルを賢くしたことではありません。処理の仕方を変えたことです。

一律に全部処理する、から、必要な部分を選んで処理する、へ。 これだけでトークンが88%減り、しかもノイズが減って精度が上がった。同じモデルでも、入力の与え方を変えるだけで結果が大きく変わるという、極めて一般的な原則の実例です。

自分が組んでいる処理でも同じことが言えないか、と考える価値があります。 「とりあえず全部モデルに渡す」実装は、コストと精度の両方で損をしている可能性がある。 前処理で絞り込む、必要な部分だけ渡す——この発想は、動画に限らずどんな入力にも適用できます。