wan2.7-image-standard プロンプトレシピ：レイアウトとテキストレンダリングのためのコピー＆ペースト式プロンプト

これらのプロンプトレシピの使い方

本ガイドの各レシピはすべて同じ形式に従います。短いロール説明、ラベル付きスロットのセット、そしてスタイルとレンダリング挙動を固定するための固定エンディングです。スロットの内容だけを埋め、骨格はそのままにすれば、複数回の実行間で比較可能な出力が得られます。

テンプレートは次のとおりです：

[subject] | [layout spec] | [text block] | [style tail]

縦線で区切られた各セグメントは1つの問いに答えます。主体（subject）は画像に何があるかを示します。レイアウト仕様（layout spec）は各要素がどこに配置されるかを示します。テキストブロック（text block）は画像に焼き込む必要があるコピーを担います。スタイルエンディング（style tail）はレンダリング外観を固定し、複数回の実行間でぶれないようにします。

レシピを改変する際は、スロットの構造ではなくスロットの内容を変更します。主体に2つではなく3つのカードブロックが必要なら、レイアウト仕様を編集します——レイアウトセグメントを削除してはいけません。フレームワークを完全に保つことで、レシピが再利用可能になり、失敗がデバッグ可能になります。何かがうまくいかないとき、どのセグメントのせいかを判断できるからです。

実用的なサイクルは次のとおりです：レシピをコピーし、自分の内容を入れ、生成し、他の変更を行う前に前回の実行結果と比較します。2つのスロットを同時に書き換えると、どちらの編集がレンダリングを修正したのか、あるいは壊したのかを判断する能力を失います。

レシピ：レイアウトと構図の制御

レイアウトはプロンプトの中で最も制御しやすい部分であり、同時に多くの人が最も曖昧に表現する部分でもあります。曖昧なレイアウト言語は曖昧な構図を生みます。

レシピ：固定されたグリッド

[subject] | centered subject inside a 3-column grid, equal gutters, elements aligned to grid lines, generous outer margins, no overlapping shapes | [text block] | flat vector style, high contrast, clean edges

3-column grid, equal gutters というフレーズが大半の仕事を担います。これにより、構図への願望が数えられる制約に変わります。列数はレイアウトに必要な値に置き換えます——2-column、4-column、single centered column。

階層と余白

階層とは、プロンプトが相対的なサイズを明示することを意味します：

[subject] | one dominant headline block occupying the upper third, two smaller supporting blocks beneath it, at least 30% of the canvas left empty

余白の要求は逐語的に書く価値があります。明示的な空白領域の指示がないと、出力はしばしば画面を埋め尽くそうとします。left empty と spacious は異なるツールとして扱いましょう。前者は制約であり、後者は雰囲気です。

予見できる失敗パターン

• 1回の実行で多数の位置句を積み重ねる（top-left AND bottom-right AND centered）と、モデルがすべての句に妥協します。
• 同じセグメントでレイアウト言語とスタイル言語を混在させると、両方が混乱します。
• 互いに暗黙的に含まれる要素名（icon grid containing icons）は何の情報も追加しません。

レイアウトセグメントは純粋な幾何記述に保ちましょう。スタイルはエンディングセグメントに置きます。

レシピ：テキストを明瞭にレンダリングする

テキストの焼き込みは画像生成の中で最も分散の大きい部分です。信頼できるレバーは順に、長さ、引用符、位置です。

レシピ：短い引用符付きテキスト

[subject] | headline area in the upper center, one line of text only | headline text: "Ship Faster" | clean sans-serif, solid fill, high contrast against background

テキスト内容は二重引用符の中に置き、他のどこにも置きません。引用符は「これを文字どおりレンダリングせよ」というシグナルを伝え、散文でテキストを説明するよりはるかに一貫しています。引用符内の文字列は1〜2語に抑えましょう。長い文は近似字形へと劣化します。

役立つ配置の手がかり

テキスト領域はレイアウトセグメントに、テキスト自体はテキストセグメントに置きます。この分離により、見出しを書き換えることなく移動でき、これはよくある反復の組み合わせです。

有用な配置の言い回し：

• headline area in the upper third
• label beneath the main block
• single centered line, no wrapping

no wrapping というフレーズは真の制約であり、モデルが短い文を2行に折り返すのを防ぎます。

長さと言い回しの規律

プロンプトを書く前に、文字数を頭の中で制約しましょう。あるフレーズがあなたのレイアウト尺度で1つの視覚行に収まらないなら、モデルに縮小を求めるのではなく、短くします。まず句読点を削り、次に単語を削ります——余分なカンマやアポストロフィはアーティファクトのよくある原因です。

テキストレンダリングが文字化けする場合、まず短くし、次にスタイル記述子を簡素化し、その後配置の手がかりを移動します。1回の実行で変更するのはそのうち1つだけです。

レシピ：構造化カードとパネル

マルチブロックレイアウトはレシピが最も報われる場所です。繰り返しこそがプロンプトに正確な記述を要求する内容だからです。

レシピ：繰り返しカード行

[subject] | a row of 3 identical cards, equal width, equal spacing between cards, consistent inner padding on all four sides, card content top-aligned within each card, unified outer margin | [text block] | flat vector style, subtle border, high contrast

荷重を担うフレーズは identical、equal width、equal spacing、consistent inner padding です。それぞれが測定可能な属性です。identical という語は数よりも重要です。明示的に一致を指示しない限り、モデルは喜んでサイズの異なる3枚のカードを生成します。

整列軸

内容がどの辺に整列するかを指定します。top-aligned within each card や left-aligned text with a single leading edge はどちらも有効です。各ブロックに整列軸を指定することで、内容が各カード内で独立して浮遊するときに生じるドリフトを防げます。

