「MOSS-Image vs FLUX 3」という見出しのヒーローカード。サブタイトルは「プロンプトにバウンディングボックスを配置する2つの方法」。MOSS-Imageのカードには、summary、items、bboxという行を含む小さなJSONレイアウトブロックが表示され、その下に「絶対座標・中央揃え」とラベル付けされた長方形の輪郭がある。FLUX 3のカードには、「オブジェクトを画像内に配置する」「左上に」「指定されたテキストで」というプロンプト文が表示され、その下に「0~1000」とラベル付けされた正方形グリッドがある。リボンには「どちらも座標でオブジェクトを配置する」と書かれている。
Guides & Insights

MOSS-Image 対 FLUX 3:プロンプトにバウンディングボックスを配置する2つの方法

著者

Alistair Wren

公開日

最新モデル · 20すべてのモデルを見る →
ベンチマーク:Artificial Analysis · 毎日更新
すべての記事に戻る

を比較して最も興味深いのはMOSS-ImageとFLUX 3、両者がこの1か月のうちに同じ結論に達したことだ — 画像モデルを制御する方法はプロンプトに座標を書き込むことだ、という結論に — それでいて座標系については意見が分かれたのだ。2026年10月16日、OpenMOSSはMOSS-Image-BaseとMOSS-Image-SFTをApache 2.0の下で公開した。ダウンロード可能な5Bの拡散トランスフォーマーで、JSONレイアウト形式はキャンバスの中心から測定した絶対ピクセルオフセットで要素を配置する。Black Forest LabsはFlux 3 Imageで先んじていた。10月1日から稼働し、料金表も公開されており、あらゆるボックスを固定グリッドに対する[top, left, bottom, right]として0から1000の整数で扱う。同じアイデア、互換性のない文法、そして手元に残せるファイルを提供するのは2つのうち片方だけだ。

その違い——画質ではなく——こそが、ほとんどのチームにとってこの対戦の勝敗を決めるものであり、どんなベンチマークよりも速く決める。だから以下の比較は、それを軸に構成されている。MOSS-Image の数値はすべて OpenMOSS 自身のもので、リリースとその技術レポートから取られたものであり、そのどれも誰によっても再現されていない。Flux 3 の数値はすべて、Black Forest Labs 自身が公表した料金表とリリース資料によるものである。これら2つのモデルの間には独立した直接対決は存在せず、しばらくは実現しないだろう。

各陣営が実際に出荷したもの

M​OSS-Image は 2 つのチェックポイント、M​OSS-Image-Base と M​OSS-Image-SFT のペアであり、重みと推論コードは Apache 2.0 の下で公開され、ModelScope ミラー、Gradio Space、Diffusers カスタムパイプライン、ネイティブ ComfyUI プラグインも用意されています。ComfyUI のコアサポートは、重みが公開されたその日に追加されました。OpenMOSS によるホスト型エンドポイントも公開価格もありません。価格を設定する対象が存在しないからです — 使うか使わないか、それだけです。

Flux 3は正反対の形をしている。Black Forest Labsは2026年7月、動画・画像・音声を横断して学習された単一アーキテクチャとしてこれを発表し、静止画向けの階層であるFlux 3 Imageは10月1日に、公開された従量課金制の価格設定で提供を開始した。オープンウェイト版のFLUX 3 Image Kleinは10月15日に続き、FLUX Kommunity Licenseの下で公開された。このライセンスが無償の商用利用を認めるのは、売上高が一定の上限を下回る場合に限られる。つまりBFLは現在、レンタルの道とダウンロードの道の両方を提供しているが、両者は異なるモデルでライセンスも異なり、ダウンロードできるのは旗艦モデルではなく下位の兄弟モデルだということになる。

どちらのモデルも当社自身のカタログにはありません。OrcaRouterは200を超えるモデルを提供していますが、M​OSS-Imageはそのうちの一つではないため、ここにある内容を当社がそれを提供していると解釈すべきではありません — F​lux 3についても同様です。この比較でルーターが役立つのは、ループのもう半分です。つまり、セルフホストのチェックポイントを同じプロンプトでホスト型画像モデルと比較したいとき、ホスト側には1つのAPIキーでアクセスでき、プロバイダーの定価で、当社側でマークアップは一切加算されず、プロバイダー間の自動フェイルオーバーにより、実行中にどれかが劣化した場合にも対応できます。

ボックスの文法を並べて

ここで両者は、設定ファイルが感知できる形で分岐する。

