Gemini APIのThinkingとは｜使い方・料金・モデル対応表

「Gemini APIに複雑な数学の問題やコードの生成を頼むと、簡単な質問より妙に時間がかかることがある」「gemini-3.8-flashを使っているだけなのに、思ったより出力トークンの料金が多く請求される」——そう感じたことはないだろうか。

結論から言うと、Gemini 3系・2.5系のモデルには応答を生成する前に内部で推論を行う「思考(thinking)」という仕組みが備わっている。公式ドキュメントでは「The Gemini 3 and 2.5 series models use a “thinking process” that significantly improves their reasoning and multi-step planning abilities, making them highly effective for complex tasks such as coding, advanced mathematics, and data analysis」と説明されており、https://ai.google.dev/gemini-api/docs/thinkingで仕様が公開されている。この思考の量はthinking_levelというパラメータで調整でき、思考にかかったトークン(thinking tokens)は出力トークンと合算して課金される。

仮の例として、社内チャットボットに「今週の売上を一言で」と聞く場合と、「過去12週の売上データから異常値を挙げて原因を3つ推測して」と聞く場合を比べると、後者のような複雑な依頼のほうが内部の推論量、つまり思考トークンが増えやすいと考えられる。

この記事では、思考の過程がどう返ってくるか(thought stepsの構造)から、thinking_summariesによる要約の有効化、thinking_levelでの制御方法、モデル別の対応状況、料金の考え方までを、公式ドキュメントの記載に沿って整理する。似た名前で大量の処理をまとめて割引価格で実行する仕組みについてはGemini Batch APIの使い方｜非同期処理と50%割引の料金で扱っているので、目的に応じて読み分けてほしい。

Gemini APIのThinking（思考）とは何か

Thinking（思考）とは、Gemini 3系・2.5系のモデルが応答を生成する前に内部で行う推論プロセスのことで、公式ドキュメントによるとコーディングや高度な数学、データ分析のような複雑なタスクで効果を発揮する仕組みである。

