Gemini APIのthinking levelは下げよう：分類タスクならminimalで十分

結論

Gemini API（Gemini 3.5 Flash）で分類タスクを実装するなら、thinking levelはminimalに設定しましょう。私が試した3つの分類実験では、minimalでも精度を落とさずに、実験1では出力トークンが約38分の1（1問あたり1,064→28トークン）に減りました。何も設定しないとデフォルトのmediumになるので、明示的な指定が必要です。

目次

• はじめに
• Gemini API（Gemini 3.5 Flash）のthinking levelとは
• Gemini 3.5 Flashの料金とトークン単価
• 実験1：シンプルな分類
• 実験2：意図的に紛らわしくした分類
• 実験3：件数を増やした3値分類
• thinking levelごとの料金比較
• 実装時の注意点
• まとめ

はじめに

こんにちは、グループ研究開発本部 AI研究開発室のT.N.です。

いま関わっているプロジェクトで、Geminiに分類タスクをやらせる場面が多いです。分類のような単純作業なら、モデルにじっくり考えさせる必要はないはずなので、コストと速度を優先してthinking levelを下げたいと考えていました。ただ下げすぎて精度が使えないレベルまで落ちると本末転倒です。そこで実際にどこまで下げられるのか、手元で試してみました。

ただし、実際のデータや実験内容は詳しく書けない点はご了承ください。

Gemini API（Gemini 3.5 Flash）のthinking levelとは

Gemini 2.5以降のモデルは、回答を出す前に内部で推論する「thinking」の仕組みを持っています。Gemini 2.5のテクニカルレポートによると、thinkingモデルは強化学習によって、推論時に追加の計算を使って精度を上げるように訓練されています。

この思考で生成されたトークンは、出力には含まれませんが課金の対象になります。thinkingはデフォルトで有効で、リクエストの複雑さに応じて推論の量が自動で調整されます。推論の中身は要約として確認できるだけで、内部の詳細は公開されていません。

そのうえでGeminiには「どれだけ深く考えるか」の目安を指定するthinking levelという設定があります。Gemini 3.5 Flashの場合、high、medium、low、minimalの4段階が用意されています。このうちminimalは最も思考量の少ない設定で、私が試した範囲では思考トークンは0でした。深く考えさせるほど消費トークン数が増え、コストと応答時間も伸びます。

公式ドキュメントには次のような目安が書かれています。

• 単純なタスク（事実の取得や分類）には最小限の思考、または低い思考を使う
• 中程度のタスク（概念の比較や創造的な推論）にはデフォルトの思考を使う
• 複雑なタスク（高度なコーディングや数学、複数ステップの計画）には最大思考を使う

分類タスクは低いthinking levelで十分、という方向性は書かれているものの、具体的にどこまで精度が保たれるかという定量的な報告は見つかりませんでした。なので自分で調べることにしました。

Gemini 3.5 Flashの料金とトークン単価

Gemini APIの料金は、トークン数に応じて決まります。2026年9月時点のGemini 3.5 Flash（有料枠）の100万トークンあたりの単価は次のとおりです（公式の料金ページ）。

処理方式	入力	出力
Standard	$1.50（約225円）	$9.00（約1,350円）
Batch / Flex	$0.75（約113円）	$4.50（約675円）

Batchは大量のリクエストをまとめて非同期で処理する方式（結果は最大24時間以内）、Flexは優先度を下げて処理する方式で、どちらもStandardの半額です（Batch APIの公式ドキュメント）。すぐに結果が要らない分類なら、minimalとBatchを組み合わせると安くなります。

円は1ドル150円で換算しています。思考トークンは画面に出てこないものの、出力トークンとして課金されます。つまりthinking levelを上げるほど、出力側の料金が増えます。

実験1：シンプルな分類

以下の実験はすべて2026年9月に行い、temperatureを0に設定しています。また、表のトークン数は思考トークンと出力トークンの合計で、入力トークンは含んでいません。

Claude Opus 5でダミーデータを作成し、全20問を用意しました。平均20個の選択肢の中から最大3個まで分類する形式で、正解は1個のみです。全てGemini 3.5 Flashで実行しました。

level	平均時間	平均トークン数	recall
minimal	920 ms	28	20/20 (100%)
low	1,160 ms	88	20/20 (100%)
medium	5,258 ms	1,064	20/20 (100%)
high	6,450 ms	1,383	20/20 (100%)

全てのthinking levelで全問正解してしまいました。このタスクが簡単すぎたということなので、もっと難しくして再実験しました。

実験2：意図的に紛らわしくした分類

実験2でもGemini 3.5 Flashをtemperature 0で使い、実験1より難しい問題を用意しました。具体的には次のような工夫を入れています。

• 入力に曖昧な表現を混ぜる
• 正解が複数ある問題を混ぜる
• どちらに分類されるか紛らわしい問題を混ぜる
• 分類先に正解がない問題を混ぜる

単純なrecallだけでなく、必ず含めて欲しい分類先を選べているか、明らかに異なる分類先を選んでいないか、という2点を合否の基準にしました。全10問です。今回はデフォルトのmediumと、最も軽いminimalの2つに絞って比べました。

level	平均時間	平均トークン数	合格
medium	7,480 ms	1,333	7/10
minimal	1,231 ms	34	9/10

