FLUX.2 Pro＋LoRAの商品画像をn8nで自動生成：ProはLoRA非対応

FLUX.2 [pro]のAPIには、LoRAを指定するフィールドがありません。 BFL（Black Forest Labs）のAPIでも、fal.aiが提供する[pro]でも同じです。商品画像を多数のシーンで同じ見た目に保ちたい場合、n8nで組める構成は次の3つに分かれます（料金と仕様は2026年10月2日時点）。

どのルートでも、n8n側は「送信→待機→ポーリング→ダウンロードして保存」という同じ骨組みで動きます。違うのはエンドポイント、認証ヘッダー、リクエスト本文、そして状態を表すフィールド名だけです。

以下のノード構成とリクエスト本文は、BFL、fal、n8nの公式ドキュメントの記載を突き合わせて組んだもので、実行結果に基づくものではありません。まず1商品・1枚で最後まで通し、保存された画像を確認してから件数を増やしてください。

FLUX.2 [pro]にLoRAは載せられるか：APIにLoRAの入力はない

載せられません。BFLのFLUX.2 [pro]のAPIリファレンスが受け付けるのは、prompt、input_imageとinput_image_2〜input_image_8、width、height、seed、safety_tolerance、output_format、webhook_url、webhook_secret、disable_pupです。LoRAやfinetune_idにあたる項目はありません。falのfal-ai/flux-2-proとfal-ai/flux-2-pro/editにもlorasパラメータはありません。

BFLが「[pro]はLoRA非対応」と一文で明記しているわけではなく、根拠はスキーマに入力がないことと、後述するLoRA用エンドポイントの一覧に[klein]しか載っていないことの2点です。

「FLUX.2はLoRA対応」という説明を見かけるのは、FLUX.2というファミリーの中にLoRAを使えるモデルがあるからです。

• BFLのAPI：LoRAを使えるのはFLUX.2 [klein]の-finetunedエンドポイントだけです（Public Beta）。[pro]、[max]、[flex]用の-finetunedエンドポイントは一覧にありません。
• fal.ai：fal-ai/flux-2/loraはFLUX.2 [dev]をベースにしたLoRA対応のエンドポイントです。名前にflux-2と入っていますが、[pro]ではありません。
• ローカル実行：公開ウェイトがあるのは[klein]と[dev]で、LoRAの学習もこの2つが対象です。

つまり「どのモデルを、どのプラットフォームで動かすか」を決めないと、LoRAを使えるかどうかは答えが出ません。BFLは2026年10月1日にFLUX 3 Imageも公開していますが、LoRAへの対応は別に確認が必要で、ここから先はFLUX.2の話です。

どのルートを選ぶか：SKU数と1商品あたりの枚数で決める

判断の軸は2つあります。1つは学習の手間を何枚の画像で回収できるか、もう1つは学習と請求をどこに置きたいかです。

SKUが多く、1商品あたりの生成が数枚〜数十枚ならルートAです。商品ごとにLoRAを学習する必要がなく、商品写真のURLを行ごとに差し替えるだけで済みます。BFLの画像編集ガイドによると、FLUX.2はAPIで最大8枚（プレイグラウンドでは10枚、[klein]は4枚）の画像を同時に参照でき、BFLは[pro]を量産向けと位置づけています。正面、側面、ラベルのアップを別々の参照として渡す使い方ができます。

同じ商品、または同じブランドのトーンで数百枚単位を出すならLoRAが候補になります。プロンプトだけで呼び出せるので、参照画像の分の料金がかからず、1枚あたりは安くなります。そのうえで次のように分かれます。

• 学習用のGPUを自分で用意でき、請求をBFLにまとめたい → ルートB。学習は自分で行い、できた.safetensorsをBFLのダッシュボードにアップロードします。BFLの学習ガイドが挙げる最低要件は、[klein] 4B BaseでVRAM 12GB・RAM 32GB、9B BaseでVRAM 22GB・RAM 64GBです。
• 学習もAPIで済ませたい、または商品LoRAとスタイルLoRAを重ねたい → ルートC。falの学習エンドポイントに画像のzipを渡せばLoRAができ、推論では最大3つまで同時に指定できます。

ルートBとCは排他ではありません。BFLの-finetunedエンドポイントはinput_imageも受け付けるので、LoRAでトーンを固定しつつ、商品写真を参照として添える構成も取れます。

ライセンスは事前に確かめてください。[klein] 4BはApache 2.0、[klein] 9BはFLUX Non-Commercial Licenseで公開されています（FLUX.2の概要）。9BベースのLoRAをBFLのAPI経由で商用の画像に使う場合の扱いは、公開ドキュメントに明記がないため、BFLのライセンス窓口で確認が必要です。[dev]は、BFLが自前運用向けのウェイトを非商用としている一方、falのモデルページには商用利用のタグが付いています。条件は動かす場所で変わります。

