【検証】Gemini 3.5 Flash-Liteは大量処理に使える？翻訳・要約・分類を3ケースで試した

Forvio note

2026年7月23日 15:52

Gemini仕事術⑥ Gemini 3.5 Flash-Liteは大量処理に使える？翻訳・要約・分類を3ケースで検証

AIを業務に取り入れたものの、「件数が増えたら、料金はいくらになるのだろう」と不安に感じたことはありませんか。

翻訳、要約、分類。1件だけなら小さな処理でも、問い合わせやレビュー、アンケートを100件、1,000件と重ねれば、利用料も確認作業も積み上がっていきます。

そこで大切になるのが、すべての仕事に同じモデルを使わないという考え方です。

Googleは2026年7月21日、軽量モデル「Gemini 3.5 Flash-Lite」を発表しました。

3.5シリーズで最も高速・低コストのモデルとして、翻訳や文書処理、単純なデータ処理など、高いスループットが求められる用途を想定して設計されています。

本記事では、このFlash-Liteを「翻訳」「100字以内の要約」「顧客の声の分類」という3ケースで実際に試しました。見るのは速さだけではありません。どの仕事ならFlash-Liteで品質基準を満たし、どこから3.6 Flashへ切り替えるべきか。その判断基準までを検証します。

この記事が特に役立つ人

問い合わせやレビューを、数百〜数千件単位で分類している方
アンケートの自由記述を、毎月まとめて集計している方
商品説明やメールの翻訳件数が多いチーム
社内文書やニュースを、決まった文字数で要約したい方
生成AIの利用料を抑えたい情シス・業務改善のご担当者
Flash-Liteと3.6 Flashの使い分けに迷っている方

一方、月に数件しか処理しない場合は、数ドルの料金差よりも、使いやすさや確認の手間を優先したほうがよいこともあります。

結論：まずLiteで試し、基準を満たさない処理だけ上位モデルへ

先に結論です。

今回の3ケースでは、仕様が明確な翻訳・要約・分類について、Flash-Liteでも実用候補になる結果が得られました。

ただし「定型処理なら必ずFlash-Liteで十分」という意味ではありません。入力する文章、業界用語、求める精度によって結果は変わります。現実的な進め方は、次の順番です。

まずFlash-Liteで実行する
人がつくった正解データと突き合わせる
自社の精度基準を満たすかを確認する
満たさない処理だけ3.6 Flashへ切り替える

モデルを「賢い・賢くない」で分けるのではなく、必要な品質を満たすかどうかで選ぶ。これが今回のいちばんの学びです。

なお今回は、Flash-Liteの出力品質を確認しています。同一の入力を3.6 Flashにも通した比較は、次回の検証で追記します。

Gemini 3.5 Flash-Liteとは？

Gemini 3.5 Flash-Liteは、低遅延・高スループット・低コストのバランスを重視したモデルです。文書の解析や単純なデータ抽出、大量処理を想定して設計されています。

Google公式の発表では、Artificial Analysisの測定として、毎秒約350出力トークンという数値が示されています。ただしこれは出力生成部分のベンチマーク値であり、業務全体の待ち時間とは異なります。実際の体感は、入力の長さ、通信環境、混雑状況などによって変わります。

Gemini 3.6 Flashとの違い

料金はいずれもStandard APIの金額です。出力料金には思考トークンも含まれます。

1,000件処理した場合の料金試算

1件につき入力500トークン・出力200トークンを使うと仮定し、1,000件を処理した場合で比べます。

Gemini 3.5 Flash-Lite

入力：50万トークン × $0.30 ＝ $0.15
出力：20万トークン × $2.50 ＝ $0.50
合計：約 $0.65

Gemini 3.6 Flash

入力：50万トークン × $1.50 ＝ $0.75
出力：20万トークン × $7.50 ＝ $1.50
合計：約 $2.25

この条件では、Flash-Liteのほうが約71％安い計算になります。

ただしこれは、Google公式の単価と仮定したトークン数から求めた試算です。1,000件を実際に連続処理した速度テストではありません。実際の料金は、入力・出力・思考トークンの量や、利用する機能によって変わります。

急がない処理なら、Batch APIという選択肢

すぐに結果を返す必要がない処理には、Batch APIがあります。

Google公式ドキュメントによれば、Batch APIの料金は同じモデルのStandard料金の50％で、ジョブは24時間以内の完了を目安に設計されています。

先ほどと同じ条件なら、次のようになります。

夜間にアンケートをまとめて分類する、週末にレビューを一括で要約する、大量の商品説明をまとめて翻訳する。

翌朝までに終わればよい処理なら、Batchが有力な候補になります。

リアルタイムの応答が必要な場面ではStandard、急がない一括処理ではBatch、という使い分けです。

3ケースで検証

検証環境

