はじめに

前回（第7回）は、Mac StudioでFLUX.1 dev系モデルを試し、紫色の画像が出る問題にも遭遇した。

今回は、標準の FLUX.1 dev と Hugging Faceの kp-forks/Flux-uncensored を組み合わせて検証する。さらに、既存の日本語入力ツールを拡張し、モデル・LoRA・縦横方向を選べるようにした。

最終的にはYouTubeの通常動画（1920×1080）とShorts（1080×1920）を制作したい。そのため、まずは約半分の縦横サイズで静止画を生成し、動画化・編集後にAIアップスケールする方針とした。

注意： 本記事の動作確認は筆者の環境での結果であり、MFLUXの全バージョンや全LoRAで同じ結果になることを保証するものではない。Uncensoredは配布元のモデル名であり、品質や動作を保証する表現ではない。

1. 使用環境

項目	構成
コンピュータ	Mac Studio（Apple Silicon、ユニファイドメモリ64GB）
ストレージ	外付けSSD `/Volumes/Hanye2T`
画像生成	MFLUX / MLX
ベースモデル	FLUX.1 dev（4bit量子化）
LoRA	`kp-forks/Flux-uncensored`
日本語→英語	Ollama＋Qwen3系ローカルLLM
UI	PythonからSwift/AppKitダイアログを起動

MFLUX、Ollama、モデルキャッシュの設定は前回までの記事を参照してほしい。

2. kp-forks/Flux-uncensoredはLoRAだった

今回使ったのは、FLUX.1 devに追加適用するLoRAである。ベースモデルを丸ごと置き換えるチェックポイントではない。

ダウンロードしたファイル名が単に lora.safetensors だったため、今後ほかのLoRAと区別できるように名前を変更した。

mv /Volumes/Hanye2T/AI/mflux/loras/lora.safetensors \
   /Volumes/Hanye2T/AI/mflux/loras/kp-forks_Flux-uncensored.safetensors

これはファイル名を変更するだけで、重みの内容は変わらない。以後、スクリプトやコマンドからは新しい名前を指定する。

なお、LoRAには対応するベースモデルがある。今回のLoRAをKrea 2 Turboに適用しようとすると、重みの形状不一致（LoRA shape mismatch）が発生した。LoRAならどのモデルにも使えるわけではない。

3. LoRA強度を変えてみる

LoRAの適用は概念的には次のように表せる。

変更後の重み = ベースモデルの重み + 強度 × LoRAの補正

今回の実験では、強度を0.5から1.0にすると画像内容に明確な変化が見られた。ただし、強くすれば必ず高品質になるわけではない。学習データの特徴が強く出たり、元のモデルの得意な表現に干渉したりすることがある。

LoRA強度と画像品質は別々に評価する必要がある。

4. まず、成功したコマンドを基準にする

標準FLUX.1 dev＋kp-forks LoRAで、以下のコマンドは正常な人物画像を生成できた。

mflux-generate \
  --model dev \
  --quantize 4 \
  --lora /Volumes/Hanye2T/AI/mflux/loras/kp-forks_Flux-uncensored.safetensors 0.5 \
  --prompt "A beautiful Japanese woman in her mid-20s, full-body portrait, soft natural light, photorealistic, high detail" \
  --steps 25 \
  --width 512 --height 512 \
  --seed 42 \
  --output direct_test.png

プロンプトには standing（立っている）が含まれていないため、座った構図になる場合もあった。これは紫色のノイズとは別の、構図指定の問題である。

5. 統合スクリプトでは紫色の画像が出た

日本語入力、モデル選択、LoRA選択を一画面にまとめた japanese_mflux_multi.py を作成した。

ところが、FLUX.1 dev＋kp-forks LoRAで生成すると、画像が紫色になった。

当初はステップ数を疑ったが、8ステップから25ステップに増やしても解消しなかった。成功した英語プロンプトに戻しても紫色のままだった。

ログではLoRAは正常に適用されていた。

Applying LoRA: kp-forks_Flux-uncensored.safetensors (scale=0.5)
Applied to 494 layers (988/988 keys matched)
All LoRA weights applied successfully
25/25
Peak MLX memory: 31.71 GB

つまり、処理がエラーなく終わったことと、画像が正常であることは別である。

解像度を比較した

直接コマンドでは512×512、統合スクリプトでは1024×1024を使っていた。そこで、統合スクリプトのFLUX.1 devの解像度を512×512に変更した。

条件	結果
直接コマンド、512×512、LoRA 0.5、25ステップ	正常
統合スクリプト、1024×1024、LoRA 0.5、25ステップ	紫色の画像
統合スクリプト、512×512、LoRA 0.5、25ステップ	正常

