Animaの3キャラ合体LoRAをRTX 5090(Blackwell)で学習、ControlNetなしで密着3人を描き分け

2キャラ合体LoRA（keikana v2）で、けいとかなを1本のLoRAにまとめて、2体接触で出ていたアホ毛移りと体の融合まで消した。rank128と2体学習データ20枚で干渉がなくなった、というところまでが前回。

今回はそこに3人目（こはる）を足して、3キャラを1本のLoRAに合体させる。 ソロに加えて3つのペア（けい＋かな・こはる＋けい・こはる＋かな）と3体（trio）まで学習データに入れた、計294枚のセットで学習する。

もう一つ、今回は学習を初めてBlackwell（RTX 5090 / B200, sm_120）で走らせる。 これまでのAnima系LoRAは全部4090（Ada, sm_89）で学習してきたが、Blackwellはアーキテクチャ世代が違うので環境スタックがそのままでは使えない。torchやアテンションの実装を差し替えないと「no kernel image」で起動すらしない。ここが過去記事と地続きでない新しい地雷になる。

学習はRunPodのRTX 5090で走らせた。Blackwellでそもそも学習を走らせられるのか、3人目を足して1本のLoRAに収め切れるのか、走らせながら確かめた記録をそのまま残す。

確かめたかったことは3つ。

• 2体ですら干渉で頭打ちだったrank容量を、3体でどこまで上げれば足りるか。今回はrank256まで上げる
• マルチ（2体＋3体）比率が23.8%とv2の13%より高い。単独トリガーで勝手に複数人が出ないか
• Blackwellの環境差し替え（cu128 / torch2.7+ / SDPA / FlashAttention無効化）が、4090プランで踏んできた地雷とどう違うか

検証環境

区分	内容
学習マシン	RunPod RTX 5090（32GB GDDR7, 60GB RAM, 12 vCPU, Blackwell sm_120, $0.99/h）。VRAMが厳しければ B200(192GB)
学習ツール	AnimaLoraToolkit（Moeblack版・RTX 50系公式サポート）
ベースモデル	Anima-Base v1.0
比較対象	keikana v2（rank128 / 2キャラ / 152枚 / 4090で学習）
今回のLoRA	3キャラ合体（rank256 / 294枚 / Blackwellで学習）
生成・評価マシン	M1 Max 64GB ローカル ComfyUI
生成の共通条件	Turbo LoRA 8-step / er_sde / simple / cfg1.0

学習だけRunPodのBlackwell、生成と評価はいつものM1 Maxローカル、という分担。過去のAnima記事と同じく生成側はTurbo 8-stepで揃える。

データの数字

区分	枚数
kei solo	79
kana solo	65
koharu solo	80
pair_keikana（2体）	20
pair_koharukei（2体）	20
pair_koharukana（2体）	20
trio（3体）	10
合計	294

ソロ計224に対し、マルチ（2体＋3体）計70で、マルチ比率は23.8%。全画像にキャプション済み、ファイル名は半角英数字のみ。v2は152枚（けい79＋かな53＋2体20）でマルチを13%に抑えていたので、今回は枚数も比率も一段重い。

設定と根拠

ベースは keikana v2 の設定（rank128 / lr2e-5 / repeats2 / ep150 / Anima-Base v1.0）。これを294枚と3キャラ向けに再計算した。v2は2キャラだったが、今回は3キャラ＋3ペアで干渉が増えるぶん、rankは据え置きにせず、少し高めにする。

パラメータ	採用値	根拠
ベースモデル	Anima-Base v1.0	v2と同じ。生成は masterpiece, best quality 等のクオリティタグ前提
rank (network_dim)	256	294枚あるので容量を上げても支えられる。データ/rank比 294/256≈1.15 は v2(152/128≈1.19)とほぼ同値で実証済みのバランス内。3キャラの顔忠実度と分離に余裕が出る
alpha	256	v2の alpha=rank 流儀。強めに効かせる
learning_rate	2.0e-5	Anima公式かつ実証の安定値。高いと不安定、低い(1e-5)は未検証
repeats	2	v2の2キャラ値。これで1枚あたり露出が300回（repeats2 × ep150）
epochs	最大120〜150（早期epも保存して各epを比べる）	マルチが多くrankも大きいぶん過学習が早まりやすい。ep100手前で崩れる見込みなので、低いepから採用する
batch_size / grad_accum	1 / 4（実効バッチ4）	toolkit構成（keichan/v2と同じ）
steps/epoch	147（= 294×2 ÷ 4）
総ステップ	約22,050（147 × 150）	v2は11,400。2倍なのは枚数が約2倍だからで過学習ではない
1枚あたり露出	300回（repeats2 × ep150）	v2と同値で安全域
save_every	1（全ep保存）	過学習が早い見込み。ストレージ保存は安いので毎ep残し、崩れる1epを取りこぼさない
resolution	1024
precision	bf16
flip_augment	false	trueは禁止。左右情報が壊れる

