Qwen-Image-2.1 i2i：自分の画像から始める方法と、Strengthスライダーが存在しない理由

もしあなたがQwen-Image-2.1 の i2i を検索したのなら、image-to-image（i2i）が何を意味するかはすでにご存じのはずです。つまり、空の潜在ではなく画像をモデルに渡し、それに似た画像を受け取るということです。このページで決着がつくのは、Qwen-Image-2.1 においてそれが正しい選択になるのはどんなときか、そして他の画像モデルから来た人が驚くそのポイントです。このモデルには、あなたが探している strength スライダーが存在しません。Qwen-Image-2.1 自身のパイプラインは strength や denoise という引数を一切取りません。参照画像はコンテキストとして入力され、ターゲット画像は純粋なノイズから始まり、出力が入力からどれだけ離れるかを決めるのは、あなたが書く内容なのです。もし本当に必要なのが、名指しした一つのものを変え、残りはそのままにしておくことなら、それは別の仕事であり、ファミリー内の別の系統——すなわち Qwen-Image-Edit チェックポイント——が扱います。そしてこのページの比較は、最初に読む価値のある部分です。なぜなら「i2i」で検索する読者は、しばしば間違ったツールまであと検索一回分の距離にいるからです。

入力画像が実際に行うこと

Qwen-Image-2.1 では、条件画像は2つの入口を通ってモデルに入り、そのどちらも「ノイズの乗った初期潜在変数を徐々に弱めていく」というものではありません。このモデル向けに公開されているリポジトリと diffusers のパイプラインクラスは、その両方について説明しています：

• テキストエンコーダー — テキストエンコーダーは Qwen3-VL 8B という視覚言語モデルで、ベンダーのリポジトリによれば、テキスト指示と条件画像を単一の統合表現にエンコードします。あなたの画像は、文字通り、モデルがプロンプトとして読み取る内容の一部なのです。

• VAE — 同じ画像が潜在トークンにエンコードされ、対象画像自身のトークンより前に、ノイズの先頭に付加されます。こうしてトランスフォーマーは、参照画像が先頭にあり、その後に生成対象が続く、単一の連結シーケンスを見ることになります。

• ターゲット開始 — ターゲット潜在変数はガウス分布からサンプリングされ、sigma 1.0 からスケジュール全体にわたってノイズ除去されます。そのパイプラインには部分的なノイズ除去のエントリポイントはありません。

3つ目の箇条書きこそが、ほとんどの人が使ってきたi2iとの決定的な違いだ。古典的な方式では、入力画像をエンコードし、strength値に比例した量のノイズを加え、そこからノイズ除去を行う——つまり入力は開始時の潜在表現に確かに存在しており、strengthの数値がそのどれだけが生き残るかを決める。Qwen-Image-2.1独自の経路では、あなたの画像が出発点になることは決してない。それはコンテキストだ。出力はあなたのファイルをきれいにしたものではなく、そのファイルが部屋の中にある状態で描かれた新しい画像なのだ。

もう一つ知っておく価値のある詳細があります。それは、読者が入力した略語が実際にどこに存在するかに関わるものだからです。diffusers のパイプラインは、事前エンコードされた潜在変数を image として渡そうとすると明示的なエラーを発生させ、「テキストエンコーダーは画像そのものを見る必要がある」というコメントを添えています。条件画像はテンソルではなくピクセルでなければなりません。

強度の調整、そしてそれはどこへ消えたのか

Diffusers はこのファミリー向けの img2img パイプラインを実際に提供しており、その strength 引数は、この分野があなたに期待するよう教えてきたとおりに正確に動作します。クラス自身の docstring から読んでみましょう。画像は「出発点として使われ、strength が高いほどより多くのノイズが加えられる」とあり、「値 1 は image を事実上無視する」と書かれています。デフォルトは strength=0.6 と num_inference_steps=50 です。したがって、両端はあなたがすでに知っている両端です:

• 強度が 0 付近 — ノイズはほとんど追加されず、デノイズループは短く、出力は入力とほとんど区別がつきません。これはカラーグレーディング、軽いテクスチャパス、ほぼコピー向けの設定です。

