Nano Banana Pro APIの最安ルート 2026: Batch、relay、公式価格の下限

Nano Banana Pro API には 隠れた割引プランはありません。公式モデルは引き続き gemini-3-pro-image-preview で、Google が現在示している real-time の価格下限は 1K/2K が \$0.134、4K が \$0.24 です。非同期処理でよければ、Google 自身の Batch/Flex で \$0.067 と \$0.12 まで下がります。そして検索結果で見かける \$0.05/枚 のようなさらに安い real-time 価格は、たいてい relay プロバイダの契約 であって、Google の隠し tier ではありません。

つまり本当に答えるべきなのは、単純な AI Studio か Vertex AI か ではありません。重要なのは どの契約を買っているのか です。Google 公式の real-time、Google 公式の Batch、relay 市場のアクセス、それとも Pro 自体をやめてもっと安い画像モデルに切り替えるべきなのか。AI Studio と Vertex は今でも重要ですが、それは主に 認証、統制、workflow の形 に関わる話であって、標準の real-time 価格がどちらかで勝手に安くなるわけではありません。

以下の model ID、Preview 状態、価格、課金境界はすべて 2026年4月2日 時点の Google 公式ドキュメントで再確認しています。より安い価格への言及は、同日の検索市場の観測 として扱っており、Google 公式契約の事実とは分けています。

要点

実務上の一文に圧縮すると、Google公式でいちばん安くしたいなら Batch、同モデルの real-time でいちばん安くしたいなら relay、最速で公式の最初の1本を通したいなら AI Studio、そもそも Pro が不要ならモデルを替える です。

Nano Banana Pro APIが最安になるかは、どの契約を買うかで変わる

cheap Nano Banana Pro API という問いには、実は 三つの別の購買判断 が混ざっています。ひとつ目は、最安の Google公式ルート が欲しいのか。ふたつ目は、誰が課金するかを問わず、同モデルの real-time 最安 が欲しいのか。みっつ目は、そもそも Nano Banana Pro に払うべきなのか です。

Google 側の答えはかなり明快です。pricing page では gemini-3-pro-image-preview に free tier なし と書かれており、標準の image output は 1K/2K が \$0.134、4K が \$0.24、Batch/Flex にすると \$0.067 と \$0.12 に下がります。つまり最安の first-party answer は抽象的な "AI Studio" でも "Vertex" でもなく、Batch/Flex そのもの です。

一方で検索市場の答えは別です。最安ルートで検索すると、\$0.05/枚 前後を掲げる relay ページが上位に並びます。それが即座に誤りだとは限りませんが、そこで説明されているのは 別の商流 です。比較しているのは Google の二つの入口ではなく、Google の契約 と プロバイダ側の契約 です。

読者によっては、さらに強い節約策があります。先に Nano Banana Pro vs Nano Banana 2 を読むことです。もし workload が Pro の強い text rendering、複雑な layout の安定性、4K 前提を本当に必要としていないなら、最適化すべきものは route ではなく モデル選択 です。

AI Studio と Vertex AI: これは割引の話ではない

AI Studio と Vertex AI は今でも重要です。ただし重要なのは、最初の価格問題とは別の理由 です。どちらも同じモデルに到達できますが、変わるのは creative capability ではなく、認証、課金面、運用モデル、スケール制御 です。

AI Studio + Gemini Developer API は、最短で公式接続したいときのルートです。Google AI Studio で API key を作り、必要ならその UI で prompt を試し、そのまま Gemini Developer API からコードで呼び出します。個人開発、プロトタイプ、小さなチームの初期導入では、この route が最も合理的です。

Vertex AI は、Nano Banana Pro が単なる試験接続ではなく Cloud workload の一部になったときに本領を発揮します。IAM、project governance、application default credentials、batch、provisioned capacity が必要になった時点で、Vertex は「重い代替案」ではなく「正しい運用面」になります。Google の現在の公式資料はこの境界を十分に示しており、価格の話と混ぜない方が理解しやすくなります。

最も短い判断規則はこうです。

• 今の優先が developer velocity なら AI Studio
• 今の優先が Cloud operations と governance なら Vertex AI
• 今の優先が Google公式のコスト削減 なら Vertex 上の Batch/Flex

