Geminiで長い動画のトークンを88%減らす節約術

Gemini API で1時間の会議録画や講義動画を読ませたら、1本で数十万トークン——という請求に驚いた方は多いと思います。結論から言うと、この無駄は動画の「読み方」を変えるだけで大きく減らせます。

動画入力のパートに "processing": "agentic" というキーを1行足すだけで、長尺コンテンツのトークン消費が最大88%削減され、しかも長尺での応答品質は約7%向上すると Google 公式ドキュメントが明記しています。既定の処理方式が「動画を1秒1コマで全部読む」のに対し、agentic はモデルが必要な区間だけを自分で取りに行くためです。設定はモデルの差し替えもプロンプトの書き直しも不要で、動画パートにキーを1つ追加するだけで済みます。

結論：長い動画のトークン代は「読み方」を変えるだけで最大88%下がる

2026年9月1日、Gemini API のリリースノートに Agentic video understanding が追加されました。対応モデルはリリースノート記載で Gemini 3.7 Flash / 3.6 Flash / 3.5 Flash-Lite、ドキュメント側の対応表ではこれに 3.8 Flash を加えた4モデルです。Interactions API と GenerateContent API の両方で使えます。

効果として公式が挙げているのは2点です。長尺コンテンツでトークンが最大88%少なくなること、そして長尺コンテンツでの品質が約7%高くなること。コストが下がると品質も落ちるのが普通ですが、ここは逆で、必要な場面に集中して読むぶん精度も上がるという構図になっています。

実務で効くのは、会議録画の議事録化、講義・研修動画の要約、監視カメラや工程動画から特定の場面を探すといった「長い動画に一言だけ質問する」用途です。逆に短いクリップでは効果が出にくく、むしろ不利になる場面もあります（後述します）。

なぜ長尺動画はトークンを食うのか（1秒＝約100トークンの計算式）

Gemini API の既定の動画処理は static と呼ばれ、動画から1秒あたり1フレーム（1FPS）を抜き出し、そのすべてを1回でコンテキストに詰め込む方式です。つまり「質問が動画の最後の30秒についてのものでも、最初から最後まで全部読む」という動き方をします。

公式の Token counting の記述によれば、既定の low 解像度では1フレーム66トークン、音声32トークン/秒。合計すると動画1秒あたり約100トークンです。high 解像度を指定した場合は1秒あたり約300トークンになります。この式を使えば、自分の動画がいくらぶんのトークンになるか事前に計算できます。

1時間の会議録画を low 解像度で1回読ませるだけで約36万トークン。これを毎日10本処理すれば月に1億トークンを超える計算になります。high 解像度なら1本で約108万トークンとなり、入力100万トークンのコンテキスト上限にもぶつかります。「動画は1本読ませるだけでもテキストとは桁が違う」という感覚を、この式で先に持っておくのが実務では大事です。

なお、モデルごとの入出力トークン上限や世代差についてはGemini 3.6 / 3.7 / 3.8 Flash の料金と性能の違いを整理した記事にまとめています。コスト試算をするときは、トークン数の見積もりとモデル単価の両方を突き合わせてください。

static と agentic は何が違うのか

agentic 処理では、モデルが動画のタイムラインを自分で移動し、プロンプトに応じて必要な字幕・フレーム・音声トラックだけをその都度読み込みます。「30分あたりで予算の話が出たはずだ」と当たりをつけて、その周辺だけを開いて確認する、という人間に近い読み方です。全編を先に丸ごと読む static とは、消費するトークンの構造そのものが違います。

公式のガイドラインは「まず agentic から始めるのを推奨」という立場です。とくに応答品質とトークン効率を最適化したい場合は agentic を出発点にし、後述の条件に当てはまるときだけ static に戻す、という順番が実務的です。

設定方法：動画パートにキーを1つ足すだけ

実装の変更は驚くほど小さく、動画入力パートに "processing": "agentic" を追加するだけです。Python / JavaScript / curl のいずれでも考え方は同じで、動画を指すオブジェクトに1つキーが増えるだけと考えてください。

たとえば Python の Interactions API なら、client.interactions.create(model="gemini-3.8-flash", input=[動画パート, テキストパート]) の動画パートの中に上表の4キーを並べ、テキストパート側に「30分以降で予算に言及した箇所を要約して」といった質問を書きます。モデル名やプロンプトを作り直す必要はありません。

もうひとつ、長尺・複雑なプロンプトのときに必ず入れておきたい設定があります。stream=True または background=True を使うことです。agentic はモデルが内部で何度も動画を読みに行くため応答までの時間が伸びやすく、ストリーミングかバックグラウンド実行にしておかないと接続維持やタイムアウトで足をすくわれます。ストリーミングにしておけば、途中の推論の様子も見えるようになります。

