IP-Adapterで衣装を固定してポーズだけ変える─完璧な衣装固定はできなかった

「ポーズを変えるたびに衣装が変わる」問題に、IP-Adapterで挑みました。結論から書きます。地雷系コーデでは全敗しました。ブレザーの制服に切り替えたら、だいぶマシになりました。ただし完璧ではありません。

経緯はこうです。地雷系の服を着た女の子のイラストを1枚用意し、表情やポーズだけを変えたかった。それだけの話なのに、生成するたびに衣装のデザインが変わります。配色が変わり、フリルが消え、シルエットすら別物になる。プロンプトをどれだけ詳細に書いても、Stable Diffusionは我々の服装指定を忠実に守る気がありません。

そこでAI（皮肉なことに、別のAIです）に相談したところ「IP-Adapterを使え」と言われました。素直に従ってみたところ、地雷系の「雰囲気」は拾ってくれるのですが、具体的な衣装デザインが毎回変わります。衣装固定としては使えませんでした。そこで衣装をブレザーの制服に変更したところ、近しいものは生成できるようになりました。ただしチェック柄のスカートなどは生成ごとにブレが残ります。本稿ではその全過程──改善したこと、しなかったことの両方を記録します。

IP-Adapterとは何か

IP-Adapter（Image Prompt Adapter）は、Tencent AI Labが開発した画像プロンプト機構です。テキストプロンプトに加えて「参照画像」を入力として受け取り、その画像の特徴を生成結果に反映させます（Ye et al., 2023, arXiv:2308.06721）。

学習時の設計

【仕様】IP-Adapterの核となるのは「分離クロスアテンション（decoupled cross-attention）」と呼ばれる設計です。U-Netの各クロスアテンション層に、テキスト特徴用とは別の画像特徴用クロスアテンション層を追加します。学習時には、既存のU-Netの重みを凍結したまま、この追加された画像用クロスアテンション層のパラメータのみを学習します。SD 1.5版のIP-Adapterで学習対象のパラメータは約22Mと報告されています（同論文）。

推論時の動作

推論時（画像を生成するとき）には、事前に学習済みのアダプターがU-Netに組み込まれます。参照画像はCLIP画像エンコーダで特徴量に変換され、投影ネットワーク（projection network）を経由したのち、追加されたクロスアテンション層を通じて生成過程に注入されます。テキストプロンプトの経路と画像プロンプトの経路が分離されているため、両方を同時に使用するマルチモーダル生成が可能です。

平たく言えば「この画像の雰囲気を覚えておいてくれ」と拡散モデルにお願いできる仕組みです。覚えてくれるかどうかは、衣装のややこしさ次第ですが。

なぜ衣装がブレるのか──問題の構造

テキストプロンプトだけで衣装を維持しようとすると、構造的な壁にぶつかります。

Stable Diffusionにとって、プロンプトの衣装記述はあくまで「そういう方向性」の指定にすぎません。「黒いワンピース」と書けば黒いワンピースは出ますが、襟の形、丈の長さ、ボタンの数といった具体的なデザインは毎回ゆらぎます。

Seed固定でも衣装は変わる──これは知っておくべき事実だった

IP-Adapterの前にまず試したのは、Seed固定です。同じSeedなら同じ画像が出る──なら衣装も固定されるはずだ、と考えました。結果は不発でした。これは地味ですが、技術的に価値のある発見だったと思っています。

Seedが同じでも、テキストプロンプトを変えてポーズや表情を指示した時点で、クロスアテンションの応答が変わります。これにより潜在空間（latent space）全体の配置が変化し、衣装のデザインも引きずられて変わってしまいます。つまり、Seed固定は「まったく同じ条件で同じ画像を再現する」ための仕組みであって、「条件の一部を変えても他の要素を固定する」ための仕組みではありません。

【経験則】私の環境では、同じSeedでポーズ指示だけを変えた場合、衣装の色・シルエット・装飾のいずれもが変化しました。画像生成AIをはじめて日が浅い段階では「Seedを固定すれば同じキャラが出る」と思いがちです。私もそう思っていました。しかし実際には、プロンプトが1語でも変われば生成画像全体が変わります。Seed固定は衣装の一貫性には効果がない──この事実は、IP-Adapterに限らず、衣装やキャラクターの一貫性を求めるあらゆる作業の前提として知っておく価値があります。

