スタイルガイドをComfyUIのプロンプトに反映するなら、RAGで取得した規則の文章をそのまま貼らず、「色」「構図」「禁止事項」などの固定フィールドに変換してからworkflowに流します。どの規則を参照したかをSource ID付きで生成ログに残すと、画像ごとに「なぜこの設定になったか」を後から追えます。
情報確認日：2026年8月22日（日本時間）
結論：RAGは「規則を引く」ためで、「画風を再現する」ためではない
責任範囲
- 画像生成でRAGが役に立つ対象（ブランド規則・キャラ設定・撮影規則）を整理する
- 1つのChunkに矛盾する規則を入れない、検索対象の整え方を示す
- Ollamaの
/api/embedで画像用途に必要な部分だけ扱う - 取得した規則をプロンプト設定のフィールドに変換する手順を示す
- Source ID・Chunk・Versionを生成ログに残す形式を示す
- RAGで解決しないこと（画風再現など）を線引きする
RAGの仕組みと5段階、向く資料・向かない資料はRAGとは？生成AIに自分の資料を参照させる仕組みで説明済みです。取得した規則からSchema検証付きのJSONを作る実装はOllamaのStructured OutputsでComfyUI設定JSONを作るに分けています。Vector DBの選定比較は扱いません。
画像生成にRAGを使う目的
画像生成でRAGが効くのは、「毎回プロンプトに書くには長すぎるが、守らないと困る規則」があるときです。ブランドカラーの指定、キャラクターの髪型や服装の決まり、商品撮影の角度や背景の規則などがこれにあたります。
| 対象 | RAGに向くか | 理由 |
|---|---|---|
| ブランドカラー・禁止色 | 向く | 文章で一意に決まり、依頼ごとに該当部分だけ引けばよい |
| キャラクターの設定（髪・服・小物） | 向く | キャラごとに規則が分かれ、該当キャラの分だけ取得できる |
| 撮影・構図の社内規則 | 向く | 用途別（商品・人物・背景）に規則が分かれている |
| 画風そのもの（筆致・質感） | 向かない | 文章で表現しきれず、参照画像やLoRAの領分 |
| 「良い感じ」の基準 | 向かない | 規則として書けていないものは検索しても出てこない |
RAGを入れる前に、「規則が文章として書かれているか」を確認します。書かれていない規則はRAGでは引けません。先にスタイルガイドを書くほうが順序として正しく、RAGはその後です。
検索対象を整える
スタイルガイドをそのまま分割すると、1つのChunkに「Aのときは赤」「Bのときは青」のような条件付きの規則が混ざり、検索で引いたChunkの中で矛盾が起きます。Chunkは「1つの条件に1つの規則」になるよう、分割前に書き直します。
悪い例（1 Chunkに条件が混在）
商品写真の背景は白。ただしアパレルはグレー、食品は木目。
人物を含む場合は背景をぼかす。
良い例（条件ごとに分ける）
[SG-BG-001] 用途: 商品写真（一般） / 背景: 白 / 禁止: 柄物
[SG-BG-002] 用途: 商品写真（アパレル） / 背景: グレー
[SG-BG-003] 用途: 商品写真（食品） / 背景: 木目
[SG-BG-004] 用途: 人物を含む商品写真 / 背景: ぼかし各Chunkの先頭にIDを付け、「用途」「対象」「規則」「禁止」の見出しを揃えておくと、後段でフィールドに変換するときに位置で拾えます。同じ対象の規則を改訂したら、古いChunkを消すのではなくversionを上げて新しいChunkを登録し、検索対象は最新versionだけに絞ります。
Chunkのサイズに正解はありません。上の例のように1規則が数行で済むなら、1規則=1 Chunkで十分です。長い説明が必要な規則は、説明部分を別Chunkに分け、IDで相互参照させます。
Embeddingと検索単位
Embeddingの作り方はOllamaの/api/embedにmodelとinputを渡すだけで、inputには文字列の配列も渡せます。公式ドキュメントはembeddinggemma、qwen3-embedding、all-minilmを例に挙げており、返るベクトルはL2正規化済みです。モデルの選び方や類似度の計算の一般論はRAGの基本記事に譲り、ここでは画像用途で違う点だけ書きます。
curl -X POST http://localhost:11434/api/embed \
-H "Content-Type: application/json" \
-d '{
"model": "embeddinggemma",
"input": [
"[SG-BG-001] 用途: 商品写真（一般） / 背景: 白 / 禁止: 柄物",
"[SG-BG-002] 用途: 商品写真（アパレル） / 背景: グレー"
]
}'画像用途で違うのは、検索クエリが「依頼文」ではなく「依頼を分解した条件」になる点です。「新商品のTシャツの写真を作って」という依頼をそのまま検索すると、Tシャツに関するChunkが広く引かれます。先に「用途=商品写真」「対象=アパレル」「人物=なし」と条件に分解し、条件ごとに検索したほうが、必要な規則だけが上位に来ます。取得件数は条件ごとに少数に絞り、同じ対象の規則が複数versionで引かれたら最新だけ残します。
取得内容をプロンプト設定に変換する
引いたChunkの文章をそのままpositive promptに連結すると、日本語の規則文がそのまま入って効かないうえ、どの規則がどの語に対応したか追えなくなります。Chunkを「プロンプトに入る語」「negativeに入る語」「workflowのパラメータ」の3つに振り分けるフィールド変換を挟みます。
{
"type": "object",
"properties": {
"background": { "type": "string" },
"palette": { "type": "array", "items": { "type": "string" } },
"forbidden": { "type": "array", "items": { "type": "string" } },
"composition": { "type": "string", "enum": ["centered", "rule_of_thirds", "flat_lay", "unspecified"] },
"aspect": { "type": "string", "enum": ["1:1", "4:5", "16:9", "unspecified"] },
"sources": { "type": "array", "items": { "type": "string" } }
},
"required": ["background", "palette", "forbidden", "composition", "aspect", "sources"]
}この変換をOllamaに任せる場合は、formatにこのSchemaを渡し、「取得したChunk以外の規則を作らない」「該当がなければunspecified」と指示します。出てきたフィールドをworkflowに当てはめる対応表は、コード側で固定します。
| フィールド | 入る先 | 変換例 |
|---|---|---|
background |
positive promptの固定位置 | 「white seamless background」 |
palette |
positive promptの色指定部分 | 色名の列挙 |
forbidden |
negative prompt | 「pattern, logo, text」 |
composition |
プリセット（構図用の定型句） | enumごとに固定文 |
aspect |
Empty Latent Imageのwidth・height | 「4:5」→ 832×1040 など事前定義の解像度表 |
LLMが作るのはフィールドの値までで、promptの全文や解像度の数値はコード側の対応表から組み立てます。こうすると、規則を改訂したときに変わるのはChunkだけで、変換ロジックは触らずに済みます。
参照元を生成ログに残す
「この画像の背景が白なのは、どの規則によるか」を後から答えるには、画像ごとに参照したChunkのIDとversionを残す必要があります。ComfyUIのworkflow JSONや画像metadataには設定値しか残らないため、別に生成ログを持ちます。
{
"request_id": "req-20260916-0012",
"prompt_id": "a1b2c3d4-...",
"seed": 123456789,
"style_guide_version": "2026-08-15",
"retrieved": [
{ "source_id": "SG-BG-002", "chunk_version": 3, "score": 0.81 },
{ "source_id": "SG-COLOR-007", "chunk_version": 1, "score": 0.77 }
],
"fields": {
"background": "グレー",
"palette": ["ネイビー", "白"],
"forbidden": ["柄物", "ロゴ"],
"composition": "centered",
"aspect": "4:5"
},
"output": { "filename": "ComfyUI_00012_.png", "subfolder": "", "type": "output" }
}prompt_idはComfyUIの/prompt応答で返る値、outputは/history/{prompt_id}から取った値です。この1件で「依頼 → 引いた規則 → 設定 → 画像」が一本につながります。規則が改訂されたあとに古い画像を見直すときは、style_guide_versionとchunk_versionで「当時の規則では正しかった」と判断できます。
検索なし／RAGありで遵守率を比べる
RAGを入れる効果は、自分のガイドと依頼で測らないと分かりません。同じ10件の依頼を「検索なし（ガイドを渡さない）」「RAGあり」で生成し、規則ごとの遵守を人が記録します。
固定するもの
- checkpoint・VAE・seed（依頼ごとに同じseed）
- sampler・scheduler・steps・CFG
- 変換Schema・対応表
変えるもの
- 検索結果をフィールド変換に渡すか（なし／あり）| 依頼 | 該当規則（ID） | 検索なし：遵守 | RAGあり：遵守 | 引かれたChunkは正しかったか |
|---|---|---|---|---|
| 1 | ||||
| 2 | ||||
| … | ||||
| 10 |
見るべきは遵守率の差だけではありません。「RAGありで守れなかった」依頼は、原因が「引けなかった（検索の問題）」か「引けたのに変換で落ちた（Schemaか対応表の問題）」か「設定に入ったのに画像に出なかった（生成側の問題）」かで直す場所が違います。最後の列で切り分けます。
RAGで解決しないこと
RAGが渡せるのは「文章で書かれた規則」だけです。次のものは、別の道具の領分です。
RAGで扱えること
- 色・背景・構図・禁止事項のように語で指定できる規則
- 対象（商品・キャラ）ごとに分かれた決まり
- 規則の改訂履歴と出典の追跡
別の道具が必要なこと
- 画風・筆致・質感の再現（LoRAや参照画像）
- 同じ人物・キャラの顔の一致（参照画像による制御）
- 特定の構図の厳密な固定（構図制御の道具）
画風や人物の一致は、参照画像を「画像で書いたprompt」として渡すComfyUIでIP-Adapterを使う方法の領分です。RAGはそのとき「どの参照画像を使うか」「どのLoRAを何の強度で使うか」を規則として引く役に回ります。規則に「このキャラはLoRA Xを0.7で」と書いてあれば、RAGで引いてフィールドに落とし、LoRAの適用自体はworkflowが行う分担です。
よくある質問
スタイルガイドが短いなら、全文をpromptに入れればよいのでは？
規則が数行で、対象が1種類ならそれで足ります。RAGが必要になるのは、対象ごとに規則が分かれ、依頼によって該当部分が変わるときです。全文を毎回入れると、該当しない規則まで効いて結果がぶれます。
引いたChunkをそのままpromptに入れてはいけませんか？
日本語の規則文はそのままではpromptとして効きにくく、どの語がどの規則から来たかも追えません。フィールドに変換し、対応表でprompt語やパラメータに落とす段階を挟んでください。
Embeddingモデルはどれを選べばよいですか？
公式が例示するモデルから、自分のガイドの言語で短い規則文をうまく引けるかを、上の10依頼の表で確かめて決めます。用途と言語で結果が変わるため、この記事では特定モデルを推奨しません。
まとめ
スタイルガイドのRAGは、「1条件1規則」にChunkを整え、依頼を条件に分解して検索し、引いた規則を固定フィールドに変換してからworkflowに渡す、という順で組みます。画像ごとにSource IDとversionを生成ログに残せば、設定の根拠を後から追えます。画風や人物の一致はRAGでは解決せず、参照画像やLoRAの役割です。この流れをn8nで依頼の受付から承認までつなぐ方法は別記事で扱います。