Reddit発のNano Bananaプロンプト：丸写しせず型を抜き出して試す

RedditにあるNano Bananaプロンプトは、実際の利用者が商品写真、キャラクター、広告、情報図、編集、参照画像、失敗例をどう言語化しているかを知る材料になる。ただし、他人のスクリーンショットでうまく見えた文が、自分の製品、人物、ブランド、画面比率、文字、参照画像、API運用でも同じように働くとは限らない。

実務では、Redditを答えの倉庫としてではなく素材置き場として扱う。残すのは文そのものではなく、画像の目的、視覚構造、経路の前提、守るべき制約、失敗時の判断である。

2026年5月18日時点で、経路やモデルIDに関わる事実はGoogleの公式情報で確認する。開発者向けではNano Banana 2はgemini-3.1-flash-image-preview、Nano Banana Proはgemini-3-pro-image-preview、元のNano Bananaはgemini-2.5-flash-imageに対応する。Redditは表現と失敗例を学ぶ場所であり、モデル名、料金、無料枠、利用経路、安全挙動の根拠ではない。

同じ型を自分の仕事で二度試して失敗するなら、形容詞を増やす前に経路を疑う。文字が崩れる、同一人物が保てない、商品形状が変わる、編集範囲が広がる、APIで再現しない、ブロックされる。これらは文章量ではなく作業経路の問題であることが多い。

まず画像の仕事を決める

良いプロンプトは、最初に何を作るかが明確である。商品hero、人物ポートレート、キャラクター設定、SNS広告、情報ボード、室内イメージ、料理写真、before/after編集、ストーリーボード、APIの一括生成では、必要な指示が違う。

「高級感のある画像」だけでは弱い。高級感を支えるのは、素材、配置、光、余白、背景、カメラ距離である。「マットブラックのデスクライトをウォールナットの机に置き、左から大きな柔らかい光、右側に見出し用の余白」と書けば、モデルは何を守るべきかを理解しやすい。

保存前に三つのタグを付ける。

この三つが空のままなら、プロンプトは参考資料に留める。ライブラリには入れない。

経路を選んでから文章を増やす

Nano Bananaという呼び方だけでは作業経路が足りない。素早い試作、参照画像の保持、文字入りレイアウト、複数画像の一貫性、APIの再現性は別問題である。

Geminiアプリは視覚方向の探索に向いている。雰囲気、ラフな構図、色、カメラ感をすぐ試せる。だが、リクエストの記録、モデルID、バッチ、再試行、コスト管理まで含む生産ワークフローの証明には向かない。

参照画像編集は、商品、顔、服装、部屋、ポーズ、既存パッケージを守るときに必要になる。守るものを先に書く。あとから「同じ人で」「同じ商品で」と足しても、すでにスタイル語が強すぎると壊れやすい。

Nano Banana Proは、画像の中に正確な文字、表、ステップ、ラベル、情報階層があるときに強い。単純な雰囲気出しまでProに寄せる必要はない。短く明確な自然文の方が早く安定する場面もある。

AI StudioやAPIは、モデルID、リクエスト形、ログ、失敗処理、保存先、費用、権限が必要なときの経路である。アプリでうまくいった一文は、APIで同じ挙動を保証しない。

プロンプトを構造に分解する

使い回せるプロンプトは、形容詞の山ではない。作るもの、守るもの、変えてよいもの、合格の見方を分けた構造である。

保存するときは次の形にする。

hljs text复制
画像の仕事：
主題と文脈：
構図とカメラ：
光と色調：
スタイルまたは形式：
守るべき細部：
避けるべき失敗：
経路またはパラメータ：
判定基準：

この形にすると、他人の題材を外しても使える。「ネオン雨のサイバーパンク戦士」が欲しいのではなく、特定の主題、環境、光、視点、制約、合格条件の組み方が欲しい。主題を自分の商品や人物に替え、場面と検証を自分の用途に合わせて初めて実務用になる。

使える型をカテゴリ別に保存する

コミュニティの例は、魔法の文ではなく作業カテゴリとして読む。どのカテゴリも、残すのは構造であり、単語の飾りではない。

商品hero

hljs text复制
[製品]を[表面/環境]に置いた商用hero画像を作成する。
[光の方向]、[影の質]、[背景処理]を使う。
カメラは[角度]で、製品が主役になる。
余分なロゴ、手、読めない文字、形状の変化を入れない。
判定：三つの出力で形、素材、主要特徴が保たれる。

商品画像では、素材、角度、面、光、背景、余白が重要になる。「ラグジュアリー」よりも、何がラグジュアリーに見えるのかを素材と構図で指定する。

キャラクターと同一性

hljs text复制
[人物/キャラクター]を[場面]で描く。
[顔型、髪、服、年齢感、持ち物]を維持する。
[スタイル]、[カメラ距離]、[表情]を指定する。
年齢、顔の構造、服色、象徴物を変えない。
判定：三つの出力で同一性のアンカーが保たれる。

