Nano Banana Pro API完全ガイド: 公式モデルID、料金、制限、クイックスタート

2026 年 3 月 27 日時点で、Nano Banana Pro API が指すのは Google の gemini-3-pro-image-preview です。 新しい統合を作るなら、最初に選ぶべきなのはサードパーティの別名でも Gemini の OpenAI 互換レイヤーでもなく、ネイティブな Gemini 画像生成ルートです。OpenAI 互換ルートを最初から選ぶ合理的な場面は、すでに OpenAI 形の SDK やクライアントがあり、書き換え量を最小化することが最優先である場合に限られます。

この結論が妥当なのは、SERP がまだかなり断片的だからです。検索結果の上位には Nano Banana Pro API、価格バッジ、短い curl スニペットを前面に出すページが多く並びますが、公式モデル ID、Paid Tier が必要になる条件、そして実際の制限をどこで確認するかまで、まとめて説明しているページは多くありません。Google の答えはより信頼できますが、image-generation ドキュメント、OpenAI compatibility ドキュメント、pricing ページ、rate-limits ページ に分散しています。

そのため、このキーワードで最初に解くべき問題は価格比較ではなくルーティングです。まず公式モデル名を確認し、次に正しい API 面を選び、そのあとで課金状態とライブ制限を確認する。この順序を守ってからプロバイダーや中継サービスを比較したほうが、実装時間もデバッグ時間も短くなります。

要点まとめ

次に気になることが価格なら Nano Banana Pro API Pricing（英語） を、より汎用的な REST 呼び出しなら Gemini Image Generation REST API を参照してください。API キー、セットアップ、課金については、このページ内でも英語の補助リンクを明示します。

Nano Banana Pro API は通称であり、Google の正式なモデル名ではない

このクエリで最初に修正すべきは名前の理解です。Nano Banana Pro は Gemini 3 の高級 image レーンに対する Google の一般向けニックネームですが、正式な API モデル名は gemini-3-pro-image-preview です。Google の現在の image-generation ドキュメント では、次のように整理されています。

• Nano Banana 2 = gemini-3.1-flash-image-preview
• Nano Banana Pro = gemini-3-pro-image-preview
• Nano Banana = gemini-2.5-flash-image

見た目には小さな違いですが、検索結果の多くを読むときの解釈を大きく変えます。いくつかのプロバイダーは nano-banana-pro のような独自エイリアスを公開しています。そのエイリアスはそのサービス内では使えるかもしれませんが、Google の正規のモデル文字列ではありません。それをそのまま Google への直接リクエストに貼り付けると、最初から間違ったレイヤーをデバッグすることになります。

Google の現在の changelog によると、gemini-3-pro-image-preview の公開日は 2025 年 11 月 20 日 です。この日付が大事なのは、古いページの多くがプレリリース時代の名称、2.5 系 image モデル、あいまいな Gemini 3.0 Pro といった表現を混在させているからです。

モデルの位置づけも確認しておくべきです。DeepMind のモデルページ では、Nano Banana Pro を高精度で制御性の高い Gemini 3 image モデルとして説明しています。image-generation ドキュメント では、プロ向けのアセット制作や複雑な指示に適しており、Gemini 3 image モデルは最大 14 枚の参照画像を組み合わせられるとされています。Google はまた、すべての生成画像に SynthID が含まれることも明記しています。

ここまでをまとめると、理解すべきポイントは次のとおりです。

• Nano Banana Pro はプロダクト向けの通称。
• gemini-3-pro-image-preview は公式 API で使うべき文字列。
• サードパーティの別名はラッパーの都合であり、first-party の正式名ではない。

この前提が固まれば、次に考えるべき実務的な問いはひとつです。どの API ルートから始めるべきか。

どのAPIルートから始めるべきか

ほとんどの読者にとって答えは明快です。まずはネイティブ Gemini API から始めるべきです。 モデルに初めて触れる場合、raw HTTP で試す場合、公式 docs に沿って理解したい場合、最初の成功レスポンスを確認したい場合、このルートが最もわかりやすい出発点になります。

理由は思想ではなく明瞭さです。Google の現在の image-generation ガイド は、ネイティブ Gemini の generateContent 契約を前提に画像出力を説明しています。モデルマッピング、画像サイズ、aspect ratio、Gemini 3 の各 image レーンは、この表面で最もストレートに整理されています。検索から最初の正しい Google リクエストまでを最短でつなぐなら、ここが最もクリーンです。

