透過PNGを作る人は、Qwen-Image-2.1の「背景まで生成しなくていい」を見ておいてほしい。
画像を生成して、背景を消して、髪や輪郭を直す。その工程を、最初から透明度を持つ画像の生成にまとめる選択肢が出てきた。
Qwenが2026年9月20日に公開したQwen-Image-2.1は、画像生成部分が7B、約70億パラメータ。しかも、次の3つを同じモデルで扱う。
- RGBと透明度を持つRGBA画像を生成する。
- 最大10枚の参照画像を使って編集する。
- テキストと参照画像の計算を、複数のノイズ除去ステップで再利用する。
それが今回のQwen-Image-2.1だ。決定的なのは、公開VAE設定にあるこの2行である。
"in_channels": 4,
"out_channels": 4
透明っぽい背景を描く話ではない。画像表現そのものに、4番目のチャンネルがある。
ただし、ここで「商品写真の背景削除も全部これでいい」と飛びつくと、別の問題にぶつかる。欲しいのは、新しい絵なのか。それとも、元の写真の色を残した切り抜きなのか。

色・透明度・輪郭の違いを表すAI生成イラスト。Qwen-Image-2.1の生成結果や性能実証ではない。
確認日は2026年10月7日、主題の公開日は17日前の9月20日。仕様値はQwenの公式資料、実装は当日参照したDiffusersソースに基づく。比較対象は既存モデルも含む。コードは構文、算術、簡略化したマスク規則を確認した。GPU推論・Pillow画像処理・画質比較・VRAM計測は未実行だ。
数字で見るQwen-Image-2.1
公式リポジトリの仕様とモデルカードを突き合わせると、導入判断に必要な情報はこうなる。
| 項目 | 公開値・条件 | 実装での意味 |
|---|---|---|
| 画像生成Transformer | 7B | 全コンポーネントの合計ではない |
| Transformerの深さ | 32層 | Single-Stream DiT |
| テキスト・画像条件のエンコーダ | Qwen3-VL 8B | 生成Transformerとは別に読み込む |
| VAEの入出力 | 4チャンネル | RGBとalphaを扱う |
| VAEの潜在表現 | 64チャンネル、空間方向16倍圧縮 | ピクセル空間と潜在空間を区別する |
| 既定の画像サイズ | 2048×2048 | 4,194,304画素。値は縦横から算出 |
| 既定の推論ステップ | 40 | 参照情報を繰り返し使う場面がある |
| 参照画像数 | 最大10枚 | 条件を増やせるが、順序も入力の一部 |
| 公開重みのライセンス | Qwen Research License | Materialsの商用利用は別契約が必要 |
ここまでは「透過画像を作れるモデル」の話。面白いのはその先だ。
何を生成し、何を残すのか。答えは4番目の値にある
透過生成と背景削除は、出力が同じでも処理が違う
1画素の色をRGB、透明度をalphaと呼ぶ。alphaが0なら完全透明、1なら不透明として、背景に重ねる基本形は次のように書ける。
C = alpha * F + (1 - alpha) * B
Fは前景の色、Bは背景の色、Cは合成後の色で、各RGB成分に同じ式を適用する。これは共通の線形色空間で考えた非乗算済みalphaの式であり、PNGのsRGB値にそのまま適用する実装を推奨する式ではない。
QwenのVAE設定は、4チャンネルの入出力と64チャンネルの潜在表現を持つ。つまり、モデルに求めるのは色と透明度を含む画像の生成・編集だ。
一方、BiRefNetの公式例は、推定したマスクを元画像のサイズに戻し、image.putalpha(mask)で付ける。こちらは、読み込んだRGBの値を残して、どこを見せるかを変える処理である。
この差は、商品ラベルの1文字や、印刷物の色を残したいときに効く。
| 一次資料から確認できること | そこから選べる処理 | 保証されていないこと |
|---|---|---|
| QwenのVAEは4チャンネルを入出力する | 新しい色・形・透明度を生成する | 編集前後のRGBが全画素で一致すること |
| BiRefNetの例は元画像にマスクを付ける | 元RGBを保持して前景を切り抜く | 推定境界が常に正しいこと |
| Qwen-Image-Layeredは複数RGBA層を出す | 分解後に要素を別々に動かす | 分解時に元画像の全画素を厳密再現すること |
最後の行はQwen-Image-Layeredの説明に基づく。レイヤー分解後に他の層を触らず編集できることと、分解が元画像を完全保存することは、別の主張だ。
さらに、マスクだけの処理にも限界がある。写真の輪郭には、撮影時の背景色がすでに混ざっている場合がある。そのRGBを厳密に残せば、白い背景の名残も残り得る。RGB保存と、境界の色かぶり除去は、同時に無条件では要求できない。
キャッシュが使えるのは、参照側が「未来」を見ないから
もう1つの仕掛けが、Mixed-Granularity Attentionだ。
Qwenの実装では、トークン列の前方には注意を向けられ、同じ画像ブロック内では双方向に注意を向けられる。テキストは因果的、画像の内部は双方向、ブロック間は順序を持つ。
条件を前、生成対象を後ろに置いた簡略図なら、こうなる。
| Query側 | 先行テキスト | 参照画像A | 後続の参照画像B | 生成対象 |
|---|---|---|---|---|
| 参照画像A | 見る | 内部は双方向 | 見ない | 見ない |
| 参照画像B | 見る | 見る | 内部は双方向 | 見ない |
| 生成対象 | 見る | 見る | 見る | 内部は双方向 |
生成対象が次のステップで変わっても、参照側はそれを見ない。だから参照側の計算を固定しやすい。
ただし、Attentionの向きだけでは足りない。
ノイズ除去モデルには「今どの時刻のノイズを処理しているか」という条件も入る。参照側まで毎回違う時刻で変調したら、そこも毎回変わってしまう。
そこで同じ実装のコメントには、こうある。
Text and condition-image tokens take the
t = 0row
テキストと参照画像には固定のt=0、生成対象には現在の時刻を使う。causal_condition=Trueが、この分離を成立させる。
未実行の概念用疑似コードで表すと、次の形だ。実APIではない。
# 概念用疑似コード・未実行。prefixの計算は各層で行う。
cache = None
for t in denoising_times:
if cache is None:
target, cache = step_with_prefix(
prefix, target, prefix_time=0, target_time=t
)
else:
target = step_with_cached_prefix(target, cache, target_time=t)
40ステップなら、初回に参照側のK/Vを保存し、残る39ステップで再利用する構造になる。ただし、生成対象側のQueryから参照K/Vを見る計算は残る。40回の生成を1回にする仕組みではない。
この設計から、参照画像を多く使う編集はキャッシュの効果を調べる有力な対象だと考えられるが、速度倍率は実測なしには出せない。
今すぐ試すべき2つの生成経路
あなたが欲しいのは、架空の新素材と、既存写真の忠実な切り抜きのどちらだろう。どちらの需要が大きいと思うか、あなたの予想もコメントで教えてほしい。
以下は研究・評価用の試行である。公式Quick StartのAPIとモデルカードの推奨プロンプト形式を使い、題材と保存名を変更した。CUDA環境を想定し、インストールと推論は未実行だ。
python -m pip install 'torch>=2.4.0' 'transformers>=5.17' accelerate pillow
python -m pip install 'git+https://github.com/huggingface/diffusers'
比較実験に進む際は、動作確認したDiffusersのコミットとチェックポイントrevisionを記録すること。上の公式手順は開発版を取得するため、同じコマンドでも将来の中身は変わる。
1. 新規イラストを、最初から透過素材として作る(未実行)
背景を消すことより、背景なしで成立する構図を作ることが目的だ。次をPythonで実行する。
import torch
from diffusers import QwenImage21Pipeline
pipe = QwenImage21Pipeline.from_pretrained(
"Qwen/Qwen-Image-2.1", torch_dtype=torch.bfloat16
)
pipe.enable_model_cpu_offload()
def rgba_request(subject):
return (
"This is an RGBA image with transparency. "
+ subject
+ ". The image has alpha channel and the background is transparent."
)
result = pipe(
prompt=rgba_request("A red origami crane sticker, complete silhouette"),
width=2048,
height=2048,
num_inference_steps=40,
generator=torch.Generator("cuda").manual_seed(42),
)
result.images[0].save("new_asset.png")
メモリ配置は公式のCPU offload例を採用した。CPU側への退避を使う構成であり、特定のGPU容量で必ず動くという意味ではない。
2. 参照画像の見た目を変え、透過素材として出す(未実行)
たとえば、自分が利用できる参照イラストを、別の質感の素材に展開する。上と同じPythonセッションで、公式の画像編集APIにimageを渡す。
from PIL import Image
reference = Image.open("reference.png")
edited = pipe(
image=reference,
prompt=rgba_request(
"Reimagine the subject from the reference as a felt ornament, "
"keeping its overall silhouette, with no surrounding scene"
),
num_inference_steps=40,
generator=torch.Generator("cuda").manual_seed(42),
)
edited.images[0].save("edited_asset.png")
参照は制作の条件として使う。ここで求めたのは質感の変更なので、RGBが変わることは目的に合っている。逆に、ラベルや図面の元画素を残す仕事なら、後述のマスク方式を先に試す方が要件に合う。
知らないと損する4つの罠
罠1:重みが公開されているので、そのまま商用工程に入れる
LICENSEの1(i)は、Non-Commercialを次のように定義している。
"Non-Commercial" shall mean for research or evaluation purposes only.
2(a)の利用許諾はこの範囲に限られ、2(b)はMaterialsの商用利用に別ライセンスを求める。無償でダウンロードできることだけでは、業務投入の条件を満たさない。
対策:評価と商用導入を分け、使う重みのLICENSEを確認すること。
ここで述べているのはモデル等のMaterialsの利用条件であり、生成物の所有権やあらゆる出力利用を一律に判定したものではない。
罠2:7Bだから14GBあれば全部載る
Architecture欄は、7Bの生成Transformerとは別にQwen3-VL 8Bを挙げている。
7Bを1パラメータ2 byteで単純計算すると、7×10^9×2 = 14×10^9 byte、約13.0 GiBだ。これは丸めた7Bから計算した生成Transformerの重み相当量だけである。
テキストエンコーダ、VAE、活性値、Attention用バッファ、キャッシュを足していない。配布サイズや実際のピークVRAMとも一致するとは限らない。
対策:7Bを購入GPUの容量表に直接変換せず、全コンポーネントと解像度を含むピークメモリで判断すること。
罠3:RGBAに変換できたので、透過生成は成功した
Pillowのconvertとputalphaの仕様を読むと、チャンネルを付ける操作と、その値を検証する操作は分かれている。
RGB画像をconvert("RGBA")しただけなら、全画素が不透明でもRGBAになる。PNG拡張子やチェッカーボード風の絵も、透明度の証拠にはならない。
対策:変換前の出力を調べ、alphaの分布と合成結果の両方を確認すること。
次は8bit RGBA出力専用の検査例だ。Pillowの公式APIに基づく独自コードで、未実行である。alpha_audit.pyとして保存し、python alpha_audit.py new_asset.pngで使う。
import json
import sys
from pathlib import Path
from PIL import Image
path = Path(sys.argv[1])
with Image.open(path) as source:
if source.mode != "RGBA":
raise SystemExit(f"RGBA専用検査の対象外: {source.mode}")
image = source.copy()
hist = image.getchannel("A").histogram()
pixels = image.width * image.height
used = [value for value, count in enumerate(hist) if count]
print(json.dumps({
"alpha_min": min(used),
"alpha_max": max(used),
"transparent_fraction": hist[0] / pixels,
"partial_fraction": sum(hist[1:255]) / pixels,
"opaque_fraction": hist[255] / pixels,
}, indent=2))
for name, color in [("white", "white"), ("black", "black")]:
background = Image.new("RGBA", image.size, color)
composite = Image.alpha_composite(background, image).convert("RGB")
composite.save(path.with_name(f"{path.stem}-on-{name}.png"))
これは合格判定器ではない。完全透明画素が1つあっても、残りの背景が消えているとは限らない。逆に、素材の意図によっては半透明ばかりでも正しい。
白と黒の両背景に重ねれば、片方だけでは見落とす輪郭の白残りや暗い縁を調べられる。この合成は輪郭点検用の簡易プレビューであり、sRGBの線形化や色管理の検証は含まない。パレット透過PNGなどはこのコードの対象外であり、エラーは「透過していない」という判定ではない。
罠4:別のモデルで使っていたCFG設定を、そのまま移植する
DiffusersのQwen-Image-2.1用ドキュメントでは、既定は40ステップ、guidanceなしである。negative_promptとtrue_cfg_scale > 1を指定するとCFGが有効になり、1ステップあたりの仕事が倍になる。
キャッシュがあるからといって、この追加処理まで消えるわけではない。生成の所要時間が必ず2倍になるという意味でもないが、既定条件とは違う実験になる。
対策:最初は推奨既定値で比較し、CFGを追加した場合は画質と時間の差をセットで記録すること。
透過素材を作る4候補。選ぶ軸は「何を残したいか」
以下は2026年10月7日に、Qwen-Image-2.1、Qwen-Image-Layered、BiRefNet、RMBG-2.0の公式資料から組み立てた比較だ。処理方式と利用条件の比較であり、同条件の画質ランキングではない。
| 候補 | 主な入力と出力 | 元RGBを残す要件 | 公開重みの利用条件 | 選ぶ場面 |
|---|---|---|---|---|
| Qwen-Image-2.1 | 指示・任意の参照画像 → 生成・編集画像 | 厳密保存を前提にしない | Research License。商用は別ライセンス | 新規透過素材、質感や構図の変更 |
| Qwen-Image-Layered | 画像 → 複数RGBAレイヤー | 分解時の厳密保存は前提にしない | Apache-2.0 | 要素を分けて移動・再配置する |
| BiRefNet | 画像 → 前景マスク | 公式例のputalpha処理なら元RGBを保持 |
MIT | 写真を描き直さず、マスクで切り抜く基準案 |
| BRIA RMBG-2.0 | 画像 → 1チャンネルのalpha matte | 同じく元画像へのマスク付与が可能 | CC BY-NC 4.0。商用は別契約 | BRIAの学習モデル・提供条件で背景除去を評価する |
表から読み取れること:
- 新規素材なら、色とalphaを一緒に生成できる点が価値になる。 元RGBを残す必要がないからだ。
- 既存商品の忠実な切り抜きなら、マスク方式から比較できる。 ただし輪郭の誤りや背景色の混入は別に評価する。
- Qwenという名前だけでライセンスを横展開できない。 Image-2.1とImage-Layeredでも条件が違う。
- RMBG-2.0とBiRefNetは、完全に独立した方式ではない。 BRIAはBiRefNetアーキテクチャを利用しており、モデルと学習の違いを比較する組み合わせである。
最後の選択をコードに落とすなら、まず要求を固定する。以下はアプリ側で使うための独自の設定例であり、各ライブラリに直接渡す設定ではない。
{
"purpose": "evaluate_photo_cutout",
"model_id": "ZhengPeng7/BiRefNet",
"preserve_decoded_rgb": true,
"allow_foreground_color_correction": false,
"output_format": "PNG",
"review_backgrounds": ["white", "black"]
}
preserve_decoded_rgbは、画像ファイルをデコードした後のRGB配列を残すという意味だ。元のJPEGバイト列、EXIF、色管理情報の保存まで含めない。
マスク推定後の処理は、公式例のputalphaを使って次のように書ける。未実行であり、mask.pngは別途推定済みの同サイズのグレースケール画像とする。
from PIL import Image
original = Image.open("input.png").convert("RGB")
mask = Image.open("mask.png").convert("L")
if mask.size != original.size:
raise ValueError("元画像とマスクの座標・サイズを一致させること")
cutout = original.copy()
cutout.putalpha(mask)
assert cutout.convert("RGB").tobytes() == original.tobytes()
cutout.save("cutout.png")
このassertが確かめるのはRGBの保存だけだ。マスクの正解率ではない。色かぶりを消したくなったら、前景色補正を許可するかどうかを改めて決める必要がある。
教訓:透過PNGは、要件の名前として粗すぎる
✗ "透過PNGが出れば同じ処理" → 色を生成する方式と、元RGBにマスクを付ける方式がある
✗ "7Bなら14GBで全部動く" → その計算は生成Transformerの重み相当量だけだ
✗ "40ステップをキャッシュで1回にできる" → 更新する生成対象の計算は残る
✗ "RGBA変換に成功したから切り抜けた" → alphaが全画素255でもRGBAである
✗ "Qwenの重みは全部同じ条件" → チェックポイントごとにライセンスが違う
Qwen-Image-2.1で試したいのは、背景除去ツールを一括で置き換えることではない。これまで「まず背景込みで描く」と決めていた素材制作を、最初から色と透明度を生成する工程に変えられるか、という問いだ。
一方、撮影済み商品の表示や正確な図版の切り抜きでは、変えてはいけない部分を先に決める。その条件さえ決まれば、モデル名で迷う時間は減らせる。今日扱う素材を1つ選び、「新しく描くのか、元のRGBを残すのか」を決めてから試してほしい。
参考資料
Qwen-Image-2.1:公式リポジトリ、Quick Start、Architecture
https://github.com/QwenLM/Qwen-Image-2.1
Qwen-Image-2.1:公式モデルカード
https://huggingface.co/Qwen/Qwen-Image-2.1
Qwen-Image-2.1:VAE設定
https://huggingface.co/Qwen/Qwen-Image-2.1/raw/main/vae/config.json
Qwen Research License Agreement(2026年9月20日)
https://github.com/QwenLM/Qwen-Image-2.1/blob/main/LICENSE
Diffusers:Qwen-Image-2.1 Transformer実装
https://raw.githubusercontent.com/huggingface/diffusers/main/src/diffusers/models/transformers/transformer_qwenimage21.py
Diffusers:Qwen-Image-2.1 Pipelineドキュメント
https://raw.githubusercontent.com/huggingface/diffusers/main/docs/source/en/api/pipelines/qwenimage21.md
Qwen-Image-Layered:公式モデルカード
https://huggingface.co/Qwen/Qwen-Image-Layered
BiRefNet:公式モデルカード
https://huggingface.co/ZhengPeng7/BiRefNet
BRIA RMBG-2.0:公式モデルカード
https://huggingface.co/briaai/RMBG-2.0
Pillow:Imageモジュール公式リファレンス
https://pillow.readthedocs.io/en/stable/reference/Image.html
透過素材の生成や商品画像の切り抜きを担当する人は、いいねと保存を。モデルを選んでいるチームにも、この4候補の比較をシェアしてほしい。
コメントで教えてほしい。
- 欲しいのは「新しい透過素材」と「元写真の忠実な切り抜き」、どちら?
- 背景除去で一番困るのは、髪・商品ラベル・ガラスのどれ?
- 生成とマスク推定を、用途別に分けて使う?