開発者向け Muse-Image-1.0 画像間変換プロンプトレシピ

画像間変換プロンプトとテキスト間変換プロンプトの違い

テキスト間変換プロンプトはシーン全体を記述します。被写体、光、スタイル、構図、背景です。モデルはノイズから出発し、すべてを構築します。画像間変換は異なります。すでに元画像があり、プロンプトはそれに対する差分です。画像に何を含めるべきかをゼロから記述するのではなく、何を変更し、何を維持するかを記述します。

この区別は重要です。なぜなら、編集プロンプト内でシーン全体を記述すると、モデルが画面全体を再レンダリングするよう誘導されるからです。被写体を詳細に記述すれば、モデルはそれを保持するのではなく描き直すかもしれません。背景を記述すれば、背景を再構築するかもしれません。結果はもっともらしいが異なる画像になりがちです。同じ概念、異なる実例です。

心に留めるべきメンタルモデルはこれです。テキスト間変換プロンプトは仕様書であり、画像間変換プロンプトは差分パッチです。元画像がベース文書であり、プロンプトはパッチです。パッチは小さく、明確で、範囲を限定すべきです。パッチが広すぎると、モデルはそれを至る所に適用し、保持したかった元画像の部分を失います。

実際には、編集プロンプトは既存の画像への参照（「被写体」「既存の背景」「現在の構図」）に依拠し、それらを再記述しないようにするべきです。何が存在するかではなく、何が動くかを述べてください。以降の章では、これを再利用可能な骨組みと具体的なレシピに落とし込みます。

もう一つの帰結として、元画像が非常に多くの情報を担うため、同じプロンプトでも異なる入力で挙動が変わり得ます。商品画像で効いたレシピがポートレートで失敗するかもしれません。だからこそ、ここでのレシピは魔法の文字列ではなく適応可能なパターンとして書かれています。

レシピの形式：変更を一つ、維持を一つ、制約を一つ

本ガイドのすべての編集プロンプトは同じ三部構成の骨組みに従います。意図的に退屈に見えますが、そこが要点です。固定構造によってプロンプトは比較可能で、レビュー可能で、テンプレート化可能になります。

骨組み

1. 変更——修正を記述する明示的な指示。動詞で始めます：change、replace、add、remove、shift、recolor。
2. 維持——固定を保つべきものを明示的に列挙したチェックリスト：被写体の同一性、姿勢、構図、背景、照明、テクスチャ。
3. 制約——境界条件：スタイルの一貫性、アスペクト比、新しい物体を追加しない、要求されない限り文字を入れない。

最小のプロンプトは次のようになります：

変更：背景を無地の淡いグレーのスタジオ背景に置き換える。
維持：被写体の顔、髪、服装、姿勢、構図。
制約：元の照明方向と影の柔らかさを保つ。小道具を追加しない。文字を入れない。

一文ではなく三部にする理由

三部への分割には二つの効果があります。第一に、変更行と維持行は別個のシグナルです。モデルが明示的な「維持」指示を編集文と絡めずに受け取ると、しばしばよりよく従います。第二に、分割によってデバッグが可能になります。出力が誤っている場合、変更が誤って適用されたのか（変更行が曖昧すぎる）、元画像が過度に編集されたのか（維持行が欠けているか短すぎる）を判断できます。

プロンプトごとに変更は一つだけ

複合編集には抵抗してください。「背景を置き換え、帽子を追加し、夕方の照明にする」は一枚の外衣をまとった三つのレシピです。代わりに順番に実行してください。各ステップにはきれいな差分があり、中間結果を確認できます。順次編集は各段階で維持行を簡潔に保つことにも役立ちます。

制約行は品質ゲートです。出力を却下する原因になるもの——誤ったアスペクト比、追加された文字、ずれた色温度——を制約に入れてください。過度に制約されたプロンプトを削除する方が、仕様不足のプロンプトを追いかけるより簡単です。

そのままコピー&ペーストできる編集レシピ

