Nano Banana 2のJSONプロンプト設計｜ヒーロー画像を毎回ブレずに出す雛形と料金

この記事は LPやSNSサムネのヒーロー画像をAIで毎週量産したい副業・個人事業主向け（JSONを触ったことがなくても読めます）。

画像生成AIに同じプロンプトを投げているのに毎回違う絵が出てきて、3回叩いたら3回ブレた、という経験はみなさんもあると思います。

私もMidjourneyとStable Diffusionでこれを散々やりました。

文章プロンプトは「形容詞がどの名詞にかかるか」をAIが毎回違う解釈で処理するので、運ゲーになる。

Nano Banana 2（Gemini 3.1 Flash Image）でもこの問題は残っています。

ただ、2026年に入って公式ガイド側から 「JSONで書くとブレが劇的に減る」 という運用が推奨され始めた。

Google Cloud Blogが推奨フィールドを明示しているので、引用ベースで構造的に説明がつきます。

そこを記事の背骨にしました。

Nano Banana 2とNano Banana Proはどう違うのか

まず名前の整理から。

2026年現在、Google公式の画像生成モデルには Nano Banana Pro と Nano Banana 2 があります。

これが名称的に紛らわしい。

一次情報を並べるとこうなります。

日本語の解説記事で 「Nano Banana 2 = Gemini 3 Pro Image」と書いてある例 をちらほら見かけますが、これは誤りです。

Google公式ブログ（blog.google）と Gemini API公式ドキュメント（ai.google.dev）が明示している通り、Nano Banana 2の中身はFlash Imageです。

私はここを取り違えたまま料金表を書いている記事を3本見ました。

Pro側の値段（4K=0.24ドル）を書いてしまうと、読者が10倍規模で予算を見誤ります。

地味だけど大事なポイント。

機能面では、アスペクト比14種、参照画像14枚、キャラクター一貫性5人、4K解像度ネイティブ対応、131,072トークンのコンテキスト。

SynthIDとC2PAメタデータの透かしが自動で入る仕様です。

なぜ文章プロンプトは毎回ブレるのか

記事の背骨はここです。たとえばこんな文章プロンプトを投げたとします。

赤い革のジャケットを着た女性ヒーローが、雨の降る夜のネオン街で立っている。背景のビルには青い看板。シネマティックな構図。

一見丁寧に見えますが、ここには 「赤い」がどこまでかかるのか分からない箇所 が潜んでいます。

革のジャケットだけが赤いのか、背景のネオンも赤寄りに傾くのか、AIにも判別しきれない。

結果、生成のたびに「ジャケット赤・ネオン青」「ジャケットも背景も赤っぽい」「ジャケット朱色・背景マゼンタ」と揺れる。

私が5回叩いた時は3回ブレました。

これを業界では「概念ブリーディング（concept bleeding）」と呼びます。

形容詞や修飾語が、意図しない別の要素にじわっとしみ出す現象のことです。

Google Cloud Blogのプロンプトガイド（cloud.google.com）でも、属性をどの要素に紐づけるかを明示することの重要性が示されています。

構造化された記述によって「red」がどの要素に属するのかが明示され、色の分離が改善される（要約）。
— Google Cloud Blog, Ultimate prompting guide for Nano Banana

文章だと地の文に混ぜて書くしかない情報を、キー名つきでAIに手渡せる。

これがJSONプロンプトの本質です。

私はこの「属性をキーで縛る」発想を知ってから、ブレ率が体感で半分以下になりました。

JSONで書くと何が起きるのか

公式ガイドと複数の解説を横断すると、JSONが効く理由は次の5つに集約されます。

私が一番効きを実感したのは4番目の「弱い入力の発見」です。

文章で書いていると、書き漏らしに気づきにくい。

JSONだと lighting フィールドが空だから絵が平板になる、という当たりが3秒でつく。

設計レビューの言語として優秀なんですよね。

公式が推奨しているJSONフィールドは何か

業界の流れは分かったとして、Google本家は何を推すのか。

Google Cloud Blogの公式プロンプトガイド（出典）が掲載している代表フィールドはこの通りです。

• subject: 被写体・人物特徴
• action: 動作
• location_context: 場所・文脈
• composition: 構図・カメラアングル
• style: スタイル・フィルム種別
• lighting_setup: 照明セットアップ（「三点ソフトボックス」等の機材用語が効く）
• camera_hardware: カメラ機材（GoPro、Fujifilm、使い捨てカメラ等）
• lens_settings: レンズ設定（焦点距離・絞り・深度を数値指定）
• color_grading / film_stock / materiality / texture_emphasis: 質感系

公式が明示しているベストプラクティスは 「ポジティブフレーミング」（〜なしと書かず、欲しいものだけ書く）、「テキストは引用符で囲む」、「カメラ用語で構図を指定する」 の3点です。

ここ地味に重要。

ヒーロー画像用のJSON雛形（コピペ用）

ここからが記事の本丸です。

LPのファーストビュー画像やSNSサムネを想定したヒーロー画像用のJSON雛形を、公式フィールドを軸に組みました。

値だけ差し替えれば、誰でも同じ構図で量産できます。

