Gemini 画像編集ガイド: アプリと API の使い分けと最適モデル

はい。Gemini はすでに image-to-image 編集を実用レベルでこなせます。そして今の標準的な出発点は Nano Banana 2 です。 2026年3月22日時点で本当に考えるべきなのは、「Gemini が画像編集に対応しているか」ではありません。対応しています。重要なのは、Gemini アプリを使うべきか、Gemini API を使うべきか、あるいは仕上がり優先で Nano Banana Pro に上げるべきか、というルート選択です。

このトピックがやや分かりにくいのは、Google が答えを複数のページに分散しているからです。image generation の公式ドキュメント は機能とコードを説明し、Gemini Apps のヘルプ はアプリ内の使い方を説明し、製品ブログは Nano Banana 2 が現在の基準になった理由を説明しています。どれも正しいのですが、「手元の画像を Gemini で編集したい」という人にとっては、まだ一枚の地図になっていません。

結論だけ先に言うとこうです。コードを書かずに画像をアップロードして背景や要素を変えたいなら Gemini アプリ。再現性のあるワークフロー、多段階の修正、サイズ制御、プロダクト統合が必要なら Gemini API。そして Nano Banana Pro は、テキストの多い画像や高価値の最終成果物で品質を優先したいときに使う上位ルートです。

要点まとめ

最短で実用的な答えが欲しいなら、まずここを見れば十分です。

このテーマで特に重要なのは 2026年2月26日 に gemini-3.1-flash-image-preview が登場したこと、そして deprecations ページ が gemini-2.5-flash-image の終了予定日を 2026年10月2日 と明示していることです。だから今の標準回答は、古い最安ラインでもなく、最初から Pro に行くことでもなく、まず Nano Banana 2 から始めることになります。

Gemini は image-to-image に対応しているが、正しいルートは作業場所で変わる

表面上はひとつの機能質問に見えますが、実際には Google はこの機能を異なるサーフェスにまたがって提供しています。Gemini アプリでは、画像をアップロードし、何を変えたいかを指示し、その結果をまた編集するという消費者向けのフローです。現在のヘルプでは、生成と編集の基本ラインは Nano Banana 2 で、さらに有料ユーザーには Nano Banana Pro の redo ルートがあります。

一方 Gemini API では、ドキュメントがこの機能を text-and-image-to-image として説明しています。画像とテキスト指示を一緒に送り、編集後の画像を返してもらう形です。しかも同じドキュメントは、会話を続けながらの multi-turn 編集 を推奨しています。つまり、状態を保持しながら段階的に詰めたいなら API の方が自然です。

ここで最も起きやすい誤解は、アプリと API を同じものとして扱ってしまうことです。実際には違います。Gemini Apps のヘルプには、無料ユーザーのダウンロードは 1K、有料では 2K と書かれています。一方、2026年2月26日の開発者向けブログでは、Nano Banana 2 を Google AI Studio で使うには 有料 API key が必要 と明記されています。つまり「Gemini の画像編集は無料だ」という話と「Gemini の画像編集は有料だ」という話が同時に存在しても、別のサーフェスを指しているなら矛盾しません。

だからこのページでは、まず入口を分けてから細部に入ります。プロダクト統合を考えているなら API パートへ、画像を手早く直したいだけならアプリから入るのが最短です。

画像編集を始める前に、どの Gemini モデルを使うか決める

このテーマで最も陳腐化しやすいのはモデル選択です。公式 docs、pricing、deprecations を合わせて見ると、現在の構図はかなり明確です。gemini-3.1-flash-image-preview が今の標準ライン、gemini-3-pro-image-preview が上位ライン、gemini-2.5-flash-image はまだ使えるが明確に legacy という位置づけです。

なぜ Nano Banana 2 が今の基本回答になるのか。理由は単純で、このキーワードに対して最もバランスが良いからです。Google 自身が速度、高スループット、多段階の編集向けとして位置づけており、pricing ページも 0.5K から 4K までの実用的なサイズ帯を与えています。

Nano Banana Pro に上げるべきなのは、画像内テキストの正確さが重要なとき、素材そのものの価値が高いとき、あるいはアプリの redo で最後の品質を引き上げたいときです。

より詳しい API 観点の解説が必要なら Gemini Flash Image API Guide が次に読むべきページです。

Gemini アプリでの画像編集をスムーズに進めるには

Gemini アプリは、コード不要で最短です。現在の Google の案内では、gemini.google.com に行き、Create image か画像アップロードを使い、変更内容を指示し、そのまま会話内で修正を続けます。今の Gemini アプリは、背景変更、被写体の差し替え、複数画像の合成、同じ画像への段階的な局所編集まで扱えるようになっています。

ここで Nano Banana 2 の意味が出ます。アプリ向けの画像編集アップデートでは、人物やペットの見た目保持、背景変更、複数画像のブレンド、局所的な multi-turn 編集が強調されています。つまり、単なる「画像生成」ではなく、実用的な image-to-image 編集ツールとしての性格がかなり強くなっています。

アプリでの成功率を上げるコツは、長く書くことではなく、守るべき部分を具体的に書くことです。たとえば「この部屋をもっと良くして」より、「壁だけを深いグリーンに変えて、家具配置・窓の光・カメラ角度はそのままにして」の方がずっと安定します。

