AIFreeAPI Logo

Nano Banana 2のThinking level設定:MinimalとHighの使い分け

A
13 min readAI画像生成

まずはMinimalで作成し、条件の多い画像でHighを比較する。設定するAPI項目から、完成画像と追加費用の見方まで、混同しやすい点を整理します。

推論レベルの切り替えと完成画像、待ち時間、費用を表したイラスト

Nano Banana 2のThinking levelは、画像を生成する際の推論レベルを指定する設定です。現在のモデルIDは gemini-3.1-flash-image。モデル別のAPIガイドが示す対応値は minimalhigh で、既定値は minimal です。Minimalでも推論を一切しないとは限りません。モデル仕様画像生成ガイドで確認できます。

最初はMinimalで生成し、配置や文字、参照画像などの条件を満たせないときにHighを比較する、という進め方が使いやすいでしょう。Highを選べば必ず画質が上がる、あるいは一定時間だけ遅くなる、といった保証はありません。見るべきなのは、必要な画像が得られたか、作り直しが減ったか、そのために何秒といくらかかったかです。

以下は2026年9月8日に確認した公式資料に基づく設定と評価の手順です。速度や品質の実測結果を示すものではありません。

まず、どこで使っているかを確認する

「Thinking」という表示があっても、Geminiアプリの会話モードと画像APIの設定は同じものとは限りません。手元の環境を先に分けると、変更する場所が明確になります。

利用環境確認する項目注意点
Gemini APIのInteractionsgeneration_config.thinking_levelminimal または high を指定する
Gemini APIのgenerateContentgenerationConfig.thinkingConfig.thinkingLevel(REST)SDKではフィールド名が異なる
Google AI Studio選択中の画像モデルとThinking levelの項目表示項目は画面の状態に依存する。見つからない場合はAPIの設定と混同しない
Geminiアプリ利用中の画像機能とアプリ側の案内「思考モード」の選択だけで画像APIに high が送られるとは判断できない
外部サービスや独自UI対応モデル、推論設定の説明、送信内容Googleのパラメータがそのまま使えるかはサービスごとに確認する

AI Studioについては、日本語の導入記事にMinimal/Highの表示が紹介されています。ただし、手元の画面に同じ項目があることを確認したうえで操作してください。モデル名の古い記事にある preview 付きIDを、現在の安定版IDと取り違えないことも大切です。

InteractionsでHighを指定する

現在の画像生成ガイドは、Interactionsの generation_config 内で thinking_level を指定する例を掲載しています。RESTでは次のように送ります。APIキーを環境変数 GEMINI_API_KEY に設定済みであることを前提としたリクエスト例です。

bash
curl --fail-with-body \ "https://generativelanguage.googleapis.com/v1beta/interactions" \ -H "x-goog-api-key: ${GEMINI_API_KEY}" \ -H "Content-Type: application/json" \ --data '{ "model": "gemini-3.1-flash-image", "input": "架空の喫茶店のメニュー画像を作成。見出しは朝のセット。料理写真を左、価格を右に配置し、背景は白。", "generation_config": { "thinking_level": "high" } }' \ --output interaction.json

Minimalで比較する場合は、"high" だけを "minimal" に変更します。モデルや入力まで同時に変えると、結果の違いが推論レベルによるものなのか判断しにくくなります。SDKを使う場合も、Interactionsの設定オブジェクトは generation_config={"thinking_level": "high"} という形です。

この例で保存する interaction.json は、画像ファイルではなくAPIの応答です。公式ガイドで示される完成画像の参照先は interaction.output_image.data で、画像データはBase64形式です。次の順序で取り出します。

  1. 応答に完成画像が存在し、データが空でないことを確認する。
  2. 応答のMIMEタイプを確認し、対応する画像形式としてBase64を復号する。
  3. 復号したファイルが画像として開けることを確かめ、保存先やユーザーへの返却処理に渡す。

HTTP 200だけでは画像を取得できたとは判断できません。完成画像がなければ、テキストの応答やエラー内容を確認し、そのJSONを .png に改名して保存しないでください。

generateContentでは設定名も応答の構造も変わる

既存の実装が generateContent を呼んでいる場合は、そのAPIの形式を使います。Interactionsの generation_config をそのまま移しても、同じ設定にはなりません。generateContent用の公式ガイドでは、言語ごとに次の形が使われています。

実装Highを渡す場所
Python SDKtypes.GenerateContentConfig(thinking_config=types.ThinkingConfig(thinking_level="High"))
JavaScript SDKconfig.thinkingConfig.thinkingLevel
RESTgenerationConfig.thinkingConfig.thinkingLevel

RESTの本文は次の形になります。送信先は https://generativelanguage.googleapis.com/v1/models/gemini-3.1-flash-image:generateContent です。

json
{ "contents": [ { "parts": [ { "text": "架空の喫茶店のメニュー画像を作成。見出しは朝のセット。料理写真を左、価格を右に配置し、背景は白。" } ] } ], "generationConfig": { "responseModalities": ["IMAGE"], "thinkingConfig": { "thinkingLevel": "HIGH" } } }

