Nano Banana Pro で RESTRICTED by System Instructions が出たら、最初にやるべきことは prompt の全面修正ではありません。多くの場合、この表示は Google が Pro をひそかに一括で弱くした という意味ではなく、今の surface が違う、現在の entitlement が違う、あるいはリクエスト自体がまだ安全境界の内側にある、のどれかです。
最初に確認するのは、どこで Pro を使おうとしているかです。Gemini Apps なら、その画像が本当に Redo with Pro まで到達しているか、そして現在の quota が残っているかを見ます。AI Mode なら Thinking with 3 Pro に入っているか、今の提供条件に合っているか、そして仕事の内容が infographic / diagram 系の route に合っているかを見ます。AI Studio や Gemini API なら、gemini-3-pro-image-preview でまず一つの安全な最小 prompt を流し、route の問題なのか category の問題なのかを分けます。
一度に全部変えないことも重要です。1つだけ直したら、そのまま同じ surface で再確認してください。safe prompt は通るのに元の依頼だけ通らないなら、それは hidden downgrade より category boundary の可能性が高いです。
2026年4月14日時点で、Google の Gemini Apps help、AI Mode help、Gemini API docs は、Pro を surface ごとに別の contract として説明しています。Gemini の safety docs も、いくつかの core harms は常に blocked のままだと書いています。ここで本当に有用な問いは Google が Pro をこっそり変えたのか ではなく、どの入口で止まっているのか です。
30秒ルートボード
| どこで止まったか | 最初に見ること | 同じ surface での確認方法 | 判断を切り替えるタイミング |
|---|---|---|---|
| Gemini Apps | Redo with Pro が出ていたか、今の quota が残っているか | 同じ画像で Pro redo が見える、または完了する | prompt ではなく route / quota の問題だと分かる |
| AI Mode | Thinking with 3 Pro か、現在の条件に合っているか、仕事が図表向きか | 同じ仕事が正しい AI Mode branch で通る | その仕事自体が AI Mode Pro に合っていない |
| AI Studio / Gemini API | gemini-3-pro-image-preview を使っているか、安全な最小 prompt が通るか | 同じ model で safe prompt が通る | 問題は route ではなく元のタスク側にある |
| Safe prompt は通るが元タスクは通らない | route 自体は生きている | 元タスクだけ引き続き blocked | policy boundary と見るべき段階 |
この表示が誤読されやすいのは、Nano Banana Pro がもうどこでも同じ一本の通路ではないからです。Gemini Apps では Nano Banana 2 の後ろに Pro redo が重なる形になり、AI Mode ではより狭い用途向けの route になり、API では model ID そのものになります。この3つを混ぜて比べると、surface の差がそのまま Pro quality drop に見えてしまいます。
だから、ここで一番効率が悪いのは最初から prompt をこね続けることです。prompt を変えても、surface が違うのか、entitlement が違うのか、policy boundary なのかは分かりません。先に branch を分け、1つだけ直し、同じ surface で確認する方がずっと早いです。
Gemini Apps でこの表示が出た場合
この branch で最初に直したい認識は、Gemini Apps の開始地点は常に Nano Banana Pro ではない、ということです。現在の Google の説明では、新しい画像はまず Nano Banana 2 で作られ、その後に有料ユーザーが Redo with Pro を使えます。つまり、ユーザーが 今 Pro を評価している と思っていても、実際には default Nano Banana 2 flow か、あるいは redo path がもう使えない app state を見ていることがあります。
Gemini Apps 内で RESTRICTED by System Instructions が出たら、まず 3 つ確認してください。1つ目は、その画像が本当に Redo with Pro まで到達していたか。2つ目は、その日の current quota がまだ残っているか。3つ目は、今日の App contract を見ているのか、それとも昔の Pro の印象と比べてしまっていないかです。
ここでは route issue と quality complaint が非常に混ざりやすいです。Gemini Apps は default model、redo path、quota boundary を1つの consumer surface にまとめているからです。Nano Banana 2 側の上限に届くと、Pro redo の道も一緒に消えることがあります。そのとき正しい次の動きは もっと上手い prompt を書く ではなく、今の App contract が欲しい route を出していないと理解し、quota reset を待つか、別の surface に移るか、Nano Banana 2 を意図的に使うかを決めることです。
もし本当の悩みが なぜ Gemini Apps、AI Mode、API で Pro の体感がこんなに違うのか なら、Nano Banana Pro は劣化したのか？ の方が広い説明になります。
AI Mode で Pro を試している場合
AI Mode は branding が似ているので、いちばん時間を溶かしやすい branch です。現在の Google の説明では、AI Mode の Pro は Thinking with 3 Pro で提供され、主な fit は infographics と diagrams です。つまり、どんな画像でも上位版 という route ではありません。加えて、現時点の plan、region、language 条件もあります。
だから、AI Mode での refusal は Nano Banana Pro is blocked everywhere と同義ではありません。単に違う mode にいる、現行の条件に合っていない、あるいは task 自体が AI Mode Pro の現在の役割に合っていない、という意味であることがずっと多いです。もしやりたい仕事が 一般的な画像をすばやく出したい に近いなら、AI Mode を押し通すより surface を変える方が速いことがあります。
この branch での same-surface verification は地味ですが重要です。Thinking with 3 Pro、現在の availability、task fit を確認したうえで、同じ仕事を再実行してください。route も entitlement も正しいのに、仕事の内容が Google の今の説明する Pro fit から外れているなら、そこで無理に prompt tuning を続ける意味は薄いです。surface choice を見直した方が早いです。
また、Gemini Apps と AI Mode を同じ troubleshooting session で混ぜない方が安全です。Apps の default flow と AI Mode の narrow route を行ったり来たりすると、異なる contract の差をそのまま 隠れた downgrade と呼んでしまいます。より確実なのは、1 surface、1 correction、1 retry です。
AI Studio または Gemini API を使っている場合
developer side では、まず model ID を確認します。Pro を試すなら gemini-3-pro-image-preview です。そのうえで最初のテストは production prompt ではなく、明らかに安全な最小 prompt にしてください。人や public figure や敏感な edit を含まない infographic、比較カード、diagram などが向いています。ここで知りたいのは output の芸術性ではなく、route が生きているかどうかです。
safe prompt が gemini-3-pro-image-preview で通るなら、それだけで大きな切り分けが終わります。model は reachable で、entry point も死んでいない。つまり、元の依頼が引き続き blocked なら、調べるべき対象は route availability より request category 側です。API ではこの切り分けが consumer surface より見えやすいです。
ここで気をつけたいのは、別の error family をこの見出しに押し込まないことです。実際に見ているのが 429、empty response、ignored parameters、wrong output size なら、それはもう RESTRICTED by System Instructions の family ではありません。その場合は Gemini image API のよくあるエラー修正 の方が適切です。次に見るべきものが billing、endpoint、parameter handling に変わるからです。
問題がリクエストのカテゴリ自体にある場合
この branch はいちばん受け入れづらいですが、この exact phrase に対してはいちばん役に立つことも多いです。現在の Gemini safety docs は、一部の core harms は常に blocked のままだと明言しています。これは quota の話でも hidden toggle の話でもなく、言い回しを少し変えれば必ず通るという話でもありません。route と entitlement を外した後に残るのが、category boundary です。
テスト方法は単純です。surface を変えず、model を変えず、元の依頼を明らかに安全で普通の依頼に置き換えます。その safe control prompt が通り、元の依頼だけが引き続き通らないなら、route issue と category issue はもう分かれています。route は動いている。blocked なのは仕事の中身です。
その段階で問うべきは この仕事を安全な形に組み替えられるか です。実在人物を fictional character にできるか。危険な image edit を中立的な diagram に変えられるか。引っかかっている核心部分を取り除けるか。もしそれができないなら、答えもまた 今はこの category を product policy が受け付けていない になります。ここで prompt を押し込む時間はあまり意味がありません。
人・public figure・顔まわりの制限が主題なら、なぜ Gemini は人物画像生成を制限するのか の方が適しています。ただしこのページの役割はもっと狭く、境界を素早く見抜くことにあります。
修正後の確認と次に選ぶルート
修正を入れたら、同時に5つの変数を動かさないでください。安全な順番は次の通りです。
- 変えるのは 1 つだけ
- そのまま同じ surface で再確認
- route と category の切り分けがまだ必要なら safe control prompt を 1 つ追加
- 今の surface が明らかに違う contract だと分かったときだけ route を変える
この順番の価値は、結果が読めることです。surface も prompt も entry path も一気に変えると、何が効いたのか分かりません。同じ surface に留まり、1 correction ごとに見れば、直したのが route なのか entitlement なのか、それとも real boundary を確認しただけなのかが分かります。
Gemini Apps で Pro redo path が出ていないと分かったなら、surface を変えるか quota reset を待ちます。AI Mode が task fit ではないと分かったなら、一般的な image job をそこに押し込まない方がいいです。API で safe control prompt が通るのに元タスクが通らないなら、global Pro outage と考えるのをやめます。逆に safe prompt も通らないなら、まだ policy diagnosis の段階ではなく、route と entitlement に戻るべきです。
gate を確認したあとに読む sibling pages は次の通りです。
- Nano Banana Pro は劣化したのか？：cross-surface の広い説明が必要なとき
- なぜ Gemini は人物画像生成を制限するのか：people / public-figure boundary が主題のとき
- Gemini image API のよくあるエラー修正：developer side の failure family が別のとき
よくある質問
Gemini Apps に Pro はまだありますか？
あります。ただし、常に最初から開いている route ではありません。現在の Google help では、画像はまず Nano Banana 2 で作られ、その後に有料ユーザーが Redo with Pro を使えるという形です。
AI Mode Pro はどんな画像にも向いていますか？
向いていません。Google の現在の説明は Thinking with 3 Pro を infographic / diagram 向け route として置いています。どんな image task にも上位互換 という意味ではありません。
API の safety settings でこれを緩められますか？
Google が常時 blocked としている category については無理です。safety settings が影響する文脈はありますが、current docs でも core harms の一部は調整で外れないと書かれています。
Safe prompt は通るのに元の依頼が通らないなら、どう考えるべきですか？
その場合、route 自体は生きています。blocked なのは元の依頼の category です。次にやるべきことは job framing を変えるか、boundary を受け入れるかを決めることです。
どんなときに Nano Banana 2 に戻るべきですか？
一般的な image generation が欲しいとき、Gemini Apps がすでに Nano Banana 2 を default path にしているとき、あるいは AI Mode Pro が task fit ではないと分かったときです。現在の公開 docs でも Nano Banana 2 はより general な default route として扱われています。