はじめに
Google が 2026 年 10 月に公開した Nano Banana 2.1（Gemini API のモデル ID は gemini-nano-banana-2.1）は、料金表を見る限り 1 枚あたりの単価が Nano Banana 2 のほぼ半分です。ところが 2.1 は thinking（推論）が既定で有効になっており、推論に使ったトークンはテキスト出力として別に課金されます。単価表の「半額」は、請求に近い数字としてどこまで成り立つのでしょうか。
同じ日本語インフォグラフィックのプロンプトを 2.1 と 2 に各 5 回投げ、usageMetadata と応答時間を記録して比べました。
対象読者は、Gemini API で Nano Banana 2（gemini-3.1-flash-image）を使っていて、2.1 への切り替えを検討している開発者です。
TL;DR
- 1K 画像 1 枚の概算は 2.1（thinking 既定）が約 $0.047、2 が約 $0.068 でした。半額ではなく約 3 割減です。差を縮めているのは thinking のトークン（1 回あたり 583〜1,793）です。
- 応答時間は 2.1 既定が平均 16.5 秒、2 が 7.9 秒で約 2 倍です。
thinkingLevel: "minimal"にすると 8.8 秒・約 $0.038 まで下がりました（1 回のみの計測）。 - 上限トークン数はモデルカード・API ドキュメント・
models.getの三者で値が一致しません。2 と 2.1 でmodels.getの値は同じでした。
費用はすべて「公式単価 × 実測した usage」で出した概算で、請求額ではありません。
検証環境
| 項目 | 内容 |
|---|---|
| 実行日時 | 2026-10-07 08:4x〜08:51 JST |
| エンドポイント | POST https://generativelanguage.googleapis.com/v1beta/models/{model}:generateContent |
| クライアント | curl（-w '%{time_total}' で応答時間を記録） |
| 認証 | ヘッダー x-goog-api-key
|
| 比較対象 |
gemini-nano-banana-2.1 と gemini-3.1-flash-image
|
| 条件 | 1K・16:9 を各 5 回、2.1 のみ minimal / high / 2K / 8:1 を各 1 回 |
| 結果 | 15 回中 14 回が HTTP 200、serviceTier は全回 standard（例外の 1 回は後述の HTTP 400） |
プロンプトは、7 個の日本語見出しだけを描かせるインフォグラフィックの指示です。
日本語のインフォグラフィックを作成してください。アスペクト比は横長16:9。白に近い明るい背景、見出しごとに小さなアイコン付きのカードを2行3列で並べ、上部に大見出しを置く。
画像内に描画する文字列は次の7個だけです。これ以外の文字は一切描画しないでください。各文字列は一字一句正確に描画すること。漢字の偏や旁を別の字に置き換えないこと。
1. 大見出し: 画像生成モデルの移行ガイド
2. 料金体系の変更
3. 参照画像の上限
4. 推論段階の設定
5. 横長比率の追加
6. 文字描画の精度
7. 移行時の確認項目
公式の単価と、半額にならない理由
料金ページ の単価を 2 モデルで並べると、1 枚あたりの価格と 100 万トークンあたりの単価で向きが逆になります。
| 公式単価 | 2.1 | 2 | 2.1 / 2 |
|---|---|---|---|
| 入力 | $1.50/1M | $0.50/1M | 3 倍 |
| テキスト出力（thinking を含む） | $7.50/1M | $3.00/1M | 2.5 倍 |
| 画像出力 | $30/1M | $60/1M | 0.5 倍 |
| 1 枚あたり 1K | $0.0336 | $0.067 | 約 0.5 倍 |
| 1 枚あたり 2K | $0.0504 | $0.101 | 約 0.5 倍 |
| 1 枚あたり 4K | $0.0756 | $0.151 | 約 0.5 倍 |
1 枚あたりの価格は画像出力トークンだけを数えた値です。1K 画像は 1,120 トークンなので、2.1 なら 1,120 × $30/1M = $0.0336 になります。半額になるのは画像出力の部分だけで、入力と thinking は逆に高くなります。どちらが勝つかは、1 回の生成で thinking がどれだけ出るかで決まります。
実測: 1K を各 5 回
| 条件（実測） | n | thoughts 平均（最小〜最大） | 応答時間 平均（最小〜最大） | 概算費用 平均 |
|---|---|---|---|---|
| 2.1・既定 | 5 | 1,226（583〜1,793） | 16.5 秒（14.1〜18.5） | $0.0472 |
| 2・既定 | 5 | 0 | 7.9 秒（7.3〜9.0） | $0.0682 |
| 2.1・minimal | 1 | 0（フィールドが返らない） | 8.8 秒 | $0.0381 |
| 2.1・high | 1 | 2,492 | 24.8 秒 | $0.0580 |
入力は全回 165 トークン、画像出力は全回 1,120 トークンで同じでした。差が出たのは thinking と、画像以外の candidates トークン（2.1 で約 470〜720、2 で約 250〜390）です。後者の内訳は API から読めないため、テキスト出力単価で計算しています。
概算に使った式を Python で書くと次のとおりです。usageMetadata をそのまま渡せば同じ数字になります。
PRICES = { # USD / 1M tokens（2026-10-07 時点の公式料金ページ）
"gemini-nano-banana-2.1": {"in": 1.50, "text": 7.50, "image": 30.0},
"gemini-3.1-flash-image": {"in": 0.50, "text": 3.00, "image": 60.0},
}
def estimate_cost(model: str, usage: dict) -> float:
p = PRICES[model]
image = sum(d["tokenCount"] for d in usage.get("candidatesTokensDetails", [])
if d["modality"] == "IMAGE")
thoughts = usage.get("thoughtsTokenCount", 0)
text = thoughts + usage["candidatesTokenCount"] - image
return (usage["promptTokenCount"] * p["in"]
+ text * p["text"] + image * p["image"]) / 1_000_000
2.1 の 1 回目（thoughts 1,352・candidates 1,594）を入れると $0.0475、2 の 1 回目（thoughts なし・candidates 1,407）は $0.0681 です。2.1 既定の平均 $0.0472 は 2 の平均 $0.0682 の約 69% で、削減幅は約 3 割にとどまります。thinking を minimal にすると約 44% 減、high にすると約 15% 減でした。
応答時間は料金と逆の動きをします。thinking のトークンを生成する時間がそのまま上乗せされるため、2.1 既定は 2 の約 2 倍かかり、high では 3 倍を超えました。minimal は 2 とほぼ同じ 8.8 秒です。
2 に medium を指定すると 400 になる
条件をそろえるため 2 にも thinkingLevel: "medium" を指定したところ、次のエラーが返りました。
{
"error": {
"code": 400,
"message": "Thinking level MEDIUM is not supported for this model. Please retry with other thinking level.",
"status": "INVALID_ARGUMENT"
}
}
2 の既定では thoughtsTokenCount が返らず、minimal と high は試していません。上の比較は「2.1 の既定」と「2 の既定」を比べたもので、thinking の段階をそろえた比較ではありません。2.1 から 2 へ戻す処理を書く場合、2.1 用に入れた thinkingConfig をそのまま残すと 400 になる可能性があります。
損益分岐は thinking の量で決まる
1 枚あたりの単価差は 1K で $0.067 − $0.0336 = $0.0334 です。これが thinking の課金でどれだけ相殺されるかを、2 通りの前提で試算します。
- 両モデルが同じ量のテキストを出す場合: 単価差 $4.50/1M で割ると約 7,400 トークンです。
- 今回の実測のように 2 側の thinking が 0 の場合: 2.1 の thinking は全量に $7.50/1M がかかるので約 4,450 トークンです。
どちらも単価表から出した目安です。2.1 は画像以外の candidates も 2 より多く出ていた（上の表のとおり約 500 トークン）ため、実測の平均差（2 の $0.0682 − 2.1 minimal の $0.0381 = $0.0301）で計算し直すと、thinking の分岐点は約 4,000 トークンまで下がります。
今回の 2.1 の thoughts は最大でも 2,492（high）で、どちらの分岐点にも届いていません。プロンプトが長く複雑になれば thinking も増えると考えられますが、どこまで増えるかは今回の 1 種類のプロンプトからは言えません。
入力単価が 3 倍になる影響は、テキストだけのプロンプトなら誤差の範囲です（165 トークンで $0.00025 対 $0.00008）。参照画像を渡すと入力が増えますが、ここは未検証なので試算に留めます。参照画像 1 枚を仮に 1,120 トークンとすると、上限の 14 枚で約 15,700 トークン、入力単価差 $1.00/1M で約 $0.016 です。入力だけで $0.0334 の差を消すには約 33,400 トークンが要るため、thinking ほどは効きません。
移行の実務
モデル ID を gemini-3.1-flash-image から gemini-nano-banana-2.1 に差し替えれば、同じ generateContent のリクエストがそのまま通りました。thinking の段階と画像の設定は generationConfig に入れます。次は今回の検証で HTTP 200 になった条件（minimal・1K・16:9）を、検証時と同じフィールド構成で書いたものです。
{
"contents": [
{ "parts": [ { "text": "（プロンプト本文）" } ] }
],
"generationConfig": {
"responseModalities": ["IMAGE"],
"imageConfig": { "aspectRatio": "16:9", "imageSize": "1K" },
"thinkingConfig": { "thinkingLevel": "minimal" }
}
}
curl -sS -w '%{time_total}\n' \
-X POST "https://generativelanguage.googleapis.com/v1beta/models/gemini-nano-banana-2.1:generateContent" \
-H "x-goog-api-key: ${GEMINI_API_KEY}" \
-H "Content-Type: application/json" \
-d @req.json -o raw.json
jq '.usageMetadata' raw.json
jq -r '.candidates[0].content.parts[] | select(.inlineData) | .inlineData.data' raw.json \
| base64 -d > out.jpg
画像は inlineData に JPEG で返りました（1K・16:9 は 1376×768 px）。usageMetadata の thoughtsTokenCount は minimal では返らないので、集計コードでは欠落を 0 として扱う必要があります。
なお、画像生成ドキュメント の REST 例は Interactions API（/v1beta/interactions・generation_config.thinking_level）で書かれています。今回は generateContent と上記のフィールド名を使い、いずれも受理されました。
上限トークン数が三者で一致しない
移行前に入力上限を確かめようとすると、出所ごとに値が違います。
| 出所 | 入力上限 | 出力上限 |
|---|---|---|
| DeepMind モデルカード | 最大 1M コンテキスト | テキスト出力 64K |
| API ドキュメントのモデルページ | 131,072 | 32,768 |
models.get の応答（2026-10-07 JST に取得） |
65,536 | 65,536 |
models.get は 2（gemini-3.1-flash-image）でも 65,536 / 65,536 で、メタデータの上では 2 と 2.1 の差が見えません。どの値が実際の制限かはこの 3 つからは判断できず、上限近くまで入力を詰めた検証もしていません。長い PDF や多数の参照画像を渡す設計なら、本番前に自分の入力で通るかを確かめるのが安全です。
2K と 8:1 の出力
2K・16:9 は 2752×1536 px で返り、画像出力は 1,680 トークンでした。1,680 × $30/1M = $0.0504 で、公式の 2K 単価と一致します。thinking を含めた概算は約 $0.062、応答時間は 21.7 秒でした。
2.1 で追加された 8:1 も受理され、2928×352 px（約 8.3:1）が返りました。ただし 16:9 用に書いたプロンプトをそのまま流したため、カードが重なって見切れています。8:1 を使うなら、横一列に並べる前提で構成を書き直す必要があります。
日本語見出しの描画記録
プロンプトの 7 文字列を正解とし、画像中の文字と字単位で照合しました。偏や旁の置き換えも誤字に数え、判定は筆者 1 名の目視です。
| 条件 | 枚数 | 誤字 | 指定外の文字が出た枚数 |
|---|---|---|---|
| 2.1・1K 既定 | 5 | 0 | 2（「16:9」「上限」） |
| 2.1・minimal / high / 2K / 8:1 | 各 1 | 0 | 2（minimal と 2K で「16:9」） |
| 2・1K | 5 | 0 | 2（「16:9」「3」） |
14 枚 × 7 文字列の 98 文字列で誤字は 0 件でした。一方で「これ以外の文字は描画しない」という指示は守り切れておらず、アイコンの装飾として「16:9」などが入った画像が 2.1 で 9 枚中 4 枚、2 で 5 枚中 2 枚ありました。
標本は 1 種類のプロンプト・短い見出し 7 個・各条件 1〜5 枚と少なく、2.1 と 2 のどちらが日本語に強いかはこの結果からは言えません。長い段落や小さい文字、英字が混ざる場合には一般化できない記録です。
品質面の評価としては、Google のモデルカードによると人手評価の Elo は総合で 2.1（Thinking 有効）が 1050±14、2 が 990、Pro が 935、インフォグラフィックで 1048 / 961 / 912 とされています。これは Google の評価で、本記事の実測とは別の数字です。
未検証の事項
- 4K の出力と費用（公式単価は $0.0756）
- 参照画像を渡した場合の入力トークン数（最大 14 枚）
- Batch API（公式には半額とされる）
- 2.1 で
mediumを明示した場合と既定が同一か（モデルページは medium を既定と記載） - 2 の minimal / high の挙動
- 2 の提供終了日: The Decoder は 2026-10-29 に廃止されると報じていますが、公式文書では確認できていません
移行判断の目安
冒頭の問いに戻ると、単価表の「半額」は画像出力トークンだけを見た値で、thinking を既定のまま使った実測では約 3 割減でした。応答時間は約 2 倍に延びます。
- バッチ的に大量生成し待ち時間を問わない用途なら、既定のままでも 2 より安くなりました。
- ユーザーが生成完了を待つ UI なら、minimal にすれば 2 と同程度の応答時間で約 4 割安くなりました（1 回の計測なので、自分のプロンプトで再確認してください）。
- どちらの場合も、
thoughtsTokenCountをログに残しておけば、プロンプトが変わって thinking が増えたときに 2 との費用逆転を検知できます。
参考リンク
- Gemini API: Nano Banana 2.1 モデルページ
- Gemini API: 料金
- Gemini API: 画像生成
- Google DeepMind: Nano Banana 2.1 モデルカード