Gemini IMAGE_SAFETY・画像未生成エラー完全トラブルシューティングガイド

Geminiの画像生成が「サイレントに失敗」しているように見える場合、まず理解すべき重要なことがあります。それは「サイレント障害」は通常、単一の問題ではないということです。2026年3月15日時点のGoogleの公式ドキュメントでは、ユーザーがひとまとめにしがちな少なくとも4つの異なる状態が明確に区別されています。すなわち、プロンプト側のブロック、出力側の画像ブロック、画像が全く生成されないケース、そしてあいまいなプロンプトやリクエスト形式のミスといった非ポリシー障害です。これら4つをすべて「Geminiのコンテンツポリシーが壊れている」と扱ってしまうと、誤った修正を繰り返すことになります。

要点を簡潔に述べると、入力プロンプトがブロックされた場合は promptFeedback が設定され、candidates は返されません。プロンプトが受け入れられたものの生成された出力画像がブロックされた場合、Googleによれば candidates は存在するが content がなく、finishReason がレスポンスが停止した理由を示します。finishReason が IMAGE_SAFETY であることは NO_IMAGE とは異なり、どちらも STOP を伴うテキストのみの拒否とは異なります。それぞれが異なる次のステップを指し示しているため、この区別が重要なのです。

このガイドでは、「Gemini画像サイレント障害」「IMAGE_SAFETY 修正」「Gemini画像コンテンツポリシー」といったフレーズで検索されるシナリオに焦点を当てています。Geminiの人物生成論争に関する2024年の古い情報ではなく、現在のGoogleドキュメントを基にしています。また、2025年11月・12月のGoogle AI Developers Forumの実際のスレッドを参照して、プロンプトが安全に見えるにもかかわらずAI StudioやGemini APIが有効な画像を返さないなど、現実の障害がユーザーを特に混乱させる場面を示しています。

Gemini画像出力だけでなく、モデル横断のプロンプト拒否問題に取り組んでいる場合は、プロンプトブロック・安全警告の修正ガイドでChatGPT、Gemini、Claude、Azureのポリシーレベルの対処法をご覧ください。本記事はより狭く、より技術的です。プロンプトを書き直したり、フィルターを緩めたり、プラットフォームがダウンしていると思い込む前に、Gemini画像障害を正確に診断することを目的としています。

要点まとめ

• プロンプトを変更する前にペイロードを確認してください。promptFeedback は、画像生成が完了する前にプロンプトがブロックされたことを意味します。
• candidates が存在するが content がなく、finishReason が IMAGE_SAFETY の場合、画像出力は生成開始後にフィルタリングされています。
• finishReason が NO_IMAGE の場合、Geminiはリクエストを受け入れたものの画像を生成しませんでした。通常、より明確な画像指示、リトライ、またはリクエスト形式のデバッグが必要です。
• テキストのみの返答は、必ずしもポリシー障害ではありません。Googleの現在の画像生成制限ページには、あいまいなプロンプトでテキストのみが返される可能性があると記載されています。
• 設定可能な安全設定ですべての保護を無効化することはできません。Googleの安全設定ドキュメントには、コアとなる危害に対する組み込みの保護はオフにできないと明記されています。
• 404、429、503エラーをコンテンツポリシーの問題として扱わないでください。これらが発生している場合は、Gemini 3 Pro Imageエラーコードガイドを参照してください。

Geminiがプロンプトをブロックしたか、画像をブロックしたか、何も生成しなかったかを見分ける方法

デバッグ時間の多くが無駄になるのは、分類ステップをスキップしてしまうからです。「画像がない」と見て「コンテンツポリシーの問題だ」と思い込み、実は問題でもなかったプロンプトを20分かけて書き直す、というパターンです。Googleのブロックされたレスポンスのドキュメントでは、より良いワークフローが示されています。まずレスポンスの構造を調べ、それから何の修正が適切かを判断するというものです。

最速の考え方はこうです。

GoogleのVertex AIドキュメントでは、プロンプトのブロックとレスポンスのブロックが明確に区別されています。プロンプト自体がブロックされている場合、promptFeedback が設定され、検査する候補はありません。レスポンスがブロックされている場合、promptFeedback はなく、candidates が存在し、content の欠落と finishReason が何が起こったかを示します。「画像を生成できませんでした」というUIレベルのメッセージが、それだけでは問題を診断するには粗すぎる理由がここにあります。APIペイロードは通常、製品のコピーよりも情報量が多いのです。

これはまた、なぜ一部のユーザーが問題を「サイレント」と呼ぶかを説明しています。ペイロード自体はサイレントでないかもしれませんが、使用しているサーフェスはまだサイレントに感じられることがあります。AI Studio、Geminiアプリ、または薄い統合レイヤーでは、製品が一般的なエラーや画像スロットをまったく表示しないことがあります。APIまたはVertexを通じてリクエストを再現して完全なレスポンスを確認できれば、システムがプロンプトをブロックしたのか、画像をブロックしたのか、そもそも生成しなかったのかを多くの場合把握できます。