• 座標空間 — MOSS-Image: キャンバスの中心から測定された絶対ピクセル。次を使用: bbox_coord_space: "abs_centralized"。したがって、1024×1024 のキャンバスでは各軸は −512 から +512 の範囲になります。Flux 3 Image: 左上隅から測定された 0~1000 の正規化された整数。

• 座標の順序 — MOSS-Image: bbox_format: "yxyx"、つまり [y_min, x_min, y_max, x_max]。Flux 3 Image: [top, left, bottom, right]。これは同じ4つの数値を、同じ順序のまま別の名前で表したものです。

• モデルにどのように渡されるか — M​OSS-Image: プロンプト文字列として渡される1つのJSONオブジェクトで、summaryブロック(シーンとスタイル用)とitems配列を伴い、各要素はラベルとキャプションを持ち、テキスト要素の場合はレンダリングするリテラル文字列を持ちます。F​lux 3 Image: 通常のプロンプトに書き込まれるボックスのJSON配列で、追加パラメータは不要です。

• 解像度結合 — MOSS-Image の座標はピクセルなので、指定した幅と高さでのみ正しくなります。出力サイズを変更すると、すべてのボックスを再計算することになります。Flux 3 の 0–1000 グリッドは、仕組み上、解像度に依存しません:[0, 0, 500, 500]は、要求したキャンバスが何であっても、その左上4分の1です。

• ボックスの用途 — MOSS-Image はまず生成コントロールとして提示されており、ベンダーは、要素のキャプションを編集したりそのボックスを移動したりすると構図のその部分が調整されると述べており、これは実験的だと説明されている。Flux 3 Image は、レイアウトとボックス単位のマルチターン編集を目玉機能として組み合わせている。

最後の箇条書きが実用上の分かれ目だ。Flux 3のグリッドは出力解像度を変更しても維持されるが、MOSS-Imageのグリッドは維持されない。ただしMOSS-Imageでは、テキスト要素内にレンダリングしたい正確な文字列を、説明するのではなく指定できる。パイプラインが異なるサイズで再レンダリングするなら、グリッドは確かな利点だ。パイプラインが固定寸法と特定のコピーでポスターをレンダリングするなら、絶対ピクセルは負担にはならない。

テキストレンダリング——そこにある数字はベンダーのものだけだ

M​OSS-Imageの最大の特徴は判読可能なテキストであり、ベンダーはそれを測定するために2つのベンチマークを構築した。Long​LongTextBenchでは——平均目標長が約1,340文字の240の文学テキストレンダリングタスク——M​OSS-ImageはMean​-6テキストカバレッジで96.3を記録し、Q​wen-Image-2512の64.9に対して対照的である。同じ表のその上の行はGPT Image 2が99.0、N​ano Banana Proが96.6であり、注目に値する。Open​MOSSは競合他社が依然として勝つ表を公開したのだ。

Black Forest LabsはF​lux 3 Image向けのテキストレンダリングベンチマークを一切公開していない。96.3の隣に並べる数字はどちら側にも存在せず、サンプル画像から比較をでっち上げるのは、このブログがすべきではない類のことだ。言えるのは、FLUX.2のVAEはM​OSS-Imageが使っているものだということだ — M​OSS-Image自身のモデルカードには、FLUX.2 small decoderを読み込むと記されている — そのため、生成器が無関係であっても、この2つのファミリーはピクセルレベルでは無縁ではない。

A two-column scoreboard headed 'MOSS-Image vs FLUX 3 Image - the scoreboard'. Left column MOSS-Image: coordinates are pixels from the canvas centre; box order yxyx; resolution coupling means re-deriving every box; text control is an exact string per element; licence Apache 2.0 with no ceiling; price is none, you run it. Right column FLUX 3 Image: coordinates 0-1000 from the top left; box order top, left, bottom, right; the grid is size-independent; no published text benchmark; pay-as-you-go API; from 0.041 US dollars per image.

コスト:1つの数値 対 5つ

• M​OSS-Image — 無料でダウンロード可能、Apache 2.0、収益しきい値なし、商用ティアなし。コストはハードウェアにあります。SFTリポジトリは合計約27.2 GBで、そのうち4つのシャードにまたがる約16.8 GBが凍結されたQwen3.5-9Bテキストエンコーダー、3つにまたがる約10.2 GBがトランスフォーマーです。予算を組むべきはバッジではなくエンコーダーです。

