【Google Cloud Next Tokyo 26】Gemini API コスト攻略ガイド: 性能を落とさず費用を最小化するためのテクニック

こんにちは！先進技術戦略室の中谷です！
2026年7月30日・31日に東京ビッグサイトで開催された Google Cloud Next Tokyo 26 に参加してきました。本記事では、2日目に聴講した「Gemini API コスト攻略ガイド」のレポートをお届けします。
AI を組み込んだアプリケーションは作れるようになったけれど、その費用をどうコントロールするかという話は、まだ現場に十分行き渡っていないと感じています。このセッションは、まさにそこを正面から扱う内容でした。

セッション概要

公式セッションカタログでは、以下のように紹介されていました。

自社アプリなどに Gemini 機能を組み込む際、コストをコントロールすることは非常に重要になります。本セッションでは、Gemini の API のコスト構造について説明をしつつ、コスト効率良く性能を引き出すためのテクニックについて説明します。
セッションは、コストを意識する必要が高まっている背景の共有から始まり、そのあと3つのテーマを順に扱う構成で進行しました。

なぜ今トークンのコストなのか

冒頭で示されたのは、技術と組織の変化速度のギャップでした。

生成 AI によってコード自体も AI で生成するようになり、AI アプリケーションを瞬時に作れるようになった。技術は指数関数的に変化しているのに対して、組織は対数的にしか変化していない。このギャップを埋める必要がある、という提示です。
そのギャップの一つとして挙げられたのが、トークン使用量の増大に対する認知と対応でした。世界のトークン使用量は年々増加しており、特に AI Agent は思考・アクション・観察を自律的に繰り返すため、ユーザーのインタラクションが少なくても、Agent 側で複数回 LLM を呼び出して消費トークンが増加するケースが起こりうる、という説明です。
ユーザーが直接何かを入力した回数と、実際に消費されるトークン量が比例しなくなってきている。ここが従来のコスト感覚と食い違うポイントだと受け取りました。

業界全体の動きとして、Tokenomics という潮流も紹介されました。2026年6月3日に Linux Foundation が Tokenomics Foundation 設立の意向を発表しており、AI のコスト管理に関するオープンな標準を策定する中立的な場を提供する、という趣旨のものです。
コスト管理が個社の工夫ではなく、標準化の対象になり始めているということですね。

そのうえで示されたのが、この問いかけでした。

• とりあえずデータは多いほうが良いと思うから、入力に出来る限りの関連書類を入れておく
• モデルは賢いのが良いと思うから Gemini 3.1 Pro を選択する
• Thinking Level はよく分からないけれど、とりあえず High に設定しておく

そして、その結果として「課金が爆発してる」「なかなか返事が返ってこなくてユーザからの評判が悪い」「思ったほど精度が出ないぞ」という状態になっていませんか、と続きます。
心当たりのある選び方でした。特に「賢いモデルを選んでおけば安心」という発想は、費用だけでなく応答速度や精度の面でも最適とは限らない、というのがこのあとの内容につながっていきます。

コストの考え方の基本

Gemini API の費用は、入力トークン量と出力トークン量のそれぞれに単価を掛けて足したもの、というシンプルな構造です。
ここで押さえておきたいのが、入力と出力で単価が違うという点です。一般に出力の単価は入力の5〜6倍高く、同じトークン数でも出力側のほうが費用がかかります。
つまり、コストを下げるには「入力を減らす」「出力を減らす」「単価そのものを下げる」の3方向があり、なかでも出力側は単価が高いぶん効果が大きいということになります。この式が、以降のテクニックすべての土台になっていました。

入出力のトークン量をコントロールする

1つ目のテーマは、入力と出力それぞれのトークン量をどう抑えるかでした。

出力の量を API レベルで縛る

プロンプトで出力のコントロールを試みつつ、maxOutputTokens を利用して Gemini からの出力値を API レベルで制限する、という方法です。任意のパラメータですが、念のため設定しておいたほうが安心、という説明でした。
プロンプトでの指示は守られないことがありますが、API のパラメータであれば確実に上限が効きます。出力側の単価が高いことを考えると、これは入れておく価値があります。

入力の量を事前に数える

入力については、CountTokens API を利用して Input のトークン量を事前に確認する方法が紹介されました。CountTokens API 自体は現在無料で使えるとのことです。
活用例として挙げられていたのが、トークン量が一定量を超えるようであれば確認をいれる、あるいは拒否するなどして、爆発を防ぐガードレールを作るという使い方でした。
呼び出す前に量が分かるので、実行してから驚くという事態を避けられます。無料で使えるなら、組み込まない理由がないと感じました。

繰り返し入れているサンプルを減らす

