Animaで作った画像だけでAnimaのオリキャラLoRAを学習したら、ep20で収束した

前回 kanachan の LoRA を Anima 向けに4本記事跨いで詰めた 結果、「1枚あたり露出 600〜720 回（= repeats × epochs）がスイートスポット、NL を必ず入れる、色情報はトリガーに吸収」というレシピが ep150/180 で方向ヒット率 100% を出した。この時の検証はキャラ1体（kanachan）でしかやっていないので、別キャラでも同じレシピが効くのか が次の問い。

今回は2人目のキャラ「ケイちゃん」を焼く。素材は事前に生成した91枚を目視で選別したもの。kanachan が53枚だったので、量は1.7倍。

なぜケイちゃんか

ケイちゃんはこういうキャラ。

• 金髪
• エアインテーク（前髪両脇の前方向きスクープ）が強めに出ているのが識別キー
• そのインテークが長い（肩より下まで届く）
• 前髪はぱっつんだが、インテーク部分が長いので結果的に姫カットには見えない
• サイドから後ろにかけてはハーフブレイドアップ
• 後ろ髪は青リボンでまとめている
• 国籍は意図的に曖昧（外国人にも日本人にも見えるライン）

エアインテークは Anima では単独タグや NL 記述では発火しない。別記事の Anima ヘアインテーク移植レシピ で水瀬名雪を参照に立てて発火させる3段重ねレシピを作ったが、これは推論時のテクニックで、毎回 minase nayuki を positive に置いてアイデンティティ要素を negative で剥がす運用が必要になる。

LoRA に焼ければこのレシピごとキャラに紐付けられて、keichan トリガーだけで安定してインテークが出るはず。レシピを毎回手で組み立てる運用から脱せる、というのが LoRA を焼く実利的な動機になる。

学習素材

構図別に3分類した91枚。

フォルダ	枚数	構図
01_bust_front	39	バストアップ・正面
02_clothed_pose	47	着衣・全身・各種ポーズ
03_nude_angles	5	ヌード・各種アングル

各画像はWAI-Anima v1.0で生成されたもの（同じく keichan 学習に使うベースモデル）。同モデル内自家中毒の懸念は一応あるが、kanachan のときも素材は IL 生成画像で IL に焼いて回ったので、今回も同じ前提で進める。

各画像にはJSONサイドカーが付いていて、生成時の英語プロンプトが残っている。中身はDanbooruタグの羅列で、自然言語記述は含まない。代表的なポジティブはこれ。

1girl, solo, teenager, blonde hair, long hair, blue eyes, blunt bangs,
(hair intakes:1.5), long sidelocks, half updo, braid, blue ribbon,
bare shoulders, nude, bust shot, head and shoulders, face focus,
close to head, front view, looking at viewer,
simple background, white background, flat color, even lighting,
ambient lighting, plain lighting, studio lighting,
official art style, clean lineart

(hair intakes:1.5) を強調していたのは Anima が単独で出さないためで、これでも生成は不安定。「インテークが出ているもの」を目視で選別済みなので、残った91枚は全て可視前提で進める。

ネガティブは minase nayuki, blue hair, navy hair, black hair, dark hair, (ahoge:1.5), antenna hair, (hime cut:1.3), (crossed bangs:1.4), parted bangs, swept bangs, short sidelocks, short hair, (mature:1.3), (adult:1.3), milf, ... という構成。インテーク移植レシピで minase nayuki をいったん positive 参照にしてから、negative で名雪のアイデンティティ要素（青髪・大人っぽさ・別の前髪形）を剥がす作りになっている。LoRA 焼き付け後はこの negative 戦術は不要になる想定。

キャプション設計方針

kanachan 4本記事の教訓 を踏まえて以下で組む。

トリガー語

keichan。kanachan と同じくスペース無し小文字一語。

キャラ核心 → トリガーに吸収（キャプションから抜く）

• blonde hair, blue eyes — kanachan の brown hair brown eyes 削除で髪色が学習素材通りに安定した教訓の踏襲
• hair intakes — これがケイちゃんの最大の識別キーなのでトリガーに吸い込ませる
• 顔の造形・年齢感・体型基本 — トリガーに紐づける

hair intakes をタグ側に残さない判断は、運用上の対称性で決めた。トリガーに吸収させておけば keichan 一語で出る、もし出が悪ければ推論側で hair intakes を手で足せばいい。逆にキャプションにタグを残すと「keichan 単独ではインテークが弱い」リスクが残る。発火しにくいタグだからこそ、補助線として推論時に追加できる選択肢を残しておいた方が運用が楽になる、という整理。

独立タグで残す

• blunt bangs
• long sidelocks
• half updo
• braid
• blue ribbon

自然言語ブロック

各画像に2文以上、構図と髪型構造を別文で描く。

共通構造

文1: 構図・ポーズ・表情・視線の描写
文2: 髪型構造（インテーク + ブレイド + リボン）の描写

主語表現は kanachan に揃えて a young girl。teenage high school student 16 years old のような年齢具体タグは元プロンプトに含まれていたが、kanachan で使わずに済んだので今回も入れない。

バリエーション例

正面バストアップ

A close-up portrait of a young girl with a {expression} expression looking at the viewer. Her long, thick hair intakes hang down past her shoulders on both sides of her face below her blunt bangs, and a half-up braid wraps around the back of her head, tied with a blue ribbon.

正面全身

A standing front view of a young girl {pose}, with a {expression} expression. Her long hair intakes fall on both sides of her face below her blunt bangs, and her hair is gathered into a braided half-updo at the back, secured with a blue ribbon.

斜め45度

A three-quarter view of a young girl with her body turned slightly. Her long hair intakes are visible on both sides of her face below her blunt bangs, and the half-up braid wraps around the side of her head toward the back where it is tied with a blue ribbon.

横プロファイル

A side profile of a young girl, her body facing {left/right}. One of her long hair intakes is visible falling beside her cheek below her blunt bangs, and the half-up braid runs along the side of her head to the back, tied with a blue ribbon.

後ろ姿

A view from behind of a young girl. Her braided half-updo runs along the back of her head, secured with a blue ribbon at the nape, and the ends of her long hair flow below.

NL設計のポイント

課題	対処
姫カット解釈の混入リスク	”long, thick hair intakes hang down past her shoulders” で長さを強調
bound hair の「縛られた人物」誤解釈	使わず half-up braid secured with a blue ribbon で記述
インテーク発火の不安定さ	NL に毎回明記してトリガーに焼き込む（タグは省略、必要時に推論で足せる）
色情報の漏れ	NL で blonde blue eyes には触れない
方向制御	左右対称髪型なので方向問題は小さい。視点（正面/側面/背面）だけ明示

胸サイズタグの方針A（kanachan 踏襲）

画像で胸のシルエットが視認可能な場合のみ medium breasts を付ける。

フォルダ	扱い
01_bust_front 39枚	バストアップ・肩までなので原則なし
02_clothed_pose 47枚	タイト衣装・水着等でシルエット可視のもののみ
03_nude_angles 5枚	全件 medium breasts

ルーズな着衣の画像にタグだけ載せると「画像と矛盾するキャプション」になる（kanachan の bikini/nude 入れ替え事件のような濁りリスク）ので、原則「画像にちゃんと写っているものしか書かない」を貫く。

体型シルエット系タグは省略（方針A1）

元プロンプトに大量にあった developed body, slim figure, curved waist, proportional body, womanly figure などのシルエット強調タグはキャプションから全部抜く。ベースのデフォルトでも普通に出る属性で、学習する必要が薄い。

強調ウェイトは全部外す

(hair intakes:1.5) のような重み付きタグは推論時の操作で、学習キャプションには平タグで十分。kanachan のときも重みは使っていない。

品質プレフィックス

masterpiece, best quality, score_7, [safe/sensitive/explicit],

safe を使う（general ではない）。レーティングは画像に応じて safe / sensitive / explicit を振り分ける（着衣 → safe、ヌード → explicit、その他 → sensitive）。

最終キャプションテンプレート

masterpiece, best quality, score_7, [safe/sensitive/explicit],
1girl, solo, keichan,
{NL 2文}
blunt bangs, long sidelocks, half updo, braid, blue ribbon,
{表情/ポーズ/衣装/構図タグ},
[medium breasts (該当画像のみ)],
white background, simple background

学習量プラン

kanachan で確立した公式は repeats × epochs ≈ 600〜720（1枚あたり露出回数）。

91枚だとこうなる。

repeats	epochs	合計step（実効）	1枚あたり露出
4	150	91 × 150 = 13,650	600回
4	180	91 × 180 = 16,380	720回

repeats 4 で固定（kanachan と同じ）、epochs は 150〜180 をターゲットにして、save_every: 1 で各エポックの LoRA を残し、ローカル ComfyUI で検証する流れにする。

公式推奨の絶対step数「12,000+」は kanachan のときに53枚で過剰だと判明したので、91枚でも素材枚数で割った「1枚あたり露出」基準で考える。合計step は結果論で 13,650〜16,380 になる、というだけ。

学習設定（YAML予定）

kanachan v4 の YAML から差分のみ。

- output_dir: "/workspace/output/rework-v4"
- output_name: "kanachan-waianima-rework-v4"
+ output_dir: "/workspace/output/keichan-v1"
+ output_name: "keichan-waianima-v1"

- # データセットパス（kanachan用）
+ # データセットパス（keichan 91枚）

  epochs: 150  # または 180
  learning_rate: 2.0e-5  # kanachan v4 と同じ、Anima公式推奨
  save_every: 1
  sample_every: 1
  flip_augment: false
  shuffle_caption: false
  keep_tokens: 1
  rank: 32
  repeats: 4