社内の動画をAPIで処理する仕組みは、この1行の使い分けに加えて、保存先の設計・失敗時の再実行・費用の見張りまで含めて初めて業務で回るものになります。Mihata では、こうした社内向けAIの仕組みづくりもお手伝いしています。記事の途中で恐縮ですが、自社で組むか任せるかを比べる材料として、よろしければ覗いてみてください。

効いているかを確かめる方法

「キーは足したが本当に agentic で動いているのか」は、レスポンスの interaction.steps を見れば判定できます。agentic が効いていれば、そこに processing_call（モデルが特定の区間や字幕を要求した記録）と processing_result（その読み込み結果）が現れます。両者は call_id で対応づけられ、thought ステップと交互に並び、最後の model_output の前に来ます。

この2つが1つも出ていなければ、キーの位置が間違っている、あるいは非対応モデルを指定している可能性が高いと考えられます。逆にこれらが並んでいれば、モデルが動画のどこを見に行ったかが分かるので、UI の進捗表示に使うこともできます（応答そのものには不要な情報なので、無視して構いません）。

導入直後は、同じ動画・同じ質問で static と agentic を1回ずつ流し、消費トークンと回答内容を並べて記録しておくことをおすすめします。88%という数字はあくまで公式が示す上限値で、実際の削減幅は動画の長さと質問の狙い方で変わるためです。自社の代表的な動画で実測しておけば、その後の見積もりが一気に楽になります。

static を選ぶべき場面もある

agentic が常に正解というわけではありません。公式は static が向く場面を2つ明示しています。ひとつは5分未満の短いクリップでレイテンシを重視するとき、もうひとつはクリップ全体でフレーム単位の精度が必要なときです。

短いクリップで不利になる理由もはっきりしています。agentic は内部推論とツールの往復を挟むため、TTFT（最初のトークンが返るまでの時間）がわずかに増えることがあるのです。5分＝約3万トークンなら静的処理でも負担は小さく、待ち時間の短さのほうが価値になります。チャットUIのように応答速度が体験を左右する用途では、あえて既定のままにする判断が合理的です。

また、動画の全フレームを漏れなく評価したい解析——たとえば不良品検知や動作の逐一チェックのように「見落としが許されない」処理では、必要箇所だけを読む agentic は設計思想が合いません。ここは削減率ではなく網羅性を優先すべき場面です。

実務での落とし穴

コストを詰める前に、仕様上の制約を確認しておくと後戻りが減ります。とくに YouTube 動画をURLで渡す運用は制限が具体的です。

• YouTube は無料枠だと1日8時間まで。有料枠では長さの制限はありません。検証段階で上限に当たり「昨日は動いたのに今日は通らない」となりがちです。
• YouTube は公開動画のみ。限定公開・非公開の動画は渡せません。社内研修動画を限定公開で置いている場合は、ファイルとしてアップロードする経路に切り替える必要があります。
• 1リクエストに渡せる YouTube 動画は Gemini 2.5 以降で最大10本。大量の動画を一括で読ませる設計にはできません。
• Gemini 3.8 Flash では thinking の minimal が使えない。2026年9月2日にGAとなった gemini-3.8-flash は low / medium / high のみ対応で、minimal を指定するとエラーになります。他モデルからの移行時にここで落ちるケースがあります。
• 短いクリップでは TTFT が伸びうる。前述のとおり、速さが要る場面では逆効果になり得ます。

もうひとつ、費用面で見落とされがちな論点があります。目的が「話した内容の文字起こし」だけなら、動画としてマルチモーダルに読ませるより専用モデルを使うほうが安く済むことです。音声を文字にするだけなら、Gemini 3.5 Transcribe の文字起こしAPIをコスト面から検証した記事で扱ったような専用の経路のほうが素直です。映像の中身を理解させたいのか、音声を文字にしたいのか——ここを分けて考えるだけで請求額はかなり変わります。

なお本記事は動画を「読ませる」側の話です。動画を「作る」「延長する」側の機能は仕組みも料金体系も別物なので、Gemini の動画生成・動画延長機能を解説した記事のほうを参照してください。

まとめ：まず agentic で始め、短尺だけ static に戻す

長い動画のトークン代は、モデルを変えたり動画を切り刻んだりする前に、動画パートに "processing": "agentic" を1行足すところから見直すのが最短です。長尺で最大88%のトークン削減と約7%の品質向上、しかも実装コストはキー1つ。まずこれを既定にして、5分未満でレイテンシが命の処理と、全フレームの精度が要る解析だけ static に戻す——という運用が、現時点で最も無駄が少ない形だと考えています。

導入時は、代表的な動画1本で static と agentic の消費トークンを実測し、interaction.steps に processing_call が出ているかを確認するところまでをセットにしてください。数字が自社のものになれば、その後の判断はぐっと速くなります。動画処理を含む社内AIの設計や、費用が読めないまま止まっている検証があれば、お気軽にご相談ください。