総ステップが22,050とv2の2倍近いが、これは枚数が約2倍だから増えただけで、1枚あたりの露出はv2と同じ300回に抑えている。総ステップ数の大きさに驚いてエポックを削ると、今度は露出不足で特徴がシードでばらつく。判断軸はステップ総数ではなく1枚あたりの露出回数にする。

所要の目安は、v2（rank128 / 152枚 / 4090）の約10時間・約$10が基準。今回は枚数約2倍だが、rank256のステップ単価増を5090の速さ（4090より速い報告）が相殺すると見込んだ。事前は18〜24時間と見積もったが、これは外れた。実測は1ep約339秒（147 step）で、フル150epなら約14時間・約$14。GPU $0.99/h（コンテナ・ストレージ込みで $1.01/h）。Blackwellでのステップ速度は初めてだったので最初の数epで確定させた。実際の打ち切りepと時間は後述する。

4090から差し替えるBlackwellの環境スタック

ここが今回の新しいところ。過去のAnima学習は torch 2.5.1+cu124（Ada / sm_89向け）で固めてきたが、これをBlackwell（sm_120）にそのまま持っていくと「no kernel image」で動かない。AnimaLoraToolkit自体はRTX 50系サポートと書いてあるので、土台さえ差し替えれば走らせられるはず。ただし学習をBlackwellで通すのは初めてで、ここは推論側（ComfyUIでの5090実績）とは別物として確かめる。

項目	4090(Ada, sm_89)	Blackwell(5090/B200, sm_120)
torch	2.5.1+cu124	2.8.0 / cu128（RunPod公式 runpod/pytorch:1.0.2-cu1281-torch280-ubuntu2404。2.7stableがsm_120対応の初）
sm対応	sm_89	sm_120（2.5系は「no kernel image」で起動失敗）
アテンション	xformersが地雷なので外す	SDPAを使う（xformersはBlackwellで更に不可。toolkit公式もSDPA）
FlashAttention	使わない	Blackwellでまだ不安定（カーネル欠け報告）。無効化してSDPAにfallback
transformers	>=4.51,<5.0	qwen3対応(>=4.51)は要るが、torch2.7+と整合する版に上げる。pip freeze 保存は同じ

VRAMは5090の32GBなら、4090の24GBよりマージンがある。rank256×3キャラは重いので、24GBだとgrad_checkpoint必須級になるところ、32GBならそのまま走らせられる見込み。B200まで上げれば192GBで完全に余裕。FP4/FP8まわりは4090より速い。

テンプレはcu124系を選ばず、cu128同梱のものから始める。RunPod公式のPyTorch 2.8.0テンプレは runpod/pytorch:1.0.2-cu1281-torch280-ubuntu2404（CUDA 12.8.1 / torch 2.8.0 / Ubuntu 24.04）で、これを土台にする。推論側で5090実績のあるComfyUIテンプレ（cu128）は学習には重いだけなので使わない。起動直後に torch.cuda.get_device_capability() が (12, 0) を返すか、依存にコンパイルが要る時のために nvcc があるかを先に確かめてから依存を入れる。

Blackwellでの学習はそのまま走った

今回の一番の未知だったBlackwellでのLoRA学習は、環境差し替えだけで普通に走った。推論（ComfyUIでの5090実績）とは別物だと思っていたが、「no kernel image」も依存衝突も出ず、動作確認から本番まで一度も落ちていない。

実際に使えた構成は次の通り。

項目	実際の値
テンプレ	runpod/pytorch:1.0.2-cu1281-torch280-ubuntu2404
torch	2.8.0 + cu128
アテンション	SDPA（xformersは入れない）
device capability	(12, 0) = sm_120
Transformer重み一致	685/688（99.6%。missing 3はAnima側の非学習層で無害）
VAE重み一致	194/194（100%）
LoRA注入	316層
1 epのステップ数	147（294枚×repeats2 ÷ grad_accum4）
ステップ速度	約339秒/ep