{
  "label": "hero_visual_v1",
  "tags": ["cinematic", "heroic", "editorial"],
  "aspect_ratio": "16:9",
  "subject": {
    "character": "Asian woman in her 30s",
    "expression": "calm but intense, slight half-smile",
    "wardrobe": "matte black tailored jacket, white inner shirt",
    "pose": "three-quarter view, arms loose, weight on right leg"
  },
  "location_context": "minimalist concrete studio, soft fog, seamless gray backdrop",
  "composition": "centered, rule of thirds, low-angle shot, head room preserved",
  "lighting_setup": "three-point softbox, key light 45 degrees camera-left, warm rim light from back-right",
  "camera_hardware": "Sony A7R V, full-frame sensor",
  "lens_settings": {
    "focal_length": "85mm",
    "aperture": "f/1.8",
    "depth_of_field": "shallow, subject sharp, background smooth bokeh"
  },
  "color_grading": "cool shadows, warm highlights, film-like contrast",
  "film_stock": "Kodak Portra 400 emulation",
  "materiality": "fine fabric weave visible, skin texture natural, no plastic smoothing",
  "mood": "confident, editorial, premium",
  "text_elements": {
    "content": "LAUNCH 2026",
    "font": "sans-serif, bold, clear outline",
    "position": "lower-left, 8% margin"
  },
  "negative_constraints_as_positive": "clean background with no clutter, undistorted hands, natural facial proportions"
}

使い方の3ステップ

ステップ1: subjectとlocation_contextだけ差し替えて生成する。

最初は2フィールドだけいじります。

期待結果は「絵柄の方向性が固まる」。

詰まりどころは、subjectの人物特徴を抽象語（「美しい女性」）で書いてしまうこと。

私は「Asian woman in her 30s, short black hair」のように年齢・髪型・人種までは必ず具体化します。

ステップ2: 構図が気に入ったらlighting_setupとlens_settingsを微調整する。

期待結果は「光と被写界深度が制御できる」。

詰まりどころは、照明と焦点距離を同時にいじって、どっちが効いたか分からなくなること。

1回1フィールドが鉄則です。

ステップ3: text_elementsで文字を入れる。

期待結果は「LPに使える文字入り画像が完成」。

詰まりどころは、長文・複雑な漢字を入れると崩れること。

短文（10文字以内）・ひらがな中心・引用符で囲む、の3点で回避できます。

運用ポイントを4つ。

• キーと値は基本すべて英語にする。複数の日本語コミュニティ報告と私の手元検証で「英語のほうが精度が出る」という結論で一致。日本語も動くけど不安定です
• ネガティブは使わず、ポジティブに言い換える。"no people" ではなく "empty room only" と書く（公式推奨）
• カメラパートは分離する。camera_hardware と lens_settings をネストで独立させると、機材感・ボケ・遠近感を個別調整できる
• text_elementsは必ず引用符で囲う。公式ガイドの明示ルール

2Kと4Kでいくらかかるのか

料金の話。

ここが既存の日本語記事でブレやすい部分です。

Gemini API公式ドキュメント（ai.google.dev/pricing）の数字を基準に、Nano Banana 2のAPI単価をまとめます。

日本語で流通している「2K=0.134ドル / 4K=0.24ドル」という数字は Nano Banana Proの料金 です。

Nano Banana 2のほうは上表の通りで、4Kで0.151ドル。

Proと比べると約50%安い。

100枚作って計算してみると、Proなら24ドル、NB2なら15ドル、差額は9ドル。

月に1,000枚なら90ドル違います。

私なら間違いなくNB2を選びます。

Gemini Appのサブスク経由で使う場合は次の通り。

無料枠はもともと100枚/日あったのが、2026年1月のクォータ削減で20枚/日に急減しました。

一部のProサブスクライバーでさえピーク時に2〜5枚まで絞られる例が報告されています。

本格運用するならAPI直叩きかUltraが現実解、というのが数字を見ての所感です。

私なら月100枚以下ならAI Plus、それ以上ならAPI直叩きを選びます。

私は月100枚以下ならAI Plus、月7.99ドルが妥当です。

API直叩きで1,000枚生成しても約101ドル、AI Ultraの249ドルより安く済みます。

2Kで10枚作るのに3分、これがNB2の現実的な速度感です。

評判はどうなっているのか

賛否の両方があります。まずGoogle側の公式発表から。

Nano Banana 2は、Pro並みの世界知識・品質・推論能力を、Flashの高速性と組み合わせたモデル。512pxから4Kまでの解像度に対応し、画像内のテキスト描画と翻訳、最大5キャラクター・14オブジェクトでの一貫性を備える（要約）。
— Google公式ブログ Nano Banana 2発表（出典）

公式の打ち出しは「Pro並みの品質をFlashの速さで」というポジショニング。

私の見方では、これは 「多様性ではなく安定性を取った設計」 として読むのが正確です。

Flash系は元々「同じプロンプトに対する出力ブレを抑える」方向にチューニングされる傾向があり、Nano Banana 2もその系譜に乗っている。

量産用途では追い風、アート用途では物足りない、という温度差はここから来ます。