AI Studioまたはアプリの症状のみで生のペイロードがない場合、エスカレーションの前に次のクイックフォールバック手順を使用してください。

1. 新しいセッションを開始し、短い名詞句を送るのではなく、明示的に「…の画像を生成してください」と依頼する。
2. 「木製テーブルの上の赤いセラミックマグの画像を生成してください」のような小さな無害なテストプロンプトを試す。
3. 無害なテストが機能する場合、元のプロンプトや以前のチャットコンテキストが原因である可能性が高い。
4. 無害なテストも同様に失敗する場合は、同じリクエストがAPIまたはVertexで機能するか確認するか、プロンプトのみの問題ではなく、より広い製品サーフェスの問題として扱う。

チームにとって、この分類ステップは不変の手順にすべきです。「画像生成が失敗した」とだけログに記録しないでください。モデルID、リクエストサーフェス、promptFeedback が存在したか、candidates が存在したか、最終的な finishReason、inlineData 画像パーツが返されたか、正確なUTCタイムスタンプを記録してください。そのデータがなければ、ポリシーのバグ、ロールアウトのリグレッション、通常のプロンプトのあいまいさがすべてインシデントレビューで同じように見えてしまいます。

IMAGE_SAFETY、NO_IMAGE、STOP が実際に意味すること

Googleの現在のGemini APIリファレンスは、このトピックにとって特に重要です。プロンプトブロックに属するenumと、候補の完了に属するenumが示されているからです。この分割が正しい診断の基盤となります。

プロンプト側のブロックは BlockReason 値を使用します。2026年1月12日に最終更新された公式リファレンスによれば、これには SAFETY、BLOCKLIST、PROHIBITED_CONTENT、IMAGE_SAFETY が含まれます。候補側の完了は FinishReason 値を使用します。画像ユースケースで最も重要なのは IMAGE_SAFETY、IMAGE_PROHIBITED_CONTENT、IMAGE_OTHER、NO_IMAGE、IMAGE_RECITATION です。言葉が似ていても、同じ場所で同じ意味を持つわけではありません。

まず STOP から始めましょう。これが最も人々を混乱させるものです。GoogleのGemini画像生成の責任あるAIページでは、潜在的に安全でない画像リクエストが FinishReason = STOP を伴うテキスト拒否を生成することがあると説明されています。つまり、システムは「フィルターエラー」と言っているのではなく、通常のモデルテキストで「その画像は作成しません」と言っているのかもしれません。だからこそ、テキストのみの返答は無視せずに読む必要があります。

IMAGE_SAFETY は異なります。finishReason = IMAGE_SAFETY を見た場合、リクエストはプロンプトブロックよりも先へ進んでいます。Googleはこれを出力側の安全停止として文書化しています。プロンプトは候補レコードを生成するほど受け入れられましたが、最終的な画像コンテンツは保留されました。多くのユーザーが「Geminiが開始して、そしてサイレントに失敗した」と感じる理由がここにあります。実際には、画像候補は概念的に存在しますが、コンテンツはリリースされませんでした。

NO_IMAGE はまた異なります。これは自動的に「ポリシー」を意味しません。画像が生成されなかったという意味です。これはリクエストがあいまいだったから、モデルが画像動作ではなくテキスト動作を選択したから、生成試行が有用に完了しなかったから、またはリクエストの形式やトランスポートが有効な画像レスポンスを妨げたからという可能性があります。Googleの現在の画像生成制限ページには、プロンプトがあいまいな場合Geminiはテキストを作成し画像を作成しない可能性があり、モデルが完了前に停止する可能性があると明示されています。これらは運用上の修正であり、ポリシーの解釈ではありません。

IMAGE_OTHER は、広範であるため最も満足のいかないenumです。実際には、リクエストが通常の画像出力で終わらず、すぐ次のステップはコンテキストを調べることを示すキャッチオールバケツとして扱ってください。プロンプトの文言、モデルサーフェス、リクエストペイロード、参照画像の数、問題がリージョンやセッションをまたいで再現可能かどうか。これは、むやみに推測する理由ではなく、より多くのコンテキストをログに記録する理由です。

IMAGE_PROHIBITED_CONTENT は IMAGE_SAFETY よりも強力です。これは調整可能な安全分類ではなく、禁止されたカテゴリを指します。GoogleのVertex安全フィルターガイドでは、特に禁止されたコンテンツに関しては一部のカテゴリが設定不可であるという、より広い点を指摘しています。IMAGE_PROHIBITED_CONTENT に遭遇した場合、「これをどのように通過させるか」という観点で考えるべきではありません。「このリクエストはポリシーラインを越えている」という観点で考えるべきです。

微妙だが重要な詳細があります。同じラベルが異なるレイヤーに現れることがあります。IMAGE_SAFETY はプロンプト側の BlockReason と候補側の FinishReason の両方に現れる可能性があります。だからこそ、enumの文字列だけでは診断できません。それがどこに現れたかを知る必要があります。モデルは候補を返しましたか？ promptFeedback は設定されていましたか？ content は欠落していましたか？これらの構造的な手がかりは、言葉自体よりも重要です。