ステップ速度が確定したので時間も見積もれた。1ep約339秒なので、フル150epなら約14時間・約$14。事前見積もりの18〜24時間は外していて、rank256のステップ単価増を5090が想定以上に相殺した。今回はかなが安定しないと判断してep75で打ち切ったので、学習自体は約7時間で止めている。チェックポイントは save_every=1 でep1〜74まで全て120GBのNetwork Volumeに残した。

環境系（torch / cu128 / xformers無効 / transformers）は事前に潰した通りで、本番では一度も問題にならなかった。AppleDouble混入もtar固めで回避できた。この記事で詰まったのは環境ではなく、データの中身（かな）だった。

けいとこはるは安定する、かなだけ出てこない

ep15あたりでけいの輪郭（金髪ロング・青リボン・青い目）がほぼ決まり、こはる（短い暗髪・赤茶の目）も続いて安定した。下はep64のけい単独とep73のこはる単独で、どちらも単独トリガーで元キャラを再現できている。

問題はかな。ep72（最後のかな単独サンプル）まで走らせても、かなの一番の記号であるサイドポニーが出ない。アホ毛は残るが、髪は長く伸びて、シルエットがけい寄りになる。けい・こはるが同じ露出で安定しているのに、かなだけ140回露出してもこの状態だった。

かなはけいに取り込まれる

かなが安定しない理由は2人出力ではっきりした。下はep74の「kanachan and keichan」で、本来は左がかな・右がけいになるはずが、2人とも金髪ロングのけいになっている。かなのトリガーが、より強いけいに上書きされている。

3キャラの中でかなは学習枚数が最少の65枚で、けい79・こはる80に対して露出も勾配シェアも薄い。容量は有限なので、弱いかなが強いけいに取り込まれる。過去の2キャラLoRA（v2）は同じけい＋かなで分離できていたから、この組み合わせ自体が原理的に無理なわけではない。こはるが3人目として容量を取り、かなの取り分がさらに減ったのが大きい。

trioではかなの原型が残らない

3体（trio）でも同じで、けいとこはるは別々に出るが、かなは汎用の長髪娘になってかなだと判別できない。下はep70のtrio（左 けい / 中 こはる / 右 かなのはずの娘）。

唯一の例外がep56で、ここだけはかながアホ毛＋ポニーで出てきた。ただし同じ画像でこはるの髪が伸びて崩れている。かなを出すとこはるが崩れ、こはるを保つとかなが消える。固定容量を3人で取り合うゼロサムになっている。

過学習でもrank不足でもない

落ちた原因を切り分けると、過学習でもrank不足でもなかった。

• ep1からep74まで、どのサンプルにもアーティファクト・ゴースト化・半透明化が出ていない。露出設計は学習しすぎ側ではない
• けいとこはるが綺麗に分離して安定しているので、設定（rank256 / lr2e-5 / repeats2 / SDPA）自体は問題ない
• rank256でも過学習の兆候はゼロで、容量はむしろ余っている

エポックを増やしてもrankを上げても、かなは出てこない。これは学習回数や容量の問題ではなく、データのバランスと分離の問題だった。かなのデータが枚数でもキャプションでもけいに対して弱く、3人目のこはるが容量を取ったことで、かなの取り分が分離に足りる閾値を下回った。

学習し直しの方針

同じ設定のまま、データ側を組み替えて学習し直す。rank・lr・repeatsは動かさない（過学習の兆候がない＝そこは原因ではない）。効果が大きそうな順に並べると次の通り。

手	何を直すか	根拠
かなのデータ一貫性	かな画像同士の髪型・色のブレを潰し、けい寄り（金髪・長髪）に映る素材を抜く	140回露出しても安定しない＝画像同士が食い違っている疑いが濃い
かなのrepeats／枚数を上げる	かなだけ露出を増やし、けいとの勾配シェアの差を埋める	最少65枚で露出が薄い。けい79・こはる80に対し約18%少ない
けいの優位を下げる	けいの枚数を削るかトリガーを散らし、引力を弱める	かなが取り込まれる先が常にけい。一番強い引力を下げる
かな単独・trioを増やす	かな単独とtrioの分離例を足す	trioでかなの原型が残らない。分離の手本が少ない

