Nano Banana Proで「Unsupported file URI type」? 先にGeminiのファイル経路を直す

Nano Banana Proで「Unsupported file URI type」や「Invalid or unsupported file uri」が出たら、まず送信先のAPIと、画像の欄に実際に入った値・型を確認してください。プロンプトの言い換えより先に、画像をどう渡したかを直します。

公開HTTPS URLや署名付きURLを使っている場合、必ずアップロードし直す必要はありません。 2026年10月1日更新のGoogle公式ファイル入力ガイドは、対応するgenerateContentへのfile_uriに外部URLを渡す方法を案内しています。Geminiが処理時に画像を取得できること、URLの期限・権限・MIMEタイプ・モデルの条件を満たすことが必要です。Gemini 2.0系はこの外部URL入力に対応していません。

手元の画像なら、ファイルを読んでinlineDataへ生バイトのbase64を入れる方法もあります。繰り返し使うならFiles APIにアップロードし、返されたuriを使います。どの方法でも、元と同じ画像編集のAPI・モデルで、編集済み画像が返るところまで確認するのが修正のゴールです。

エラーの後ろに出た値から、最初の修正を決める

設定画面の値ではなく、HTTP送信直前のJSONを確認します。エラー文に値が含まれる場合も、その文字列を手掛かりにできます。ただし、次の入力すべてが同じエラー文を返すわけではありません。

ワークフローの式が展開されない例は、APIYIによる2026年4月8日の解説でも報告されています。これは原因を探す手掛かりであり、すべてのn8nや代理APIに共通する再現結果ではありません。項目名がimageUrlsでも、実際の型が文字列なのか配列なのかは別に確かめます。

JSON化するとき、未定義の値はオブジェクトの項目ごと消えることもあります。「画面にはURLがあるから送信できている」と判断せず、送信後の形を見てください。確認用ログには型、URIの方式、項目の有無などを残し、APIキー、署名付きURLのクエリ、画像のbase64全体は出さないようにします。

ネイティブGemini APIなら、URLを1本の文字列で渡す

GoogleのネイティブAPIでNano Banana Proを使う場合、現在のモデルIDはgemini-3-pro-imageです。画像編集もgenerateContentで行えます。公式画像生成ガイドを確認し、画像説明用のモデルへ変更してエラーだけを消さないようにしてください。

送信先は次の形です。認証は既存のGemini APIキーをx-goog-api-keyヘッダーで指定します。

POST https://generativelanguage.googleapis.com/v1beta/models/gemini-3-pro-image:generateContent
Content-Type: application/json
x-goog-api-key: <自分のGemini APIキー>

次は画像URLを渡すリクエストの形です。https://example.com/reference.pngは説明用の置き場所なので、使用が認められ、処理中にGeminiから取得できる実際の画像URLへ置き換えてください。以下のJSONはキャメルケースで統一しています。

{
  "contents": [
    {
      "role": "user",
      "parts": [
        {"text": "この画像の背景を明るい青に変更し、編集後の画像を返してください。"},
        {
          "fileData": {
            "mimeType": "image/png",
            "fileUri": "https://example.com/reference.png"
          }
        }
      ]
    }
  ],
  "generationConfig": {
    "responseModalities": ["TEXT", "IMAGE"]
  }
}

fileUriは配列ではなく文字列です。2枚を渡すなら、2つの画像Partを作ります。1つのPartにtextとfileDataを同居させたり、ネイティブのpartsへOpenAI形式のimage_urlを混ぜたりしないでください。Content・Part・FileDataのAPI仕様で、それぞれの項目を確認できます。

URLは正しいのに取得できないとき

ブラウザで開けることと、Geminiから画像本体を取得できることは同じではありません。ログイン済みのブラウザだけが見られるページ、画像のプレビューHTML、期限切れの署名付きURLでは、欲しい画像が届かないことがあります。

画像本体のURL、処理が終わるまで有効な期限、必要な読み取り権限、実際の画像に一致するmimeTypeを確認します。PNGならimage/png、JPEGならimage/jpegです。拡張子だけを変えても画像の形式は変わりません。非公開画像を使う場合は、承認された範囲の署名付きURLか、後述のバイト入力・アップロードを選び、バケット全体を公開する必要はありません。

公式ガイドの外部URL入力表には100MBという値がありますが、これは一般の入力方法の条件です。すべてのNano Banana Pro画像、モデル、代理サービスで100MBを受け付ける保証ではありません。ファイル形式・モデル・トークン処理の制限も確認し、まず小さな参照画像で同じ編集経路を確かめます。入力方法ごとの公式条件を優先してください。

