ローカルLLMで画像プロンプトを作る｜日本語から英語への変換品質を比較

ローカルLLMに画像プロンプトを作らせるなら、「日本語を英語に訳す」のではなく、Subject・Style・Composition・Lightingなどの項目に分解させてJSONで受け取ります。どのモデルが向くかは決め打ちできないため、同じ日本語依頼10件を複数モデルに通し、固定の評価項目で比べてから選びます。

情報確認日：2026年8月22日（日本時間）

結論：翻訳ではなく項目化、評価は固定項目で複数モデル比較

Ollamaの導入と基本操作はOllamaの使い方で扱っています。formatにJSON Schemaを渡してComfyUI用の設定JSONを作り、受信後に再検証する方法はStructured Outputsの記事、LLMの出力をComfyUIに安全に渡す役割分担はOllamaとComfyUIの連携を参照してください。この記事は「prompt本文の品質をどう作り、どう比べるか」に絞ります。画像prompt一般の書き方や、特定モデル向けのタグ辞書は扱いません。

LLMに任せる範囲を決める

ローカルLLMが得意なのは、曖昧な日本語から「何を・どんな雰囲気で・どう構図で」を取り出して英語の句に整えることです。苦手なのは、実在する作家名・作品名・製品名を正しく引くことと、そのモデルに効くタグを知っていることです。後者はLLMの学習データと画像モデルの組み合わせに依存し、もっともらしい嘘が混ざります。

「任せない」側は、system promptで禁止するだけでなく、後述の検査で機械的に弾きます。LLMは禁止と言われても出すことがあるためです。

入力テンプレートを項目化する

出力を自由文にすると、モデルごとの癖（長さ・語順・修飾の多さ）がそのまま比較のノイズになります。先に項目を決め、各項目を短い英語句で埋めさせます。

{
  "type": "object",
  "properties": {
    "subject":     { "type": "string", "description": "main subject, one noun phrase" },
    "action":      { "type": "string", "description": "what the subject is doing, or empty" },
    "setting":     { "type": "string", "description": "place and time" },
    "style":       { "type": "string", "description": "medium and rendering style, no artist names" },
    "composition": { "type": "string", "description": "framing and camera angle" },
    "lighting":    { "type": "string", "description": "light source and mood" },
    "palette":     { "type": "string", "description": "dominant colors, or empty" },
    "negative":    { "type": "array", "items": { "type": "string" } },
    "uncertain":   { "type": "array", "items": { "type": "string" },
                     "description": "Japanese phrases the model could not map confidently" }
  },
  "required": ["subject", "setting", "style", "composition", "lighting", "negative", "uncertain"]
}

最後のuncertainが重要です。「えもい感じで」「いい塩梅に」のような、英語の句に落とせない表現を、推測で埋めずにここに入れさせます。ここが空でないときは、人が日本語の依頼を直すか、項目を補う合図になります。

最終的なprompt文字列は、LLMに作らせず、こちらのコードで項目を決まった順に連結します。連結順を固定しておけば、モデルを替えても「構造は同じで中身だけ違う」比較ができます。

// 項目をこちらの順序で連結する。LLMに最終文字列を作らせない
export function buildPrompt(p) {
  return [p.subject, p.action, p.setting, p.composition, p.lighting, p.palette, p.style]
    .filter((s) => s && s.trim())
    .join(", ");
}
export function buildNegative(p) {
  return (p.negative ?? []).join(", ");
}

日本語から構造化promptを得る

Ollamaの公式ドキュメントでは、formatにJSON Schemaオブジェクトを渡す方法が案内され、temperatureを下げること、Schemaをprompt本文にも書いてモデルに示すことが推奨されています。Schemaの設計と受信後の再検証は前述のStructured Outputs記事に任せ、ここでは依頼文の中身だけ示します。

{
  "model": "置き換える",
  "stream": false,
  "options": { "temperature": 0 },
  "messages": [
    {
      "role": "system",
      "content": "You convert a Japanese image request into structured English fields for an image generator. Rules: (1) Do not add artist names, brand names, or real person names even if implied. (2) Do not add quality tags such as 'masterpiece'. (3) Put things the user does not want into 'negative'. (4) If a Japanese phrase cannot be mapped confidently, copy it into 'uncertain' instead of guessing. (5) Each field is a short English phrase, not a sentence. Return JSON only."
    },
    { "role": "user", "content": "雨上がりの商店街を歩く制服の女の子。少しノスタルジックで、看板の文字は読めなくていい。人は他にいない感じで。" }
  ],
  "format": { "...": "上のSchemaをここに入れる" }
}

system promptを英語にしているのは、指示の解釈を安定させるためで、日本語でも動くモデルは多くあります。どちらが安定するかも、次の比較で確かめる項目の1つです。この依頼文は、Structured Outputs記事のSchema検証とComfyUI連携記事の「自由文をそのまま実行しない」規則の上で動く前提です。

