キャラLoRAを99体規模で自動生産する「工場」アーキテクチャ堅牢化設計 2026

1. 結論：工場を堅牢化する最重要3レバー

99体を人間無介入で回し続ける工場で、品質・稼働率・コストを同時に守る決定打は次の3つに集約される。それ以外の改善は「この3レバーが効いている前提」での微調整に過ぎない。

2. 市場・前提：なぜ「工場化」が今これだけ難しいのか

2025〜2026年時点で、単体LoRA学習のノウハウ（kohya_ss / sd-scripts / Prodigy）は十分に成熟した^[1][9]。しかし「無人で99体を連続生産し、品質を自動保証する工場」という領域は、依然として個人運用者が自前で組む以外に確立解がない。理由は3つ。

• ① 学習ツールは単発実行前提：kohya_ssはGUI＋単発accelerate launchが基本で、キュー・採点・再学習ループは付属しない^[1][4]。バッチ化はTOMLを量産して回す自作運用になる。
• ② GPUジョブキューは研究者向けで品質ゲート非搭載：gpuq等の単ノードGPUキューは「学習を順番に回す」までで、サンプル生成→採点→合否→再学習の業務ループは利用者が実装する領域^[5][6]。
• ③ LoRA品質の自動評価が業界的に未成熟：研究レベルではArcFace同一性＋CLIP-T追従の多指標評価が標準化しつつあるが^[12][13]、これをローカルの量産パイプラインに組み込み、合否ゲートとして機能させる実装はまだ各自で作るしかない。

つまりCC1の工場は「市場に完成品が存在しない領域を自作で先行している」状態であり、堅牢化の本質は外部の万能ツールを探すことではなく、自前パイプラインの不変条件・冪等性・自己修復を固めることにある。本DRはそこに全フォーカスを置く。

3. 全体アーキテクチャ図（層構造・データフロー・状態遷移）

ジョブ状態遷移機械

不変条件：state='running' の行は常に最大1件。supervisor起動時に孤児running（前回クラッシュ残骸）をpendingへ自動復帰させる（recover --all相当）。

4. 技術スタック：パイプライン7ステージ詳細設計

各ステージは 入出力・成果物ファイル・冪等性キー・失敗時挙動 を明示的に持つ。冪等性キーが一致すれば再計算をスキップでき、クラッシュ後の途中再開が安全になる。

5. ジョブキュー / スケジューラ設計（SQLite WAL・1GPU排他）

5-1. スキーマ（WAL強制）

PRAGMA journal_mode=WAL;
PRAGMA synchronous=NORMAL;

