最近、Nano Banana Pro（モデルID: gemini-3-pro-image-preview）を使用して画像から画像生成を行う際に、非常に「Googleらしい」400エラーに遭遇したというお客様がいらっしゃいました。
{
"status_code": 400,
"error": {
"message": "Unsupported file URI type: {{ $json.imageUrls }}. File URI must be a File API (e.g. https://generativelanguage.googleapis.com/files/<id>), Youtube (e.g. https://www.youtube.com/watch?v=<id>), or HTTPS (e.g. http://path/to/file).), or a valid gURI (e.g. gs://bucket/object",
"type": "",
"code": 400
}
}
この Nano Banana Pro のエラーメッセージは、すでに「犯人」を指し示しています。それは Unsupported file URI type: {{ $json.imageUrls }} です。ここで注目すべきは、{{ $json.imageUrls }} が n8n のテンプレート変数が置換されていない状態のままであるという点です。つまり、お客様はワークフロー内で動的式を書いたものの、エンジンがそれを実際のURLにレンダリングせず、Gemini API の fileUri フィールドに文字列としてそのまま渡してしまったのです。Google 側では {{ ... }} という形式の URI を認識できないため、リクエストを拒否したというわけです。
本記事では、この実際のエラー事例と、gemini-3-pro-image-preview の入力形式に関する Google 公式ドキュメントに基づき、最もよくある5つの発生シナリオを分解し、それぞれの最小再現コードと解決策を提示します。この記事を読み終える頃には、Unsupported file URI type が発生した失敗リクエストを5分以内に特定し、修正できるようになっているはずです。
Nano Banana Pro エラーの核心情報まとめ
コードを修正する前に、このエラーの重要な情報と、公式が許可している URI 形式を一覧表にまとめました。
| 項目 | 内容 |
|---|---|
| モデル ID | gemini-3-pro-image-preview（Gemini API における Nano Banana Pro の正式名称） |
| HTTP ステータス | 400（Bad Request、クライアント側のパラメータエラー） |
| エラーの主要フィールド | Unsupported file URI type |
| 真の問題箇所 | リクエストボディ内の fileData.fileUri フィールド |
| エラーに含まれるリテラル | {{ $json.imageUrls }}（レンダリングされていない n8n 式） |
| Gemini が受け入れる URI 型 | File API URI / YouTube URL / 公開 HTTPS URL / GCS gs:// URI |
| Gemini が受け入れる画像形式 | JPEG、JPG、PNG、WEBP、HEIF |
| Nano Banana Pro は外部 URL 対応？ | ✅ 対応（Gemini 2.5 以降のモデルは公開 HTTPS / 署名付き URL をネイティブサポート） |
| 主な原因 | n8n / Make / Zapier などのローコードワークフローにおけるテンプレート変数の未置換 |
🎯 迅速なトラブルシューティングのヒント: もしクライアントがリクエストボディ全体を見せたがらない場合は、APIYI (apiyi.com) のコンソールで、同じ
gemini-3-pro-image-previewモデルと同一の参照画像を使用して成功する呼び出しを一度再現してもらい、その成功リクエストと失敗リクエストのボディを比較（diff）してもらうのが、Nano Banana Pro のエラーを特定する最も早い方法です。
Nano Banana Pro で発生する「Unsupported file URI type」エラーの5つの原因
実際の事例を分類した結果、Unsupported file URI type エラーは、以下の5つの典型的な原因に集約されることがわかりました。発生頻度の高い順に解説します。
原因 1: n8n / Make / Zapier のテンプレート変数がレンダリングされていない
このエラーの第一容疑者です。{{ $json.imageUrls }} は n8n の式（Expression）構文ですが、通常は実行前に前段のノードが出力した実際の URL（例: https://cdn.example.com/uploads/abc.jpg）に置換される必要があります。しかし、以下のケースでは置換に失敗します。
- HTTP Request ノードの Body フィールドが「Expression」モードになっていない: 「Fixed」モードのままになっていると、JSON 全体が単なるテキスト文字列として送信されてしまいます。
- JSON Body で二重引用符がネストされている: n8n が式を文字列の一部と誤認し、レンダリングをスキップしてしまいます。
- 前段ノードの出力構造とパスが一致していない: 例えば、前段が
imageUrl（単数）を出力しているのに、$json.imageUrls（複数）と記述している場合、解析に失敗して n8n が式をそのまま返してしまいます。 - サブノード内の式が Item ごとに反復されない: 固定で最初の項目のみを取得しようとし、入力内容によっては
undefinedになり、シリアライズ後に文字列としてそのまま出力されてしまいます。
判断方法: Gemini のエラーメッセージに {{ ... }} が含まれていれば、100% この問題です。通常の URL がそのような形式になることはあり得ないからです。
原因 2: フィールド名のスペルミスにより undefined / null が渡されている
次に多いのがフィールド名の問題です。ユーザーのコードでよく見られるケースです。
// 上流インターフェースが実際に返すフィールド名は imageUrl（単数）
const upstream = { imageUrl: "https://cdn.example.com/a.jpg" };
// しかし下流では imageUrls（複数、s付き）と書いている
fileUri: upstream.imageUrls // 結果は undefined になる
undefined は JSON シリアライズや文字列結合の際に "undefined" という文字列に変換されます。Gemini はこれを認識できず、テンプレート変数が未レンダリングの場合とほぼ同じ 400 エラーを返します。違いは、エラーメッセージ内のリテラルが {{ ... }} ではなく undefined である点です。
原因 3: 配列を文字列として fileUri に渡している
「複数の画像をまとめて処理する」際によくあるミスです。Gemini API の fileData.fileUri フィールドは単一の文字列のみを受け付け、配列は受け付けません。しかし、多くの開発者が以下のように記述してしまいます。
// ❌ 誤り: 配列をそのまま fileUri に入れている
{
"fileData": {
"fileUri": ["https://cdn.example.com/a.jpg", "https://cdn.example.com/b.jpg"],
"mimeType": "image/jpeg"
}
}
JSON シリアライズ後、この fileUri フィールドは ["https://...", "https://..."] という文字列になり、Gemini は解析に失敗して Unsupported file URI type を返します。正しい方法は、配列を一つの fileUri に詰め込むのではなく、画像ごとに独立した parts 要素を生成することです。
原因 4: URL プロトコルまたはパスの形式がサポートされていない
「形式の不一致」による問題です。Gemini API が受け付ける URI タイプは 4 種類のみであり、範囲外の書き方をするとエラーになります。
| URI タイプ | 例 | gemini-3-pro-image-preview での可否 |
|---|---|---|
| File API パス | https://generativelanguage.googleapis.com/files/abc123 |
✅ |
| YouTube URL | https://www.youtube.com/watch?v=xxxxx |
✅（主に動画理解用） |
| 公開 HTTPS URL | https://cdn.example.com/img.jpg |
✅（Gemini 2.5+ でネイティブ対応） |
GCS gs:// URI |
gs://my-bucket/img.jpg |
✅（Vertex AI パス） |
http:// 平文 |
http://cdn.example.com/img.jpg |
⚠️ 一部拒否されるため HTTPS を推奨 |
file:// ローカルパス |
file:///Users/me/a.jpg |
❌ |
data:image/...;base64, |
base64 データURL | ❌（inlineData に含めるべき） |
| Pre-signed S3 URL | https://bucket.s3.amazonaws.com/...?X-Amz-... |
✅ |
| Azure SAS URL | https://account.blob.core.windows.net/...?sv=... |
✅ |
ローカルファイルのパス、data: で始まる base64、またはプライベートなイントラネット URL を fileUri に指定すると、例外なく Nano Banana Pro エラーが発生します。
原因 5: URL にアクセスできるが認証が必要、または画像以外が返される
最後は「URL は正しいように見えるが、Gemini が内容を取得できない」ケースです。よくある状況は以下の通りです。
- プライベート OSS / 七牛 / Cloudinary のリンクに公開権限がなく、Gemini が 403 エラーを受け取る
- 一時的な署名付き URL の有効期限が切れている
- URL が画像ではなく HTML ページを返している（画像ホスティングサイトの「共有ページ」など）
- URL がログインページへリダイレクトされている
- MIME タイプが
mimeTypeフィールドと一致していない
これらも Unsupported file URI type として表示されることがありますが、400 Invalid or unsupported file uri となることもあります。修正方法はシンプルです。ブラウザのシークレットウィンドウでその URL に直接アクセスし、正当な画像がダウンロードできるか確認してください。これが最も確実で効果的な方法です。
Nano Banana Pro エラーの最小再現と一括修正案
5つの主な原因を確認したところで、各シナリオにおける最小再現コードと修正バージョンを紹介します。これらはそのままワークフローやバックエンドにコピーして使用できます。
修正 1: n8n で imageUrls パラメータを正しく渡す
お客様が現在直面している Nano Banana Pro エラー について、n8n の HTTP Request ノードを使用している場合、正しい記述は以下の通りです。
HTTP Request ノードの設定:
- Method:
POST - URL:
https://api.apiyi.com/v1/messages(APIYIの転送先アドレスに置き換えてください) - Authentication: Header Auth (APIキーを設定)
- Body Content Type:
JSON - Specify Body:
Using JSONを選択 (Using Fields ではありません) - JSON Body (JSON全体を式モードにする点に注意。左側の紫色の「fx」ボタンを点灯させてください):
={
"model": "gemini-3-pro-image-preview",
"contents": [
{
"parts": [
{ "text": "この画像を宮崎駿スタイルに変換して" },
{
"fileData": {
"fileUri": "{{ $json.imageUrls }}",
"mimeType": "image/jpeg"
}
}
]
}
]
}
重要なポイントは3つ:
- JSON文字列の先頭に
=を付けることで、n8n に対して全体が式であり、解析が必要であることを伝えます。 "{{ $json.imageUrls }}"の外側に必ずダブルクォーテーションが必要です。これにより、内側の{{ }}が実際の文字列に置換されます。- 前のノードが確実に
imageUrlsという名前のフィールドを出力している必要があります。もしimageUrl(単数形) やimage_urlを出力している場合は、フィールド名を適切に変更してください。
この3点が満たされていれば、Unsupported file URI type エラーは即座に解消されます。
修正 2: Python / Node.js でのフィールド名のタイプミス防止
バックエンドコードを使用している場合、リクエストを Gemini に送る前にタイプミスを検知できるよう、入力チェックを追加することを推奨します。
import requests
def call_nano_banana_pro(prompt: str, image_url: str):
# 防御的チェック: リクエスト送信前に None / 空文字 / テンプレート文字列を弾く
if not image_url or not isinstance(image_url, str):
raise ValueError(f"image_url は空でない文字列である必要があります。現在の値: {image_url!r}")
if image_url.startswith("{{") or "undefined" in image_url:
raise ValueError(f"image_url が未レンダリングのテンプレート変数のようです: {image_url}")
if not image_url.startswith(("https://", "gs://")):
raise ValueError(f"image_url は https:// または gs:// で始まる必要があります: {image_url}")
payload = {
"model": "gemini-3-pro-image-preview",
"contents": [{
"parts": [
{"text": prompt},
{"fileData": {
"fileUri": image_url,
"mimeType": "image/jpeg"
}}
]
}]
}
resp = requests.post(
"https://api.apiyi.com/v1/messages",
headers={"Authorization": "Bearer YOUR_API_KEY"},
json=payload,
timeout=120
)
return resp.json()
このように「チェックしてから送信」する手法をとれば、Nano Banana Pro エラー の90%を呼び出し前に防ぐことができ、Gemini 側の失敗ログを汚さずに済みます。
修正 3: 複数の画像を正しく複数の parts に分割する
Nano Banana Pro に一度に複数の参照画像を渡す必要がある場合（スタイル変換＋人物固定など）、配列をそのまま fileUri に入れるのではなく、画像ごとに独立した parts 要素を作成するのが正しい方法です。
// ✅ 正しい記述
const imageUrls = [
"https://cdn.example.com/style.jpg",
"https://cdn.example.com/person.jpg"
];
const payload = {
model: "gemini-3-pro-image-preview",
contents: [{
parts: [
{ text: "2枚目の画像の人物を1枚目の画像のスタイルで描いて" },
...imageUrls.map(url => ({
fileData: { fileUri: url, mimeType: "image/jpeg" }
}))
]
}]
};
const resp = await fetch("https://api.apiyi.com/v1/messages", {
method: "POST",
headers: {
"Content-Type": "application/json",
"Authorization": "Bearer YOUR_API_KEY"
},
body: JSON.stringify(payload)
});
この記述により、Unsupported file URI type を回避できるだけでなく、Gemini が画像間の意味的な関係を正しく理解できるようになります。
修正 4: アクセス不可の URL は base64 インラインにフォールバック
取得した URL がプライベートバケット、社内ネットワーク、または一時的な URL の場合、Gemini サーバー側からアクセスできない可能性があります。最も確実な回避策は inlineData + base64 への切り替えです。
import base64
import requests
def call_with_base64(prompt: str, local_path: str):
with open(local_path, "rb") as f:
b64 = base64.b64encode(f.read()).decode("utf-8")
payload = {
"model": "gemini-3-pro-image-preview",
"contents": [{
"parts": [
{"text": prompt},
{"inlineData": {
"mimeType": "image/jpeg",
"data": b64
}}
]
}]
}
return requests.post(
"https://api.apiyi.com/v1/messages",
headers={"Authorization": "Bearer YOUR_API_KEY"},
json=payload
).json()
注意: inlineData は data フィールドを使用します（data:image/jpeg;base64, プレフィックスを含まない純粋な base64）。fileData は fileUri フィールドを使用します。これらは排他的ですので、同時に指定しないでください。
🎯 安定性のためのアドバイス: URL のソースが制御できない場合（顧客によるアップロードやサードパーティの API など）、画像から画像生成 はデフォルトで base64 インラインを使用し、APIYI (apiyi.com) のような API 中継サービスを通じて
gemini-3-pro-image-previewを呼び出すことを推奨します。これにより、ネットワークや権限の問題で Gemini が外部 URL を拒否する事態を回避できます。
Nano Banana Pro エラー調査チェックリスト
上記の内容を「5分でできる調査」リストにまとめました。Unsupported file URI type が発生した際は、これに沿って確認してください。
5分調査チェックリスト
| 手順 | アクション | 期待される結果 |
|---|---|---|
| 1 | エラーメッセージの Unsupported file URI type: 以降の値をコピーする |
Gemini が実際に受け取った fileUri の値を取得 |
| 2 | 値に {{、undefined、null、[ が含まれていないか確認 |
含まれていれば → 90% の確率でテンプレート未レンダリングかフィールド名ミス |
| 3 | ブラウザのシークレットウィンドウでその URL を開く | 期待: 有効な JPEG/PNG/WEBP 画像がダウンロードできる |
| 4 | URL プロトコルが https:// または gs:// か確認 |
違う場合 → プロトコル修正または base64 に変更 |
| 5 | プライベートバケット、期限切れ署名、リダイレクトではないか確認 | 該当する場合 → 公開 URL に変更または base64 に変更 |
| 6 | APIYI (apiyi.com) コンソールで同じモデル＋公開画像で再現テスト | 成功 → クライアント側の問題; 失敗 → 当社へ報告 |
この6ステップを踏めば、Nano Banana Pro エラー の根本原因をほぼ確実に特定できます。
Nano Banana Pro Unsupported file URI type に関するFAQ
Q1: エラーメッセージに {{ $json.imageUrls }} というリテラルがそのまま表示されるのはなぜですか？
Gemini API はリクエストを受け取った際、fileUri フィールドの値をそのままエラーメッセージに含めます。これは Google の標準的な仕様で、「実際に何が送信されたか」を素早く特定するためのものです。もし {{ ... }} のようなリテラルが見える場合、それはローコードワークフローのテンプレート変数がレンダリングされていないことを100%示しています。また、undefined や null の場合は、フィールド名のタイポ（誤字）が原因です。まずは APIYI (apiyi.com) 上で、固定の公開 URL を使用して正常な呼び出しを再現し、その後クライアント側のボディをその正常な形式に合わせることをお勧めします。
Q2: Nano Banana Pro / gemini-3-pro-image-preview はどの URL に対応していますか？
Google の公式ドキュメントによると、fileUri は以下の4種類の URI を受け付けます：File API パス（https://generativelanguage.googleapis.com/files/...）、YouTube URL（主に動画理解用）、公開 HTTPS URL（S3 Pre-signed、Azure SAS を含む）、GCS gs:// URI。Gemini 2.5 以降のモデルは公開 HTTPS をネイティブサポートしているため、gemini-3-pro-image-preview を使用する場合、画像を一度 File API にアップロードしてから呼び出す必要はありません。
Q3: n8n で {{ $json.imageUrls }} がレンダリングされない場合はどうすればよいですか？
主な修正ポイントは3つあります。第一に、HTTP Request ノードの JSON Body で式モード（Expression）が有効になっていること（JSON 全体の前に = があるか、左側の fx ボタンが点灯していること）を確認してください。第二に、フィールドパスが前のノードの実際の出力と一致しているか確認してください。n8n の「Execute Node」後の Output パネルでフィールド名を確認できます。第三に、サブノードを使用している場合、式はデフォルトで最初のアイテムのみを取得します。メインノードを使用するか、Item Lists ノードでデータを展開してから処理してください。
Q4: エラーメッセージに undefined と表示される場合はどう修正しますか？
コード内で存在しないフィールドにアクセスしていることを意味します。最も早い修正方法は、Gemini を呼び出す前にアサーションを追加することです：assert image_url is not None and isinstance(image_url, str)。その後、上流インターフェースの戻り値を確認してフィールド名を修正してください。よくあるタイポには imageUrls vs imageUrl、image_url vs imageUrl、url vs uri などがあります。本記事の「修正 2」の Python コードのように、HTTPS/GS 以外の文字列をリクエストから除外する処理を実装することをお勧めします。
Q5: 複数の画像を直接 fileUri に入れることはできますか？
できません。fileUri は単一の文字列のみを受け付けます。複数の画像を送信したい場合は、画像ごとに { "fileData": { "fileUri": "...", "mimeType": "..." } } 要素を作成し、それらをすべて同じ parts 配列に入れるのが正しい方法です。これにより、Gemini は画像間のセマンティックな関係を正しく認識できます。
Q6: プライベートバケットや一時的な署名付き URL を公開できない場合はどうすればよいですか？
最も確実な代替案は inlineData + base64 を使用することです。画像を読み込んで base64 エンコードし、リクエストボディに直接含めます。これにより、Gemini サーバーが外部リソースを取得する必要がなくなり、「認証失敗 / 署名期限切れ / MIME 不一致」といった問題をすべて回避できます。ただし、リクエストサイズが大きくなるため、小サイズの画像に適しています。高並列の画像生成を行う場合は、画像を一度公開可能な CDN にアップロードし、APIYI (apiyi.com) を介して gemini-3-pro-image-preview を呼び出すことを推奨します。これにより、base64 によるデータ肥大化を防ぎ、プラットフォーム側でのキャッシュやリトライも容易になります。
まとめ: Nano Banana Pro エラー修正後のベストプラクティス
Nano Banana Pro のエラー「Unsupported file URI type: {{ $json.imageUrls }}」について、結論は明確です。これは Gemini の問題ではなく、n8n やローコードワークフローがテンプレート変数を実際の URL に置換できておらず、{{ ... }} というリテラルがそのまま Gemini API に送信されてしまったことが原因です。修正方法は「修正 1」で示した通り、HTTP Request ノードの JSON Body で式モードを有効にし、前のノードが正しく imageUrls フィールドを出力しているかを確認するだけで解決します。
より広義には、「Unsupported file URI type」というエラーは、多くのチームが画像 API を呼び出す際に「入力バリデーション（検証）」層を欠いていることを浮き彫りにしています。Gemini 側でリクエストが拒否された際、それがモデルの問題なのか、ネットワークの問題なのか、あるいはパラメータの問題なのかが判別しにくくなるためです。本記事で紹介したチェックリスト、Python のバリデーションコード、n8n の式記述は、チームの標準的な対応手順としてそのまま活用いただけます。
🎯 最終アドバイス: gemini-3-pro-image-preview をベースにした画像生成ワークフローを構築している場合、すべての Nano Banana Pro 呼び出しを APIYI (apiyi.com) のような中継プラットフォームに集約することをお勧めします。コンソール上で失敗したリクエストの再現や比較が容易になるだけでなく、Google 側の障害発生時にも Nano Banana 2 や Seedream 等の同等モデルへシームレスに切り替えることができ、「Unsupported file URI type」のようなパラメータエラーを即座に特定・修正できるようになります。
著者: APIYI Team ｜ AI 大規模言語モデルの導入と安定性エンジニアリングに注力しています。Gemini や画像 API の実践的なトラブルシューティングについては、APIYI (apiyi.com) をご覧ください。