FLUX.2以外のモデルも含めて検討している段階なら、2026年の画像生成モデル比較で用途別の候補を先に絞れます。

n8nの共通の骨組み：送信→Wait→ポーリング→If→ダウンロード

BFLもfalも、リクエストを送るとすぐに「受け付けた」という応答だけが返り、画像は後から取りに行く非同期のAPIです。そのためHTTP Requestノード1つでは完結せず、次の並びになります。

1. 入力：商品ごとの行を用意します。最低限、SKU、商品写真のURL、シーンのプロンプトの3列です。Google Sheetsなどの表から読み込めば、1行が1アイテムになります。
2. Loop Over Items：1件ずつ（または少数ずつ）次の処理に流します。
3. HTTP Request（送信）：POSTで生成を依頼します。応答に結果確認用のURLが入っています。
4. Wait：Resumeを「After Time Interval」にして数秒待ちます。
5. HTTP Request（状態確認）：手順3で返ったURLにGETします。
6. If：状態が完了なら次へ、処理中なら手順4に戻し、失敗なら記録して次の商品へ進みます。
7. HTTP Request（ダウンロード）：画像のURLにGETし、Response Formatを「File」にしてバイナリとして受け取ります。
8. 保存：自社のストレージやドライブに書き込み、ループの先頭に戻ります。

設定で間違えやすい点は4つあります。

認証はヘッダーで渡します。 BFLとfalへの接続には汎用のHTTP Requestノードを使います。Generic Credential Typeの「Header Auth」を選び、認証情報を1つ作って送信と状態確認の両方で使い回します。ヘッダー名はBFLがx-key、falがAuthorization（値はKey に続けてAPIキー）です。

状態確認のURLは組み立てず、応答の値をそのまま使います。 BFLはapi.bfl.ai（およびapi.eu.bfl.ai、api.us.bfl.ai）を使う場合、返されたpolling_urlを必ず使うよう統合ガイドで求めています。ループで手順4に戻ると直前のノードの出力は状態確認の応答に置き換わるので、URLは送信ノードの出力を名前で参照します。送信ノードを「Submit」と名づけたなら{{ $('Submit').item.json.polling_url }}です。

待ち時間は65秒未満にします。 n8nのWaitノードは、65秒未満の待機なら実行データをデータベースに退避せず、メモリ上で続行します。BFLの公式サンプルは0.5〜1秒間隔でポーリングしていて、最小間隔の規定は公開されていません。n8nでは5秒程度から始め、長すぎると感じたら縮めるのが扱いやすい設定です。

ループには打ち切り条件を付けます。 状態がいつまでも完了にならない場合に備えて、Edit Fields（Set）ノードで確認回数を数え、上限を超えたら失敗として扱う分岐を入れておくと、実行が止まらなくなる事態を避けられます。

ルートA：FLUX.2 [pro]に参照画像を渡すHTTP Requestの設定

送信ノードは、MethodをPOST、URLをhttps://api.bfl.ai/v1/flux-2-proにします。/v1/flux-2-proは固定スナップショット、/v1/flux-2-pro-previewは最新版です。商品画像のように後から同じ条件で再生成したい用途では、固定スナップショットのほうが結果を 比べやすくなります。

本文はJSONで次のように指定します。{{ }}の中は入力の列名に合わせてください。

{
  "prompt": "{{ $json.scene_prompt }}",
  "input_image": "{{ $json.product_image_url }}",
  "width": 1024,
  "height": 1024,
  "output_format": "png"
}

input_imageにはURLかbase64を渡せます。角度違いやラベルのアップを足すときはinput_image_2、input_image_3と続けます。プロンプトに引用符や改行が入るとJSONが壊れるので、その場合はJSONを直接書かず、フィールドごとに値を指定する方式に切り替えます。

応答にはidとpolling_urlのほか、cost、input_mp、output_mpが含まれます。costをシートに書き戻しておくと、バッチ全体の費用を後から実績で集計できます。

状態確認のIfノードは{{ $json.status }}を見ます。

result.sampleは10分で失効する署名付きURLです。URLをシートに書いて後でまとめて取りに行く設計にすると、取りに行った時点で期限が切れています。Readyになった同じ実行の中でダウンロードし、自社のストレージに保存してください。このURLはdelivery.*.bfl.aiから配信され、CORSが有効ではなく、エンドユーザーに直接見せる用途も想定されていません。

ルートB：BFLの-finetunedエンドポイントでklein LoRAを呼ぶ

ルートAとの違いは、事前準備とURL、本文の2フィールドだけです。n8nの骨組みとstatusの判定はそのまま使えます。

事前準備はFLUX.2 LoRA Inferenceの手順に沿います。

