【比較】Gemini 3.5 Flash-Liteと3.6 Flashはどう使い分ける？同じデータで精度と料金を検証
前回の記事では、軽量モデル「Gemini 3.5 Flash-Lite」で翻訳・要約・分類を検証し、「定型処理なら実用候補になる」という結果をお伝えしました。
ただ、そこでひとつ宿題が残っていました。
同じデータを上位のGemini 3.6 Flashに渡したら、結果はどう変わるのか。
比較していない以上、「どちらをどの業務で使うべきか」には答えきれていません。
そこで今回は、前回とまったく同じ3つの入力（翻訳・要約・分類）を、Flash-Liteと3.6 Flashの両方で実行し、精度・出力の質・料金を並べて比較します。
この記事が特に役立つ人
Flash-Liteと3.6 Flashの使い分けに迷っている方
大量の定型処理（分類・翻訳・要約）のコストを抑えたい方
「安いモデルで品質が落ちないか」を判断したい情シス・業務改善のご担当者
結論・比較結果
先に結果の一覧です。
今回もっとも興味深かったのは、上位モデルのGemini 3.6 Flashに切り替えても、翻訳・要約・分類の品質がほとんど変わらなかったことです。
固有名詞や数字を維持した翻訳、100字以内の要約、明確な顧客意見の分類は、どちらのモデルも同じ水準で処理できました。さらに、文字数の自己申告がずれる点や、複数の意味を含む意見では判断が分かれる点も共通しています。つまり、今回のような定型処理では、上位モデルに変えれば弱点まで解消されるわけではありませんでした。
一方、1,000件処理した場合の料金試算は、Flash-Liteが約0.65ドル、3.6 Flashが約2.25ドルです。品質と人が確認する手間がほぼ同じにもかかわらず、Flash-Liteは約71％安くなります。
今回の結果から分かったのは、モデルは「上位だから選ぶ」のではなく、必要な品質を満たす最も軽いモデルを選ぶべきだということです。翻訳・要約・分類のように条件を明確にできる処理なら、まずFlash-Liteを使い、判断が難しいデータだけを人や上位モデルへ回す運用が、最も合理的だと考えられます。
結論
今回の3ケースは品質差なし（境界1件の判断が割れたのみ・どちらも妥当）。この種の定型処理は、料金が約71％安いFlash-Liteで十分です。
なお、今回も小規模な品質比較と料金試算です。100〜1,000件を連続処理する実負荷テスト（処理時間・エラー率・実際の請求額）は行っていません。この点は今後の検証課題です。
検証の設計：条件は完全に同一
比較で大事なのは条件をそろえることです。今回は次をそろえました。
入力：前回と同じ3つ（料金改定のお知らせ文／記事本文／顧客の声8件）
プロンプト：前回と同じ文面（改良版ではなく、あえて同一の原文プロンプト）
評価：文字数は外部で計測、分類は事前に用意した正解と突き合わせ
実行環境：Google AI Studio でモデルだけを切り替え
料金の前提（Gemini APIの公式料金ページ・2026年7月23日時点）：
入力（100万トークン） 出力（100万トークン） Gemini 3.5 Flash-Lite $0.30 $2.50 Gemini 3.6 Flash $1.50 $7.50
ケース①：翻訳（固有名詞・数字・日付）
Flash-Lite（前回実測）：製品名「B-Cloud Standard」、金額「9,800円→12,000円」（ドル換算せず）、日付「2026年9月1日」、営業時間「9時〜21時」をすべて維持。訳文のみを出力。唯一、対訳を指定しなかった新機能名「AI議事録要約」が日本語のまま残りました。
3.6 Flash（今回実測）：こちらも崩れゼロ。固有名詞・金額（円のまま）・日付・営業時間をすべて維持し、訳文のみを出力しました。訳文もLiteとほぼ同一で、違いは "the monthly subscription fee" が "our monthly subscription fee" になった程度。品質差は実質ありません。
出力（抜粋）：Effective September 1, 2026, we will revise our monthly subscription fee from 9,800 yen to 12,000 yen.
注目していた「AI議事録要約」の扱いは——3.6 Flashも日本語のまま残しました。上位モデルなら文脈で訳すかと思いきや、同じ挙動です。つまりこれはモデルの能力差ではなく、「製品名・数字・日付は原文のまま変更しない」という指示に両モデルが忠実だった結果。訳語を決めたい用語は、モデルに関係なく対訳リストで渡す必要がある——この学びが、比較によって「Liteの弱点」から「共通の仕様」へ格上げされました。
この翻訳タスクの判定：品質同等。であれば、料金が約5分の1のLiteで十分です。
ケース②：要約（100字以内・外部計測）
Flash-Lite（前回実測）：実測76字で条件を遵守。本文にない情報の補完もなし。ただし自己申告の字数は「90字」で、実際と14字のずれがありました。
3.6 Flash（今回実測）：実測73字で条件を遵守。本文にない情報の補完もなく、原文の「設計」というキーワードを押さえた要約でした。要約の質は、両モデルとも重要点（任せる業務の選定＋人の確認工程）を外しておらず、実用上の差はほぼありません。
出力：「生成AIの導入で成果を出すには、すべての業務に広げるのではなく、定型業務などAIに適した作業を選んで任せ、人が確認する工程を残す設計が重要である。（79字）」
そして注目の字数の自己申告。3.6 Flashの申告は「79字」でしたが、実測は73字——6字のずれです。Liteの14字ずれより小さいものの、上位モデルでも正確ではありませんでした。つまり「字数の自己申告がずれる」のはLite固有の弱点ではなく、モデル共通の癖。文字数が厳密に効く用途では、モデルを問わず外部で数える必要があります。
この要約タスクの判定：品質同等（自己申告のズレも共通）。Liteで十分です。
ケース③：分類（顧客の声8件）
Flash-Lite（前回実測）：明確な6件は全問正解。境界の2件（梱包の話、説明書と価格が混ざった意見）も妥当な判断。JSONのみで8件返却。弱点は、境界ケースで根拠（reason）に原文をそのまま写す傾向でした。
3.6 Flash（今回実測）：明確な6件は全問正解で、Liteと完全に同じ仕分けでした。JSONのみで8件返り、形式も安定しています。
[
{ "no": 6, "category": "配送", "reason": "梱包の段ボールがきれいで" },
{ "no": 8, "category": "価格", "reason": "値段を考えれば納得" }
]
境界の2件が興味深い結果でした。no.6（梱包）は両モデルとも「配送」で一致。一方、no.8（説明書が分かりにくいが、値段には納得）は、Liteが「その他」、3.6 Flashが「価格」と判断が割れました。どちらも間違いとは言えません——この意見には「使いやすさ（説明書）」と「価格（納得）」の2つの論点が混ざっているからです。
ここから分かるのは、境界ケースはモデルを上げても安定しないということ。上位モデルに任せれば解決する問題ではなく、secondary_category や needs_review を用意して「人が最終判断する」設計（前回の改良版プロンプト）が正解だと、比較によって裏づけられました。
なお、reasonの書き方は3.6 Flashのほうがわずかに丁寧で、境界ケースでも原文の丸写しではなく「値段を考えれば納得」と語句を抽出していました。集計のしやすさでは3.6 Flashに小さな利点があります。
この分類タスクの判定：明確な項目は同等＝Liteで十分。境界はどちらのモデルでも人の確認が必要。
料金と総コストの考え方
仮に1件あたり入力500トークン・出力200トークンで1,000件を処理すると、公式料金（2026年7月23日時点）ベースの試算で Lite 約$0.65／3.6 Flash 約$2.25。さらに、急がない一括処理ならBatch API（Standard料金の50％・24時間以内の完了目安）で Lite 約$0.325 まで下がります。
ただし、実務のコストはAPI料金だけではありません。
＞ 総コスト ＝ API料金 ＋ 人が確認・修正する時間
もし3.6 Flashのほうが修正箇所が少ないなら、API料金の差額を人件費が逆転する可能性もあります。今回の検証では、各ケースで**「人が直すとしたら何か所か」**もあわせて記録します。
今回の3ケースでは、人が直すとしたら次のとおりでした。
Flash-Lite：1か所（翻訳の「AI議事録要約」に訳語を当てる）＋分類の境界1件の確認
3.6 Flash：1か所（同じく「AI議事録要約」）＋分類の境界1件の確認
修正量も同じでした。API料金が約71％安く、人の手間が変わらないなら、総コストの結論は明快です。
どう使い分けるか（今回の結果から）
今回の3タスクに関しては、結論は明快です。
仕様が明確な翻訳・要約・分類は、迷わずFlash-Liteでよい。 品質はすべて同等で、弱点（字数の自己申告ズレ・未指定用語の扱い）まで共通でした。この種の処理で3.6 Flashを使う差額は、品質ではなく"安心料"になってしまいます。
一方で、今回の比較で「上位モデルでも解決しないもの」もはっきりしました。境界ケースの判断です。 no.8はモデル間でも割れました。これはモデル選びではなく、needs_review を用意して人が裁く設計の問題です。
したがって、前回提案した型がそのまま最適解になります。
全件をFlash-Liteで処理する
確信度が低いもの・要確認のものだけを取り出す
それを3.6 Flashに再送する、または人が直接確認する
ただし1点、正直な注記を。今回の3タスクは「仕様が固まった定型処理」です。長文の文脈理解や、高い文章品質が要る下書きでは3.6 Flashが優位になる可能性が高く、それは①〜⑤の検証（すべて3.6 Flashで良好）と別枠で考えるべき領域です。
よくある質問
Q. どちらか一方だけ契約すればいいですか？
A. Gemini APIは同じAPIキーでモデルを切り替えられます。「契約を分ける」のではなく、処理ごとにモデル名を切り替えるイメージです。
Q. 実負荷（1,000件連続）の結果はいつ分かりますか？
A. 今回はスコープ外です。処理時間・エラー率・実際の請求額を測る実負荷テストは、今後の検証課題として予定しています。
Q. 業務データを入力しても大丈夫ですか？
A. データの保存や利用条件はサービス・プラン・契約で異なります。利用時点の公式規約と社内規程をご確認ください。
まとめ
同じデータで並べた結果、今回の3タスク（翻訳・要約・分類）は品質同等・修正量も同等・料金は約71％差でした。
モデル選びの原則は、「賢いほうを選ぶ」ではなく「必要な品質を満たす、いちばん軽いモデルを選ぶ」。今回のような定型処理では、その答えはFlash-Liteです。
そして、比較して初めて見えたことが2つあります。字数の自己申告ズレも、未指定用語をそのまま残す挙動もモデル共通だったこと。境界ケースの判断は上位モデルでも安定しないこと。つまり、品質を決めるのはモデルのグレードよりも、プロンプトの設計と、人が確認する工程でした。
このシリーズで積み上げてきた「AIは下ごしらえ、判断は人」という役割分担が、モデル比較でも変わらず結論になります。
次に読む（Gemini仕事術シリーズ）
Gemini仕事術⑥ Gemini 3.5 Flash-Liteは大量処理に使える？（前回・この記事の前提）
Gemini仕事術① Gemini 3.6 Flashは“仕事のどこ”に効くのか
もっと体系的に学ぶなら
Geminiを図解で体系的に学びたい方へ
『ビジュアル グーグルの最強AI Gemini活用術』は、Geminiの基本的な特徴や使い方を、図や画面イメージを交えながら整理したい方に向いている一冊です。
今回の記事ではFlash-Liteと3.6 Flashの違いを、翻訳・要約・分類という定型業務で比較しました。一方で、実際にGeminiを仕事へ取り入れるには、モデルの選び方だけでなく、どの機能をどの場面で使うのかという全体像も理解しておく必要があります。
Geminiをこれから使い始める方や、断片的に使ってきた知識を一度整理したい方は、基礎から活用方法まで見直す入口として参考にしてみてください。
SAP経験を活かしてキャリアを見直したい方へ
生成AIや自動化技術が広がるなかで、SAPをはじめとする業務システムの現場でも、AIをどのように組み合わせて業務を改善するかという視点が重要になっています。
今回の記事のようなモデル選定やコスト設計の知識を、現在のSAP経験と組み合わせてキャリアに活かしたい方は、SAP分野に特化した転職サービスを利用する方法もあります。
「SAPテンショク」は、SAP案件や職種に特化した転職エージェントです。これまでのSAP経験やスキルを整理しながら、次のキャリアや求人について相談したい方は、選択肢のひとつとして確認してみてください。
出典
Google AI for Developers「Gemini Developer API pricing」（2026年7月23日時点）: https://ai.google.dev/gemini-api/docs/pricing
Google AI for Developers「Batch API」: https://ai.google.dev/gemini-api/docs/batch-api
Google公式ブログ「Introducing Gemini 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash Cyber」: https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-6-flash-3-5-flash-lite-3-5-flash-cyber/