以下の各レシピは変更 / 維持 / 制約の骨組みに従います。括弧部分はあなたの被写体に合わせて調整してください。前後のフレームをチェックリストとして扱ってください：何が明確に異なるべきか、何がまったく同じであるべきか。

1. 背景の置き換え

前：賑やかな街路上の被写体。後：同じ被写体、きれいな背景。

変更：背景を継ぎ目のない[色]のスタジオ背景に置き換える。
維持：被写体の顔、髪、服装、姿勢、身体の構図。現在のトリミングを保つ。
制約：被写体上の元の照明方向に合わせる。背景に新しい影を加えない。文字やロゴを入れない。

2. 商品の色変更

前：ある配色の商品。後：同じ商品、異なる色。

変更：[商品の部位]を[目標の色]に着色し直し、素材の表面処理を保つ。
維持：商品の形状、継ぎ目、ラベル、反射、および既存の構図。
制約：背景や周囲の表面上の反射を着色し直さない。文字を変更しない。

3. 照明と時間帯のシフト

前：正午の平坦な光。後：暖かな夕方の光。

変更：照明を暖かな低角度の夕方の光にシフトする。
維持：被写体の同一性、姿勢、服装、およびシーン配置。
制約：影を単一の低角度光源と一致させる。物体を追加または削除しない。文字を入れない。

4. 物体の除去

前：邪魔な要素のあるシーン。後：同じシーン、要素が消えている。

変更：[位置]から[物体]を除去し、その領域を周囲の表面で埋める。
維持：画面内の他のすべてを元のまま保つ。構図と照明を含む。
制約：物体があった場所にぼけや塗りむらなどのアーティファクトを生じさせない。代替の物体を追加しない。文字を入れない。

5. 被写体のスタイル変換

前：被写体の写真。後：同じ被写体のイラスト化処理。

変更：この画像を[スタイル]のイラストスタイルでレンダリングする。
維持：被写体の顔の特徴、姿勢、服装の細部、および構図。
制約：被写体を識別可能に保つ。要素を追加しない。文字や署名のマークを入れない。

6. トリミングと再構図

前：広角ショット。後：よりタイトな構図、同じ被写体。

変更：被写体を中央に寄せたより近い[ポートレート/正方形]のクロップに再構図する。
維持：被写体の外観、表情、照明、および新しいクロップ内の背景の文脈。
制約：元のフレームの外に細部を捏造しない。文字を入れない。

レシピは一度に一つずつ実行し、確認してから次のステップを連結してください。あるレシピがうまくいかない場合、修正は通常、変更行に形容詞を積み重ねることではなく、維持行または制約行にあります。

被写体の細部を完全に保つ表現

アイデンティティのドリフトは画像間変換で最もよくある不満です。モデルは要求された編集を完了しますが、静かに顔を描き直したり、生地を変えたり、姿勢をずらしたりします。ここでの主なレバーは表現であり、繰り返しよりも効果的です。

固定すべきものを名指しする

抽象的な維持指示（「同じに保つ」）は弱いです。具体的なものは強いです。比較してみましょう：

• 弱い：「被写体を変えないでください。」
• 強い：「被写体の顔、生え際、目の色、衣服のしわ、手の位置を保ってください。」

強い版が機能するのは、確認可能な属性を列挙しているからです。モデルは曖昧な「ものを変えるな」ではなく、具体的なアンカーを持てます。

画像を参照し、再記述しない

被写体を再記述することは最もよくある自滅的な誤りです。「茶色の髪で青いシャツを着た女性」と書くと、モデルは茶色の髪で青いシャツを着たある女性を生成するかもしれません——元画像のその女性ではなく。指示的な参照を優先してください：「被写体」「既存の背景」「現在の構図」。再記述が役立つのは、その属性を変えたいときだけです。

編集範囲を空間的に限定する