実用的なルールはシンプルです。

• promptFeedback が存在する場合：プロンプト側の分類から始める。
• finishReason = STOP：拒否テキストを読み、モデルの拒否として扱う。
• finishReason = IMAGE_SAFETY：出力フィルタリングとして扱う。
• finishReason = NO_IMAGE：特に証明されない限り、受け入れられたが画像が生成されなかったとして扱う。

このフレームワークは、どんな一般的な「プロンプトを書き直してください」というアドバイスよりも多くのケースを解決します。

テキストのみの返答と非ポリシーのサイレント障害の迅速な修正方法

Googleの現在のGemini画像生成制限ページは、このセクションで最も役立つ公式ページです。多くの開発者が試行錯誤からしか学べないことを確認しているからです。画像なしの結果の一部は、ポリシーの拒否ではありません。生成形式の問題です。このセクションをスキップしてポリシーの調整に直接ジャンプすると、多くの障害を誤診することになります。

修正1：明示的に画像を要求する。 恥ずかしいほど単純ですが、驚くほど頻繁に機能します。プロンプトが分析、ブレインストーミング、またはキャプション作成のように読める場合、Geminiはテキストを返すことがあります。Googleの文言では、プロンプトがあいまいな場合モデルはテキストのみを作成し画像を作成しない可能性があると述べています。「夕暮れ時の静かな日本の店先」と言う代わりに、「夕暮れ時の静かな日本の店先の画像を生成してください。シネマティックフォトスタイル、16:9構図。」と言ってください。その1つの追加指示がモデルのモード選択を変えることがあります。

修正2：SDKが期待する方法で画像出力を要求したか確認する。 SDKによって同じフィールドの名前がわずかに異なりますが、考え方は同じです。一般的なマルチモーダル完了ではなく、画像出力を要求してください。新しいGemini SDKを使用していて画像レスポンスモダリティを忘れると、モデルはテキストで返答することがあります。モデルの視点では、厳密な画像生成の質問ではなく一般的なコンテンツ生成の質問をされたからです。

画像の意図を明示する最小限のPythonの例を示します。

python
from google import genai
from google.genai import types

client = genai.Client(api_key="YOUR_API_KEY")

response = client.models.generate_content(
    model="gemini-2.5-flash-image",
    contents="Generate an image of a ceramic coffee cup on a walnut desk, soft morning light, editorial product photo.",
    config=types.GenerateContentConfig(
        response_modalities=["IMAGE"]
    )
)

レスポンスがテキストのみの場合、「Geminiが壊れている」と結論付けないでください。返ってきたパーツを確認してください。テキストパーツのみで inlineData がない場合、ペイロードが別のことを証明するまでは、モード選択またはリクエスト形式の問題を見ています。

修正3：不完全な生成を規律的な方法でリトライする。 Googleの2026年3月14日に最終更新された画像生成制限ページでは、モデルが完了していない場合でもコンテンツの生成を停止することがあり、リトライまたはプロンプトの変更を明示的に推奨しています。これは盲目的に30回リトライする許可ではありません。ポリシー停止ではなく不完全な生成を示すペイロードの場合、少数の制御されたリトライが合理的という意味です。実際には、すぐ1回のリトライとプロンプトを調整した1回のリトライで、障害が一時的かどうか判断するのに十分です。

修正4：混合タスクによるあいまいさを減らす。 多くの失敗するプロンプトは、Geminiに1ターンで分析、要約、比較、画像生成をすべて依頼します。これはチャット形式の統合でテキストファーストの回答の確率を高めます。これらのジョブを分離してください。モデルに画像を理解させてから新しい画像を生成させる必要がある場合は、推論ステップを先に、生成ステップを後に行ってください。リクエストが単目的であるほど、何かが問題になった際に診断しやすくなります。

修正5：画像入力の送信方法を調べる。 2025年11月3日の有用なフォーラムスレッドでは、画像から画像への編集が inlineData では機能したが、特定の方法で fileData を使用した場合にテキストのみが返されたと報告されています。Googleフォーラムの回答者が機能するアップロードパターンを示し、元の投稿者は後でフローが機能したと確認しました。重要な教訓は「ファイルは絶対に使用しない」ではありません。リクエストトランスポートが動作を変える可能性があり、テキストのみの結果は自動的にコンテンツポリシーを意味しないということです。同じ無害なプロンプトで fileData が失敗して inlineData が機能する場合、コンテンツポリシーの判定ではなく統合の問題を見ている可能性が高いです。

修正6：文書化された画像入力の制限を尊重する。 Googleの現在の制限ページでは、Gemini 2.5 Flash Imageは最大3枚の入力画像で最もよく機能し、Gemini 3 Pro Imageは14枚以下にとどめるべきと述べています。参照画像を多く詰め込みすぎると、解釈とデバッグが難しくなります。ハードリミットに達していない場合でも、複雑な参照スタックは不正形式または使用できない出力の可能性を高めます。サイレント障害のトリアージには、参照画像を少なくすることで再現が容易になります。