最後の一行が今回の重要な補正です。Vertex が価格の選択肢になるのは、Batch/Flex が入ってきたときだけ です。それまでは AI Studio と Vertex の違いは、基本的に運用の違いです。

ルート1: AI Studio + Gemini Developer API

多くの読者にとって、ここが正しい出発点です。Google AI Studio は Gemini Developer API の key 管理と試験導線の中心です。単なる playground ではなく、公式 API-key ルートの一部 と考えるのが正確です。

ここで最大の誤解が起きます。AI Studio が開けて試せることから、Nano Banana Pro に無料 API 層があるかのように受け取ってしまうケースです。しかし Google の pricing page は明確で、gemini-3-pro-image-preview には Free Tier: Not available とあります。Billing FAQ も、AI Studio 自体は無料で使えるが、paid features に paid API key を紐づけた時点でその usage は課金される と説明しています。

したがって安全な理解は次の通りです。

• AI Studio という UI 自体は無料で使える場合がある
• Nano Banana Pro の API usage は依然として 有料契約
• 「AI Studio に出ている」ことは「無料 API がある」ことを意味しない

どんなときにこのルートを選ぶか

次の条件なら、まず AI Studio です。

• まず最初の working request を最短で通したい
• API key で十分に運用できる段階にいる
• prompt と output style をまだ反復中
• Cloud IAM、batch、provisioned throughput はまだ必要ない

最小 JavaScript 例

まず公式 SDK を入れます。

bash
npm install @google/genai

次に API key でリクエストします。

javascript
import { GoogleGenAI } from "@google/genai";
import fs from "node:fs";

const ai = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY });

const response = await ai.models.generateContent({
  model: "gemini-3-pro-image-preview",
  contents: "Create a clean product hero image for a mechanical keyboard on a dark studio background.",
  config: {
    responseModalities: ["IMAGE"],
    imageConfig: {
      aspectRatio: "16:9",
      imageSize: "2K",
    },
  },
});

for (const part of response.candidates[0].content.parts) {
  if (part.inlineData) {
    fs.writeFileSync(
      "nano-banana-pro-output.png",
      Buffer.from(part.inlineData.data, "base64"),
    );
  }
}

これが最短の公式導線です。AI Studio で key を作り、GEMINI_API_KEY を設定し、generateContent を呼びます。現在の image-generation docs には、小さいですが実務上重要な注意もあります。1K、2K、4K の K は大文字でなければいけません。

HTTP から確認したい人は、同じルートを Gemini Developer API の REST と x-goog-api-key でも使えます。変わるのは transport であって、契約ではありません。

ルート2: Vertex AI は Cloud 運用向け

問題が「どう最短でつなぐか」から「どう Cloud の中で安全に運用するか」に変わった瞬間、Vertex AI の方が自然な選択になります。Vertex は単なる重い UI ではありません。Cloud の認証と運用契約に入ること自体が価値 です。

Gemini Developer API ルートでは中心は API key です。Vertex AI ルートでは中心は Cloud auth です。Google の現行 image-generation docs は、GenAI SDK を GOOGLE_CLOUD_PROJECT、GOOGLE_CLOUD_LOCATION、GOOGLE_GENAI_USE_VERTEXAI=True で設定する形を示しています。これだけでも、今いる場所が API-key 契約ではなく Google Cloud operating model だと分かります。

どんなときにこのルートを選ぶか

Vertex を選ぶべきなのは次のような場合です。

• 個人実験ではなくチームのアプリになっている
• IAM、監査、project governance が必要
• batch や provisioned throughput が必要
• API key 配布より service account / ADC の方が security boundary に合う
• 単なる接続ではなく継続運用が問題になっている

最小 Node.js 例

同じ SDK を使います。

bash
npm install @google/genai

Google の Vertex docs に合わせて環境変数を設定します。

bash
export GOOGLE_CLOUD_PROJECT=your-project-id
export GOOGLE_CLOUD_LOCATION=global
export GOOGLE_GENAI_USE_VERTEXAI=True

その上で同じモデルを Vertex から呼びます。

javascript
import fs from "node:fs";
import { GoogleGenAI, Modality } from "@google/genai";