IP-Adapterはこの問題に対し、「テキストでは伝わらない視覚的特徴」を参照画像から直接注入することで対処します。言葉で伝わらないなら画像を見せればいい。合理的な発想です。ただし、参照画像から抽出される特徴は「スタイルの方向性」であって「具体的なデザイン情報」ではない場合がある──これが今回の検証でわかったことです。

まず地雷系で試した──そして全敗した

検証環境（共通）

• UI：Stable Diffusion WebUI Forge
• チェックポイント：waiIllustriousSDXL_v160.safetensors
• IP-Adapterモデル：ip-adapter_sdxl.safetensors
• プリプロセッサ：CLIP-ViT-bigG (IPAdapter)
• CLIPビジョンモデル：CLIP-ViT-bigG-14-laion2B-39B-b160k.safetensors

※ プリプロセッサとCLIPビジョンモデルの関係は後述のプリプロセッサ選択セクションで解説します。

「全敗」の意味について

先に補足しておきます。ここで言う「全敗」は、生成画像の品質が悪かったという意味ではありません。1枚1枚を見れば普通にきれいなイラストですし、「地雷系の雰囲気」はどれもちゃんと出ています。

問題は、「衣装固定として実用的か」という基準で見たときに使えなかったということです。参照画像と生成結果を並べると、同じスタイルの服を着てはいるが、同じ服ではない。ポーズ違いのイラストを並べて「同一キャラクターの衣装バリエーション」として使おうとしたとき、衣装が毎回違っていては一貫性の証明になりません。その意味での全敗です。

地雷系コーデで起きたこと

参照画像として用意したのは、ピンクの星マークが入った黒のオーバーサイズパーカー、ピンクのリボンチョーカーに十字架ネックレス、パーカーの裾から覗くピンクのフリルスカート、レーストップのニーハイソックスに厚底シューズ──いわゆる典型的な地雷系コーディネートの女の子です。

IP-Adapterに参照画像を入れ、ポーズや表情だけをテキストプロンプトで変更して生成しました。Control Weightは0.7からスタートし、0.05刻みで1.0まで試しています。

結果は以下のとおりです。

「地雷系の雰囲気」は拾えていました。 これは正確に書いておくべきことです。生成結果を見ると、黒基調の服、ピンクのアクセント、十字架モチーフ、ゴシック調の装飾──「地雷系コーデの女の子」という大枠の方向性は、どの生成結果にもちゃんと反映されています。CLIPは「地雷系っぽさ」というスタイルレベルの情報はしっかり拾っていました。

しかし、具体的な衣装デザインが毎回変わりました。 オーバーサイズのパーカーがクロップド丈になる。参照画像にはないレースのフィンガーレスグローブやブレスレットが生えてくる。フリルスカートの段数やデザインが変わる。袖のリボンの位置や数が変わる。「地雷系の服を着ている」ことは共通していても、「同じ服を着ている」とは言えない状態です。

つまり、スタイルは転写されるがデザインは固定されない。 IP-Adapterが参照画像から抽出しているのは「こういう雰囲気の服」という意味的な特徴であって、「このパーカーのこのデザイン」という具体的な衣装情報ではないことが、生成結果から読み取れます。

0.7〜1.0まで試した中では、0.8が最もマシでした。 「安定した」と書くと語弊があります。0.8でも衣装デザインは毎回変わります。ただ、他の設定値では明らかに参照画像とかけ離れた画像が生成されることが多かったのに対し、0.8は「地雷系の雰囲気を保ちつつ、ポーズの変更もある程度反映される」バランスが比較的取れていました。最もマシだった、というだけの話です。

なぜ地雷系は安定しなかったのか

【経験則】以下は推測です。仕様として確認された説明ではなく、検証結果からの推論である点にご注意ください。

生成結果を見ると、IP-Adapterの画像エンコーダ（CLIP）は「地雷系っぽさ」というスタイルレベルの情報はしっかり拾えていました。黒基調にピンクのアクセント、十字架モチーフ、ゴシック調の装飾──この「雰囲気」はどの生成結果にも共通しています。

