Nano Banana 2.1の複数ターン編集チュートリアル：細部を失わずに2回連続で画像を編集するための3つの引き継ぎ要素

著者注：王冠を赤い帽子に替え、次にピンクのハートを青に変える一連の事例を通して、Nano Banana 2.1で複数回編集するときに、各ターンで会話履歴・直前の画像・思考シグネチャを再送する方法を解説します。これにより、前のターンの成果を保ったまま部分的に編集できます。

gemini-nano-banana-2.1で初めて画像を編集する開発者の多くが、同じ問題に直面します。1回目の編集はうまくいったのに、2回目に細部を少しだけ調整しようとすると、前の編集内容が「上書き」されたり、画像全体が別のスタイルで描き直されたりします。この記事では、Nano Banana 2.1で複数回編集するときの正しいデータの再送方法を紹介し、細部を失わずに2回連続で画像を編集する方法を解説します。

単なる概念解説ではありません。再現可能な事例に沿って説明します。1回目はキャラクターの頭の王冠を赤い帽子に替え、2回目はピンクのハートだけを青にし、赤い帽子はそのまま残します。2回分のリクエストをコードで示し、各ターンでどのデータを含める必要があるのかも解説します。

この記事でわかること：Nano Banana 2.1の複数回編集の仕組みと、各リクエストで再送が必要な3つの要素を理解できます。コードをそのまま応用して、部分編集を連続して行うこともできます。

Nano Banana 2.1の複数ターン編集で押さえておきたいポイント

まず、概念を正確に整理しましょう。Nano Banana 2.1の「ネイティブな複数ターン」編集は、より厳密には「連続編集」と呼ぶのが適切です。各ターンは独立したAPIリクエストであり、モデルが前のターンで何を変更したか「覚えている」ように見えるのは、リクエストにコンテキストをすべて含めて送り返しているためです。サーバー側でセッションが保存されているわけではありません。

Nano Banana 2.1の複数ターン編集で「細部が失われる」理由

よくある間違いは、2回目のリクエストで「ピンクのハートを青にして」とだけ伝え、元画像を添付することです。この場合、モデルが見ているのは依然として王冠をかぶった元画像なので、王冠はそのまま残り、1回目に追加した赤い帽子は消えてしまいます。

もう一つの間違いは、1回目の出力画像だけを添付し、履歴を含めないことです。これでは、モデルは赤い帽子の画像を受け取っていても、その帽子が「直前に意図して変更したもので、維持すべきもの」だとは分かりません。そのため、2回目の編集で帽子の色や形まで変えてしまうことがあります。

安定した編集を行うには、1回目のやり取り全体を対話履歴として送り返します。ユーザーが何を指示したか、モデルがどの画像を返したか、モデルの返信にどのシグネチャが付いていたかを、すべて含めます。Googleの公式ドキュメントでも、画像編集の複数ターン利用は同様に説明されています。履歴に含まれるシグネチャによってモデルが推論コンテキストを引き継ぎ、指定した部分だけを変更できます。

Nano Banana 2.1の複数ターン編集におけるリクエスト構造

2回目のリクエストのcontentsは、時系列順に並んだ配列で、少なくとも次の3つを含みます。1回目のuserメッセージ（元画像と指示）、1回目のmodelの返信（出力画像とシグネチャ）、そして2回目の新しいuser指示です。重要なのは、modelの返信を「そのまま再現」することです。画像のbase64だけを取り出して再構成すると、変換時にシグネチャフィールドが失われやすくなります。

Nano Banana 2.1の複数ターン編集をすぐに始める

ここでは、Pythonとrequestsライブラリを使って、GeminiネイティブのgenerateContent形式で直接呼び出します。OpenAI互換のchat形式を使わないのは、複数ターンの編集ではthought signatureと画像partを引き継ぐ必要があるためです。ネイティブ形式なら、これらのフィールドを元の構造のまま最大限保持できます。

事前準備チェックリスト

簡単な例：1ターン目で王冠を赤い帽子に変更する

1ターン目は、通常の画像編集リクエストです。userメッセージを1つ送り、その中に元画像と指示を含めます。重要なのは、返されたmodelの内容を丸ごと保存しておくことです。次のターンで使用します。

import base64, requests

BASE_URL = "https://api.apiyi.com/v1"  # APIYI 统一接口，原生格式路径以文档中心说明为准
API_KEY = "YOUR_API_KEY"
MODEL = "gemini-nano-banana-2.1"
URL = f"{BASE_URL}/models/{MODEL}:generateContent"
HEADERS = {"Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json"}

