開発者向け FLUX 3：本番運用の画像ワークフロー

現時点でFLUX 3をリリースするなら、まず安全なキー、非同期ジョブの制御、高速なアセット保存という三つに注力します。 これが本ガイドの中心です。生成・編集ジョブの送信方法、タスク状態のポーリング方法、単一画像編集・bbox による部分編集・複数画像参照の扱い方、リリース前の確認事項を説明します。APIMart では FLUX 3 Image API をすぐに試せます。

要点を先にまとめます。

• FLUX 3は生成と編集の両方を一つの画像ワークフローで処理します。
• ジョブは非同期で実行されるため、ジョブを送信して task_id を保存し、ステータスが completed か failed になるまで /v1/tasks/{task_id} をポーリングします。
• APIMartの生成結果は72時間保存されます。
• 再試行ルールは重要です。429と5xxはバックオフして再試行し、400、401、402は問題を修正してから再実行します。
• 解像度が待ち時間とコストを左右します。4k は数分かかることがあり、ドキュメントでは合計 10 分の待機タイムアウトが推奨されています。
• ソース画像は公開 URL として image_urls に渡します。Base64 も使えますが、ペイロードが約 33% 増えます。
• 2026年10月時点の通常料金では、FLUX 3 Imageは1kが1枚$0.048、4kが$0.607で、料金は約12.6倍になります。 FLUX 3 Image
• リリース時には、キュー、レート制限、ログ、安全性レビュー、USD建ての支出追跡を確認します。

最も重要な点だけをまとめると、_FLUX 3は単発のAPI呼び出しではなく、ジョブ、ファイル、再試行、コストを管理する整ったパイプラインを構築することが重要_です。

クイック比較

この記事では、デモ出力だけでなく、リリースに必要なリクエストフロー、編集コントロール、本番設定、コスト上の注意点に焦点を絞っています。

要点まとめ

• FLUX 3 Image は、テキストから画像、単一画像編集、最大 10 枚の複数画像参照、プロンプト内に bbox を書く部分編集を、一つの非同期エンドポイントで処理します。mask パラメーターも strength パラメーターもありません。
• ジョブは「POST が task_id を返す」流れです。/v1/tasks/{task_id} をポーリングし、ステータスが completed か failed になったら停止します。4k は数分かかることがあり、ドキュメントでは合計 10 分の待機タイムアウトが推奨されています。
• 429 と 5xx のレスポンスは指数バックオフで再試行し、400、401、402 のエラーは再試行前に修正する。再試行前に task_id を永続化して、課金対象の重複ジョブを作らないようにする。
• APIMartの生成結果は72時間保存されます。
• 2026年10月時点の通常料金では、FLUX 3 Imageは1kが1枚$0.048、4kが$0.607で、料金は約12.6倍になります。 一つのAPIMart APIキーで、複数の提供元のモデルを呼び出せます。

FLUX 3 の概要

FLUX 3ワークフローの動画概要

FLUX 3ワークフロー：認証、リクエスト、ジョブ処理

安定したFLUX 3統合には、安全なキー、一時的な画像URL、非同期ジョブ処理という三つの要素が必要です。

APIキーと安全な設定を準備する

ソースコードにAPIキーをハードコードしないでください。サーバー側のシークレットマネージャーに保存し、クライアントコードや公開リポジトリへ公開しないでください。キーが漏えいした場合は、APIMartダッシュボードからすぐにローテーションします。

キーローテーションは緊急事態ではなく、通常の保守として扱うことが有効です。この考え方により設定を整理し、問題が拡大する前にリスクを減らせます。

安全な認証情報、予測可能なリクエスト処理、信頼性の高いジョブ管理は、本番環境に耐えられる画像機能をリリースするための基盤です。

Prompt-to-imageリクエストを構築し、レスポンスを処理する

基本的なFLUX 3画像生成リクエストには、次の情報が必要です。

• モデルID
• テキストプロンプト
• サイズまたはアスペクト比

