モデルカード
完全な価格比較、1リクエスト課金と token ベース課金の比較、ならびに token の選び方については、Nano Banana シリーズの料金をご覧ください。
サイズ制御
- 元画像の比率に従う:
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 + キーを APIYI のものに置き換えるだけで構いません。その他のパラメータは公式のものとすべて同じです
公式ステータスの確認(上流側の問題の診断)
Nano Banana シリーズは Google の AIStudio / Gemini API の上で動作しています。まれに、ぼやけた 2K / 4K 出力や出力失敗が、統合レイヤーではなく Google 側の問題で発生することがあります。Google の公式ステータスページを確認できます(ご自身でコピーしてアクセスしてください):aistudio.google.com/status。
たとえば、2026年6月19日にはそのページで「Issues with Nano Banana」と報告されており、Gemini API と AI Studio 上の Nano Banana 2 / Pro で 2K または 4K 解像度に問題が発生していました。同様の症状が見られた場合は、まず公式ステータスページと照らし合わせて、上流側の障害かどうかを素早く判断してください。
APIYI は冗長化のため、Nano Banana シリーズを AIStudio + Vertex のデュアルチャネル で運用しています。片方の公式チャネルに問題が発生しても、もう一方が引き継いでサービスを利用可能な状態に保ちます。
エンドポイント対応
- 推奨エンドポイント(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 prompt あたり最大 14 枚の画像
- 対応 MIME type:
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 は課金対象です — 下記のエラー処理と保証プランをご覧ください
Google Search のグラウンディングは、1回ごとの価格に加算されます
Pro はgoogleSearch ツールをサポートしています(3/3 のテスト実行でグラウンディングが発動し、完全な groundingMetadata を返しました)。これは、天気カード、株価チャート、その他リアルタイム情報が必要なあらゆる用途に役立ちます。
ただし、検索呼び出し料金は 1回ごとの価格 $0.09 に上乗せされ、含まれていません:
Image Search のグラウンディング(
searchTypes.imageSearch)は Pro では動作しません — 0/2 回の実行で発動せず、imageSearchQueries は groundingMetadata に一度も表示されませんでした。これは Nano Banana 2(gemini-3.1-flash-image)専用です。Nano Banana 2 · 課金に影響する 3 つのパラメータ をご覧ください。thinkingLevel は Pro では効果がありません — NB2 からコピーしないでください
generationConfig.thinkingConfig.thinkingLevel は Nano Banana 2 シリーズ専用 です。Pro に high を渡しても:
- エラーにはなりません — リクエストは通常どおり 200 を返します
- しかし効果はありません: 測定された
thoughtsTokenCountは 108〜156 の範囲で、パラメータなしで見られた 130〜159 の範囲と完全に重なっていました - Pro の thinking は常に有効で、Google の公式ドキュメントにあるとおり調整できません
タイムアウト設定(重要)
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ネイティブ形式 を採用し、真の会話型マルチターン編集 に対応しています。各ターンで生成された画像をrole: "model" inlineData として contents に戻し入れ、次のユーザー指示を送ります。モデルは 会話履歴全体 をもとに編集し、変更を 累積 します(たとえば、最初にソファの色を変えてからアクセサリーを追加すると、前の変更は保持されます)。
これは「リバース」画像モデルとは根本的に異なるため、統合前に明確に理解してください:
検証済み: 以前の画像を
model ロールのターンとして戻し入れると、Nano Banana 2 (gemini-3.1-flash-image-preview) は編集を継続し、変更を累積できることが正しく確認されました。リバースモデルは 最後のユーザーメッセージ の参照画像しか読み取らないため、会話履歴を保持しても、そこでのマルチターンには機能しません。contents に戻し入れる):
画像を取得するには parts を必ず反復処理する — インデックス参照はしない
parts は 異種配列 です。画像セグメントだけを含むこともあれば、テキストと画像セグメントが交互に入ることもあり、長さも順序も保証されません。したがって、parts[0] / parts[1] のようなハードコードされたアクセスは、断続的に必ず失敗します。
テストでは、次の 3 つの構成が確認されています。
テキストセグメントが発生する理由は 1 つではありません。
TEXT を responseModalities に含める場合も、モデルに自己説明させるような prompt でも、画像と一緒にテキストが返されます。そして、そのテキストが画像の前後どちらに来るかも固定ではありません。つまり、画像が入るインデックスは一定ではありません。そのため、同じコードでもリクエストごとに異なる構造を受け取ることがあります。
正しい方法は、位置ではなくフィールドの形状で選択することです。最初の inlineData ではなく、最後の inlineData を取ることに注意してください。複雑なタスクでは複数の画像が返され、最後のものが最終版です(次のセクションを参照):
レスポンスに複数の画像が含まれることがあるのはなぜですか
gemini-3-pro-image を呼び出すと、まれに 1 回のレスポンスに複数の画像パートが含まれる(テストでは 2〜10 件を確認)ことがあり、ログに散発的に 6000+(極端な場合は 5 桁)output-token エントリが記録されることがあります。これは異常ではありません。Google の公式ドキュメントでは、Gemini 3 の画像モデルはデフォルトで「Thinking」が有効(API では無効化できない)で、モデルは構図とロジックを検証するために途中の画像を生成し、これらの下書きは最終版と並んで parts に表示され、さらに「Thinking 内の最後の画像が、最終的にレンダリングされる画像でもある」(公式ドキュメント: ai.google.dev/gemini-api/docs/image-generation)とされています。2026 年 7 月に実施したテスト(Google ネイティブgenerateContent形式)に基づくと:
トリガーは prompt のタスクの複雑さ であり、「画像編集」そのものではありません。複数の画像は依然として 1 つの候補(複数の候補ではありません)内にあり、各画像は完全な画像です。つまり、同じデザイン(同じ構図で、細部が少しずつ異なる)の連続した下書きであり、最後のパートが最終版 です。これらの下書きは通常の画像パートとして返されます(
thoughtSignature フィールドはありますが、thought: true フラグはありません)。Google のドキュメントでは Thinking は最大 2 枚の途中画像を生成するとされていますが、複雑なタスクでは最大 10 枚を確認しました。
課金への影響: 各画像は固定の token 数で課金されます(1K/2K 解像度では画像 1 枚あたり 1120 token、4K では 2000 token)ので、output token は画像数に比例して厳密に直線的に増加します。ログに散発的に 6000+(極端な場合は約 13.5k)と記録されている output-token エントリは、単に 4〜10 枚の画像レスポンスであり、課金の異常ではありません。
推奨する後続コード:
- 常にパートを順に処理する — 1 回のレスポンスにつき 1 画像と決めつけないでください。画像ごとのカウントや保存ロジックは、実際のパート数に基づいて行う必要があります
- 1 枚だけ必要な場合は最後の画像を使う: 先頭の下書きは細部が未完成で品質もわずかに低いため、最初の画像は使わないでください
- prompt で画像枚数を制御するのはほとんど効果がありません(テストでは「1 枚だけ出力して」という指示は無視されました)— コード側で処理してください
- 複数画像のレスポンスは 35〜142 秒かかります(1K 解像度で、画像数が多いほど長くなります)。単一画像のレスポンスよりかなり長いです — 上記のタイムアウト推奨(5 分以上)を維持してください
よくある質問
エラー処理ガイド
生成失敗、コンテンツモデレーションポリシー、親しみやすい prompt 戦略を診断するための3つの重要な指標
必読の開発者向けよくある質問
生成失敗のトラブルシューティングとよくある質問
生成失敗保証プラン
入力に起因しない失敗については、失敗したリクエスト数に応じてクレジットを返還します
なぜ connection reset by peer / write_response_body_failed (500) が発生するのですか?
なぜ connection reset by peer / write_response_body_failed (500) が発生するのですか?
完全なエラーは次のようになります:これは通常、画像アップロードのサイズが大きすぎることが原因です — リクエストボディが大きくなりすぎて接続が切断されます。以下のベストプラクティスに従ってください。
- 画像数を制限する: 公式ルールの範囲内に収めてください(prompt あたり最大14枚 — 上記の公式仕様を参照してください)。
- 画像1枚あたりのサイズを制限する: 画像1枚ごとに5MB未満にしてください — 公式の1枚あたり上限は7MBで、base64 エンコーディングによりサイズは約3分の1増加するため、余裕を持たせてください。
- アップロード前にフロントエンドで圧縮する: API に送信する前に、フロントエンド(またはサーバーサイドのリレー)で画像を圧縮してください — 一般的には、長辺を制限し、JPEG/WebP に変換し、品質パラメータを調整します。
- URL入力に切り替える: Gemini のネイティブ形式では、
fileData.fileUriを介して画像 URL を渡せるため、大きすぎる base64 のリクエストボディを完全に回避できます — 上記の URL画像入力 を参照してください。
利用例
- AI チャットクライアント: Cherry Studio などのクライアントを、APIYI 経由で直接画像を生成するように設定できます
- 生成テスト: チャットクライアントまたはコンソールでモデルの性能をすばやく確認できます
高度な要件
- URL経由で画像をアップロードしたいですか? Gemini のネイティブ エンドポイントでは
fileData.fileUriを通じて画像URLを渡すことがサポートされています。ただし、OpenAI互換モードでは URL アップロードはサポートされていないため、代わりに Base64 を使用してください。上記の URL画像入力 にあるコード例と注意事項をご覧ください。 - Base64 ではなく、ダウンロードURLを直接取得したいですか? NB-OSS グループをご利用ください — Nano Banana OSS グループ をご覧ください。