Tuning によって Input 量を減らすという方法も紹介されました。Gemini への Input の中で回答のサンプルなどを多く入力している場合に有効で、副次的に特定タスクの品質向上、モデルの堅牢性向上、プロンプトが短くなることによる推論のレイテンシとコストの低減という効果も得られる、という内容です。
ただし Tuning 自体にコストがかかるため、コスト削減になるかどうかはプロンプト量や呼び出し回数によって見極める必要がある、という注意も添えられていました。
毎回のプロンプトに同じサンプル文を入れていると、実行するたびにその分のトークンを消費し続けることになります。呼び出し回数が多いほど、事前に Tuning しておく判断が効いてくるという構図です。

メディアの解像度を指定する

Gemini 3 以降であれば、メディアの解像度（media_resolution）を指定できます。費用とレイテンシが最優先で、メディアの詳細な解像度がそれほど重要でないケースには MEDIA_RESOLUTION_LOW などに設定する、という使い分けです。
スライドの表を見ると、画像の場合はデフォルトが 1120 に対して LOW が 280 で、4分の1になります。画像や PDF を扱うアプリケーションでは、ここの指定だけで入力側のトークン量が大きく変わることになります。

モデルと呼び出し方を選ぶ

2つ目のテーマは、モデルの選択と呼び出し方の最適化でした。個人的にはここが一番の収穫でした。

同じ Flash でも単価にばらつきがある

モデルごとの入力単価と出力単価をプロットしたグラフです。求めるパフォーマンスやコストに合わせたモデル選択が重要であること、一般に出力単価のほうが高いこと、そして同じシリーズでも単価のばらつきがあるので注意が必要、という説明がありました。
グラフを見ると、Flash 系のなかでも Gemini 3.5 Flash と Gemini 3 Flash では出力単価に3倍近い差があります。「Flash だから安い」とひとくくりにはできないということです。
さらに、バージョニングが変わると単価が変化するケースもあると示されていました。スライドでは、Gemini 3.5 Flash から Gemini 3.6 Flash へのアップデートで Output Token のコストが下がった例が挙げられています。

こちらはコストだけでなく、パフォーマンスに対するコストを見た図です。Terminal-Bench 2.1 のスコアを縦軸に取っています。
同じバージョニングだと Flash-Lite、Flash、Pro の順にコストパフォーマンスが高い傾向があること、そしてモデルがアップデートされると、より安く高いパフォーマンスを発揮できるユースケースもあることが示されていました。ユースケースによって得意不得意があるので、用途を意識したベンチマーク等の確認が必要、という補足もありました。
ここが一番刺さった部分でした。モデル名だけを見て「Flash なら安い」「新しいバージョンが出たから切り替えよう」と判断するのは危ういということです。同じ Flash のなかでも単価に開きがあり、バージョンが上がれば単価も性能も変わる。選び直すたびに、そのときの単価表とベンチマークを確認する作業が必要になります。

思考の深さを制御する

思考モードに対応しているモデルでは、Thinking Budget や Thinking Level で思考の深さを制御できます。Gemini 3 以降では Thinking Level の指定が対応しており、Thinking Budget と両方指定するとエラーになるので注意、という説明でした。
思考の時間を長めに取れば精度の高い回答をもらえる可能性が上がりますが、その分トークン消費量も上がります。冒頭の「とりあえず High でいいか」に戻ってくる話で、タスクの性質に応じて選ぶ必要があるということですね。

呼び出し方でコストが変わる

同じモデルを使っていても、呼び出し方によって単価が変わるという話です。5つの選択肢が、求める性質に応じて並べられていました。

急がない処理を Standard PayGo で回していると、半額で済むはずのものに倍払っていることになります。

Batch 推論については個別に説明がありました。非同期で処理され、ほとんどのジョブは実行開始後24時間以内に完了。24時間を経過すると未完了のジョブはキャンセルされ、完了したリクエストに対してのみ課金される。最大 200,000 件のリクエストを一つのバッチ処理に含められる、という内容です。
適したタスクとして、商品説明やソーシャルメディア投稿などのコンテンツ生成、ユーザーレビューの分類や感情分析といったデータのアノテーション、記事の要約やドキュメント翻訳などのオフライン分析が挙げられていました。

同じ入力を繰り返すならキャッシュが有効

入力内容が繰り返される場合は、コンテキストキャッシュを使ってトークン費用を削減できます。暗黙的なキャッシュ保存（Implicit Caching）と明示的なキャッシュ保存（Explicit Caching）の2パターンがあり、暗黙的なほうはデフォルトで有効かつストレージ費用が無料、明示的なほうは API による手動制御でストレージ費用が発生する、という整理でした。