批判・懸念の側も無視できません。

私が触ってみて感じた弱点と、ユーザーコミュニティで指摘されている弱点を整理するとこうです。

• 参照画像の保持力はPro系に劣る。同じキャラを別構図で出したい時、Pro系のほうが顔の一貫性が高い印象。NB2は「だいたい同じ」止まりで、SNSサムネには十分でも写真集レベルの厳密さには届かない
• テキスト描画の改善は大きいが完璧ではない。短い英文・ひらがなは強くなったが、複雑な漢字や長文は依然崩れる
• 多様性は意図的に抑えられている。同じJSONを5回叩くと、Proなら5通りの解釈が出るところ、NB2は3〜4通りに収束する。量産には向くがアート性は薄い

私の見方では、Nano Banana 2は「速くて安定」、Nano Banana Proは「多様で豊か」という棲み分けに落ち着きつつあります。

大量生成・高速イテレーションがしたいならNB2、アート性重視なら現状はProが上、と整理するのが公平だと思います。

10枚作って2〜3枚採用するワークフローならNB2、1枚を作り込むならProです。

JSON運用でハマるポイント（先回りメモ）

触る前に知っておきたい罠を、公式ドキュメントと私の検証メモからまとめました。

• 日本語テキスト描画は改善したが完璧ではない。複雑な漢字・長文・装飾フォントでは崩れる。ひらがな中心＋短文（10文字以内）＋中央配置＋ "sans-serif, bold, clear outline" 指定で回避できる
• API経由で日本語プロンプトを投げると画像が返らない事例 あり。Thinking modeを明示的に選択すると解消するという報告がある（Gemini API公式ドキュメントのトラブルシューティング項参照）
• 1K解像度でテキストがぼけることがある。テキスト重要なら最低2K推奨
• 参照画像を過剰に編集してしまう ケースあり。preserve や do_not_change フィールドで保持したい要素を明示すると効く
• ピーク時に503エラー。朝方・週末にリクエストが集中する。Batch APIで時間をずらすのが得策

私の手元では、土曜午前11時に503が連発した日が1回ありました。

Batchに切り替えて2時間後にまとめて返してもらう運用が一番ストレスがないです。

どんな人に向いているのか

向いている層と、そうでもない層を整理します。

私がいまから本格的に画像生成を業務に組み込むなら、「プロンプトはJSON雛形で固定運用、モデルはNB2をデフォルト、アート性が必要な場面だけProに切り替え」 という使い分けにします。

月のAPI予算は1,000枚で約151ドル、サブスクなら AI Plus（月7.99ドル）を出発点にして、足りなくなったらPro/Ultraに上げる、というのが現実的な階段です。

よくある質問

Q. Nano Banana 2とNano Banana Proはどちらを使うべきですか

用途によります。

SNSサムネ・LPヒーロー画像の量産ならNB2（速くて安い）。

アート作品や広告ビジュアルなど1枚絵の質を追い込むならPro。

迷うなら両方試せるAI Ultra（月249.99ドル）が無難ですが、API直叩きでコスト計算するのも現実的です。

私は月100枚以下なら AI Plus からスタートを薦めます。

Q. JSONプロンプトは英語で書かないとダメですか

英語のほうが安定するというのが公式ガイドと複数の検証報告の共通見解です。

日本語でも動きますが、特にキー名は英語で固定、値は英語を基本とし、どうしても日本語にしたいテキスト要素（画像内に表示する文言）だけ日本語にするのが無難です。

APIで日本語プロンプトが反応しない事例も報告されています。

Q. 無料で使える1日の枚数は本当に20枚ですか

2026年1月のクォータ削減後、複数のソースが「約20枚/日」と記載しています。

ただしピーク時はさらに絞られる報告あり（一部Proサブスクライバーでも2〜5枚まで制限される例）。

本番運用するなら無料枠に頼らず、AI PlusかAPIに切り替えるのが安全です。

Q. JSONで書いても毎回違う絵が出るのですがなぜですか

JSONは「揺れを減らす」仕組みであって「揺れをゼロにする」仕組みではありません。

固定したい要素にはseed（使える場合）を明示、値を具体化する（「明るい」ではなく「45度キーライト、色温度5600K」等）、ネガティブをポジティブに書き換える、の3点を徹底すると揺れがさらに減ります。

私の手元では3回叩いて2回ブレた状態から、5回叩いて1回ブレるくらいまで安定しました。

Q. Nano Banana 2にAPIはありますか

あります。

Gemini API経由で gemini-3.1-flash-image-preview モデルIDを指定してアクセスします。

料金は2K=0.101ドル、4K=0.151ドル。

Batch APIなら半額です。

詳細はGemini API公式ドキュメント（ai.google.dev）を参照してください。

参考リンク

• Google公式ブログ（Nano Banana 2）: blog.google
• Google Cloud 公式プロンプトガイド: cloud.google.com
• Gemini API ドキュメント（画像生成）: ai.google.dev
• Gemini API ドキュメント（料金）: ai.google.dev/pricing

※この記事の内容は執筆時点のものです。AIは進化が速い分野のため、最新の仕様は公式サイトでご確認ください。