Nano Banana 2 における image safety は一つのスイッチではありません。Gemini API では、調整可能な prompt-side safety system が一つあります。別に、OTHER、PROHIBITED_CONTENT、IMAGE_SAFETY のような可視の理由を返す、より硬い response layer があります。さらに Gemini Apps の上には product-level の policy removal もあります。多くのデバッグが外れるのは、モデルが完全に不可解だからではなく、この三つの判断を一つのフィルターとして扱ってしまうからです。
最初に覚えるべきことは一つです。BLOCK_NONE は狭い control であって、master switch ではありません。Gemini API の四つの prompt-side categories にだけ関わります。Google の built-in core protections を消すわけでもありませんし、Gemini Apps では通るように見えたタスクが API では別の硬い block に入る理由を説明してくれるわけでもありません。
最短ルートは、どの契約が発火したかを先に見ることです。
safetySettingsを変えた時に結果も動くなら、まだ調整可能な層にいる可能性が高いです。- API が
SAFETY、OTHER、PROHIBITED_CONTENT、IMAGE_SAFETYのような visible reason を返しているなら、それを曖昧なエラーではなく route signal として扱ってください。 - 同じタスクが Gemini Apps と Gemini API で違って見えるなら、app shell を独立した surface として扱い、API の完全な鏡だとは思わないことです。
根拠メモ: この記事は 2026 年 4 月 3 日時点で確認した Gemini API の公式ドキュメント、Gemini Apps の help page、Gemini 3.1 Flash Image の model card、そして current developer complaint threads に基づいています。この環境では Google の直接 capture が blocked されたため、search observation は fallback evidence で補いました。
Nano Banana 2 で image safety が実際に意味するもの
Nano Banana 2 は Gemini API では gemini-3.1-flash-image-preview です。Google はこれを、より高速で throughput の高い image model として位置付けています。ここが重要なのは、多くのページが古い Nano Banana や Nano Banana Pro の safety language をそのまま流用し、新しい model を「同じ挙動のまま少し厳しくなったもの」として扱っているからです。その近道は安全ではありません。
より正確な mental model は、Nano Banana 2 の image safety が少なくとも三つの別々の契約を指している、というものです。
一つ目の契約は、Gemini API の調整可能な prompt-side safety system です。Google が現在公開している adjustable categories は harassment、hate speech、sexually explicit content、dangerous content の四つだけです。開発者が safetySettings という時、普通はこの層を指しています。
二つ目の契約は、API 自体のより硬い block と response layer です。公開 schema には SAFETY、OTHER、PROHIBITED_CONTENT、IMAGE_SAFETY のような理由が出てきます。これは同じ拒否を言い換えているだけではありません。settings を見るべきか、prompt を書き換えるべきか、タスク自体を変えるべきか、あるいはその surface に属さないと受け入れるべきかを分ける route signal です。
三つ目の契約は Gemini Apps という product shell です。Google の current help documentation は、画像生成、アップロード画像の編集、複数画像の組み合わせ、そして人物を含む personalized-image scenarios を示しています。一方で、policy reason によって画像が削除される可能性も明記しています。だから Gemini Apps は「見た目の良い API」ではありません。別の user-facing contract を持つ別の surface です。
この三つを分けるだけで、Nano Banana 2 の安全まわりはかなり読みやすくなります。なぜこの filter は random に見えるのかと嘆く代わりに、どの layer が今の決定をしたのかを先に問えるからです。
safety settings が変えられるものと、変えられないもの
Nano Banana 2 で最も多い誤解の一つは、BLOCK_NONE を model のオフスイッチのように扱うことです。現在の Gemini API safety docs はその読み方を支持していません。
ドキュメントが支持しているのは、もっと狭く、しかしもっと役に立つ読み方です。Gemini API で adjustable safety settings がカバーするのは次の四カテゴリだけです。
HARASSMENTHATE_SPEECHSEXUALLY_EXPLICITDANGEROUS_CONTENT
つまり、リクエストが本当にその configurable thresholds の中にあるなら、BLOCK_NONE は意味があります。しかし万能ではありません。
Google は、core harms は adjustable settings の外側でも引き続き block されると書いています。だから configurable thresholds を下げたり外したりしても結果が全く動かないなら、それは「Google が秘密の extra filter を隠している」というより、最初から adjustable layer の話ではなかった可能性が高い、という方が defensible です。
この点が、Nano Banana 2 の troubleshooting threads が堂々巡りしやすい理由でもあります。ある人は「全部 BLOCK_NONE にした」と言い、別の人は「なら hidden filter があるはずだ」と返します。より筋が通る結論は、リクエストが configurable layer を超えて、BLOCK_NONE がそもそも触れない別の契約に入った、というものです。
実務的な結論は単純です。観測された failure が adjustable prompt-side layer と一致する時だけ safetySettings を使うこと。response surface が別の signal を返しているなら、それを信じて route を変えるべきです。
SAFETY、OTHER、PROHIBITED_CONTENT、IMAGE_SAFETY をどう読むか
visible reason を vague rejection ではなく「次の行動の指示」として読むようになると、Nano Banana 2 はかなり扱いやすくなります。
現在の Gemini API docs では、Google は SAFETY、OTHER、PROHIBITED_CONTENT、IMAGE_SAFETY のような block reasons を公にしています。image-generation integrations では、それらまたは近い response-layer reasons が body に現れることがあります。より安全な運用は、その visible reason を routing instruction として使うことです。
| Visible reason | それが通常示すこと | 次にやること |
|---|---|---|
SAFETY | configurable safety system に入った。 | safetyRatings を見て、現在の safetySettings と照らし合わせ、本当に四つの adjustable categories の問題かを確認する。 |
OTHER | より広い policy boundary、または unsupported content に触れている可能性がある。Google の troubleshooting docs でも BlockedReason.OTHER は ToS や unsupported content を意味しうると明記されている。 | narrow threshold problem と見なさない。タスクを組み直す、簡略化する、その surface では扱えないと受け入れる。 |
PROHIBITED_CONTENT | mild false-positive zone ではなく、より硬い policy zone に入っている。 | 同じアイデアを細かく言い換えて押し込まない。タスク自体を変えるか、やめる。 |
IMAGE_SAFETY | image-generation safety layer が output を止めた。 | prompt を書き換える、framing を変える、style を変える、またはより狭い troubleshooting path に移る。settings toggle で直ると決めつけない。 |
大事なのは最後の列です。これらの label が有用なのは、別々の action へ route してくれるからです。
SAFETY なら docs は settings path を与えています。OTHER なら、問題が adjustable categories の外側にある可能性を Google 自身が示しています。PROHIBITED_CONTENT なら、微修正を重ねるより task 自体を変える方が自然です。IMAGE_SAFETY なら、それは image-layer block であって、API settings misconfiguration の証拠ではありません。
ただし境界はあります。Google は IMAGE_SAFETY や OTHER の詳細な trigger taxonomy を公表していません。だからこれらの label を hidden rulebook のように扱ってはいけません。あくまで route marker です。
benign prompt でも失敗する理由
Nano Banana 2 の safety が opaque に感じられる理由の一つは、合法で普通の use case でも friction が起こりうることです。Google の developer forum では、fashion や lifestyle のような non-NSFW prompts でも false positives を訴える current complaint threads が続いています。Gemini 3.1 Flash Image の model card でも、Google は false positives と false negatives の両方を減らし続けていると書いています。つまりバランスはまだ調整中です。
この evidence をどう読むべきか。正しい答えは「model は壊れている」でもなければ「全部 user error」でもありません。より強い読み方は、public contract がまだ incomplete だ、というものです。
例えば benign な reference-image edit でも失敗しうるし、服装の記述が想定より厳しく読まれることもあります。ある realistic portrait edit が一つの surface では通って見えるのに、別の surface では止まることもあります。これは hidden official blacklist の証明ではありません。単に、実運用の friction が neat な public taxonomy より複雑だということです。
この違いは重要です。forum rumors を official policy のように扱い始めると、debug quality はすぐ落ちます。folklore に過剰適応し、evidence から離れ、実際には route を変えるべきところで細かい prompt surgery を繰り返すからです。
より良い workflow は、失敗を正確に記録し、曖昧さを減らし、毎回一つの大きな change だけを入れることです。identity- or body-centric language から、task- or scene-centric language に寄せる。人物を含むなら、必要なのが photorealistic generation なのか、editorial-style illustration なのか、より安全な reference transform なのかを先に決める。それでも繰り返し失敗するなら、「まだ magic wording が足りない」のではなく、「この surface では今は supported ではない」の方が正しいこともあります。
Gemini Apps と Gemini API
安全まわりの悪い advice の多くは、Gemini Apps と Gemini API を一つの挙動に潰してしまうところから始まります。
公式の Gemini Apps help docs は、その単純化を支持していません。Google は現在、Nano Banana 2 を Gemini Apps 上で image generation、uploaded-image editing、image combination、さらに人物を含む personalized-image scenarios に使えると説明しています。これだけで「Nano Banana 2 は人の画像を完全に許さない」という blanket claim は崩れます。
同時に、その same help surface は、possible policy issue が検出された時に画像が削除されることも警告しています。ここが重要な caveat です。ある capability が product-level で supported されていることと、あらゆる request が通ることは同じではありません。また、app-level removal は documented API response reason と同一ではありません。
だから cross-surface anecdotes は誤解を生みやすいのです。ある人が「Gemini では動いた」と言い、別の人が「同じ concept は API で止まった」と言っても、両方とも true でありえます。shell、moderation path、user-facing messaging、enforcement timing が一致していないからです。
実務上の結論ははっきりしています。consumer-style editing や personalized image manipulation が主目的なら、Gemini Apps の方が current support range を知る reference surface として役立ちます。production API integration が主目的なら、判断の起点は documented API contracts であるべきで、app screenshots や forum anecdotes ではありません。関連はありますが、置き換えはできません。
retry を続けるより route を変えるべき時
Nano Banana 2 image safety で最も役に立つ習慣の一つは、もう一回 retry しても意味がない瞬間を見分けることです。
200 OK なのに usable image がなく、response path に IMAGE_SAFETY が見えているなら、より狭い guide Nano Banana 2 が 200 OK を返すのに画像がない時 に移ってください。これは非常に specific な operational failure mode で、独自の debug logic を持っています。
failure mix の中に quota exhaustion、malformed requests、broader reliability problems が含まれていて、安全 block だけの話ではないなら、総合的な Nano Banana 2 が動かない時のガイド に route する方が自然です。429、bad parameter、temporary service problem は safety analysis では直りません。
本当の疑問が「Nano Banana 2 は人物、portrait、personalized edits をどこまで安定して扱えるのか」なら、より狭い Gemini image generation の人物制限 の方が適切です。あちらは human-image branch に焦点を当てています。
そして、やりたいことが「Google の safety contracts を読むこと」よりも「一つの stable な app/API layer の上で image generation を届けること」に近いなら、Nano Banana AI image generator のような broader tooling surface を検討する方が relevant です。Google model 内部の policy decisions は消えませんが、provider switching や fallback routing の operational mess は減らせます。
大きなポイントは、正しい次の一手は retry ではなく routing であることが多い、ということです。Nano Banana 2 image safety を「先に contract を見分け、それから action を選ぶ問題」として扱うと、無駄な再試行はかなり減ります。
FAQ
BLOCK_NONE は Nano Banana 2 の safety filters を全部無効にしますか。
いいえ。現在の Gemini API docs が支持しているのはもっと狭い読み方です。BLOCK_NONE は四つの prompt-side categories の threshold を変えるだけで、Google の built-in core protections を外すものではありません。app-level policy behavior まで同じ rule set にまとめることもできません。
image safety は Nano Banana 2 が人物画像を全く扱えないという意味ですか。
いいえ。Gemini Apps の current help page には、人物を含む personalized-image や image-editing scenarios が明記されています。より正確なのは、人を含む request はより sensitive な zone にあり、Gemini Apps と Gemini API で挙動が一致しないことがある、という言い方です。
IMAGE_SAFETY block は毎回課金されますか。
安全な読み方は、processed image-generation blocks は official surface が明示的に否定しない限り、potentially billable と考えることです。Google は Nano Banana 2 の current token-based pricing を公開していますが、今回の research pass では、あらゆる IMAGE_SAFETY case を一文でカバーする clean な公式文は見つかりませんでした。そのため、この記事は docs が支持しない universal billing claim は避けています。
Nano Banana 2 image safety を一番簡単にデバッグする方法は何ですか。
先に contract を特定することです。Gemini API の adjustable safety settings の問題なのか、より硬い API response reason なのか、Gemini Apps の product-level policy behavior なのか。layer の名前を言えないままでは、その後の troubleshooting はほぼ推測になります。
Nano Banana 2 に一つだけの image-safety filter があるわけではありません。市場が一つの曖昧な言い方でまとめたがる複数の enforcement contracts があるだけです。それを分けて考えれば、無駄な retry はかなり減ります。