Nano Banana 画像編集：入口の選び方、プロンプト、止めどき

Nano Banana で既存画像を編集できるかどうかより先に、どの入口で扱うかを決める必要があります。安全な軽い試しなら Gemini、スマートフォン写真や視覚検索に近い作業なら Search または Lens、再現性やログやプロジェクト制限を見たいなら AI Studio や Gemini API、自動化や一括処理なら条件を確認した provider API、低リスクのブラウザ作業なら第三者エディタ、正確な文字やロゴや法務素材なら従来の編集ツールを選ぶべきです。

安定するプロンプトは、変更内容よりも先に守る対象を書く形です。人物の同一性、ポーズ、光、カメラ角度、背景配置を保持する。青いジャケットだけをマットブラックに変える。アクセサリを追加しない。見える文字を読めるまま残す。この順序なら、モデルが自由に再構成してよい範囲と触ってはいけない範囲を区別しやすくなります。

二回続けて別の物体を変える、顔が別人になる、文字やロゴが壊れる、画質が濁る場合は、プロンプトを長くするより入口を変えるべきです。私的な顔、本人確認書類、顧客未公開素材、医療や金融の画面、権利が不明な素材は、気軽なテストに使わないでください。きれいなプレビューと納品可能な編集結果は別物です。

いま Nano Banana 画像編集が指すもの

Nano Banana は Google の画像生成と画像編集能力を指す市場上の呼び名として使われます。ただし、実際の契約は入口で変わります。Gemini では現在の画像モデルと写真編集体験として扱われ、開発者向けには Google AI のドキュメント上で Nano Banana 2、Nano Banana Pro、元の Nano Banana が異なる API 経路として説明されます。第三者エディタはさらに独自の credits、保存、出力権利、サポートを持ちます。

この分岐を無視すると、Gemini で通ったプロンプトをそのまま本番 API、provider endpoint、ブラウザ wrapper に持ち込んでしまいます。Nano Banana 画像編集は、モデル名の暗記ではなく、入口選択とプロンプト作業の組み合わせです。inpainting は一つの編集モードにすぎません。物体除去、背景差し替え、顔を保った服装変更、参照画像の合成、商品 mockup、画面拡張では守る条件が違います。

安定して判断に使える事実は、Google AI によって生成または編集された画像に SynthID の透かしが使われることです。一方で、無料回数、provider credits、画像単価、最大解像度、速度、保存期間、商用権利は入口とアカウントで変わるため、数字として固定しないほうが安全です。

アップロード前に入口を選ぶ

Gemini アプリは、素材が安全で、まず見た目を試したいときに向いています。画像を添付し、一つの変更を指定し、結果を確認し、必要なら一、二回だけ狭い修正を行います。API の model ID、batch behavior、provider limit、asset governance を調べる場所ではありません。

Search や Lens は、スマートフォンで撮った写真や視覚検索から始まる作業に合います。カメラに近い日常的な入口なので速い一方、制作管理のための面ではありません。人物、書類、顧客製品、未公開ブランド素材が写るなら、監査できるアカウントと明確な処理条件のある経路へ移してください。

AI Studio や Gemini API は、再現性が重要な作業に向いています。同じプロンプトを複数の商品画像に当てたい、request logs を見たい、project limits を確認したい、response class を切り分けたい場合は、消費者向けチャットより開発者向け経路のほうが検証しやすくなります。

Provider API や第三者エディタを使う前には、契約の主体を確認します。provider は自動化、請求統合、多モデル接続に便利ですが、credits、storage、output handling、support は provider 側の条件になります。第三者エディタは非技術者に便利ですが、Google が明示しない限り Google 第一方の契約ではありません。

安全なアップロード手順

素材を低リスク、中リスク、高リスクに分けます。低リスクは合成デモ、公開済みのマーケティング下書き、人物や顧客情報を含まないテスト画像です。中リスクは識別できる人物、ブランド要素、商用予定の素材です。高リスクは本人確認書類、私的な顔、医療や金融の記録、未公開製品、顧客機密、契約やアカウント情報を含む画面です。

低リスクなら消費者向け入口で十分なことが多いです。ただし、一度に一つの変更に絞り、変更対象と保護対象を分けて書きます。中リスクでは、保存、権利、アカウント権限を確認できる経路を使います。高リスクでは、公的に承認された内部ツール、従来の編集ツール、またはデータ処理条件のある production route を使うべきです。

最初の文は編集指示書のように書きます。人物の顔、ポーズ、光、カメラ角度、背景配置を保持する。青いジャケットだけをマットブラックに変える。アクセサリを追加しない。見える文字は変えず読めるままにする。結果確認では、印象よりも守るべきものが守られたかを見ます。

顔が変わったなら失敗です。光や視点が変わったなら、保持条件が弱いか入口が合っていません。文字やロゴが壊れたなら、画像モデルに精密なタイポグラフィを直させる段階ではありません。AI は方向出しに使い、正確な文字層は従来の編集ツールで戻します。

役に立つプロンプトの作り方

物体除去では、消す対象と埋める内容を指定します。「これを消して」ではなく、「ドア横の赤いごみ箱を消し、コンクリート壁、床の影、左側の光を自然につなげる」と書きます。隠れていた部分の情報がない場合は plausible fill として扱い、事実復元として使わないことが重要です。

背景差し替えでは、保持条件を強くします。顔、髪の輪郭、ポーズ、服の形、カメラの遠近感を保持し、無地の壁を暖かいグレーの柔らかなスタジオ背景に変える。背景色が髪ににじむ、輪郭が変わる場合は、一度だけ変更範囲を狭め、それでも崩れるならレイヤー編集へ移ります。