APIMartの生成結果は72時間保存されます。完了後は速やかにダウンロードし、長期利用する画像は自分のS3などのストレージへ移してください。

長時間ジョブのポーリング、再試行、エラーを処理する

画像生成は非同期です。POST リクエストでジョブを送信すると task_id が返されます。その後 GET /v1/tasks/{task_id} をポーリングし、ステータスが completed か failed になったら停止します。ドキュメントにポーリング間隔の指定はないため、数秒間隔から始めて徐々に間隔を延ばしてください。

待機の上限は解像度ごとに設定します。4k は数分かかることがあり、ドキュメントでは合計 10 分の待機タイムアウトが推奨されています。低い解像度ならより短い上限で構いません。上限に達しても、クライアントが待つのをやめるだけで、ジョブが失敗したわけではありません。失敗はステータスが failed を返したときだけです。task_id を保存しておけば後から再確認でき、重複ジョブを送らずに済みます。

再試行には状況に応じた判断が必要です。すべてのエラーを同じように扱うべきではありません。

• 429と5xxのレスポンスでは、指数バックオフを実行して再試行します。
• 400、401、402エラーは、不正なパラメータ、APIキーの欠落や無効化、残高不足など、リクエスト自体の問題を示します。

リクエストが壊れている場合、原因を修正せずに再試行してもクレジットと時間を無駄にするだけです。課金対象のジョブが重複しないよう、再試行前にtask_idを永続化してください。

このリトライのルールは、テキストから画像、単一画像編集、部分編集のいずれでも同じです。

ワークフローの違いは主にリクエストの中身です。いずれも同じエンドポイントとモデルを使い、resolution に応じて課金されます。

このモデルのドキュメントには Webhook も callback_url もないため、本番環境ではポーリングを自前で管理する必要があります。キューで同時実行数を制御し、各 task_id のステータスを記録してください。

リクエスト処理が安定したら、次はソース画像と編集指示をモデルにどう渡すかを決めます。

FLUX 3 の画像編集ワークフロー：単一画像編集、部分編集、複数画像参照

ジョブ送信とリトライの準備ができたら、次の判断はシンプルです。ソース画像をどこまで残し、どこを変えるか。FLUX 3 Image の編集はすべて image_urls とプロンプトで行い、主なパターンは単一画像編集、bbox による部分編集、複数画像参照の三つです。

単一画像編集で視覚的な変更をコントロールする

image_urls にソース画像を 1 枚渡し、何を変えて何を残すかをプロンプトで指示します。このモデルには strength のような強度パラメーターがないため、変更の度合いはプロンプトでしか調整できません。aspect_ratio が auto の場合、出力は 1 枚目の参照画像のアスペクト比に従います。

商品バリエーション、広告の更新、ブランドのスタイル変更に適しています。変更してはいけない部分を明確に指定してください。曖昧なままにすると、モデルがソース画像から離れてしまう可能性があります。実用例として、新しい撮影を行わず、同じ基本写真を季節ごとのバリエーションへ再利用できます。

ソース画像には公開アクセス可能な HTTP(S) URL か Base64 を使えます。Base64 はペイロードが約 33% 増えるため、通常は CDN などの公開 URL のほうが適しています。

bbox で部分編集の領域を指定する

このモデルには mask パラメーターがなく、mask_url を送ると HTTP 400 が返ります。特定の領域だけを変えたい場合は、プロンプト内で <car_1> のようなタグで要素を指し、同じ文字列の末尾に bbox の JSON 配列を付けます。ボックスは [top, left, bottom, right] 形式で、ピクセルではなく 0〜1000 の正規化グリッド上の値です。tgt_bbox が src_bbox と同じなら要素はその位置に残り、異なるボックスを指定すると移動します。次の例は、囲んだ車を赤くし、背景を維持します。

