Nano Banana Proプロンプト完全ガイド：構造化された書き方、文字レンダリング、複数画像での一貫性

まず名称をはっきりさせておく。Nano Banana Proはどこかの企業が登録した製品名ではなく、コミュニティがGoogle Gemini 3 Proの画像生成能力に付けたニックネームで、かつてのNano BananaがGemini 2.5 Flash Imageを指していたのと同じロジックだ。名前は気にしなくていいが、能力は気にすべきだ――このモデルの強みがどこにあり、弱みがどこにあるかは分けて話す必要があり、「すごい」の一言で済ませるべきではない。

サイト内のこのバッチの実例は、大半がこのモデルで出力したもので、人物写真、EC、イラスト、デザインポスターといった大きなカテゴリーをカバーしている。この記事を書く前によくある問題を一通り確認した――どんなプロンプトの書き方が効きやすく、どんな書き方だとここでは効率が落ちるか。以下、具体的な能力ごとに分けて話す。抽象的な話はしない。

強みは3つのことに集約される、漠然とした「効果がいい」ではない

一つ目は複数画像を参照した際の一貫性だ。同じ顔、同じ小道具を、9分割・16分割のグリッドの中でぶれさせずに維持することを求められると、以前はこの点が大きな弱点だったが、今は明らかに安定してきている。二つ目は画面内の文字レンダリングだ。ポスターの大きな文字やラベルの小さな文字を、書いた内容どおりに正確に描き出せる。以前のような文字化けした筆致ではなくなった。三つ目は構造化された長いプロンプトへの指示追従力だ。フィールドを細かく書くほど正確に聞き取ってくれる。この点は多くのモデルが「言葉が多いと聞き逃す」のとちょうど逆の傾向にある。

この表情プリクラの実例は16枚の顔を一度に出力し、どの一枚も顔のパーツの比率がずれていない。これは一貫性という強みが直接表れたもので、人物写真カテゴリーの中でもかなり出来のいい実例と言える。

nano banana proのプロンプトはどう書くべきか、構造化テンプレート

短文に形容詞を積み上げる書き方は、このモデルでは明らかに不利になる。このモデルは構造をより重視する――要求をフィールドごとに分解し、一つずつ並べたほうが、すべての要求を一段落に詰め込むより正確に実行される。そのまま使えるテンプレートを一つ紹介する。

• style：全体のスタイルの指定。たとえば「高解像度のファッション写真、フィルム粒状感」
• subject：主体は誰で、どんな状態か。姿勢や表情まで具体的に
• scene：場面と小道具、空間の関係性を伝える
• lighting：光源の方向と色温度。「きれいな光」とだけ書かない
• camera：構図の比率、レンズのアングル、フォーカスの位置
• text（画面に文字を出したい場合）：文言の原文を引用符で固定する

この人魚座りの人物写真の実例は、まさにこのフィールドの分け方で書かれている。姿勢、小道具、光を分けて伝えることで、出来上がった構図がお互いにぶつかっていない。フィールド設計をより完全に理解したい場合は構造化プロンプトの書き方の記事を、プロンプト万能構成公式と実は同じ考え方だが、このモデルは構造化への許容度が高く、詰め込めるフィールドも多い。

画面内の文字レンダリング、どう書けば正確になるか

これはgemini 3 pro imageの能力ラインの中で、一番もったいない使われ方をされがちな部分だ。よくある失敗は文字が描けないことではなく、プロンプトの中でそもそも出したい文字が何なのかをはっきり書いていないことにある。「ポスターにプロモーション文言がある」と書くだけでは、モデルは推測するしかない。「ポスター中央に大きく『FINAL HOURS』と書く。フォントは高コントラストのサンセリフ、ベージュの背景に濃い赤の文字を重ねる」と書いて初めて、この能力を本当に使っていることになる。原文は必ず引用符でくくり、字数は一文以内に抑える。10文字を超える長い文になると、レンダリングのエラー率が明らかに上がる。

このプロモーションポスターの実例は文字に変形もなく余分な筆致もなく、色のブロックと文字の太さもプロンプトに書いたとおりになっている。この種のデザイン素材カテゴリーの実例は、基本的に引用符で文言を固定して初めて安定する。