style transfer では、変えてよいものと変えてはいけないものを分けます。「映画風に」だけでは広すぎます。商品形状、label、見える文字、撮影角度を保持し、光だけを柔らかな evening editorial look に変える。浅い被写界深度を加える。logo と package geometry は変えない。このように書くと、見た目の方向と納品物の保護が分離されます。

product mockup は最も厳しい幾何条件が必要です。製品寸法、ラベル位置、キャップ形状、すべての文字を保持し、表面反射と背景だけを変える。文字が曲がる、ラベルを作り替える、包装比率が変わるなら AI 層を止め、承認済みの製品アートを手作業で戻します。

複数画像を組み合わせる場合は、各参照画像の役割を書きます。雰囲気、素材、人物同一性、構図のどれを参照するのかを明示しないと、モデルは優先順位を推測してしまいます。

プロンプトの公式

多くの編集は、target、preserve、change、context、constraints、output check の順で書けます。target は変更できる物体、人物、領域、背景を示します。preserve は同一性、姿勢、光、カメラ角度、配置、文字、ロゴ、製品形状を守ります。change は色、素材、位置、環境、スタイルを指定します。context は理解に必要な場面情報だけを足します。constraints は追加禁止、切り抜き禁止、読める文字を指定します。output check は失敗条件を先に決めます。

preserve block を省略すると、モデルは画像全体を作り直してよいと解釈しがちです。正確な文字、ロゴ、商品ラベル、顔、法務素材を守る必要があるなら、画像モデルは最終層ではなく試案作りの道具かもしれません。

否定指示は具体的なときだけ効きます。「変にしないで」では境界になりません。「顔、手、ロゴ、文字、カメラ角度、背景配置を変えない」は境界になります。長いほど良いのではなく、変えてよい部分、守る部分、失敗条件が明確であることが重要です。

編集が失敗したときの判断

違う物体が変わる場合、target が曖昧です。位置、色、物体名、近くの要素との関係を足してください。「椅子を変える」ではなく、「木製テーブル右側の奥にある小さな赤い椅子を黒い金属椅子に変える」と書きます。

人物の同一性が崩れる場合、ルートまたは保護条件が不十分です。同じ人物、同じ顔立ち、同じ年齢印象、同じ表情、同じポーズを追加し、一度だけ再試行します。二回目も別人になるなら、その入口では止めます。

文字とロゴの問題は小さな見た目の問題ではありません。画像モデルはもっともらしい文字を作れても、文字列、間隔、記号の形を変えることがあります。パッケージ、UI、看板、文書風の画像では、AI を方向出しに使い、最終文字を従来の編集環境で管理します。

何度も重ねるうちに画質が落ちたら、元画像に戻って一つだけ狭い変更を行います。生成結果をさらに編集し続けると、ぼけ、平板な光、人工的な質感が積み上がります。

入口そのものが失敗している場合は、プロンプトではなく経路を診断します。Gemini が失敗するなら同じアカウントの別入口を確認します。API が失敗するなら model ID、project limits、response class、request logs を見ます。wrapper が失敗するなら、その wrapper の credits や障害を確認します。復旧の切り分けには不具合対応の手順を使えます。

開発者と provider の境界

開発者にとって重要なのは、消費者アクセスと API 契約を混ぜないことです。Gemini chat はプロンプト挙動の理解に使えますが、本番コードでは文書化された model path を使います。Google AI 文書では Nano Banana 2、Nano Banana Pro、元の Nano Banana が分かれているため、model ID は開発者向けの段落で扱うべきです。

Provider API は batching、共通 billing layer、複数モデル gateway で便利です。同時に、Google のモデルと自社コードの間に別の責任者を追加します。どのモデルを呼ぶのか、入力画像をどう保存するのか、output rights をどう説明するのか、エラーをどう返すのか、price や credit の説明が最新かを確認してください。

価格、quota、無料範囲が主題なら専用の価格ページを確認してください。日本語版がない場合は英語のpricing and quota guideを参照できます。動画用途なら画像から動画への経路、ローカル代替ならComfyUI の代替案が近いです。

よくある質問

Nano Banana で既存画像を編集できますか？

できます。ただし、最初に決めるべきなのは入口です。Gemini は公式の消費者向け編集、Search や Lens はスマートフォン写真、AI Studio/API は管理された開発作業、第三者エディタは credits、保存、権利、経路確認が必要です。

Nano Banana の編集は無料ですか？

一つの答えにはなりません。消費者アクセス、 paid plan capacity、API billing、provider credits、第三者エディタの trial は別の条件です。費用が選択に関わるなら、古い daily limit ではなく現在使う入口の条件を確認します。

inpainting と Nano Banana 画像編集は同じですか？

同じではありません。inpainting は一部の領域を変える編集です。Nano Banana 画像編集には、背景差し替え、style transfer、参照画像の組み合わせ、product mockup、outpainting、物体除去、プロンプトによる再調整も含まれます。

どんなプロンプトが安定しますか？

preserve-first prompt が安定します。変更対象を指定し、守るべき同一性、姿勢、光、文字、ロゴ、配置を書き、変更内容、制約、失敗条件を足します。ただし入口は別問題で、プロンプトだけで公開 wrapper を機密素材向けの環境に変えることはできません。

いつ再試行を止めるべきですか？

顔が別人になる、文字やロゴが壊れる、画質が落ちる、アップロードリスクがある、権利が不明、入口が合っていない場合です。別の入口、管理された API、従来の編集ツールへ移るほうが、同じ経路で形容詞を増やすより安全です。