ComfyUIでLoRAを使う実践手順：ウェイト、重ねがけ、キャラクター一貫性

同じキャラクターLoRAで4枚生成したのに、顔がすべて別人になる。ウェイトを0.5から1.2へ動かしても、違いがほとんど見えない。2つのLoRAを重ねると、スタイル同士がぶつかる。ComfyUIはSD WebUIよりパラメータが細かく分かれているため、調整の自由度が高い一方、配線や設定の間違いも増えます。ここではLoad LoRAの各パラメータ、strength_modelとstrength_clipの違い、複数LoRAの接続と主従ウェイト、さらにベースモデル、トリガーワード、切り分け手順を使ってキャラクターのブレを抑える方法を整理します。

LoRAの基本とフォルダの準備

LoRA（Low-Rank Adaptation）は軽量なウェイト適応手法です。ベースのcheckpointを書き換えるのではなく、実行時に追加のウェイトを重ねます。LoRAは数十MB程度のものが多く、数GBになるベースモデルより小さいため、モデル全体を再学習するより学習コストと保存容量を抑えられます。

LoRAファイルを置く場所

標準パスはComfyUI/models/loras/で、サブフォルダも検出されます。モデル作者が配布した.safetensorsを優先し、配置後にモデル一覧を更新します。ドロップダウンが更新されない場合はComfyUIを再起動してください。新しいファイルはLoad LoRAのlora_nameに表示されます。拡張子だけで互換性を判断せず、モデルカードに記載されたベースモデルと用途も確認します。

LoRAのバリアントを扱う方法

Lycoris、LoHa、LoKr、LoConなどのバリアントも、同じLoRA読み込みフローで使用します。ファイルを正しいフォルダへ置けば、ノード側の操作は変わりません。違いは主に学習時の低ランク分解方式にあり、ファイルサイズや特定場面での挙動に影響します。利用時の読み込み手順は共通です。

Load LoRAノードのパラメータ

Load LoRAはベースモデルの出力へLoRAウェイトを適用します。左側に2つの入力、右側に2つの出力があり、中央の3項目で対象ファイルと適用強度を決めます。

入力ポートと出力ポート

ポート	方向	型	説明
model	入力	MODEL	ベースのCheckpoint Loaderが出力するMODELへ接続
clip	入力	CLIP	ベースのCheckpoint Loaderが出力するCLIPへ接続
model	出力	MODEL	LoRA適用済みのMODEL。後段のサンプラーへ接続
clip	出力	CLIP	LoRA適用済みのCLIP。prompt側へ接続

2つの出力を適切な後段ノードへ接続します。modelだけを接続してclipを外すと、トリガーワードへの反応が弱くなるか、機能しない場合があります。

ノードの設定項目

項目	型	範囲	説明
lora_name	ドロップダウン	ファイル一覧	models/loras/から選択。追加ファイルは更新後に表示
strength_model	数値	-100〜100	モデルウェイトへの影響。通常は0〜1付近から試す
strength_clip	数値	-100〜100	CLIPテキストエンコードへの影響。通常は0〜1付近から試す

2つのstrengthは負の値も受け付けますが、負値を共通の「弱める設定」と考えるのは危険です。LoRAごとに反応が異なるため、互換性を確認し、seedを固定してから個別に試します。2つの値を同じにする必要もなく、model側とclip側を分けて観察します。

strength_modelとstrength_clipの実際の違い

Load LoRAには1つではなく2つのウェイトがあります。片方だけ動かせばよいのか、両方を調整すべきかを切り分けます。

2つのウェイトが変えるもの

strength_modelはLoRAが画像生成へ与える影響を制御します。モデルのウェイトに作用し、ディテール、スタイル、質感、光の表現などへ直接影響します。

strength_clipはテキストエンコードへの影響を制御します。CLIPテキストエンコーダーに作用し、promptの解釈やトリガーワードへの反応を変えます。

model側は見た目の特徴をどれだけ強く出すか、clip側はトリガーとpromptをどの程度強く解釈するかに関係します。単純に大きいほど良いわけではありません。

LoRAの種類別に見る開始値

LoRAの種類	strength_model	strength_clip	説明
キャラクター型	0.8-1.0	0.6-0.8	model側で特徴を保ち、clip側を抑えてトリガーの過剰反応を避ける
スタイル型	0.7-0.9	0.7-0.9	近い値でスタイルとprompt解釈を両立する
コンセプト型	0.6-0.8	0.8-1.0	clip側でトリガーを補強し、model側を抑えて見た目の過剰適用を避ける

