モデルカード
完全な価格比較、リクエストごとの課金と token ベース課金の違い、token の選び方については、Nano Banana Series Pricing をご覧ください。
サイズ制御
- 元画像の比率に従う:
aspectRatioを単純に省略します。複数画像編集のシナリオでは、最後の画像のサイズ が優先されます - 解像度
imageSize:1K/2K/4Kに対応- Nano Banana (Gen 1) は 1K のみ対応
- Nano Banana 2 は 512px を追加
- Nano Banana 2 Lite は 1K のみ対応(2K/4K/512px は非対応)
組み込み方法
公式ドキュメント
- Google 公式ドキュメント:
ai.google.dev/gemini-api/docs/image-generation - APIYI と連携するには、request URL + KEY を APIYI のものに置き換えるだけです。その他のパラメータは公式のものとすべて同一です
公式ステータスの確認(上流障害の診断)
Nano Banana シリーズは Google の AIStudio / Gemini API 上で動作しています。まれに、2K / 4K 出力がぼやける、または失敗する問題は、統合レイヤーではなく Google 側 に原因がある場合があります。Google の公式ステータスページを確認してください(URL をコピーしてご自身でアクセスしてください):aistudio.google.com/status。
たとえば、2026年6月19日には、そのページで「Issues with Nano Banana」と報告されていました。Gemini API と AI Studio 上の Nano Banana 2 / Pro において、2K または 4K 解像度で問題が発生していました。同様の症状が見られる場合は、まず公式ステータスページと照合し、上流の障害かどうかを素早く判断してください。
APIYI は冗長化のため、AIStudio + Vertex のデュアルチャネル で Nano Banana シリーズを提供しています。片方の公式チャネルに問題が発生しても、もう一方が引き継いでサービスの可用性を維持できます。
エンドポイント対応
- 推奨エンドポイント(Gemini ネイティブ):
https://api.apiyi.com/v1beta/models/gemini-3-pro-image-preview:generateContent - OpenAI 互換モード 経由の呼び出しに対応しています(注: URL アップロードはサポートされていません。代わりに Base64 を使用してください)
- 対応していません
/v1/image/generations
開発形式(デフォルトの推奨)
- [推奨] Google ネイティブのエンドポイント形式を使用してください
- 画像: Base64 としてアップロードし、ダウンロードして再ホストする
- 呼び出し方法: 同期マルチスレッド呼び出し。非同期呼び出しはまだサポートされていません
入力画像の要件
- 単一の画像は 7MB を超えられません(Google のルールです)。Google Cloud Storage 経由でインポートする場合、1ファイルあたりの上限は 30MB です
- 1 プロンプトあたり最大 14 枚の画像
- 対応 MIME タイプ:
image/png,image/jpeg,image/webp,image/heic,image/heif(jpg形式はすでに APIYI でサポートされています) - Base64 のサイズ増加: 画像を Base64 に変換すると、サイズは約 33.3% 増加します(7MB の画像は約 9.3MB になります)
- APIYI の制限: 1 回のリクエストでアップロードされる画像の総量は 100MB 未満 である必要があります。すべての呼び出しは同期であり、サイズの大きすぎるペイロードはメモリ使用量の急増を引き起こす可能性があります

Google official technical specs: inline / console upload per-file limit is 7MB, supporting png/jpeg/webp/heic/heif

