# Geminiで画像が出ない・IMAGE_SAFETYになる原因と直し方

> Geminiが画像を返さない、テキストしか返さない、または IMAGE_SAFETY / NO_IMAGE を返すときに向けて、プロンプトブロック、出力フィルター、無画像結果、非ポリシー障害の見分け方と直し方を解説します。

- Source: https://www.aifreeapi.com/ja/posts/gemini-image-silent-failure-image-safety-fix
- Language: ja
- Published: 2026-03-15
- Updated: 2026-03-15
- Publisher: AI Free API (https://www.aifreeapi.com)

Geminiの画像生成が無反応に見えるとき、最初に押さえるべきなのは、いわゆる「サイレント失敗」が単一の不具合ではないという点です。2026年3月15日時点でGoogleの公式ドキュメントは、ユーザーがひとまとめにしがちな少なくとも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画像障害を正確に診断することを目的としています。

![GeminiのIMAGE_SAFETY静的障害修正ガイド](https://www.aifreeapi.com/posts/ja/gemini-image-silent-failure-image-safety-fix/img/cover.png)

## 要点まとめ

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

| クイック診断 | 最初に確認すること | 意味 |
|---|---|---|
| プロンプトブロック | `promptFeedback.blockReason` | 使用可能な画像候補が返される前にリクエストがフィルタリングされた |
| 出力ブロック | `candidates[0].finishReason = IMAGE_SAFETY` かつ `content` が欠落 | プロンプトは進んだが最終画像が保留された |
| 画像が生成されない | `finishReason = NO_IMAGE` | Geminiはリクエストを受け入れたが画像出力を生成しなかった |
| テキストのみの返答 | テキストパーツのみで画像パーツなし | 通常はあいまいさ、出力設定、またはリクエスト形式の問題 |

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

![promptFeedback、IMAGE_SAFETY、NO_IMAGE、テキストのみの返答がGemini画像障害の異なるタイプにどのようにマッピングされるかを示すフロー図](https://www.aifreeapi.com/posts/ja/gemini-image-silent-failure-image-safety-fix/img/diagnostic-map.png)

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

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

| 見えているもの | 典型的なAPIシグナル | 通常の意味 | 最初の修正 |
|---|---|---|---|
| 使用可能な候補が出る前にリクエストが失敗する | `promptFeedback.blockReason` が存在し `candidates` がない | 画像出力が返される前のプロンプト側ブロック | プロンプトを書き直す。適切であれば安全なコンテキストを追加する。または禁止された境界に触れているリクエストを受け入れる |
| 画像の代わりにテキスト拒否 | `candidates[0].finishReason = STOP` でレスポンスに画像データではなくテキストが含まれる | モデルがリクエストを拒否または安全にリダイレクトした | テキストを読み、センシティブなビジュアル意図を除去するか、タスクをより安全なステップに分割する |
| 画像データなしと `IMAGE_SAFETY` | `candidates` が存在し、`content` がなく、`finishReason = IMAGE_SAFETY` | プロンプトは受け入れられたが、出力画像がフィルタリングされた | センシティブなビジュアルの詳細を減らし、無害な意図を明確にする。安全設定がすべてを上書きできると思わない |
| 画像データなしと `NO_IMAGE` | `finishReason = NO_IMAGE` | Geminiが実際には画像を生成しなかった | 明示的に画像を要求し、あいまいさを減らし、1〜2回リトライして、リクエスト形式を確認する |
| 明らかなポリシーマーカーのないテキストのみの返答 | レスポンスにテキストがあるが `inlineData` 画像パーツがない | 多くはあいまいなプロンプト、画像出力設定の欠落、またはトランスポートのバグ | 明示的に画像出力を要求し、リクエスト設定を確認する |
| 404、429、または503 | 画像候補の代わりにHTTPエラー | モデルのルーティング、クォータ、または過負荷の問題。コンテンツポリシーではない | プロンプトの書き直しではなく、適切な運用ガイドを使用する |

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リファレンス](https://ai.google.dev/api/generate-content)は、このトピックにとって特に重要です。プロンプトブロックに属する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ページ](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/multimodal/gemini-image-responsible-ai)では、潜在的に安全でない画像リクエストが `FinishReason = STOP` を伴うテキスト拒否を生成することがあると説明されています。つまり、システムは「フィルターエラー」と言っているのではなく、通常のモデルテキストで「その画像は作成しません」と言っているのかもしれません。だからこそ、テキストのみの返答は無視せずに読む必要があります。

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

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

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

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

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

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

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

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

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

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

**修正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で失敗している場合、コンテンツポリシーの変化を見ているのではありません。ルーティング、クォータ、または容量の問題です。

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

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

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

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

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

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

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

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

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

| リスクのあるパターン | 問題を引き起こす理由 | より安全な書き換えパターン |
|---|---|---|
| あいまいな大人または官能的なフレーミング | モデルがリクエストがエロティックか商業的かを推測しなければならない | カタログ、スタジオ、エディトリアル、マネキンなし、ポーズ強調なし、または製品のみのフレーミングを指定する |
| グラフィックな暴力の詳細 | 合法的なプロジェクトでも有害なビジュアル生成として読まれることがある | 非グラフィックな図、余波のないイラスト、または教育的なレイアウトを求める |
| 混合分析と生成 | Geminiがきれいな画像フローの代わりにテキストまたは拒否を返すことがある | 計画を1ターンに、画像生成を2ターン目に分ける |
| 感情的に負荷のかかった名詞を含む最小限のプロンプト | 短いプロンプトは安全システムに無害なコンテキストをほとんど与えない | 主題、設定、照明、目的、対象者、スタイルを平易な言葉で追加する |

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

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

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

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

![Geminiの安全コントロールの調整可能なものと固定された組み込みの保護を比較する図](https://www.aifreeapi.com/posts/ja/gemini-image-silent-failure-image-safety-fix/img/safety-controls.png)

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

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

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

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

| コントロールサーフェス | 変更できること | 変更できないこと | よくある間違い |
|---|---|---|---|
| Gemini API安全設定 | ハラスメント、ヘイトスピーチ、性的に露骨なコンテンツ、危険なコンテンツのしきい値 | コアとなる危害に対する組み込みの保護 | `BLOCK_NONE` がすべてを無効にすると思い込む |
| Vertex AI安全フィルター | サーフェスによっては危害のしきい値と一部のフィルター処理動作 | 設定不可能な禁止コンテンツカテゴリ | ブロックされたすべての画像をしきい値のバグとして扱う |
| AI StudioなどのツールのプロダクトUI設定 | サーフェス固有の利便性トグルやデフォルト | 基盤となるプラットフォームレベルのポリシー境界 | UIラベルが生のAPIの動作に1:1でマッピングされると思い込む |
| プロンプトの書き直し | コンテキスト、具体性、無害なフレーミング、ビジュアルの強調 | ポリシーで禁止されたリクエスト | 明確さと回避を混同する |

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レート制限ガイド](/ja/posts/gemini-api-rate-limit-explained)と先に紹介したGemini画像エラーコード記事で別途説明しています。

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

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

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

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

![ペイロード検査からエスカレーションまたはフォールバックルーティングまでのGemini画像障害の5ステップトラブルシューティングワークフロー](https://www.aifreeapi.com/posts/ja/gemini-image-silent-failure-image-safety-fix/img/troubleshooting-workflow.png)

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. モデルは画像の代わりにテキストを返しましたか？

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

| 見えているもの | 次にやること | やってはいけないこと |
|---|---|---|
| ブロック理由を持つ `promptFeedback` | プロンプトのセマンティクスとポリシーの適合性を確認する | 全く同じプロンプトを盲目的にリトライし続ける |
| `finishReason = IMAGE_SAFETY` | センシティブなビジュアルの詳細を減らし、ユースケースが明確に無害であることを確認する | 安全しきい値がすべてを上書きすると思い込む |
| `finishReason = NO_IMAGE` | 画像の意図を明示し、プロンプトを簡略化し、1回リトライして、リクエスト形式を確認する | コンテンツポリシーの保証されたブロックとして扱う |
| テキストのみの返答 | 返答を読み、画像出力設定を確認し、混合タスクを分離する | モデルがプロンプトを意図的に無視したと結論付ける |
| 404、429、または503 | ルーティング、クォータ、または容量のトラブルシューティングに移る | コンテンツポリシーの用語を書き直すために1時間費やす |

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

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でのブロックされたレスポンスの処理](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/multimodal/process-blocked-responses)、[Gemini APIリファレンス](https://ai.google.dev/api/generate-content)、[Gemini安全設定](https://ai.google.dev/gemini-api/docs/safety-settings)、[Gemini画像生成の制限](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/multimodal/gemini-image-generation-limitations)、[Gemini画像生成と責任あるAI](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/multimodal/gemini-image-responsible-ai)、Googleの[Generative AI禁止利用ポリシー](https://policies.google.com/terms/generative-ai/use-policy)。