これらは経験に基づく開始値です。実際の範囲は学習データとトリガーの強さで変わります。

同じpromptとseedでウェイトを比較する

1. prompt、seed、CFG、sampling stepsを固定します。
2. strength_modelだけを変え、0.6、0.8、1.0、1.2を試します。
3. 4枚のスタイル、ディテール、人物特徴を比較します。
4. 効果が明確で、画像が崩れない最大値をmodel側の開始点にします。
5. strength_clipを微調整し、トリガー応答とpromptの一貫性を確認します。

clip側の変化は見た目に間接的なので、model側の範囲を決めてから調整します。スタイルは合っているのに顔が崩れる場合は、strength_clipを0.1〜0.2下げて比較してください。

トリガーワードの探し方と使い方

LoRAを選び、ウェイトも設定したのに画像がほとんど変わらない。その場合、LoRA自体ではなくトリガーワードが抜けている可能性があります。

トリガーワードとは

トリガーワードは学習時に定義されたキーワードです。LoRAが学習した特徴を呼び出します。キャラクター型やコンセプト型では必要な場合が多く、スタイル型では不要なものや、スタイルを補強する任意トリガーだけを持つものがあります。

トリガーがないと効果が弱く、ほぼ見えないこともあります。わずかなスタイル傾向だけが出て、顔、服、髪などの中心的な特徴が現れないケースもあります。

トリガーワードの確認方法

1. CivitAIなどのモデルカードを開きます。
2. 「Trigger Words」または「Activation Text」を探します。
3. 記載されたトークンをpromptへコピーします。

専用欄ではなく説明文に書かれている場合もあるため、使用方法も読みます。トリガーが不要なLoRAなら、その旨がモデルカードに明記されているはずです。

prompt内の配置

トリガーは、対象のキャラクターやコンセプトの記述と近い位置に置き、他の語とカンマで区切ります。追加のウェイト構文が必要かどうかは、モデルカードと現在のワークフローに従います。先頭に置くだけで必ず強くなるわけではありません。

prompt構造の例：

character_name, 1girl, long hair, blue eyes, white dress, ...

character_nameはモデルカードにあるtrigger tokenを表します。標準のComfyUIワークフローではLoad LoRAでモデルを選択済みなので、WebUIの<lora:ファイル名:ウェイト>構文をそのまま書く必要はありません。明示的に対応したカスタムノードを使う場合だけ例外です。

トリガーの後に人物特徴、シーン、構図を続けます。トリガーと対象特徴の間に無関係なスタイル語を挟み、反応を薄めないようにします。

スタイル型とキャラクター型のウェイト範囲

LoRAのウェイトはいくつがよいのでしょうか。1.0から始めると、画像が崩れることも、効果が見えないこともあります。種類によって有効な範囲が異なるためです。

範囲の目安

LoRAの種類	推奨範囲	開始値	高すぎる場合の症状
スタイル型	0.5-0.9	0.75	色の飽和、ノイズ増加、強すぎるスタイルによる人物の変形
キャラクター型	0.7-1.2	有名キャラクターは0.8 小規模データ学習は1.0-1.1	破綻、誇張された顔、特徴の過剰適用

これは公式の制限ではなく、経験的な開始値です。大きなデータセットで学習したキャラクターLoRAは0.8付近で機能することがありますが、小規模な学習では1.0〜1.1が必要な場合もあります。

素早く範囲を探すウェイトスイープ

1. prompt、seed、CFG、sampling stepsを固定します。
2. strength_modelを0.6、strength_clipを0.8にします。
3. 1枚目を生成し、LoRAの特徴が出るか確認します。
4. strength_modelを0.8にして2枚目を生成します。
5. strength_modelを1.0にして3枚目を生成します。
6. strength_modelを1.2にして4枚目を生成します。
7. 4枚を比較し、効果が見えて破綻しない範囲を選びます。
8. 選んだ範囲で約0.1ずつ微調整します。

0.6でまったく効かない場合は、トリガー不足やベースモデル不一致を確認します。1.2で大きく崩れる場合は、0.7〜0.9付近に有効範囲があるかもしれません。model側を決めたらclip側を調整します。

比較ではpromptとseedを固定します。条件が変わると、ウェイト以外の差が混ざります。