Gemini OpenAI-compatible route も正式に存在し、Google は OpenAI compatibility ページ でこれをサポートしています。client.images.generate から gemini-3-pro-image-preview を呼べるので、既存の OpenAI 形アプリや SDK 規約を崩したくない場合には有効です。ただし、新規統合の標準ルートとしては適しません。互換レイヤーの向こう側にネイティブ契約が隠れてしまい、どこで何が起きているかを理解しにくくなるからです。

したがって、実務上の分け方は次のようになります。

• 公式ルートを学ぶ、ゼロから構築する、raw request をデバッグするなら ネイティブ Gemini。
• OpenAI 形クライアントを維持することが主目的なら Gemini OpenAI compatibility。
• 公式モデル、公式価格、billing surface を理解したあとで relay provider を比較する。

最後の分岐が重要です。検索上位には、製品そのもののように見える provider ページが多くあります。しかし、それらは製品そのものではなく、製品への一つのアクセス経路です。この差を理解しないまま読み進めると、Google の API 挙動ではなく、誰かの gateway のルールを比較することになります。

課金、料金、そして実際の制限はどこで確認するか

ルーティングの問題と課金の問題は、多くのランディングページが示す以上に密接に結びついています。

Google の billing ページ では、新しい Gemini API アカウントは Free Tier から始まり、Paid Tier に移行するには billing account のリンクと最低 $10 の前払いが必要だと説明されています。同じページには、2026 年 3 月 23 日 に始まった一時的な prepay-to-postpay migration 状態も書かれています。実務上の要点は明確で、API キーを取得しただけではセットアップ完了とは言えません。モデル名もエンドポイントも正しくても、課金状態がプロジェクト要件と一致していなければ、画像生成は失敗したり、期待と異なる挙動になったりします。

現在の Google 公式 pricing ページ に基づく料金は次のとおりです。

比較を始めるときは、まずこの公式基準を頭に入れるべきです。検索上位の provider ページの多くは、Google の基準価格を知る前に、自分たちの credit 価格や代理価格を印象づけようとします。まず公式基準を持っておけば、wrapper の価格比較にも意味が出ます。もし本当に解きたい問題が「もっと安い経路はないか」であれば、Nano Banana Pro Cheap API Alternative（英語） を見たほうが早いです。

制限については、古い記事がもっとも誤解を広げやすい部分です。Google の rate-limits ページ は、誰にでも永続的に適用される単一の RPM を提示していません。代わりに、次の点を明確にしています。

• 制限は project 単位 で適用される
• requests per day は 太平洋時間の深夜 にリセットされる
• preview モデルは より厳しい制限 を持ちやすい
• ライブ制限は AI Studio で確認すべき

だからこそ、このページでは固定の universal RPM を繰り返しません。多くのページはいまだにそう書いていますが、Google 自身の説明はもっと条件依存です。安全なデフォルトは、AI Studio を現在の live limits の確認場所として扱うことです。

クイックスタート: 最初の Nano Banana Pro API リクエストを通す

最初の検証として最も安全なのは、1 本の公式 Google リクエスト、1 つの正しいモデル名、1 枚の画像です。最初の目的がルートの証明であるなら、provider alias、batch pipeline、複雑な中継サービスから始めるべきではありません。

ネイティブ Gemini ルート

bash
curl -s -X POST \
  "https://generativelanguage.googleapis.com/v1beta/models/gemini-3-pro-image-preview:generateContent" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "contents": [{
      "parts": [
        {
          "text": "Create a clean 16:9 product hero image of a matte black travel mug on a light concrete surface with soft studio lighting and premium ecommerce styling."
        }
      ]
    }],
    "generationConfig": {
      "responseModalities": ["IMAGE"],
      "imageConfig": {
        "aspectRatio": "16:9",
        "imageSize": "2K"
      }
    }
  }'

このリクエストは、公式ルートそのものを直接証明します。Google の正規モデル文字列、現在のネイティブ Gemini 契約、Gemini 3 image generation 向けに Google が文書化している設定フィールドを使っています。

ネイティブルートでは、扱いやすい hosted URL ではなく、レスポンス内部に画像バイトが返ることが一般的です。だからこそ、これが最初の proof として適しています。実際のレスポンス形状が見えれば、アクセス権の問題か、モデル選択の問題か、自分の保存ロジックの問題かを切り分けやすくなります。

Gemini OpenAI 互換ルート

すでに OpenAI 形のクライアントを持っていて、互換レイヤーを意図的に使いたい場合は、Google の docs がこのルートもサポートしています。

python
from openai import OpenAI