検証日：2026年7月23日
使用モデル：Gemini 3.5 Flash-Lite
入力データ：料金改定のお知らせ文（翻訳）／記事本文（要約）／顧客の声8件（分類）
評価方法：あらかじめ人が用意した正解と突き合わせ

評価基準

翻訳：製品名・数字・日付・通貨・単位を維持できているか
要約：文字数の条件を守り、本文にない情報を足していないか
分類：正しく仕分けできたか、曖昧な項目を無理に断定していないか
形式：指定した出力形式で安定して返るか

今回確認したのは、この3ケースの出力品質です。1,000件規模の実負荷テストは行っていません。

ケース①：製品名・数字を維持した翻訳

料金改定のお知らせ文を、次のプロンプトで英訳しました。

以下の日本語を、ビジネス文書として自然な英語に翻訳してください。

ルール：
・製品名、固有名詞、数字、日付、金額、通貨、単位は変更しない
・通貨換算や単位変換をしない
・否定表現と条件を落とさない
・本文にない情報を追加しない
・訳文のみを出力する

【原文】
（ここに本文を貼る）

結果：崩れゼロ。 製品名「B-Cloud Standard」、金額「9,800円 → 12,000円」、日付「2026年9月1日」、営業時間「9時〜21時」を、いずれも原文どおりに反映しました。金額を勝手にドルへ換算することもなく、訳文だけが返っています。

出力（抜粋）：Effective September 1, 2026, we will revise the monthly subscription fee from 9,800 yen to 12,000 yen.

ひとつだけ、判断が分かれる挙動がありました。新機能名「AI議事録要約」が、日本語のまま英文に残ったのです。「固有名詞は変更しない」という指示に忠実な結果ではありますが、英語の読み手には意味が伝わりません。

訳語を決めている用語は、あらかじめ対訳をプロンプトに渡すのが確実です（例：「AI議事録要約 = AI Meeting Summary」）。

ケース②：100字以内の要約

文字数の条件を守れるかを確認しました。文字数はモデルの自己申告ではなく、出力後に別途数えて評価しています。

以下の文章を、日本語100字以内で要約してください。

ルール：
・本文に書かれている事実だけを使用する
・重要な数字と結論を優先する
・前置きや解説を付けない
・要約文のみを出力する

【本文】
（ここに本文を貼る）

結果：実測76字で、条件を遵守。 本文にない情報を足すこともありませんでした。

ただし、検証用に「最後に文字数を書く」と指示したところ、申告は「90字」。実際は76字で、14字のずれがありました。文字数の自己申告は当てにせず、外部で数える。これは実務でも押さえておきたい点です。

ケース③：顧客の声を分類

顧客の声8件を、6つのカテゴリに分類しました。

結果：明確な6件は全問正解。 配送・価格・サポート・使いやすさ・品質を、それぞれ根拠つきで正しく仕分けています。JSONのみが返り、8件すべてに番号がついていました。

[
  { "no": 1, "category": "配送", "reason": "届くまで1週間" },
  { "no": 2, "category": "価格", "reason": "2,000円ほど高い" },
  { "no": 4, "category": "使いやすさ", "reason": "画面のボタンが小さくて押しにくい" },
  { "no": 5, "category": "品質", "reason": "本体にヒビが入りました" },
  { "no": 7, "category": "サポート", "reason": "電話が全然つながりません" }
]

「電話がつながらない」をサポートへ入れるなど、言い回しが違っても意図をくんで仕分けできていました。境界にある2件（梱包の話、説明書と価格が混ざった意見）も、無理のない判断です。

一方で、境界のケースではreasonに原文をそのまま写す傾向がありました。根拠語句の抽出になっていないため、集計に使うなら書き方を指定したほうが安全です。

改良版のプロンプトは、複数の論点を含む意見に備えて項目を増やしています。

以下の【意見リスト】を分類してください。

カテゴリ：価格 / 品質 / 配送 / サポート / 使いやすさ / その他

出力はJSON配列のみとしてください。
[
  {
    "no": 1,
    "primary_category": "最も関連するカテゴリ",
    "secondary_category": "2つ目のカテゴリ。なければ空文字",
    "confidence": "high | medium | low",
    "reason": "判断の根拠となる語句（原文の引き写しではなく該当箇所のみ）",
    "needs_review": true または false
  }
]

ルール：
・書かれていない内容を推測しない
・複数の問題を含む場合は secondary_category を使う
・判断が分かれる場合は confidence を下げ、needs_review=true にする
・どのカテゴリにも当てはまらない場合は「その他」にする

【意見リスト】
（ここに番号つきで貼る）

必ずどれかひとつに決めさせるのではなく、「要確認」という逃げ道を用意する。これが、分類を実務で使うときのコツです。

どう使い分ける？

モデル選びで大切なのは「簡単そうな仕事かどうか」ではなく、自社の品質基準を満たすかどうかです。

Flash-Liteから始めやすい処理

カテゴリが決まっている分類
定型文の翻訳
文字数が決まっている要約
問い合わせの振り分け、商品属性の抽出

