Skip to main content

簡潔な回答

Gemini の画像 API が HTTP 200 を返しても、レスポンスに candidates がなく promptFeedback.blockReason(多くは OTHER)のみが含まれている場合、そのリクエストは生成が開始される前にプロバイダーの入力チェックによってブロックされています。
  • この種のブロックは通常数秒以内に返され、通常の画像よりもはるかに高速です
  • OTHER には理由が記載されておらず、safetyRatings は空であることがよくあります
  • これは必ずしも prompt の書き方に関連しているとは限らず、多くの場合、1枚の参照画像が原因でトリガーされます
  • gemini-3-pro-image(Nano Banana Pro)は gemini-3.1-flash-image よりも厳格に入力をチェックするため、同じリクエストでも Pro ではブロックされ、Flash では成功することがあります
対処法は次のとおりです。まずどの画像がブロックの引き金になっているかを特定し、その後すべての参照画像を一貫して前処理します

識別方法

典型的なレスポンスは以下のようになります。

テスト検証事例

2026年9月 (UTC+8) に、あるファッションカタログのリクエストを再実行しました。1つの prompt と6枚の参照画像(ポーズ、人物、シーン、衣装、靴と靴下のコラージュ、帽子)、アスペクト比 2:3、解像度 2K、responseModalities: ["IMAGE"] という構成です。
  • gemini-3-pro-image は3回連続で blockReason: OTHER を返しましたが、同じリクエストが gemini-3.1-flash-image では成功しました
  • 画像を繰り返し二分割して検証した結果、トリガーとなっていたのは人物の参照画像のみであることが判明しました。これは正面、背面、側面、顔のアップパネルを含む AI 生成のキャラクター設定シートでした
  • その画像は、「背景を薄いグレーに変更してください」といった無関係な指示を含め、どのような prompt を指定してもブロックされました
  • 最も疑っていた2枚の画像(ウォーターマーク入りの実在人物のポーズ写真と、ロゴ入りの帽子の写真)は、いずれも単体では通過しました
主な発見: 言い換えれば、このチェックは特定の画像の厳密なピクセルに対して非常に敏感である可能性があり、画像を一度再エクスポートするだけでリクエストが通るようになります。プロバイダーは OTHER が何に基づいているかを公開していないため、これ以上原因を特定することはできません。
この事例は、1つのリクエストで多数の参照画像を送信することや、複数のステップを単一の生成処理に統合すること自体が問題ではないことを示しています。OTHER が発生した場合は、prompt を書き直したりワークフローを分割したりする前に、まず原因となっている画像を特定してください。

対象の画像を特定する方法

1

ステップ1:再現性を確認する

変更を加えずにリクエストを2〜3回再送信します。blockReasonのブロックは通常、一貫して再現します。たまにしか失敗しない場合は、NO_IMAGEの類いである可能性が高くなります。
2

ステップ2:promptを除外する

すべての画像はそのまま残し、promptを「背景を薄いグレーに変更する」などの無関係でシンプルな指示に置き換えます。それでもブロックされる場合、原因は画像にあります。
3

ステップ3:画像を半分に分割する

それぞれの半分を個別に送信し、ブロックされ続けている半分のみを1枚の画像になるまで分割し続けます。6枚の画像であれば、最大でも3ラウンドで済みます。
4

ステップ4:その画像を修正する

後述の「推奨事項」に記載されている通りに画像を再エクスポートし、完全なリクエストを再度送信して確認します。
絞り込みを行う際、1枚の画像が生成されればそのグループを「合格」とするのに十分であるため、繰り返す必要はありません。2回連続でブロックされれば、「ブロック」と判定するのに十分です。検索全体でも、通常は十数回程度の呼び出ししかかかりません。

推奨事項

