はじめに
前回（第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を動かす
GitHub：japanese-krea