{
  "model": "flux-3-image",
  "prompt": "In <ref_image_0>, make the car <car_1> red and preserve the background <background_1>. [{\"id\":\"car_1\",\"from\":null,\"src_bbox\":null,\"tgt_bbox\":[250,300,750,800],\"desc\":\"A red car, preserving its original shape and orientation.\"},{\"id\":\"background_1\",\"from\":\"ref_image_0\",\"src_bbox\":[0,0,1000,1000],\"tgt_bbox\":[0,0,1000,1000],\"desc\":\"Preserve the original road, background, and lighting.\"}]",
  "image_urls": [
    "https://example.com/car.jpg"
  ],
  "aspect_ratio": "auto",
  "resolution": "2k"
}

アウトペインティング専用のパラメーターはありません。複数画像参照では、画像は順に ref_image_0、ref_image_1 と番号が振られ、プロンプトで Image 1 / Image 2 と書くこともできます（例：「Turn Image 1 into the style of Image 2.」）。

プレビューにはresolution: "768sq"を使い、納品時は1k、1.5k、2k、4kから選びます。これは解像度の区分であり、width/heightのピクセル指定ではありません。4kは約16 MP、2kは約4 MPです。 FLUX 3 Image

編集ステップを再現可能なパイプラインへ連結する

簡単な構成方法は次のとおりです。

• 単一画像編集でスタイルや細部を調整する
• bbox 部分編集で特定の要素を変更・移動する
• 複数画像参照で被写体とスタイルを組み合わせる
• 各ステップを中間アセットとして保存

アップロード前に、ブラウザの canvas 書き出しや余分な再圧縮は避け、ディテールの劣化を防いでください。元のファイルをそのまま渡します。

編集ステップが安定したら、次の課題は、それらをアクセス制御とコスト追跡を備えた一つのプロダクトワークフローへまとめることです。

APIMart経由でFLUX 3を利用し、製品統合とコストを管理する

編集ステップを再現可能にしたら、APIMartを本番利用の制御レイヤーとして中央に配置できます。スタックの各部分を個別に接続する代わりに、編集パイプラインを一つのAPIレイヤーへルーティングし、アクセス、支出、下流の自動化を管理します。

FLUX 3を統合APIワークフローへ接続する

すでにOpenAI-形式のクライアントを使用している場合、通常は簡単に設定できます。多くの場合、新しいベースURLへ切り替え、APIキーを追加し、リクエストのモデルIDにFLUX 3を指定するだけです。

同じリクエスト構造、解析、再試行ルール、非同期ロジックを維持できる点が便利です。FLUX 3のジョブは、APIMart全体でPOSTからtask_idを取得し、GETでポーリングする同じフローに従います。そのため、既存のジョブ処理コードは、一回の画像生成でも、フルパイプラインで複数の編集ステップを連結する場合でも、そのまま利用できます。一つのAPIMart APIキーで複数のモデルとプロジェクトを扱うこともできます。

利用量、予算、チームの作業量をUSDで追跡する

APIMartのダッシュボードは、モデルとプロジェクトを横断して利用量を集計し、コストをUSDで表示します。どのワークフローが本番投入の準備を終え、どのワークフローにまだ調整が必要かを判断しやすくなります。

たとえば、カタログ生成プロジェクトに月間上限を設定し、支出が上限に達する前にアラートしきい値を設定できます。コストが制御不能になる前に、チームがバッチジョブを遅くしたり一時停止したりできます。

2026年10月時点の通常料金では、FLUX 3 Imageは1kが1枚$0.048、4kが$0.607で、料金は約12.6倍になります。 以下は2026年10月時点の通常料金で、単位は米ドル/枚です。参照画像の追加料金はありません。最新料金はFLUX 3 Imageの料金表をご確認ください。

FLUX 3画像生成を幅広いマルチモーダルワークフローと組み合わせる

FLUX 3をコンテンツ制作の画像生成工程として使い、文章作成、画像理解、タグ付けなどと組み合わせられます。APIMartでは一つのAPIキーで複数の提供元のモデルを呼び出せます。 APIMart

ロールベースの権限を設定し、分析アクセスを必要な担当者に提供する一方、キー管理を承認済みのエンジニアに限定することもできます。