3.6 Flashへ切り替える候補

文脈によって答えが変わる
長い文章の全体を踏まえる必要がある
下書きに高い文章品質が求められる
Flash-Liteでは精度基準を下回った
人の修正が多く、かえって工数が増えた

すべてを上位モデルに任せる必要はありません。たとえば、全件をFlash-Liteで処理し、confidenceが低いものだけ3.6 Flashへ送り、最後に人が確認する。この組み立てなら、コストを抑えながら難しいデータの品質を上げられます。

精度を上げる4つのコツ

正解データを先につくる：20〜30件を人が処理し、比較の基準にします
「その他」と「要確認」を用意する：必ずどれかを選ばせると、無理な分類が増えます
制約は測定できる形に：「短く」ではなく「100字以内」。「自然に」ではなく「数字と否定表現を維持」
モデルの自己評価だけを信じない：文字数やconfidenceは、人が確認する優先順位の目安として扱います

導入手順

大量に発生している定型処理をひとつ選ぶ
人が20〜30件の正解データをつくる
同じ入力をFlash-Liteと3.6 Flashに渡す
正答率・修正量・料金を比べる
Flash-Liteで足りる処理を決める
確信度が低いものや例外だけ、上位モデルへ送る
本番の前に、社内規程とデータの取り扱い条件を確認する

データの取り扱い

Gemini APIの無料枠では、入力内容がGoogle製品の改善に使用されると案内されています。有料枠では使用されないとされていますが、条件はサービス・プラン・契約によって異なります。

業務データを扱う際は、個人情報や機密情報を含まないか、利用中の契約プラン、データの保存・利用条件、社内のAI利用規程、匿名化の要否を、利用時点の公式情報とあわせてご確認ください。無料で使えることと、業務データを安全に入力できることは別の問題です。

こんな方におすすめ／おすすめしない

向いている方

数百〜数千件の同じ種類のデータを扱っている
品質の合格基準を決められる
出力を人が確認できる体制がある

おすすめしない方

月に数件しか処理しない
一件ごとの表現が結果を大きく左右する（法務・医療・広告コピーなど）
正解データをつくれない、人の確認を完全になくしたい

まとめ

Gemini 3.5 Flash-Liteは、最高性能だけを追うのではなく、低遅延・高スループット・低コストのバランスを重視したモデルです。

今回の記事でお伝えしたいのは、「Flash-Liteなら何でも安く処理できる」ということではありません。大切なのは、必要な品質を満たす、いちばん軽くて安いモデルを使うという考え方です。

まずFlash-Liteで試す。基準を満たさない処理や、確信度の低いデータだけを3.6 Flashへ送る。そして最後は人が確認する。この役割分担ができれば、品質を保ちながら利用料を抑えられます。

モデルの名前や料金がこの先変わっても、仕事に応じてモデルを振り分けるという考え方は、これからさらに重要になっていくはずです。

よくある質問

Q. 無料で試せますか？
A. Google AI StudioとGemini APIには無料枠があり、Geminiアプリからも利用できます。モデルを指定して同じ条件で比べたい場合は、Google AI Studioが分かりやすいです。

Q. 必ず約71％安くなりますか？
A. いいえ。71％は、1件につき入力500トークン・出力200トークンを1,000件処理するという仮定での試算です。実際の料金は、トークン量や利用する機能によって変わります。

Q. 大量処理なら、必ずFlash-Liteが適していますか？
A. 必ずではありません。大量処理でも、複雑な判断や高い文章品質が必要な場合は、3.6 Flashのほうが人の修正工数を減らせることがあります。API料金だけでなく、人が直す時間も含めて比べてください。

次に読む（Gemini仕事術シリーズ）

Gemini仕事術① Gemini 3.6 Flashは“仕事のどこ”に効くのか

Gemini仕事術② カスタマーサポートの問い合わせ対応

Gemini仕事術⑤ 職務経歴書をAIで一次整理

もっと体系的に学ぶなら（書籍）

①『AIを味方につける仕事術』

AIを使うこと自体ではなく、現場の課題を見つけ、データやAIを成果につなげるための「5Dフレームワーク」を扱っています。今回の記事の「安いモデルを選ぶ前に、目的・品質基準・確認方法を決める」という結論と相性が良いです。

②『図解まるわかり AIエージェントのしくみ』

生成AIとAPIの違い、Function Calling、MCP、AIエージェントの導入ロードマップ、PoCの評価軸などを図解で扱っています。Flash-Liteを単発利用で終わらせず、翻訳・要約・分類を業務フローに組み込みたい読者へ自然につなげられます。

出典

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/
Google AI for Developers「Gemini Developer API pricing」: https://ai.google.dev/gemini-api/docs/pricing
Google AI for Developers「Batch API」（Standard料金の50％／24時間以内の完了目安）: https://ai.google.dev/gemini-api/docs/batch-api