img_b64 = base64.b64encode(open("origin.png", "rb").read()).decode()
user1 = {"role": "user", "parts": [
    {"inline_data": {"mime_type": "image/png", "data": img_b64}},
    {"text": "把角色头上的皇冠换成一顶红色的帽子，其他内容保持不变。"}]}

resp = requests.post(URL, headers=HEADERS, json={
    "contents": [user1],
    "generationConfig": {"responseModalities": ["TEXT", "IMAGE"]}}).json()
model1 = resp["candidates"][0]["content"]  # 原样保存，含图片和 thoughtSignature

特に注目したいのは最後の行です。model1には、画像データだけでなく、candidates[0].contentオブジェクト全体をそのまま格納しています。このオブジェクトのpartsには、テキスト、画像、thoughtSignatureフィールドが含まれる場合があります。丸ごと保存すれば、必要な情報を漏らさずに済みます。

完全版サンプル：第 2 ラウンドではピンクのハートだけを青に変更し、赤い帽子は残す

第 2 ラウンドのポイントは、contents を組み立てることです。[user1, model1, user2] の順に指定します。以下の完全なコードには、2 回の呼び出し、署名の確認、画像の保存が含まれており、そのまま実行できます。

import base64
import requests

BASE_URL = "https://api.apiyi.com/v1"  # 通过 APIYI 调用，原生格式路径以 docs.apiyi.com 为准
API_KEY = "YOUR_API_KEY"
MODEL = "gemini-nano-banana-2.1"
URL = f"{BASE_URL}/models/{MODEL}:generateContent"
HEADERS = {"Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json"}
GEN_CONFIG = {"responseModalities": ["TEXT", "IMAGE"]}


def call(contents):
    """发送一次 generateContent 请求，返回 model 回复的完整 content 对象"""
    r = requests.post(URL, headers=HEADERS,
                      json={"contents": contents, "generationConfig": GEN_CONFIG},
                      timeout=180)
    r.raise_for_status()
    return r.json()["candidates"][0]["content"]


def save_image(content, path):
    """从 model 回复中取出图片并保存"""
    for part in content.get("parts", []):
        data = part.get("inlineData") or part.get("inline_data")
        if data:
            open(path, "wb").write(base64.b64decode(data["data"]))
            return True
    return False


def has_signature(content):
    """检查回复中是否带有思维签名"""
    return any("thoughtSignature" in p or "thought_signature" in p
               for p in content.get("parts", []))


# ---------- 第 1 轮：皇冠 → 红帽 ----------
img_b64 = base64.b64encode(open("origin.png", "rb").read()).decode()
user1 = {"role": "user", "parts": [
    {"inline_data": {"mime_type": "image/png", "data": img_b64}},
    {"text": "把角色头上的皇冠换成一顶红色的帽子，其他内容保持不变。"}]}

model1 = call([user1])
save_image(model1, "round1_red_hat.png")
print("第 1 轮签名存在:", has_signature(model1))

# ---------- 第 2 轮：粉心 → 蓝心，保留红帽 ----------
user2 = {"role": "user", "parts": [
    {"text": "在上一张图的基础上，只把胸前的粉色爱心改成蓝色。"
             "红色帽子和其他所有细节保持不变。"}]}

# 关键：完整历史 + 原样回传的 model1（含上一轮图片与签名）
history = [user1, model1, user2]
model2 = call(history)
save_image(model2, "round2_blue_heart.png")
print("第 2 轮签名存在:", has_signature(model2))

# 如需第 3 轮，继续追加：history += [model2, user3]

🚀 すぐに試す：まずは APIYI（apiyi.com）の無料テスト枠で上記の 2 ラウンド分のコードを実行し、round2 の画像で赤い帽子が残り、ハートだけが変色していることを確認してから、ご自身の業務フローに組み込むのがおすすめです。

第2ラウンドの指示を書くコツ

連続編集で「一部だけを変更」できるかどうかは、履歴の返し方だけでなく、指示の書き方にも左右されます。第2ラウンドの指示では、次の3点を明確に伝えるのがおすすめです。どの画像をもとにするのか、どこを変更するのか、何を必ず維持するのか。たとえば「直前の画像をもとに、ピンクのハートだけを青に変更し、赤い帽子やその他の細部はそのままにしてください」と指示するほうが、単に「青に変更して」と伝えるより安定します。

