Nano Banana Pro で「Unsupported file URI type」または「Invalid or unsupported file uri」と出ても、最初に prompt をいじらないでください。多くの場合、モデルが画像を理解できないのではなく、画像が Gemini に正しいファイル経路で届いていません。
まず分けるべきなのは二つです。何を渡したのか。そして、どの Gemini surface がそれを拒否したのか。native Gemini file_data、OpenAI互換 image_url、Vertex の gs://、公開 HTTPS URL、ローカルファイルパスは、同じ URI ルールでは動きません。URI に見える文字列でも、今の surface にとって有効な file resource とは限りません。
30秒ルート表
このエラーで最初にやるべきことは一つです。surface と入力タイプで先に分け、その後で直すこと。2026年4月9日に Gemini 公式文書を再確認した時点でも、native Gemini は Files API / files.register、OpenAI互換は image_url、Vertex は独自の object route という分離は変わっていません。
| 渡したもの | 起きがちな問題 | 最初に取る安全な手 | 同じ path での確認 | どこで切り分けを一段上げるか |
|---|---|---|---|---|
| 公開 HTTPS URL | web で見える URL を native Gemini file resource と混同した | Gemini 側で先に upload するか、実体が GCS object なら基底 object を登録する | 同じ Gemini リクエストがファイルを受け付ける | 返された file resource でも失敗する |
data:image/...;base64,... | surface を取り違えたか、base64 が途中で壊れた | OpenAI互換 image_url を維持して clean payload を作り直す | 同じ互換リクエストが画像を受け付ける | clean payload でも失敗する |
gs://bucket/object | native Gemini と Vertex の cloud route を混ぜた | Gemini なら files.register、Vertex なら gs:// を維持する | 同じ surface が object を受け付ける | docs に沿った cloud route でも失敗する |
/tmp/a.png や file:///... のような local path | device path を再利用可能な file URI のように扱った | 先に upload し、返された resource を使う | 同じ flow が valid resource で動く | upload 後も失敗する、または wrapper が request を書き換える |
ここで一つだけ強く覚えておくべきことがあります。画像形式が対応していても、file route が正しいとは限りません。 Gemini の current docs では PNG、JPEG、WEBP、HEIC、HEIF が挙がっていますが、このページのエラーはモデルが画像を受け取る前に起きていることが多いです。
native Gemini file_data を使っている場合
native Gemini が欲しいのは、Gemini 自身が理解できる file resource です。public URL や local path をそのまま file_uri に入れても、native Gemini ではそこから先に進めません。
現在の Files API docs では、flow は明快です。まず upload し、返ってきた file.uri を後続 request で使います。もし source file が Google Cloud Storage にあるなら、現在の Files API reference は files.register も明示しています。つまり、public URL を既成の file resource と見なすのではなく、GCS object を Gemini 側の resource に変換する route があるということです。
ここが old forum advice と current contract のずれやすい場所です。いまでも「AI Studio / Gemini は GCS を使えず、gs:// は Vertex 用」という言い方を見かけます。その言い方は「surface を混ぜるな」という警告としてはまだ役に立ちますが、2026年の publish-layer truth としては不十分です。今のより正確な言い方はこうです。任意の public URL は native Gemini file resource ではないが、GCS object には files.register という current official route がある。
もう一つ見落としやすいのが file resource の寿命です。Gemini の current Files API docs では upload 済みファイルが 48 時間保持されるとされています。昨日まで通っていた request が today 突然似た失敗を返すなら、prompt や model を責める前に expired resource を疑うべきです。
OpenAI互換 image_url を使っている場合
この枝が一番ややこしいのは、route 自体は合っていても同じエラーが出ることがあるからです。現在の Gemini OpenAI compatibility docs は、image_url を使った multimodal 例をまだ示しており、そこには data:image/...;base64,... も含まれています。つまり data: は everywhere unsupported ではありません。互換 route にだけ属するというだけです。
そのため、ここで問うべきなのは「Gemini は data: URL をサポートするのか」ではなく、「その payload は docs が期待する形のまま到達したのか」です。HTML escape された base64、wrapper による content item の書き換え、compat client の変形などで、route が正しくても unsupported-file-URI family のエラーは出ます。
修正順は単純です。互換 route だと確認する。image_url の shape を維持する。元ファイルから clean な base64 を再生成して、余計な変換を挟まず送り直す。native Gemini file_data の logic をここへ持ち込まない。そこを混ぜると、問題が一つから二つになります。
この section が独立している理由もそこにあります。現在の Google AI Developers Forum には Unsupported file uri: data:image/png;base64,... という exact symptom が実際にありますが、同じ日に official docs は image_url での data: を still support しています。publishable な結論は「docs が間違い」ではなく、「同じエラーは wrong route でも broken payload でも起きる」です。
GCS object、public URL、Vertex path を渡している場合
public URL、登録済み Gemini file、Vertex の gs:// は interchangeable ではありません。多くの短い解説が曖昧にするのはこの点です。
native Gemini に public HTTPS object URL を渡した場合、たいていは「ブラウザで開ける object」と「Gemini が扱える file resource」を混同しています。公開されている URL だからといって、native Gemini file_data でそのまま使えるわけではありません。より安全なのは Files API upload、あるいは source of truth が GCS にあるなら files.register です。登録対象は object そのものであって、公開用の web wrapper URL ではありません。
Vertex AI では事情が違います。そこでは gs://bucket/object が natural shape になり得ます。問題は、その経験をそのまま native Gemini に持ち戻して、「Google の image route は全部同じ object contract だ」と思い込むことです。そうではありません。
だからこの枝で先に答えるべき問いは「GCS は使えるか」ではなく、「今この request を所有している surface はどれか」です。native Gemini なら upload / files.register へ。Vertex なら Vertex route を維持。URI に見えるという理由だけで URL を入れたなら、それをまず current surface が認める file resource に変える。それが最小修正です。
アプリが local file path を渡している場合
local path は一見もっともらしく見えます。実際に file はそこにあります。しかし /tmp/example.png、file:///storage/...、似た device-side path は、あなたの app が見ている参照であって、Gemini が後で再取得できる file resource ではありません。
最も安全な cross-platform rule はやはり upload first です。ファイルを一度 Gemini 側の resource に変えてから、その returned URI を使う。そこに到達するまでは、local path は「自分の環境では見える」ことしか保証しません。
mobile SDK や wrapper の edge case、たとえば content:// のような話題は確かに存在します。ただし、それは main route を直した後の話です。最初の repair が終わる前に client-specific nuance へ潜ると、reader は長く読んだのに request が still blocked という状態になりがちです。
修正後の確認と、その次に疑うべきもの
一度だけエラーが消えたからといって、問題が完全に閉じたとは限りません。より安全な順序は次の通りです。
- 一回に一つだけ最小の file-route correction を入れ、同じ path で再試行する。
- その same request がファイルを受け付けるだけでなく、本来の job もちゃんと完了するか確認する。
- 以前 upload / register した file を使っているなら expired resource でないかを見る。
- route が明らかに正しいのに失敗するなら、base64 integrity、wrapper rewrite、stale client code を次に疑う。
ここで最も重要なのは、何を早まって blame しないかです。この symptom は、Nano Banana Pro が急に画像を理解しなくなったことを意味することは少なく、むしろ画像が supported route でモデルに届いていないことを意味します。route が整った後にだけ、payload や platform behavior へ進むべきです。
もしそこまで進んで、真の問題が別の image failure class だと分かったなら、次の相性がいいページは Gemini image common errors guide です。
FAQ
native Gemini file_data に public HTTPS URL をそのまま入れられますか。
通常はできません。public object URL と Gemini File resource は別物です。native Gemini では upload、または GCS object に対する files.register がより安全です。
data:image/...;base64,... は使えますか。
使えます。ただし OpenAI互換 image_url route に限ります。2026-04-09 時点で current Gemini docs は still support しています。そこでも失敗するなら、まず payload integrity を疑うべきです。
/tmp/a.png や file:///... のような local path は直接渡せますか。
Gemini の再利用可能 file URI のように直接渡すべきではありません。upload して returned resource を使うのが safer です。
files.register は upload の代わりになりますか。
全部の代わりにはなりません。GCS object 向けの current official route であって、local file は still upload first です。
route を直しても同じエラーが残るなら。
その時点で pure route bug ではありません。corrupted base64、expired resource、wrapper / SDK の書き換えを見てください。
覚えておくべきルール
最短の clean fix は「prompt を変える」でも「全部を PDF にする」でもありません。今の surface を見極め、その surface が本当に受け付ける file route に入力を移し、同じ path で verify し、それでも失敗する時だけ payload や platform behavior を疑うことです。