公式ドキュメントでは「When you use a thinking model, Gemini reasons internally before responding. The Interactions API surfaces this reasoning via thought steps, dedicated steps that appear chronologically alongside function calls, user inputs or model outputs in the steps array」と説明されている(https://ai.google.dev/gemini-api/docs/thinking)。つまりモデルの推論過程は、通常の応答や関数呼び出しと並んで、Interactions APIのstepsという配列の中に時系列で記録される。

同じページの注記では、思考の扱いはgenerateContent APIとInteractions APIで異なり、generateContent APIには専用のthoughtブロックが無くsignatureが任意のpartに付与される一方、Interactions APIでは思考が専用のthought stepとして扱われると説明されている(https://ai.google.dev/gemini-api/docs/thinking)。どちらのAPIを使っているかで、思考データの受け取り方が変わる点は覚えておきたい。

仮の例として、gemini-3.8-flashに「複雑な物流最適化の手順を3パターン考えて」と依頼した場合、モデルは内部でいくつかの候補を検討したうえで最終的な3パターンを出力すると考えられ、その検討過程がthought stepとしてstepsに記録される。

思考の過程はどう返ってくるか｜thought stepsのsignatureとsummary

thought stepのsignatureとsummaryとは、それぞれモデルの内部推論状態を暗号化した情報と、その推論を要約した文章や画像のことで、公式ドキュメントではsignatureは常に付与され、summaryは設定や状況によって空になる場合があると説明されている。

公式ドキュメントでは「Every thought step contains two fields」としたうえで、2つのフィールドの内容を次のように説明している(https://ai.google.dev/gemini-api/docs/thinking)。

signatureが常に付いてくる一方でsummaryは条件次第で空になるという非対称な仕組みになっているため、アプリ側のコードはsummaryが空または存在しないケースを前提に組んでおく必要がある。

thinking_summariesで思考の要約を有効にする方法

thinking_summariesとは、モデルの内部推論の要約(summary)をレスポンスに含めるかどうかを切り替える生成設定のことで、公式ドキュメントによると既定では最終的な出力のみが返される。

公式ドキュメントでは「By default, only the final output is returned. You can enable thought summaries with thinking_summaries」と説明されている(https://ai.google.dev/gemini-api/docs/thinking)。Python SDKでの最小例は次のようになる。

from google import genai

client = genai.Client()

interaction = client.interactions.create(
    model="gemini-3.8-flash",
    input="What is the sum of the first 50 prime numbers?",
    generation_config={
        "thinking_summaries": "auto"
    }
)

for step in interaction.steps:
    if step.type == "thought":
        print("Thought summary:", step.summary)
    elif step.type == "model_output":
        print("Answer:", step.content)

公式ドキュメントでは、summaryが空になりうる条件として「Simple requests, where the model didn’t reason enough to generate a summary」「thinking_summaries: “none”, where summaries are explicitly disabled」「Certain thought content types, such as images, may not have text summaries」の3つを挙げている(https://ai.google.dev/gemini-api/docs/thinking)。同ページでは、この3条件を受けて「Your code should always handle thought blocks where summary is empty or absent」と、summaryが空または存在しない前提でコードを組むよう案内されている。

ストリーミングで思考の要約を受け取る仕組み

ストリーミングでの思考取得とは、生成の途中経過として思考の要約を段階的に受け取る仕組みのことで、公式ドキュメントによるとSSE(Server-Sent Events)で2種類のdeltaが送られてくる。

公式ドキュメントでは「Thought blocks are delivered using Server-Sent Events (SSE) with two distinct delta types」としたうえで、次の2種類のdeltaを説明している(https://ai.google.dev/gemini-api/docs/thinking)。

ストリーミングのレスポンスはstep.start・step.delta・step.stopといったイベントの連なりとして届く。公式ドキュメントに掲載されている例では、思考のstepがthought_signatureのdeltaを送ってからstep.stopで終わり、続くmodel_outputのstepでテキストのdeltaが順に届く流れになっている(https://ai.google.dev/gemini-api/docs/thinking)。仮の例として、チャットUIで「考え中…」という表示を出したい場合は、最初のthought_summaryのdeltaを受け取った時点でその表示に切り替え、model_outputのテキストdeltaが来たら回答本文の表示に切り替える、という実装になる。

thinking_levelで思考の量を制御する

thinking_levelとは、モデルが応答生成にどれだけ推論の労力をかけるかを指定するパラメータのことで、公式ドキュメントによるとモデルは既定でリクエストの複雑さに応じて自動調整するdynamic thinkingを行う。

公式ドキュメントでは「Gemini models engage in dynamic thinking by default, automatically adjusting the amount of reasoning effort based on the complexity of the request. You can control this behavior using the thinking_level parameter」と説明されている(https://ai.google.dev/gemini-api/docs/thinking)。thinking_levelにはminimal・low・medium・highがあり、対応する値はモデルによって異なる。指定する場合のコード例は次のようになる。

from google import genai

client = genai.Client()

interaction = client.interactions.create(
    model="gemini-3.8-flash",
    input="Provide a list of 3 famous physicists and their key contributions",
    generation_config={
        "thinking_level": "low"
    }
)
print(interaction.output_text)

既定のdynamic thinkingに任せた場合、単純な質問には短く、複雑な質問には長く推論してくれることが期待できるが、レイテンシや料金をコントロールしたい場面ではthinking_levelを明示的に指定したほうが挙動を予測しやすい。

モデル別のデフォルト設定と対応レベル一覧

モデル別の対応状況とは、各Geminiモデルがthinking_levelの既定でどのレベルの思考を行い、どのレベルを選べるかを示した公式ドキュメントの一覧のことである。

公式ドキュメントの一覧表には、思考に対応する13モデルのDefault Thinking(既定の思考レベル)とLevels Supported(選択可能なレベル)が示されている(https://ai.google.dev/gemini-api/docs/thinking)。最新のFlashモデルであるgemini-3.8-flashの特徴や旧世代との違いはGemini 3.8 Flashとは？できること・制限・旧世代Flashとの違いで整理している。

この表を見ると、gemini-2.5-flash-liteだけがDefault Thinking「Off」になっている点が目に付く。既定では思考をオフにしつつ、thinking_levelを指定すれば低コストのFlash-Liteでもlow・medium・highの思考を後から有効化できる設計になっている。gemini-3.1-flash-lite-imageのようにminimalとhighの2段階しか選べないモデルもあり、対応レベルの幅はモデルごとに異なる。

max_output_tokensと思考トークンの関係

max_output_tokensとは、思考トークンを含めて1回の応答で生成できる最大トークン数を制限する生成パラメータのことで、公式ドキュメントによるとthinking_levelの割り当てとは別に働く固定の上限である。

公式ドキュメントでは「The max_output_tokens generation parameter sets the maximum number of tokens a response can generate, including thought tokens. When set, this parameter acts as a hard cutoff enforced by the infrastructure without changing how the model allocates its thinking budget (thinking_level)」と説明されている(https://ai.google.dev/gemini-api/docs/thinking)。つまりmax_output_tokensを小さくしても、モデルが割り当てる思考量そのものは変わらない。

そのうえで公式ドキュメントは「If the model hits this limit while reasoning, it stops generating with status “incomplete” and returns truncated or empty output (while still billing for any thinking tokens generated). To reduce cost or latency without truncating responses, lower thinking_level (low or medium) instead of setting a small max_output_tokens」と注意している(https://ai.google.dev/gemini-api/docs/thinking)。推論の途中で上限に達すると、ステータスが「incomplete」になり出力が途切れたり空になったりする一方、そこまでに生成した思考トークンの料金は発生したままになる。料金やレイテンシを抑えたい場合は、max_output_tokensを小さくするのではなくthinking_levelを下げるほうが、公式の推奨する方法になる。

Thought signatureの役割と多ターンでの扱い

Thought signatureとは、モデルの内部推論を暗号化して表現した情報のことで、公式ドキュメントによると複数ターンにわたる会話で推論の連続性を保つために必要とされる。

公式ドキュメントでは「Thought signatures are encrypted representations of the model’s internal reasoning. They are required to maintain reasoning continuity across multi-turn interactions」と説明されている(https://ai.google.dev/gemini-api/docs/thinking)。また同ページの注記では、Google Searchのような組み込みツールの呼び出し(google_search_call/google_search_result)にも、thought stepとは別のsignatureが付くことがあると説明されている。ツール呼び出しと組み合わせた使い方の詳細はGemini APIのFunction Calling入門｜仕組み・書き方・料金で扱っている。

仮の例として、旅行プランをGoogle Searchツールと組み合わせて多ターンで相談するような使い方では、1ターン目の思考結果とツール呼び出し結果のsignatureを、2ターン目以降も欠かさず保持しておく必要がある。次のStateful mode/Stateless modeの違いを理解しておくと、この保持作業を自分で書くべきかどうかが判断しやすくなる。

Stateful modeとStateless modeでの管理方法の違い

Stateful modeとStateless modeとは、Interactions APIで会話の履歴とthought signatureをどちら側(サーバーかクライアント)が管理するかを分ける2つの動作モードのことである。

公式ドキュメントでは、Stateful modeについて「By default, when you use the Interactions API in stateful mode (by setting store: true and passing the previous_interaction_id in subsequent turns), the server automatically manages the conversation state, including all thought blocks and signatures. In this mode, you do not need to do anything regarding signatures」と説明されている(https://ai.google.dev/gemini-api/docs/thinking)。一方Stateless modeについては「You MUST always resend all thought blocks exactly as they were received from the model. You should NOT remove or modify thought blocks from the history」と、履歴側で思考ブロックをそのまま保持し続けることを求めている。

公式ドキュメントは、Interactions APIの方がgenerateContent APIよりもsignatureの取り扱いがシンプルになっていると位置づけている。会話の履歴管理を自前で実装したくない場合は、Stateful modeを使ってサーバー側に任せる設計が基本になる。

料金の考え方｜出力トークンと思考トークンの合算

思考の料金とは、応答の生成にかかった出力トークンの料金と、内部推論にかかった思考トークンの料金を合算した金額のことで、公式ドキュメントによるとどちらも同じ出力単価で課金される。

公式ドキュメントでは「When thinking is turned on, response pricing is the sum of output tokens and thinking tokens. You can get the total number of generated thinking tokens from the total_thought_tokens field」と説明されている(https://ai.google.dev/gemini-api/docs/thinking)。さらに「Thinking models generate full thoughts to improve the quality of the final response, and then output summaries to provide insight into the thought process. Pricing is based on the full thought tokens the model needs to generate, despite only the summary being output from the API」とも説明されており、実際にAPIから返ってくる要約(summary)の長さではなく、モデルが生成した思考トークンの全量に対して課金される点は誤解しやすいポイントである。

料金ページでは、Gemini 3系・2.5系の各モデルの単価が「Output price (including thinking tokens)」という項目名で示されている(https://ai.google.dev/gemini-api/docs/pricing、2026年9月28日取得時点)。2026年9月時点の単価は次のとおりである。

料金ページでは、Gemini 2.5 Flashについて「Our first hybrid reasoning model which supports a 1M token context window and has thinking budgets」と紹介されている(https://ai.google.dev/gemini-api/docs/pricing)。モデル別の単価やキャッシュ料金、無料枠の範囲まで含めた料金全体の読み方はGemini API料金の読み方2026｜モデル別単価・キャッシュ・無料枠・試算で詳しく扱っている。なお同じ料金ページのBatchティアでも「Output price (including thinking tokens)」という項目名が使われており、標準ティアの単価をちょうど半額にした金額が示されている。大量の思考を必要とする処理を即時性にこだわらず流す場合は、Gemini Batch APIの使い方｜非同期処理と50%割引の料金で扱っているBatch APIに載せ替えることで、同じ思考トークンの料金を抑えられる余地がある。

仮の例として、gemini-3.8-flashで入力2,000トークン・出力(思考トークン含む)8,000トークンの処理を1,000回実行する場合、標準ティアの単価で計算すると入力側はおよそ$1.5、出力側はおよそ$30という規模になる計算だが、実際の請求額は料金ページの最新単価とキャッシュの利用状況によって変わるため、見積もりの参考程度にとどめてほしい。

思考レベルの選び方｜タスクの複雑さに応じた実践例

思考レベルの選び方とは、依頼するタスクの複雑さに応じてthinking_levelをどの値に設定するかという、公式ドキュメントが示すベストプラクティスの考え方のことである。

公式ドキュメントでは、思考モデルを効率的に使う方法として次のような指針を挙げている(https://ai.google.dev/gemini-api/docs/thinking)。

公式ドキュメントは、これに加えて「Review reasoning: Analyze thought summaries to understand failures and improve prompts」「Control thinking budget: Prompt the model to think less for lengthy outputs to save tokens」とも案内している。thinking_levelの値を変える以外に、プロンプト側で「手短に考えて」のように依頼して思考量を抑える調整方法もあるということになる。

Thinkingが関わる他のGemini API機能との関係

他機能との関係とは、Thinkingという推論の仕組みが単体の機能ではなく、Live APIのような他のGemini API機能の内部でも共通して使われている設計であることを指す。

リアルタイムの音声対話を扱うLive APIにも、Thinkingを取り入れたモデルがある。公式ドキュメントでは「Thinking in the Live API (gemini-3.8-live-extended-thinking) adds background reasoning to real-time voice sessions. The model plans and calls asynchronous tools in the background while speaking natural conversational fillers to keep the interaction active」と説明されている(https://ai.google.dev/gemini-api/docs/live-api/thinking)。音声のまま相手を待たせずに、裏側でツール呼び出しなどの推論を進められる設計になっている。Live APIの対応モデルや料金、セッション時間の上限についてはGemini Live APIとは｜対応モデル・料金・セッション制限で整理している。

先に紹介したベストプラクティスの「複雑なタスクには最大限の思考を」という考え方は、複数ステップの調査を行うGeminiのDeep Researchの使い方｜調査レポートの作り方と確認手順や、画面操作を1手ずつ判断するGemini Computer Useとは｜対応環境・安全機能・料金の考え方のような、いずれも多段階の判断を必要とするタスクにも当てはまる考え方である。ターミナルから対話的にGeminiモデルを呼び出すGemini CLIの使い方 インストールから無料枠の現状まで解説でも、内部では同じthinking_levelの仕組みが働いているモデルを呼び出すことになる。

よくある質問（FAQ）

Q1. thinking_levelにはどんな値を指定できますか？

公式ドキュメントによると、thinking_levelにはminimal・low・medium・highがあり、モデルごとに選べるレベルの範囲(Levels Supported)が異なります。たとえばgemini-3.8-flashはlow・medium・highの3段階、gemini-3.6-flashはminimal・low・medium・highの4段階に対応しています。

Q2. 思考にかかったトークンにも料金はかかりますか？

かかります。公式ドキュメントでは、思考をオンにした場合の料金は出力トークンと思考トークンの合計になり、料金ページでも各モデルの出力価格が「Output price (including thinking tokens)」として示されています。要約(summary)の長さではなく、モデルが生成した思考トークンの全量に対して課金される点に注意が必要です。

Q3. max_output_tokensを小さくすれば思考トークンの料金を減らせますか？

公式ドキュメントによると、max_output_tokensは思考トークンを含めた合計の上限を切る仕組みであり、モデルが割り当てる思考量そのものは変えません。上限に達すると応答が「incomplete」ステータスで途切れ、それまでの思考トークン分は課金されたままになります。料金やレイテンシを抑えたい場合は、thinking_levelをlowやmediumに下げる方法が公式に推奨されています。

Q4. 複数ターンのやり取りでthought signatureはどう扱えばいいですか？

Stateful mode(store: trueとprevious_interaction_idを使う方法)であれば、サーバー側がthought blockとsignatureを自動で管理するため、特別な処理は不要です。自分で会話履歴を管理するStateless modeの場合は、受け取ったthought blockを変更せずそのまま履歴に残し、次のターンでも再送する必要があります。

Q5. gemini-2.5-flash-liteでもThinkingは使えますか？

使えます。公式の一覧表では、gemini-2.5-flash-liteのDefault Thinkingは「Off」ですが、Levels Supportedにはlow・medium・highが挙げられており、thinking_levelを明示的に指定することで思考を有効化できます。

Q6. Live APIのようなリアルタイム対話でもThinkingは使えますか？

使えます。公式ドキュメントでは、gemini-3.8-live-extended-thinkingというモデルがLive APIに背景推論(background reasoning)を追加すると説明されており、音声で応答しながら裏側でツール呼び出しなどの推論を進める設計になっています。

まとめ

Gemini APIのThinkingは、Gemini 3系・2.5系のモデルが応答前に内部で行う推論の仕組みであり、thought stepのsignature・summary、thinking_summariesによる要約の有効化、thinking_levelによる思考量の制御という3つの要素で構成されている。料金は出力トークンと思考トークンの合計で決まり、max_output_tokensは思考量そのものを変えずに合計の上限だけを切る点、複数ターンではthought signatureをStateful modeかStateless modeのどちらで管理するかを決めておく必要がある点は、実装前に押さえておきたいポイントである。

まずは既定のdynamic thinkingのまま使ってみて、料金やレイテンシが気になる場面が出てきたら、タスクの複雑さに応じてthinking_levelを調整していくとよい。Thinking以外のGemini APIの使い方や活用事例の全体像についてはGoogle AIの使い方ガイドやGoogle AI活用事例を目的別に整理｜仕事・学習・SNS運用で使う方法も参考にしてほしい。