また、第2ラウンドでは元画像を再添付しないでください。元画像はすでに user1 に含まれています。user2 にもう一度添付すると、モデルが新たな参照画像として解釈し、かえって王冠のあるバージョンに戻ってしまう可能性があります。

Nano Banana 2.1のマルチターン編集：3つの履歴の返し方を比較

「3つの要素をすべてそろえる」必要性を説明するため、よく使われる3つの方法を並べて比較します。以下の表では、それぞれの履歴の返し方で起こりやすい挙動を定性的にまとめています。自分のコードがどのパターンに当てはまるか、すぐに判断できます。

比較のポイント

方式Aの比較：方式Aは実装が最も簡単で、毎回独立したリクエストとして処理します。ただし、モデルは第1ラウンドの結果をまったく参照できないため、実質的に1回限りの編集をやり直すことになります。一方、完全な履歴を返せば、第2ラウンドでは第1ラウンドの結果をもとに編集を続けられます。

方式Bの比較：方式Bは画像を1枚だけ送るため、リクエストのサイズを抑えられます。ただし、モデルには「赤い帽子は意図的に変更したもの」という文脈が伝わらず、署名も受け取れないため、部分的な一貫性は保証されません。デザイン案やECサイトの商品画像など、段階的に細部を仕上げる必要がある場面では、方式Cのほうが安心です。

💡 選び方のヒント：業務で2ラウンド以上の編集を続ける場合は、最初から方式Cを採用するのがおすすめです。APIYI apiyi.comで同じコードを使って3つの方法をそれぞれ試し、出力画像を比較すると、違いがよくわかります。

Nano Banana 2.1と同シリーズのモデルの選び方

APIYIでは、Nano Bananaシリーズの複数のモデルを利用できます。連続編集は、編集機能を応用した使い方です。以下の表を参考に、同シリーズの中から適切なモデルを選んでください。

Nano Banana 2.1の複数ターン編集でよくある問題と対処法

実際に組み込む際、「変更した内容が消えた」という問題の多くは、いくつかの決まった原因に集約できます。発生頻度の高い順にまとめたので、確認しながら一つずつチェックしてください。

1. 署名の欠落：モデルの返信を独自のデータ構造に変換してから再度組み立てると、フィールド名の大文字・小文字やネストの階層が変わり、thoughtSignature が渡されないことがあります。元の content オブジェクトをそのまま保存し、再送するのがおすすめです。
2. ロールの指定ミス：1ターン目のモデルの返信を user ロールにすると、モデルは自分の出力をユーザーがアップロードした新しい画像として扱ってしまいます。モデルの返信は必ず role: model のままにしてください。
3. 順序の逆転：contents は時系列順に並べる必要があります。user1、model1、user2 の順にし、新しい指示を先頭に置かないでください。
4. 形式の混在：前のターンでOpenAI互換形式を使い、次のターンでネイティブ形式に切り替えると、途中のフィールド変換で署名が失われることがあります。複数ターンの処理では、Geminiのネイティブ形式に統一するのがおすすめです。
5. 履歴が長すぎる：ターン数が増えるほど、リクエストに含まれる画像も増え、データ量と処理時間が大きくなります。2〜3ターンを超える長い処理では、重要な段階で現在の結果を新しい元画像として扱い、履歴を区切ることも検討してください。

🎯 技術アドバイス：問題を調べる際は、まず model1 の parts 構造を出力し、thoughtSignature フィールドが存在することを確認してください。次に、送信する2ターン目のリクエスト本文に、その値が変更されずに含まれているかを確認します。APIYI（apiyi.com）のドキュメントセンターには、Geminiのネイティブ形式と複数ターンの会話を組み立てるサンプルがあるので、照らし合わせて確認できます。

よくある質問（FAQ）

Nano Banana 2.1の複数ターン編集：押さえておきたいポイント

• 本質は連続編集：各ターンは独立したリクエストです。コンテキストはクライアントから情報を返送することで維持します
• 欠かせない3つの要素：会話履歴全体、前のターンで生成した画像、思考シグネチャ
• modelの内容はそのまま返送：candidates[0].contentを直接保存し、シグネチャの消失を防ぎます
• ネイティブ形式を使う：generateContentのcontents構造は、画像とシグネチャの返送に最適です
• 残す要素を指示に明記：2ターン目では「どこだけを変更し、何を変えないか」を明確にすると、部分編集が安定します
• 元画像を重複して添付しない：2ターン目に元画像を添付すると、変更前の状態に戻ってしまうことがあります
• 低コストで検証：APIYI（apiyi.com）の無料枠を使い、まず2ターンの編集を試してから本番環境に導入しましょう