修正7：コンテンツを修正する前に明らかな運用レイヤーを確認する。 全く同じプロンプトとペイロードが昨日は機能していて、今日は404、429、または503で失敗している場合、コンテンツポリシーの変化を見ているのではありません。ルーティング、クォータ、または容量の問題です。問題がプロンプト固有ではなくシステム的に見える場合は、Gemini 3 Pro Image安定チャンネルガイドと本記事を組み合わせることをお勧めします。

最後に、時系列を無視しないでください。安全なプロンプトが狭い時間帯に突然機能しなくなり、複数のフォーラムユーザーが同様の症状を報告している場合、それはリグレッションのヒントです。2025年11月25日のGoogle AI Developers Forumのスレッドでは、無害な写真のワークフローがほとんどまたは全くポリシーの説明なしに失敗し、約48時間以内に部分的に回復したと説明しています。これはすべてのケースの証拠ではありませんが、プラットフォームの動作が時間とともに変化するリマインダーです。適切な修正が「より良い婉曲表現を考案する」ことではない場合があります。「正確なタイムスタンプを記録し、最小限の再現を作成し、リグレッションがアカウントよりも広いかどうかを確認する」ことが正しい修正である場合があります。

ポリシー範囲内での IMAGE_SAFETY とプロンプトブロックの迅速な修正方法

このセクションは、オンラインのアドバイスの多くが杜撰になりがちなところです。「Geminiの安全機能を回避する」ようにユーザーに伝えることは、悪いガイダンスであるだけでなく、虐待の保護または安全フィルターを回避する試みを明示的に禁じているGoogleのGenerative AI禁止利用ポリシーと矛盾しています。正しい質問は「フィルターをどのようにすり抜けるか？」ではありません。「Geminiが正しく分類できるように、合法的なリクエストをどのように明確に表現するか？」が正しい質問です。

コード化された文言ではなく、無害なコンテキストから始めてください。プロンプトが実際にeコマース、カタログ作業、医療教育、または歴史的なシーンのためであれば、それを直接述べてください。センシティブな用語を婉曲表現に置き換えてモデルに無害な意図を推測させようとしないでください。直接的かつ安全なコンテキストは、モデルが分類するためのシグナルが多くなるため、一般的にうまい回避言語よりも効果的です。

例えば、ファッションや製品の画像を編集している場合、「もっとセクシーにして」や「大人っぽい雰囲気」のようなあいまいなプロンプトを避けてください。無害なリクエストを性的に露骨な解釈に引き込む可能性があります。より安全で明確なバージョンは、「白いシームレスな背景に薄茶色のコットンのスポーツブラのスタジオeコマース写真を作成してください。カタログ照明、モデルなし、ポーズの強調なし、小売製品スタイル。」のようなものです。2番目のバージョンはまだ商業的に有用ですが、リクエストを IMAGE_SAFETY に押し込む可能性のある多くのあいまいな手がかりを取り除いています。

合法的な医療、安全、または歴史的なユースケースに取り組んでいる場合は、目標をグラフィックな描写から遠ざけて説明に近づけてください。血液、負傷の詳細、屈辱、またはエロティックなフレーミングを明示的に求めるリクエストは、より広いプロジェクトが合法的であっても無害として弁護することが非常に難しくなります。可能な場合は、フォトリアリスティックな危害ではなく、図、非グラフィックなイラスト、ラベル付きの教育的レイアウト、またはビフォー/アフタープロセスのビジュアルを求めてください。

ファッション以外での別の無害な書き換えパターンは、シーンレベルのあいまいさを対象者と形式に置き換えることです。暴力的な分類に落ちてしまう可能性のある「歴史上の抗議負傷シーン」を求めるのではなく、「1960年代の公民権運動の歴史についての博物館パネルのための非グラフィックな教育イラストを作成してください。ポスタースタイル、目に見える傷なし、群衆の看板と警察のバリアに焦点を当てる。」を試してください。この種の書き換えは承認を保証するものではありませんが、モデルにはあいまいなドラマチックシーンのリクエストよりも安全で明確な出力目標を与えます。

プロンプト側のブロックと出力側の IMAGE_SAFETY 停止には、わずかに異なるメンタルモデルが必要です。プロンプト自体がブロックされた場合、システムはリクエストが述べられている通りには進むべきではないと言っています。プロンプトは受け入れられたが最終画像がブロックされた場合、システムは入力テキストがゲートで拒否されなかったにもかかわらず、生成されたビジュアル出力が境界を越えたと言っています。両方のケースで実用的な対応はあいまいまたはセンシティブなビジュアルの手がかりを取り除くことですが、出力側のブロックは特に、リアリズムの低減、官能的なフレーミングの減少、身体強調の詳細の削除、またはエッジケースのビジュアルではなく非センシティブなオブジェクトを中心にシーンを再構成することで効果があります。