rankは256のまま据え置く（最大値で、上げる必要も下げる必要もない）。それでもかなが出ないなら、2キャラLoRA（けい＋こはる）とかな単体LoRAに分けて、3人目を1本に詰め込むのをやめる。

学習し直しで分かった主因はキャプションの非対称

学習し直す前にデータを点検して、かなが取り込まれた本当の理由が分かった。設定（rank・lr・repeats）ではなく、キャプションの付け方が3キャラで非対称だった。

LoRA学習では、キャプションに書いた属性はトリガー語から切り離されて汎用タグ側に紐付き、書かなかった属性がトリガー語に覚え込まれる。3キャラのソロ画像でこの差を数えると露骨だった。

キャラ	髪・目の記述	結果
こはる	0 / 80（無記述）	ロック
けい	0 / 79（色・長さほぼ無記述）	ロック・最強
かな	65 / 65（全枚に side ponytail 等）	取り込み・消失

こはるは暗髪ショート・赤目を一度も書いていない。けいも金髪・ロング・青リボンを書いていない。特徴がトリガー（koharu / keichan）そのものに覚え込まれるから、単独でも崩れない。かなだけ全画像に side ponytail・ahoge・medium hair・blue scrunchie を書いていたため、サイドポニーは汎用タグの側に紐付き、kanachan 本体は中身が薄くなる。競合すると、強く覚え込まれたけいに上書きされて金髪ロングになる。アホ毛だけ残ってサイドポニーが消える挙動と一致する。

2キャラ（けい＋かな）では競合が弱く、この非対称でもかなは保たれていた。3人目のこはるが容量と勾配を取ったぶん、もともと薄かったかなのトリガーが閾値を下回った。

直し方は逆で、書くのをやめて覚え込ませる。やったのは2つ。

• 全キャラのキャプを髪・目無記述に統一: かなソロ65枚から髪・目トークンと「Her side ponytail…」系の文を除去。ペア・trioも髪描写を抜いて左右の位置だけにした
• かなを65→81枚に増量: けい・こはると枚数を揃えた。増やした16枚は、QIEがかなのサイドポニーを安定再現できない（正面の素体に引っ張られて崩れる）ので、サイドポニーが正しく写った画像を参照に、参照画像ガイドの画像生成で別衣装・別ポーズを起こして補った

rank256・lr2e-5・repeats2は据え置き。過学習の兆候が無かった以上、容量やステップは原因ではない。この2点を反映したデータで学習し直して、かなが出るかを次の学習で確かめる。

v2を学習し直してかなが出た

キャプションを直したv2を同じBlackwell環境で学習し直し、ローカルComfyUIで各epを比べた。かなが出た。全キャラを髪・目無記述に揃えた効果で、kanachan のサイドポニーがトリガー本体に覚え込まれ、けいに取り込まれなくなった。前回v1で汎用の長髪娘になっていたかなが、3体でもサイドポニー＋アホ毛＋茶髪で本人として出る（採用したep143の出力）。

覚え込ませた属性は生成プロンプトに書いてはいけない

ところが、v2を素直なプロンプトで出すと最初はうまく分離しなかった。各キャラの外見をプロンプトに書き込むと、かなの茶が抜けて金髪が増え、サイドポニーと青シュシュが宙に浮いて別のキャラに移る。

同じep143・同じシード7で、プロンプトだけを変えた比較がこれ。左は各キャラの外見を書いた版、右はトリガー名と位置だけにした版。

原因はLoRAでなくプロンプト側だった。v2はかなの髪・アクセをキャプションから外してトリガーに覚え込ませたのに、生成プロンプトでは brown side ponytail, blue scrunchie, ahoge と属性を書き戻していた。覚え込ませた属性をプロンプトに明示すると、そのトークンはトリガーから切れて、別キャラの枠に移る。学習で直したはずのキャプション非対称を、生成時に手で作り直していた。

直しは「覚え込ませた属性は書かない」。各キャラはトリガー名と位置だけにする。これでかなは茶のサイドポニーで出て、金髪はけい1人だけになる。

ControlNetなしで密着3人を分離するやり方

このLoRAの狙いは、ControlNetもRegional Prompterも使わず、プロンプトだけで多キャラを描き分けること。実際に使っているプロンプトをそのまま載せる。