• Strength が 1 — 加えられるノイズは最大となり、デノイズは全スケジュールを実行し、入力画像は事実上破棄される。高コストな無駄処理が付随した text-to-image である。

ここに落とし穴があります。そしてそれが、このページが存在する理由です。そのパイプラインとともに公開されている例が読み込むのは、このモデルではなく 2025 年のチェックポイントです。Qwen-Image-2.1 には独自のパイプラインクラスがあり、QwenImage21Pipeline、そして次のものはいずれも受け取りません: strength 引数、denoise 引数、そして部分的ノイズのエントリポイントもありません。別のモデルで設定したと記憶している値が何であれ、2.1 の経路にはそれを設定する場所がありません。レバーは数値からプロンプトへと移りました。

それはベンダーが放置した空白ではない。ベンダーは、そのプロンプトを書くことだけを役割とするモデルを出荷している：Qwen-Image-2.1-PE-I2I、曖昧な指示と1つ以上の入力画像を受け取り、JSONオブジェクトを返す、ファインチューニング済みのQwen3.5-VL 9Bチェックポイントである。そのJSONオブジェクトにはrewritten_promptと、相互排他的な2つのフィールドのいずれか一方が含まれる — wh_ratio（リクエストが新しい構図を生成する場合）、またはratio_follow（番号付きの入力画像のアスペクト比を継承すべき場合）だ。このJSONは、Qwen-Image-2.1にとって強度設定に最も近いものだ。これは、あなたのリクエストが入力のフレームを維持するのか、新しく構築するのかをモデルが教えてくれているのだ。ベンダー自身の命名で「i2i」という文字列がどこに現れるかに注目してほしい。それはこのプロンプト書き換え用チェックポイント上であり、独立したimage-to-imageチェックポイント上ではない。2.1世代はそれを公開していない。

i2i または編集：適用するルール

バリエーションが欲しいときはi2iに手を伸ばす。変更を加えたいときは編集に手を伸ばす。それ以外はすべて、この一行から導かれる。

• バリエーション — 画像が気に入って、もっと同じようなものが欲しい。別のカット、違う光、新しい場面での同じキャラクター、新しい設定での同じ製品。ピクセル単位で同一に保たなければならないものを一つも挙げられない。なぜなら、あなたは保存しているのではなく、描き直しているからだ。それがi2iの仕事だ。

• 変更 — それは名指しできる。「キャラクターとポーズはそのままに、このシャツを着せて」 指示は制約であり、フレームの残りはあなたに返ってくるべき約束だ。それは編集の仕事だ。

Qwen-Image-2.1 では、両方の挙動が1つのチェックポイントに同居している。ベンダー自身のリリース資料はこれを「統一的なテキスト画像生成および画像編集モデル」と呼んでおり、そこで文書化されているローカル編集の経路はマスク型だ。領域を丸で囲むか塗る、あるいは元画像と別個のマスクを2つの入力として渡す。2.1世代に同梱されていないのは、別個の編集用チェックポイントだ。

専用の編集チェックポイントは別系統であり、世代も異なります。ベンダー組織自身の Hugging Face 上のモデル一覧を10月13日に確認したところ、その作者の下には9つの画像モデルが掲載されており、その中の編集用エントリは Qwen-Image-Edit（作成: 2025年8月17日）、Qwen-Image-Edit-2509（2025年9月22日）、Qwen-Image-Edit-2511（2025年12月17日）です。いずれも2.1モデルではありません。したがって、「Qwen-Image-Edit 2.1」と書かれたページは慎重に扱ってください。その名前のリポジトリはベンダーの一覧に存在せず、人々が入力する表記 —「qwen image edit 3」「qwen image edit 2512」— も、公開されているベンダーリポジトリとは一致しません。編集系統に関する主張が何であれ、それに基づいて行動する前に、どの世代についてのものかを確認してください。この系統は日付付きの3世代にまたがっており、2.1リリースはそのどれでもないからです。

