ローカル環境で画像生成をしていると、プロンプトの組み立てに時間を取られることがあります。特にNSFW用途では、クラウドAIに翻訳や表現の補助を頼もうとしても断られるケースが増えています。
今回は「ならローカルLLMを使えばいいのでは」という発想から試したことを書いておきます。
クラウドAIの制限は「仕様」として受け入れる
クラウド型のAIサービスは、年々安全制限が強化されています。NSFW関連の翻訳や表現の補助を依頼すると、拒否されることが以前より増えました。
これは良い悪いの話ではなく、サービス設計上の仕様です。ただ、制作の途中でフローが止まる点は実用上の問題になります。サービスによって対応の幅は異なりますが、いつ挙動が変わるかわからない不安定要素でもあります。
ボトルネックは「日本語→英語変換」
NSFWプロンプトの設計でつまずく場所は、ほぼここに集中しています。
- 日本語で思い描いたニュアンスを英語に変換する
- 表現の揺らぎを整理する
- 近い意味の単語を比較して選ぶ
この作業をクラウドLLMで補助しようとすると、用途次第で弾かれます。かといって検索で解決しようとすると、時間がかかるうえに欲しい答えが見つからないことも多いです。
ここで自然に発想が転換しました。ローカルで画像生成できる環境があるなら、LLMもローカルで動かせばいい。
ローカルLLMを補助脳として使う
ローカルLLMは外部サービスへの通信が不要なので、クラウド側の制限に左右されません。翻訳を頼んでも、表現を整理してもらっても、途中で止まることがなく、思考のテンポが維持されます。
ただし、ローカルLLMにも安全制限は存在します。モデルによっては、ローカルで動いていても特定の表現を拒否するものがあります。補助脳として機能させるためには、モデルの選定が重要です。
モデル選定の考え方
実用に耐えるモデルを選ぶ際、以下を基準にしています。
基本条件
- ある程度の規模（14Bクラス以上が目安）
- Instructチューニング済み
- 英語出力が自然
用途によって追加で必要な条件
- リミッターが緩和された派生モデルであること
ベースモデルのままだと、翻訳や表現補助を拒否するケースがあります。用途によっては、安全制限が緩和された派生モデルを選ぶ必要があります。精度と自由度の両立が、この用途では特に重要です。
具体的なモデル名はリリース頻度が高く情報が古くなりやすいため、ここでは割愛します。Hugging Faceなどで定期的に確認するのが現実的です。
ワークフローのイメージ
実際の流れはシンプルです。
- 日本語で意図を書く
- ローカルLLMに英語化させる
- 表現の揺らぎや言い換えを整理させる
- 画像生成に投入する
- うまくいかない場合のみ、検索で補完する
検索は最後の手段です。この順番にするだけで、作業時間はかなり変わります。
実感しているメリット
- 翻訳・表現整理が止まらない
- 検索に使う時間が減る
- 「80点の状態」に到達するまでが早くなる
- 思考のテンポが保たれる
「完璧な生成結果を最短で出す」というよりは、試行錯誤の入口に立つまでの時間を短縮するというイメージが近いです。
注意点
いくつか留意しておくべき点もあります。
モデルの規模は重要で、小さいモデルだと英語の自然さが落ちたり、指示の解釈がブレたりします。リミッター緩和モデルを使ったとしても、すべての表現に対応できるわけではありません。
また、生成するコンテンツの倫理的・法的な問題は、ツールの効率とは別軸の話です。ローカル環境であっても、何を生成するかについての判断は制作者側にあります。この記事はあくまで制作効率化の一案として書いています。
まとめ
ローカルで画像生成できる環境があるなら、LLMもローカルで補助させる選択肢は自然な延長線上にあります。
重要なのはモデルの規模と制限の緩和度の両立です。検索依存を減らすことは、そのままプロンプト設計の時間短縮に直結します。研究や実証ではなく、個人制作のTipsとして参考にしていただければと思います。