Base64 encoding increases size by about 33.3%: a 7MB image is roughly equal to 9.3MB
docs.cloud.google.com/vertex-ai/generative-ai/docs/models/gemini/3-pro-image
URL画像入力
Base64に加えて、Geminiネイティブエンドポイントでは、画像URL(画像ホスト / OSSアドレス)をfileData.fileUriを通じて直接渡すこともでき、ローカルでのエンコードが不要です。
URLアップロードはGeminiネイティブエンドポイントでのみ動作し、OpenAI互換モードではURLアップロードはサポートされず、Base64が必要です。
Curl の例(fileUri)
Pythonの例 (fileUri)
課金の基本(重要)
- 同期呼び出しの所要時間: Pro / 2 の 4K では、生成におよそ 30〜150秒 の妥当な時間がかかります
- タイムアウト時に切断しても課金されます: たとえば、生成に120秒かかるのにクライアント側のタイムアウトが100秒に設定されていて切断された場合でも、課金は発生します
- 429 / 503 は課金されません: 失敗したリクエストは課金対象外です(お客様を待たせたり、画像がないまま行き詰まらせたりしないようにしています)
- コンテンツセーフティによる拒否でも課金されます: お客様の入力にコンテンツセーフティ上の問題があり、Google が画像生成を拒否した場合でも、ステータスコード 200 は課金対象 です — エラー処理と下記の保証プランをご覧ください
タイムアウト設定(重要)
4K画像生成は全体的に時間がかかり、画像アップロード、API処理、Base64画像ダウンロード などの段階を含みます(当社のバックエンドでは API処理時間 に基づいて課金されます)。通常は、4K では約 50秒 かかります(ポーリングは除く) が、クライアントがタイムアウトを短く設定しすぎると、生成完了前に 早期に切断 され、次のようなエラーが報告されます:
Call logs: time-to-first-byte for 4K generation is about 43–61s, so the default 120s timeout is too tight
マルチターン会話編集(ネイティブは対応、リバースモデルは非対応)
Nano Bananaシリーズは Gemini ネイティブ形式 を使用し、真の会話型マルチターン編集 をサポートします。各ターンで生成された画像をcontents に role: "model" inlineData として戻し、そのうえで次のユーザー指示を送ります。モデルは 会話履歴全体 をもとに編集し、変更を 蓄積 します(例: まずソファの色を変え、その後アクセサリーを追加する — 前の変更は保持されます)。
これは「reverse」画像モデルとは根本的に異なります。組み込む前にここを明確にしておいてください:
テスト済み: 以前の画像を
model ロールのターンとしてバックフィルすると、Nano Banana 2 (gemini-3.1-flash-image-preview) は編集を継続して変更を正しく蓄積できます。一方、リバースモデルは 最後のユーザーメッセージ の参照画像しか読み取らないため、会話履歴を保持してもマルチターンでは機能しません。contents にバックフィル):
なぜレスポンスに複数の画像が含まれることがあるのか
gemini-3-pro-image を呼び出すと、まれに1回のレスポンスに複数の image パーツが含まれる(テストでは 2〜10 枚を確認)ことがあり、ログに散発的に記録される 6000超(5桁に達することもある)の output-token エントリと一致します。これは異常ではありません。Google の公式ドキュメントによると、Gemini 3 の image モデルでは「Thinking」がデフォルトで有効になっており(API では無効化できません)、モデルは構図やロジックを試すために中間画像を生成し、これらの下書きは最終版と並んで parts に表示されます。また、「Thinking の中の最後の画像が最終レンダリング画像でもある」とされています(公式ドキュメント: ai.google.dev/gemini-api/docs/image-generation)。2026年7月のテスト(GoogleネイティブのgenerateContent形式)に基づくと:
トリガーはprompt のタスク複雑度であり、「image editing」そのものではありません。複数の画像は単一の candidate内に収まり(複数 candidate ではありません)、各画像は完全な1枚の画像です。これは同じデザインの連続した下書き(同じ構図で、細部だけが少しずつ異なる)であり、最後のパーツが最終版です。これらの下書きは通常の image パーツとして返され(
thoughtSignature フィールドはありますが、thought: true フラグはありません)、Google のドキュメントでは Thinking が生成する中間画像は最大 2 枚とされていますが、私たちは複雑なタスクで最大 10 枚まで確認しました。
課金への影響: 各画像は固定の token 数で課金されます(1K/2K 解像度では画像1枚あたり 1120 tokens、4K では 2000 tokens)ので、output tokens は画像枚数に対して厳密に線形に増加します。ログ内の 6000超(極端な場合は約 13.5k まで)の output-token エントリは、単に 4〜10 枚の画像レスポンスであり、課金の異常ではありません。
推奨される downstream コード:
- 常に parts を反復処理する — 1レスポンスにつき1枚と決め打ちしないでください。画像ごとのカウントや保存ロジックは、実際のパーツ数に基づいて処理する必要があります
- 1枚だけ必要なときは最後の画像を使う: 前の下書きは細部が未完成で品質もわずかに低いため、最初の画像を取るのは避けてください
- prompt で画像枚数を制御するのはほぼ効果がありません(テストでは、「1枚だけ出力して」の指示は無視されました) — コード側で処理してください
- 複数画像のレスポンスは 35〜142秒(1K 解像度では、画像が増えるほどさらに長くなります)かかり、単一画像よりかなり長いです — 上記のタイムアウト推奨値(5分以上)を維持してください
よくある質問
エラーハンドリングガイド
失敗した生成、コンテンツモデレーションポリシー、やさしいプロンプト戦略を診断するための3つの重要指標
必読の一般的な開発者向け質問
失敗した生成のトラブルシューティングとよくある質問
失敗した生成の保証プラン
入力に起因しない失敗については、失敗したリクエスト数に応じてクレジットが返還されます
なぜ connection reset by peer / write_response_body_failed (500) が発生するのですか?
なぜ connection reset by peer / write_response_body_failed (500) が発生するのですか?
完全なエラーは次のようになります:これはたいてい、画像アップロードのサイズ超過が原因です。リクエスト本文が大きくなりすぎて接続が切断されます。次のベストプラクティスに従ってください:
- 画像枚数を制限する: 公式ルールの範囲内にしてください(1プロンプトあたり最大14枚 — 上の公式仕様を参照してください)。
- 1枚あたりのサイズを制限する: 各画像は5MB未満にしてください — 公式の1枚あたり上限は7MBですが、base64エンコードでサイズが約1/3増えるため、余裕を持たせてください。
- アップロード前にフロントエンドで圧縮する: APIに送信する前に、フロントエンド(またはサーバー側リレー)で画像を圧縮してください — 一般的には最長辺を制限し、JPEG/WebPに変換し、qualityパラメータを調整します。
- URL入力に切り替える: Geminiのネイティブ形式は、
fileData.fileUriを介して画像URLを渡すことをサポートしており、サイズ超過したbase64リクエスト本文を完全に回避できます — 上のURL画像入力を参照してください。
ユースケース
- AIチャットクライアント: Cherry Studio などのクライアントは、APIYIを介して直接画像を生成するように設定できます
- 生成テスト: チャットクライアントまたはコンソールでモデルの性能をすばやく確認できます
高度な要件
- 画像を URL 経由でアップロードしたいですか? Gemini のネイティブ エンドポイントは
fileData.fileUri経由で画像 URL を渡すことをサポートしています。ただし、OpenAI 互換モードでは URL アップロードに対応していないため、代わりに Base64 を使用してください。上の URL 画像入力 のコード例と注意点を参照してください。 - ダウンロード URL を直接取得したいですか(Base64 の代わりに)? NB-OSS グループを使用してください — Nano Banana OSS グループ を参照してください。