モデルの違いを比較する

「日本語に強いモデル」の評判は、画像promptの項目化に当てはまるとは限りません。同じ10件を、手元にある複数のモデルに同じsystem promptとtemperature 0で通し、固定の評価項目で採点します。

再現してほしい比較：日本語依頼10件 × 複数モデル

1. 日本語の依頼を10件用意する。短文・長文・曖昧語入り・否定指示入り・固有名詞を匂わせるもの・英語混じりを混ぜる
2. モデルを2〜3個選び（ollama listにあるもの）、同じsystem prompt・Schema・temperature 0で10件ずつ送る
3. 各出力を次の5項目で採点する（0〜2点）。採点は人が行い、基準を先に文章で書いておく
4. 合計点ではなく、項目ごとの弱点を見る。「意味は正しいが冗長」「短いが固有名詞を出す」など、モデルごとの癖が分かる

この記事ではどのモデルが良いかを断定しません。採点は読者の依頼の傾向と画像モデルに依存するためです。見るべきなのは合計点より「禁止の遵守」と「uncertainの使い方」で、ここが0点のモデルは、他が高くても検査の負担が増えます。

長文promptの限界を確かめる

LLMに作らせると、promptは長くなりがちです。長いほど良いとは限らない理由は2つあります。画像モデル側のテキストエンコーダには扱えるトークン数の上限があり、超えた部分は切り捨てられるか、分割処理で重みが薄まること。もう1つは、修飾が増えるほど互いに打ち消し合い、主題がぼやけることです。

これも数値を断定せず、同じSeedで確かめます。

1. 比較で得た構造化promptを1件選び、buildPromptで連結した「通常版」を作る
2. 同じ項目から、subject・setting・lightingだけの「短縮版」と、各項目に形容詞を2つずつ足した「冗長版」を作る
3. ComfyUIでSeed・sampler・steps・CFG・解像度を固定し、3本のpromptで1枚ずつ生成する
4. 3枚を並べ、主題の明瞭さ・依頼した要素の有無・破綻を記録する

冗長版で依頼要素の再現が上がらず、余計な要素だけ増えるなら、それが手元の画像モデルでの上限の目安です。その語数を、LLMへの依頼文に「各項目は N 語以内」として戻すと、次回から長さが安定します。

生成前の検査を入れる

LLMの出力は、Schema検証を通っていても内容の検査が必要です。禁止語・権利・人物表現は、機械的な検査と人の確認を分けて入れます。

// validate-prompt.mjs — 機械的に弾ける範囲だけ。最終判断は人が行う
const BANNED = [
  /\b(masterpiece|best quality)\b/i,          // 品質タグ（モデル依存の呪文を混ぜない）
  /\b(in the style of|by)\s+[A-Z][a-z]+/,     // 作家名を示唆する定型
  /\b(logo|trademark|brand)\b/i,              // 商標に寄る語
];
const REQUIRE_REVIEW = [
  /\b(girl|boy|child|kid|teen)\b/i,           // 未成年を示す語 → 人が内容を確認
  /\b(nude|naked|lingerie)\b/i,               // 性的表現 → 原則不可
  /[A-Z][a-z]+ [A-Z][a-z]+/,                  // 固有名詞らしい2語 → 実在人物・ブランドの可能性
];

export function checkPrompt(fields) {
  const text = Object.values(fields).flat().join(" ");
  const errors = BANNED.filter((re) => re.test(text)).map((re) => `banned: ${re}`);
  const reviews = REQUIRE_REVIEW.filter((re) => re.test(text)).map((re) => `review: ${re}`);
  if (fields.uncertain?.length) reviews.push(`uncertain: ${fields.uncertain.join(" / ")}`);
  return { ok: errors.length === 0 && reviews.length === 0, errors, reviews };
}

errorsがあれば生成せず、LLMに再依頼するか依頼文を直します。reviewsがあれば生成を止めて人が判断します。正規表現は取りこぼしがあるため、検査を通った＝安全ではなく、「人が見る件数を減らす」道具として扱ってください。

よくある質問

まとめ

ローカルLLMで画像promptを作るときは、翻訳させるのではなく、Subject・Setting・Style・Composition・Lighting・Negative・Uncertainの項目に分解させ、最終文字列はこちらのコードで連結します。曖昧語は推測させずuncertainに入れさせ、人が直す合図にします。

モデルの優劣は断定せず、同じ10件を複数モデルに通して固定項目で採点し、長文の上限は同じSeedで3版を比べて決めます。生成前には、禁止語を機械で弾き、人物・権利に関わる語は人が判断する検査を必ず通してください。画像を見て再依頼する自動ループは別記事で扱います。