一枚のコンセプトなら文字だけでも試せる。連載、広告シリーズ、マスコット、複数カットでは参照画像を使う。テキストだけで同一人物を長く保つのは難しい。

情報ボード

hljs text复制
[読者]向けに[テーマ]を説明する情報ボードを作成する。
必須セクション：[1]、[2]、[3]、[4]。
短いラベル、読みやすい余白、文書風の階層を使う。
正確に出す文字：[指定語]。
偽の数値、余分なラベル、装飾ノイズを入れない。
判定：指定文字が読め、新しい主張が混ざらない。

文字と階層がある仕事では、Pro経路を検討する。正確な数字、料金、上限、法務表現、ブランドコピーを画像モデルに自由生成させてはいけない。

入力画像の編集

hljs text复制
入力画像を編集し、[具体的な変更]だけを行う。
[人物、商品、姿勢、背景、透視、文字]を維持する。
元画像のカメラ角度、光の方向、遠近を合わせる。
新しい物体、別人化、背景変更、文字の書き換えを避ける。
判定：変更は見えるが、守る要素は元画像と一致する。

編集では、何を変えないかが成功を左右する。良い見た目でも、商品や人物が別物になったら失敗である。

同じプロンプトを小さく検証する

保存する前に、一つの型を三つの小さな実験で見る。基準版、視覚変数、経路変数を分けると、失敗原因が読みやすい。

1. 基準：Redditの型を自分の条件で書き直したもの。
2. 変数A：光、カメラ、背景など一つだけ変える。
3. 変数B：文字、参照画像、レイアウトなど経路に関わる要素を一つだけ変える。

評価は好みではなく基準で行う。

平均4以上、重要項目が3未満にならず、失敗理由を説明できるときだけ保存する。偶然の一枚ではなく、再現可能な型を残す。

失敗の記録も残す

成功例だけを保存すると、ライブラリはすぐ弱くなる。必要なのは、どこで壊れたか、なぜ壊れたか、次に何をするかである。

失敗記録はチームを守る。誰かが同じReddit例を見つけても、過去にどの経路で失敗したか、どの条件なら通るか、どこから危険になるかを判断できる。

人気リストをランキング扱いしない

100件、500件、1000件のリストは、ざっと眺めるには便利である。しかし、いいね数や収集数は、自分の素材、言語、ブランド、参照画像、API、ポリシーにおける安定性を示さない。

リストから読むべきものは二つある。一つ目は、よく出る仕事の種類。商品、人物、3Dフィギュア、インフォグラフィック、食べ物、室内、広告、before/afterである。二つ目は、よく出る失敗。短すぎる指示、参照の弱さ、Proと2の違い、文字の失敗、同一性の漂い、生成と編集の混同である。

同じ問題が繰り返し語られるなら、必要なのはもう一つの長い文ではなく、経路の判断である。文字が重要なら短いラベルとPro、人物が続くなら参照画像、APIに入れるならモデルIDとリクエスト記録。この形で残すと、リストは単なる収集物ではなく作業ルールになる。

チームで使えるライブラリにする

個人メモなら自由でよいが、複数人が使うなら記録形式をそろえる。デザイナー、編集者、マーケター、開発者が同じプロンプトを見るとき、それぞれが別の失敗を見ていることがある。共通の言葉がないと、「もっときれいに」「もっと自然に」「もう少し広告っぽく」が毎回違う意味になる。

ライブラリには次の項目を入れる。

短い実行用プロンプトと、長い説明メモは分けて保存する。前者はすぐ使うため、後者はなぜその形になったのかを引き継ぐためである。説明メモがないと、数週間後には誰も直し方を覚えていない。

実例を自分の仕事へ変換する

よくある失敗は、題材だけを置き換えることである。たとえば、コミュニティで見つけた「シネマ風のコーヒーカップ広告」を、そのまま「ヘッドホン」に差し替えると、元の雰囲気は残っても仕事としては弱くなりやすい。元の強さはコーヒーカップではなく、単一主体、近いカメラ、机の質感、柔らかい横光、背景のぼけ、右側の余白にあったかもしれない。

この場合は、まず骨格を抜く。単一商品を主役にする。左から柔らかい光を当てる。背景を浅くぼかす。右側に見出しスペースを残す。不要な文字や偽ロゴを入れない。次に自分の製品条件を入れる。ヘッドホンの素材、イヤーカップの向き、ケーブルの有無、ブランド色、パッケージの扱い、EC用の余白、広告用の裁ち落としを指定する。最後に合格条件を書く。三つの出力で形状、質感、色、見出しスペースが保たれること。ここまで変えて初めて、他人の例が自分のプロンプトになる。

キャラクターでも同じである。華やかなポートレート例を見ても、保存すべきは「超高精細」「映画的」「感情的」ではない。顔型、髪、服の色、年齢感、表情、象徴物、カメラ距離、参照画像の有無である。連続したカットに使うなら、テキストだけでは足りない可能性を先に書いておく。失敗時の動きも決める。二回連続で顔が変わるなら、文章を長くするのではなく参照経路へ移る。