一般的に回避に踏み込まずに役立つ安全なプロンプト書き換えパターンを示します。

もう1つの重要な修正は、周囲の会話コンテキストから画像タスクを分離することです。長いチャットでは、モデルは最後の行以上のものを見ています。以前のターンで暴力、性的行為、トラウマ、犯罪、または安全上センシティブなトピックについて議論した場合、後の画像リクエストはそのコンテキストを引き継ぐことがあります。プロンプトが予期せず失敗し始めた場合は、正確な画像生成指示と最小限の必要なソース画像のみで新しいセッションを試してください。これはコンテキストの汚染とハードなポリシー境界を区別する最もクリーンな方法の1つです。

また、「以前は機能した」は「常に機能するべき」と同じではないことを覚えておいてください。2025年12月24日のコミュニティの証拠では、ユーザーが設定可能な性的コンテンツ設定が緩和されたと言った後でも、Vertex AI Studioで正規のeコマース下着のプロンプトが IMAGE_SAFETY で終わることがあることを示しています。これはGoogleのドキュメントが間違っているという意味ではありません。出力側のフィルタリングがユーザーが調整可能な設定でカバーできると期待するものを依然として上書きできることを意味します。本記事の正しいスタンスは「Googleは自分自身のコントロールを無視する」ではありません。正しいスタンスは「調整可能な設定は存在するが、組み込みおよび出力レベルの保護は依然として画像を返すべきでないと決定できる」です。

ユースケースが明らかに禁止されたカテゴリに属する場合は、そこで止めてください。Googleのポリシー境界はプロンプトエンジニアリングで回避するためにあるわけではありません。ユースケースが合法的であるにもかかわらずブロックされ続ける場合は、正確なモデル、リージョン、日付、ペイロードシグナル、およびサニタイズされたプロンプトを文書化し、その情報でエスカレーションしてください。精度は10回以上の書き直し試みよりも役立ちます。

Geminiの安全設定が変更できることとできないこと

このセクションは、多くのランキングページが話の半分だけを正確に伝え、そのため誤解を招きがちな部分です。はい、Geminiには設定可能な安全設定があります。しかし、すべての画像拒否が調整可能というわけではありません。

2026年1月15日に最終更新されたGoogleの現在の安全設定ドキュメントでは、調整可能なカテゴリが4つの領域をカバーしていると述べています。ハラスメント、ヘイトスピーチ、性的に露骨なコンテンツ、危険なコンテンツです。これは広く聞こえますが、同じページにはまったく調整できないコアとなる危害に対する組み込みの保護があるとも述べています。平たく言えば、一部のフィルターは調整できますが、安全システム全体をオフにすることはできません。

同じ公式ページにはまた、明示的にしきい値を設定しない場合、Gemini 2.5および3モデルのデフォルトのブロックしきい値は Off であるとも述べています。この詳細は重要です。多くの古いチュートリアルでは、基本的な画像生成を機能させるために最も許容度の高いしきい値を手動で設定するようにユーザーに指示しています。現在のドキュメントの状態では、その前提は時代遅れです。求める結果が得られない場合、原因は多くの場合「しきい値を緩めるのを忘れた」ではありません。あいまいなプロンプト、出力側のフィルタリング、または調整不可能な保護である可能性が高いです。

以下のコントロールサーフェスの表を現実確認として使用してください。

GoogleのVertex AI安全ドキュメントには別の重要なニュアンスが追加されています。プロンプト拒否コードには PROHIBITED_CONTENT が含まれる可能性があり、ブロックされたレスポンスはブロックされたコンテンツ自体が保留されたまま安全関連の終了理由で終わることができます。つまり、強制にはレイヤーがあります。リクエストは設定可能なカテゴリ、設定不可能なカテゴリ、または最終的に生成された出力自体のために失敗することがあります。1つのノブだけを見ている場合、システムの一部しか見ていません。

2026年における BLOCK_NONE またはその他の許容度の高いしきい値についての正しい見方はこうです。特定のカテゴリに対する追加の設定可能なブロックを減らすことができますが、すべての画像安全動作のマスターオーバーライドではありません。合法的なリクエストが依然として IMAGE_SAFETY を返している場合、それは自動的に壊れた設定の証拠ではありません。出力レベルの分類器または組み込みの保護が依然として画像をリリースしないと決定したという意味かもしれません。

Geminiの上でプロダクトフローを構築しているチームにとって、エンジニアリングの意味は明確です。安全設定をシステムへの1つの入力として扱い、システム全体としては扱わないでください。「生成に失敗しました」だけでなく「このリクエストは出力側の画像安全ブロックに当たりました」と説明できるロギングとUXを構築してください。プロダクトが障害をより正確に名付けるほど、ユーザーはアプリが不安定または不誠実だと思い込む可能性が低くなります。

API、AI Studio、Vertex AI、アプリの障害は同一ではない

多くの悪い記事は、まるで1つのユニバーサルなプロダクトサーフェスがあるかのように「Gemini」について話しています。そうではありません。同じ基盤となるモデルファミリーが、生のGemini API、Vertex AI、AI Studio、またはコンシューマーGeminiアプリのどれを使用しているかによって、まったく異なる感じを受けることがあります。