const client = new GoogleGenAI({
  vertexai: true,
  project: process.env.GOOGLE_CLOUD_PROJECT,
  location: process.env.GOOGLE_CLOUD_LOCATION || "global",
});

const response = await client.models.generateContent({
  model: "gemini-3-pro-image-preview",
  contents:
    "Create a premium launch poster for a smart watch, crisp typography, dark editorial lighting.",
  config: {
    responseModalities: [Modality.IMAGE],
  },
});

for (const part of response.candidates[0].content.parts) {
  if (part.inlineData) {
    fs.writeFileSync(
      "vertex-nano-banana-pro-output.png",
      Buffer.from(part.inlineData.data, "base64"),
    );
  }
}

ここで 変わっていないもの は model string です。変わっているもの は client setup と auth assumptions です。記事全体をコードで要約すると、これがそのまま答えになります。

公式の割引は Batch であって、AI Studio の隠しプランではない

ここがまだ多くの ranking pages で曖昧なままです。いまの Google の pricing は十分はっきりしていて、公式の割引は Batch/Flex です。workflow が非同期でよければ、Google の bill は 1K/2K で \$0.134 から \$0.067 に、4K で \$0.24 から \$0.12 に下がります。

だからといって、公式ユーザーが全員最初から Vertex AI に入るべきだという意味ではありません。順序はこうです。まず いちばん安い Google 公式契約 が必要かを考える。必要なら Batch が答えです。そこまででなければ、次にどの公式 operating surface が workload に合うかを考える。この段階で AI Studio と Vertex が route choice に戻ってきます。

無駄に cost を増やしやすい罠は三つあります。

• AI Studio を開けることを、Pro API が無料で使えることと混同しない。 Google は今も gemini-3-pro-image-preview を Free Tier: Not available としています。
• API key を増やせば pricing tier が変わると考えない。 Google は rate limits を API key 単位ではなく project 単位 で適用すると明記しています。
• 本当に Pro が必要か確かめる前に route 最適化を始めない。 Pro の強みが不要なら、より大きい節約は model choice 側にあります。

AI Studio で始めて、あとで Vertex に移れるか

はい。むしろ多くのチームにとっては、それが最も自然な順序です。AI Studio で prompt と出力品質を理解し、最初の integration を通し、それから Cloud-native control が必要になった段階で Vertex AI に移る方が合理的です。

移行が思ったより軽いのは、モデルの identity が変わらない からです。変わるのは周辺契約だけです。

• API key auth から Cloud auth へ
• AI Studio 側の key / project 管理から Cloud の project / IAM 運用へ
• 「まず動かす」から「長期運用する」へ

だから、最初からすべてを Vertex AI に載せるのも過剰設計になりやすく、逆に AI Studio を永遠の最終形として固定するのも正しくないことが多いです。まずは最速の公式 route で始め、Cloud control が必要になったら Vertex に移り、first-party の cost reduction が最重要になったら Batch に切り替える、という順序で考えるのが自然です。

30秒で決めるなら

本当に短い判断規則だけ欲しいなら、次で十分です。

あなたの本当の質問が次なら Vertex AI Batch / Flex です。

• 「いちばん安い Google 公式ルートはどれか」
• 「この workflow は非同期で回せるか」
• 「first-party の billing と governance が必要か」

あなたの本当の質問が次なら relay プロバイダ です。

• 「同じモデルの real-time 最安はどれか」
• 「Google 自身の契約より bill を優先したいか」
• 「third-party の support / compliance boundary を受け入れられるか」

あなたの本当の質問が次なら AI Studio + Gemini Developer API です。

• 「最初のリクエストを一番早く通すにはどうするか」
• 「公式環境で prompt を確認してから進めたい」
• 「Cloud 運用を全部入れる前に、まず公式 route で接続したい」

あなたの本当の質問が次なら Vertex AI です。

• 「これをどう Google Cloud に組み込むか」
• 「API key を配るのではなく、チームに制御された access をどう渡すか」
• 「batch や provisioned throughput をどう計画するか」

そして、もし本当の悩みが route ではなく Pro というモデル自体が必要かどうか なら、先に入口で迷わない方がいいです。まず Nano Banana Pro vs Nano Banana 2 を見てください。多くの workload では、より大きな cost / architecture の差は route ではなく model choice 側にあります。