可能であれば、テキストで編集領域を区切ってください：「背景のみ」「画面の下三分の一」「商品ラベル」。空間的な限定は付随的な編集を減らします。パイプラインがマスクをサポートするなら、空間的な言語とマスクを組み合わせてください——テキストとマスクは互いを強化します。

絶対級ではなく比較級を使う

「より暖かく」「少しタイトに」「彩度を低く」は、「暖かいオレンジ」「極端なクローズアップ」「高彩度」よりも元の内容を多く保ちます。絶対級はモデルを記述された典型版へ引き寄せ、比較級は元画像に固定します。

維持リストは短く、しかし重要なものに

三から六個の属性で通常は十分です。二十項目の維持リストは注意を希釈し、ゼロ項目のリストはドリフトを招きます。出力を却下する原因になる属性を選び、残りは空けておいてください。

実用的な習慣：維持行を先に書き、変更行を後に書いてください。何が動くかを決める前に何が最も重要かを決めると、しばしばより簡潔なプロンプトになります。

よくある失敗事例に対するネガティブプロンプト

ほとんどの悪い生成は少数の再現可能な失敗カテゴリに集中しています。小さく再利用可能なネガティブプロンプトのセットで、編集を過度に制約することなくそれらをカバーできます。パイプラインの受け渡し方法に応じて、ネガティブ語を制約行に加えるか、別のネガティブフィールドとして渡してください。

失敗：顔のアイデンティティのドリフト

症状：顔の形、目、年齢がずれる。表情が意図せず変わる。

Negative: altered facial features, changed eye color, different person, age change, expression change

失敗：背景の過剰編集

症状：被写体のみを編集したのに、背景の物体が動く、壁の色が変わる、影がずれる。

Negative: changed background, moved objects, altered wall color, new shadows, shifted horizon

失敗：テクスチャとマテリアルの喪失

症状：生地がプラスチックのように見える、肌がエアブラシのように見える、金属が反射を失う。

Negative: plastic texture, airbrushed skin, lost fabric weave, flattened reflections, oversmoothing

失敗：望まない追加

症状：小道具が現れる、文字やウォーターマークが現れる、余分な手足や物体。

Negative: added props, extra objects, text, watermark, logo, signature, extra limbs

失敗：スタイルの浸食

症状：局所編集が新しいスタイルで画像全体を描き直す、またはスタイル編集が被写体のアイデンティティに染み出す。

Negative: global restyle, changed lighting on subject, painterly bleed, uniform filter

失敗：アーティファクトの継ぎ目

症状：物体を除去した場所にぼけや塗りむら。編集境界に硬いエッジ。

Negative: blur artifacts, smudge, visible seam, halo, patch mismatch

編集を壊さずに使う方法

実際に観察した失敗に一致するネガティブ行から始めてください。六つすべてを一度に加えると、しばしば出力を平坦化し、要求した変更と衝突する可能性があります。ネガティブ語は短く具体的にしてください。「bad quality」系の用語の長いリストは的を絞った編集にはほとんど役立ちません。あるネガティブ行がある状況を修復するが別の状況を壊す場合、それをグローバルテンプレートではなくそのレシピに限定してください。

レシピをパラメータ化されたテンプレートに変換する

コピー&ペーストのプロンプトは出発点にすぎません。製品でスケールできるのは、名前付きスロット、バージョンタグ、責任者を備えたテンプレートです。目標は、どのエンジニアでも同じレシピを呼び出して比較可能な挙動を得られることです。

スロットを抽出する

レシピを見て、リクエストごとに変わる部分をプレースホルダーに置き換えてください：

変更：背景を継ぎ目のない {backdrop_color} のスタジオ背景に置き換える。
維持：被写体の {identity_attributes}。現在のトリミングを保つ。
制約：被写体上の元の照明方向に合わせる。背景に新しい影を加えない。文字やロゴを入れない。
Negative: {failure_negatives}

典型的なスロット：被写体カテゴリ、編集対象、目標値、維持属性リスト、制約フラグ、ネガティブセット。スロット名をレシピ間で安定させ、同じ呼び出し側コードがレシピを切り替えられるようにしてください。