一方で、「このパーカーのこの星マーク」「この位置のこの袖リボン」といった具体的なデザイン情報は保持されませんでした。CLIPの特徴量空間では、参照画像の「黒いオーバーサイズパーカー＋ピンク星マーク＋十字架ネックレス」という具体的な組み合わせが、「ゴシック調の黒い服＋ピンクの装飾＋十字架アクセサリー」という抽象的なスタイル情報にまとめられてしまったのではないかと考えています。

結果として、生成のたびにCLIPが拾った「地雷系スタイル」をモデルが異なるデザインで解釈し直すことになります。フィンガーレスグローブが生えてきたり、パーカーがクロップド丈に変わったりしたのは、「地雷系の服」という方向性の中でモデルが自由に補完した結果だと推測しています。

衣装を変えた──ブレザー制服なら、だいぶマシになった

地雷系での全敗を受けて、衣装をブレザーの制服に変更しました。紺のブレザー、白シャツ、チェック柄のスカート、リボンタイ──地雷系と比べれば構成要素がずっと少ないデザインです。

ブレザー制服で改善した点

【経験則】以下はいずれも私の環境（waiIllustriousSDXL v160 + ip-adapter_sdxl + CLIP-ViT-bigG）での傾向です。他の環境やモデルでは異なる結果になる可能性があります。

配色が安定しました。 紺のブレザーと白シャツという基本の配色は、生成ごとのブレがほぼなくなりました。地雷系で起きていた「黒が紺になる」「白がクリーム色になる」といった色の揺れは、制服ではほとんど発生しませんでした。

シルエットが維持されるようになりました。 ブレザー＋スカートというシンプルな構成であれば、IP-Adapterの参照が効きやすく、衣装の大枠が崩れることはほとんどありませんでした。「ブレザーがカーディガンに変わる」といったレベルの破綻は起きていません。

それでも完璧ではない

ここで正直に書いておきます。ブレザー制服でも、IP-Adapterによる衣装固定は完璧ではありませんでした。

チェック柄は安定しません。 スカートのチェック柄は生成ごとにパターンが変わります。タータンチェックがウィンドウペーンになったり、格子の太さが変わったり、色の組み合わせが微妙にずれたりします。CLIPの特徴量では「チェック柄のスカート」という概念は拾えても、具体的な柄のパターンまでは保持しきれないのだと思われます。

細部のディテールにはブレが残ります。 リボンタイの形状、ブレザーのボタンの数、襟の開き具合──こうした細部は、生成のたびに微妙に異なります。「同じ制服を着ている」と認識できる程度には安定しましたが、「まったく同じ制服」と呼べるかと聞かれると、答えはノーです。

地雷系の「毎回別の服になる」惨状と比べれば大幅な改善です。しかし「近しいものが出る」と「同じものが出る」のあいだには、まだ溝があります。

Control Weightについて

ブレザー制服では、地雷系で最もマシだった0.8をそのまま引き継いで生成しました。結果が安定していたため、地雷系のときのような0.05刻みの網羅的な検証は行っていません。

念のため前後の値（0.75と0.85）を試しましたが、いずれも0.8より安定しませんでした。0.75ではシルエットの維持が甘くなり、0.85ではポーズの自由度が下がる傾向が見られたため、0.8に戻してそのまま生成を続けています。

厳密な比較検証ではないため、0.8が「最適値」かどうかは断言できません。ただ、地雷系で見つけた0.8がブレザー制服でもそのまま通用したのは、結果的に助かりました。

プリプロセッサの選択──参照画像をどうエンコードするか

ForgeのControlNetパネルでIP-Adapterを使う際、「Preprocessor」ドロップダウンから参照画像の処理方法を選択します。ここで選んだプリプロセッサが、参照画像をどのCLIPエンコーダで特徴量に変換するかを決めます。

私の環境（Forge）では、ドロップダウンに以下の4つが表示されました（UI上の並び順です）。