ポジティブはJSON形式で、各キャラを name／lora_trigger／position だけにする。前述の通り、覚え込ませた髪・目・服を書くと外れて隣に移る。外見は一切書かない。

{
  "scene": "three girls hugging each other tightly, cheek to cheek, close together, upper body, white background, simple background",
  "left_character":   { "name": "Kanachan", "lora_trigger": "kanachan", "position": "left" },
  "center_character": { "name": "Keichan",  "lora_trigger": "keichan",  "position": "center" },
  "right_character":  { "name": "Koharu",   "lora_trigger": "koharu",   "position": "right" },
  "rule": "three different girls, keep each girl visually distinct, do not mix or merge them, each girl keeps her own appearance"
}

ネガティブ。1girl, solo と 2girls, 4girls を両方ネガに入れると、人数が3人に固定される。

worst quality, low quality, lowres, blurry, jpeg artifacts, bad anatomy, bad hands,
fused fingers, fused limbs, extra arms, conjoined twins, merged faces, deformed face,
1girl, solo, 2girls, 4girls, monochrome, text, watermark, signature

生成設定。

項目	値
ベースモデル	Anima-Base v1.0
キャラLoRA	anima-trio-v2 ep131 / strength_model 1.0 / strength_clip 1.0
高速化	Turbo LoRA併用（8-step）
サンプラー / スケジューラ	er_sde / simple
CFG	1.0
解像度	1024×1024（832×1216でも可、一発率は同等）
シード	ランダム

調整するのは3つだけ。外見を書かない・LoRA strength_model はフル1.0（下げるとけいの金が薄茶に退色する）・cfgは上げない（3〜10へ上げるとこはるのショートが伸び、シュシュが全員に出てしまう）。多キャラを1本のLoRAに詰めている以上、各キャラの素性はトリガーが持っている。プロンプトで上書きしようとすると外れて隣に移る。

各エリアを文章で区切る

この構造は、祭禍（@saika_aiart）がXで公開していた、DiT系モデル向けの複数キャラ描き分けプロンプトが下敷きになっている。LoRAを使わず、外見をプロンプトに書いて複数体を出す人も同じ書き方をしている。要点は2つ。

空間ラベルでエリアを宣言する。 left side: / center: / right side: で各キャラの居場所を先に決める。far left / center left / center right / far right まで細かく割れば、4〜5人まで比較的安定する。

カンマのタグ羅列をやめ、自然文で各エリア内にまとめる。 character A, blue hair, techwear のように単語を並べると、AIがどっちのキャラの指示か判別できず、青髪やテックウェアが隣のキャラに移ってしまう。代わりに「主語（a girl）＋代名詞（she）＋動詞」の文で書くと、そのエリア内でプロンプトが完結する（文章で固定する）。個別ポーズも、末尾にまとめず各エリアの文中に直接書く。

LoRAなしなら、この外見記述をそのまま文章で書く。

masterpiece, best quality, two girls standing in a classroom.
left side: a girl with long blue hair tied in a side ponytail, she is wearing an oversized cardigan, she is looking at the viewer.
right side: a girl with short red hair, she is wearing a black blazer, she is smiling and waving.
soft afternoon light, depth of field.

このLoRAでは、a girl with long blue hair ... の外見記述部分をトリガー名に置き換えるだけだ。アイデンティティは学習済みなので、外見を書くと外れる。上のJSONを自然文に直すとこうなる。

three girls hugging each other tightly, cheek to cheek, upper body, white background, simple background.
left side: kanachan, she is hugging the others.
center: keichan, she is in the middle.
right side: koharu, she is on the right.
keep each girl visually distinct, do not mix or merge them.

構造（空間ラベル＋she縛り）はsaika式、外見の中身はトリガーが持つ。混線とキャラ重複を抑えるのはこの「エリア内で文をまとめる」書き方で、これはLoRAの有無に左右されない。

ここまでで分かったことを並べると、複数キャラを1枚に出すのに、キャラLoRAを複数積むだけでは混ざる（3キャラを1本に詰めたのはそのため）。そのうえで、Illustrious系のタグ羅列プロンプトではAnimaは描き分けてくれず、空間ラベル＋自然文でエリアを区切る指定が要る。アイデンティティをLoRA、配置をAnima向けプロンプトに分担させて、初めて密着でも分離する。LoRAだけだと混ざり、プロンプトだけだと各キャラの素性が出ない。