生のAPIとVertex AIは、ペイロードの構造を調べることができるため、デバッグに最適な場所です。promptFeedback、candidates、content の欠落、finishReason を確認できます。だからこそ、技術的な診断は可能な場合はそこから始めるべきです。UIレイヤーのみを使用している場合、証拠ではなく症状からデバッグしています。

AI Studioは中間に位置しています。プラットフォームに十分近く有用ですが、それでも独自のUX選択、リリースサイクル、時折のリグレッションを持つプロダクトサーフェスです。だからこそ、「Geminiがサイレントに失敗した」と報告する2人のうち、1人だけが実際にポリシーブロックに当たっていることがあります。もう1人はリクエスト形式のバグ、プロダクトのリグレッション、またはAPIならより明確になるサーフェス固有の動作に当たっているかもしれません。

コンシューマーGeminiアプリはペイロードからさらに遠ざかっています。アプリの可用性、プランの権限、機能のロールアウト状態、およびUIレベルの制限はすべて、画像作成が機能するように見えるかどうかに影響を与える可能性があります。深刻なワークフローをデバッグしている場合は、アプリの症状だけに頼らないでください。問題がポリシー、機能、またはプロダクトサーフェスの動作かどうかを確認できるよう、可能な場合はAPIまたはAI Studioを通じて再現してください。

リージョンとモデルの可用性も状況を複雑にします。2025年4月20日のコミュニティスレッドでは、us サーバーの場所に切り替えることで gemini-2.0-flash-exp-image-generation のnot-foundエラーが解決されたと報告されています。これはコンテンツポリシーの問題ではありませんが、ユーザーはしばしば「Gemini画像が機能しない」として経験します。教訓は特定の実験的モデルを超えて広がります。リージョン、ルーティング、デプロイ状態がユーザーの認識においてポリシー障害を模倣することがあります。

クォータと過負荷についても同様です。429または503に当たったユーザーでも「何も生成されなかった」と表現することがあります。ログにクォータの枯渇またはサービスの利用不能が表示されている場合は、コンテンツポリシーについて考えるのを止めてください。クォータと容量から始めてください。これらについては、Gemini APIレート制限ガイドと先に紹介したGemini画像エラーコード記事で別途説明しています。

サポートチームにとってのベストプラクティスは、プロンプト修正を提案する前に3つの質問をすることです。

1. どのサーフェスを使用していますか？API、Vertex AI、AI Studio、またはアプリ？
2. 生のペイロードがありますか、それともUIメッセージだけですか？
3. 新しいセッションで最小限の無害なプロンプトで障害は再現可能ですか？

これらの3つの質問で、「コンテンツポリシー」の誤チケットの半分を本物の安全上の偽陽性から分離できます。

再利用できるトラブルシューティングワークフロー

Gemini画像生成が実際のワークフローにとって重要になったら、直感の代わりに繰り返し使えるプロセスが必要です。最速のチームは最高のプロンプトハックを持っているチームではありません。障害を一貫して分類し、プロンプトの問題をプラットフォームの問題から区別するのに十分な証拠を収集しているチームです。

アプリケーションログに小さな分類器から始めてください。これは洗練された理論ではありません。運用上の衛生習慣です。

python
def classify_gemini_image_result(resp):
    if getattr(resp, "prompt_feedback", None):
        return {
            "kind": "prompt_blocked",
            "block_reason": getattr(resp.prompt_feedback, "block_reason", "UNKNOWN"),
        }

    candidates = getattr(resp, "candidates", None) or []
    if not candidates:
        return {"kind": "no_candidates"}

    candidate = candidates[0]
    finish_reason = getattr(candidate, "finish_reason", "UNKNOWN")
    content = getattr(candidate, "content", None)
    parts = getattr(content, "parts", None) if content else None

    has_inline_image = False
    has_text = False
    if parts:
        for part in parts:
            if getattr(part, "inline_data", None):
                has_inline_image = True
            if getattr(part, "text", None):
                has_text = True

    return {
        "kind": "candidate_returned",
        "finish_reason": finish_reason,
        "has_inline_image": has_inline_image,
        "has_text": has_text,
        "content_missing": content is None,
    }

このコードは洗練されている必要はありません。毎回6つの質問に答えるだけでよいのです。

1. promptFeedback は存在していましたか？
2. candidates は返されましたか？
3. 最終的な finishReason は何でしたか？
4. content は欠落していましたか？
5. 画像の inlineData は返ってきましたか？
6. モデルは画像の代わりにテキストを返しましたか？

その分類ができれば、残りのワークフローははるかに信頼性が高くなります。

本番環境で推奨するワークフローは以下の通りです。

