レック・テクノロジー・コンサルティング株式会社TECH BLOG

※自動翻訳 / Automated translation

【Google Cloud Next Tokyo 26 参加レポート】個別セッション:Gemini API コスト攻略ガイド: 性能を落とさず費用を最小化するためのテクニック

Re:Q Tech Blogをご覧いただきありがとうございます。
クラウド&ネットワーク技術統括部のW.Rです。
先日、東京ビッグサイトで開催された Google Cloud Next Tokyo 2026 に参加してきました。
本記事では、私が聴講したセッション「Gemini API コスト攻略ガイド: 性能を落とさず費用を最小化するためのテクニック」の内容をレポートします。

セッション概要

IMG_3292.jpg

コストの考え方の基本

Gemini APIの費用はトークンの入力量と出力量、そして単価によって決まります。
以下の計算式がコストの基本となり、費用を最小化するためのポイントは「トークン量のコントロール」と「単価のコントロール」の2つです。
ここからは、具体的にどのようにして入出力のトークン量を減らし、単価を下げるのかについて解説していきます。

Gemini API 費用 = [入力トークン量 × 単価] + [出力トークン量 × 単価]

IMG_3301.jpg

1.入出力のToken量をコントロールする

コスト削減の第一歩はAPIリクエスト・レスポンスに含まれるトークン数そのものを制御することです。

  • アウトプットのコントロール
    maxOutput_Tokens:生成されるレスポンスの最大トークン数を上限設定するパラメータです。任意のパラメータですが意図しないコストを抑えることができます。

  • インプットのコントロール
    count_tokens:リクエストを送信する前に入力のトークン数を事前確認できる機能です。規定値を超えた場合に確認を入れる、拒否するなどといった制御を組み込むことで想定外のコストを防ぎます。

  • その他のコントロール手法
    Tuningによりインプット量を減らす:Geminiへのリクエスト時に解答のサンプルを多数入れている場合に有効な手段となります。副次的に特定タスクの品質向上、モデルの堅牢性向上、推論レイテンシとコストの低減といったメリットがあります。
    メディアの解像度指定:Gemini3以降で「media_resolution」を指定することができ、メディアの解像度を指定することができます。

2.モデルの選択、チューニング・呼び出しの選択で単価をコントロールする

  • 正しいモデル選択
    Gemini APIでは選択するモデルやバージョンによってトークン単価が大きく異なります。
    グラフで見て分かる通り同じFlash系のGemini 3 Flash、Gemini 3.5 Flash、Gemini 3.5 Flash-Liteでも使用量に大きな開きがあります。また、アップデートによって従来モデルと同等以上の精度を維持しつつ単価が下がるケースもあります。
    単に最も高性能なモデルを選ぶのではなく、ユースケースごとにベンチマークや必要な精度を見極め、適切なモデルを選択することが重要です。

IMG_3308.jpg

  • 呼び出し方によるコスト変化
    Gemini APIの単価はモデルだけでなくどのようなオプションで呼び出すかによっても変化します。

IMG_3312.jpg

3.コスト要素を可視化する

APIコストの最適化を維持し続けるには現在の利用状況を正しく可視化・監視する仕組みが不可欠です。

  • 従来からのコスト管理手法の徹底
    Google Cloud が提供する標準的なコスト管理機能を組み合わせることで管理します。
    • 予算アラートの活用:あらかじめ設定した閾値に達した際アラート通知を受け取ることで想定外の予算超過を検知します。
    • BigQueryエクスポート:課金詳細データをBigQueryへエクスポートし、用状況を分析・可視化します。
  • Agent に特化した監視機能(Agent Observability)の活用
    トークン消費の異常値を検知できる特化型の観測(Observability)機能が役立ちます。
    • Inputの異常値検知:コンテキストが異常に膨らんでいないか、あるいはユーザーが想定を超えた大量のテキストを入力していないかを監視します。
    • Outputの異常値検知:冗長な文章を生成し続けて過剰なトークンを消費していないかをチェックします。

最後に

今回のセッションを通じて、Gemini API を使ったシステム構築において「ただモデルを呼び出すだけ」ではなく、設計段階からコストを考慮したアーキテクチャを組むことの重要性を強く感じました。

特に、入出力トークン量の抑制や、Batch API・Flex PayGo といった呼び出しオプションの使い分け、さらには Agent Observability による異常値の事前検知などは、実際のプロダクション運用で今すぐ取り入れられる具体的な知見ばかりでした。

今後生成AIを活用したシステム開発やクラウドインフラ構築に携わる中で、常に性能とコストのベストバランスを意識し、より効率的で高品質な実装を目指していきたいと思います。。

最後までお読みいただきありがとうございました!

この記事をシェアする

  • Facebook
  • X
  • Pocket
  • Line
  • Hatena
  • Linkedin

資料請求・お問い合わせはこちら

WEB説明会実施中!

各技術領域ごとの業務内容や取り組んでいる最新技術についてお話します。
カメラ・マイクオフでの参加OK!
気軽にご参加ください。

お申込みはこちら

Re:Qチャンネル

Re:Qの技術領域や、これまで培ってきた経験を元にIT技術についての解説動画などを投稿しています。
是非ご覧ください!

公式Youtubeはこちら

ページトップへ戻る