使用ガイド
Recraft v4 Styles Pro テキスト-to-画像プロンプトレシピ集、コピー＆ペーストですぐ使える
なぜプロンプトレシピが一発プロンプトに勝るのか
ほとんどの人はプロンプトを走り書きのように書く。速さ優先、即興、再現不能。適当に文章を打ち込んでそこそこの画像が出たとしても、二日後にそれと揃う素材が必要になったとき、当時何を書いたかまったく思い出せない。結果として、一つのフォルダの画像が別々のプロジェクトから来たように見えてしまう。
レシピはこの問題を解決する。変わらない部分と変わる部分を分離するからだ。毎回文章を組み立て直すのではなく、安定した骨格を保ち、いくつかのスロットだけを差し替える。これには三つの実利的な利点がある：
- 再現性。 再実行できるレシピこそ、チューニングできるレシピだ。ある効果がうまくいったなら、どの語が効いたのかを正確に把握できる。
- セットとしての一貫性。 ブログのアイキャッチ、アプリ内の空状態ページ、ランディングページのイラストが同じ骨格を共有していれば、他人行儀ではなく家族のように見える。
- より速いイテレーション。 一つのスロットをデバッグするのは数分で済む。自由奔放な文章全体をデバッグするのは当て推量でしかない。
一発プロンプトは一度書いたら捨てる文だ。レシピは継続的にメンテナンスする小さな資産だ。本ガイドのすべての例は同じ構造に従っているので、中の具体的な内容が不要でも、このフレームワークはそのまま使える。
始める前に実用的な注意を一つ：レシピは出発点であり、保証ではない。モデルはあなたの文章をガイダンスとして解釈し、同じレシピを別のテーマに使ったり、スタイル参照を組み合わせたりすると、期待と違う結果になることがある。最初の生成は最終判決ではなく、一つの計測と捉えよう。
再利用可能なプロンプトの解剖
ほぼすべての繰り返し使えるプロンプトには四つの層があり、おおよそこの順序で書かれる。各層は可能な画像の空間を狭め、後続の層は前の層を洗練させるべきであり、矛盾してはならない。
1. 主体
画面に何があり、それが何をしているか。数量、状態、関係を具体的に書く。
a lone hiker resting on a granite ledge, backpack beside them
2. スタイルのヒント
どう見えるべきか：媒体、レンダリング方式、配色、ディテールの程度。イラストか写真かはここで決まる——後述の専用セクションでこの選択を分解する。
flat vector illustration, limited palette, no gradients
3. 構図
何がどこに置かれ、画面がどう組織されるか。クロップ、余白、フォーカス位置、そして実際の用途で必要なあらゆるレイアウト制約。
subject centered, generous empty space on the left for headline text, vertical 4:5 framing
4. 出力意図
この画像が何のためにあるか。これは多くの人が飛ばす層だが、まさにこれが多くの問題を静かに解決する。
clean marketing asset, crisp edges, no busy background texture
有用な習慣：これら四つの層を、流暢な一つの長文ではなく、四つの独立した短文として書くこと。こうすると意図がより明確になる——編集時に自分が理解でき、モデルも理解できる。
以下はスロットを明示した組み立て済みの骨格で、どんな内容にも当てはめられる：
[subject], [style cue], [composition], [output intent]
本記事の残りすべては、これらのスロットのどれかに内容を埋めていくだけだ。
スタイル参照の扱い
スタイル参照はプロンプト内の役割分担を変える。スタイル参照を提供すると、モデルは見た目についてすでに強いシグナルを持っているので、その見た目を文章で再記述するのは無駄だ——さらに悪いことに、参照と衝突して混乱した結果を生むことがある。
実用的な役割分担はこうだ：
- 参照に任せる： 配色、質感、線の品質、レンダリングの完成度、全体的なビジュアルムード。
- プロンプトに残す： 画像に何が含まれるか、どうレイアウトするか、何のために使うか。参照はどう見えるかを表現し、文章は何であるかを表現する。
スタイル参照を付けた簡潔なプロンプトはこんな感じだ：
a delivery cyclist locking a bike at a curb, subject on the right third, open sky upper left, horizontal banner crop, clean background
参照なしのバージョンと比べてみよう——後者はほぼ同じ見た目に落とし込むために、明示的なスタイル条項が必要になる。これがトレードオフだ：参照を使えばより短いプロンプトが書けるが、スタイルの漂いに対する許容度は低くなる。
参照を有効に使い続ける三つの習慣
参照と格闘しない。 スタイル条項が参照にできないことを記述していると、出力は通常、好ましくない形で妥協する。見た目は一つの支配的な権威だけを選ぶ。
参照は単発画像ではなくシリーズに使う。 統一感を感じさせる必要があるコンテンツ群——連載記事のアイキャッチ、機能アイコンのセット、多サイズのキャンペーン素材——を生成するとき、参照は最も価値を発揮する。
スタイルではなく内容をテストする。 参照を付けたら、主体と構図だけをイテレーションする。スタイルが違うと感じたら、その上に形容詞を積むのではなく、参照を替える。
本当にスタイルを微調整する必要があるとき——たとえば参照が用途に対して柔らかすぎる——は、一箇所だけ調整し、書き直すのではなく修飾語で表現する：
... crisper edges, higher contrast than the reference ...
イラストプロンプト：出力を描画感へ押しやる語
イラストプロンプトの失敗の仕方は予測可能だ。人々はシーンを写真言語で描写しながら、モデルにそれを描いてほしいと願う。選ぶ語彙こそがレバーだ。これらのヒントは結果を描画感・デザイン感へと押しやる。
形状と形態
flat shapes, geometric forms, simplified silhouettes, no realistic volume
なぜ効くのか：「Flat shapes」（フラットな形状）と「simplified silhouettes」（簡略化されたシルエット）は、画像を写実へ押しやる明暗とボリュームを取り除く。モデルは奥行きのレンダリングをやめ、形状の組織化へと移行する。
線
なぜ効くのか：線幅は描画媒体の最も明確なシグナルの一つだ。均一な線幅を指定することは、手描きの習作ではなくベクター的な構築を意味する。スケッチ感が欲しいなら、明示的にそう書く。
配色
なぜ効くのか：境界のある配色は、モデルに実シーンをサンプリングさせるのではなく、意図的な色選択を強いる。「No gradients」（グラデーションなし）はこのリストで最も強い単一の反写実ヒントだ。
レンダリング
なぜ効くのか：これらの語は一つの制作工法を指し、各工法は暗黙の制約群を含む——限られたインク、可視の形状、写真的な光の減衰の不在。工法を指すことは、その副作用を列挙するよりも通常効果的だ。
完全なイラストレシピ
これが四層の骨格で、各スロットにイラスト語彙が埋められている。主体と構図を替えても、依然として有効だ。
写真プロンプト：出力を写実感へ押しやる語
写真プロンプトを効かせるには、単にシーンを描写するのではなく、撮影を描写する必要がある。カメラは制約の集合だ——レンズがあり、光に反応し、被写界深度がある。これらの制約を指摘してこそ、精緻なデジタル絵画ではなく写真的な出力が得られる。
レンズとフレーミング
なぜ効くのか：焦点距離はパースペクティブと視野を示唆し、空間が画面内でどう圧縮されるかを変える。数語で済む、利用可能な中で最もレバレッジの高いヒントの一つだ。
光
なぜ効くのか：写実画像の成否は光の方向と品質に懸かる。「Soft」（柔）と「Hard」（硬）、そして光源の方向が、レンダリングに物理的に整合する計算基盤を与える。
被写界深度とフォーカス
なぜ効くのか：選択的フォーカスはカメラの産物であり、観察者の頭の中の虚構ではない。これはほぼ即座に写真として読まれる。
質感と不完全さ
なぜ効くのか：軽微な不完全さは、合成物のように読ませる過度な平滑さを打ち消す。軽微に保つこと——強い粒子感は写実ではなくスタイルの選択になる。
完全な写真レシピ
何が欠けているかに注目：スタイル参照も、雰囲気や感情に関する形容詞もない。光、レンズ、被写界深度のヒントが写実感を担い、出力意図条項がその実用性を保証する。
コピー＆ペーストですぐ使えるレシピ
以下の各レシピはそのまま使える。コメントが何を替え、何を残すべきかを教えてくれる。
レシピ 1 — 編集アイキャッチ、イラスト
替える：主体と配色語。残す：シルエット、塗り、余白の条項——まさにこれらがアイキャッチとして使えるようにしている。
レシピ 2 — 写真的なプロダクトシーン
替える：主体と光の方向。残す：焦点距離と被写界深度の条項。
レシピ 3 — スタイル参照シリーズ
替える：主体だけ。残す：その他すべてをそのまま——このレシピはコンテンツ群に統一感を感じさせるために存在する。
レシピ 4 — 機能解説用のコンセプトイラスト
替える：主体とアクセントカラー。残す：幾何と配色の条項。
レシピ 5 — スナップ風チーム写真
替える：主体と人数。残す：「candid」（スナップ）と「spontaneous」（自然）——これらがストックフォト的な硬さを防ぐ。
このレシピセットは意図的に絞っている。五つのレシピでほとんどのプロダクトとコンテンツのニーズをカバーでき、絞られたレシピセットこそが実際にメンテナンスされるレシピセットだ。
一から作り直さないイテレーション
最もよくあるイテレーションの誤りは、結果に不満があるとプロンプト全体を書き直してしまうことだ。これでは証拠が壊れる：どの変更が効いたのかわからなくなり、以前うまくいったバージョンに戻ることもできなくなる。
一度に一つの変数だけを、この順序で変える：
- まず主体を変える。 内容が間違っていれば、他はどうでもいい。まず画面の中身を直し、それから見た目に手を付ける。
- 次に構図を変える。 内容が正しくなったら、レイアウトに合わせて位置、クロップ、余白を調整する。
- 最後にスタイルを変える。 内容と構図が固まってから、スタイルのヒントを調整する。スタイル修正は最も誘惑されるが、初期段階では最も重要でない。
画像を生成するときのクイックチェックリスト：
- 主体の数量と状態は正しいか？ 正しくなければ、主体条項が曖昧すぎる。
- レイアウトが必要とする場所に使える空間はあるか？ なければ、構図条項の記述が具体的でない。
- 媒体は意図した通りに読めるか——描画か写真か？ 曖昧なら、前述の関連セクションで最も強いヒントを落としている。
- 頼んでいないものが画面にあるか？ 新しい形容詞を十個足すのではなく、明確な除外項目を一つ追加する。
変更を加えるときは、既存条項の内部を編集するのではなく、独立した条項として末尾に追加する。こうすると差分が読みやすく、ある変更が裏目に出たときにそれを単独で削除できる。
条項を一つ足し、一度テストする。メソッドはこれだけだ。
自分だけのレシピライブラリを作る
レシピライブラリにツールは要らない。フォーマットが統一された共有ドキュメントで十分だ——全員が使うことが前提だが。
使い続けられるフォーマット
各レシピにはこれらを保存する：
- 名前 — 記述的で安定したもの。例：
final-v3ではなくheader-illustration-flat。 - プロンプト — 全文、スロットは角括弧で示す。
- 何を替えるか — 明確に列挙した変数。
- 何を動かさないか — 構造的な役割を担う条項。
- 参考出力 — 良い結果がどんなものかの説明。新人が自分で判断できるように。
ライブラリを活かし続ける習慣
一行に一レシピ、例外なし。 誰かが多段式の実験をドキュメントに貼り付けたら、もう誰も見なくなる。
昇格させ、積み上げない。 一発プロンプトが二度成功したら、レシピに昇格させる。さもないとライブラリは誰も信頼しない草稿で溢れる。
バージョンはサフィックスで、書き直しではなく。 元のレシピは残し、バリアントには -alt を付ける。こうすれば検証済みのバージョンが消えることはない。
定期的に見直す。 四半期に一度も使われなかったレシピは、間違っているか余剰だ——削除する。みんなが信頼する十個のレシピライブラリは、誰も見ない四十個のレシピライブラリに勝る。
上の五つのレシピから始め、チームの呼び方でリネームし、また同じプロンプトを打ち直していることに気づくたびに一つ追加する。数プロジェクトを経れば、レシピライブラリは後から思い出すものではなく、デフォルトの出発点になる。
目標は完璧なプロンプトではない。人をまたぎ、プロジェクトをまたぎ、月をまたいで、あなたの出力が意図的に見えるようにする、小さく共有された語彙のセットなのだ。