1. ユーザー向けのエラー文字列だけでなく、生のレスポンスペイロードをキャプチャする。
2. 上記の構造的フィールドを使用して障害を分類する。
3. 新しいセッションで最小限の無害なプロンプトで再現する。
4. 最小限の無害なプロンプトが機能する場合、問題はプロンプトの文言またはチャットのコンテキストにある可能性が高い。
5. 最小限の無害なプロンプトが同じように失敗する場合は、リクエスト形式、リージョン、モデルID、現在のプラットフォームの状態を確認する。
6. 同じペイロードで動作が突然変わった場合は、エスカレーション用に正確なUTC時刻とサーフェスを記録する。
7. 分類した後にのみ、書き直す、リトライする、待つ、またはルートを切り替えるかどうかを決定する。

根本原因分析で実際に役立つ変数もログに記録してください。

• モデルID
• 使用したサーフェス
• リージョンまたはエンドポイント
• 参照画像の数
• 入力が inlineData かファイルか
• 画像出力モダリティが要求されたか
• プロンプトハッシュ
• UTCタイムスタンプ
• SDKバージョンまたはクライアントバージョン

そのデータは、リグレッションが現れるたびに助けになります。サポートが「再現できますか？」と尋ねるとき、既に答えがわかります。フォーラムスレッドがロールアウトのバグを示唆するとき、障害が日付とサーフェスによって整列しているかどうかがわかります。障害が単純なリクエスト形式の問題であることが判明したとき、1週間それを安全の問題と呼んで時間を無駄にすることはありません。

待つべきか、エスカレーションすべきか、フォールバックルートを使うべきか

すべての障害が同じ対応に値するわけではありません。プロンプトの書き直しに値するものもあります。1回のリトライに値するものもあります。エスカレーションに値するものもあります。そして、Googleの画像動作が変化した場合でもプロダクトが機能し続けるためのアーキテクチャ上のフォールバックに値するものもあります。

待ってリトライするのは、証拠が確固としたブロックではなく不完全な生成を指している場合です。Googleの画像制限ページは、生成が完了する前に停止する可能性があると明示しています。これは限定されたリトライ戦略のゴーサインです。正しいバージョンは制御されたものです。すぐに1回リトライし、次に少し明確なプロンプトで1回リトライします。同じ分類された障害が繰り返される場合は、一時的なものとして扱うのを止めてください。

書き直すのは、ペイロードがプロンプトブロックまたは出力側の IMAGE_SAFETY 結果を、まだ合法的で無害として分類できる可能性のあるユースケースで示している場合です。追加のコンテキスト、あいまいでないビジュアルフレーミング、センシティブな手がかりの削減がここで役立ちます。ユースケースが禁止ラインに近い場合、書き直しは役立たない可能性があり、回避ゲームとして扱うべきではありません。

エスカレーションするのは、以前に機能していた無害なワークフローが突然壊れた場合です。特に：

• 同じ最小限のプロンプトが以前は機能していた
• 障害が狭い時間帯に始まった
• 複数のユーザーやフォーラムスレッドが同様の動作を報告している
• 問題が新しいセッションをまたいで再現される

エスカレーションの際は、最小限だが完全な再現を送ってください。

• モデル名
• サーフェス
• リージョン
• 正確なタイムスタンプ
• サニタイズされたプロンプト
• promptFeedback が存在したか
• finishReason
• content が欠落していたか

それがレポートを使用可能にします。「Geminiがまたサイレントに失敗した」ではなく。

フォールバックルートを使うのは、ビジネスがプラットフォームの曖昧さに耐えられない場合です。一部のチームにとって、それは特定のクラスの画像ジョブを別のGemini画像モデルにルーティングすることを意味します。他のチームにとっては、第2のプロバイダーやリレーパスを維持することを意味します。重要なのは別のルートが魔法のように安全性が低いということではありません。サイレント障害がカスタマーエクスペリエンスに直接影響する場合、本番システムはすべての画像作業に対して1つの狭い依存関係だけを持つべきではないということです。

実際の問題が本番の継続性であってコンシューマーアプリの使用ではない場合、リレーレイヤーは合理的な選択肢になり得ます。laozhang.ai は、1つの公式エンドポイントではなく統合APIルーティングを望むチームのためのOpenAI互換のリレーオプションです。これは禁止されたリクエストの修正ではなく、そのように説明すべきでもありません。信頼性、統合の一貫性、またはマルチモデルルーティングのための運用上の選択です。それが懸念事項であれば、ポリシーとルーティングを同じ問題として扱うのではなく、まずチャネルのトレードオフを比較してください。

より広い教訓は、「Gemini画像サイレント障害」は単一のバグクラスではないということです。「プロンプトがラインを越えた」が正しい答えである場合があります。「ペイロードの形式が間違っている」が正しい答えである場合があります。「Googleはプロンプトを受け入れたが最終画像をフィルタリングした」が正しい答えである場合があります。「モデルがまったく画像を生成しなかった」が正しい答えである場合もあります。正しいクラスを早く名付けるほど、早く間違った修正に時間を無駄にするのを止めることができます。

