開発者向け Recraft v4.1 テキストtoイメージ プロンプトレシピ

なぜプロンプトレシピが使い捨てプロンプトより優れているのか

テキストtoイメージ API を呼び出すチームは、最終的に同じ壁にぶつかります。見事な結果を生み出したあの画像のプロンプトが、チャット履歴や使い捨てスクリプト、誰かのノートアプリの中に眠っているのです。製品要件が変化したとき——「同じイラストだが写真風に」とか「画像にタイトルを入れて」——どの単語が効いたのか誰にも分からず、プロンプトはゼロから書き直され、出力も予測不能に変わってしまいます。

プロンプトレシピは、プロンプトを小さなパラメータ化された文書として扱うことでこの問題を解決します。1つの骨格、いくつかの差し替え可能なブロック、そして短い制約リスト。スタイルの変更は全書き換えではなく単一フィールドの編集になり、プロンプトを diff したり、pull request でレビューしたり、出力がなぜ変わったのかを推論したりできるようになります。

レシピは品質のリグレッションをデバッグ可能にもします。画像が突然おかしくなったら、二分探索できます。主体ブロックか、スタイルブロックか、レイアウト指示か、それともネガティブリストか？ 使い捨てプロンプトなら、答えはたいてい「全部」です。

本ガイドでは、Recraft v4.1 テキストtoイメージに適した具体的な骨格を解説し、開発者が最もよく使う2大カテゴリ——イラストと写真——のコピー&ペースト可能なレシピを紹介します。同じ構造はレイアウト制御、画像内テキスト、ネガティブリストにも拡張できます。

レシピが実際に含むもの

各レシピは4つの部分として捉えてください：

• 固定骨格——コードベース内のすべてのプロンプトが共有する順序付きブロック。
• 差し替え可能なスタイル語彙——出力をイラストと写真の間で切り替える単語。
• 制約句——レイアウト、アスペクト比、文字レンダリング、除外指示。
• バージョンタグ——本番環境のプロンプトを、その素材を生成した正確なリビジョンまで追跡可能にする。

これらに特別なツールは不要です。レシピごとに1つの JSON ファイルを、API を呼び出すコードと一緒にリポジトリへコミットすれば十分です。

プロンプト骨格：保たれるブロックと変わるブロック

以下の骨格は意図的に退屈に見せています。それが要点です——安定した部分は決して編集不要であるべきで、そうすれば注意は変化する部分に集中できます。

[SUBJECT]        画像に何があるか、平易な言葉で記述
[STYLE]          媒体とレンダリングの語彙
[COMPOSITION]    フレーミング、カメラまたはレイアウト、アスペクト比
[CONSTRAINTS]    文字レンダリング、配色制限、禁止ルール

どのブロックが保たれ、どれが差し替えられるか

• SUBJECT——保持。通常、製品ロジックが唯一パラメータ化すべきブロックです（製品名、ユーザー入力からのシーン記述）。
• STYLE——差し替え。イラストと写真の違いはほぼここに集約されます。
• COMPOSITION——大部分差し替え。ただし指示の形態は変わりません（まずフレーミング、次にアスペクト比）。
• CONSTRAINTS——一部共有。ネガティブリストと「指定がなければ文字を入れない」ルールは多くの場合グローバルです。文字レンダリング指示はリクエストごとです。

データとしての最小テンプレート

{
  "recipe_id": "product-hero",
  "version": "3",
  "subject": "a ceramic coffee mug on a plain surface",
  "style": "{{style_block}}",
  "composition": "centered, generous negative space above the subject, square aspect",
  "constraints": ["no text in image", "no watermark"],
  "negatives": "{{negative_list_v2}}"
}

{{style_block}} プレースホルダーが継ぎ目です。残りの部分はレシピ間で共有されるか、呼び出し側が提供します。後日3つ目のスタイル——例えばアイソメトリック 3D——を追加するときは、新しいプロンプトファイルではなくスタイルブロックを1つ追加するだけです。

実用的な注意：ブロック順序をすべてのレシピで一貫させてください。モデルが順序に敏感かどうかは文書化された保証はありませんが、あなたのチームは敏感です。一貫した順序はプロンプトを比較可能にし、並列レビューを意味あるものにします。

イラストレシピ：フラット、ベクター、エディトリアル

イラストレシピはほとんどのチームの出発点です。イラストは単純化をよく許容するため、写実性と格闘せずに骨格をテストするのに適した選択肢になります。

フラットイラスト

[SUBJECT] a developer workspace with a laptop, notebook and coffee mug
[STYLE] flat vector illustration, solid fills, no gradients, bold simple shapes, limited four-color palette, clean geometric forms
[COMPOSITION] centered composition, even margins, square aspect
[CONSTRAINTS] no text in image, no shadows, no textures

この見た目を駆動する単語：フラット、単色塗り、グラデーションなし、太くシンプルな形状。どの単語も効いています。「グラデーションなし」を削ると、柔らかな影が忍び込むのがよく見られます。

