ローカルVLMとComfyUIを連携し、画像からプロンプトを起こして生成するパイプラインを作った
今回やったこと / この記事について
画像を見て、その内容を画像生成用のタグ形式プロンプトへ変換する工程を、ローカルの視覚言語モデル（VLM）からComfyUIの生成処理までつないだ。目的は、画像を説明するだけの機能ではなく、説明結果を次の生成へそのまま渡せる一連の作業にすることだった。画像生成を繰り返すと、毎回プロンプトを手で書き直す工程がボトルネックになる。そこで、画像の観察、タグ化、生成、記録を一つの流れとして扱った。
採用したのは、Ollama経由の huihui_ai/Qwen3.8-abliterated:27b である。vision・tools・thinkingに対応しており、画像説明を返すだけでなく、作成したパイプラインスクリプトに -g オプションを付けることで、画像からプロンプトを作り、そのまま生成まで進められる構成にした。
画像説明で終わらせない構成
この構成では、入力画像をVLMへ渡し、Animagine形式のタグpromptを作る。生成側にはモデル、prompt、seed、サイズなどを prompts.jsonl として残す。生成結果だけを保存すると、後から同じ条件を再現できないため、入力に対する説明と生成条件を別々にせず、同じ処理の記録として扱う。
処理の流れは次のとおりである。
入力画像
↓
ローカルVLMによるタグ抽出（Animagine形式）
↓
Animagine形式のタグprompt
↓
ComfyUIで画像生成
↓
モデル・prompt・seed・サイズをprompts.jsonlへ記録
以前試したモデルでは、タグの無限ループや、安全フィルタによるサイレントな拒否が問題になった。そのため、モデルの名前や知名度ではなく、実際に必要な処理を最後まで止めずに実行できるかを基準に乗り換えた。ここでの「ローカル化」の価値は、汎用的な知能を持たせることではない。従量課金なし、データを外へ出さないという境界を保てることにある。拒否でバッチ全体を止めない点は、採用したモデルの性質と例外処理の設計による。
本体と個人ツールを分ける
ComfyUI本体と、画像を説明して生成までつなぐ個人ツールは別リポジトリに分け、symlinkで接続した。本体側へ個人向けの試作コードを直接置かないことで、ComfyUIの更新と実験ツールの変更を独立させられる。画像生成環境はノードやモデルの更新だけでも壊れやすいため、処理を追加する場所を分けること自体が保守の一部になる。
一方で、分離したから安全になるわけではない。モデル名の一字違いで別モデルをpullする事故や、ComfyUI本体の絶対パスが古いまま半年近く残っていた問題も明らかになった。モデル名はエイリアスで済ませず、実際に解決されたモデル名をログへ残す必要がある。起動時に本体の場所を検査する処理も、画像生成の品質とは別の運用上の要件になる。
やってみてわかったこと
画像→説明→生成の接続で重要なのは、VLMが流暢な説明を書けることではない。次の工程が読める形式で返し、生成結果と条件を追跡できることだ。説明文がきれいでもタグへ変換できなければ作業は手作業に戻る。反対に、タグの粒度が一定していれば、説明の文章が簡潔でも反復作業には使える。
また、ローカル運用の利点は「高性能なモデルを所有すること」ではなく、処理の境界を自分で決められることにある。入力画像を外部へ出さず、生成条件を手元に残し、失敗した画像だけを切り分けられる。個人制作で重要なのは、モデルの能力を大きく見せることではなく、失敗しても原因を追える小さなパイプラインにすることだった。
更新履歴
- 2026-09-21: 初稿作成。
訂正履歴
現時点で訂正なし。