もう1つ本番での習慣として採用する価値があるのは、カスタマーに達したすべての画像安全インシデントのためにサニタイズされた再現パックを保持することです。パックにはモデル名、UTCタイムスタンプ、リージョン、リクエストサーフェス、リクエストがテキストのみか画像編集か、参照画像の数、それらの参照がアップロードされたファイルかインライン画像データとして送られたか、最終的なブロックまたは終了理由、プロンプトハッシュとサニタイズされた人間が読めるプロンプトが含まれるべきです。それは面倒に聞こえますが、あいまいな苦情をアクション可能なエンジニアリングアーティファクトに変えます。また、週をまたいでインシデントを比較し、変化が1つのサーフェス、1つのモデルファミリー、1つのプロンプトテンプレート、または1つの新しいプロダクトリリースに結びついているかどうかを確認できます。

同じ再現パックは、公式ルートに留まるか追加のフォールバック容量を追加するかを決定する必要がある場合にも役立ちます。障害の95%が明らかにプロンプト側のブロックである場合、より多くのルーティングレイヤーは根本的な問題を解決しません。障害が不完全な生成、テキストのみの返答、または別のルートで消えるような突然のサーフェスリグレッションの周りに集中している場合、運用上の冗長性が意味をなし始めます。この区別は、実際にはプロンプトデザインの問題を解決するためにインフラを購入することからチームを守り、実際には可用性の問題のためにプロンプトを責めることからも守ります。

FAQ

最も役立つメンタルモデルはシンプルです。最初に分類し、次に修正する。2026年1月12日から3月14日の間に確認されたGoogleの現在のドキュメントは既に、Gemini画像障害がプロンプト側のブロック、出力側のブロック、画像なしの結果、非ポリシー生成の問題に分かれることを教えています。そのレンズを通じてペイロードを読めば、IMAGE_SAFETY、NO_IMAGE、テキストのみの返答は1つの神秘的なコンテンツポリシーの塊のように見えなくなります。

もう1つの重要な洞察は、設定可能な安全設定は全体像の一部にすぎないということです。Googleの公式安全設定ページでは、調整可能なしきい値が4つの主要カテゴリに存在するが、コアとなる危害に対する組み込みの保護は有効であり、ユーザーによる調整はできないと述べています。だからこそ、緩和された設定が安全に見えるエッジケースが通過することを保証せず、一部の正当なワークフローは依然として動作が変化するときに慎重なプロンプトフレーミングやエスカレーションを必要とします。

この記事から1つだけ覚えるとすれば、これを覚えてください。promptFeedback はプロンプトがブロックされたことを示し、finishReason = IMAGE_SAFETY は出力画像がブロックされたことを示し、finishReason = NO_IMAGE はGeminiが実際には画像を生成しなかったことを示します。これらは3つの異なる運用ブランチであり、それらを1つとして扱うことが、Gemini画像トラブルシューティングセッションの多くが堂々巡りになる理由です。

Geminiがなぜ画像の代わりにテキストを返すのですか？

最も一般的な理由は、あいまいなプロンプト、画像出力設定の欠落、またはテキスト回答を招く混合タスクです。Googleの現在の画像制限ページには、プロンプトがあいまいな場合Geminiはテキストを作成し画像を作成しない可能性があると明示されています。

なぜ BLOCK_NONE または緩和された安全設定が IMAGE_SAFETY を修正しないのですか？

Googleの公式安全設定ドキュメントでは、コアとなる危害に対する組み込みの保護は調整できないと述べているからです。設定可能なしきい値を緩めても、すべての出力側の画像フィルタリングが無効になるわけではありません。

IMAGE_SAFETY と NO_IMAGE の違いは何ですか？

IMAGE_SAFETY は、リクエストが候補レコードを生成するほど進んだ後に出力画像がブロックされたことを意味します。NO_IMAGE は画像が生成されなかったことを意味します。NO_IMAGE の正しい修正は多くの場合、ポリシーの再解釈ではなく明確さまたはリトライです。

先週は機能していたプロンプトが突然機能しなくなったのはなぜですか？

考えられる原因には、プラットフォームのリグレッション、モデルの動作の変化、サーフェスのデフォルトの変更、蓄積されたチャットコンテキスト、または新しいリクエスト形式の問題が含まれます。2025年後半のフォーラムスレッドでは、無害な画像ワークフローがアップデートをまたいで動作が変わることがあることを示しているため、プロンプト自体に問題があると思い込む前に、正確な日付、サーフェス、ペイロードの詳細を記録してください。

同じ失敗したリクエストをリトライし続けることは安全ですか？

不完全またはあいまいな画像なしの結果については、1〜2回の制御されたリトライは合理的です。プロンプトブロックまたは明確な IMAGE_SAFETY 停止については、同一のリトライを繰り返しても通常は価値がありません。代わりに再分類、書き直し、またはエスカレーションしてください。

使用された公式ソース： Vertex AIでのブロックされたレスポンスの処理、Gemini APIリファレンス、Gemini安全設定、Gemini画像生成の制限、Gemini画像生成と責任あるAI、GoogleのGenerative AI禁止利用ポリシー。