• None：プリプロセッサを使用しない（事前にエンコード済みの入力を使う場合）
• **InsightFace+CLIP-H (IPAdapter)**：顔認識エンジンInsightFaceとCLIP ViT-Hを組み合わせて、顔の特徴を重点的に抽出する
• **CLIP-ViT-bigG (IPAdapter)**：OpenCLIP ViT-bigG/14で参照画像の特徴を抽出する
• **CLIP-ViT-H (IPAdapter)**：OpenCLIP ViT-H/14で参照画像の特徴を抽出する

ここで重要なのは、プリプロセッサの選択が対応するCLIPビジョンモデルファイルの使用と紐づいているという点です。たとえば「CLIP-ViT-bigG (IPAdapter)」を選ぶと、あらかじめmodels/CLIPVisionフォルダに配置しておいたCLIP-ViT-bigG-14-laion2B-39B-b160k.safetensors（約3.6GB）が参照画像のエンコードに使われます。このファイルがなければ処理が実行できません。

正直に告白しますと、初見では何を選べばいいかまったくわかりませんでした。名前から察するに何かが大きくて何かが小さいことは理解しましたが、それ以上の判断材料がありません。

各プリプロセッサの役割

【仕様】ViT-bigG/14とViT-H/14はいずれもOpenCLIPプロジェクトで開発された汎用の画像エンコーダです。特定の拡散モデル向けに設計されたものではありません。IP-Adapterの実装において、SDXL版ではViT-bigGが、SD 1.5版ではViT-Hが画像エンコーダとして採用されています（Hugging Face – h94/IP-Adapter）。

IP-Adapterの公式リポジトリには「ViT-bigGはViT-Hよりはるかに大きいが、実験結果では有意な差は見つからなかった」という記述があります（GitHub）。ただし、この比較がどのような条件（使用モデル、解像度、評価タスク）で行われたかの詳細は、同リポジトリ上では確認できませんでした。

【仕様】InsightFace+CLIP-Hは、FaceIDモデル向けのプリプロセッサです。顔の特徴抽出に特化しており、衣装やスタイル全体の転写には向いていません。FaceIDモデル以外のIP-Adapterモデルと組み合わせた際にエラーが発生した事例が報告されています（Forge Discussion #524）。ただし、すべての環境・バージョンで同様のエラーが発生するかは未検証です。

今回の目的は「衣装のデザインを維持したい」ですので、InsightFace系は選択肢から外れます。顔ではなく服を見てほしいのです。

SDXLベースのモデル（waiIllustriousSDXL v160）を使用していたため、IP-AdapterのSDXL版が採用しているCLIP-ViT-bigGを選択しました。結果的に、これが一番しっくりきた選択でした。

早見表

プリプロセッサ	参照画像の処理	IP-Adapterでの採用	対応CLIPビジョンモデル
CLIP-ViT-bigG (IPAdapter)	画像全体の特徴を抽出	SDXL版で採用	CLIP-ViT-bigG-14-laion2B-39B-b160k（約3.6GB）
CLIP-ViT-H (IPAdapter)	同上	SD 1.5版で採用	CLIP-ViT-H-14-laion2B-s32B-b79K（約2.5GB）
InsightFace+CLIP-H (IPAdapter)	顔の特徴を重点的に抽出	FaceID系モデルで使用	上記 + InsightFaceモデル
None	なし（入力をそのまま使用）	─	─

この表は私の検証範囲に基づくものです。公式リポジトリやHugging Faceの対応表も併せてご確認ください。

ControlNetとの併用で精度を上げる

IP-Adapter単体でも、私の環境ではブレザー制服程度のシンプルな衣装なら概ね安定しましたが、「ポーズを明確に指定したい」場合はOpenPoseやDepthなどのControlNetとの併用が現実的です。

【経験則】私の環境での組み合わせ例は以下のとおりです。

• Unit 0：IP-Adapter（衣装の参照）── Control Weight: 0.8
• Unit 1：OpenPose（ポーズの指定）── Control Weight: 0.8〜1.0

この構成で、「衣装はIP-Adapterで固定、ポーズはOpenPoseで指定」という役割分担が成立します。

ただし、各ControlNetユニットのWeightを個別に強く設定しすぎると、生成画像が破綻する場合があります。ControlNetの各ユニットは独立して適用される仕組みですので、「Weightの合計」で制御するものではなく、各ユニットのWeight個別の強弱が結果に影響します。

実践まとめ：検証環境での設定