URL_RETRIEVAL_STATUS_UNSAFEなど、安全上の取得拒否が返る場合は、文字列の整形だけで直す問題ではありません。拒否理由を確認し、アクセス制限や安全上の保護を回避する方法を試さないでください。

ローカル画像やdata URLは、inlineDataへ直す

ネイティブAPIのinlineData.dataに入るのは、画像ファイルそのものをbase64にした値です。data:image/png;base64,という接頭辞は入れません。ファイルパスをbase64にするのでもありません。

次のPythonコードは、手元のPNGから送信用JSONを作るだけの例です。API呼び出しは行いません。reference.pngは自分のPNGへ置き換え、生成したrequest.jsonを前節と同じgenerateContentに送る構成です。画像がJPEGならmimeTypeもimage/jpegへ変更してください。

import base64
import json
from pathlib import Path

image_bytes = Path("reference.png").read_bytes()
request = {
    "contents": [{
        "role": "user",
        "parts": [
            {"text": "この画像の背景を明るい青に変更し、編集後の画像を返してください。"},
            {"inlineData": {
                "mimeType": "image/png",
                "data": base64.b64encode(image_bytes).decode("ascii"),
            }},
        ],
    }],
    "generationConfig": {"responseModalities": ["TEXT", "IMAGE"]},
}
Path("request.json").write_text(
    json.dumps(request, ensure_ascii=False), encoding="utf-8"
)

URLが取得できないときにバイト入力で通るなら、取得経路を切り分ける材料になります。ただし、画像の大きさや形式がモデルの制限を超えていれば、入力方法を変えただけでは解消しません。

Files APIを使うなら、返されたuriと状態を確認する

画像を複数のリクエストで使う場合は、Files APIにアップロードして参照できます。Files APIの仕様に従い、アップロード応答のFileオブジェクトからuriとmimeTypeを取得してください。Fileの識別名であるnameや、アップロードに使ったローカルパスをfileUriへ入れないようにします。

手順は次の順です。

1. 既存のクライアントで、画像本体と正しいMIMEタイプを指定してアップロードします。
2. 返されたFileのstateを確認します。PROCESSINGならnameで状態を取得し、ACTIVEになってから生成に使います。待機には回数や時間の上限を設け、FAILEDならエラー内容を確認して止めます。
3. 前掲JSONの画像Partを、返された値を使う次の形へ置き換えます。
4. 同じProモデル・同じ編集指示で送信し、画像出力を確認します。

{
  "fileData": {
    "mimeType": "image/png",
    "fileUri": "<アップロード応答のFile.uri>"
  }
}

このfileUriの例は差し替え用です。山括弧を含めて送信する値ではありません。通常のFiles APIアップロードは48時間保持されるため、以前保存したURIが使えなくなった場合は、Fileの期限と存在を確認します。アップロード自体が成功しても、選択したモデルがそのファイル形式を扱えるという証明にはなりません。公式のファイル入力方法で保持期間とモデル別の条件を照合してください。

gs://を使う場合は、GCS登録とVertex AIを区別する

Google Developer APIで既存のGCSオブジェクトを使うには、files.registerという方法があります。gs://を任意のfileUriへ貼り付けることと、登録手順を済ませることは別です。

登録先はPOST https://generativelanguage.googleapis.com/v1beta/files:registerで、入力はuris配列、応答はfiles配列です。例えば登録対象の形は次のようになります。

{"uris": ["gs://your-bucket/reference.png"]}

ここではAPIキーだけでは登録できません。公式ガイドのGCS登録手順に従い、呼び出し側のOAuth認証・必要な権限、APIとサービスIDの準備、Geminiサービスエージェントが対象バケットを読み取るための権限を確認します。クライアント初期化でAPIキーを要求されても、登録処理の認証とは別です。登録後は返されたFileのuriを使い、生成リクエストの認証はその経路の条件に従います。登録仕様と権限を含む公式手順を併せて確認してください。

GCS登録では画像をFiles APIの保管領域へコピーするわけではなく、登録によるアクセスは最大30日です。元のオブジェクトの読み取り条件も維持する必要があります。通常のアップロードの48時間とは区別してください。

元からVertex AIを使っている場合は、プロジェクト・ロケーションを含む別の送信先と認証の手順を使います。gs://という文字列だけを見てGoogle Developer APIとVertex AIを入れ替えると、URI以外の条件まで変わります。2025年のGoogle ForumのGCS入力に関する質問も、Gemini 2.0とAPIキー・Vertexの区別が背景にある報告です。現在の公開HTTPS対応を否定する根拠にはなりません。