この環境では、解像度変更によって問題が解消した。

ただし、これはFLUX.1 devの最大解像度が512×512という意味ではない。1024×1024はFLUX系で一般的に使われるサイズであり、原因がLoRA、量子化、MFLUXの実装、メモリ挙動のどれなのかは、この実験だけでは断定できない。

また、ピークMLXメモリが約31.71GBだったという記録だけで、システム全体のメモリ問題を完全に否定することもできない。

6. 動画制作を考えて「ハーフHD」にする

目標は、静止画そのものよりも動画制作である。最終出力は次の解像度で十分と考えた。

用途	最終出力
YouTube通常動画	1920×1080
YouTube Shorts	1080×1920

動画を最初からフルHDで生成すると計算負荷が大きい。そこで、まずは約半分の縦横サイズでシーンを作る。

MFLUXで扱いやすい16の倍数に合わせ、次のサイズを採用した。

方向	生成サイズ	想定する最終サイズ
横	960×544	1920×1080
縦	544×960	1080×1920

厳密な半分である960×540／540×960とは数ピクセル異なる。最終的なFHD化では、拡大後にわずかにクロップして調整する。

7. 縦横を選べるスクリプトを作成

最終的に japanese_mflux_half.py を作成した。既存のPython＋Swift/AppKitダイアログを拡張し、縦横方向を選択できるようにした。

主な機能は以下のとおり。

日本語プロンプトを入力し、前回の入力を再利用
Ollamaで英語プロンプトに変換
モデルを選択
LoRAの有無と強度を選択
シードとステップ数を指定
縦／横を選択
PNGを連番保存し、生成後に自動表示

実行例：

cd /Volumes/Hanye2T/dev/GitHub/japanese-krea
python3 japanese_mflux_half.py

このフォルダは筆者の環境でのパスである。ほかの環境では適宜読み替えてほしい。

スクリプトの配布について： 本文では実行方法と検証結果を記載した。公開用のコードをGitHubに反映した場合は、実際のファイルURLを追記する。

8. 最終的な動作確認

japanese_mflux_half.py を使い、横960×544、縦544×960の両方で正常な画像を生成できた。さらに、問題が起きていたkp-forks LoRAを有効にしても正常だった。

検証項目	結果
横960×544	正常
縦544×960	正常
kp-forks LoRA	正常

この結果から、少なくとも筆者の環境では、512×512しか使えないわけではなく、動画素材向けの縦横サイズでも生成できることが確認できた。

なお、モデルごとの全組み合わせや、長時間の連続生成までは検証していない。

9. 次の目標：静止画から動画へ

今後の制作工程は次のように考えている。

① シーンごとの静止画生成（FLUX / Krea）
                  ↓
② ハーフHD相当で動画生成（Wan 2.2など）
                  ↓
③ セリフ・歌・音声の準備
                  ↓
④ リップシンク（口の動きを音声に合わせる）
                  ↓
⑤ シーン編集・BGM・字幕
                  ↓
⑥ AI動画アップスケールでFHD化
                  ↓
⑦ YouTube / Shorts向けに書き出し

AIアップスケールは単純な画素の引き伸ばしとは異なり、学習済みの特徴から細部を推定・生成する。ただし、存在しなかったディテールを正確に復元するわけではない。動画ではフレーム間のちらつきや、顔・口元の変化にも注意が必要だ。

動画生成・リップシンク・AIアップスケールの連携は今後の計画であり、今回の動作確認範囲には含まれない。

10. まとめ

今回の成果は次のとおり。

kp-forks/Flux-uncensored がFLUX.1 dev用のLoRAであることを踏まえ、識別しやすいファイル名に変更した。
LoRAを強くしても画質が必ず向上するわけではないことを確認した。
紫色の画像が出た問題を、直接コマンドと統合スクリプトの比較で切り分けた。
この環境では、解像度を変更すると正常生成できることを確認した。
横960×544・縦544×960の両方で、kp-forks LoRAを含めて正常生成できた。
将来の動画生成とFHDアップスケールに向けた静止画制作環境を整えた。

今回、特に重要だったのは、動作したコマンドを基準にして、条件を一つずつ比較することだった。生成ログが成功でも画像が正常とは限らない。画像生成AIでは、実際の出力を確認しながら条件を切り分けることが欠かせない。

前回：ローカルLLMを使う第7回：Mac Studioで高品質と表現の自由度を追求し、Uncensored FLUX.1 devを動かす

LoRA：kp-forks/Flux-uncensored

GitHub：japanese-krea