一発率とepの当たり、過学習はかなの色から崩れる

固定シード1枚で「描き分けられた」と言うのは弱い。実運用で大事なのはランダムシードで何枚出して何枚まともかだ。解像度は832×1216でも1024×1024でも一発率はほぼ変わらない（良いepなら6/6）。1024で1枚崩れたのを見て「正方は崩れる」と早合点したが、ランダム6枚で出すと832と同率で、あれは単にシードのハズレだった。

ep別の一発率（1024×1024・各6枚ランダム・トリガーのみ・ウェイト1.0。かなの茶が真の茶のままかを基準に採点）。

ep	3人別人	かなの茶	失敗（人数増・色化け）	判定
119	6/6	真の茶	0	◎
131	6/6	真の茶	0	◎
143	6/6	真の茶	0	◎
147	6/6	暖色寄りが出始める	0	○
160	4/6	暖色/混在	1（金髪重複）	△
170	~4/6	暖色	2（けいにアホ毛＋シュシュ移り）	△
180	~5/6	オレンジ大半	1（かな→金髪）	△
190	~5/6	常時オレンジ	1（金髪重複）	△

頂点は「点」ではなく平らな帯で、ep119〜143が全部6/6。退色（かな→オレンジ）と失敗はep147あたりから始まり、160以降で顕著になる。事前に「マルチ多＋rank256で過学習が早い」と見込んでいた通り、ep147から崩れ始めた。様子見で継続学習したep151-190は完全に過学習域で、この用途では使えない。

崩れ方が示唆的で、最初にオレンジへ退色するのは、唯一キャプションに属性を書いていたかな。トリガーに覚え込ませた kei/koharu（無記述）は最後まで保たれる。キャプション非対称は、立ち上がりの弱さだけでなく、過学習時にどのキャラから崩れるかにも出る。

同一シードでep143まで詰める

ep119/131/143はランダム6枚だとどれも6/6で並び、これだけでは1本に絞れない。そこで同じ10シードを3つのepに使って1対1で比べた。同一ノイズに対してどのepが保ち、どこで崩れるかを直接見る。

ep	同一10シードの保持	崩れたシード
119	9/10	シード42（かなが銀髪ロングの別人になる）
131	9/10	シード42（同じく銀髪化）
143	10/10	なし

ep119とep131が揃って落とすシード42を、ep143だけが保持した。崩れ方は色の退色ではなく、かなが丸ごと別人（銀髪・赤紫目）に置き換わるアイデンティティ崩壊で、これが出ると即アウトだ。

ep143は平らな帯の右端、暖色化が始まるep147の直前にあたる。この帯の中では学習が進むほど難シードへの耐性が上がり、過学習に入る手前のep143が最も安定する。

実用ラインは ep143（帯の右端）＋ トリガーのみ ＋ ウェイト1.0 ＋ Turbo cfg1.0。この条件なら密着3人を一発率10/10で出せる。v1で「お蔵入り→re-bake」としたところから、v2はControlNetなしで実用レベルに達した。

このep143・トリガーのみ・ウェイト1.0で出した実例を並べる。シードを変えても3人が別人で揃い、かなは茶のサイドポニーで出る。

2人ペアは記述プロンプトで描き分けられる

2人の描き分けは、各キャラを「トリガー名＋見た目」の自然文で1人ずつ書き、服指定を3組で共通に固定すると安定する。下の3組はすべて同じ服指定（both wearing crisp pure white shirts）で出して、別人に分かれ、身長差まで出ている。

masterpiece, best quality, very aesthetic, vivid colors, 2girls, keichan is a blonde girl with blunt bangs, hair intakes, a blue ribbon and blue eyes; kanachan is a brown-haired girl with a side ponytail, an ahoge and a blue scrunchie; both wearing crisp pure white shirts

相手をこはるに替えるときは、けいの記述部分をこはるの記述（koharu is a girl with short messy black hair, a blue ribbon and red eyes）に入れ替えるだけで、服指定はそのまま固定する。

接触させても特徴は入れ替わらない

同じ記述プロンプトの末尾に、自然文でハグを足すだけでよい。位置ラベル（left / right）は付けない。

... both wearing crisp pure white shirts, the two girls are hugging each other tightly, cheek to cheek