速く安いだけでなく、minimalの方が合格数も多かったです。thinking levelを上げるほど賢く分類してくれるだろうという予想は外れました。考えすぎるとかえって精度が下がる場合もあるようです。

実験3：件数を増やした3値分類

実験3でもGemini 3.5 Flashをtemperature 0で使い、Claude Opus 5で作った300問のダミーデータで3値分類を試しました。

level	平均時間	平均トークン数	精度
minimal	74 ms	14.8	100% (300/300)
low	79 ms	17.2	100% (300/300)
medium	178 ms	39.8	100% (300/300)

ここでは精度に差が出ず、全レベルで100%でした。それでいてminimalはmediumの半分以下の時間とトークン数で済んでいます。精度を落とさずにコストと速度だけ削れるなら、下げない理由がありません。

thinking levelごとの料金比較

実験1の平均トークン数（思考トークンと出力トークンの合計）をもとに、Standardの出力単価で1万件を分類したときの出力側の料金を計算しました。入力側の料金はプロンプトの長さで決まり、thinking levelによって変わらないので含めていません。入力側のトークン数については、PDF入力のトークン数をClaude・ChatGPT・Geminiで比較した記事で詳しく扱っています。

level	平均トークン数	1万件あたりの出力料金
minimal	28	約$2.5（約380円）
low	88	約$7.9（約1,200円）
medium	1,064	約$96（約14,000円）
high	1,383	約$124（約19,000円）

デフォルトのmediumのまま使うと、minimalの約38倍の出力料金を払うことになります。料金は改定されることがあるので、実際に見積もるときは公式の料金ページで最新の単価を確認してください。

実装時の注意点

thinking levelはVertex AI SDKでは変更できない

thinking levelはGoogle Gen AI SDK側の設定です。Vertex AI SDKのthinking budgetの設定方法では、Gemini 3.5 Flashのthinking levelを変更できませんでした。

thinking levelの指定方法

Google Gen AI SDKでは、GenerateContentConfigのthinking_configでthinking levelを指定します（Gen AI SDKでのthinking設定）。minimalにする場合はThinkingLevel.MINIMALを指定します。コード例は次の節にまとめています。

分類タスクは引数でJSON出力を指定するとよい

分類タスクでは、出力をJSON形式にさせると結果を扱いやすくなります。このときプロンプトで「JSONで出力して」と頼むのではなく、APIの引数で指定できます。Google Gen AI SDKでは、response_mime_typeにapplication/jsonを、response_schemaに出力の型を渡します（Gen AI SDKでの構造化出力）。

thinking levelをminimalにしたうえで、選択肢から最大3個まで選ばせる分類をJSONで受け取るなら、次のように書きます。

import json

from google import genai
from google.genai import types

response_schema = {
    "type": "OBJECT",
    "properties": {
        "labels": {"type": "ARRAY", "items": {"type": "STRING"}},
    },
    "required": ["labels"],
}

client = genai.Client()
response = client.models.generate_content(
    model="gemini-3.5-flash",
    contents="次のテキストを、選択肢の中から最大3個まで分類してください。\n選択肢: ...\nテキスト: ...",
    config=types.GenerateContentConfig(
        response_mime_type="application/json",
        response_schema=response_schema,
        thinking_config=types.ThinkingConfig(
            thinking_level=types.ThinkingLevel.MINIMAL
        ),
    ),
)
print(json.loads(response.text)["labels"])

東京リージョンで使えるモデルは限られる

Geminiはモデルによって東京リージョンに対応していないものがあります（Googleモデルのロケーション一覧）。対応しているのは3.5 Flash、2.5 Flash、2.5 Proです。ただし2.5系は2026年10月20日に廃止される予定です（モデルのバージョンとライフサイクル）。そのため、東京リージョンで使うなら実質的に3.5 Flashが選択肢になります。

東京リージョン対応でも処理が東京に閉じているとは限らない

マネージドサービスは、RAG Engineのように東京リージョンサポートと書かれていても、処理が全て東京リージョン内で完結しているとは限りません。

temperatureを0にしても回答が変わることがある

temperatureを0にしても、同じ入力に対して回答が異なる場合があります。今回の実験でも、同じ入力で回答が変わることがありました。

まとめ

3つの実験のどれでも、minimalにしても精度は落ちませんでした。一方で応答時間とトークン数は、minimalがmediumの数分の1で済んでいます。料金に換算すると、1万件の分類で出力側の料金はminimalが約2.5ドル、mediumが約96ドルです。

分類タスクではthinking levelを上げても精度が上がるとは限らないので、まずはminimalで試すのがおすすめです。デフォルトはmediumなので、設定を忘れると余計なコストを払い続けることになります。実装するときは明示的にminimalを指定しましょう。

ただし、今回の実験は問題数が少なく、ダミーデータでの検証です。結果は参考程度にとどめ、実際のタスクでは自分のデータで精度を確認してから採用してください。

最後に

グループ研究開発本部 AI研究開発室では、データサイエンティスト/機械学習エンジニアを募集しています。ビッグデータの解析業務などAI研究開発室にご興味を持って頂ける方がいらっしゃいましたら、ぜひ募集職種一覧からご応募をお願いします。皆さんのご応募をお待ちしています。一緒に勉強しながら楽しく働きたい方のご応募をお待ちしています。