ベクター風アイコン

[SUBJECT] a single shield icon with a checkmark
[STYLE] minimal vector icon, uniform stroke weight, rounded line caps, two-tone, high contrast on plain background
[COMPOSITION] centered, icon fills most of the frame, square aspect
[CONSTRAINTS] no text, no background scenery, no gradients

アイコンプロンプトは明示的な限定詞——単一の、均一な線幅——の恩恵を受けます。これらがないと、グラフィックシンボルではなく小さなシーンが得られがちです。

エディトリアルイラスト

[SUBJECT] a person reviewing charts on a large screen
[STYLE] editorial illustration, muted palette, subtle grain, hand-drawn line quality, slightly abstracted human figures, magazine feature style
[COMPOSITION] subject offset to the right, breathing room on the left, landscape aspect
[CONSTRAINTS] no text in image, no photorealism, no logos

エディトリアルスタイルは中間地帯にあります。フラットベクターより質感と個性がありますが、明らかに写真ではありません。落ち着いた配色とかすかな粒子感を組み合わせることが、どちらの極端にも滑り込まないための鍵です。

チューニングのヒント：一度に1つのスタイル形容詞だけを変えてください。「落ち着いた配色」を「鮮やかな配色」に変えるのは本物の実験です。一度に5語を変えるのはそうではありません。

写真レシピ：写実、スタジオ、ライフスタイルフレーミング

写真レシピは同じ骨格を使い、語彙だけが異なります。主体ブロックがほとんど変わらないことに注目してください——これがテンプレート化の見返りです。

クリーンなスタジオ製品写真

[SUBJECT] a ceramic coffee mug on a plain surface
[STYLE] professional studio product photography, soft diffused key light, gentle falloff, neutral background, sharp focus, realistic material detail
[COMPOSITION] centered, slight three-quarter angle, generous negative space above, square aspect
[CONSTRAINTS] no text in image, no props, no harsh reflections

写真語彙は光（柔らかな拡散、減衰）、光学（シャープなフォーカス、被写界深度）、素材のリアリティ（写実的な素材ディテール）の周りに集まります。イラスト語彙は形状と塗りの周りに集まります。この対比が2つのレシピファミリーのすべての違いです。

環境ライフスタイル

[SUBJECT] a person working at a wooden desk near a window
[STYLE] candid lifestyle photography, natural window light, shallow depth of field, warm neutral tones, realistic skin and fabric texture
[COMPOSITION] over-the-shoulder framing, subject left of center, landscape aspect
[CONSTRAINTS] no text in image, no visible brand marks, no exaggerated saturation

キャンディッドと自然な窓光が出力をスタジオの洗練から引き離します。結果が作りすぎに見えるなら、それは多くの場合スタイルだけでなく構図の問題でもあります——形容詞を積み重ねるより「肩越しフレーミング」を加えるほうが効きます。

イラストレシピを写真に変換する

動作するイラストレシピがあれば、変換は機械的です：

1. [STYLE] ブロック全体を写真語彙で置き換える。
2. [COMPOSITION] はフレーミングが異なる場合にのみ調整する（角度は写真でより重要）。
3. [SUBJECT] はバイト単位で完全に同一に保つ。
4. グローバルなネガティブ項目は保持し、もはや当てはまらないイラスト固有の項目——「グラデーションなし」など——は外す。

写真結果が主体の要素を勝手に発明したり失ったりするなら、主体ブロックの記述が不十分な可能性が高いです。補償的なスタイル語を足すのではなく、そこで修正してください。

レイアウトと文字レンダリングの制御

レイアウトと文字は、開発者が最もよくモデルに推測させてしまう2つであり、まさに明示的に書く価値が最も高い2つでもあります。これらはスタイルとは別の独立したプロンプトブロックとして扱ってください。

実際に制約として機能する位置言語

曖昧：「ランディングページのバナー画像。」

明確：

[COMPOSITION] landscape 16:9 frame; subject occupies the right two-thirds;
left third is empty open space suitable for a headline; horizon line at
lower third; nothing enters the left third

位置指示を強固にする3つの習慣：

• まずフレームを名指す、次に配置を記述する（「横向き 16:9 フレーム」）。
• 予約領域を明示する、そしてその領域に何も入らないと宣言する。空白空間はデフォルト状態ではありません。
• 三分割線にアンカーする、「やや中心から外れて」のような測定不可能な言葉ではなく。

文字レンダリング

画像内に文字を入れたいときは、それを独立したブロックに分離し、正確な文字列を引用します：

[TEXT] render exactly the words "Ship faster" in a bold sans-serif,
placed in the reserved left third, vertically centered, single line,
high contrast against a plain background. No other text anywhere.

反復を減らすポイント：