まとめ

Nano Banana 2.1で複数ターン編集を行う際のポイントは、次のとおりです。

1. 仕組み：複数ターン編集とは、クライアントから情報を返送しながら続ける編集です。サーバー側が自動的に記憶する仕組みは未検証のため、依存しないようにしましょう
2. 返送する内容：2ターン目のリクエストには、user1、画像と思考シグネチャを含むmodel1の内容（そのまま）、user2を含める必要があります
3. 実践のコツ：Geminiのネイティブ形式に統一し、指示には残す要素を明記します。新しいターンで元画像を再度添付するのは避けましょう

この3点を押さえれば、「王冠を赤い帽子に替え、次にピンクのハートを青くする」といった2ターンの連続画像編集を安定して再現できます。同じ構造は、さらに多くのターンにも応用できます。

APIYI（apiyi.com）を使うと、効果をすばやく検証できます。OpenAI互換形式とGeminiネイティブ形式のインターフェースを利用でき、1つのAPIキーでNano Bananaシリーズをはじめとする主要モデルを呼び出せます。従量課金制のため、小規模なテストから始めて、段階的に本番環境へ導入するのに適しています。

📚 参考資料

1. Google Gemini API 画像生成・編集ドキュメント：公式の複数ターンにわたる画像編集の説明
2. リンク：ai.google.dev/gemini-api/docs/image-generation

3. 説明：画像編集のリクエスト構造と、連続して編集する際の会話形式について解説しています。

4. Google Gemini API 思考署名ドキュメント：thought signature の仕組みについて

5. リンク：ai.google.dev/gemini-api/docs/thought-signatures

6. 説明：署名の役割と、複数ターンのリクエストで署名をどのように返送するかを解説しています。

7. APIYI ドキュメントセンター：Nano Banana シリーズの開発ガイド、複数ターンの会話実装ガイド、Gemini ネイティブ形式の呼び出しガイド

8. リンク：docs.apiyi.com
9. 説明：接続先エンドポイント、ネイティブ形式のパス、履歴の組み立て例を掲載しています。この記事のコードを実装する際の参考資料です。

著者：APIYI 技術チーム
技術的なお問い合わせ：APIYI のウェブサイトトップページからお気軽にお問い合わせください。Nano Banana シリーズの接続に関する資料は、docs.apiyi.com のドキュメントセンターをご覧ください。

関連記事

• Nano Banana 2 vs 2.1の文字レンダリング：5パターンのポスターで実測比較と選定チェックリスト:Nano Banana 2.1は文字描画が向上したと言われるのに、なぜ2代目のほうが正確だと感じる人がいるのでしょうか。再現可能なポスターのシーン5例、合格基準、1回あたりの価格を用いて、いつ切り替えるべきか、いつ切り替える必要がないかを説明してください。
• Nano Banana 2.1は何が改善された？6つの主要アップグレードを徹底解説、Nano Banana Proと実力を比較する:Nano Banana 2.1はNano Banana 2のアップグレード版で、公式ベンチマークスコアはNano Banana Proを上回っていますが、実際の画像生成でも本当に勝てるのでしょうか？本記事では、6つの主な改善点と公式・第三者機関の評価データを分析し、用途に応じたNano Banana 2.1とProの選び方を紹介します。
• Nano Banana 2.1の料金を徹底解説：Nano Banana 2との5つの重要な違いと節約額の試算:Google公式料金ページをもとにNano Banana 2.1の料金を分析。画像出力の単価は半減する一方、入力トークンと思考トークンは値上がりし、4Kの消費量は増加、0.5Kの枠は廃止。1K・2K・4Kの画像1枚あたりのコスト、Batch料金、損益分岐点、移行に関する提案を掲載。
• 1枚の画像で300万人をだました？GPT Image 2.5でAI風刺・疑似ドキュメンタリー風の旅行画像を作る2ステップ講座:Wytse Koetseのパリ風刺動画を分析し、まずGPTで構造化プロンプトを作成してから、gpt-image-2.5-sunburstまたはgemini-nano-banana-2.1を使って「偽の旅行広告風」の疑似ドキュメンタリー静止画を一括生成する。