結論から言うと、現行のテキストToken単価だけなら gemini-2.5-flash-lite が最安です。一方、新規開発で新世代の安定した低コスト候補から始めたいなら、まず gemini-3.1-flash-lite を検証します。「単価が最安」と「新しい安定候補」は別の答えで、最終判断は入出力比率とタスクの一発合格率で変わります。
2026年7月14日に確認した Google公式料金 では、2.5 Flash-Lite の Standard は入力100万Tokenあたり $0.10、出力は $0.40。3.1 Flash-Lite は入力 $0.25、出力 $1.50です。入力100万・出力25万Tokenの同一負荷なら、前者は $0.20、後者は $0.625 になります。
| 現行テキストモデル | Standard 入力 / 出力（100万Token） | 入力100万 + 出力25万 | 最初の役割 |
|---|---|---|---|
gemini-2.5-flash-lite | $0.10 / $0.40 | $0.20 | 現行の最安単価 |
gemini-3.1-flash-lite | $0.25 / $1.50 | $0.625 | 新世代の安定した低コスト候補 |
gemini-2.5-flash | $0.30 / $2.50 | $0.925 | Liteが基準未達のときの安定版昇格 |
gemini-3-flash-preview | $0.50 / $3.00 | $1.25 | Preview検証用。production既定にしない |
gemini-3.5-flash | $1.50 / $9.00 | $3.75 | 価格差を実測で説明できる場合のみ |
まず安定版Liteで代表タスクを回し、失敗・再試行・手修正の追加費用がモデル差額を超える場合だけFlashを比較します。待てる処理や同じ長い文脈を繰り返す処理だけ、Batch、Flex、キャッシュを別計算します。
テキストAPIの単価は、Gemini APIの無料枠 や Gemini 3.1 Flash-Lite Imageの画像料金 と分けて判断します。名前が似ていても、出力形式、請求対象、読者が完了したい仕事は同じではありません。Geminiアプリの月額やVertex AIの料金も、このGoogle AI Developer APIテキスト表へ混ぜません。
1回あたりと月額コストを先に計算する
入力単価だけを並べても、実際の請求は分かりません。テキスト呼び出しの基本式は、入力と出力を別々に計算してから合計します。
月額 = 月間入力Token × 入力単価 / 1,000,000 + 月間出力Token × 出力単価 / 1,000,000
入力にはユーザーの最後の発言だけでなく、system prompt、会話履歴、検索・RAGで取得した文書、モデルへ戻すツール結果、画像などのマルチモーダル文脈、エラー後の再送も入ります。出力は返答全体です。料金表が「thinking tokensを含む」と書く行では、画面に見える文章だけを数えると過小評価になります。
冒頭の「入力100万 + 出力25万」は5モデルを同じ作業量で比較するための基準です。Grounding、有料ツール、明示的キャッシュの保存、税、失敗後の再試行、第三者経路の上乗せは含みません。production予算ではこれらを別行にしないと、精密に見えるモデル費用が総額を隠します。
より実務に近い例として、月100,000回、1回平均800入力・200出力Tokenを処理するとします。月間合計は入力8,000万、出力2,000万Tokenです。
| モデル | Standard 1回あたり | Standard 月100,000回 | 対応し遅延を許容できるBatch/Flex |
|---|---|---|---|
| Gemini 2.5 Flash-Lite | $0.00016 | $16 | $8 |
| Gemini 3.1 Flash-Lite | $0.00050 | $50 | $25 |
| Gemini 2.5 Flash | $0.00074 | $74 | $37 |
| Gemini 3 Flash Preview | $0.00100 | $100 | $50 |
| Gemini 3.5 Flash | $0.00300 | $300 | $150 |
2.5 Flash-Lite の $16 は 80 × $0.10 + 20 × $0.40、3.1 Flash-Lite の $50 は 80 × $0.25 + 20 × $1.50 です。80と20の単位は100万Tokenです。1回あたりは月額を100,000で割っただけで、別の価格仮定は置いていません。
数件の短いprompt平均だけで本番予算を作らないでください。入力・出力の中央値と上位パーセンタイルを取り、長い会話、RAG文脈、構造化出力エラー、再試行を分けます。FAQボットは平均出力が短くても少数の長文が費用を支配し、抽出処理は不正なJSONを直す再送が入力をもう一度消費します。
特に出力は過小評価されやすい項目です。確認日時点で3.1 Flash-Liteと3.5 Flashは、出力単価が入力単価の6倍です。最大出力Tokenを絞れば支出を抑えられますが、狭すぎる上限は途中切れ、必須フィールド欠落、再試行を生みます。目標は「最短回答」ではなく「タスクを安定完了できる最短出力」です。
予算には、現状、呼び出し数2倍、上位出力量増加の少なくとも3シナリオを置きます。これで、モデル単価、コンテキスト長、回答設計、再試行率、実行モードのどれを改善すべきか見えます。小規模試験の最小値をそのまま本番上限にしないことが重要です。
2.5 Flash-Lite、3.1 Flash-Lite、Flashの選び方
まず呼び出せない選択肢を外します。Gemini 2.0 FlashとGemini 2.0 Flash-Liteは2026年6月1日に停止済みです。Googleの廃止スケジュール は移行日を、現在のモデル一覧 は利用可能な正確なIDとライフサイクルを確認するために使います。停止IDの低価格を比較しても実行可能な判断にはなりません。
現行のToken単価を最小化するなら、Gemini 2.5 Flash-Liteから試します。 分類、抽出、ルーティング、書き換え、短い要約、構造変換はLiteの開始候補です。ただし「候補」は品質保証ではありません。言語、長文脈、厳格なschema、複雑な判断、安全境界を自分のタスクで検証します。
新規開発で新世代の安定した低コスト候補を選ぶなら、Gemini 3.1 Flash-Liteから試します。 3.1 Flash-Liteのモデルページ は確認日に、1,048,576 Tokenの入力上限と65,536 Tokenの出力上限を掲載しています。マルチモーダル入力を受けられますが、出力はテキストです。画像を生成するFlash-Lite Imageとは別モデルです。
Liteが受け入れ基準を満たさないとき、Gemini 2.5 Flashを比較します。 安定版Flashへの昇格候補で、入力単価は3.1 Flash-Liteに近い一方、出力は高くなります。選ぶ理由は、合格率が上がり、再試行と手修正が減ることです。「Flashの方が強そう」という名前だけでは予算を説明できません。
Gemini 3 Flash Previewは実験レーンに限定します。 Previewはライフサイクル、提供状況、動作変更のリスクが安定版より高い状態です。新機能を検証する理由があり、安定版へ戻せるチームだけが試し、productionの無言の既定値にしません。
Gemini 3.5 Flashは高価格の能力レーンです。 100,000回の例ではStandardが月$300で、二つのLiteより大幅に高価です。より高い合格率、手修正削減、安価な候補では実行できない明確な能力が差額を超える場合のみ合理的です。料金表は品質改善を証明しません。
初期選択は三つのルールで十分です。Token予算を最優先するなら2.5 Flash-Lite。新世代の安定した低コスト候補なら3.1 Flash-Lite。両方が同じ受け入れテストで基準未達なら安定版Flashを追加します。モデル、prompt、実行モード、キャッシュを同時変更すると、改善の原因が分からなくなります。
無料枠・課金レベル・Token単価を分ける
料金表にFree Tierがあっても、すべてのプロジェクトに同じ固定無料回数があるとは限りません。利用量はモデル、プロジェクト、usage tier、地域、Googleの現在の条件で変わります。レート制限の説明 はRPM、TPM、RPDなどの単位を示しますが、実際の値は対象プロジェクトを選んだGoogle AI Studioで確認します。
同じプロジェクト内でAPI keyを増やしても、通常はクォータが倍になりません。keyは認証情報で、クォータと請求はプロジェクトに属します。429が出たら、どの制限軸に到達したか、backoffが必要か、tierを変更すべきかを確認します。原因を見ないkeyローテーションは容量問題を隠すだけです。
「モデルに無料行がある」「このプロジェクトに今いくら残っている」「有料課金が有効」の三つは別の質問です。無料枠はリクエスト形式や初期タスクを試すには便利ですが、継続トラフィックを支えられるかはライブクォータ次第です。有料運用では予算上限、請求担当、異常利用アラート、停止条件を先に決めます。
Gemini APIの課金ガイド は確認日に、prepaid/postpaid、spending cap、クレジット期限などを説明しています。最低入金、税、利用可能条件はアカウントごとに変わり得るため、古い日本語記事の数字ではなく、支払う直前の実billing accountを確認します。
失敗リクエストは「請求」と「容量消費」の二軸で監視します。Googleの現在の説明では400系・500系の失敗はToken課金されませんが、クォータへ数えられる場合があります。retry stormは請求を大きく増やさずにRPMやTPMを枯渇させる可能性があります。金額グラフと容量グラフを同時に見てください。
データ利用も別契約です。Gemini API追加利用規約 はunpaid serviceとpaid serviceを区別します。無料サービスへ送ったコンテンツはGoogle製品改善に使われ、人が確認する場合があるため、機密・個人・秘密情報を送るべきではありません。顧客データを本番投入する前に、組織方針、データ処理条件、プロジェクト設定を確認します。
主な疑問が「自分のプロジェクトは今どこまで無料か、いつ課金が必要か」であれば、Gemini API無料枠ガイド へ分けます。動的クォータをモデル価格表に固定すると、価格ページも無料枠ページも早く古くなります。
Standard、Batch、Flex、キャッシュを使い分ける
ユーザーの待つリクエストでは、まずStandardを測ります。Standardはレイテンシ、エラー、Token、タスク合格率の説明可能な基準になります。この基準がなければ、費用減少がBatch、Flex、キャッシュ、モデル変更、prompt変更のどれによるものか判断できません。
| 実行モード | 向く処理 | 確認日のコスト影響 | 使わない条件 |
|---|---|---|---|
| Standard | 対話応答、同期判断、即時の後続処理 | Standardの全Token単価 | 安全に待てる、または大きい反復文脈がある |
| Batch | 非緊急の非同期generateContent | 対応料金行ではStandardの50% | 最大約24時間の完了目標を許容できない |
| Flex | 対応モデル・地域で弾力的実行を許容 | 対応時に割引料金 | 可用性・サービス特性が本番要件に合わない |
| 明示的キャッシュ | 大きい有効な接頭辞を繰り返す | cache read + storage + 新規input + output | 反復が少ない、TTL不適切、保存費が節約を超える |
| 上位モデル | Liteが代表タスクで基準未達 | 単価上昇、失敗費用が下がる可能性 | 合格結果あたりコストが改善しない |
Batch APIドキュメント は目標完了時間を24時間以内と説明します。夜間分類、評価、backfill、オフライン補完には適します。画面内の即答、同期審査、直後に後続処理を起動するリクエストを半額だけのためにBatchへ移しません。
Flexも「オンにすれば常に半額」のスイッチではありません。正確なモデル、地域、現在のサポートを確認し、業務が実行特性を許容するか判断します。UXが安定した同期チェーンへ依存するならStandard基準を維持し、本当に弾力実行できる負荷だけを移します。
コンテキストキャッシュは、同じマニュアル、コードスナップショット、規約コーパス、マルチモーダル背景などの長い接頭辞を何度も送る場合に向きます。キャッシュ概要 はimplicitとexplicitを分け、明示的キャッシュガイド はTTLと保存を説明します。キャッシュヒットしても、cache read、storage、未キャッシュ入力、出力は残ります。
作成前に 接頭辞サイズ × 再利用回数 × TTL を見積もります。数回しか使わない、または毎回大きく変わる文脈では、管理・保存費が節約を上回ります。数千件が同じ大きな文脈を読むときに初めて大きな効果が期待できます。cache readの割引率を総請求の削減率として書かないでください。
監査しやすい順序は、Standardを測る、待てる負荷を対応Batch/Flexへ移す、反復接頭辞のキャッシュを別計算する、失敗が測れたときだけモデルを上げる、です。一度に四つ変えると、請求が下がっても原因が分からず、品質やレイテンシの問題も切り分けられません。
比較すべきは「合格結果あたりコスト」
安いモデルが頻繁に失敗すれば、最終的には安くありません。Token費用はログと料金表で算出できます。失敗費用は業務側で定義し、再呼び出し、別モデルへのfallback、JSON修復、手動審査、サポート対応、誤った後続処理の取り消しなどを含めます。
production既定を選ぶ前に代表タスクを用意します。通常入力、長い・汚れた入力、多言語、厳格なJSON/schema、安全境界、実際の最大出力を含めます。実行前に合格条件を書き、数件の印象的な回答で安定性の欠陥を隠さないようにします。
| 測る項目 | 記録する内容 | 「最安」が変わる理由 |
|---|---|---|
| タスク合格率 | 必須事実・フィールド・指示を満たしたか | 抽象的な品質を自分の負荷へ変換する |
| 再試行率 | 合格まで何回呼び出したか | Tokenとレイテンシを直接増やす |
| 修正率 | parse、schema recovery、手修正 | API外の工数を費用へ戻す |
| 出力量 | 中央値と上位パーセンタイル | 平均に隠れた高価な長い尾を示す |
| レイテンシ・timeout | end-to-end挙動 | Standard、Batch、Flexの適否を決める |
| 失敗の影響 | 審査時間、サポート、後続損失 | 上位モデルに払える差額を決める |
100,000回の例で、2.5 Flash-Liteは3.1 Flash-Liteより月$34安価です。しかし低価格モデルが追加で500件の手修正を生み、1件1分かかるなら、Token差は主要コストではない可能性があります。逆に決定的な抽出で両者の合格率が同じなら、高いモデルへ払う測定可能な価値はありません。
昇格ルールを先に決めます。Liteが目標合格率を満たし、再試行、修正、レイテンシが予算内なら維持します。安定版Flashが減らす総失敗費用が追加API費用を超える場合だけ切り替えます。モデル、prompt、schema、トラフィック構成が大きく変わったら同じセットを再実行します。
一度のA/Bを永久ランキングにしません。モデル、価格、業務データは変化し、代表タスクも古くなります。サンプル、判定基準、正確なmodel ID、実行日、Token統計を保存すれば、次の変更時に再計算でき、「どれが強いか」をゼロから議論せずに済みます。
Gemini 2.0の古い予算を移行する
2026年6月1日の停止後、Gemini 2.0の価格は実行可能なproduction選択肢を表しません。古い表計算では安く見えても、リクエスト先は廃止IDです。移行では呼び出し経路と予算仮定を同時に更新します。
- コード、環境変数、proxy設定、評価fixture、fallback一覧、監視画面からGemini 2.0 Flash / Flash-Lite IDを検索する。
- 旧Flash-Lite負荷を現在の3.1 Flash-Lite候補へ、旧Flash負荷を現行の安定版Flash候補へ対応させ、モデル一覧で正確なIDを確認する。
- 入出力modalityを再確認する。
gemini-3.1-flash-liteはテキスト出力であり、画像生成は別モデル・別料金である。 - 代表タスクを再評価する。後継IDが完全に同じ出力挙動を保証するわけではない。
- 限定トラフィックで入力、出力、再試行、エラー、レイテンシ、実行モードを記録する。
- 廃止モデル金額へ割合を足すのではなく、現行料金行で予算を作り直す。
fallback設定は特に見落とされます。主経路だけ更新され、障害時に廃止モデルへ戻ると、局所障害が連続失敗へ変わります。古いRPM、TPM、日次上限表も削除しないと、現在のプロジェクト状態を誤診します。
移行完了は、新IDで一度回答が返ることではありません。主経路とfallbackが現行ID、タスクセットが合格、ログがTokenとエラーを説明、予算が現行価格、容量アラートが現在のプロジェクトを見る、という全条件を満たした状態です。
4段階の小規模テストで予算を確定する
第1段階：実負荷を記録する。 月間呼び出し数、入力・出力の中央値と上位パーセンタイル、反復接頭辞サイズ、レイテンシ期限、待てる処理の割合を集めます。一つの短いpromptを製品全体の代表にしません。
第2段階：Standard基準を計算する。 2.5 Flash-Liteと3.1 Flash-Liteを同時に計算し、ツール、Grounding、cache storage、再試行、税を別列にします。別のエンジニアがログと公式料金だけで同じ結果を再計算できる状態にします。
第3段階：同じタスクで受け入れテストを行う。 合格率、再試行、修正、出力量、レイテンシを記録します。両方のLiteが基準未達なら、一つの安定版Flash候補を追加します。高い価格だけで改善を仮定しません。
第4段階：条件ごとにトラフィックを分ける。 対話経路はStandard、待てる処理は対応Batch/Flex、反復する長い接頭辞はexplicit cacheを試し、測定された失敗だけがモデル昇格を起動します。試験上限を増やす前に、モデル状態と料金をもう一度確認します。
成果物はモデル名だけではありません。どの負荷がどの実行モードへ行くか、割引最適化を止める位置、昇格の閾値、請求とクォータの担当、価格変更時の再計算手順を残します。これでコスト管理は一度きりの最安ランキングではなく、運用可能な仕組みになります。
よくある質問
現在もっとも安いGemini Flash APIのテキストモデルは？
2026年7月14日時点で、ここで比較するFlash-familyテキストモデルのStandard最安行は gemini-2.5-flash-lite です。入力100万Tokenあたり$0.10、出力$0.40です。価格行の最安であり、すべてのタスクに最適という意味ではありません。
新規開発は2.5と3.1 Flash-Liteのどちらから始める？
同じタスクセットで両方を試します。2.5 Flash-Liteは単価が安く、3.1 Flash-Liteは新世代の安定した低コスト候補です。同じタスク・出力・レイテンシ条件を満たす側の合計費用で選びます。
Gemini Flashは1回いくら？
平均入力Token×入力単価と、平均出力Token×出力単価をそれぞれ100万で割って合計します。月額は呼び出し数を掛けます。再試行、ツール、Grounding、cache storage、税は別計算です。
Batchは常にStandardの半額？
確認日の対応料金行では50%ですが、Batchは非緊急の非同期処理向けで、完了目標は24時間以内です。正確なモデルの対応状況と業務の待ち時間を満たす場合だけ使います。
FlexとBatchは同じ？
同じではありません。両方に割引行があっても、実行条件と提供状況が異なります。モデル、地域、現在のサービス条件を確認し、対話経路はStandardを基準にします。
コンテキストキャッシュで請求全体が割引になる？
なりません。explicit cacheは適格な反復入力を安くできますが、cache read、保存期間、未キャッシュ入力、出力は課金対象です。再利用回数が十分で、storageが節約を打ち消さないときに有効です。
Gemini APIの無料枠は正確に何回？
全プロジェクト共通の固定数はありません。モデル、プロジェクト、tier、地域、現在のルールで変わります。Google AI Studioでライブ値を確認し、無料枠ガイド でアカウントとプロジェクトの境界を確認してください。
Gemini 3 Flash Previewをproduction既定にしてよい？
原則として勧めません。Previewはライフサイクルと動作変更リスクが高い状態です。新機能を試す理由がある場合のみ、安定版fallbackを用意して検証します。価格だけではproduction適性を判断できません。
Gemini 2.0 FlashとFlash-Liteはまだ使える？
使えません。Googleは両方を2026年6月1日停止としています。主モデル文字列だけでなく、呼び出し経路、評価、fallback ID、予算を同時に移行します。
3.1 Flash-LiteとFlash-Lite Imageは同じモデル？
同じではありません。gemini-3.1-flash-lite はマルチモーダル入力を受けますが、出力はテキストです。画像生成は別のmodel IDと料金契約なので、Flash-Lite Imageのコストガイド を参照してください。