アプリには三つの現実的な制約があります。第一に、機能の有無は Gemini Apps がサポートする言語・地域に依存します。第二に、ポリシー判定で画像が拒否されることがあり、ユーザーにはそれがモデルの失敗に見えます。第三に、アプリで生成・編集した画像には 可視 watermark と SynthID が付きます。

有料ユーザーなら最も実用的なのは Redo with Pro です。Nano Banana 2 で構図を固めた後、Nano Banana Pro に引き上げて最後の品質を詰める流れです。

Gemini API で image-to-image 編集を行う方法

API を使うべきなのは、再現性、制御、統合が必要なときです。公式 docs では、編集は generateContent の普通の流れとして示されています。画像とテキスト指示を送り、画像とテキスト parts を受け取る構造です。今の基本モデルとして一番自然なのは gemini-3.1-flash-image-preview です。

重要なのは一回で終わらせることではなく、multi-turn で詰めること です。背景を変え、次に被写体サイズを調整し、最後に色味を整える、というように段階的に詰めるほうが、Gemini の長所を活かせます。

python
import os
import base64
from google import genai
from PIL import Image

client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])
source = Image.open("living-room.png")

response = client.models.generate_content(
    model="gemini-3.1-flash-image-preview",
    contents=[
        "Using the provided image, change only the blue sofa to a vintage brown leather chesterfield. "
        "Keep the pillows, room layout, camera angle, and lighting unchanged.",
        source,
    ],
)

for part in response.candidates[0].content.parts:
    if part.inline_data:
        with open("edited-room.png", "wb") as f:
            f.write(base64.b64decode(part.inline_data.data))

この例が細かいのは意図的です。image-to-image では、変更点が限定されているほど安定しやすいからです。さらに、必要なら同じ会話の中で「植物を小さくして」「色味を少し暖かくして」のように続ける方が自然です。現在の Gemini 3 image docs では imageConfig を使って aspectRatio と imageSize も制御できます。

API には二つの前提があります。第一に、現行の Gemini image API モデルには 公開 free tier がありません。第二に、rate limits ページ は、実際の上限が tier ごとに違い、AI Studio で確認すべきだと明記しています。プロダクトに入れるなら、最初から re-try、timeout、ログ、コスト管理を織り込んで考えるべきです。

無料と有料の整理が欲しければ Gemini image generation free tier、legacy ラインの置き換えなら Gemini 2.5 Flash Image replacement が次です。

Gemini の編集で効きやすいプロンプトの考え方

Gemini の編集が崩れる原因の多くは、モデルの限界よりプロンプトの曖昧さです。Google の prompting ガイドが示す原則はシンプルで、キーワードを並べるのではなく、場面を描写する ことです。image-to-image では特にこれが重要です。

一つ目の型は 要素の追加・削除 です。元画像、変更内容、どう自然に馴染ませたいかまで書くと安定しやすくなります。二つ目は 一箇所だけを変える 型で、「ここだけ変えて、他は維持する」と明示するやり方です。三つ目は スタイル転写、四つ目は 複数画像の合成。現在の Gemini 3 image docs では 最大14枚の reference image を扱えます。五つ目は 構図や比率を守る 型で、「元の aspect ratio を変えない」と明示します。

要するに、良い編集プロンプトは「何を変えるか」「何を守るか」「どの視覚ロジックを維持するか」を同時に伝えます。

よくある失敗と修正の考え方

最初の失敗は 古い前提や違うサーフェスで考えてしまうこと。2026年3月時点の標準は Nano Banana 2 であって、過去の preview ラインではありません。

二つ目は 局所編集をしたいのに、全体書き換えを許すプロンプトになっていること。三つ目は 多段階編集での一貫性ドリフト。Google 自身も、似姿が崩れ始めたら新しい会話を始めることを勧めています。四つ目は aspect ratio や構図のずれ、五つ目は API の不安定さ、六つ目は ポリシーや地域制限をモデル能力の不足と誤認すること です。

FAQ

Gemini は本当に image-to-image 編集に対応していますか。
はい。現行 docs は text-and-image-to-image を明示的に扱っており、Gemini Apps でもアップロード画像の編集と複数画像の合成が可能です。

今の標準モデルは何ですか。
大半のケースでは gemini-3.1-flash-image-preview が最も自然な基準です。

Nano Banana Pro はどんな時に使うべきですか。
文字が重要な画像、高価値の成果物、品質の失敗コストが高いタスクで意味があります。

Gemini の画像編集は無料ですか。
サーフェス次第です。Gemini アプリには独自ルールがありますが、アクティブな Gemini image API モデルに公開 free tier はありません。

同じ画像を何ターンにも分けて編集できますか。
できます。むしろ、その multi-turn 編集こそが Gemini の強みです。

まとめ

今いちばん有用な答えは、「Gemini は画像編集に対応している」という一文ではありません。あなたの作業に対して、Gemini のどのルートを選ぶべきか が本当の答えです。

手早く編集したいなら Gemini アプリ。再利用可能なフローを作りたいなら Gemini API。多くのケースは Nano Banana 2 から始め、必要な時だけ Nano Banana Pro に上げる。そして gemini-2.5-flash-image は今では安い legacy ルートとして扱うのが自然です。