FLUXで画像生成を始める方法｜利用環境ごとの違い

FLUXを使い始める方法は一つではありません。

Black Forest Labs公式では、大きく分けて、

Playground、API、local deploymentの3つがあります。

初めて使うならPlayground、automationやproduct組み込みならAPI、model weightsやruntimeを自分でcontrolしたいならlocalと考えると分かりやすいです。

最初に試すならBFL Playground

BFL Playgroundはbrowser上でFLUX modelを試せる公式環境です。

codeを書かずにmodelを選び、promptを入力して画像を生成できます。

FLUX.2 [max]、[pro]、[flex]、[klein]などを切り替えながら結果を比較できます。

Playgroundでpromptとparameterを詰める

Playgroundではprompt、reference image、output設定などを変えながら結果を確認できます。

FLUX.2はtext-to-imageだけでなくimage editingやmulti-referenceにも対応しています。

最初からAPI codeを書くより、Playgroundで「どのmodel・prompt・sizeが合うか」を固める方が試行錯誤しやすくなります。

成功した設定からAPI codeを確認できる

Playgroundではsuccessful generationからAPI Codeを表示できます。

Python、JavaScript、cURLなどのsnippetを取得し、同じparameterをapplicationへ移せます。

「UIで試す → codeへ移す」という流れが公式で用意されています。

automationや大量生成ならAPI

公式APIではAPI keyとcredit balanceを用意し、HTTP requestで画像を生成します。

FLUX.2 [pro]、[max]、[flex]、[klein]など用途別endpointを選べます。

Web app、batch generation、社内toolなど、repeatableなworkflowを作るならAPIが向いています。

APIは非同期処理

BFL APIはgeneration requestを送ると、すぐ完成画像を返すのではなくpolling URLを返します。

そのURLへstatusを問い合わせ、Readyになったらresult URLから画像を取得します。

application側ではrequest送信だけでなく、polling、failure、timeoutまで実装する必要があります。

localで使うならopen-weight variant

FLUX.2では[klein]や[dev]などlocal deploymentできるvariantがあります。

Hugging Faceからweightsを取得し、自分のGPUでinferenceできます。

APIへ画像やpromptを送らずruntimeをcontrolできるのがlocalの特徴です。

local向けなら[klein] 4Bが入りやすい

FLUX.2 [klein] 4BはApache 2.0で、consumer GPUを想定した比較的軽量なvariantです。

BFLのmodel pageは[klein] 4B distilledのVRAMを8.4GBと示す一方、Quick Generation Guideは約13GBを目安にしています。両者を一律の最低要件と見なさず、使うruntime・precision・設定に対応する公式手順を基準にしてください。

実際の必要VRAMはimplementationやprecisionで変わりますが、9Bや[dev]よりlocal環境へ入れやすい選択肢です。

9Bや[dev]はlicenseも確認する

[klein] 9BとFLUX.2 [dev]はNon-Commercial Licenseです。

個人experimentやresearchでは使えても、local commercial productionでは別licenseが必要になります。

localを選ぶときはhardwareだけでなくlicenseもmodel選定条件です。

MCPから使う方法もある

Black Forest LabsはFLUX MCP serverも提供しています。

Claude、Cursor、CodexなどMCP-compatible appからFLUX.2のgenerationやeditingを呼び出せます。

API codeを書かず、AI assistantのconversationから画像生成を使いたい場合の別ルートです。

料金はBFL側へ直接課金され、APIと同じrateが使われます。

どの環境を選ぶか

操作を覚えたい → Playground。

serviceや自動化へ組み込みたい → API。

自分のGPU・network・custom pipelineを使いたい → local。

AI coding assistantから呼びたい → MCP。

同じFLUXでも、目的によって入口を変える方が効率的です。

まずは使ってみる

記事の文脈に合うToolへ進めます。報酬の有無で見た目は変えていません。

• 

  FLUX

  公式サイトを見るTool詳細を見る

目的に合わせた利用開始フロー

1. まず出力の種類を決める

「新しい画像を作る」「手元の画像を編集する」「複数の参照画像を使う」「生成をアプリへ組み込む」のどれをしたいかを書きます。編集では変えたい部分と残したい部分を分けます。たとえば商品写真なら「背景を変更する／商品の形、色、ラベルは維持する」のようにします。ここが曖昧なままmodelだけ切り替えても、結果の比較が難しくなります。

2. 入口を選ぶ