サンプルプロンプトはスイートスポット検証の N 形式に揃える。

masterpiece, best quality, safe, 1girl, solo, keichan,
A close-up portrait of a young girl looking at the viewer.
Her long hair intakes hang down past her shoulders on both sides of her face,
and a half-up braid wraps around the back of her head, tied with a blue ribbon.
blunt bangs, half updo, braid, blue ribbon,
upper body, looking at viewer, white background, simple background

残る決定事項

• repeats 4 / epochs 150 か 180 か（最初は 180 で広めに撃ってスイートスポットを含めるのが安全）
• ネガティブプロンプト（サンプル生成用）で ahoge / hime cut / minase nayuki などを引き継ぐか
• 学習画像の解像度バケット設定（kanachan のままで動くはず）

検証計画

学習完了後、kanachan v4 と同じ3形式マトリクスをかける。今回見るのは方向ではなくインテーク発火率。

形式	確認すること
K（トリガーのみ）	keichan 一語でインテークが出るか（本命）
N（NL併用）	NL の “long hair intakes hang down…” を足したら発火率が上がるか
KT（トリガー + hair intakes タグ補助）	推論で補助線足したときに発火率が上がるか

各形式 × seed 3パターン × ep複数 = 9〜27枚のマトリクスで「インテークが安定して出るエポック範囲」をスイープする。kanachan のスイートスポット ep150〜180 と同じ範囲に一致するかが目玉。形式K で安定して出ればトリガー吸収成功、出ないなら形式KT の補助で出るかを確認、それでもダメならキャプション設計の見直し。

副次的に見たいものはこれ。

• 国籍感（外国人寄り/日本人寄り）が keichan トリガーで安定するか
• ハーフブレイドアップが正しく後ろに回るか（独立タグ化の検証）
• 推論時に minase nayuki 参照テクニックを使わずに済むか（本記事の主動機）

---

ここまでで学習データ作成方針は固まった。次は91枚分のキャプション実装に入る。

キャプション実装

JSON サイドカーから一括生成

各画像に付いている JSON サイドカーには元の英語プロンプト（Danbooru タグの羅列、自然言語なし）が入っている。これをパースして、設計方針どおりのキャプションに組み直す Python スクリプトを書いた。

抽出と分類のロジックはこうなっている。

• 重み付き (tag:1.5) を平タグに正規化
• 構図キーワード（bust shot / three quarters view / full profile / from behind / cowboy shot / upper body / full body）から構図種を判定
• 向きキーワード（body turned to the left/right, looking to the left/right, body facing left/right）から向きを判定
• 表情タグを優先順位リスト（angry > annoyed > frown > smile > calm > neutral …）でマップ
• 衣装タグ群から1個の代表衣装ラベル（nude / school_swimsuit / bikini / gym / leotard / tshirt / dress / yukata / preppy / uniform）を選別
• レーティングを衣装ラベルから導出（nude → explicit、bikini/swimsuit/leotard/gym → sensitive、それ以外 → safe）
• medium breasts は 体型可視 + 露出系衣装 の組み合わせの時だけ追加（kanachan v3 踏襲）

NL は構図種ごとのテンプレートに {expression} {facing} を埋める形で固定し、各画像2文以上を保証。バストアップは「A close-up portrait of a young girl with a {expression} expression…」、斜め構図は「A three-quarter view of a young girl with her body turned slightly to the {facing}…」のように構図ごとに切り替える。

スクリプトを走らせて91枚分の .txt を一発で書き出した。

39 枚のバストアップは表情だけ可変

01_bust_front/available の39枚は元プロンプトを集計すると 全枚が front view, looking at viewer, bust shot, head and shoulders, face focus, close to head で完全同型。sideways glance が4枚あるだけで、構図のブレはゼロ。

つまりキャプションは39枚すべて同じテンプレで、可変なのは表情1スロット。表情判定一覧を1枚の表にダンプして、Finder のサムネ表示と並べて 39 枚を一気にチェックした。表情の取り違えはなく、39枚分は確定。

03_nude_angles の5枚はキャプションを目視確認

5枚しかないので手で1枚ずつ画像を見て、full body / three quarters view / side profile / from behind の判定が正しいかを直接確認。全枚で足のつま先まで写っていて Danbooru の full_body 定義を満たしている、向き判定も合致。修正なし。

47 枚の着衣ポーズは Codex CLI でフレーミング検証

問題は 02_clothed_pose/available の47枚。バリエーション（衣装 8種、構図混在）が一番多い。元プロンプトは「full body で撃った」と書いてあるが、拡散モデルは full body 指定を平気でカウボーイショット（腰〜太もも切り）に落とすので、実画像が指示通りに出ているかが不確実。

最初は Gemini CLI で画像チェックを試みたが、水着画像で安全フィルタに止まる懸念が出たので Codex CLI に切り替え。-i オプションで画像を添付して codex exec に投げる構成。

検証プロンプトはこういう形（出力が表記揺れしないように「一致しないものだけ FIX に書け」と明示する必要があった）。

Verify this LoRA caption against the attached anime-style image of a single girl.
Caption: ---{caption}---
The original generation prompts often requested poses the model didn't deliver,
so judge from the IMAGE, not from caption assumptions.