レシピをバージョン管理して登録する

プロンプトをスキーマのように扱ってください。各テンプレートに id とバージョン（background_replace@2）を付け、何がなぜ変わったかを記録してください。モデルやレシピの変更後に出力品質が変わったとき、どのバージョンが与えられた資産を生み出したかを知る必要があります。レンダリング後のプロンプトを、テンプレート参照だけでなく出力と一緒に保存してください。

連結ではなく合成する

自由テキストの文字列連結ではなく、ブロックからプロンプトを構築してください——変更ブロック、維持ブロック、制約ブロック、ネガティブブロック。ブロックは維持行の欠落を lint 可能にし、失敗カテゴリごとにネガティブセットを差し替え可能にします。小さな維持ブロックライブラリ（ポートレート、商品、シーン）とネガティブブロックライブラリ（アイデンティティ、テクスチャ、追加）を維持してください。

テンプレート層のガードレール

送信前にスロットを検証してください：未知の色、空の維持リスト、複数の変更を組み合わせた編集を拒否します。API 境界で呼び出しごとに一つの変更を強制してください。これらのチェックは低コストで、ほとんどの悪いプロンプトがモデルに届く前に捕捉します。

例を添えて共有する

各テンプレートには二～三のサンプル元画像と期待される結果を添え、新しいチームメンバーが誰かに尋ねずに変更の基本チェックを行えるようにしてください。テンプレートと例のセットが再利用の単位です。

自分の画像でレシピを評価する

一つのサンプルで良く見えるレシピはほとんど何も証明しません。プロンプトが製品に入る前に、実際の入力を反映した固定評価セットでその地位を勝ち取るべきです。

小さな固定テストセットを構築する

十から三十枚の元画像で通常は十分に始められます。実際に見られる変種をカバーしてください：被写体タイプ、照明条件、背景、アスペクト比、エッジケース。セットを凍結し、プロンプトバージョン間で再利用して比較を意味あるものにしてください。セットが見落としていた失敗カテゴリを見つけたら新しい画像を追加しますが、セットもバージョン管理してください。

レシピごとに合格基準を定義する

各レシピについて、合格とは何かを書き留めてください。背景の置き換えなら：被写体のアイデンティティが保たれ、ハローがなく、照明方向が一致し、背景にアーティファクトがない。色変更なら：目標の色が正しく、ラベルが完全で、反射が妥当である。基準は「感覚」の記述ではなく、人間のレビュアーが数秒で確認できるものであるべきです。

絶対ではなく変種を比較する

同じセットでプロンプト変種を並行実行し、合格率を比較してください。変更行の調整、短縮した維持リスト、追加したネガティブ語——それぞれが候補変種です。簡単な記録を保ってください：変種 id、合格数、顕著な失敗。これによってプロンプト調整は逸話から小さな実験ログになります。

レシピの失敗と入力の失敗を区別する

一部の失敗は元画像に関係します：低解像度、重度の遮蔽、被写体のぼけ。これらは別に記録してください。レシピは悪い入力を修復できないからといって壊れてはいませんが、パイプラインには入力品質ゲートが必要かもしれません。

レシピ間の回帰に注意する

共有ブロック——維持リスト、ネガティブセット——は一方のレシピを改善しつつ、他方を静かに損なう可能性があります。共有ブロックを変更するときは、調整中のレシピだけでなくセット全体を再実行してください。これがテンプレートをモジュール化し続ける主な理由です。

監視付きでデプロイする

レシピがデプロイされた後、本番で出力をサンプリングし、明らかな失敗を評価セットに戻してください。このループ——観察、セットへ追加、変種のテスト、昇格——が、入力とモデルの変化に伴ってプロンプト品質が劣化するのを防ぐ鍵です。

三部構成の骨組みから始め、小さな評価セットを構築し、ここでのレシピを最終回答ではなく、バージョン管理して適応させる出発点としてください。