暗黙的なキャッシュ保存について、デフォルトで有効化されているため、特に設定など行っていなくても恩恵をうけている可能性もある。そしてキャッシュにヒットすると、トークン単価が90%削減される、という説明がありました。
これも知らなかった話でした。自分では何も設定していないのに、条件が合えば単価が10分の1になっている可能性があるということです。逆に言えば、キャッシュにヒットしているかどうかで請求額が大きく変わるので、実績値だけを見て「うちはこれくらいの費用感」と判断すると読み違えることになります。
明示的なキャッシュ保存のほうは、キャッシュしたいコンテンツを事前に保存し、モデル呼び出しの際にキャッシュを明示的に指定するものです。保存には料金がかかりますが、暗黙的なキャッシュとの併用も可能とのことでした。

コスト要素を可視化する

3つ目のテーマは、使った結果をどう見るかでした。

まずは従来からあるコスト管理を徹底すること。予算アラートを活用して想定外の予算超過を検知し、課金データを BigQuery にエクスポートして利用状況を分析・可視化する、という内容です。

上限に達したら止める仕組み

スライドには含まれていませんでしたが、口頭で紹介があったのが Spend cap budgets（スペンド キャップ バジェット）です。設定した利用量に達したタイミングで、自動的に利用ができなくなる機能とのことでした。
登壇者の方が「資料に間に合わなかった」と話されていた通り、公式ブログでの発表が2026年7月29日、このセッションが7月31日です。
公式ドキュメントで確認したところ、現在は Public Preview で、Gemini API、Gemini Enterprise Agent Platform、Cloud Run、Cloud Run functions が対象です。上限に達すると、そのプロジェクトの該当サービスへの新規の利用がブロックされます。手動で解除するまでブロックは続き、コンピュートやストレージのような永続リソースの課金は止まりません。設定は1プロジェクトかつ1サービス単位で、期間は月単位です。
従来の予算アラートが「気づかせる」機能だったのに対して、こちらは「止める」機能です。トークン消費が読みにくい AI アプリケーションでは、気づいたときには手遅れということが起こりえます。止まってしまうリスクはありますが、青天井で課金され続けるリスクと比べてどちらを取るかという判断になります。

Agent の入出力を監視する

最後に紹介されたのが、Agent に特化した監視機能（Agent Observability）です。Token に関する観測が行え、Input の異常値としてコンテキストが異常に多くないか、ユーザーが大量にテキストを入力していないか、Output の異常値として冗長な文章を生成していないかを見ることができる、という内容でした。
冒頭にあった「Agent は自律的に複数回 LLM を呼ぶ」という話と対になっています。人が直接操作していない分だけ、どこで消費しているかを別途観測する必要があるということですね。

まとめ

セッションの内容は、以下の3点に整理されていました。

• 入出力のトークン量をコントロールするための手法（maxOutputTokens、メディア解像度、Tuning など）
• モデルを正しく選択し、さらにユースケースに合わせてチューニング・呼び出しを行うための選択肢（Thinking Budget、Batch API、コンテキストキャッシュ など）
• コストや入出力量をモニタリングするための手法（Billing 分析、Agent Observability など）

聴き終えて感じたのは、コストを下げる手段はすでに一通り揃っているということでした。maxOutputTokens も count_tokens も media_resolution も、特別な設計を必要とせずに指定できるパラメータです。にもかかわらず費用が膨らむのは、手段がないからではなく、知られていないからだと思います。

さいごに

このセッションを聴こうと思ったのは、社内で Gemini や AI が組み込まれたアプリケーションを活用していくなかで、AI アプリに特化した注意事項の普及が足りていないと感じていたからでした。利用するメンバーがヘビーにトークンを使えるようになるほど、全体としての消費量は跳ね上がります。
聴いてみて、その懸念は具体的な形になりました。今回の内容をそのまま社内向けの利用ガイドとしてまとめようと思っています。特に、暗黙的なキャッシュのように自分では設定していないのに効いている仕組みや、同じ Flash でも単価にばらつきがあるという話は、知らないまま使い続けると判断を誤るポイントです。
もう一つ、これからの自分の仕事として持ち帰ったのが、提案の段階でコスト設計を必ず含めるということでした。
AI を組み込んだアプリケーションの提案では、どんな体験が実現できるかという話が中心になりがちです。ただ、今回のセッションで示された通り、同じ機能を実現するにもモデルの選び方や呼び出し方によって費用は何倍も変わります。作れるかどうかだけでなく、いくらで動かし続けられるのかまで含めて設計するのが、AI を扱う側の責任なのだと受け止めました。
最後までお読みいただき、ありがとうございました。