実際には、このルールは次のように分解できる。指示を対象物を含む文として書けるなら——「空を夕焼けにして」「時計を消して」——それは編集の領域であり、2.1ではツールを切り替えるのではなく、マスクやペイント注釈によってそこに到達する。あなたの文に対象物がなく、次に欲しい画像の説明になっているなら、それはi2iの領域だ。「i2i」と入力したのに、気づけば命令文を書いている読者こそ、編集の道筋を必要としている読者であり、まさにそれが、この節がページ内でこれほど上の位置を占めている理由である。

あなたの入力画像が制約するもの

参照を選んだ瞬間に確定する5つのこと。それらはすべて、パイプライン自身のコード、またはこのモデルに関するComfyUIの公開ドキュメントに記載されています。2026年10月13日閲覧。

• 解像度バジェット — 2.1パイプラインのoutput_resolutionはデフォルトで1024で、すべての条件画像は、それぞれ自身のアスペクト比のままoutput_resolutionの二乗をバジェットとしてリサイズされ、32の倍数に丸められます。したがって、3000×4000の写真は、モデルがその1ピクセルを見る前に、およそ896×1184——約1メガピクセル——まで縮小されます。ComfyUIのドキュメントはそのコストを具体的に示しています。3008×4000のキャンバスでの同じ作業は、およそ896×1184の場合と比べて、RTX 5090で測定すると1イテレーションあたり約6秒対約0.3秒で実行されます。キャンバスを下げるとi2iの実行は速くなりますが、それはディテールが増えるからではなく、より小さな画像が生成されるためです。

• アスペクト比 — 高さと幅を省略した場合、出力キャンバスは、最後に渡した条件画像のアスペクト比から導出されます。個々の参照はそれぞれ自身の形状を保つため、縦長の画像と横長の画像を同じ呼び出しで扱っても、一方がもう一方のフレームに合わせて切り取られることはありません。

• 32の倍数 — 高さまたは幅がVAEスケール係数の2倍（このモデルでは32）で割り切れない場合、パイプラインは警告を発し、暗黙的にリサイズします。キャンバスを手動で選ぶ場合は、その倍数に丸めてください。

• ネイティブサイズ — Qwen-Image-2.1 は 2K で学習されており、リポジトリが推奨するサイズはすべてその範囲内にあります。1:1 なら 2048×2048、16:9 なら 2752×1536、9:16 なら 1536×2752、4:3 なら 2400×1792 です。ComfyUI のドキュメントには、デフォルトのターゲットは 1 メガピクセルであり、ネイティブの 2048×2048 の正方形にはおよそ 4.0 MP を設定すること、そして — これが役立つ警告ですが — 学習時のサイズをはるかに超えるターゲット、たとえば 4K では、ディテールが増えるどころかプロンプトへの追従性が失われると記載されています。

• Alpha — 参照画像に透明度が含まれている場合、ビジョンエンコーダーに渡されるのは白背景に合成されたコピーです。4つのチャンネルすべてを保持しているのはVAE側のコピーだけです。モデルに透過部分を理解してほしいと思っている内容は、テキスト側では白い背景として読み取られています。

生き残るもの、そして新たに生まれ変わるもの

ここは正確に述べてください。なぜなら、リリース資料とメカニズムでは言っていることが異なっており、そしてどちらも真実なのです。

• 存続することが文書化されている — ベンダーは忠実性への取り組みを二つの面で主張している。すなわち、ポートレートの同一性（編集や生成をまたいでも人物が認識可能なままであること）と、製品の一貫性（テキスト、テクスチャ、形状を保持すること）である。これらはいずれも測定値に紐づけられたものではなく、並べて比較した例で示されたベンダーの主張であり、2026年10月13日にこのページのために参照した資料には、そのいずれについても独立したスコアは公表されていなかった。

• ピクセルレベルで保証されるもの — 何もない。あなたの参照はコンテキストトークンとビジョンプレフィックスであり、ターゲットはノイズである。プロンプトが扱わず示唆もしない入力の部分は自由に変化してよく、パイプライン内のどの設定もそれを固定しない。細部を動かしてはならないなら、プロンプト内でそれを明示せよ。他の何もそうしないからである。