CREATE TABLE IF NOT EXISTS jobs (
  id            TEXT PRIMARY KEY,
  character_id  TEXT NOT NULL,
  stage         TEXT NOT NULL,   -- DATASET/TAGGING/CACHE/TRAIN/SAMPLE/EVAL/GATE
  state         TEXT NOT NULL CHECK (state IN
                ('pending','running','preempted','interrupted','passed','failed','retired')),
  priority      INTEGER DEFAULT 100,   -- 小さいほど高優先
  dependency_id TEXT,                  -- 先行ジョブID
  config_json   TEXT NOT NULL,
  failure_count INTEGER DEFAULT 0,
  max_retries   INTEGER DEFAULT 3,
  pid           INTEGER,
  created_at    TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  updated_at    TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
CREATE INDEX IF NOT EXISTS idx_jobs_state_priority ON jobs(state, priority, created_at);

WALモードはクラッシュ安全性と「daemon書込中の並行読取」を両立する。JSON状態管理は機械クラッシュ時に破損した実例があり、WALへの移行が推奨される^[5]。

5-2. 1GPU排他ロック（BEGIN IMMEDIATE）

def acquire_next_job():
    with transaction() as conn:           # BEGIN IMMEDIATE で即時書込ロック
        n = conn.execute("SELECT COUNT(*) FROM jobs WHERE state='running'").fetchone()[0]
        if n > 0:
            return None                   # GPUビジー → 取得しない（1件不変条件）
        row = conn.execute("""
            SELECT j.id, j.character_id, j.stage, j.config_json, j.failure_count, j.max_retries
            FROM jobs j LEFT JOIN jobs dep ON j.dependency_id = dep.id
            WHERE j.state='pending'
              AND (j.dependency_id IS NULL OR dep.state='passed')
            ORDER BY j.priority ASC, j.created_at ASC LIMIT 1
        """).fetchone()
        if not row: return None
        conn.execute("UPDATE jobs SET state='running', pid=?, updated_at=CURRENT_TIMESTAMP WHERE id=?",
                     (os.getpid(), row[0]))
        return row

5-3. Windowsでの/proc相当：PID生存監視 & プロセスツリー掃討

gpuqはLinuxの/proc/{pid}でPID生存を確認する設計だが^[5]、Windowsではtasklist／taskkill /F /Tで等価機能を実装する。

def is_pid_alive(pid):
    out = subprocess.check_output(f'tasklist /FI "PID eq {pid}" /NH',
            shell=True, stderr=subprocess.DEVNULL, encoding='cp932')
    return str(pid) in out

def kill_tree(pid):
    subprocess.run(f"taskkill /F /PID {pid} /T", shell=True,
            stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)  # /T=子プロセスツリーごと

accelerate / Python / CUDA はプロセスツリーを作るため、親PIDだけ殺すと子のVRAM保持ゾンビが残る。必ず/Tでツリー一掃する。

6. 収益・効率試算：GPU1枚での効率化とスループット

「工場の収益」とはここでは1枚のRTX3090から1日あたり何体の合格LoRAを搾り出せるかに等しい。GPUを1秒も遊ばせないCPU/GPU分業が肝。

ROI注記：採点コストは最安profile委譲で1体≤¥1。対して没LoRA1体の機会損失（再学習GPU時間＋ストレージ）は遥かに大きい。採点ゲートは「コスト」ではなく「収益保護装置」。

7. supervisor自己再起動・自己修復設計

7-1. 単一インスタンスロック（多重起動の物理防止）

import msvcrt, sys
LOCK = r"D:\factory\supervisor.lock"
def acquire_single_instance():
    fp = open(LOCK, 'w')
    try:
        msvcrt.locking(fp.fileno(), msvcrt.LK_NBLCK, 1)   # ノンブロッキング排他
    except OSError:
        print("[CRITICAL] supervisor already running"); sys.exit(0)
    return fp  # プロセス生存中はfpを保持しロック維持

タスクスケジューラの「5分おき起動」と組み合わせると、生きている間は新インスタンスが即exitし、死んだ瞬間だけ次回起動が成功する＝自己再起動と多重起動防止を同時に満たす。

7-2. ログ正規表現によるETA監視・ハング/OOM検出

progress_re = re.compile(r"(\d+)%\|.*\| (\d+)/(\d+) \[.*, (.*)s/it\]")  # tqdm進捗
oom_re      = re.compile(r"CUDA out of memory", re.IGNORECASE)
# 一定時間 step が進まなければ TIMEOUT、OOM文字列検出で即 batch半減再キュー

gpuqもr'[Ss]tep\s+(\d+)\s*/\s*(\d+)'でログをパースしETA推定する設計^[5]。本工場はtqdmバーとOOM文字列の両方を監視し、進捗無停止が閾値（例450秒）を超えたらドライバクラッシュ/デッドロックとみなしツリー掃討。

7-3. OOM自己修復（無限ループを作らない）

1. OOM検出 → kill_tree(pid) でゾンビ一掃
2. time.sleep(30) でVRAM解放を待つ（即再起動は再OOMの無限ループを生む）
3. config.tomlのtrain_batch_sizeを半減＋gradient_accumulation_stepsを倍化（実効バッチ維持）
4. failure_count++ 。max_retries到達でretiredへ

7-4. 起動時リカバリ（孤児runningの救出）

# supervisor起動時：前回クラッシュで running のまま残ったジョブを pending へ戻す
for job_id, pid in conn.execute("SELECT id,pid FROM jobs WHERE state='running'"):
    if pid and is_pid_alive(pid): kill_tree(pid)
    conn.execute("UPDATE jobs SET state='pending', pid=NULL WHERE id=?", (job_id,))

gpuqはrecover --allで中断ジョブを元の引数・発見済みチェックポイントごと再キューする^[5]。本工場も同思想で、再開はチェックポイント（save_every_n_epochsの途中safetensors）から行う。

8. kohya学習の自動化（config量産・Prodigy・ステップ式）

8-1. 3090最適化 config.toml テンプレート

[additional_network_arguments]
network_module = "networks.lora"
network_dim = 16
network_alpha = 8          # dim:alpha = 2:1（キャラLoRA定番。低alpha=過学習抑制）
unet_lr = 1.0
text_encoder_lr = 1.0      # ★Prodigyは必ず 1.0（他値厳禁）

[optimizer_arguments]
optimizer_type = "Prodigy"
optimizer_args = ["decouple=True","weight_decay=0.01","d_coef=2.0",
                  "use_bias_correction=True","safeguard_warmup=True","betas=0.9,0.99"]
lr_scheduler = "cosine"

[training_arguments]
train_batch_size = 4
mixed_precision = "fp16"
xformers = true
fused_backward_pass = true        # v0.9.0+ VRAM圧縮の決定打
gradient_checkpointing = true
save_every_n_epochs = 1           # 途中再開チェックポイント
persistent_data_loader_workers = true

Prodigyはlearning_rate=1.0必須。他の値を入れると自動調整が破綻し、出力が真っ黒(NaN)になる^[9][10]。推奨引数は decouple=True / weight_decay=0.01 / d_coef=2 / use_bias_correction=True。d_coefの推奨域は0.5〜2、既定2^[10]。Prodigy等の適応的オプティマイザはlr手調整を不要にし、UNetを焼きにくい代わりに20〜30%多めのステップを要する^[9]。

8-2. ステップ数の自動最適化（過学習と未学習の境界 1500〜2400）

キャラLoRAは1500〜2400ステップが定番レンジ（例：20枚×3repeats×25〜40epoch≒1500〜2400）^[11]。枚数に応じてrepeats/epochsを自動探索し、このレンジに収める。

def calc_params(num_images, target=1800, batch=4, grad_accum=1):
    unit = num_images / (batch * grad_accum)
    best = None
    for r in range(1, 11):            # repeats上限10（過学習防止）
        for e in range(5, 16):
            steps = math.ceil(unit * r * e)
            if 1500 <= steps <= 2400:
                d = abs(steps - target)
                if best is None or d < best[0]: best = (d, r, e, steps)
    return best  # (diff, repeats, epochs, total_steps)

過学習対策の鉄則：repeats >5は構図・背景まで記憶しやすい^[11]。ステップを稼ぎたい時はrepeatsでなくepochsを増やす。alphaを上げる/rankを下げる/repeatsを減らすのも過学習緩和に効く^[11]。

8-3. バッチ起動

accelerate launch --num_cpu_threads_per_process 4 train_network.py \
    --config_file "D:\factory\configs\{char}.toml"

kohya GUIの「Print training command」でエクスポートした.tomlはそのままsd-scriptsのCLIに渡せる^[1]。工場はこのTOMLをテンプレートから量産生成して回す。

9. 落とし穴：latentキャッシュ重複 + 失敗パターン10連発

9-1. latentキャッシュの三大事故と決定論的隔離

対策（レバー1）： 画像バイナリ＋mtime＋解像度＋モデルから16桁SHA256を生成し、{char}_{hash}_{idx:04d}へリネーム＋専用ディレクトリへ隔離する。これで同名衝突・古キャッシュ混入が原理的に起きない。さらに学習前プリフライトで「PILで開けるか」「アスペクト比1:4〜4:1の範囲内か」を検証してstuckを未然に弾く。

def dataset_hash(image_paths, resolution, base_model):
    h = hashlib.sha256()
    for p in sorted(image_paths):
        h.update(p.encode()); h.update(str(os.path.getmtime(p)).encode())
    h.update(str(resolution).encode()); h.update(base_model.encode())
    return h.hexdigest()[:16]
# → isolated_datasets\{char}_{hash}\ に画像とtxtをリネームコピー

補足：cache_latents_to_diskはcache_latents（メモリ）より学習が遅くなる事象が報告されている^[3]。VRAM/RAMに収まるデータセットではcache_latents（非disk）の方が速い場合があるので、枚数で使い分ける。キャッシュは別フェーズ(STG3)で事前計算し学習(STG4)と分離するのが工場では有利。

9-2. 失敗パターン10連発（実運用で起きる事故）

10. 撤退・retireライン（無限ループを断つ設計）

工場の最大の敵は「壊れ続けるジョブに無限にGPUを注ぎ込むこと」。明確な撤退基準を状態機械に埋め込み、人手介入を最小限のシグナルに限定する。

同一性閾値の根拠：ArcFaceコサインは0.5以上を同一人物の目安とするのが一般的で、用途に応じて0.5〜0.69付近で調整する^[13][14]。アニメ顔は実写ほど分離が綺麗でないため、初期は0.50を最低ライン、0.58を量産許容、0.65を理想合格として段階運用するのが安全。

11. 堅牢化チェックリスト30項目 + 30日ロードマップ + 既存資産活用

11-1. 堅牢化チェックリスト30項目（4ゲート）

11-2. 30日堅牢化ロードマップ（週次）

11-3. 既存資産活用（CC1の現工場への組込み）

• 既存LoRA 99体の互換性：ベースモデルはwaiIllustriousSDXL_v160継続が無難（99体100%互換）。乗換はIllustrious XL 2.0のeps系統のみ検討、vpredは砂嵐事故のため除外。本工場のbase_model_hashを冪等性キーに含めれば、モデル変更時に自動で全キャッシュ・全LoRAが再生成対象になる。
• 既存の番人スクリプト連携：_mem_guard（RAM監視）・_gpu_guard（温度83/85/88℃退避）をsupervisorの常駐サブスレッドとして取り込み、OOM/熱でのハングをジョブ状態機械に反映する。
• 品質ゲートの統一：既存r18_quality_gate.htmlの9軸加重スコア思想を、本DRのgrader（ArcFace+CLIP+VLM）に統合しgate.json証跡をD:\projects\fanza3_mass\gates\へ出力。preflight()のsys.exit(2)ブロックと直結させる。
• 採点の外部AI委譲：VLM採点はgrok_router.py経由・最安profile（dr_gemini/img_caption系の非reasoning）で実行し、コストログを自動記録。reasoningや高額slugは使わない。

12. 脚注（全URL・関連DR一覧）

関連DR一覧（D:\市場調査資料\）

• DR_ComfyUI_LoRAトレーニング完全ガイド_2026.html（単体LoRA学習の基礎）
• DR_ComfyULoRA最速学習CG量産ワークフロー_2026-04-28.html（量産WFの前段）
• DR_ComfyUI_RTX3090_バッチ生成_2026-04-28.html（3090バッチ生成）
• DR_SDXLvsPonyvIllustrious品質比較2026_2026-04-28.html（ベースモデル選定）
• DR_Civitai_モデルLoRA収集管理_2026.html（モデル/LoRA管理）
• DR_PM2_ClaudeAPI_自動タスク処理_量産システム_2026.html（量産supervisor思想の隣接）

本DRは上記の「単体学習・単体生成」DR群の上位レイヤー＝無人工場のオーケストレーション層を扱う新規テーマ。重複なし（新規作成）。