シンプルな衣装（ブレザー制服）で概ね安定した設定を整理しておきます。

• UI：Stable Diffusion WebUI Forge
• チェックポイント：waiIllustriousSDXL_v160.safetensors
• IP-Adapterモデル：ip-adapter_sdxl.safetensors
• プリプロセッサ：CLIP-ViT-bigG (IPAdapter)
• Control Weight：0.8（地雷系・ブレザー制服いずれでも最もマシだった値）
• Starting Control Step：0
• Ending Control Step：1
• Control Mode：Balanced

テキストプロンプトには、変更したいポーズや表情に加えて、衣装の記述も残しておく価値があります。IP-Adapterとプロンプトの両方から衣装情報を与えることで、私の環境では安定性が向上する傾向がありました。

限界と注意点

IP-Adapterはピクセルレベルの画像転写ではありません。 CLIPエンコーダで抽出した意味的な特徴量をクロスアテンション経由で注入する仕組みです。そのため、参照画像の細部をそのまま再現することは、実装上の特性として困難な傾向があります。

【経験則】情報量の多い衣装ほど安定しにくい傾向がありました。 地雷系・ゴスロリのように装飾が密集するデザインでは、IP-Adapterによる衣装固定が実用に至りませんでした。ブレザー制服に変更しても、チェック柄のような反復パターンは生成ごとにブレが残ります。ただしこれは私の環境（waiIllustriousSDXL v160 + ip-adapter_sdxl）での結果です。他のモデル・IP-Adapterのバリエーション（Plus, Style Transfer等）・異なるWeight設定では、異なる結果になる可能性があります。

参照画像の構図が結果に影響します。 私の環境では、参照画像のポーズと指定したいポーズの差が大きい場合に、衣装の再現が不安定になる傾向がありました。

VRAM消費が増えます。 CLIPビジョンモデルがチェックポイントやVAEに加えてVRAMに載ります。CLIP-ViT-bigGのファイルサイズは約3.6GB、CLIP-ViT-Hは約2.5GBです（実際のVRAM消費量はロード時の精度設定等によりファイルサイズとは異なります）。私の環境ではOpenPoseとの併用時にVRAM消費が目に見えて増加しました。

プリプロセッサとIP-Adapterモデルの組み合わせにご注意ください。 FaceIDモデルにCLIP-ViT-bigGを使う、あるいは通常のIP-AdapterモデルにInsightFace+CLIP-Hを使うと、エラーや予期しない結果になる事例が報告されています。組み合わせは公式の対応表に従ってください。

ComfyUI_IPAdapter_plusについて。 同リポジトリのREADMEには、2025年4月14日付で「メンテナンスのみのモードに移行する」旨が記載されています（GitHub、2025年2月に確認）。ComfyUI公式組織からフォーク版（comfyorg/comfyui-ipadapter）も公開されています。ただし、こうした情報は時期によって変わる可能性がありますので、最新の状況は各リポジトリでご確認ください。

完璧ではないが、前よりはマシになった

IP-Adapterは「テキストでは伝えきれない視覚的特徴を参照画像から注入する」ための仕組みであり、私の環境では衣装デザインの維持にそれなりの効果がありました。ただし、「それなり」です。完璧ではありません。

【経験則】ブレザー制服に変更したことで、シルエットと基本配色の安定性は大幅に向上しました。地雷系のときの「スタイルは合っているが毎回違うデザインになる」状態からは明確に改善されています。しかし、チェック柄のパターンや細部のディテール（ボタン数、襟の形、リボンタイの形状）は生成ごとにブレが残ります。「近しいものが出る」と「同じものが出る」は、似ているようで全然違います。

おそらく、この問題に対する対応策はあるのだと思います。IP-Adapter Plusの各バリエーション、LoRAの学習、Weight Typeの調整、あるいはここで書いていない別のアプローチ。ただ、画像生成AIに取り組みはじめて日が浅い私には、まだその技術がありません。

これは正直に書いておくべきことです。知ったかぶりで「こうすれば解決する」とは書けません。今の私にできるのは、試したことと試していないことを正確に記録することだけです。チェック柄が安定する方法を見つけた暁には、続報を書きます。

本日の検証記録はここまで。