1. AI-ToolkitやDiffusersで、FLUX.2 [klein]のBaseモデルに対してLoRAを学習します。
2. BFLのダッシュボードで「Customization → Finetunes」を開き、.safetensorsをアップロードします。ここで付けた名前（小文字の英数字、ハイフン、アンダースコアのみ）がfinetune_idになります。トリガーフレーズも任意で設定できます。
3. アップロード時に選んだベースモデルに対応する-finetunedエンドポイントを呼びます。

エンドポイントは/v1/flux-2-klein-4b-finetuned、/v1/flux-2-klein-9b-finetuned、/v1/flux-2-klein-9b-kv-finetuned、/v1/flux-2-klein-9b-kv-bf16-finetuned、/v1/flux-2-klein-base-4b-finetuned、/v1/flux-2-klein-base-9b-finetunedの6つです。9B用に登録したLoRAを4Bのエンドポイントで呼ぶと失敗するので、ダッシュボードで選んだベースモデルと一致させます。

{
  "prompt": "{{ $json.scene_prompt }}",
  "finetune_id": "my-product-lora",
  "finetune_strength": 1.0,
  "width": 1024,
  "height": 1024
}

finetune_strengthの既定値は1.0です。どんなプロンプトでも学習画像そっくりの結果になる場合は、seedを固定して0.7〜0.9の範囲で下げ、商品の特徴が残りつつシーンが変わる値を探すようBFLは案内しています。トリガーフレーズを設定したLoRAは、プロンプトにそのフレーズを入れないと効きません。

この機能はPublic Betaです。BFLは料金、パラメータ、エンドポイント名が正式提供までに変わる可能性があると明記しているので、URLをワークフローに書き込む前に、ダッシュボードが自動生成するAPI例と見比べてください。

ルートC：falでFLUX.2 [dev]のLoRAを学習して呼ぶ

falでは学習と推論の両方がAPIで、どちらもキューAPIを通します。骨組みは同じですが、フィールド名がBFLと異なります。

falの状態はIN_QUEUE、IN_PROGRESS、COMPLETEDの順に進みます。注意が必要なのは、失敗したリクエストもCOMPLETEDで終わり、errorフィールドが付く点です。Ifノードではstatusだけでなくerrorが空であることも条件に入れます。完了後はresponse_urlへのGETが1回増えるので、BFL版よりHTTP Requestノードが1つ多くなります。

学習はfal-ai/flux-2-trainerにPOSTします。

{
  "image_data_url": "https://example.com/product-dataset.zip",
  "default_caption": "a photo of TOK product",
  "steps": 1000
}

image_data_urlは画像をまとめたzipのURLで、falは10枚以上を目安にしています。画像ごとに同名の.txtでキャプションを付けられ、付けない場合はdefault_captionが必須です（どちらもないと学習が失敗します）。stepsの既定値は1,000で、100〜10,000の範囲で指定できます。結果のdiffusers_lora_fileにLoRAファイルのURLが入ります。学習は商品ごとに1回なので、生成用とは別のワークフローに分けておくと管理しやすくなります。

推論はfal-ai/flux-2/loraです。

{
  "prompt": "{{ $json.scene_prompt }}",
  "loras": [
    { "path": "{{ $json.lora_url }}", "scale": 1 }
  ],
  "image_size": { "width": 1024, "height": 1024 },
  "num_images": 1,
  "output_format": "png"
}

lorasは最大3つ、scaleは0〜4（既定1）です。image_sizeはプリセット名でも、512〜2,048pxの幅と高さでも指定できます。商品写真も参照として渡したい場合はfal-ai/flux-2/lora/editに切り替え、image_urls（最大4枚）を加えます。

1枚あたりの費用：[pro]＋参照1枚は$0.045、LoRAは267枚から安くなる

FLUX.2の料金はメガピクセル（MP）単位で、1MPは1,024×1,024です。BFLの料金ページでは、出力と参照画像のそれぞれが次のMPに切り上げられ、参照画像は1枚ごとに1MPとして数えます。出力1MPでの1枚あたりは次のとおりです。

BFLの-finetunedエンドポイントは、Public Betaの間はベースのエンドポイントと同じ料金です（BFLの料金ドキュメント）。falの学習費用は0.0064×ステップ数で、1,000ステップなら$6.40です。

500枚（すべて1MP）を出す場合の例です。

• [pro]＋参照1枚：500×$0.045＝$22.50
• [klein] 9B LoRA：500×$0.015＝$7.50（自前のGPUでの学習費用は含みません）
• falの[dev] LoRA：500×$0.021＋$6.40＝$16.90（LoRAを1つ学習した場合）

学習費用を何枚で回収できるかは、1つの不等式で出せます。falのLoRA（テキストのみ）と[pro]＋参照1枚を比べると、