generateContentの応答では、候補の content.parts を調べます。thought が付いたパートは思考中の内容なので、完成画像として返さずに読み飛ばし、最終出力の画像データを探してください。RESTの画像データは inlineData に入り、SDKでは命名規則が異なる場合があります。Interactionsの output_image と混ぜないことが、画像保存の不具合を避けるポイントです。

InteractionsとgenerateContentで、推論設定から画像の保存に進む流れを示した説明図
InteractionsとgenerateContentで、推論設定から画像の保存に進む流れを示した説明図

includeThoughtsをオフにすれば無料になるわけではない

includeThoughtsは思考の内容を応答に含めるかどうかの設定です。推論そのものや、その課金を停止するスイッチではありません。思考の要約が見えないことも、推論トークンがゼロだった証拠にはなりません。

会話を引き継いで画像を編集する実装では、返されたthought signatureを次のリクエストにそのまま渡す必要があります。表示しないパートを画面から除く処理と、次のリクエスト用の会話履歴を保存する処理は分けて扱ってください。公式のthought signatureの説明に、引き継ぎ時の要件があります。

Highにする価値は「採用できる画像」で判断する

単純な雰囲気出しや案の探索なら、まずMinimalで十分な結果が得られるかを確認します。Highを試す候補になるのは、複数の条件を同時に満たす必要がある画像です。たとえば、見出しと価格を正確に入れるメニュー、要素の位置関係が決まった説明図、参照画像の特徴を保ちながら構成を変える編集などです。

これはHighの効果を保証する分類ではなく、比較する対象の選び方です。画面を見てから何となく良い方を選ぶより、先に合格条件を決めると仕事に使える判断になります。先ほどのメニューなら、「見出しが指定どおり」「料理が左、価格が右」「背景が白」を条件にできます。

比較するときは、プロンプト、参照画像、解像度、縦横比、検索の利用設定をそろえ、推論レベルだけを変えるのが基本です。毎回まったく同じ画像が出るわけではないため、一組の出力で結論を決めず、実際によく使う複数の依頼で傾向を見ます。

記録するもの判断したいこと
最終画像が返ったか推論の説明だけで終わらず、成果物を取得できたか
事前に決めた条件の達成状況文字、配置、参照画像との対応が用途に合うか
リクエスト開始から完成画像取得までの時間制作の待ち時間として許容できるか
応答のusageと請求内容推論を含む費用がどれだけ増えたか
採用までの再生成・修正回数一回の費用が増えても、総作業量を減らせるか

Highで条件を満たしやすくなり、作り直しが減るなら、その用途で採用する理由になります。差が見られず待ち時間や費用だけが増えるなら、その依頼はMinimalのままでよいでしょう。画像の解像度も変えたい場合は、まず推論レベルの比較を終えてから別に試すと、改善の理由を追いやすくなります。

条件をそろえてMinimalとHighを比較し、指定条件、時間、費用、作り直しの回数を記録する説明図
条件をそろえてMinimalとHighを比較し、指定条件、時間、費用、作り直しの回数を記録する説明図

追加費用は画像代と推論代を分けて見る

Googleの標準API料金では、gemini-3.1-flash-image の入力はテキスト・画像とも100万トークン当たり0.50米ドル、テキストと推論の出力は100万トークン当たり3米ドルです。画像出力は別枠で、1K画像の目安として0.067米ドルが掲載されています。この0.067米ドルは、入力や推論などを含むリクエスト総額ではありません。公式料金表

たとえば、Highで推論トークンが追加で1,000増えたと仮定すると、その追加分は 1,000 ÷ 1,000,000 × 3 = 0.003 米ドルです。これは計算例であり、Highの通常消費量や一回当たりの固定追加料金を示す数字ではありません。

総費用を見積もるときは、画像出力分に入力、テキスト・推論、利用したツール等の費用を加えます。制作全体では、失敗して生成し直したリクエストも含め、採用した画像一枚にいくらかかったかを比較してください。解像度別の料金やAPI費用の全体像は、Nano Banana 2の料金とAPI費用で確認できます。

よくある設定の疑問

dynamiclowmediumも指定できる?

Nano Banana 2の現在のモデル別ガイドで確認できるのは minimalhigh です。Googleの発表記事には「High/Dynamic」という表現がありますが、それを根拠に dynamic というAPI値を作らないでください。他のGeminiモデルの選択肢も、そのままNano Banana 2に適用できるとは限りません。

Minimalは思考オフと同じ?

同じではありません。公式ガイドはMinimalでも推論する場合があると説明しています。推論を止める目的で offthinkingBudget=0 を追加する方法も、Nano Banana 2のモデル別設定としてここで確認したものではありません。

Highを選んだのに違いが分からない場合は?

まず、送信先のAPIに合うフィールドを使っているか、外部サービスならその項目を受け付けているかを確認します。正しく指定できている場合でも、すべての依頼で見た目の差が出るとは限りません。推論の文章量ではなく、完成画像が指定条件を満たす割合と、採用までの時間・費用を比べて判断してください。