3組とも、密着させても各キャラの特徴は入れ替わらず、別人のまま保たれた。接触部の髪がわずかに混じることはあるが、完全分離は難しく、特徴の入れ替えや顔の融合が起きていなければ実用上は問題ない。以前「2人だと混ざる」と見えたのは、この記述プロンプトを使わずに接触へ位置ラベルを足したり描写を端折ったりしていたためで、LoRA側の問題ではなかった。

密着で成立するのは、ハグ・手繋ぎ・肩抱き・おんぶ・姫抱っこ・立ち並びのように分離して積み重なる絡みまで。膝乗せのように脚が融合する構図や、腕・指を絡める交差ポーズは、ベースとQwen3テキストエンコーダの空間理解の限界でLoRAでは直せない。

複雑なシーンも自然言語で足せる

各キャラの描写をしっかり固定しておくと、その上に場所・状況・小道具・関係性を自然文で重ねられる。下は「学校の教室で掃除中、かなとこはるが掃除道具で対峙し、けいが離れて怒っている」シーンを 1536×864（16:9）で出したもの。Animaは1024に収めなくてもこのサイズを出せる。

masterpiece, best quality, very aesthetic, vivid colors, 3girls, in a school classroom during cleaning time, kanachan and koharu are playfully facing off with their cleaning tools; kanachan is a brown-haired girl with a side ponytail, an ahoge and a blue scrunchie, she is holding a broom and pointing it toward koharu; koharu is a girl with short messy black hair, a blue ribbon and red eyes, she is holding a mop and pointing it back; keichan is a blonde girl with blunt bangs, hair intakes, a blue ribbon and blue eyes, she stands apart in the background, empty-handed, angry and scolding the other two; all three wearing crisp pure white shirts

3人とも別人で保持され、教室・掃除道具・対峙のポーズまで出ている。小道具を「剣のように」と書くと箒が剣に変形してしまうので、「持っている」と素直に書くほうがよい。一方で「誰が何を持つ・誰が傍観する」という個別アクションの割り当ては3人同時だとまだ弱く、けいを手ぶらにしきれないことがある。アイデンティティが強く定着している分、シーン記述は反映されるが、細かいアクション分担はこれから詰める点になる。

アニメOPパロのポーズも自然文で付けられる

描写を固定したまま、解像度を1536×1536に上げ、クオリティタグ（amazing quality, very aesthetic, absurdres, highres, ultra-detailed）を増やしたうえで、アニメのOPでよくある集合ポーズを自然文で指定してみた。3人とも別人で保持され、ポーズも無理なく反映される。

ここで一度ハマったのが服指定の書き漏らしだった。all three wearing crisp pure white shirts のように上半身だけ書くと、スカートに色が付かず白っぽいまま出てしまう。下まで明示して初めてネイビーのプリーツが描かれる。

all three wearing crisp pure white dress shirts and navy blue pleated skirts

ポーズ部分は3girlsの直後に自然文で入れる。下は「空を指差す」「夜の繁華街で振り返る」「薔薇の花びらが舞う」「全員でジャンプ」の4種。

masterpiece, best quality, amazing quality, very aesthetic, absurdres, highres, ultra-detailed, vivid colors, 3girls, all three pointing one index finger high up to the sky together with fired-up determined expressions, kanachan is a brown-haired girl with a side ponytail, an ahoge and a blue scrunchie; koharu is a girl with short messy black hair, a blue ribbon and red eyes; keichan is a blonde girl with blunt bangs, hair intakes, a blue ribbon and blue eyes, all three wearing crisp pure white dress shirts and navy blue pleated skirts

うまくいかない方向もはっきりした。「主要キャラを右斜め下のローアングルから撮るきららジャンプ」のようなカメラ角度はプロンプトだけでは動かせず、何度出しても正面寄りになる。Animaの正面バイアスが強く、角度を変えるならControlNetのポーズ指定が要る領域になる。個別アクションの割り当てが3人同時だと弱いのも掃除シーンと同じで、こはるの髪にかなの青シュシュが薄く滲んだり、リボンの色が赤と青でばらついたりする弱い混線も残る。それでも、描写を固定したうえで状況とポーズを自然文で重ねれば、複雑な構図でも3人の描き分けは保たれる。

参考リンク

• Anima 2キャラ合体LoRAでアホ毛移りと融合を消す（rank128＋2体データ）
• WAI-Anima向けキャラLoRAの学習キャプションを書き直す
• AnimaLoraToolkit + RunPod で LoRA を学習する