情報ボードではさらに慎重にする。見た目がきれいな例でも、あなたの内容に料金、上限、モデル名、規約、日付、正確な数値があるなら、モデルに自由な補完をさせてはいけない。画像内で正確に出す語、短くまとめる語、出してはいけない語を分ける。情報密度を上げたいときほど、文章を増やすより、板面の階層を決める方が安定する。

この変換を毎回行うと、ライブラリは単なる引用集ではなくなる。どの例から来たかより、どの仕事に使えるか、どの経路で試したか、どの条件で失敗するかが見える。

プロンプトを長くする前の点検

失敗した出力を見たとき、すぐ文を長くすると原因が見えなくなる。まず、失敗が意味の不足なのか、経路の不一致なのか、素材の問題なのかを分ける。

意味の不足なら、主題、場面、構図、光、禁止項目を追加する。たとえば「自然な商品写真」が弱いなら、「白いセラミック皿の上、斜め45度、朝の窓光、背景は薄いグレー、ラベルは追加しない」と書く。これは有効な加筆である。

経路の不一致なら、加筆ではなく移動が必要になる。参照画像の人物が毎回別人になるなら、文章で「同じ人」と繰り返しても限界がある。文字入りの表が崩れるなら、短いラベル、少ないブロック、Pro経路を検討する。APIで揺れるなら、モデルID、リクエスト、入力画像、時刻、出力ファイルを記録する。

素材の問題もある。入力画像が圧縮されている、商品が小さい、参照人物の角度が違いすぎる、背景が複雑すぎる、元画像に読めない文字がある。こうした場合、プロンプトだけを直しても改善しない。入力を変える、切り抜く、参照を増やす、別経路に分けるといった判断が必要になる。

この点検を省くと、プロンプトは長いのに弱くなる。強いプロンプトは、必ずしも長い文ではない。必要な指示だけが、正しい経路に対して、測れる形で入っている文である。

保存する前の短いレビュールール

最後に、保存判断を一人の好みにしない。小さなレビュー項目を決めるだけで、ライブラリの質は大きく変わる。

このレビューは重くしすぎない。目的は、創作を止めることではなく、保存する価値のある型だけを残すことにある。判断に迷うプロンプトは、まず小テスト用に置く。採用済みの欄へ入れるのは、経路、合格条件、失敗記録がそろってからでよい。

また、同じ型を別の仕事に移すときは、必ず一度は最小構成で走らせる。商品名、人物名、ブランド色、必要な文字、出力比率を一気に変えると、どの変更が失敗を生んだか分からない。まず主体だけを変える。次に光や構図を変える。最後に文字や参照を足す。この順序なら、良い型を壊さずに新しい仕事へ移せる。

保存した後も、定期的に古い記録を見直す。モデル名、経路、画面の挙動、料金、無料枠、編集機能は変わり得る。古いプロンプトを消す必要はないが、現在の制作で使う前に、短い再テストと公式情報の確認を行う。プロンプトライブラリは固定資料ではなく、検証済みの作業台として扱う方が強く、更新の責任も明確になり、チーム内の引き継ぎも楽になりやすい。

よくある質問

RedditのNano Bananaプロンプトは本当に優れている？

発見には役立つ。実際の利用者がどんな仕事を頼み、どこで失敗しているかが見えるからである。ただし、そのまま使えるとは限らない。価値は文ではなく、目的、構図、制約、経路、検証にある。

そのままコピーしてもよい？

一度試すだけならよい。仕事で使うなら、主題、ブランド、場面、比率、参照画像、文字、合格条件を置き換える。保存するのは原文ではなく構造である。

Nano Banana Proではどんな形式がよい？

出力タイプ、文字、階層、禁止事項、守る要素、判定基準を明確にした構造化形式がよい。特に情報図、表、資料風レイアウト、説明ボードで役立つ。

JSONプロンプトは必要？

チームやAPIで同じ項目を毎回使うなら便利である。だが、JSONは弱い目的を強くしない。普通の文章で構造が明確なら、それで十分な場合も多い。

まずGeminiアプリで試すべき？

視覚方向を早く見るならGeminiアプリ。対象を守るなら参照編集。文字と版式が重要ならPro。モデルID、ログ、バッチ、統合が必要ならAI StudioまたはAPIを使う。

プロンプト生成ツールは役に立つ？

抜けている項目を埋める用途なら役に立つ。仕事の目的を決める役割まで任せると危ない。余計な主張、危険な言い換え、装飾だけの語を削ってから検証する。

何度も失敗する場合は？

まず失敗を分類する。構造が曖昧なら書き直す。参照が漂うなら経路を変える。文字が弱いなら短くするかProを使う。ブロックされるなら安全な目的に戻すか停止する。