一度画像を作って操作を理解するなら公式Playground、同じ処理を繰り返したりWebアプリに入れたりするならAPI、重みと実行環境を自分で管理する必要があるならローカルが候補です。MCP経由は対応するassistantから画像生成を呼びたい場合の入口ですが、裏側の料金や利用条件は接続先の契約に従います。目的が分からない状態で複数経路を同時に導入せず、最初は一つに絞ります。

3. modelと条件を決める

公式モデル一覧から、用途に合う現行IDを選びます。品質名だけで決めず、入力画像の有無、必要な編集機能、出力サイズ、利用可能endpoint、費用単位を確認します。モデルIDは製品画面の表示名とAPI endpointで異なることがあるため、実装へ移す前に公式資料の表記を保存します。ローカル実行なら対応する重み、必要なVRAM、runtime、依存ライブラリ、licenseを揃えてください。公式が示す参考VRAMは実機の処理時間や同時実行を保証しません。

Promptと入力を分けて記録する

最初の試行では、指示を「対象」「変更する内容」「残す内容」「画面構成」「雰囲気」「出力用途」に分けます。これは特定モデルの専用syntaxではなく、要件を整理するための記録方法です。参照画像がある場合は、どの画像をどの役割で使うかを記します。権利を確認できない画像を入力素材として使わないことも、生成結果とは別の前提です。

例：対象＝商品ボトル、変更＝背景を淡いグレーへ、維持＝ボトルの形とラベルの文字、構成＝ボトルを中央に置き左右に余白、用途＝ECの一覧サムネイル。出力を見た後は「何が違うか」を一つずつ記録し、構図と照明を一度に大きく変えないようにします。この例は実測promptではなく、入力要件を分けるためのひな型です。

PlaygroundからAPIへ移す場合

1. Playgroundで利用可能なmodelと入力形式を確認する。

2. 同じ目的の画像を数回作り、業務上の合格条件を満たすか見る。

3. 出力結果、model ID、parameter、入力素材の出所を記録する。

4. 公式画面からAPI code / request例を取得し、対象endpointと現在のrequest schemaを確認する。

5. API keyをサーバー側のsecret管理へ置き、client bundleへ含めない。

6. 生成request後の非同期status確認、timeout、moderation / failure、結果保存まで設計する。

7. 最初は低い上限・小さな件数で動作と費用を確認し、監視を整えてから処理量を増やす。

PlaygroundのparameterがすべてAPIで同じように利用できるとは限りません。画面で成功したことだけでAPI実装まで保証されたと考えず、移行後にendpoint別の確認をします。API responseのpolling URLや結果URLは、固定形式を前提に自作せず、その時点の公式仕様に従います。

Local実行を選ぶ前のチェック

ローカルは「API料金が不要」というだけでは選べません。モデル重みのdownload先と容量、GPUのVRAM、OS・driver、利用するinference library、出力時間、license、更新を追う担当が必要です。FLUX.2 [klein] 4Bは公式が参考VRAMを示していますが、精度設定や実装によって必要量は変わります。9Bや[dev]の商用利用条件も、ハードウェアとは別に確認してください。

機密データを外部へ送りたくない場合、local executionは候補になりますが、導入したruntimeやログ、保存先からの漏えいリスクまで自動で消えるわけではありません。アクセス権、ログ、生成ファイル、バックアップを管理し、社内の情報区分に沿って運用します。

試行結果を採用判断に変える

表は横にスクロールできます

確認する項目	記録する例	採用判断の例
指示への適合	残す部分・変える部分の達成	必須条件を一つでも崩したら差し戻す
出力品質	文字、輪郭、色、構図	公開先ごとの品質基準を満たす
時間	1件の待ち時間、timeout	作業上限内か
費用	model、サイズ、生成枚数ごとの費用	月間上限に収まるか
運用	secret、データ、保存、失敗処理	担当者が運用できるか
権利	入力素材、model license、output用途	責任者確認が完了したか

「画質が良い」だけでは導入の判断になりません。必要条件を満たし、費用・時間・利用条件を受け入れられる経路だけを継続します。うまくいかない場合は、まず入力要件、次にmodel・経路、最後に別サービスの順で見直すと、どこが原因だったかを切り分けやすくなります。

AIものさしの判断

初めてFLUXを使うなら、PlaygroundでFLUX.2 [pro]や[klein]を比較し、気に入った設定をAPI codeへ移す流れが最も理解しやすいです。

localは自由度が高い反面、GPU、model download、runtime、licenseまで自分で管理します。

「無料だからlocal」ではなく、controlが必要かどうかで選ぶのが本質です。