Geminiで写真を作るときは、長い「魔法の一文」より、Replace(案件ごとに差し替える値)・Protect(変えてはいけない要素)・Pass check(目で確認できる合格条件)を分けた方が修正しやすくなります。下の8個から目的に近いものを選び、角括弧をすべて埋めてGemini Appsへ貼り付けてください。
新規生成と写真編集は、同じ指示ではありません。新規生成は入力写真がないため、構図や光を一から指定します。編集では、どの入力画像を使うか、何だけを変えるか、何を固定するかまで書きます。特に日本語を画像内に入れる場合は、出力を原寸で開き、承認済み原稿と文字単位で完全一致するかを確認してください。1文字の置換、脱落、余計な句読点でも不合格です。
この記事はGemini Apps向けです。Developer APIのモデル名、料金、サイズ指定、参照画像上限をGemini Appsへ読み替えるものではありません。2026年7月22日に確認したGoogleのGemini アプリ画像ヘルプでは、画像の新規生成、アプリ内画像やアップロード画像の編集、複数画像を使った生成が別の操作として案内されています。利用可否はアプリの版、言語、国、年齢、アカウント種別などで変わるため、手元の画面に「画像」機能がない場合はプロンプトを書き換えて回避しようとせず、現在の公式案内を確認します。
コピペ前に決めるのは三つだけ
まず、次の三行を案件メモに書きます。
hljs textReplace:今回だけ変える値(被写体、背景、比率、正確な文字列など) Protect:元画像から維持する値(顔、商品形状、構図、影、ロゴなど) Pass check:採用できる可視結果と、却下する失敗
角括弧はGemini専用の命令記号ではありません。コピー後に人が埋める欄です。[商品名] や [背景色] を残したまま送信しないでください。
| したい作業 | 選ぶテンプレート | 最優先の確認 |
|---|---|---|
| 架空人物の写真を一から作る | 1. ポートレート生成 | 画角、光、表情、手や背景の破綻 |
| 写真の一部分だけ直す | 2. 一点だけ変更 | 指定外のドリフトがないか |
| 背景を差し替える | 3. 背景置換 | 輪郭、影、遠近感 |
| EC用の商品写真を作る | 4. 商品ビジュアル | 形状、ラベル、ロゴ |
| 日本語入りの告知画像を作る | 5. ポスター | 承認済み原稿との完全一致 |
| 複数素材を一枚にまとめる | 6. 多画像合成 | 各入力の役割が混ざっていないか |
| 人物写真を別の画風にする | 7. スタイル変換 | 同意、開示、外見の無保証 |
| ほぼ良い出力を直す | 8. 一項目修復 | 一度に一つだけ変えたか |
1. 架空人物のポートレートを生成する
実在人物に似せる必要がないプロフィール用のイメージから始めます。顔だけでなく、画角、目線、光の方向、背景の距離まで書くと、何を採用するか判断しやすくなります。
hljs textOperation:新規画像を生成する。入力画像は使用しない。 Subject:実在人物を参照しない架空の成人。[年齢層]、[服装]、[髪型]、[表情]。 Context:[用途]に使うポートレート。背景は[背景の場所または色]。 Composition:[胸上/腰上]、カメラは目線の高さ、[正面/斜め45度]、余白は[方向]に確保。主光は[方向]からの[柔らかい/硬い]光。 Replace:[年齢層]、[服装]、[髪型]、[表情]、[用途]、[背景]、[画角]、[光]。 Protect:人物は1人のみ。文字、ロゴ、余分な手、背景の群衆を追加しない。 Output intent:[掲載先]向けの[縦/横/正方形]写真。自然な肌の質感で、過度な美肌加工は避ける。 Pass check:人物が1人、指定した画角と目線、光の方向、表情、余白になっている。手、歯、眼鏡、耳、背景に目立つ破綻がなく、文字やロゴがない場合のみ合格。
架空人物を作ったつもりでも、実在する誰かの写真だと誤認させる用途には使いません。人物の属性や経歴を出力だけから事実として付け足さないでください。
2. 写真の一点だけを変更する
「もっと良くして」では変更範囲が広すぎます。このテンプレートは、変更対象を一つの部位または物に限定し、それ以外を固定します。
hljs textOperation:アップロードした画像Aを編集し、[変更対象]だけを[変更後の状態]に変える。 Subject/Input:画像Aが唯一の元画像。[変更対象]は画像内の[位置]にある。 Context:[用途]のための局所修正。 Composition:元画像の切り抜き、カメラ位置、被写体の大きさ、奥行きを維持する。 Replace:[変更対象]、[変更後の状態]、[用途]、[位置]。 Protect:人物の顔・肌・髪・体形、衣服のうち変更対象外の部分、背景、光、影、色調、トリミングを変更しない。新しい物や人物を追加しない。 Output intent:元画像と同じ構図で、指定箇所だけが変わった編集画像。 Pass check:元画像と並べ、指定箇所だけが変わっている。顔、輪郭、背景、影、色調、切り抜きに変化が見つかったら不合格。
実在人物の写真を編集する場合は、アップロードと編集に必要な権利・本人の同意を先に確認します。本人に知らせず外見や状況を変え、事実の写真として見せる用途には使わないでください。
3. 背景を置き換え、輪郭と影を確認する
背景置換は「背景だけ」でも、髪の毛、透明素材、床の接地影、レンズの遠近感が崩れやすい作業です。背景の説明より、つなぎ目の合格条件を具体化します。
hljs textOperation:画像Aの前景被写体を残し、背景だけを[新しい背景]へ置き換える。 Subject/Input:画像Aの[人物/商品/物体]を前景として使用する。 Context:[掲載先]で使う自然な背景差し替え。 Composition:元の被写体サイズ、カメラ角度、焦点距離の見え方、切り抜きを維持。新背景の地平線と消失点を元画像に合わせる。 Replace:[新しい背景]、[時間帯]、[背景の明るさ]、[掲載先]。 Protect:前景の輪郭、髪や毛先、透明部分、商品形状、ラベル、ロゴ、姿勢、元の接地位置を変えない。 Output intent:前景と背景の光、色温度、遠近感が矛盾しない一枚。 Pass check:輪郭に白い縁や欠けがなく、接地影の向きと光源が一致し、遠近感が自然。前景の形状・ラベル・顔・切り抜きが元画像から変わっていない場合のみ合格。
元画像と結果を同じ倍率で重ねられるなら、前景の輪郭と切り抜きを確認しやすくなります。背景編集の考え方をもう少し広く整理したい場合は、既存の/ja/blog/ai-image-generator-from-imageも参照してください。
4. EC商品写真を作り、形状とラベルを守る
商品写真では「高級感」より先に、売る物が別物になっていないことを確認します。元商品の形状、開口部、部品数、ラベルの文字、ロゴ比率を固定します。
hljs textOperation:画像Aの商品を使い、[販売チャネル]向けのEC商品写真を作成する。 Subject/Input:画像Aの商品が唯一の製品参照。商品名は「[承認済み商品名]」。 Context:[季節/利用場面]を感じるが、商品を隠さない撮影セット。 Composition:商品を[中央/三分割位置]に配置し、[背景色]の背景、[光の方向]からの柔らかい光、商品下に自然な接地影。余白は[用途]の文字配置分を残すが、この画像には文字を追加しない。 Replace:[販売チャネル]、[商品名]、[季節/場面]、[配置]、[背景色]、[光]、[用途]。 Protect:商品の外形、寸法比、部品数、蓋・持ち手・ボタンの位置、素材、色、既存ラベル、ロゴの形と比率を変更しない。架空の認証、受賞、機能を追加しない。 Output intent:商品一覧または商品詳細のメイン画像候補。 Pass check:画像Aと比較し、外形、部品、色、ラベル、ロゴが一致する。余分な付属品や文字がなく、影と接地面が自然で、商品が背景に埋もれていない場合のみ合格。
AI画像だけで商品の仕様、安全性、認証、実寸を証明することはできません。購入判断に関わる表示は、商品台帳や実物確認と照合します。
5. 日本語入りポスターを作り、1文字ずつ照合する
Googleの現行ヘルプは画像内テキストの改善を案内していますが、綴りの完全一致を保証してはいません。日本語は、読みやすく見えるかではなく、承認済み原稿と完全一致するかで判定します。
hljs textOperation:[イベント告知/SNS投稿/動画サムネイル]を新規生成する。 Subject/Input:[主役となる被写体]。入力画像を使う場合は画像Aを主役参照として使用する。 Context:[対象読者]に向けた[掲載先]用の告知画像。 Composition:[縦/横/正方形]。視線順は、見出し→日時→補足→主役。文字の周囲に十分な余白を残し、背景とのコントラストを確保する。 Replace:見出し「[承認済み見出し]」、日時「[承認済み日時]」、補足「[承認済み補足]」、[主役]、[対象読者]、[掲載先]、[比率]。 Protect:引用符内の日本語を翻訳、要約、言い換え、追記しない。文字の順番、漢字、かな、英数字、空白、句読点、記号を変えない。指定以外の文字やロゴを追加しない。 Output intent:承認済みの3文字列だけを所定の階層で表示した告知画像。 Pass check:原寸表示で、見出し・日時・補足を原稿と文字単位で完全一致確認する。1文字でも置換、欠落、重複、文字化け、余計な空白があれば不合格。文字が被写体や端に重ならず、読む順番が明確なら合格。
同じ日本語が二度続けて崩れたら、形容詞を足し続けません。文字量を減らす、画像と文字組みの工程を分ける、または承認済み原稿を別のデザイン工程で配置する方が安全です。
6. 複数画像を合成し、各素材の役割を固定する
「この3枚を混ぜて」だけでは、顔、服、商品、背景のどれを採用するか曖昧です。ファイル名または画像記号ごとに、役割を一つずつ割り当てます。
hljs textOperation:画像A・画像B・画像Cを役割別に使い、一枚の合成画像を作る。 Subject/Input:画像A=[主役の形状または人物]、画像B=[背景と光]、画像C=[色調または小物]。各画像はこの役割だけに使う。 Context:[掲載目的]のための一場面。 Composition:画像Aの主役を[位置と大きさ]に置き、画像Bのカメラ角度と光の方向に合わせ、画像Cからは[採用する色/小物]だけを取り入れる。 Replace:[各画像の役割]、[掲載目的]、[主役の位置]、[採用する色/小物]。 Protect:画像Aの主役の顔または商品形状、画像Bの遠近感と光源、画像Cの指定要素を維持する。入力同士のロゴ、文字、人物、商品を勝手に交換・融合しない。 Output intent:どの入力が何に使われたか説明できる合成画像。 Pass check:Aの主役、Bの背景と光、Cの指定要素がそれぞれ判別できる。役割外の要素が混入せず、人物数、商品数、影、遠近感が指定どおりなら合格。
複数人の写真を使う場合は、全員について必要な権利と同意を確認します。入力画像が多いほど本人性が正確になるとは限らず、外見の維持は依頼であって保証ではありません。
7. 人物写真をスタイル変換する
この作業は、実在人物の写真を扱う直前に停止条件を置きます。本人または権利者の許可が確認できない、公開範囲を説明できない、欺く目的がある場合は、アップロードも生成もしません。架空人物や権利を持つ自分の素材へ切り替えます。
hljs textOperation:権利と同意を確認済みの画像Aを、[画材/時代感/イラスト表現]のスタイルへ変換する。 Subject/Input:画像Aの成人人物。[利用許可の範囲]でのみ使用する。 Context:[個人鑑賞/本人承認済みの投稿/制作資料]向け。 Composition:元画像の[顔の向き]、[ポーズ]、[服装]、[切り抜き]、[光]を基準にする。背景は[維持/指定内容へ変更]。 Replace:[スタイル]、[利用目的]、[背景の扱い]。 Protect:人物数、認識可能な外見、肌の色、髪型、表情、ポーズ、服装、切り抜きのうち[固定項目]を維持する。年齢、身体、親密さ、状況を本人の同意なく変更しない。 Output intent:AIによるスタイル変換だと説明できる創作画像。実写の出来事を証明する写真として使わない。 Pass check:指定スタイルが全体に一貫し、固定項目が元画像と視覚的に安定している。別人化、年齢や身体の意図しない変化、手や顔の破綻、誤認を招く状況変更があれば不合格。
「本人そっくり」「同一人物を完全維持」といった結果は保証できません。Googleの生成 AI の使用禁止に関するポリシーも、必要な同意を得ない個人データ・生体認証データの使用、同意のない親密画像、欺く目的のなりすまし、保護フィルタの回避などを禁じています。拒否が出たら、遠回しな言い換えや地域・アカウント変更で回避せず、目的と権利を見直すか、非個人素材に置き換えてください。
8. ほぼ良い画像を一項目だけ修復する
初回結果の良い部分を残し、失敗した一項目だけを修正します。毎回全文を書き直すと、直っていた構図や人物まで再抽選されます。
hljs textOperation:直前の出力画像Bを修復し、失敗項目[一つだけ]を[正しい状態]へ変更する。 Subject/Input:画像Bを唯一の編集元として使う。元の案件指示と承認済み原稿も参照する。 Context:[最終用途]の採用判定に必要な局所修正。 Composition:画像Bの構図、カメラ、被写体位置、光、色、余白を維持する。 Replace:[失敗項目]、[正しい状態]。 Protect:画像Bで既に合格した[合格項目の列挙]をすべて維持する。指定外の再生成、追加、削除、言い換えをしない。 Output intent:画像Bと同じ見た目で、失敗項目だけが修正された版。 Pass check:画像Bと並べ、失敗項目だけが正しく変わり、合格済み項目に新しい差分がない。新しいドリフトがあれば不合格。
同じ保護項目が2回続けて崩れたら、具体的な修復仮説なしに再送しません。元画像を整理する、変更範囲をさらに小さくする、背景と文字を別工程に分けるなど、入力または工程を変えます。
出力確認は「変えた所・守る所・文字」の3点で行う
プロンプトを送った後は、結果を雰囲気で採用せず、次の順序で見ます。
- Replace:依頼した変更が、場所・色・内容まで正しいか。
- Protect:顔、商品形状、切り抜き、背景、光、影など、固定した項目に意図しない差分がないか。
- Pass check:人物数、文字列、部品数、余白など、数えられる条件を満たすか。
- 原寸確認:顔、手、歯、眼鏡、輪郭、ラベル、日本語、影を100%表示で確認する。
- 出所と用途:AI編集であることの開示、人物の同意、商品情報、公開範囲を案件ルールと照合する。
GoogleのAI生成コンテンツ検証ヘルプは、SynthIDを目に見えない透かしとして説明し、非常に単純な画像や小さな編集では判定できない場合があると案内しています。画面の隅に見えるロゴの有無だけで、出所や編集の有無を断定しないでください。プロンプトで来歴情報を消す方法も扱いません。
うまくいかないときの短い切り分け
| 症状 | 次に変える一項目 | 変えないもの |
|---|---|---|
| 主役が小さい | 構図の占有率または画角 | 被写体、光、背景 |
| 背景だけ変えたいのに顔も変わる | 編集範囲を背景に限定 | 顔、髪、姿勢、切り抜き |
| 商品ラベルが崩れる | 承認済み文字列と原寸合否 | 商品形状、構図、影 |
| 日本語が文字化けする | 文字量または対象文字列一つ | デザイン階層、主役、比率 |
| 多画像の役割が混ざる | 各入力の役割定義 | 採用済みの構図と光 |
| 拒否される | 権利、目的、対象、公開範囲を確認 | 安全フィルタを回避しない |
回数、待ち時間、リセット時刻をプロンプトの問題として解こうとしないでください。Gemini Appsの上限はアカウント、プラン、モデル、機能、プロンプトの複雑さ、混雑などの影響を受けます。現在の状態はGemini アプリの使用量上限ヘルプと手元の通知で確認します。
特定のNano Bananaモデルをどう使い分けるかが目的なら、ここでモデル順位を作らず、別の既存ガイド/ja/blog/nano-banana-pro-best-promptsへ進んでください。本記事の8テンプレートは、Gemini Appsで作業内容と検品基準を伝えるためのものです。
よくある質問
英語に翻訳してから貼る方がよいですか?
日本語のまま具体的に書けます。重要なのは言語より、対象、構図、変更範囲、固定項目、合格条件が曖昧でないことです。日本語を画像内に表示する案件では、指示言語とは別に、承認済み文字列を引用符で固定し、出力を文字単位で照合します。
長いプロンプトほど正確になりますか?
長さだけでは決まりません。同じ内容の形容詞を重ねるより、Replace、Protect、Pass checkを分ける方が、失敗箇所を特定できます。条件が衝突しているなら、文章を追加するほど判断が難しくなることもあります。
「変更するのは背景だけ」と書けば顔は必ず同じですか?
いいえ。肯定的な固定指示は曖昧さを減らしますが、完全な本人性や顔の維持を保証しません。元画像と原寸比較し、ドリフトがあれば不合格にします。実在人物なら、結果以前に権利と同意の確認が必要です。
画像内の日本語が読めれば合格ですか?
公開原稿が決まっている案件では不十分です。承認済み原稿と、漢字、かな、英数字、記号、空白、句読点まで完全一致を確認します。1文字でも違えば不合格です。
同じプロンプトなら同じ写真を再現できますか?
再現を保証できません。採用した出力を保存し、次の編集ではその画像を元に、変更する一項目と守る項目を明示してください。プロンプト文だけを保存するより、入力、出力、合否理由をセットで残す方が実務的です。
Geminiが拒否したら、言い換えて試してもよいですか?
まず目的、権利、同意、対象、公開範囲を確認します。合法で安全な依頼が曖昧だった場合は明確化できますが、同じ禁止目的を隠す言い換え、婉曲表現、地域やアカウントの変更、フィルタ回避は行いません。必要なら架空人物や非個人素材へ切り替えます。