client = OpenAI(
    api_key="GEMINI_API_KEY",
    base_url="https://generativelanguage.googleapis.com/v1beta/openai/",
)

result = client.images.generate(
    model="gemini-3-pro-image-preview",
    prompt="Create a clean 16:9 product hero image of a matte black travel mug on a light concrete surface with soft studio lighting and premium ecommerce styling.",
    size="2K",
    n=1,
)

この経路は、例が短く見えるからではなく、OpenAI 形を維持すること自体が目的であるときに選ぶべきです。

最初の成功レスポンスが取れたら、次の一手は残っている疑問次第です。

• billing が詰まりどころなら Nano Banana Pro Google AI Studio Billing（英語）。
• API key が詰まりどころなら Nano Banana Pro API Key（英語）。
• セットアップ全体 を見直したいなら Nano Banana Pro API Setup（英語）。
• より一般的な image REST 呼び出し を見たいなら Gemini Image Generation REST API。

セットアップ後によく起きる失敗

このクエリは、最初のコード例のすぐあとにサポート問題へ変わりやすいです。そのため、この章は一般的な機能紹介よりも価値があります。

Google の公式 docs は billing と limit の所在を説明していますが、実際の実装時の摩擦はコミュニティのスレッドのほうが見えやすいです。Google Developers Forum のスレッド では、AWS Lambda では再現するがローカルでは再現しない IMAGE_OTHER 失敗が報告されています。Reddit のスレッド では、rate-limit の枯渇と backend capacity の問題が混同されやすいことが見て取れます。

まず使える切り分け表は次のようなものです。

大事なのは、層ごとにデバッグすることです。まず official model ID、次に billing、その次に route、そのあとで compatibility layer や provider gateway を見る。これだけで、一般論の最適化テクニックよりもずっと多くの時間を節約できます。

relay provider を使うべきなのはどんなときか

公式ルートが理解できたあとであれば、relay provider に意味がある場面はあります。SERP にそれらが多いのにも理由があります。典型的には次の四つです。

• 複数の image モデルを一つの OpenAI-style gateway で扱いたい
• ベンダー横断の billing を一本化したい
• 自分のトラフィック形状に合った provider 独自の price plan がほしい
• 直接の Google billing より速く商用オンボーディングしたい

ただし、それらは 公式 baseline の理解を置き換えるものではありません。 nano-banana-pro のような alias や credit 価格だけを前面に出すページを見ても、背後の公式モデル、Google の直価格、ライブ制限の本当の由来は自分で把握しておくべきです。

だからこのハブ記事は official-first を維持しています。その後で relay を比較するのは問題ありませんが、Google 公式 surface を理解しないままそこから始めるのは遠回りです。

より安い、あるいは簡単な gateway を探したい場合は、次の英語ページも役立ちます。

• Nano Banana Pro Cheap API Alternative（英語）
• How to Call Nano Banana Pro via API（英語）
• Nano Banana Pro API Pricing（英語）

FAQ

Nano Banana Pro API に対応する Google の正式モデル名は何ですか。

正式なモデル文字列は gemini-3-pro-image-preview です。Nano Banana Pro は通称であり、公式 API モデル名ではありません。

ネイティブ Gemini API を使う必要がありますか。それとも OpenAI 互換クライアントでも大丈夫ですか。

どちらも使えます。新しい統合ではネイティブ Gemini ルートが最も安全な初期値です。OpenAI 互換クライアントを維持することが主目的なら、Gemini の OpenAI 互換ルートが適しています。

実際のライブ制限はどこで確認すればよいですか。

Google の現在の rate-limits ページは、アクティブな制限を AI Studio で確認するよう案内しています。公開 docs はルールを説明しますが、現在のプロジェクト状態は AI Studio で確認するのが安全です。

Nano Banana Pro API を本格運用するには billing が必要ですか。

はい。Google の billing docs によれば、Paid Tier へ移るには billing account のリンクと最低 $10 の前払いが必要です。API key を取得しただけでは、必要な運用ルートが保証されるわけではありません。

生成画像には SynthID が含まれますか。

はい。Google の image-generation docs では、生成画像に SynthID が含まれると明記されています。

まとめ

Nano Banana Pro API は謎の第三者製品ではありません。Google の gemini-3-pro-image-preview です。

新規導入ならまずネイティブ Gemini ルートから始めるべきです。すでに OpenAI 形のクライアントがあり、移行コストを抑えることが最重要なら、Gemini の OpenAI 互換レイヤーを意図的に選んでください。どちらのルートでも、最初の判断基準は Google 公式の価格、課金、制限ページに置くべきです。