OpenAI互換APIやComfyでは、そのAPIの形式を保つ

送信先が/v1beta/openai/配下なら、ネイティブのcontentsではなく互換APIの形式を使います。GoogleのOpenAI互換ガイドには、画像理解の入力として次の形が載っています。

{
  "type": "image_url",
  "image_url": {"url": "data:image/png;base64,<画像のbase64>"}
}

これは互換APIのメッセージ内に置く画像要素です。この形式ではdata URLの接頭辞を使いますが、ネイティブのfileUriやinlineData.dataへ同じ文字列を移すことはできません。また、画像理解の例が動くことと、Nano Banana Proで画像編集できることは別です。互換APIを使い続ける場合は、そのサービスが公開しているモデル・編集操作・画像応答の仕様まで確認してください。

ComfyのNano Banana Proコード例は、api.comfy.org/v2/models/vertexai/gemini-3-pro-imageとCOMFY_API_KEYを使う独自のAPIです。日文資料にはURIベースの入力と生バイトの入力が載っていますが、Google Developer APIのホストや認証と置き換えられるわけではありません。Comfyで説明されているinlineDataの20MB制限、生成画像の署名付きURLの24時間という期限も、そのサービスの条件です。Google Filesの48時間やGCS登録の最大30日と混同しないでください。

一般的な入力スキーマに音声や動画の項目があることも、Proモデルがその入力を処理できる証拠にはなりません。今回直したいのは参照画像を使った画像編集です。選択したモデルの画像入力・出力の説明を基準にします。

SDKや代理サービス経由でのみ失敗する場合は、クライアントがURLを先に取得してバイトへ変換しているか、そのままサーバーへ渡しているかも確認します。2025年のVercel AI SDKの報告には、その違いが記載されています。ただし、当時のバージョンの報告であり、現在のすべてのラッパーに同じ不具合があるとは言えません。送信先、SDK・ラッパーのバージョン、最終JSONを確認してから、該当する仕様や修正履歴を調べます。

修正完了は「画像が返り、編集結果も合う」まで

最初の再試行では、元のAPI、Proモデル、編集指示を保ち、画像の渡し方だけを変えます。別のモデルで画像の説明文が返ったことを、Proの編集成功として扱わないでください。

ネイティブgenerateContentなら、candidates[].content.parts[]を調べ、画像のMIMEタイプとデータを含む画像要素があるか確認します。inlineDataで返された画像はbase64を復号して保存し、画像として開けることと、指定した背景の変更などが反映されていることを確認します。画像要素は文章要素と一緒に返ることもあるので、先頭のparts[0]だけを見る実装は避けます。公式の画像編集例も画像要素から結果を取り出しています。

HTTP 200でも文章しかない場合は、まだ目的を達成していません。応答に候補があるか、finishReasonやpromptFeedbackにブロック理由がないか、アプリが画像要素を捨てていないかを確認します。403の権限、404のモデル、429の上限などへ症状が変わったら、URIの整形を繰り返す段階ではありません。Gemini画像生成エラーの対処法とAPIエラーコード表で、そのエラーに合う確認へ進みます。

このページのJSONとbase64の処理は、入力の形を確認するための例です。ここで実APIの画像生成成功率や、実際のアカウント・URLでの動作を検証したものではありません。

よくある確認

公開HTTPS URLなら、そのままfileUriへ入れてよいですか？

対応するネイティブgenerateContentでは使えます。URLが画像本体を返し、Geminiが処理時に取得でき、期限・MIME・モデルなどの条件を満たすことが必要です。Gemini 2.0系は外部URL入力に対応していません。詳しい条件は現在のGoogle公式ガイドを確認してください。

base64はfileUriとinlineDataのどちらへ入れますか？

ネイティブAPIではinlineData.dataへ入れます。mimeTypeも指定し、data:image/...;base64,の接頭辞は付けません。OpenAI互換APIのimage_url.urlで使うdata URLは別の形式です。

昨日使えたファイルURIが今日は失敗するのはなぜですか？

期限や元ファイルのアクセス条件を確認します。公式ガイドでは、通常のFiles APIアップロードは48時間、GCS登録によるアクセスは最大30日です。署名付きURLはそのURLの有効期限に従うため、これらの数字を一律に当てはめないでください。

URLを配列で持っている場合はどうしますか？

各URLを1本ずつ別の画像Partへ入れます。fileUriそのものを配列にしたり、配列全体を文字列へ変えたりしません。テンプレート式を使うワークフローなら、送信時に式が評価され、期待したURI文字列になっていることも確認します。