レシピの拡張

1行からグリッドにするには、幾何記述だけを変えます：

a 2x2 grid of 4 identical panels, equal gutters horizontally and vertically, consistent inner padding

密度を下げるには、内側パディングを縮めるのではなくブロック数を減らします。より少なく内側パディングが十分なブロックは、詰め込まれた多くのブロックよりもきれいにレンダリングされます。

よくある失敗パターンは、各カードの内容を異なるものにしつつ構造を同じにするよう求めることです。カードが内容では異なるが形状では一致する必要がある場合は、明示的に述べます：identical card dimensions and spacing, varying text content per card。

パラメータと反復のコツ

プロンプト作業はデバッグ作業です。重要な規律は単一変数の反復です。

1つだけ変える

現在のプロンプトを書き留め、1箇所だけ編集し、生成し、比較します。変更が助けになったなら、保持して記録します。助けにならなかったなら、補償フレーズを重ねるのではなく完全に元に戻します。補償フレーズは誰も推論できないプロンプトへと蓄積します。

実行を比較可能に保つ

プロンプトテキストを反復する間は、パラメータを固定します。同じラウンドでレイアウトの言い回しと生成設定を調整すると、結果を帰属できません。シードか設定のベースラインを選び、それに対してプロンプトを変化させ、その後で勝ったプロンプトに対してパラメータを調整します。

積み重ねるのではなく書き換える

あるセグメントが2回連続で失敗したら、限定詞を追加するのではなく書き換えます。centered が失敗したら centered, truly centered, make sure it is centered ではなく aligned to the horizontal center line に変えます。同じ語の繰り返しはノイズとして読まれます。

何を試したか記録する

各レシピについて短い変更ログを保ちます：行った編集、実行識別子、結果の1行説明。これが反復と放浪の違いです。数回の実行後、どのスロットが本当に敏感かが見えてきます——通常はスタイルエンディングではなく、レイアウトかテキストです。

最後に、構造が使えるようになるまでは、スタイルを先に調整したい衝動を抑えましょう。まず素朴なスタイルエンディングの下で幾何とテキストを正しくし、その後で外観を磨きます。

実際の生成出力付きレシピ

ここではこれらのレシピをエンドツーエンドで実行し、提案を盲信するのではなく結果を判断できるようにします。以下の各項目は、提出されたプロンプトとその横の生成出力を示しています。

実行1：引用符付き見出しを持つ固定グリッド

announcement graphic | centered subject inside a 3-column grid, equal gutters, elements aligned to grid lines, generous outer margins | headline text: "Ship Faster" | flat vector style, high contrast, clean edges

見るべき点：見出しが1行に収まっているか、列間隔が本当に等しく読めるか、外側マージンが保たれているか。外側マージンをレシピが宣言した意図と比較しましょう——「ゆったり」は実行間で最初に侵食されるものです。

実行2：3カード行

feature overview | a row of 3 identical cards, equal width, equal spacing between cards, consistent inner padding, card content top-aligned | feature labels: "Build", "Ship", "Measure" | flat vector style, subtle border

見るべき点：カード幅の一貫性、そして3つのラベルがベースラインを共有しているか。短い単語ラベルは最も寛容なケースです。この実行が上限を確立し、その後により長いコピーを試します。

実行3：余白を持つ階層

section header | one dominant headline block in the upper third, one smaller supporting block beneath, at least 30% of canvas left empty | headline text: "Release Notes" | minimal flat style

見るべき点：空白領域が連続しているか散在しているか。散在する余白はレイアウト指示が緩く解釈されたことを示し、空白領域を名前付き領域として言い直すべき信号です。

各出力はそのレシピの参照点であり、保証ではありません。内容を入れたバージョンが参照より劣る場合、差異は通常あなたが変更したスロットにあります——戻ってそのセグメントを語単位で比較しましょう。

レシピを反復可能なワークフローにする

チャットウィンドウの中に生きるレシピは資産ではありません。繰り返し価値を得るには、チームが検索し、比較し、バージョン管理できる場所にレシピを保存します。

レシピをファイルとして保存する

各レシピを小さな構造化ファイルとして保存し、スロットを固定フレームワークから分離し、レシピの目的とこれまでにどの出力を生んだかの説明を添えます。スロットを分離して保存することは、内容の更新がフレームワークに決して触れないことを意味し、これこそがこれらのレシピが依存する不変条件です。

内容だけでなくフレームワークをバージョン管理する

固定エンディングを変更したとき——スタイルの言い回し、レンダリング記述子——記録します。フレームワークの変更はそのレシピの将来のすべての使用に影響するため、バージョン番号を上げ、理由を1行添える価値があります。

出力をバージョンに添付する

各バージョンのそばに参照出力を1つ保ちます。レビュアーと将来の貢献者は、すべてを再実行することなく期待品質を確認できます。これは上記の各実行と同じ原則です：出力は常にプロンプトのそばに置く。

単一インターフェース経由でルーティングする

すべてのレシピを同じAPIインターフェース経由で実行し、生成設定、ログ、識別子を統一します。異なるレシピが異なるツールチェーンを通ると、1週間で比較は意味を失います。実際には、これは各マシンに散らばったアドホックスクリプトではなく、プロンプトを集中的に提出することを意味します。

実際に再利用する1〜2個のレシピから始め、単一インターフェース経由でパイプラインに接続し、真の必要が現れたときだけ集合を増やします。小さくバージョン管理が行き届いたレシピ集は、誰も信頼しない雑多なプロンプトライブラリに勝ります。