• マークが入力に漏れ出す — ComfyUI のドキュメントに記載された編集ワークフローでは、ペイントペンのストロークはマスクではなく画像の RGB レイヤー上に描かれるため、保存するとマーク付きの画像がそのままノードに書き戻され、マークがモデルの参照するリファレンスの一部になってしまいます。変更したい領域の内側にマークを置き、さらにプロンプトでも希望する色を指定してください。そうしないと、マークの色が出力に現れてしまうことがあります。

• キャンバスの不一致は結果をずらす — ComfyUIのドキュメントでは、カスタムキャンバスを最初の参照画像のリサイズ後のサイズに近づけておくよう推奨されています。「そうしないと編集がずれてしまう可能性があります」。要求したキャンバスと形状が異なる入力はレターボックス処理されず、移動されます。

• 決定性には1つではなく2つの設定が必要 — use_kv_cacheを2.1パイプラインで切り替えると、固定シードでもサンプルが変わる。なぜならキャッシュによって、デコードステップがプリフィルステップとは異なるシーケンスレイアウトでアテンションを行うため、この2つは「同等に妥当だが目に見えて異なるサンプルを生成する」。パイプライン自身の助言は、フラグを固定することだ。ComfyUIでは、同等の制御はキャッシュノードの保存精度であり、そこでは — ComfyUI自身の数値で、未監査 — int8はキャッシュを約bf16精度で半減させ、int4はそれを4分の1にする一方、ステップごとの誤差をおよそ2倍にする。

i2i が間違ったツールとなる場面

五つのケース。それぞれに代替案が示されている。

• 変更したい対象を正確に指定できます。 Qwen-Image-2.1 の instruction path を使う — 領域を塗るか丸で囲む、あるいは別のマスクを2つ目の入力として渡す — または Qwen-Image-Edit 系の専用チェックポイントを使います。i2i はターゲットそのものだけでなく、その周囲のフレームも描き直します。

• 元のピクセルを保持しておく必要があります。 i2i は新しい画像を生成し、元のピクセルは一切保持しません。マスクパスは、フレームの残りの部分をそのままにしておくために作られたものです。

• 4Kが必要です。 ComfyUIのドキュメントによると、2Kの学習サイズを超えるとモデルはプロンプトへの追従性を失います。4Kでのi2iは、よりシャープになるのではなく、実行が遅く、あなたの記述に従う度合いが低くなるものです。

• 入力の細かなディテールを忠実に再現する必要があります。 条件画像はまず約100万画素の予算に合わせてリサイズされるため、1200万画素の参照画像がフル解像度のままモデルに届くことはありません。その予算より小さいディテールは、ノイズ除去が始まる前に失われています。

• ビット単位で完全に同一の反復実行が必要です。 KVキャッシュのフラグとシードを固定し、設定は一度にひとつだけ変更してください。さもなければ、あなたは二つの異なるサンプラーを比較して、それをノイズと呼んでいることになります。

1点だけ相互参照です。これは必ず話題になるので：2026年10月9日にリリースされたTurboチェックポイントは、同じ7B視覚生成アーキテクチャと同じ画像条件付け経路を使用し、スケジュールを約40ではなく8つのデノイジングステップで実行します。入力画像の使われ方は、両者の間で何も変わりません。i2i経路を高速で使いたいなら、ロードすべきはそのチェックポイントです。参照が無視されている理由をデバッグしているなら、ステップ数は変数ではありません。

次にやること

チュートリアルではなく、モデルカードにあるベンダー自身のクイックスタートから始めて、編集例の引数リストを読んでください。それは image=input_image を渡し、num_inference_steps を設定しており、strength 引数はどこにもありません。その不在こそがこのページの要点であり、ベンダーのコードでそれを見るほうが要約を信じるより速いのです。

そこから、output_resolution類似性について何かを判断する前に、実際に必要なサイズに設定し、可能な限りキャンバスはネイティブの2Kプリセットのままにしておき、参照画像が部分的にノイズ除去された潜在テンソルではなく、プロンプトの横に置かれた写真であるかのようにプロンプトを書いてください。このモデルでは、まさにそうだからです。そして、3回試したところで「これだけを変えて、ほかはすべてそのままにして」と言いたくなったら、手を止めてください。その一文は、i2iが間違ったルートであるというサインであり、編集のラインこそがふさわしい場所です。