シナリオ1:手動作業(キャンバスやツールでの生成)

  1. アップロード前に参照画像を再エクスポートする:任意の画像エディタ(内蔵のプレビューアプリや Photoshop など)を使用して、長辺を2048px以下、品質90〜95のJPEGとしてエクスポートします。
  2. 大きな画像を縮小する:長辺が3000〜4000pxの元画像は、結果に影響を与えることなく2048pxに縮小でき、アップロードも高速になります。
  3. リクエストが数秒以内に失敗した場合は、まず参照画像を疑う:直近に追加した画像を再エクスポートして再試行してください。それでも解決しない場合は、上記のように画像を1枚ずつ確認します。
  4. 人物の参照には全身画像を優先する:上記のケースでは、キャラクターシートを分割したところ、正面の全身パネル単体で通過しました。キャラクターシートがブロックされ続ける場合は、その全身ビューのみを使用してみてください。
  5. 一時的な代替手段:Pro で画像が通過できない場合は、そのステップで gemini-3.1-flash-image を使用してください。

シナリオ2:コード(自動処理)

1. 個別の画像に対処するのではなく、送信前にすべての参照画像を前処理する:sRGBに変換 → EXIFの向きを適用 → 長辺を2048pxに制限 → JPEGとして再エンコード(品質90〜95) → メタデータを削除。 主なメリットは、リクエストボディが大幅に小さくなり、アップロードが高速化されることです(上記のケースにおける元のリクエストは約4.6 MBでした)。また、このような OTHER によるブロックも削減できます。Node.js の例:
Pillow を使用した Python での同様のパイプライン:
2. 失敗のタイプごとに異なる対応を行う
自動再試行は、理由が不明な OTHER にのみ適用されます。明示的な安全性の理由である場合、画像の再エンコードによって結果を変更することはできませんし、変更すべきではありません。代わりにユーザーにコンテンツの調整を依頼してください。
3. トラブルシューティングの詳細を記録する:失敗するたびに、responseId および各参照画像のハッシュと寸法を記録します。これにより画像を迅速に特定できるようになり、サポートにお問い合わせいただく際に必要な情報を提供できます。

よくある質問

2つのモデルでは異なる入力チェックが使用されており、Pro のほうがより厳格です。flash で通過した参照画像が Pro でブロックされるのは想定通りの挙動であり、リクエスト自体に誤りがあることを意味するわけではありません。
はい。上記の事例でブロックされた画像は、ユーザー自身の写真から再生成されたキャラクターシートでした。画像がブロックされるかどうかは、その出所だけで単純に決まるわけではありません。本ページの説明に従って該当画像を特定し、前処理を行ってください。
上記の事例では、6枚の画像自体が問題だったわけではありません。該当する1枚の人物画像を差し替えた後は、6枚すべての画像を含んだリクエストでも正常に生成されました。
そのリクエストに対して課金記録が作成されたかどうかについては、APIYI の呼び出しログをご確認ください。

まだ解決しない場合はサポートにお問い合わせください

スムーズに対応できるよう、以下の情報を含めてご連絡ください:
  • モデル名と token グループ;
  • 完全なレスポンス(少なくとも promptFeedback および responseId)と request ID
  • 発生時刻(タイムゾーンを含む);
  • 特定した参照画像(共有可能な場合)。
完全な API キーは絶対に送信しないでください。スクリーンショットやログを共有する前に、キーをマスキングしてください。

WeCom サポート

WeCom サポートの QR コードQR コードをスキャンするか、このカードをクリックしてサポートに直接お問い合わせください。

メールサポート

サポート: [email protected]件名に「blockReason」とモデル名を含めることを推奨します。

関連ドキュメント

Gemini 画像 API が NO_IMAGE を返す理由

不鮮明な prompt の意図によって画像が生成されない原因とその修正方法

Nano Banana 画像生成の失敗

安全性、透かし除去、著名なIP、未成年者などの一般的な原因

Gemini 画像 API のエラーハンドリング

完全なレスポンス確認手順とユーザーフレンドリーなエラーメッセージ

ログ内の課金額はどのように確認すればよいですか?

呼び出しログを使用して、リクエストが成功し課金されたかを確認します