複数画像を参照した一貫性、実践ではどう維持するか

複数の参照画像を与えて、同じキャラクター、同じ装備だとモデルに認識させたい場合、この能力はキャラクター設定画や回転図のような場面で一番よく使われる。重要なのは「参照画像をたくさん与える」ことではなく、プロンプトの中で各参照画像がどの情報レイヤーに対応するかを明確に指示することだ。一枚目で顔を決め、二枚目で服の素材を決め、三枚目で小道具のディテールを決める、というように層ごとに分けて伝えるほうが、漠然と「これらの画像を参考にして」と書くよりずっと安定する。

このエージェントの回転図の実例は8つのアングルを通して、装備のディテールがどのコマも食い違っていない。この種のイラストアートカテゴリーのキャラクター設定の要求は、ほぼこの能力の自然な活用場面と言える。

ECのインフォグラフィックのような精密なレイアウトも、この構造化された書き方が効く

EC商品の詳細ページやタイムライン式インフォグラフィックのように、複数の情報ブロックがそれぞれ独立していながら全体としても統一されている必要がある場面も、同様に構造化プロンプトの恩恵を受ける。ブロック同士の階層関係をはっきり書く――第一段階にどんな内容が入り、フォントの大きさはどれくらいで、余白はどれくらいか――ほうが、モデルに自由にレイアウトさせるより安定する。

このタイムラインインフォグラフィックの実例は5つの段階がそれぞれ独立しながら同じ軸線上に揃っている。このレイアウトの精度は、EC商品カテゴリーの詳細ページの要求でも同様に活用できる。

よくある失敗と対策

実測で繰り返し出てきたいくつかの落とし穴を紹介する。一つ目は、プロンプトに一度にたくさんの文字ブロックを詰め込みすぎることで、モデルがあちらを立てればこちらが立たずという状態になりやすい。一度に固定するのは核となる文言一つに絞り、複数の文字ブロックは二回に分けて走らせるほうが、一度に全部正しく出そうとするより安定する。二つ目は、複数画像参照の際に情報の階層を区別しないことで、「顔は合っているのに服がおかしい」といった中途半端な結果が出やすい。これは本質的にはどの画像がどの部分の情報を担当するかをモデルに伝えていないからだ。三つ目は、構造化されたフィールド同士が矛盾していること(たとえばlightingで逆光の指定をしつつmoodで正面からの光を書いてしまうなど)で、提出前にフィールド間の論理を一度自分で確認しておくと、やり直しの時間をかなり節約できる。四つ目は、パラメータ的な描写と内容的な描写を混ぜて書いてしまうことで、画角比率のような技術的な項目は最後にまとめて別に伝え、内容のレイヤーとは分けたほうが、モデルの解析がすっきりする。

もう一つ見落とされがちな問題がある。同じプロンプトから出力した複数の結果の差異が大きい場合、多くはモデルが不安定なのではなく、プロンプト自体に曖昧な余地を残しすぎていることが原因だ。姿勢が固定されていない、小道具の数がはっきり書かれていない、といったことはすべて「自由にやっていい」というサインとして扱われてしまう。この判断を検証したいなら、同じプロンプトから異なるフィールドを一つずつ削って何度か比較してみるといい。どのフィールドを削ったときに差異が一番大きくなるかを見れば、そのフィールドが本当に効いている項目だとわかる。

nano banana proの使い方は、突き詰めれば「フィールド思考」の問題だ――どの情報レイヤーを伝えるべきかをまず整理し、それを一層ずつ構造の中に埋めていくほうが、一度に華やかな長文を書くよりずっと効果がある。他のモデルとの違いを直接比較したいなら、GPT Image 2対Nano Banana ProとNano Banana対Nano Banana Proの2本を見てほしい。モデル百科のトップページにはサイト内の全モデルの立ち位置の説明がまとまっており、全比較ページにはさらに多くの組み合わせがある。トップページimage.faxianai.comには既製のプロンプト実例集があり、その構造をそのまま参考にフィールドを変えて使える。