複数LoRAの重ねがけ：順序と主従ウェイト

キャラクターLoRAとスタイルLoRAを併用したり、複数のキャラクターLoRAを使ったりする場合は、Load LoRAをチェーン接続します。

ノードをチェーン接続する方法

1つ目のLoad LoRAのmodelとclip出力を、2つ目の同名入力へ接続します。3つ目も同じように続け、最後のLoad LoRAだけをサンプラーとテキストエンコードの経路へつなぎます。

公式ワークフローは複数Load LoRAのチェーン接続に対応しています。ただし実際の結果は、ベースモデル、学習方式、ウェイト、カスタムノードにも左右されます。順序が常に無関係とは考えず、seedを固定して両方の順序を比較します。主従関係を決める最初の変数は、通常ウェイト配分です。

ウェイト配分の方針

重ねがけ	ウェイト設定	期待する結果
2つのLoRA	各0.5-0.6	干渉を抑えたバランス型
3つ以上	主役0.8、脇役0.3-0.5	主役を残し、脇役が補助する
キャラクター＋スタイル	キャラクター0.8-1.0、スタイル0.5-0.7	人物特徴を優先しつつスタイルを加える

2つとも0.8〜1.0にすると、人物特徴が薄れ、スタイルが衝突しやすくなります。3つ以上では主役を0.8前後にし、他を0.3〜0.5へ下げて上書きを避けます。

重ねがけのリスク

互換性の低いスタイルLoRA同士は画面を別方向へ引っ張ります。多くのLoRAを高いまま使うと人物特徴が平均化されます。複数を1.0付近へ上げると、人体の破綻、色の飽和、不安定な出力につながります。

組み合わせる前に各LoRAを単体でテストし、主役と脇役を決めます。最初からすべて同じウェイトにはしません。

キャラクター一貫性を高める構成

同じキャラクターLoRAで4枚作っても、顔が変わることがあります。LoRAは特徴を提供しますが、人物の完全な一致を保証しません。再現性は生成条件全体で決まります。

基本の組み合わせ

LoRA、固定seed、固定したprompt構造から始めます。sampler、steps、CFG、サイズ、ワークフローを変えず、トリガー、人物特徴、シーン記述の順序、ウェイトも揃えます。同じ環境なら再現可能な基準になりますが、シーン、構図、制御ノードを変えるとブレは再び生じます。

prompt構造の例：

character_name, 1girl, long hair, blue eyes, white dress, school background, ...

生成ごとに変えるのはシーン部分だけにし、トリガーと人物特徴は固定します。

構造制御や参照画像制御を追加する

姿勢、深度、エッジを使うControlNetワークフローは、構図と身体構造の固定に役立ちます。顔の同一性が中心課題なら、同じベースモデルに対応する参照画像、IP-Adapter/FaceID、顔の補正ワークフローも検討します。LoRAとは異なる要素を制御するため、組み合わせるとブレをさらに減らせます。

LoRA、seed、promptの基準を固定してから、互換性のある制御を1つ追加します。万能な強度はないため、中程度から段階的に比較し、固定しすぎて画面が硬くなるのを避けます。

想定すべき限界

この組み合わせでも100％同一にはなりません。表情、光、細部は変化します。LoRAと固定した生成条件はブレを減らしますが、人物を完全に複製するものではありません。

prompt、sampler、steps、CFG、サイズ、ベースモデル、LoRAウェイト、制御ノードの変更がブレの主因です。ハードウェアや演算によって非決定性が生じる場合もあります。構造制御で姿勢や輪郭を固定しても、髪、服、表情、背景は変化します。

キャラクター一貫性は継続的な調整です。万能設定を求めるのではなく、使用するLoRAとシーンに合わせてウェイトとprompt構造を詰めます。

SD1.5、SDXL、FLUXのLoRAとベースモデルを合わせる

LoRAが効かない代表的な原因がベースモデルの不一致です。SD1.5 LoRAはSD1.5 checkpoint、SDXL LoRAはSDXL checkpoint、FLUX LoRAは対応するFLUXモデルとワークフローに合わせます。不一致では無反応またはエラーになります。

互換性のルール

LoRAの種類	対応するベース	不一致時の症状
SD1.5 LoRA	SD1.5 checkpoint	無反応、効果が弱い、または静かな失敗
SDXL LoRA	SDXL checkpoint	shape不一致、出力の破綻、または無反応
FLUX LoRA	対応するFLUXベースモデルとテキストエンコーダー	読み込み失敗、keyや次元の不一致、異常な出力