この構成により、スケーリング、レート制限、ログ記録が日常運用の次のレイヤーになります。

本番デプロイ：スケーリング、可観測性、展開判断

キュー、同時実行数、レート制限を計画する

生成と編集が安定すると、本番環境では別の課題が生まれます。この段階では、単一リクエストを動かすことより、システムを破綻させずにトラフィックを処理することが重要です。

画像生成の需要は急増する可能性があります。そのため、すべてのリクエストをインラインで処理すべきではありません。キューによって余裕を確保できます。リクエストの受付と実行を分離し、急激なトラフィックがワーカーへ一度に集中するのを防ぎます。

同時実行数をレート制限に合わせることも重要です。簡単な方法は、キューとモデルごとの同時実行上限を組み合わせることです。プロバイダーの制限を超えずに、急増を吸収できます。

デバッグと再現性に必要なデータを記録する

実行ごとに出力が変わる場合、適切なフィールドを記録していないとデバッグがすぐに複雑になります。

再現性とトラブルシューティングのために、リクエストID、タスクID、プロンプト、生成メタデータを記録します。何が起きたかを追跡し、必要に応じて後からジョブを再実行するのに十分な情報が得られます。ログの詳細度は環境にも合わせてください。ステージングと本番のログは、必要以上のペイロードデータを公開せず、役立つ内容を維持する必要があります。

ジョブごとの解像度と推定コストも記録するとよいでしょう。高額な外れ値が予想外の請求になる前に発見しやすくなります。

まとめ：リリース前に画像機能向けFLUX 3を評価する方法

FLUX 3を本番へ移行する前に、以下の環境で異なるアクセス、ログ、レビュールールを使い、設定を検証します。

次の表を使ってリリース準備状況を確認してください。

信頼性は、実際の負荷試験、監視、復旧手順を基に設計してください。公開前に、急増するリクエストへの対応、ログのリクエストIDとタスクID、レート制限、安全対策、解像度別の費用追跡を確認します。

これらの制御が負荷テストに合格すれば、FLUX 3は本番投入の準備が整っています。

モデルの全体像は「FLUX 3 解説：モデル構成・提供状況・料金」で詳しく解説しています。

よくある質問

FLUX 3 のジョブはどのくらいポーリングすべきですか？

ステータスが completed か failed になるまで GET /v1/tasks/{task_id} をポーリングします。このモデルのドキュメントには Webhook も callback_url もないため、結果はポーリングで取得します。

待機の上限は解像度ごとに設定します。4k は数分かかることがあり、ドキュメントでは合計 10 分の待機タイムアウトが推奨されています。上限に達するとクライアントは待機をやめますが、ジョブが失敗したとは限りません。task_id を保存して後から再確認できるようにしてください。

本番環境でFLUX 3画像を保存するにはどうすればよいですか？

APIMartの生成結果は72時間保存されます。完了後は速やかにダウンロードし、長期利用する画像は自分のS3などのストレージへ移してください。

非同期ワークフローを使用します。ジョブが完了するまでtask_idをポーリングし、ファイルを永続インフラへ保存します。task_id、タイムスタンプ、内部ファイルパスを含むデータベースログを保持すると、明確な監査証跡も得られます。

編集に最適なFLUX 3ワークフローは何ですか？

既存画像から始め、変更したい箇所だけに絞ったプロンプトを適用する画像編集ワークフローを使用します。必要に応じて他言語のテキストも含めながら、画像の残りのレイアウトを維持できます。

本番利用では、非同期APIパイプラインとして構成します。POSTリクエストで編集を開始し、task_idを受け取ったら、completed か failed になるまでジョブをポーリングします。完成した画像URLが返されたら、有効期限が切れる前に独自ストレージへ保存してください。

重要な基本ルールは次のとおりです。

• APIキーはバックエンドだけに保存する
• リクエスト送信前に入力を検証する
• APIMartの生成結果は72時間保存されます。

この構成によりワークフローを整理し、トラフィックの増加後に回避可能なエラーが起きるのを防げます。