Nano Bananaでタミル語を含む画像を作るなら、スタイルより先に、タミル文字・承認済みローマ字表記・二言語レイアウトのどれを納品するか決めます。実際に表示する文字列は、タミル語に堪能な確認者が承認した形を引用符で囲み、モデルには翻訳も文字の追加もさせません。
字形確認には வணக்கம் を使います。「こんにちは/ごあいさつ」に相当する中立的な文字列であり、チェンナイ、タミル・ナードゥ、インド、特定の宗教、寺院、衣装、映画調を意味する記号ではありません。文化的な要素が必要なら、地域またはディアスポラの場所、行事、受け手、衣服、物、建築、食べ物、除外したい表現を案件ごとに指定します。
使えるプロンプトは、長い形容詞の列ではなく、次の四つを確認できる制作指示です。
- 目的:生成、置換、修復、合成、レイアウトのどれを行うか。
- 差し替え:人物、商品、場面、承認済みの文字列、比率など、案件ごとに変わる値。
- 固定:顔、肌の色、商品形状、ロゴ、構図、正確な文字、光、遠近など、変更しない要素。
- 合格条件:文字の欠落・追加・並べ替えがなく、固定要素を保ったと実寸で確認できる状態。
まず12個のテンプレートから作業に最も近いものを一つ選び、角括弧の値をすべて埋めます。初回が不合格でも全文を書き足さず、失敗した項目を一つだけ直します。
2026年7月16日時点では、大量のラフはNano Banana 2 Lite、日常的な生成や範囲を限定した編集はNano Banana 2、正確な文字・密なレイアウト・複数リファレンスはNano Banana Proが出発点です。初代Nano Bananaは旧ワークフローの互換ルートとして扱います。
テンプレート本文は無料でコピーできますが、Nano Banana Proを無料で実行できるという意味ではありません。2026年7月16日時点で、GoogleのGemini Developer API料金表は gemini-3-pro-image にFree Tierを掲載していません。Gemini Appsヘルプは、有料プランのユーザーがNano Banana 2で生成した後に「Proでやり直す」を使えると案内しています。料金、割り当て、地域別の提供状況は別の条件なので、利用前に現在の画面と公式資料を確認してください。
「コピペできる」と「どの案件でも再現できる」は別です。公開ギャラリーはアイデア探しに役立ちますが、入力画像、非公開設定、失敗例、採用までの選別を示さないことがあります。出力は固定要素と合格条件で判定してください。同じ文字列または固定要素が、入力を管理した2回の試行で連続して崩れたら、形容詞を増やすのを止めます。入力や一項目を修正する、作業に合うルートへ切り替える、工程を分ける、または文字なしで画像を作り、承認済みの文字をデザインツールで組む判断が必要です。
12枚のプロンプトカードの使い方
各カードには六つの情報があります。用途は画像作業を定義し、ルートは最初に試すモデルを示します。プロンプトは角括弧を埋めればテストできる形です。差し替えは案件変数、固定はドリフトさせない要素、合格条件は採用・却下を目で判断する基準です。
この分け方が必要なのは、生成と編集で責任範囲が異なるためです。新規生成は場面を発明できますが、編集では変更箇所と凍結範囲を同時に指定します。複数リファレンスは画像ごとに役割を割り当てます。文字入りレイアウトは正確な原稿、読む順番、誤字が一つでもあれば却下する規則が必要です。
独自の作業は、次の骨格に整理できます。
hljs text[生成 / 編集 / 置換 / 修復 / 合成]する対象:[具体的な画像作業]。 入力・リファレンス:[各ファイルの役割。ない場合は「なし」]。 文脈:[主役、環境、使用目的]。 構図:[画角、カメラ、階層、光、視覚言語]。 差し替え:[案件ごとに変更する値]。 固定:[顔、形状、正確な文字、配置など、維持する項目]。 出力:[縦横比、掲載場所、用途]。 合格条件:[採用できる可視結果と、却下する失敗]。
Googleの画像生成公式ガイドは、テキストからの生成、画像とテキストによる編集、反復編集、複数リファレンスの合成を分けています。Google CloudのNano Bananaプロンプトガイドも、明確な意図、具体的な視覚方向、カメラ言語、肯定的な指示、反復を重視します。これらはカード構造の根拠ですが、一つのテンプレートが全画像で同じ結果を出す保証ではありません。
設定値と文章も分けます。モデル、入力ファイル、出力サイズ、対応する縦横比は、利用画面やAPIリクエストで選びます。プロンプトには制作指示、変更しない条件、合格条件を書きます。文章中で「16:9」を何度繰り返しても、ルート側が対応していない出力は作れません。
現行のNano Bananaルートを選ぶ
Nano Bananaは単一モデル名ではなく、複数ルートを含む呼び名です。必要なのは万能な順位ではなく、今回の作業を最初に試す場所です。
| ルート | 最初に試す仕事 | 切り替える目安 |
|---|---|---|
| Nano Banana 2 Lite / gemini-3.1-flash-lite-image | 大量の初期ラフ、単純な構図、方向性の絞り込み | リファレンス、正確な文字、厳密な配置、却下コストが重要になる |
| Nano Banana 2 / gemini-3.1-flash-image | 日常の画像生成、範囲を限定した編集 | 顔や商品形状が崩れる、文字が重要、情報階層が密になる |
| Nano Banana Pro / gemini-3-pro-image | 正確さ、文字量、構造化レイアウト、複数リファレンス、高い審査コスト | 実際は単純なラフ、または失敗原因が入力不足にある |
| 初代Nano Banana / gemini-2.5-flash-image | 旧ワークフローの保守、過去記録の再テスト | 新規案件で互換性を保つ理由がない |
これは作業配分であり、速度や品質のランキングではありません。冒頭の短い案内は、無料でコピーできるプロンプト本文と現在のPro利用条件を分けるためのもので、料金ガイドではありません。正確な価格、割り当て、地域、第三者プロバイダーの条件は別々に変わるため、ここでは扱いません。モデルIDとルート挙動はGoogleの開発者向け資料を基準とし、その資料ではGemini生成画像にSynthIDが含まれることも説明されています。
モデルファミリー同士を比較する場合は、GPT Image 2とNano Banana Proの比較を使います。プロンプト集に別のプロバイダー選定まで背負わせると、目的がぼやけます。
テンプレートを埋める順番は、最も高くつく失敗から逆算します。商品なら形状やラベル、人物なら本人性、室内なら窓と寸法、ポスターなら一文字の誤りです。そのリスクを入力条件、固定欄、合格条件の三か所に置きます。結果が崩れたとき、次に直す一項目が明確になります。
案件用に書き換える六つの手順
最初の行から順番に穴埋めする必要はありません。採用を即座に止める失敗を先に決め、その失敗を防ぐために必要な入力と固定項目を逆算します。たとえば物理ボタンが三つあるスピーカーなら、商品名を入れるだけでは不十分です。承認済み画像を添付し、「三つのボタンの位置と間隔」を固定し、「ボタンがちょうど三つあり、参考画像と位置が対応する」を合格条件にします。四つ目のボタンが生まれた場合、次の試行では背景や色を変えず、その幾何条件だけを強めます。
実在する講師の講座カバーなら、本人写真は顔と髪の基準、服の資料は形と素材の基準、ブランド資料は色の基準です。役割を書かないと、服の写真から別人の顔を借りたり、ブランド資料の装飾を服へ貼ったりする可能性があります。入力が増えるほど、「何を参照するか」と「何を参照しないか」の両方が重要です。
最小限の作業版は次の順番で作れます。
- 主動詞を一つ決める。 一回で生成、修復、再レイアウトを同時に要求しません。
- 文章で推測できない入力を用意する。 本人、実商品、正確な原稿、固定平面などです。
- 入力ごとに所有権を割り当てる。 競合時にどの資料を優先するかも明示します。
- 本当に却下につながる固定要素を3〜7個選ぶ。 画面内の全名詞を並べる必要はありません。
- 見える合格条件を書く。 「一か所だけ変化」「全文字一致」「窓が一つずつ」のようにします。
- 最後に光、カメラ、素材、雰囲気を足す。 視覚方向は作業を支えるためのものです。
長いプロンプトが自動的に優れるわけではありません。各行に担当が必要です。「柔らかい朝日」と「真昼の強い硬い光」を同時に書いたなら、第三の形容詞を足すより競合を消す方が有効です。出力サイズのように利用画面で指定する値を、全段落で繰り返す必要もありません。
角括弧を埋めた後は、指示を声に出さずとも役割ごとに読み直します。変更対象は一つに絞れているか、入力がないのに本人性や商品形状を保証していないか、固定項目どうしが衝突していないか、合格条件を第三者が画像だけで確認できるかを点検します。「高級感がある」「魅力的に見える」のような好みだけが残った場合は、材質、余白、光の方向、読む順番などの可視条件へ置き換えます。この事前確認は再生成回数を減らすだけでなく、失敗をプロンプト、入力、ルートのどこへ戻すべきかも明確にします。
タミル文字入り画像を作る前に決めること
「タミル語のプロンプト」という言い方には、指示文をタミル語で書くこと、特定のタミル地域や行事を描くこと、画像内にタミル文字を表示することが混ざっています。指示文を理解できても文字を正しく描けるとは限らないため、まず納品する文字の形を一つ選びます。
| 納品する形 | 先に承認するもの | モデルに決めさせないこと |
|---|---|---|
| タミル文字 | タミル語に堪能な確認者が承認した原文 | 翻訳、文字の追加、似た装飾記号への置換 |
| 承認済みローマ字表記 | 対象読者に合う綴りと句読点 | 「一般的な綴り」の推測、英語風への書き換え |
| 二言語レイアウト | 両言語の原文、主従、サイズ、読む順番 | 翻訳、優先順位、追加の副見出し |
வணக்கம் は中立的な字形確認用文字列です。意味は「こんにちは/ごあいさつ」に相当しますが、特定の都市、州、国、宗教、衣装、映画、祭礼を表す記号ではありません。本番では必ずタミル語に堪能な確認者が承認した原文に置き換えてください。見た目が自然でも、モデルが作った翻訳やローマ字表記をそのまま広告原稿にはしません。
次のアダプターを、目的に合う12枚のカードへ追加します。
hljs text[生成 / 編集]する対象:[具体的な画像作業]。 言語の形:[タミル文字 / 承認済みローマ字表記 / 二言語]。 画像内に表示する正確な文字列:「வணக்கம்」 引用内の文字を一字ずつそのまま表示する。 翻訳、ローマ字化、文字の追加、反復、装飾記号への置換をしない。 タミル語の行の役割:[見出し / ラベル / キャプション / なし]。 第二言語と階層:[正確な原文、主従、サイズの関係 / なし]。 文脈:[具体的な地域またはディアスポラの場所、行事、受け手、目的]。 含める文化要素:[確認済みの衣服、物、食べ物、建築、行事要素、色、環境]。 「タミル」という語だけから、宗教、カースト、政治、著名人、 儀礼の意味を推測しない。上で指定したものだけを含める。 固定:[本人性、商品形状、承認済みロゴ、正確な文字、レイアウト]。 出力:[縦横比、形式、掲載場所]。 合格条件:タミル文字が承認原文と一致し、余分な文字がなく、 すべての固定要素が維持されている。
引用符は魔法の構文ではなく、検査対象を分離するための欄です。完成画像を実寸で開き、綴り、句読点、空白、語順、欠落・追加文字、最終的な字形を原文と比較します。タミル文字に英語の大文字・小文字チェックを当てはめる必要はありません。単純なラベルや初期レイアウトならNano Banana 2から始められます。複数の文字ブロック、密な階層、却下コストの高い案件はProの方が妥当な出発点ですが、正確さを保証するものではありません。
ポスター・サムネイル:見出しを一度だけ表示する
文字そのものがメッセージになるイベント告知、SNSサムネイル、招待状、店頭カードでは、見出しの原文と置き場所を同じ検査対象にします。
hljs text[受け手と目的]向けの[ポスター / サムネイル / 招待状]を生成する。 正確なタミル語見出し:「வணக்கம்」 見出しは一度だけ、文字単位で一致させ、最優先の文字として表示する。 翻訳、ローマ字化、省略、重複、副見出しの追加をしない。 上部の[割合]を、十分なコントラストと字間を持つ見出し領域として空ける。 場面:[具体的な主役、行動、場所、時間]。 文化要素:[この案件で確認済みの項目だけ]。 方向性:[色、光、カメラ、質感、雰囲気]。 固定:[本人性 / 行事の象徴 / 商品 / ロゴ / 必要な余白]。 出力:[縦横比と掲載場所]。 合格条件:見出しが実寸で承認原文と一致し、最初に読まれ、 一度だけ表示され、指定していない文化記号がない。
二言語にするなら、第二言語も別の正確な文字列として渡し、大小関係を数値で書きます。たとえば「タミル語見出しを100%、日本語訳を45%」のようにします。「二言語にする」だけでは、翻訳、順番、強調の判断までモデルへ渡してしまいます。
カップル・ポートレート:権利と本人性から始める
実在人物を編集する場合、雰囲気より先に、画像をアップロードして編集する権利と本人性の固定が必要です。「タミルのカップル」だけでは、地域、行事、服装、宗教、婚姻関係を特定できません。必要な背景と変更点を具体的に書き、指定していない属性を追加させません。
hljs text本人たちの許可を得た添付ポートレートを編集する。 変更するのは[背景 / 衣服 / 光 / 承認済みキャプション]だけ。 二人の顔、肌の色、年齢、生え際、体格、表情、姿勢、手の位置、 二人の関係が見える配置を変更しない。 場所:[具体的な実在場所または行事の文脈]。 承認済みの衣服・物:[確認済みの具体項目]。 任意の正確なタミル語キャプション:「வணக்கம்」 使う場合は一度だけ表示し、翻訳も文字の追加もしない。 明示されていない宗教、カースト、民族、政治、結婚、著名人、 経済状況を推測して加えない。肌の色、年齢、体形、顔を変えない。 出力:[縦横比と用途]。 合格条件:同じ二人だと認識でき、承認済みの変更だけが起こり、 文化要素と文字をこの指示へ一つずつ対応づけられる。
顔が変わったら、スタイル語を減らし、各リファレンスの役割と顔の固定項目を強めます。本人性は合っていて背景だけが曖昧なら、「タミル風」を、確認済みの場所、行事、衣服、物から2〜3項目へ置き換えます。未成年者、公人、故人を含む画像は、一般的な「許可済み」という一行だけでは十分な権利確認になりません。
商品カード・図解:商品事実と文字を別々に固定する
商品や情報ボードでは、タミル文字の誤りと商品情報の捏造を別々に検査します。各リファレンスに一つの役割を与え、背景を説明する前に商品形状と承認済み情報を固定します。
hljs text[用途]向けの[商品カード / 比較パネル / 図解]を生成する。 リファレンス1を商品形状、素材、ロゴ、包装の基準にする。 リファレンス2は[色 / レイアウトのリズム / 光]だけの基準にする。 正確なタミル語見出し:「வணக்கம்」 その他の承認済みラベル:[ラベルごとに引用した文字列 / なし]。 各文字列は一度だけ表示し、利点、価格、バッジ、材料、仕様、 脚注、翻訳文を捏造しない。 階層:[見出し、商品、根拠、行動、必要な余白]。 商品輪郭、操作部、素材の境界、承認済みロゴ、SKU、数値、通貨、 単位、ラベル順、正確な文字を固定する。 出力:[縦横比、寸法、掲載場所]。 合格条件:商品がリファレンス1と一致し、すべてのタミル語ラベルが正確で、 読む順番が明確で、根拠のない主張がない。
図解の数値や説明は、画像とは別に所有資料へ戻って確認します。レイアウトが正しく見えても、ラベルや数字をモデルが作っていれば納品できません。
タミル文字で失敗した項目だけを直す
不合格になったら、文字・本人・商品・文化要素・階層のどれが失敗したかを一つ決めます。次の試行で全部を書き換えると、どの修正が効いたか分かりません。
| 見える失敗 | 最初の一変更 | 中止または工程を切り替える条件 |
|---|---|---|
| 字形が違う、欠ける、結合する、別の文字になる | 承認済み原文を独立した引用欄へ貼り直し、周囲の文字を減らし、表示領域を広げる | 同じ文字列が管理された2回の試行で失敗したら、文字なしで画像を作り、デザインツールで承認済み原文を組む |
| 翻訳、重複、余分な単語が入る | 「一度だけ表示。翻訳・ローマ字化・反復・文字追加をしない」と書き、競合する原稿を外す | 検査できる量を超える文字ブロックが必要になる |
| 顔や商品が変わる | リファレンスの役割を分け、実際に変わった3〜7個の固定項目だけを強める | 元画像が弱い、競合する、または利用権を確認できない |
| 文化的に曖昧または不正確 | 「タミル風」を、確認済みの場所、行事、衣服、食べ物、物、建築へ置き換える | 文化的な意味を確認できない、または暗示する許可がない |
| 文字があふれ、読む順番が崩れる | 行数を減らし、主・従の比率を指定し、文字領域を広げる | 実際の掲載サイズで読める大きさを保てない |
文字なしで生成して後から組版する方法は、生成の失敗を成功扱いする抜け道ではありません。「モデルがビジュアルを作成し、タミル語に堪能な確認者が原文を承認し、デザイン担当が最終文字を配置した」という工程引き継ぎとして記録します。実在人物、ロゴ、商品、参照画像を使う場合は、アップロードと編集の権利、最終用途、行事固有の文化的意味も公開前に確認してください。
ゼロから画像を作る六つのプロンプト
元画像がなくても固定要素は必要です。商品形状、空間の幾何、視線の階層、正確な原稿、文字を置く余白は、新規生成でも簡単に変わります。
1. 映画のワンシーン
用途: 行動、場所、カメラ位置、光源の関係が明確な映画スチルを作るとき。
ルート: Nano Banana 2から開始。正確な文字、複数リファレンス、厳格なレイアウトも含む場合だけProを検討します。
hljs text[被写体]が[具体的な行動]をしている映画のワンシーンを生成する。 場所と時間:[環境]。物語の瞬間:[直前・直後に起きること]。 [ロング / ミディアム / クローズ]、カメラは[高さと角度]、 [レンズの印象]で前景・中景・背景の関係を明確にする。 主光源は[実在する光源]、影と色の挙動は[説明]。 雰囲気は[二つの具体語]。文字ではなく場面で表現する。 [衣装、主要小道具、建築、色のアンカー]は変えない。 字幕、枠、ロゴ、無関係な人物を追加しない。 出力:[縦横比と使用場所]。 合格条件:行動が一目で読め、被写体が背景から分離し、固定要素が残る。
差し替え: 被写体、行動、環境、物語、画角、レンズ、光、雰囲気、出力。固定: 継続する衣装、主小道具、建築、ブランド色。合格条件: 見た人が「誰が何をしているか」を一文で言え、余計な人物や文字がないこと。
「壮大」「映画的」を重ねるより、物語の瞬間を指定する方が関係を作れます。きれいでも静止した印象なら、モデルを変える前に行動かカメラとの距離を直します。
2. 商品のヒーロー画像
用途: ECや広告向けに、商品表面、比率、光、コピー用余白を管理するとき。
ルート: コンセプトはNano Banana 2。包装文字、実物形状、ブランド審査が厳しい場合はProから始めます。
hljs textアップロードした商品リファレンスを基に、[商品]のヒーロー写真を生成する。 リファレンスを形状、素材、操作部、包装比率の参照基準とする。 [表面]の上、[ブランドに合う環境]に置き、カメラは[角度と切り取り]。 [キーライト]、[補助光]、[影の挙動]で[重要な素材]を見せるが、 商品の設計は変更しない。 [位置]に[量]のきれいなコピー用余白を残す。 輪郭、ボタン位置、素材の境界、包装比率、承認済みロゴ、 文字「[確認済み原文]」を固定する。 端子、ラベル、付属品、反射、商品機能を捏造しない。 合格条件:実物と一目で対応し、文字が正確で、余白を使用できる。
差し替え: 商品、台、環境、カメラ、照明、素材、余白、原文。固定: 輪郭、操作部、継ぎ目、ロゴ、ラベル、包装比率。合格条件: 同じ商品であり、存在しない機能がなく、余白が小物で埋まっていないこと。
実物リファレンスがない場合は「コンセプト画像」と呼びます。文章だけで実在商品の端子やラベルが正しいとは証明できません。
3. ビジネス・編集ポートレート
用途: 表情、服装、背景、カメラを用途に合わせた人物写真を作るとき。
ルート: 架空人物はNano Banana 2。実在人物の本人性を複数入力で守る場合や、正確な文字も含む場合はPro。
hljs text[人物または架空人物]の[用途]向けポートレートを生成する。 入力がある場合、リファレンス1は本人性だけ、 リファレンス2は[服装または色]だけの基準とし、背景は無視する。 表情と視線:[具体的な説明]。 服装:[形、フィット、素材、色]。背景:[簡潔な環境と奥行き]。 カメラ:[顔 / 半身 / 環境]、[高さと角度]、[レンズと被写界深度]。 光:[主光の方向と硬さ]、[弱い輪郭光]。 顔の構造、肌色、生え際、年齢、体格、承認済みアクセサリーを固定する。 別人化、若返り、装飾品の追加をしない。 合格条件:本人性が安定し、表情が用途に合い、顔・髪・手が自然。
差し替え: 人物、用途、入力役割、表情、服、背景、画角、光。固定: 本人性、年齢、肌、顔、生え際、体格、アクセサリー。合格条件: 用途を満たし、頼んでいない美化や年齢変更がないこと。
「フォトリアル」は本人性の条件ではありません。顔が変わるなら入力役割を強め、顔が合っていて印象だけ違うなら表情や撮影距離を変えます。
4. フードの編集写真
用途: 料理の層、量、食卓の文脈を保ちながら、おいしさを可視化するとき。
ルート: Nano Banana 2。正確なメニュー文字や密な誌面も含むときはPro。
hljs text[料理]を[提供・食べる瞬間]で撮影した編集写真を生成する。 料理の構造:[層、断面、ソース、湯気、焼き目、飾り]を見せる。 [器]に盛り、[テーブル素材]の上に置き、補助物は[2〜3点]だけ。 カメラは[真上 / 45度 / 卓上]、切り取りは[説明]。 光は[方向]から入り、影は[硬さ]、[主要な質感]に自然なハイライト。 料理を定義する材料、個数、器の形、[重要要素]の位置を固定する。 余計な飾り、重複した食器、プラスチック感、画像内文字を加えない。 合格条件:構造が読め、食べられる質感で、小物が主役を奪わない。
差し替え: 料理、瞬間、断面、器、台、補助物、カメラ、光。固定: 材料数、層、量、文化的な盛り付け、主な飾り。合格条件: 料理として成立し、別の材料が勝手に加わっていないこと。
「おいしそう」だけでは作業になりません。断面、つや、湯気、衣、焦げ目、ソースの流れを見える状態で指定します。
5. インテリア案
用途: 幾何、素材、家具、採光が矛盾しない室内を作るとき。
ルート: 一室ならNano Banana 2。複数の参考資料や図面に近い階層を守る場合はPro。
hljs text[部屋]を[利用者と目的]向けに可視化する。 寸法と開口:[簡潔な幾何説明]。 [主要家具]を[窓、扉、動線との関係]に配置し、 [副家具]を通路を塞がない位置に置く。 素材:床[ ]、壁[ ]、造作[ ]、布[ ]。 自然光は[方向と開口]から入り、[実在する照明]で補う。 カメラは[高さと場所]から[優先する関係]を見せる。 扉と窓の数・位置、部屋比率、造作、必須家具数を固定する。 不可能な角、開口の重複、浮く物、部屋の勝手な拡張を作らない。 合格条件:歩ける動線があり、開口が固定され、素材を区別できる。
差し替え: 部屋、利用者、幾何、家具、素材、光、カメラ。固定: 開口、造作、比率、家具数、動線。合格条件: 現実に建てて歩ける関係で、必須物が一度ずつ存在すること。
部屋が歪む場合、スタイル語ではなく広角を弱め、固定開口を再記述し、構図を一つだけ変えます。
6. アイコン・ロゴのコンセプト
用途: 商標審査済みの完成データではなく、独自の視覚方向を探すとき。
ルート: シルエット探索はNano Banana 2。正確なワードマークやブランドボードを含むならPro。
hljs text[ブランドまたは機能]のオリジナルアイコン案を生成する。 [一つの意味]を[比喩]で表現する。 主シルエットは一つ、補助形状は最大[数]、色は[限定色]、背景[ ]。 小さなアプリアイコン表示でも認識できる形にする。 [幾何 / 有機 / モノライン / 切り紙]構造、角・線・余白は[説明]。 比喩、シルエットの均衡、限定色、周囲の余白を固定する。 既存商標の模倣、モックアップ背景、未承認の文字を加えない。 合格条件:縮小しても意味が伝わり、余計な記号や文字がない。
差し替え: ブランド、意味、比喩、形状数、色、背景、構造。固定: 比喩、輪郭、色、負の空間、未承認文字の除外。合格条件: 小さくても認識でき、提供した方向と区別できること。
商標調査、法的判断、ベクター化は別工程です。完成して見える生成案をそのまま登録・納品可能とはみなしません。
編集と修復に使う三つのプロンプト
編集では変更範囲を明確にします。元画像、変更する箇所、変更しない範囲を同時に書きます。「もっと良くする」だけでは、守るべき部分まで再設計する余地を与えてしまいます。
7. 一要素だけ変更する
用途: 一つの物、色、素材、局所領域だけを変え、残りを維持するとき。
ルート: Nano Banana 2。対象に正確な文字やブランド形状、複数入力が関わるならPro。
hljs textアップロード画像を編集する。[対象]だけを[現在]から[新しい状態]へ変更する。 元画像の遠近、焦点深度、光向き、影の硬さ、反射、粒子、色応答に合わせる。 それ以外は概念上固定する:[本人性]、[姿勢]、[商品形状]、[背景]、 [切り取り]、[文字]、[未変更の物]。 全体の再スタイル、カメラ移動、小物追加、無関係な改善をしない。 合格条件:指定変更が見え、未編集部分が位置・本人性・光・構図で一致する。
差し替え: 対象、旧状態、新状態、元画像固有の固定リスト。固定: 対象外すべて、特に顔、カメラ、文字、商品形状、影、背景。合格条件: 元と結果の意図した違いを一つだけ説明できること。
無関係な変更は順番に行います。服、場所、季節、カメラ、光を同時に変えると、失敗原因を追えません。
8. 写真の修復・画質改善
用途: 傷、ノイズ、色かぶり、露出を減らし、本人や文書の詳細を捏造しないとき。
ルート: Nano Banana 2。顔、包装、文書の正確さが却下条件ならPro。
hljs textアップロードした[写真またはスキャン]を修復する。 [ほこり、傷、退色、ノイズ、色かぶり、露出]を補正し、 構図、年代、本人性、顔、服、商品特徴、印刷文字、自然な質感を維持する。 元画像が裏付ける詳細だけを回復する。 肌、布、紙、素材の粒子を残す。 蝋のような肌、まつ毛、装飾品、偽ロゴ、シャープの縁、 元で読めない文字を作らない。 合格条件:損傷が目立たず、同じ人物・物・時点・記録のままである。
差し替え: 元の種類、損傷、保護すべき歴史・商品詳細、用途。固定: 本人、年代、構図、服、質感、読める原文、不明箇所の不確実性。合格条件: きれいになっても新しく発明されたように見えないこと。
存在しない証拠は復元できません。読めない顔やラベルは、目的が明示的な創作再構成である場合だけ再構成と呼びます。
9. 服と背景を同時に替える
用途: 人物、姿勢、カメラ、体格を維持しながら、関連する二点を変えるとき。
ルート: 一つの元画像はNano Banana 2。本人・衣装の複数資料を調整するならPro。
hljs textポートレートを編集し、変更は次の二つだけに限定する。 1. [現在の服]を[新しい服、形、素材、色]へ置換する。 2. 背景を[新しい環境と奥行き]へ置換する。 本人性、顔、肌、髪、体格、姿勢、手、視線、カメラ、切り取り、表情を固定する。 新しい服は元の姿勢と光に従い、背景の遠近と光向きは人物と一致させる。 年齢、体型、化粧、装飾品、顔立ちを変えない。 合格条件:同じ人物と姿勢で、服が自然に合い、背景と光が一つに見える。
差し替え: 旧服、新服、素材、色、環境、奥行き。固定: 本人、年齢、顔、体格、手、表情、カメラ、アクセサリー。合格条件: 服と背景以外が変わらず、一つの場所で撮ったように見えること。
リファレンスとレイアウト用の三つのプロンプト
入力には一枚ずつ役割が必要です。一枚は本人の基準、一枚は衣装の基準、一枚は姿勢や構図の基準にします。「これらを参考にする」だけでは役割の衝突を解決できず、背景や顔が混ざります。
10. 同じキャラクターを維持する
用途: 新しい姿勢、行動、場所でも同じキャラクターと分かる必要があるとき。
ルート: 少数資料はNano Banana 2。資料、道具、パネルが多く審査コストが高いならPro。
hljs text入力画像の役割を分けて、キャラクターの新しい場面を生成する。 - リファレンス1:顔、年齢、肌、髪。 - リファレンス2:衣装構造、素材、色の配置。 - リファレンス3:[道具またはポーズ言語]だけの基準。本人性には使わない。 キャラクターを[新しい場所]で[行動]させ、[画角と角度]で描く。 顔、生え際、体の輪郭、衣装構造、特徴色、[専用アンカー]を固定する。 姿勢、表情、環境、カメラは指定どおり変更してよい。 顔や背景を混ぜず、衣装部品数を変えず、新アクセサリーを足さない。 合格条件:資料なしでも識別でき、各資料の役割が交差していない。
差し替え: 役割、行動、場所、画角、アンカー。固定: 顔、髪、輪郭、衣装、色、道具、部品数。合格条件: 保持要素を正しい資料へ対応づけられ、役割混同がないこと。
11. 正確な文字入りポスター
用途: 原稿、階層、読む順番そのものが納品物に含まれるとき。
ルート: Nano Banana Proから開始。後で確定的なデザインツールで文字を入れるなら、生成は背景だけを担当する別ワークフローです。
hljs text[目的]向けの[ポスター / イベントカード / SNS画像]を生成する。 表示する文字は次の原文だけ。他の単語を追加しない。 見出し:「[正確な見出し]」 副見出し:「[正確な副見出し]」 詳細:「[日付、時刻、CTAの正確な文字]」 読む順番:見出し、[主ビジュアル]、副見出し、詳細。 方向性[ ]、色[ ]、書体の印象[ ]、間隔[ ]。 [掲載場所]向けに[安全余白]を残す。 綴り、句読点、大小、行順、ブランド色、ロゴ位置を固定する。 疑似文字、バッジ、価格、追加CTAを作らない。 合格条件:全ての文字が原文と一致し、対象サイズで順番どおり読める。
差し替え: 形式、目的、原稿、主役、階層、色、書体、掲載。固定: 一文字ずつ、句読点、行順、ロゴ、余白。合格条件: 文字単位で比較し、余分・欠落・誤字が一つでもあれば却下。
一行だけ何度も失敗するなら、生成させる文字量を減らすか、確定的な組版へ移します。見た目が良くても誤字は合格にしません。
12. 図解・複数リファレンス合成
用途: 情報ボードや比較図で、複数資料の役割を混同させたくないとき。
ルート: 階層、正確なラベル、複数入力が中心ならNano Banana Pro。
hljs text[対象者と判断]向けの[技術図解 / 比較ボード / 複数資料合成]を生成する。 入力の役割: - リファレンス1:[主役または商品事実]。 - リファレンス2:[スタイルまたは色]だけ。 - リファレンス3:[図の構造または構図]だけ。 読む順番:[第一]、[第二]、[第三]、最後に[判断]。 確認済みラベル「[1]」「[2]」「[3]」だけを使用する。 [関係、順序、対比]を見せ、提供されていない数値を加えない。 出典の同一性、ラベル、階層、ブランド色、事実と例示の境界を固定する。 役割を混ぜず、統計や宣伝文を捏造しない。 合格条件:判断経路が明確で、ラベルが正しく、事実を入力へ追跡できる。
差し替え: 形式、対象者、判断、入力役割、読む順番、ラベル、関係。固定: 事実、同一性、階層、役割境界、ブランド色。合格条件: 順序に曖昧さがなく、全事実を人が検証できること。
画像モデルは与えられた事実を整理できますが、事実の情報源にはできません。数値、主張、ラベルは公開前に所有資料へ戻って確認します。
プロンプトが失敗する六つの原因
最初に失敗した項目を決め、形容詞を足す前にその指示を直します。
| 原因 | 見える症状 | 最初の修正 |
|---|---|---|
| 操作が違う | 編集が新規生成になり、修復が再設計になる | 生成、編集、置換、修復、合成、レイアウトの動詞から始める |
| 入力不足 | 本人、商品、文字、配置を守る根拠がない | 元画像や引用原稿を追加し、スタイル語で補わない |
| 固定が弱い | 変更は成功しても顔、形、切り取り、背景が崩れる | 変えない範囲を列挙する |
| 指示が競合 | カメラ、光、文字、空間要求が両立しない | 各項目の条件を一つに絞る |
| ルート違い | 密な文字や複数資料がラフ向けルートで崩れる | 同じ基準を適切なルートで再テストする |
| 不可能・不適切 | 証拠の捏造や欺瞞が必要になる | 中止し、正当な作業へ狭める |
被写体、光、カメラ、色、ルートを同時に変えないでください。画像内容の指示ではなくサービスやリクエストのエラーなら、Nano Banana Proのトラブル対処へ切り替えます。
同じプロンプトを一項目だけ変えて試す
- 目的とルートを固定する。 入力、比率、固定リスト、合格条件を変えません。
- 基準版を生成する。 「ロゴ文字が変わった」「窓が移動した」など見える失敗を記録します。
- 一項目だけ変える。 対象を狭める、役割を指定する、競合を消す、固定文を強めます。
- 同じ基準で比べる。 主役、配置、固定要素、合格条件を比較し、雰囲気点数にしません。
- 一つの判断をする。 通過なら保存、原因が一つなら書き直し、同じ固定要素を壊すなら破棄。
2回ルールは能力の永久判定ではなく、予算の境界です。現在のプロンプト・入力・ルートの組み合わせに、根拠のない再生成を追加しないための規則です。入力を変える、ルートを変える、段階化する、確定的な編集へ移す判断をします。
記録には入力の版、ルート、設定、全文、実行日時、基準の失敗、一つの変更、最終判断を残します。「良くなった」では再現できません。「包装の2行目が消えた」「左窓が二枚に増えた」のような観察なら、別の担当者も同じ検査をできます。
チームでは生成担当と検査担当を分けることもできます。検査担当は、どのモデルが高価か、どの画像が派手かを知らなくても構いません。あらかじめ決めた固定要素と合格条件だけを見て、通過・再試行・破棄を判断します。これにより、見栄えが良いのに商品形状や文字が間違っている出力を採用しにくくなります。
比較時には元入力も版管理します。切り取り、圧縮、色補正が変わった画像は新しい入力です。以前の成功率や失敗理由をそのまま引き継ぎません。縦横比、出力寸法、利用画面の設定も別欄へ残し、プロンプト本文に暗黙に含まれていると仮定しないでください。
判断は三つだけに絞れます。全固定要素と合格条件を満たせば保存、一つの原因と次の一変更を説明できれば書き直し、同じ固定要素が二度崩れるか存在しない証拠を要求するなら破棄です。判断語を統一すると、別ルートへ移っても同じ比較基準を維持できます。
合格した後にプロンプトを保存する
ライブラリには文章だけでなく、作業条件と試験結果を保存します。
hljs json{
"name": "product-hero-soft-window-light",
"job": "商品ヒーロー画像",
"route": "gemini-3.1-flash-image",
"inputs": ["承認済み商品リファレンス"],
"replace": ["台", "環境", "カメラ", "光"],
"protect": ["輪郭", "操作部", "承認ラベル"],
"pass_check": "実物一致、正確なラベル、使える余白",
"test": {
"baseline_failure": "ラベルが変わった",
"single_change": "原文を引用し、追加文字を禁止した",
"decision": "save"
},
"checked_on": "2026-07-16"
}
変動する事実は創作プロンプトから分離します。モデルID、ルート状態、対応比率、API形式には日付と公式資料が必要です。価格、上限、無料枠、地域、プライバシー、商用条件は、それぞれの最新資料で確認します。
ギャラリー、GitHub、掲示板、動画は、被写体語、カメラ、光、編集動詞、構図の発見に使えます。人気数や選抜画像、「毎回成功」という見出しを自分の合格条件にはしません。
よくある質問
12個のプロンプトはそのままコピペできますか?
全ての角括弧を置き換え、必要な入力を用意すればテストできます。ただし固定要素と合格条件は案件固有です。実商品リファレンスのない商品カードや、正確な原稿のないポスターカードは準備未完了です。
写真編集にはどのプロンプトが向いていますか?
「アップロード画像の[対象]だけを[旧状態]から[新状態]へ変更し、[本人、姿勢、カメラ、切り取り、光、背景、文字]を固定する」という最も狭い変更条件から始めます。
画質を上げたいときは何と書きますか?
ノイズ、露出、色かぶり、傷、ぼけ、圧縮など、見える欠陥を指定します。そのうえで本人性、年代、素材、印刷文字、不明箇所を捏造しないよう固定します。「高画質化」だけでは範囲が広すぎます。
Nano Bananaでタミル文字を正確に表示するには?
タミル語に堪能な確認者が承認した原文を、独立した引用文字列として渡します。翻訳、ローマ字化、文字の追加、反復を禁止し、十分な文字領域を確保したうえで、実寸の画像を原文と比較してください。ローマ字表記が必要なら、対象読者に承認された綴りも指定します。文字量や階層が密ならProが妥当な出発点ですが、正確さの保証ではありません。同じ文字列が管理された2回の試行で崩れたら、文字なしで画像を生成し、デザインツールで承認済み原文を組みます。
Lite、Nano Banana 2、Proのどれを選びますか?
日常作業はNano Banana 2、大量の単純ラフはLite、正確な文字・密なレイアウト・複数リファレンス・高い却下コストはProから始めます。初代は旧工程の互換用です。
JSONでプロンプトを書く必要はありますか?
創作指示は自然文の方が読みやすく、直しやすい場合が多いです。JSONはアプリの項目、ログ、保存に向きます。モデルと設定はAPIリクエスト、視覚指示と固定・合格条件はpayloadに置きます。
公開プロンプト集は信頼できますか?
表現や構図を探す入口としては有用です。ただし、ルート、設定、入力、選別、再現性まで証明するとは限りません。アイデアを取り、自分の固定要素と基準で基準テストを行います。
同じ失敗が2回続いたらどうしますか?
無目的な再生成を止めます。一項目、入力不足、ルート変更で直せるかを判断し、直せないならテンプレートを破棄、工程分割、確定的編集へ切り替えます。形容詞の追加は診断ではありません。
長く使える単位は「魔法の一文」ではなく、プロンプトと検査の組です。操作、入力、変数、固定要素、ルート、採用・却下できる結果が揃って初めて制作資産になります。