SDXL LoRAをSD1.5へ使うと、エラーになるか、見た目に変化が出ない場合があります。FLUX LoRAもベースモデル、テキストエンコーダー、ワークフローを揃えます。現在の公式例ではワークフローに応じてLoraLoaderModelOnlyなどの内蔵ノードを使うため、特定のサードパーティノード名を唯一の入口にしません。

ベースモデルを確認する手順

1. モデルカードを開きます。
2. 「Base Model」または「Compatible Model」を探します。
3. SD1.5、SDXL、対象FLUXバージョンのどれかを確認します。
4. ComfyUIで対応するcheckpointまたはdiffusion modelを読み込みます。

複数ベース対応と書かれていても、実際の出力には差が出ます。作者が推奨するベースモデルを優先します。

FLUX LoRAの注意点

FLUXはSD1.5やSDXLとモデル構造、ワークフローが異なります。LoRAは対象のFLUXバージョンと読み込み経路に合わせます。現在のComfyUI公式FLUX例ではLoraLoaderModelOnlyを使い、diffusion model、テキストエンコーダー、VAEを個別に読み込む構成があります。

FLUX周辺は更新が続いています。失敗時は、対象モデルの最新ComfyUI公式チュートリアル、LoRAのモデルカード、ベースモデルのバージョンを先に確認します。古い記事のノード名だけでは互換性を判定できません。

LoRAが効かない、効果が弱い場合の切り分け

LoRAを読み込んでも変化がない、または弱い場合は、次の順で確認します。

症状	主な原因	確認方法
画像が変わらない	LoRAが有効な経路にない	modelとclipの両方がLoad LoRAを通るか確認
画像が変わらない	ウェイトが0	strength_modelとstrength_clipを確認
効果が弱い	0.3未満などウェイトが低すぎる	0.6〜1.0付近へ上げ、スイープする
効果が弱い	トリガー不足	モデルカードのTrigger Wordsをpromptへ追加
効果がない	ベースモデル不一致	SD1.5、SDXL、FLUXを確認し対応ベースへ変更
効果がない	フォルダが違う	models/loras/内にあるか確認
効果がない	不正または非対応のモデルファイル	拡張子だけでなく作者が配布する対応ファイルとモデルカードを確認
一覧に表示されない	モデル一覧が未更新	一覧を更新するかComfyUIを再起動
読み込み、key、次元エラー	FLUX LoRAとワークフローが不一致	FLUXバージョン、公式例のノード、テキストエンコーダー、モデルカードを確認
スタイル衝突、人物特徴の低下	複数LoRAの配分が不適切	脇役を下げ、主役を明確にする

最初にmodelとclipの配線、次にウェイト、トリガー、ベースモデル、最後にファイル位置を確認します。弱い効果の多くは、トリガー、ウェイト、互換性で解決できます。

次のステップと関連記事

読み込み、ウェイト調整、重ねがけが安定したら、用途別のワークフローへ進めます。

関連記事

• ComfyUI入門ガイド：インストール、モデルフォルダ、ノード、最初の生成を確認
• ComfyUIワークフロー再利用ガイド：ワークフローの読み込み、ノード依存関係、モデルパスを切り分け
• Stable Diffusionモデル選定ガイド：SD1.5、SDXL、FLUXの選択肢と利用条件を比較
• Stable Diffusion promptテンプレートガイド：prompt構造、ウェイト構文、反復方法を整理
• ControlNetによる姿勢、線画、深度制御（公開後にリンクを追加予定）

発展的な方向

多数のLoRAを扱う場合は、rgthree Power LoRA Loaderなどのサードパーティノードでウェイト管理を簡略化し、ワークフロー固有のマスクや領域適用を検討できます。

LoRAマスクは、画像全体へスタイルをかける代わりに、選択した領域だけへ効果を適用します。

Kohya_ssなどで独自LoRAを学習する場合は、データセット、学習パラメータ、検証、書き出しを別の手順として設計します。

LoRAはStable Diffusionでよく使われる適応手法ですが、ウェイト調整と重ねがけには制御した比較が必要です。まず単体で基準を作り、その後に組み合わせます。効果が消えたり出力が崩れたりしたら、切り分け表を上から確認してください。