Skip to main content

モデルカード

完全な価格比較、リクエストごとの課金と 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 は非対応)
同じコードで初代 gemini-2.5-flash-image を呼び出す場合は、imageSize パラメータを削除する必要があります2K / 4K をサポートしていないため)、さもないと呼び出しは失敗します。

組み込み方法

公式ドキュメント

  • 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/heifjpg 形式はすでに APIYI でサポートされています)
  • Base64 のサイズ増加: 画像を Base64 に変換すると、サイズは約 33.3% 増加します(7MB の画像は約 9.3MB になります)
  • APIYI の制限: 1 回のリクエストでアップロードされる画像の総量は 100MB 未満 である必要があります。すべての呼び出しは同期であり、サイズの大きすぎるペイロードはメモリ使用量の急増を引き起こす可能性があります
Google Gemini 3 Pro Image の公式技術仕様表:単一画像の上限は 7MB、1 プロンプトあたり最大 14 枚の画像、対応アスペクト比と MIME タイプ

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

Base64 のサイズ計算:7MB のソース画像は、4/3 の比率でエンコードすると約 9.33MB になります

Base64 encoding increases size by about 33.3%: a 7MB image is roughly equal to 9.3MB

ベストプラクティス: API に送信する前に画像へ 可逆圧縮 を適用し、過剰な解像度によってリクエストが遅くなるのを避けてください。 Google 公式仕様の参照(コピーしてご自身でアクセスしてください): docs.cloud.google.com/vertex-ai/generative-ai/docs/models/gemini/3-pro-image

URL画像入力

Base64に加えて、Geminiネイティブエンドポイントでは、画像URL(画像ホスト / OSSアドレス)をfileData.fileUriを通じて直接渡すこともでき、ローカルでのエンコードが不要です。
URLアップロードは画像ホストとOSSアドレスに厳しい要件があります: アドレスがグローバルCDN上にない場合(たとえば、Tencent Cloud Object Storage の既定は中国国内のみのCDNです)、Googleのサーバーが画像に到達できない可能性が非常に高く、リクエストは失敗します(典型的な症状: 出力内で画像が参照されません)。可能であれば、より安定性の高いBase64アップロードを優先してください — プラットフォームの観点では、これが最も運用に力を入れており、最も信頼性の高い経路です。
URLアップロードはGeminiネイティブエンドポイントでのみ動作し、OpenAI互換モードではURLアップロードはサポートされず、Base64が必要です。

Curl の例(fileUri)

Pythonの例 (fileUri)

fileDatamimeType、およびfileUricamelCase である必要があります(file_data / file_uri ではありません)。そうでない場合、パラメータは無視され、画像は参照されません。

課金の基本(重要)

  • 同期呼び出しの所要時間: Pro / 2 の 4K では、生成におよそ 30〜150秒 の妥当な時間がかかります
  • タイムアウト時に切断しても課金されます: たとえば、生成に120秒かかるのにクライアント側のタイムアウトが100秒に設定されていて切断された場合でも、課金は発生します
  • 429 / 503 は課金されません: 失敗したリクエストは課金対象外です(お客様を待たせたり、画像がないまま行き詰まらせたりしないようにしています)
  • コンテンツセーフティによる拒否でも課金されます: お客様の入力にコンテンツセーフティ上の問題があり、Google が画像生成を拒否した場合でも、ステータスコード 200 は課金対象 です — エラー処理と下記の保証プランをご覧ください

タイムアウト設定(重要)

4K画像生成は全体的に時間がかかり、画像アップロード、API処理、Base64画像ダウンロード などの段階を含みます(当社のバックエンドでは API処理時間 に基づいて課金されます)。通常は、4K では約 50秒 かかります(ポーリングは除く) が、クライアントがタイムアウトを短く設定しすぎると、生成完了前に 早期に切断 され、次のようなエラーが報告されます:
ログ: gemini-3-pro の 4K 生成における最初のバイトまでの時間は 43〜61 秒です

Call logs: time-to-first-byte for 4K generation is about 43–61s, so the default 120s timeout is too tight

より安全にするため、解像度ごとにタイムアウトを設定することをおすすめします:

マルチターン会話編集(ネイティブは対応、リバースモデルは非対応)

Nano Bananaシリーズは Gemini ネイティブ形式 を使用し、真の会話型マルチターン編集 をサポートします。各ターンで生成された画像を contentsrole: "model" inlineData として戻し、そのうえで次のユーザー指示を送ります。モデルは 会話履歴全体 をもとに編集し、変更を 蓄積 します(例: まずソファの色を変え、その後アクセサリーを追加する — 前の変更は保持されます)。 これは「reverse」画像モデルとは根本的に異なります。組み込む前にここを明確にしておいてください:
テスト済み: 以前の画像を model ロールのターンとしてバックフィルすると、Nano Banana 2 (gemini-3.1-flash-image-preview) は編集を継続して変更を正しく蓄積できます。一方、リバースモデルは 最後のユーザーメッセージ の参照画像しか読み取らないため、会話履歴を保持してもマルチターンでは機能しません。
最小例(各出力を同じ contents にバックフィル):
詳細(履歴バックフィルと再投入の方式、既存画像からのマルチターン開始)は 画像編集 API · マルチターン会話編集 にあります。

なぜレスポンスに複数の画像が含まれることがあるのか

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分以上)を維持してください
usageMetadata フィールドの完全な内訳(details と totals の差、拒否レスポンス時のカウントの癖、その他の詳細)については、Usage Fields と Output の解説 をご覧ください。

よくある質問

エラーハンドリングガイド

失敗した生成、コンテンツモデレーションポリシー、やさしいプロンプト戦略を診断するための3つの重要指標

必読の一般的な開発者向け質問

失敗した生成のトラブルシューティングとよくある質問

失敗した生成の保証プラン

入力に起因しない失敗については、失敗したリクエスト数に応じてクレジットが返還されます
完全なエラーは次のようになります:
これはたいてい、画像アップロードのサイズ超過が原因です。リクエスト本文が大きくなりすぎて接続が切断されます。次のベストプラクティスに従ってください:
  • 画像枚数を制限する: 公式ルールの範囲内にしてください(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 グループ を参照してください。