• F​lux 3 Image — 768×768で$0.041、約1メガピクセルで$0.048、1.5Kで$0.07、2Kで$0.10、4Kで$0.607(画像1枚あたり、Black Forest Labs自身の料金表による)。50%のローンチ割引は10月1日から10月8日まで実施され、すでに終了しています。そのため、それに基づいて構築されたコストモデルには、通常料金での2行目が必要です。

• FLUX 3 Image Klein — 768×768で$0.008、4Kでは$0.036に上がり、テキストから画像生成と編集のコストは同じ。ライセンスはともかく、手間の面では競合する5Bダウンロードより劇的に安い。

正直に言えば、これらは同じ購入ではありません。M​OSS-Image はお金を GPU 時間とエンジニアリングに交換し、F​lux 3 Image はお金を、スタックを代わりに運用してくれる誰かに交換するもので、納品された画像ごとに、解像度が上がるにつれて急激に高くなる料金で価格設定されています。

どちらの側も公表していないもの

M​OSS-Image の独立したベンチマークは存在しない。F​lux 3 Image の独立したベンチマークも存在しない——B​FL は、他のどの画像モデルに対しても、ベンダー実施であれそうでなくとも、比較数値を一切示さずに画像ティアを出荷した。どちらのモデルも、誰もが指し示せる中立的なリーダーボードの行を持っていない。比較の両側に証拠がない場合、正しい結論は両者が同じくらい優れているということではない。現時点では判断できないということであり、決着をつける基準は実際に測定できるものでなければならない——ライセンス、フォーマット、自分のハードウェア上でのレイテンシ、そしてボックス文法がすでに持っているコードと一致するかどうか。

それを変えるものが2つある。OpenMOSS以外の誰かによるLongLongTextBenchまたはRealLayoutArenaの独立した実行が、MOSS-Imageの中心的主張を裏付ける最初の実証的証拠となるだろう。BFLグリッド上での第三者によるレイアウト制御の比較は、Flux 3 Imageにとっても同じ役割を果たすだろう。どちらもまだ存在しない。

A screenshot of the Black Forest Labs documentation pricing page, showing credit-based pricing for all FLUX models including FLUX 3, with the line '1 credit equals $0.01 USD' and the note that pricing is per image or per second for video, at the same price for API and Playground.

実際にあなたならどちらを選びますか

成果物がポスター、インフォグラフィック、製品モックアップといった合成ページで、特定のテキストを特定の位置に配置する必要があり、重みを自社インフラ内に置きたいなら、MOSS-Image を選びましょう。Apache 2.0 ライセンスにより商用レビューは短時間で済み、Base チェックポイントは意図的に未蒸留のまま残されて LoRA トレーニングに取り組む余地を与え、JSON レイアウトはベンダーが最も注意深く測定したモデルの部分です。エンコーダーを予算に組み込み、散文ではなく構造化 JSON を供給することを想定してください。ベンダー自身のアブレーションでは、同じシステム上で JSON レイアウトプロンプトが 1622.87 Elo、自然言語が 1506.20 Elo であり、これは大きな差で、今回のリリースで最も明確なシグナルです。

今日、呼び出し可能なエンドポイントが必要なら、出力の解像度が一定でないなら、あるいは複数ターンにわたるボックス範囲編集を実験的機能ではなくサポート対象の機能として使いたいなら、F​lux 3 Image を選んでください。0–1000 グリッドは解像度非依存で、料金表は公開されており、ライセンス上の上限が許容できるなら、その隣に安価なオープンウェイト版もあります。

注目すべき点は、ボックスの文法です。ツールが最初に採用した規約が、そのまま残ることになります。そして現時点では、この2つの規約に互換性はありません——一方は中心相対の絶対ピクセルを yxyx 順で、もう一方は正規化された左上整数です。小さなアダプター関数が両者を変換します。これが重要なのは、今日完全に知り得るこの比較の唯一の部分だからです。

A screenshot of the OpenMOSS project page for MOSS-Image, headed 'MOSS-Image: Text-to-Image Generation with Native Layout Control', with navigation for Features, Layout Control, Models, Quick Start and GitHub, and an introduction describing a base model and a curated-data fine-tuned model taking objects, rendered text and positions in a JSON prompt from a compact 5B backbone.

このようなリリースの背景にある、文書化されたAI障害やエージェントのインシデントは、OrcaRouter AI Incident Archiveに収集されており、各エントリには独自の情報源、重大度、信頼度グレード、異議申し立てフラグが付いています。