6.40 + 0.021 × n < 0.045 × n
6.40 < 0.024 × n
n > 266.7

となり、LoRA1つにつき267枚以上を生成するなら、falのLoRAのほうが安くなります。266枚では[pro]が$11.97、LoRAが$11.986で[pro]のほうが安く、267枚では[pro]が$12.015、LoRAが$12.007で逆転します。

この分岐点は、出力1MP、参照画像1枚、学習1,000ステップ、公表価格という前提でだけ成り立つ予算上の目安です。採用できずに捨てる画像や再生成、学習用画像を用意する人の時間は含まれておらず、解像度やステップ数を変えれば分岐点も動きます。[pro]、[klein]、[dev]の画質の違いも金額には表れないので、安いルートに決める前に同じ商品で少数を出して見比べる必要があります。

バッチを回す前に：同時24タスクの上限と402・429の扱い

BFLのAPIは、同時に実行できるタスクが24件までです。超えると429が返り、先に投げたタスクのどれかが終わるまで新しい依頼は受け付けられません。クレジットが切れた場合は402が返ります。

n8nでは次の2点で対応します。

• 同時に投げる数を抑える：Loop Over ItemsのBatch Sizeを1にすれば、1件が保存まで終わってから次に進むので上限には触れません。速度を上げたい場合はBatch Sizeを増やすか、HTTP RequestノードのOptions→Batchingで「Items per Batch」と「Batch Interval」（ミリ秒）を設定しますが、処理中のタスクが24件を超えない範囲に収めます。
• 402でバッチ全体を止める：残高不足は待っても解決しないので、再試行せずに実行を止めて通知する分岐にします。429は待てば解消するため、時間を置いて同じ行を送り直します。

件数を増やす前に、上の表の単価に枚数を掛けて予算を出し、最初の数件で応答のcostが想定どおりかを確かめておくと、参照画像の枚数や出力サイズの設定ミスによる請求の膨らみに早く気づけます。

生成結果で目視確認する箇所：ロゴ、ラベル文字、細かい表記

参照画像もLoRAも、商品の形や色、質感を保つ手段であって、ラベルを一字一句再現する保証ではありません。BFLのドキュメントも、商品のロゴ、ラベル、小さな文字が正確に保たれるとは約束していません。公開前に人が確認する項目を決めておきます。

• ロゴとブランド名：綴り、書体、配置が実物と一致しているか。
• ラベルの文字：内容量、成分、注意書きなどの小さな文字が、読める別の文字列に置き換わっていないか。
• 数字と記号：型番、容量、認証マークが実物と同じか。
• 形状と個数：キャップ、ボタン、端子など部品の数と位置が変わっていないか。
• 色：ブランドカラーがシーンの照明で別の色に見えていないか。

ワークフローには、生成した画像をそのまま商品ページに出す経路を作らず、保存先を「確認待ち」のフォルダにして、承認したものだけを次の工程に流す形にしておくと安全です。文字の正確さが欠かせないカットでは、実物の写真を使うか、ラベル部分を後から合成するほうが確実です。

FLUX.2 ProとLoRA、n8n連携の補足Q&A

FLUX.2 Proはローカルで動かせる？

動かせません。FLUX.2 [pro]はAPIなどホスティング経由でのみ提供されています。ウェイトが公開されているのはFLUX.2 [klein]（4BはApache 2.0、9BはFLUX Non-Commercial License）とFLUX.2 [dev]（非商用）で、ローカルで動かす場合やLoRAを学習する場合はこの2つが対象です。

FLUX.2のLoRA学習は何枚の画像から始められる？

falの学習エンドポイントは、10枚以上を目安とし、多いほどよいとしています。商品向けの推奨枚数やステップ数をfalは示していません。BFLの[klein]向け学習ガイドは、1,024px以上の高解像度で品質のそろった画像を使うよう勧めています。

1回のリクエストでLoRAを複数重ねられる？

プラットフォームで違います。BFLの-finetunedエンドポイントは1リクエストにつきfinetune_idを1つしか受け付けず、重ねがけはできません。falのfal-ai/flux-2/loraはloras配列に最大3つまで指定できます。LoRAの合計サイズが2GBを超えると料金が1GBごとに50%加算され、上限は5GBです。

ポーリングの代わりにWebhookは使える？

使えます。BFLはリクエストにwebhook_url（とwebhook_secret）を指定でき、falのキューAPIもWebhookに対応しています。n8n側はWaitノードのResumeを「On Webhook Call」にして受ける形になります。ループが不要になる一方で、n8nが外部から到達できるURLを持っている必要があります。BFLでは通知を受けた後も、署名付きURLの10分の期限内に画像をダウンロードする点は変わりません。