• 文字列をリテラルで引用する——プロンプト内で言い換えてはいけません。
• 「正確に」と「他の文字は入れない」を明記する——さもないと隅や小道具に余計な文字が湧いてきます。
• 行数を指定する（「単一行」）。さもないと改行は推測になります。
• コントラストのある背景を指定する（「無地の背景の上」）。文字が寄りかかる先を作ります。
• 文字は [STYLE] ブロックから完全に切り離し、混ぜると両方とも調整が難しくなります。

リクエストが正確な多要素タイポグラフィを必要とするなら、文字生成を出発点として扱い、下流で本物のテキストレイヤーを計画してください。プロンプトレベルの文字制御は短い見出しやラベルに適しており、密な本文には向きません。

ネガティブリスト：何を除外するか、そしてどうバージョン化管理するか

ネガティブリストは最も安価な品質管理手段です。欲しいものを記述する代わりに、受け入れを拒む失敗パターンを指摘します。

除外する価値のあるカテゴリ

ネガティブ項目をカテゴリで整理すると、矛盾を生むことなく拡張できます：

• 文字アーティファクト——余計な文字、文字化けしたグリフ、透かし、署名。
• 構図アーティファクト——切り取られた主体、切断された四肢、重複要素、雑然とした端。
• レンダリングアーティファクト——ぼやけ、色のバンディング、過飽和、きつすぎる HDR 感、プラスチックのような肌。
• コンテンツ衛生——ブランドロゴ、識別可能な商標、実在人物の肖像。
• スタイルの漂流——イラストレシピに写真写実性が出現、写真レシピにイラスト感が出現。

最後のカテゴリこそチームが最も忘れがちなものです。イラストレシピが写実へ漂流し続けるなら、明示的なネガティブ項目のほうがスタイル形容詞の積み重ねより信頼できることがよくあります。

短く、矛盾なく保つ

長すぎるネガティブリストは逆効果です。ネガティブ項目がポジティブ指示と衝突すると、結果は不安定になり、どの句が勝ったのか判断できません。2つのルール：

1. 要求したものを否定してはいけない。 構図ブロックが奥行きのために影を要求しているなら、グローバルに「影なし」を並べてはいけません。
2. 具体的なものが一般的なものに優先する。 「透かしなし」は実行可能です。「悪いものを入れない」はノイズです。

ネガティブリストをプロンプトとともにバージョン化する

ネガティブ項目はそれを参照するすべてのレシピの挙動を変えるため、プロンプトと同等の追跡可能性が必要です：

{
  "negative_list_id": "global-v2",
  "entries": ["watermark", "signature", "stray text", "cropped subject", "duplicated elements", "oversaturated colors"]
}

各レシピから ID でこのリストを参照し、編集時に ID をインクリメントしてください。デプロイ後に出力品質がずれたとき、「ネガティブリストは変わったか？」が調査ではなく diff の1行チェックになります。

リリース前に実際の出力と比較する

実際の出力を見るまで、レシピは仮説にすぎません。以下の比較フローは意図的に軽量に保っています——数分で済むべきで、スプリントを要するべきではありません。

フロー

1. 1つの変数以外をすべて凍結する。 同じ主体ブロック、同じ構図、同じネガティブ項目、API がシードを公開するなら同じシード。変えるのはスタイルブロックだけ。
2. 小さなマトリックスを生成する。 2〜3のスタイルバリアントと2〜3の代表的な主体の組み合わせで、たいてい悪いレシピを露呈させるのに十分です。
3. 並列でレビューする、順番ではなく。順番レビューは直近性バイアスを招きます——最後の画像が一番新しいから一番良く見えるのです。
4. 好みではなく要件に照らして評価する。 その素材が何のために使われるか（ヒーローバナー、アイコンセット、エディトリアルヘッダー）を書き、本当に重要な具体的属性をチェックする：予約空間は本当に空か、余計な文字はないか、スタイルの漂流はないか。
5. 意識的に昇格させる。 レビューを通過したレシピリビジョンだけが製品コードに入り、そのバージョンタグが付与されます。

注目すべきこと

• 主体間の一貫性。 ある主体では効くが別の主体では崩れるスタイルブロックはまだ準備できていません。
• 制約の遵守度。 予約された左三分の一は空のままか？ 引用した正確な文字列は一度だけ出現するか？
• 失敗の集積。 同じアーティファクトが複数のバリアントに現れるなら、スタイルの微調整ではなくネガティブリストに入れるべきです。

すべてをリポジトリに保存する

レシピ JSON、ネガティブリストのバージョン、レビュー記録を一緒に保管してください。半年後に誰かがなぜヒーロー画像がこうなっているのかと尋ねたら、答えは1つのコミットであり、記憶ではありません。

レシピがこのサイクルを通過すれば、所与の主体についてイラストと写真を切り替えるのは単一フィールドの編集になります——これこそ骨格が提供するために設計された保守特性です。統一 API を通じて Recraft v4.1 テキストtoイメージでこれらのレシピを実行し、すべてのプロンプト改訂をそれを呼び出すコードとともにバージョン化してください。