Check ONLY these aspects:
A. FRAMING — bust / upper body / cowboy shot / full body / three quarters / side profile / from behind
B. BODY FACING (viewer's perspective) — left / right / forward / back
C. EXPRESSION — does the caption's expression tag match the face?

Output format — exactly one line:
- All match: "OK"
- Any mismatch: "FIX: <letter>=<what image actually shows> (caption says <claim>), ..."

47枚を並列6で投げて1分48秒。結果は 18 OK / 29 FIX。FIX の内訳はこうなった。

種類	件数
A=cowboy shot（caption says full body）	22
A=three quarters view（caption says full body）	5
B=forward（caption says left/right）	4
B=left（caption says right）	1
C=neutral（caption says softly smiling）	1

ほぼ全部「full body 指定したのにカウボーイショットで出ていた」パターン。(three quarters view:1.5) で 1.5 倍の強調をかけても、Anima ベースのデフォルトのフレーミング癖（腰から上寄りに収束する）が勝つことが多い、というのが今回のデータポイントとして取れた。

Codex の Danbooru 厳密判定 vs 目視印象

Codex が「29枚 FIX」と言うのは少し多すぎる気がしたので、実画像を1〜2枚開いてみた。010800（カウボーイ判定）は確かに膝より上で切れていて、足首が見えない構図だった。011541（OK 判定）は座り姿で足の指まで見えていた。

Codex は Danbooru の full_body 定義（足が見える）に厳密に従って判定していて、人間の「ほぼ全身入ってる」という感覚とは別の物差しで切っている。Anima/Qwen3 TE は Danbooru タグで学習されているので、LoRA キャプションも Danbooru 寄せにする方が学習効率は良い。full_body という概念を「足首切れ画像」と結びつけて学習させると、推論時に full body 指定しても腰上で出る LoRA になりかねない。

ただし境界線（膝下で切れているがほぼ全身に見える、など）は人間の判断のほうが信頼できるので、Codex の結果を機械的に適用するのではなく、自分の目で見てフォルダ分けする手順に切り替えた。

フォルダ分けで決着

02_clothed_pose/available/ 直下に full_body/ / cowboy_shot/ / upper_body/ の3サブフォルダを切って、47枚を手で振り分けた。結果はこうなった。

フォルダ	枚数
full_body/	21
cowboy_shot/	24
upper_body/	2

これを正解として、各 .txt のフレーミングタグを更新するスクリプトを書いた。書き換えロジックはシンプル。

• full_body/ に入っている21枚は既存キャプションが full body タグを持っているので変更不要
• cowboy_shot/ に入っている24枚は、22枚が full body を持っていたので cowboy shot に置換、残り2枚は元から cowboy shot で正しかった
• upper_body/ に入っている2枚は元から upper body タグで正しかった

NL は構図種ごとに「three-quarter view of a young girl」「side profile of a young girl」「view from behind of a young girl」のように方向描写になっており、フレーミング情報（足が見えるかどうか）には触れていない。なので NL は触らずタグ列の1単語だけ置換すれば足りる。

最終状態

カテゴリ	枚数	状態
01_bust_front (バストアップ正面)	39	テンプレ固定、表情のみ可変
02_clothed_pose full_body	21	full body タグ
02_clothed_pose cowboy_shot	24	cowboy shot タグ
02_clothed_pose upper_body	2	upper body タグ
03_nude_angles	5	全枚 full body

合計 91/91 が画像内容と整合した状態でキャプションが揃った。hair intakes はトリガー吸収方針なのでタグ列には入れず、各画像の NL に「Her long, thick hair intakes hang down past her shoulders…」のように毎回明記して二重に焼く構成（タグ側に置かないのは、出ない時に推論プロンプトで補助線として足せる選択肢を残すため）。

副産物の知見

• 拡散モデルは full body を指示してもデフォルトのカウボーイ収束に負けることが多い。(full body:1.5) で1.5倍重みをかけても、本記事素材の場合は47枚中24枚（51%）がカウボーイで出ていた。学習素材作りの段階で「full body で撃ったから full body で揃っている」と思い込むのは危険、Anima 系では特に
• Gemini CLI は水着画像で安全フィルタに止まる（試した範囲）。Codex CLI （ChatGPT 認証経由）は同じ画像が通った。NSFW 寄り素材の検証パイプラインに使うなら Codex 側のほうがハマりが少なそう
• Codex の Danbooru 厳密判定は人間の日常的な感覚とずれる。full_body の境界は「足首まで見えるか」で機械的に切られるので、学習素材を Danbooru 寄せで揃えたい場合は機械判定を採用、見た目の自然さで揃えたい場合は人間判定、と用途で使い分けが必要

RunPod 学習

新ツール・新レシピのサーベイ

kanachan v4 を書いてから1ヶ月、Anima 周辺で新しい話が出ているのは把握していたので、走る前にいったん見直した。

新要素	公開	うちの91枚キャラLoRAタスクに効くか
kohya-ss/sd-scripts の Anima 対応（networks.lora_anima / anima_train_network.py）	2026春	❌ ツール切替コストが上回る。レイヤー別ランク制御は実装されたがキャラLoRA向けガイダンスなし
neme-anima（3-step LoRA builder）	開発活発	❌ 動画→クロップ前提。うちは静止画91枚
Anima-LoRA-Factory v2.2	2026-04-25	❌ GUI + Blackwell sm_120 対応が売り。CLI派 + RTX 6000 Ada のうちには恩恵が薄い
AnimaLoraToolkit に LoKr 追加	直近	❌ Anima × LoKr × キャラLoRA の実績まだ無い。変数増やすと kanachan 比較が崩れる
Differential Output Preservation のコミュニティ実装（Anima Discussion #60, by cpbmc）	直近	△ 破滅的忘却対策の本命路線、ただし 600+ 枚の正則化画像 + パッチ必要 + 3倍遅い
Anima公式コンセンサス「3000-4000 step で劣化が始まる」	同 Discussion #60	❌ kanachan v4 実測（ep100=5,300 step まだ立ち上がってない、ep150=7,950 step がスイートスポット 100%）と矛盾。素材枚数別解像度がない汎用論

新しいの色々出てるが、91枚で1キャラ焼くという具体タスクに対しては、kanachan v4 で出した実測ベースを上回る根拠を持つ選択肢が無い、というのがサーベイ結論。エビデンス合わないんだよなあ、というのが正直な感想。

DOP だけは本筋っぽいので将来検討に残す。ただし「DOP 入れたら良くなる」を確かめるには、まず DOP 無しのベースライン（= kanachan v4 リプレイ）が同じデータで再現することを示してからじゃないと、改善寄与の切り分けができない。本記事ではそのベースラインを取る位置付け。

そもそも DOP の前提として「600+ 枚の関係ない画像」を正則化用に用意しろという要求自体が、キャラ LoRA 1本焼くついでにやるレベルを超えていて、これは「Anima ベースのバイアスに打ち勝つにはそれくらいやれ」という側のメッセージにも読める。逆に言えば、Anima の方向性をねじ伏せるには素材が多くないと無理、ということでもある。

ただ実運用観測として、kanachan を Anima Turbo LoRA と併用した別記事 では Turbo LoRA（8 steps, CFG 1.0 の高速 LoRA）を当てている状態で kanachan の特徴は普通に出ている。Turbo LoRA が破滅的忘却由来の細かいズレを均す方向に効いている可能性があり、推論側で実用に耐えるなら DOP まで踏み込まなくても運用可能、という現実解は既に取れている。本記事でも検証は Turbo LoRA 併用で見るので、ベースが「DOP無しのキャラ LoRA × Turbo LoRA」の組合せで実用ラインに乗れば、それで結論として十分。

というわけで、ツールチェーンも YAML も kanachan v4 を踏襲、変えるのはデータと出力名だけ。

GPU は今回も RTX 6000 Ada

ハードも kanachan v4 と同じ RTX 6000 Ada (48GB) を継続する。当然 RTX 5090 (Blackwell, sm_120) を使えば1.5〜2倍速くなる可能性があるので考えたが、現状そこに賭ける根拠が弱い。

GPU	単価/h	VRAM	想定時間	総コスト	リスク
RTX 6000 Ada (48GB)	$0.77 オンデマンド	余裕（必要量 10.8GB）	約14.7h	約$11	ほぼなし、kanachan v4 実績
RTX 5090 (32GB)	$0.99 オンデマンド / $0.69 スポット	余裕（同上）	約8h	$8 / $5.5	torch + AnimaLoraToolkit の cu128 セットアップ未知数

主な詰まりポイントはこれ。

• PyTorch の sm_120 サポートが2026年5月時点でまだ安定版に来ていない。cu128 ビルドや 2.9.0 で動くという話はあるが、いきなり pip install torch だと no kernel image is available for execution on the device で吹き飛ぶ
• AnimaLoraToolkit の Blackwell 動作実績が公式 README や Issue に書かれていない。同じ Anima 系でも GUI 寄りの Anima-LoRA-Factory v2.2 は明示的に Blackwell 対応を謳っているので、Anima エコシステム自体は対応進行中だが、AnimaLoraToolkit のほうがいつ追従するかは未確認
• xformers は kanachan v4 で cu130 地雷を踏んだので相変わらず避ける必要があり、Blackwell でも同じ判断になる

さらに実験設計の観点から、kanachan v4 と同じハードを使うほうが結果差を「データ・キャラの違い」に絞り込める。5090 にすると it/s が違うので「学習進行速度が違ってスイートスポット位置がズレた」みたいな解釈余地が入る。本記事の主問いは「kanachan v4 のレシピが別キャラでも成立するか」なので、ハードは固定したい。

コスト差は最大でも $5〜6。これは「ハードを変数化しない」という実験条件をそろえることの対価としては安い。

Blackwell 検証は別記事の話題で、今のところ「AnimaLoraToolkit に Blackwell 対応 PR が来た」「cu128 で安定動作した検証ログが出た」のどちらかを観測したら踏み込む予定。

YAML 差分（実値）

AnimaLoraToolkit の v4 YAML から差分のみ。

- # Kanachan LoRA on WAI-Anima v1 - Caption rework v4 (long training: 12k+ steps at 2e-5)
+ # Keichan LoRA on WAI-Anima v1 - First training pass (replicating v4 recipe on 91 images)

- output_dir: "/workspace/output/rework-v4"
- output_name: "kanachan-waianima-rework-v4"
+ output_dir: "/workspace/output/keichan-v1"
+ output_name: "keichan-waianima-v1"

- # Dataset: kanachan 53 images
+ # Dataset: keichan 91 images (39 bust + 47 clothed + 5 nude)

- epochs: 227
+ epochs: 180  # target sweet spot range (1枚あたり露出 = repeats 4 × ep 180 = 720)

  learning_rate: 2.0e-5     # 同上
  repeats: 4                 # 同上
  rank: 32                   # 同上
  save_every: 1              # 同上
  sample_every: 1            # 同上
  flip_augment: false        # 同上
  shuffle_caption: false     # 同上
  keep_tokens: 1             # 同上

epochs を 180 にしたのは、kanachan v4 結果からスイートスポットが ep150/180 の両方で 100% だったので、より深い ep180 をターゲットにして、その手前（ep120/150）と ep200/215 も save_every: 1 で取り、本番後のスイープに使う想定。227 まで延ばすのは過剰だと kanachan v4 で実証済みなので踏まない。

repeats × epochs = 720 で 1枚あたり露出は kanachan v4 のときと同条件。素材は91枚なので実効 step は 91 × 180 = 16,380。コストは kanachan v4 (12,031 step, 約 $10) × 1.36 ≒ $13〜14。

サンプルプロンプト（N形式）

トレーナー内蔵サンプラーが毎エポック1枚生成する。プロンプトは検証の N 形式に揃える。

masterpiece, best quality, safe, 1girl, solo, keichan,
A close-up portrait of a young girl looking at the viewer with a calm expression.
Her long, thick hair intakes hang down past her shoulders on both sides of her face below her blunt bangs,
and the half-up braid wraps around the back of her head, tied with a blue ribbon.
blunt bangs, long sidelocks, half updo, braid, blue ribbon,
upper body, looking at viewer, white background, simple background

hair intakes はタグ列に置かず NL でのみ言及。kanachan v4 のサンプルプロンプトと同じ思想で「トリガー一語でどこまで出るか」を毎エポック観測したいので、補助線になり得る hair intakes タグは出力に入れない。

seed は seed: 42 固定（kanachan v4 と同じ）。

ネガティブプロンプト

学習データの元プロンプトには minase nayuki, blue hair, navy hair, black hair, dark hair, (ahoge:1.5), (hime cut:1.3) などのネガティブが入っていたが、これは生成時のレシピ的ネガティブで、LoRA 学習中のサンプラー用ネガティブとは別。サンプル用ネガは kanachan v4 流用で簡素化した。

worst quality, low quality, blurry, jpeg artifacts, text, watermark, signature, 
ahoge, antenna hair, hime cut, multiple views, split view, cropped, 
nipples, areola, blood

minase nayuki は外す。学習素材生成時の参照テクニックなので、LoRA 焼き付け後のサンプル検証には不要のはず。ここが残っていると「LoRA が hair intakes を学んだのか、それとも minase nayuki 参照が暗黙に効いているのか」が切り分けられない。

データセットの転送

LoRA フォルダの中身（91 PNG + 91 TXT、約 50MB）を Network Volume 上の /workspace/datasets/keichan/ に scp で上げる。kanachan v4 のときに作った Volume はそのまま残っているので、WAI-Anima 本体・VAE・TE・AnimaLoraToolkit・依存環境はすべて生きている。

# ローカルから RunPod CPU Pod 経由で Volume へ
scp -r "/Users/hide3tu/projects/Antigravity/金髪の子/LoRA/" \
  cpu_pod:/workspace/datasets/keichan/

CPU Pod ($0.08/h) で受けて Volume に書き出す。GPU Pod ($0.77/h) を立てっぱなしで scp 待つのは無駄なので、転送中は GPU Pod を止めておく。

環境

Pod のコンテナは新規取り直すと Python 環境ゼロからになる。kanachan v4 で踏んだ xformers 依存地雷（cu130 で torch 吹き飛ばす）を避けるため、requirements.txt をそのまま pip install せず、必要な依存だけ手動で入れる。

pip install einops safetensors transformers diffusers accelerate peft \
  lycoris-lora omegaconf tqdm Pillow numpy lpips pytorch-fid pytorch-msssim \
  scipy scikit-image matplotlib pandas pyyaml psutil rich tiktoken sentencepiece \
  protobuf

pillow-jxlpy は wheel が無いのでスキップ（JPEG-XL用、今回不要）。

torch が cu124 で生きていることを確認する。

python -c 'import torch; print(torch.__version__, torch.cuda.is_available())'
# → 2.4.1+cu124 True (期待値)

tmux 起動

11時間の学習を SSH 接続維持で見続けるのは非現実、tmux で起動して切断後も走り続けるようにする。

cd /workspace/AnimaLoraToolkit
tmux new-session -d -s train \
  "python anima_train.py --config ./config/train_keichan_v1.yaml \
   2>&1 | tee /workspace/output/keichan-v1/train.log"

進捗確認は monitor_data/state.json 経由で行う。

python3 -c 'import json; d=json.load(open("/workspace/AnimaLoraToolkit/monitor_data/state.json")); \
  print("step:", d["step"], "/", d["total_steps"], "speed:", d["speed"])'

期待値はこう。学習速度 0.31 it/s（kanachan v4 と同じ GPU・同じ rank なので変わらないはず）、91 steps/epoch × 180 epoch = 16,380 step、所要時間 16,380 / 0.31 ÷ 3600 ≒ 14.7 時間。サンプル生成（30秒/回 × 180回 = 1.5時間）も加味すると合計 16時間前後。

初回起動でCPU Pod が借りられず A100 PCIe を兼用

実際に起動してみた段階で、想定どおりにいかないことが2つ起きた。

CPU Pod が借りられない。RunPod のアカウント画面で CPU Pod がどのリージョンでも軒並みグレーアウト。理由は不明（最近 GPU 専業に寄せている話は聞くので、アカウント階層の問題か CPU Pod 自体が縮小中か）。さらに GPU 選定でも RTX 6000 Ada / L40S はどのリージョンも在庫切れ、A100 (PCIe / SXM) は ca-mtl-3 に在庫があった。Volume 再作成のコストを払うなら A100 PCIe の速度メリットで相殺できるので、結局 A100 PCIe 80GB を1本だけ借りて、転送と学習を同一 Pod で兼用する構成に切り替えた。

家からの scp が想定の25倍遅い。kanachan v4 のときは「WAI-Anima 3.9GB を5分」（≒100Mbps）で上げていたが、今回は同じ家・同じ scp で 4Mbps しか出ない（理由は不明、ISP 側か RunPod 側の帯域制限か）。3.9GB に2時間かかる計算になり、A100 待機時間で $2.78 余計に乗ってしまう。

→ Pod 側から CivitAI と HuggingFace に直 DL に切り替えた。データセンタ帯域なので 240Mbps（家の60倍速）、WAI-Anima 3.9GB が2分で着地、VAE 243MB は8秒で完了。

# Pod 上で並列 DL
tmux new-session -d -s dl_anima \
  "curl -L -o /workspace/waiANIMA_v10.safetensors \
   https://civitai.com/api/download/models/2859702"
tmux new-session -d -s dl_vae \
  "hf download circlestone-labs/Anima \
   split_files/vae/qwen_image_vae.safetensors \
   --local-dir /workspace/anima_split"

CivitAI の直 DL は API トークン不要（公開モデルなので 307 リダイレクトだけ）。kanachan v4 のときは「トークン発行が面倒だから家から上げた」と書いたが、実態はトークン無くても curl 一発で取れた。次回からはこっち。

kanachan v4 と同じインストールコマンドが動かない（依存パッケージのズレ）

セットアップが終わって python anima_train.py を起動、Transformer のロード（7分）と VAE のロード（10秒）が終わって、テキストエンコーダのロード段階で 2連続クラッシュした。

1回目のクラッシュ

File "/usr/local/lib/python3.11/dist-packages/transformers/generation/continuous_batching/distributed.py", line 19, in <module>
    from torch.distributed.tensor.device_mesh import DeviceMesh
ModuleNotFoundError: No module named 'torch.distributed.tensor.device_mesh'

pip install transformers が 5.9.0（2026年5月時点の最新）を引いてきた。これは torch.distributed.tensor.device_mesh を要求していて、torch 2.5+ じゃないと存在しないモジュール。Pod のベースイメージは torch 2.4.1+cu124 なので即落ち。

「transformers を古めに固定すれば動くだろう」と考えて transformers==4.45.2 に下げて再起動。Transformer ロード（また7分）→ 2回目のクラッシュ。

ValueError: The checkpoint you are trying to load has model type `qwen3`
but Transformers does not recognize this architecture.

transformers 4.45.2 は Qwen3 サポート前のバージョンだった（Qwen3 サポートは 4.51+ で追加）。中途半端に古いバージョンに下げたせいでアーキテクチャ判定で詰まった。

根因

kanachan v4 記事に書いたインストールコマンドはこれ。

pip install einops safetensors transformers diffusers accelerate peft ...

これはバージョン指定なしで、pip が常に最新を取りに行く。kanachan v4 当時（4月）に動いたのは、その時点で最新だった transformers が torch 2.4 互換だったから。1ヶ月経った今、同じコマンドで入る transformers は torch 2.5 必須になっている。

要するに 「kanachan v4 と同じインストールコマンド ≠ kanachan v4 と同じスタック」。pip install foo は再現性のあるコマンドではない、という当たり前のことに踏み抜いた。

正しい修復路線

その場で出した解は torch 2.5.1+cu124 にアップグレードしてから最新 transformers を入れるだった。これなら通る。

• transformers 5.9.0 の torch.distributed.tensor.device_mesh 要求を満たす
• Qwen3 サポートあり
• cu124 のままなので A100 sm_80 互換は崩れない

pip install --upgrade torch==2.5.1 torchvision==0.20.1 torchaudio==2.5.1 \
  --index-url https://download.pytorch.org/whl/cu124
pip install --upgrade "transformers>=4.51,<5.0"

ただし、ここまでで Pod 時間40分・$0.93 を燃やしていて、3回目の起動が成功する保証も無いので、今日は中止して仕切り直す判断になった。

反省

• インストールコマンドではなく pip freeze のスナップショットを再現用に持つべきだった。kanachan v4 のときの正確なバージョンを requirements.txt で固定しておけば1回目から動いた
• 「同じインストールで1ヶ月前と同じスタック」と思い込んだのが甘い。pip のデフォルト挙動は破壊的に最新を取りに行くので、特に AI/ML 系のように毎週バージョンが上がるエコシステムでは1ヶ月で破綻する
• 次回の起動時は、最初の段階で依存バージョン確定 → スモークテスト（AutoModelForCausalLM.from_pretrained まで一通り走らせる）→ 本番学習、の3段階に分ける。Transformer のロード7分を待ってから落ちる、というのを2回繰り返した時間損失が大きかった

中止時点のコスト

項目	額
A100 PCIe 約40分	$0.93
Network Volume 50GB（残しておく、再開時に再 DL 不要）	$0.005/h × 残り時間
本日消費	約 $0.93

Volume は破棄せず残す。次回 Pod 起動時に同リージョンで同 Volume をマウントすれば、WAI-Anima / VAE / TE / AnimaLoraToolkit / データセット / YAML は全部生きている。次回は torch 2.5.1 アップグレード → 最新 transformers → スモークテスト → 本番起動 からスタートできる、所要 5〜10分。

次回の手順（要点）

1. 同リージョン (ca-mtl-3) で A100 PCIe Pod 起動、既存 Volume をマウント
2. 最初に pip install --upgrade torch==2.5.1+cu124 torchvision==0.20.1+cu124 torchaudio==2.5.1 等で torch アップグレード
3. pip install --upgrade "transformers>=4.51,<5.0" で Qwen3 対応の transformers を取る
4. スモークテストで python -c "from transformers import AutoModelForCausalLM; AutoModelForCausalLM.from_pretrained('/workspace/AnimaLoraToolkit/models/text_encoders', torch_dtype='auto')" を走らせ、TE ロードまで通すことを確認
5. tmux で anima_train.py 起動 → 監視
6. 学習が回り始めたら、ローカルで定期 rsync をループ起動して epoch ごとに LoRA + サンプル画像を持ってくる

2回目の起動は反省を踏まえた手順で本番突入

夜のうちに RunPod のダッシュボードを再確認したら、RTX 6000 Ada が別リージョンで在庫復活していた。kanachan v4 と完全同条件のハードに戻れる、A100 PCIe を避けて Ada を取り直す。Volume も同じリージョンに新規 50GB で作り直し、前 Pod の Volume は捨てる。

今度は前回の失敗を踏まえて、順序を入れ替えて起動した。

# 1. torch を先に 2.5.1+cu124 へアップグレード
pip install --upgrade torch==2.5.1 torchvision==0.20.1 torchaudio==2.5.1 \
  --index-url https://download.pytorch.org/whl/cu124

# 2. transformers は Qwen3 対応の範囲を pin（>=4.51, <5.0）
pip install --upgrade "transformers>=4.51,<5.0" \
  einops safetensors diffusers accelerate peft lycoris-lora omegaconf \
  tqdm Pillow numpy lpips pytorch-fid pytorch-msssim scipy scikit-image \
  matplotlib pandas pyyaml psutil rich tiktoken sentencepiece protobuf

# 3. smoke test を「実際に Transformer ロードする前」に走らせる
python -c "
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer, T5Tokenizer
from transformers.models.auto.configuration_auto import CONFIG_MAPPING
print('torch:', torch.__version__)
print('qwen3 in CONFIG_MAPPING:', 'qwen3' in CONFIG_MAPPING)
"

結果は torch: 2.5.1+cu124 / transformers: 4.57.6 / qwen3 in CONFIG_MAPPING: True。前回 7 分かかった Transformer ロードに突入する前に、依存レイヤーで詰みが無いことを確認できた。

CivitAI 直 DL ワークフローの確立

前回の踏み抜きから持ち帰った教訓はこれ。

• 家の上り回線で WAI-Anima 3.9GB を上げると（今日に限って？）約2時間かかる
• 一方 Pod から CivitAI に curl すれば 240Mbps、2分で完了
• CivitAI の公開モデルは API トークン不要、https://civitai.com/api/v1/models/<modelId> で modelVersionId を取れば 307 リダイレクト経由で直 DL

3並列で tmux new-session -d を使ってバックグラウンド実行する。

# WAI-Anima (3.9GB) from CivitAI
tmux new-session -d -s dl_anima \
  "curl -sL -o /workspace/waiANIMA_v10.safetensors \
   https://civitai.com/api/download/models/2859702"

# Qwen3 TE (1.2GB) from HuggingFace
tmux new-session -d -s dl_te \
  "cd /workspace/AnimaLoraToolkit && hf download Qwen/Qwen3-0.6B-Base \
   tokenizer.json vocab.json model.safetensors \
   --local-dir models/text_encoders"

# Qwen Image VAE (243MB) from HF (Anima 公式リポにある)
tmux new-session -d -s dl_vae \
  "hf download circlestone-labs/Anima \
   split_files/vae/qwen_image_vae.safetensors \
   --local-dir /workspace/anima_split"

3並列でも Pod の外向き帯域がボトルネックにならず、合計2-3分で全部着地。これと並行してローカルから keichan-package.tar.gz (80MB) を scp で上げた（80MB なら家の遅い上りでも数分）。

hf コマンドの新仕様も踏み抜きポイント。前回 huggingface-cli download で書いたら非推奨警告を吐かれて空振り。hf download <repo> <files> --local-dir <path> が現在の正解。

tar xzf が macOS xattr の警告で非ゼロの終了コードを返してきて set -e が引っ掛ける、というのも軽くハマった。展開自体は成功しているので set -e を外すか、エラーを許容する書き方に変える。

スモークテストで TE ロードを先に確認

依存入れ替え直後、Transformer の重い 7 分ロードを待つ前に、前回クラッシュした TE ロードと同じ呼び出しをスモークテストとして走らせた。

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer, T5Tokenizer
m = AutoModelForCausalLM.from_pretrained(
    "/workspace/AnimaLoraToolkit/models/text_encoders",
    torch_dtype=torch.bfloat16,
    device_map="cpu"
)
tok = AutoTokenizer.from_pretrained("/workspace/AnimaLoraToolkit/models/text_encoders")
t5 = T5Tokenizer.from_pretrained("/workspace/AnimaLoraToolkit/models/t5_tokenizer")
print(">>> SMOKE TEST PASSED <<<")

ここが通れば、本番起動で Transformer のロード 7 分待った先で TE ロードに入っても落ちない確証が得られる。前回 2 回燃やした 「7分待ち→TEで落ちる」 ループを潰せた。

本番起動と立ち上がり

cd /workspace/AnimaLoraToolkit
mkdir -p /workspace/output/keichan-v1
tmux new-session -d -s train \
  "python anima_train.py --config ./config/train_keichan_v1.yaml \
   2>&1 | tee /workspace/output/keichan-v1/train.log"

step 1 到達まで約 2 分（Transformer 6 分 → VAE 10 秒 → TE 数秒 → データセット / latent cache → step 1）。前回までの「Transformer 7 分待ち→TE で落ちる」と比べて、TE ロードが走らないと辿り着けない地点に問題なく到達できた。

step 5 時点の状態はこう。

指標	値
GPU 使用率	100%、295W/300W、53℃
VRAM	10.89GB / 49GB (kanachan v4 と同条件)
速度	0.335 it/s（kanachan v4 の 0.31 と誤差範囲）
合計step数	16,380 (= 91 × repeats 4 × epochs 180 / batch_size×grad_accum 4)
想定実時間	約 14 時間
想定総コスト	RTX 6000 Ada $0.77/h × 14h ≒ $11

ローカル側に sync_loop.sh を仕込んで nohup でデタッチ起動、5分おきに rsync -av --partial a100_pod:/workspace/output/keichan-v1/ で サンプル画像 + LoRA チェックポイント を持ってくる。学習完了を検知したら自動終了。寝てる間にローカルへ全部降りてくる構成。

1回目との差分

項目	1回目（クラッシュ）	2回目（成功）
GPU	A100 PCIe ($1.39/h)	RTX 6000 Ada ($0.77/h) ← kanachan v4 同条件
リージョン	ca-mtl-3	（Ada 在庫のある別リージョン）
起動順序	依存インストール → 起動 → 7分待ち → 落ちる	torch アップグレード → 依存固定 → スモークテスト → 本番起動 → step 1
スモークテスト	無	有（前回クラッシュ点を先に通過確認）
失敗 epoch 数	0（step 1 にも辿り着かず）	0（順調にステップ進行中）
消費コスト	$0.93 ぶん燃やして撤退	（継続中）

学習サンプルは ep1 で完成して ep20 で頭打ち

sample_every: 1 で全エポックのサンプル（固定 seed 42、固定 N 形式プロンプト）が出る。学習中のサンプルを ep0（ベースライン）から追っていくと、kanachan v4 とは全く違う曲線が出た。

epoch	サンプルの状態
ベースライン (LoRA未適用)	茶髪・茶目・キモノ風。keichan という概念がベースに無いので、a young girl + 青リボン描写から普通の女の子が出るだけ
ep1	いきなり金髪・水色目・ぱっつん前髪・両側青リボン。キャラ核心が1エポックで乗った
ep2-3	顔立ちが学習素材寄りに洗練、塗りが落ち着く。衣装はサンプルプロンプトが衣装を強く指定してないぶん揺れる
ep5	サイドの毛束が肩より下まで長く垂れ始める（長いインテークの萌芽）
ep10	サイド毛束が太く立体的に。ただし「強い前向きスクープ」までは行かず long thick sidelocks 寄り
ep20	ep10 とほぼ同じ。ここで頭打ち
ep50 / ep90 / ep125	ep20 と差が誤差レベル。100エポック分ほぼ同じ絵を焼き直しているだけ

ベースライン（茶髪・茶目・キモノ風）から ep1 で一気に金髪・青目・青リボンに乗り、ep5 以降はほぼ変化なし、という頭打ちが並べると一目でわかる。内蔵サンプラーは N 形式（NL付き）なので ep1 から金髪が出ているが、これは後述のとおりトリガー単体だと話が変わる。

kanachan v4 では「ep10 以下はキャラ感ゼロ、ep30-50 で立ち上がり、ep100-180 がスイートスポット」だった。今回は ep1 でキャラ核心が完成、ep20 で完全に頭打ち。曲線の形がまるで違う。

なぜこんなに速いのか（自家中毒＝データ分布の一致）

原因は学習素材の出自にある。

• kanachan の素材は ほぼ全部 Gemini 生成（一部 Grok / Qwen Image Edit の i2i） だった。Gemini は Anima とは全く別系統のモデルなので、ベース（Anima）から見ると素材は完全に別の分布で、分布のズレが極めて大きい。だからベースが強く抵抗し、焼き付くのに大量のステップ（ep150 スイートスポット）が要った
• keichan の素材は 全部 WAI-Anima v1.0 自身で生成した画像。ベースと素材の分布がほぼ一致しているので、ベースが一瞬で寄る。LoRA は「自分が既に出せる絵」を強化するだけなので ep1 で乗り、ep20 で飽和する

つまり kanachan v4 で出した「1枚あたり露出 600-720 がスイートスポット」という公式は、素材に分布のズレがある前提でのみ成立する。同一モデル生成素材（自家中毒データセット）では、その何十分の一のステップでピークに達して、あとはずっとプラトー。学習量のスイートスポット理論は、データの出自で全く変わる。今回それが一番はっきり出た。

（逆に Gemini や Qwen Image で生成した分布のズレがある素材で焼いたら、収束は遅くなる代わりに顔が締まるのか、という対の検証は自然な次の問いだが、本記事では割愛して別記事に回す。）

実用上の含意はこう。

• 同一モデルで生成した素材でキャラ LoRA を焼くなら、ep180 まで回すのは完全な無駄。ep20-30 で十分、それ以降は電気代と RunPod 課金を捨ててるだけ
• 今回は検証のため ep125 まで回したが（プラトー確認 + 過学習の崩壊が来るか見たかった）、結局 ep125 まで崩壊もせずプラトーが続いた。自家中毒データは過学習の崩壊すら起こしにくい（ベース分布から離れないので壊れようがない）

インテークは「長い側毛」までで、強いスクープにはならない

キャラ核心（金髪・青目・前髪・リボン・体型）は完璧に乗ったが、ケイちゃん最大の識別キーであるはずの「強めのエアインテーク」は、学習サンプル上では弱いままだった。サイドに長く太い毛束は垂れるが、前方向きにカールするスクープ形状にはならない。

これは Anima ヘアインテーク移植レシピ記事 で見た「Anima ベースは hair intakes を素直に出さない」構造的制約と、kanachan v4 のサイドポニー方向問題 と同根。Anima/Qwen3 TE は特定の髪構造シグナルに抵抗し、LoRA で焼いてもその抵抗を完全には超えられない。トリガー吸収方針にしたぶん keichan 一語で核心は出るが、インテークの主張はトレーナー内蔵サンプラー（N 形式・seed 42 固定）の単一条件では弱い。

ただし内蔵サンプラーは1プロンプト・1 seed なので判断材料として薄い。インテークが本当に焼けているか／タグや seed を変えれば出るのかは、ローカルでの K/N/KT マトリクステストで切り分ける（次節）。

コストと所要

項目	値
GPU	RTX 6000 Ada（kanachan v4 同条件で取り直せた）
学習速度	0.323-0.335 it/s（kanachan v4 の 0.31 と一致）
回した範囲	ep1〜125（ep180 まで回さず、プラトー確認で打ち切り）
学習時間	約10.5時間（ep125 時点）
消費	RTX 6000 Ada $0.77/h × 約10.5h ≒ $8 + 1回目失敗 $0.93 = 約 $9
取得物	ep1〜125 の LoRA 全部（各97MB、計12GB）+ サンプル125枚

LoRA は save_every: 1 で全エポック残してあるので、ローカルで好きな epoch を引いて検証できる。

結果検証

ローカル（M1 Max + ComfyUI + genserver）で kanachan v4 と同じ3形式マトリクスをかける。素材が自家中毒で ep20 頭打ちと分かったので、検証 epoch は早期寄りに ep5 / ep10 / ep20 / ep50 / ep125 を選定。

3形式の定義（kanachan v4 の T/N/TN に対応、今回はトリガー吸収方針なので K/N/KT）。

形式	内容
K（トリガーのみ）	keichan + 構図タグだけ。インテーク発火のヒントを一切与えない。本命の「トリガー一語でどこまで出るか」
N（NL併用）	学習キャプションと同じ自然言語（“Her long, thick hair intakes hang down…”）を足す
KT（トリガー + hair intakes タグ補助）	推論時に hair intakes タグを明示して補助線を引く

各形式 × seed 42/100/200 × 5 epoch = 45枚。genserver 経由、Anima Turbo LoRA 併用の 8-step、832×1216。

なお kanachan v4 ではサイドポニーが左右非対称だったため「向かって左に倒れる」方向制御が最大の論点だったが、ケイちゃんはインテークが左右対称なので方向という軸そのものが存在しない。kanachan の「方向」軸の代わりに、ケイちゃんで効いてくるのは インテークの指定有無と強度。

• 軸1は指定有無（K/N/KT マトリクス）。トリガー任せ（K）/ NL記述（N）/ タグ明示（KT）でインテーク発火がどう変わるか
• 軸2は強度（phase 2 の重みスイープ）。色が安定する epoch を固定し、hair intakes の強調の重みを 1.0 / 1.3 / 1.5 / 1.8 で振って、強い前向きスクープまで出せるか、それとも Anima ベースの抵抗で頭打ちか。あわせて アホ毛の副作用も見る。Anima ヘアインテーク移植レシピ記事 で「インテークを強く指定するとアホ毛が漏れ、ネガに ahoge を入れても通らない」と記録されていて、Anima ベース内でインテークとアホ毛の概念が結合しているらしい。ケイちゃんは学習側でアホ毛を入れていない（元プロンプトのネガに (ahoge:1.5)、キャプションにも無し）ので、推論でインテーク強度を上げたときにこの結合が呼び出されてアホ毛が出るか、出るならどの重みが閾値か、を確認する

加えて副次的に (a) 髪色がトリガーで安定するか（ep5 トリガー単体では茶/金/オレンジに揺れた） (b) キャラ再現度 も見る。

もう1個、crossed bangs（前髪に入る謎の1本線クロス）が出ないかも評価軸になる。これは Anima ベースが前髪に出しがちなアーティファクトで、ケイちゃんの元生成プロンプトでもネガに (crossed bangs:1.4) を入れて抑えていた。学習素材はこのクロスが出ていない画像を選んでいるので、テスト画像でクロスが出ない = LoRA がベースのクロスバイアスを中和してクリーンな前髪を焼けている証拠になる。出てきたらベースバイアスが漏れているサイン。「出ないこと」がポジティブシグナルという、いつもと逆向きの判定。

もう一つの検証軸はアングル制御性（phase 3）

検証を進めるうちに気付いたのが、Anima/IL が特定の 3/4 アングルに強く収束すること。体をわずかに振って、ほぼ正面顔、リボンが向かって左側に来る、あの「かわいい」とされる定番構図がやたら多い。

これはおそらく元の学習データを作っている層に右利きが多い + この角度が一般に可愛いとされることに由来するクセで、Anima も IL も共通して持っている。

ケイちゃんはインテークが左右対称なので「髪の向き」問題は存在しないが、体 / カメラアングルのロックは別問題として残りうる。kanachan のサイドポニー方向ロックと同種の現象が、髪ではなく構図レベルで起きる可能性がある。

なのでスイートスポットのエポックを拾えたら、逆 3/4 アングルを明示指定して出るかを phase 3 で確認する。出れば構図は制御可能、出なければ「正面 + この定番 3/4 に固定」されていることになる。

成功基準

「完全成功」のラインを先に切っておく。キャラのキーワード（トリガー keichan）だけで以下6点が出れば成功。

1. 金髪
2. ぱっつん前髪だが姫カットではない（サイドが顎までで短くバッサリ切れていない）
3. 大きめのインテークから流れる長い髪
4. ハーフブレイドアップ
5. 青いリボン
6. 青い目

逆に、減点にしない構造的限界を最初に認める。

• 体型のブレ。胸サイズ・スタイルの揺れは Anima でも IL でも常に出る、LoRA の出来とは別問題
• 顔の安定性が kanachan 未満。これは LoRA の失敗ではなく学習素材の出自による。kanachan の素材は Gemini 生成が主体で、Gemini はキャラ一貫性が高いので顔の締まった素材が揃っていた。ケイちゃんの素材は WAI-Anima 自家生成で、Anima はそもそもキャラ一貫性が弱い。つまり LoRA は「ブレた Anima 顔の分布」を学習しているので、出力顔も揺れる。自家中毒データは収束が速い代償に、元モデルのキャラ一貫性の弱さもそのまま継承する。もっと一貫した外部ソース（Gemini 等の整った生成）から顔を揃えれば改善余地はあるが、本記事のスコープ外
• 衣装のバラつき。今回のキャプション設計で衣装は独立可変タグにしてトリガーに焼き付けていない（キャラを1つの服に固定しないため意図的にそうした）。なので生成ごとに服が変わるのは減点どころか狙いどおりの正解。1着に固定される LoRA より、好きな服を着せ替えられる方がキャラ LoRA として有用で、これが本来あるべき挙動。1つの衣装に固定したいときだけ、その衣装タグを推論時に明示すればいい

K形式（トリガーのみ）は核心が ep10-20 でロック、ep125 で揺り戻し

本命の「keichan 一語でどこまで出るか」を epoch 別に見る。

epoch	髪色	ロング維持	インテーク	アホ毛	総合
ep5	不安定（seed で茶/金/オレンジ）	○	なし	なし	弱い
ep10	ほぼ金髪ロック	○	なし	出始める	中
ep20	金髪安定	○	弱〜中（正面で出る）	たまに	良
ep50	金髪安定	○	弱〜中	たまに	良
ep125	金髪（seed で暗め）	△（seed42 でショート化）	なし	たまに	不安定

トリガー単体で見ると ep5 は髪色が seed ガチャ（茶/金/オレンジ）、ep10 で金髪がほぼロック、ep20-50 で安定。ep125 は seed 42 でショートヘアに崩れる個体が出て、軽い過学習の揺り戻しが見える。学習中サンプル（内蔵サンプラーは N 形式）では ep125 まで金髪ロングで安定して見えたが、トリガー単体の K 形式で初めて ep125 の不安定さが露見した。内蔵サンプラーの N プロンプトが劣化を隠していた形。

ep5 トリガー単体の seed ガチャ（同じプロンプト、seed だけ変えて茶/金/オレンジ）。

そして ep125 トリガー単体で出たショート化の個体（過学習の揺り戻し）。

想定スイートスポット

このK形式の挙動から、スイートスポットは ep20（実質 ep20-50 はどこでも同等） と判定する。根拠はこう。

• ep5/ep10 は髪色がまだ完全にはロックされていない（特にトリガー単体）
• ep20 で色・ロング・核心が安定し、ep50 まで質が変わらない（自家中毒データなので ep20 で飽和）
• ep125 は seed によってショート化する軽い過学習が出る

kanachan v4 が「ep150 がスイートスポット」だったのに対し、ケイちゃんは ep20 がスイートスポット。約 7.5 倍速い。同一モデル生成素材（分布のズレゼロ）の威力がここに出ている。以降の形式比較・アングル検証はこの ep20-50 の LoRA を使う。

そして「そのスイートスポットでの出力精度がプロンプト形式でどう変わるか」が次の形式比較。トリガー単体（K）で核心は出るがインテークは弱い、N/KT を足すとインテークが乗る、という精度差を ep50 で見る。

1girl, keichan だけだと何が焼けているか

K 形式でも品質/構図/背景タグは入れていた。それすら全部抜いて 1girl, keichan の2語だけで出すと、トリガーに本当に焼き付いているものの境界が見える。

3枚とも 金髪碧眼ロング + 胸大きめ + ギャル寄りの顔で揃った。一方、

• ❌ ぱっつん前髪が出ない（分け目・流し前髪寄り）
• ❌ インテークが出ない（巻き髪ロング）
• ❌ ハーフブレイド + 青リボン構造が弱い

つまり トリガーに焼けているのは「色・体型・顔の系統」まで。髪型の構造（ぱっつん/インテーク/ブレイド/リボン）は焼けていない。髪型を出すには構造タグが要る。K 形式が6点中5点を出せたのは構造タグを入れていたからで、構造タグは冗長ではなく必須だと切り分けられた。「トリガーで核心、こぼれる特徴は記述で補う」という二段構えが必要な理由がここにある。

そして3枚ともセーラー服で出た。学習データにはセーラー服（制服）はほぼ入れていない。素材は水着・体操着・Tシャツ・レオタード・ドレス・浴衣などで、制服系は意図的に薄い。にもかかわらず衣装無指定だとセーラー服が出るのは、ベース Anima の「女子学生の既定服＝セーラー服」というクセが、学習データの実際の衣装分布すら完全に上書きして勝つから。衣装をトリガーに焼き付けていない（独立タグ化した）設計上、無指定ではベース既定が出る。

@ducha ©keichan のような偽サインのアーティファクトも出るが、これはベースが「キャラ絵にはサインが付く」と学習している副産物。出力もまたバトルアクション漫画『一騎当千』に出てきそうな金髪碧眼巨乳ギャルで、これも金髪碧眼の引力圏に収まる。

形式比較ではインテークは K < N < KT、ただし KT はアホ毛コスト

同じ ep50・seed 42 で3形式を並べると、インテークの出方が綺麗に差が付いた。

形式	髪色	インテーク	アホ毛	備考
K（トリガーのみ）	金髪	弱	たまに	核心は出るがインテーク主張弱い
N（NL併用）	金髪	中（クリーン）	なし	顔を縁取る太い側毛、最もバランス良い
KT（hair intakesタグ）	金髪	強（最も前向き）	出る	スクープ感は最大、ただしアホ毛が漏れる

hair intakes タグを足すと前向きスクープは一番強く出るが、予告どおりアホ毛が漏れた（KT の頭頂を見ると1本立っている）。ヘアインテーク移植レシピ記事で記録した「Anima ベース内でインテークとアホ毛が結合している」現象が、LoRA を当てても残っていることの実証。学習側でアホ毛をネガに入れていたのに、推論でインテークタグを明示すると結合が再浮上する。

実用解は N 形式（インテークがクリーンに出て、アホ毛が出ない）。最大限インテークを尖らせたいときだけ KT を使い、アホ毛は後処理で消す、という運用になる。真正面 N 形式できれいに出た例がこれ。

強度スイープ（phase 2）は重みを上げてもスクープ化しない

KT で hair intakes を入れるとインテークが一番出るなら、その重みを上げれば「強い前向きスクープ」まで持っていけるのか。ep20・真正面で (hair intakes:1.0 / 1.3 / 1.5 / 1.8) を振った。

結果は明快で、重み 1.0 から 1.8 までインテークの強さはほぼ変わらない。側毛が顔の脇に流れる「中程度」で頭打ちし、ドラマチックな前向きスクープにはならない。Anima のインテーク抑制は強調の重みでは力押しできず、強度の天井が低い。これは前述の「インテークは時代的に古い意匠で Anima が過小評価している」仮説と一貫する。ベースが持っていない造形は、いくら重みで押しても湧いてこない。

副作用のアホ毛は 重み 1.0（タグを入れた瞬間）から出ており、強度を上げても増えも減りもしない。つまりインテーク⇄アホ毛結合は「hair intakes タグの有無」で二値的に決まり、重みとは無関係。アホ毛を避けたいなら KT を使わず N 形式（NL 記述）で出す、というのが結論として確定した。

インテーク発火は異方的で、真正面で出て3/4・プロファイルで弱い

重要な発見。インテークは真正面アングルで明確に出て、体が 3/4 に振れると弱まる。これは2つの要因で二重に決定されている。

要因1は、構図とインテークの写りサイズが相関していたこと

• 01_bust_front の 39枚は全て「真正面バストアップ + インテークがはっきり大きく写る」ものを選んで入れた
• 02_clothed_pose の斜め構図は 全身 / カウボーイショットで、キャラが小さく写るぶんインテークもフレーム内で小さかった

つまり「真正面 = インテーク大きく学習」「斜め = インテーク小さく学習」という偏りがそのまま LoRA に乗った。斜めで弱いのはアングルそのものというより、そのアングルの学習画像でインテークが小さく写っていたことの反映。

要因2は、インテークにベースのデフォルト「大きく出す」というクセが無いこと（kanachan との決定的な差）

ここが kanachan との一番大きな違い。

• kanachan の特徴は「サイドポニー」。Anima も IL も ponytail / side ponytail と言えばデフォルトで大きめの房を出す。だからタグを入れるだけで勝手に大きく出て、「存在すれば認識成立、サイズは自動」。kanachan が「左サイドポニーさえ出てればキャラ認識OK、ポニーのサイズ云々にならなかった」のはこのため
• ケイちゃんの「インテーク」にはそういう大きいデフォルトがベースに存在しない。hair intakes と言ってもベースは小さく弱くしか出さないので、強く押さない限り埋もれる

結果、kanachan の特徴（大きいデフォルトのポニー、存在さえすれば勝ち）は頑健で、ケイちゃんのインテーク（ベースのデフォルト無し + 斜め学習画像で小さい）は脆い。特徴点が「ベースがデフォルトで大きく出すもの」かどうかで、キャラ LoRA の作りやすさが決定的に変わる。kanachan との対比でそこがはっきり分かれた。

実用上はむしろ好都合な含意もあって、**「ケイちゃんのインテークを見せたいなら真正面で生成する」**という運用指針が立つ。真正面は元々一番使うアングルでもある。逆に Anima が好む例の 3/4 定番アングルでは、インテークが弱い + 金髪碧眼の引力圏に近いので、後述の「他キャラ似」に転びやすい。

crossed bangs は出ない = クリーン学習の確認

評価軸に置いた crossed bangs（前髪の謎の1本線クロス）は、全45枚で一度も出なかった。学習素材がこのアーティファクトの無い画像で揃っていたぶん、LoRA がベースのクロスバイアスをきれいに中和している。「出ないこと」がポジティブシグナル、という逆向き判定が成立した。狙いどおり。

phase 3 の結果、学習データに入れた構図は制御できる

「真正面ポートレートが綺麗」だけでは「使える LoRA」とは言えない。逆角度・あおり・ふかん・全身・各種ポーズで破綻せず出るかを ep20 で振った。

学習データに入れた構図（左右3/4・プロファイル・振り返り・全身・座り・走り）は全部きれいに出る。人体も破綻しない。振り返りでは後頭部のハーフブレイド + 青リボンが正しく見え、髪構造が背面まで学習されているのが確認できた。正面 + 定番3/4 に固定されてはいない＝構図は制御可能 = 使える LoRA。

一方、あおり / ふかんは控えめにしか効かない。ただしこれは減点にならない。あおり/ふかんは人体破綻リスクを嫌って学習データに入れていない。LoRA が学んでいない角度なのでベース Anima 任せになり、弱いのは当然。分布外の要求に対する挙動として想定どおり。

Anima の最強アトラクタは 3/4、外すには学習データに入れるしかない

phase 3 を通して見えたのは、Anima の構図のクセが一番強いのは 3/4 だということ。あおり/ふかん/極端角度の要求は 3/4〜正面寄りに引き戻される。これはおそらく元データ作者に右利きが多い + この角度が一般に可愛いとされることに由来する。

そして振り返り・プロファイル・全身がちゃんと出たのは、それらを学習データに明示的に入れたから。つまり「Anima の 3/4 のクセを外したい構図は、学習データに入れておかないと出ない」。データ設計（左右・振り返り・各種ポーズを入れた判断）が正しく機能した。

方向制御は弱指定で曖昧、強指定で一貫

逆向き（右向き）は、(three quarters view:1.3) 程度の弱い指定だと「頭だけ右に向けた 3/4」くらいで方向の決まりが弱かった。そこで (facing right:1.5), (body turned to the right:1.5) と強めに振って複数 seed で回すと、seed 42/100/200 すべてで安定して右向きになった。

ちなみに学習データには左右どちらの向きも入れてある。それでも弱い指定では出力がなかなか右を向かず、緩い条件で回したときは右向きがせいぜい2枚程度しか出てこなかった。推論段で Anima の左/3-4 のクセが強く効く、ということ。強めに指定すれば安定して右を向くので、方向自体は制御できる範囲にある。

そして決定的なのは、ケイちゃんはインテークが左右対称なので、方向が違ったら最終的に水平反転すれば済む。kanachan は非対称サイドポニーだったので反転すると位置が逆になり左右反転が使えず、生成で方向を当てるしかなく面倒だった。ケイちゃんは対称ゆえ左右反転が無損失。「右向きが欲しい → 左向き生成 → 反転」で終わる。手のポーズや非対称な衣装ディテールが無ければ、方向制御の弱さは実害ゼロ。

横長アスペクトは概ね可、ただし寝そべりは二重化リスク

縦長（832×1216）ばかりだったので横長（1216×832）も振った。寝そべり等、横長を活かした構図でもキャラ自体は保つ（下の seed 42 はきれい）。

ただし同じ横長寝そべりを seed 違いで回すと、1枚は人体が二重化して崩壊した（顔が2つ、体が融合）。これはこの LoRA 固有ではなく、横長アスペクト + 寝そべりポーズでモデルがワイドな空白を埋めようと2人目を描いてしまう拡散モデルの典型的失敗モード。横長自体は使えるが、寝そべりのような「ワイドに引き伸ばされる構図」では二重化が出やすいので、seed ガチャか縦長で撮るのが無難。

インテーク強度は構図内での顔の見かけサイズに比例する

ここまでのインテークの出方を1つの原理にまとめると、インテークの強度は「構図内で顔（=インテーク）がどれだけ大きく写るか」に比例する。

構図	顔の写り	インテーク
バストアップ正面（学習39枚）	大	濃く学習 → 強く出る
全身立ち	小	薄く学習 → 弱い
座り込み等（顔が結果的に大きく写るポーズ）	中	中程度に出る

「正面 vs 斜め」ではなく「顔の見かけサイズ」が支配変数。学習データに顔が大きく写る多様なポーズを入れていたぶん、非正面でもインテークが乗る構図がある。

インテークは「時代的に古い」特徴で Anima が過小評価している（仮説）

ここからは推測（モデルの美的意図は直接証明できない）。インテークが Anima で焼きにくく、特に Anima が「可愛い」とする定番 3/4 で小さくなりがちなのは、大きいヘアインテークが 2000年代ギャルゲ/アニメ全盛の意匠で、2020年代中盤イラストで学習した Anima には希薄だから、という説で辻褄が合う。

裏付けになるのが ヘアインテーク移植レシピ記事 で、汎用キャラにインテークを出すのに 水瀬名雪（Kanon、2002年）を参照に借りる必要があった。インテークを出すのに 2000年代キャラを召喚しないといけない＝Anima の現代の傾向では大インテークが過小評価されていることの傍証。ケイちゃんのインテークが弱いのも、LoRA の詰め不足というより、この時代的なズレに根がある可能性が高い。

インテークが死ぬと「無個性な金髪碧眼」に落ちる

検証中、インテークが弱い／非発火の個体を見て、最初は「デレマスの大槻唯っぽい」「ハガナイの柏崎星奈っぽい」と既知キャラを次々思い浮かべた。唯も星奈も金髪碧眼で、ケイちゃんと色アイデンティティが完全に被るからだ。

ところが実際にベース Anima で唯と星奈を生成して並べてみると、ケイちゃんの崩れは特定のどちらにも似ていなかった。下が比較で、左2枚がベースの唯（ohtsuki yui）と星奈（kashiwazaki sena）、右がインテーク非発火の keichan。

唯は元気な笑顔、星奈はクールな高慢顔と、それぞれ固有の顔をしている。一方 keichan の崩れはどちらでもない、ただの金髪碧眼ロング。つまり「唯似/星奈似」は脳がありふれた絵を既知キャラにパターンマッチしていた錯覚（apophenia）で、実態は特定キャラですらない無個性化だった。

そして「どのキャラとも特定できない」こと自体が、命題の証明になっている。

ケイちゃん = 金髪碧眼ロング（無個性でありふれた原型）+ インテーク（唯一の差別化要素）

金髪碧眼ロングは有名キャラ（唯・星奈・他多数）がひしめくと同時に、個々を曖昧にする無個性ゾーンでもある。ケイちゃんをそこから引き上げているのはインテークただ1つ。ところがそのインテークが Anima で一番焼きにくい。だからこうなる。

• インテーク発火 → ケイちゃん
• インテーク非発火 → 無個性な金髪碧眼ロング（唯にも星奈にも『見えなくはない』が、どれでもない）

を seed ごとに往復する。LoRA のアイデンティティが、一番発火しにくい1特徴に全依存しているという構造的弱点が浮き彫りになった。複数の金髪碧眼キャラが次々思い浮かぶこと自体が、この原型の無個性さ＝「インテーク無しだと埋もれる」ことの生きた証拠。

運用上の対処として、ネガティブに ohtsuki yui 等を入れて引力圏から押し戻す手は理屈上あるが、金髪碧眼を共有するキャラなので強くネガると色まで削れるうえ、そもそも崩れ先が特定キャラじゃない以上、効果は限定的。素直に N 形式でインテークを記述して押し戻す方が筋。

可愛いし、トリガーだけでケイちゃんとして出るので実用十分

成功基準（トリガーだけで6点）に照らすと、こうなる。

基準	判定
金髪	✅ ep10+ でロック
ぱっつん前髪・非姫カット	✅
大きめインテークから流れる長髪	△ 真正面なら出る、斜めで弱い
ハーフブレイドアップ	✅
青リボン	✅
青目	✅

インテークだけ「真正面限定で出る」という条件付きだが、6点中5点はトリガー単体で安定、インテークも正面 + N 形式なら十分主張する。崩れる時は金髪碧眼の無個性ゾーンに落ちるが、それは「色はちゃんと出ている」証拠でもある。

そして phase 3 で 学習データに入れた構図（左右3/4・プロファイル・振り返り・全身・座り・走り・横長）は全部制御できることを確認した。正面 + 定番3/4 にロックされておらず、ポーズ・アングルの自由度がある＝実用的な意味で「使える」。あおり/ふかんだけは学習に入れていないぶん弱いが、これは設計どおりの想定済みの穴。

総合すると、「まあ可愛いし、インテーク指定が無くても（特に真正面なら）ケイちゃんとして出るから実用十分」 という着地。kanachan v4 のような方向制御の苦闘は無く、自家中毒データのおかげで ep20 で焼き上がる安上がりな成功だった。

ここで現実的な期待値の話をしておくと、「トリガー一語で毎回完璧に出る」は、そもそも kanachan ですら達成できていない。kanachan でも特徴が消えそうなときは記述プロンプト（自然言語でキャラを書き下す形）を足して補っていた。だから keichan に「トリガーだけで完璧」を求めるのは非現実的で、特徴が薄れる構図・seed では N 形式で記述を足して押し戻すのが通常運用。これは LoRA の欠陥ではなく、キャラ LoRA というものの標準的な使い方。今回の「インテーク非発火時に金髪碧眼の他キャラ（唯/星奈）が顔を出す」現象は、まさに記述プロンプトで押し戻すべき対象であって、トリガー単体への過剰な期待を捨てれば運用で吸収できる範囲。要するに トリガーで核心を出し、こぼれる特徴は記述で補う、という二段構えが現実解。

残る弱点（インテークの異方性、顔の揺れ、金髪碧眼の引力圏に引っ張られること）は Anima ベース由来の構造的なもので、LoRA 側の詰めではなく素材の出自を変える（分布のズレがある高一貫性ソースを使う）方向でしか改善しない。ただしそれは別記事の話。

推奨運用レシピ

項目	推奨
エポック	ep20-50（ep125 まで回す必要なし、むしろ軽く過学習）
形式	N（自然言語でインテーク描写）、アホ毛が出ない
アングル	真正面でインテークが最も出る。強度は「顔がフレーム内で大きく写る構図」ほど上がる
強インテークが欲しいとき	KT（hair intakes タグ）だがアホ毛は後処理前提
方向を変えたいとき	(facing right:1.5) 等の強め指定で効く。安定しなければ左右対称なので水平反転で済む（kanachan には無かった特権）
アスペクト	縦長・横長どちらも可
速度	Turbo LoRA 併用 8-step で実用品質

残る宿題は別記事に回した「Gemini 等の分布のズレがあるソースで焼いて顔が締まるか」くらい。インテークの強度天井（phase 2 で重みを上げても頭打ち）も確認済みで、本記事の範囲では ep20 + N 形式 + Turbo で実用ライン、という結論で十分。

ケイちゃんとかなちゃんを揃いの制服で並べてみる

最後に、スイートスポットの ep20 で、指定した制服を着せて全身が出るかを確認した。どちらのキャラもデフォルトの制服を持っていないので、推論プロンプトで揃いの制服を指定する。

キャラ	制服パーツ
ケイちゃん	白ワイシャツ、赤リボン、濃紺プリーツスカート、白ハイソックス、黒靴
かなちゃん	白ワイシャツ、赤ネクタイ、濃紺プリーツスカート、黒ニーソ、黒靴

両キャラとも指定した制服パーツが全部出て、全身・人体も破綻なし。ケイちゃんは金髪碧眼+青リボン、かなちゃんは茶髪サイドポニー+赤ネクタイで、揃いの制服を着ながらキャラの識別性は保たれている。

ただし全身だとケイちゃんのインテークは引っ込む。これは「全く出ない」のではなく「学習した分だけは出る、ただ想定したほどの分量が出ていない」状態。(hair intakes:1.5) まで重みを上げても、cowboy shot で寄せようとしても、全身の顔の小ささでは想定どおりのインテークにはならない。

面白いのは、顔自体は全身でも崩れていないこと。バストアップを多めに学習させたので、遠くても顔は頑健に出る。髪型もインテーク以外（ぱっつん・ブレイド・リボン）はちゃんと出る。インテークだけが想定の分量に届かないのは、推論プロンプトの問題ではなく、学習素材のインテークの特徴量が弱かった（＝もともとそこまで誇張されていなかった）ことに起因する。Anima がインテークを構造的に過小評価するぶんを、素材の誇張で押し返せていなかった、ということ。(hair intakes:1.5) で叩いても増えないのが、プロンプト側では直せない＝素材を盛り直す（v2 でインテークをもっと過剰に描いて学習させる）しかないことの裏付け。

もう一つ並べて気づくのが、2人の等身が揃わないこと。ケイちゃんは脚長でグラマー、かなちゃんは低めで寸胴寄り。これも素材の出自そのままで、ケイちゃんは Anima 生成（Anima の等身）、かなちゃんは Gemini 生成（Gemini の等身）を継承している。顔の一貫性だけでなく等身まで素材モデルのクセが乗る。揃いの制服を着せても体型の系統が違うのは、この出自差のため。

ケイちゃんのスイートスポット（ep20）が指定衣装の全身でもちゃんと回る、というのが確認できたところで本記事は一区切り。次回はこの2枚を使って、ちょっとした実験を予定している。