Flux-1 Kontext Max プロンプトレシピ：コピー＆ペーストでそのまま使える編集プロンプト

Kontext Max プロンプトレシピの本質

プロンプトレシピは説明的な文章ではない——モデルに対して何を変え、何を保つかを正確に伝える、コンパクトな指示フォーマットである。Flux-1 Kontext Max において、我々が使う信頼できるレシピはすべて同じ4段階構造に従っている：

• 動詞——操作の種類：置換、削除、再着色、追加、拡張、スタイル変換。
• 対象——動詞が作用する領域やオブジェクト。明確に名指しする必要がある（「左側の人物が着ている赤いジャケット」）。
• 期待する変化——プロセスではなく最終状態（「色を変える」ではなく「紺色にする」）。
• 保持条項——完全に一致させなければならない内容（「同じ布のシワ、光、背景を保つ」）。

したがって、レシピは次のように読める：replace the jacket on the person at left with a navy wool coat; keep pose, lighting, and background unchanged。

重要なメンタルモデル：Kontext Max はエディタであり、ジェネレータではない。入力画像から出発し、差分（diff）を適用する。この差分が小さく、境界が精密であるほど、結果は予測可能になる。画像生成の説明のように読めるプロンプト（「夜の街にいる女性のムードあるポートレート」）は、モデルにすべてを再生成する自由を与えてしまい、実際にそれが起きる。

保持条項は多くの人が飛ばす部分であり、最も効果を発揮する部分でもある。これがないと、モデルは画像の残りの部分を自由に変更可能なものとみなす。これがあれば、自然言語でマスクを描いているのと同じになる——手動でマスクを構築する必要が一切ない点が便利である。

結果の方向性を変える指示の言い回しルール

これらはプロンプトレベルで制御できるレバーである。どれも出力を予測可能な方向へ確実に導く。

記述文ではなく命令文を使う

「そこにあるべきでないゴミ箱がある」ではなく「右下のゴミ箱を削除する」と書く。命令形は編集操作に直接対応する。記述的な口調は場面説明のように読まれ、再生成を招く。

画像全体ではなく対象を名指しする

「画像内のテキスト」より「ドアの上の看板」の方が優れている。画像に看板が3つあるなら、どれかを特定する（「左側の出入り口の上に吊り下げられた木製の看板」）。空間的なアンカー——左、右、上、前景、被写体の後ろ——はコストがほとんどかからないのに、曖昧さの大部分を排除できる。

1つの指示につき編集は1回だけ

2箇所の変更が必要な場合、それらが同じ領域に作用するときだけセミコロンで連結する：remove the chair; keep the floorboards and shadows beneath it。無関係な編集は別々の呼び出しに分けるべきである。無関係な変更を1つのプロンプトに積み重ねることは、意図しない箇所への影響を引き起こす最も一般的な原因である。

順序：制約をスタイルより先に

保持と範囲の制約は、任意の形容詞より前に置く。Keep the background, wardrobe, and expression unchanged; restyle the lighting to soft window light は機能する。一方 Restyle to soft cinematic lighting, keep background unchanged では、映画的な処理が画面全体に漏れ出す。モデルは最後に読んだ内容を支配的な参照枠とみなすので、動かせない内容で締めくくるべきである。

手順ではなく最終状態を述べる

「空を曇らせ、平坦な灰色の雲で満たす」は目標である。「彩度を下げ、雲を追加し、コントラストを下げる」はワークフローであり、モデルは文字通りには実行せず、過剰に適用する可能性がある。見たい結果を描写する。

肯定的な目標がある場合は否定を使わない

「ウォーターマークを削除する」は削除が操作そのものなので問題ない。しかし「ぼかさないで」は「被写体をシャープに、ピントの合った状態に保つ」より弱い。可能な限り制約は肯定的な不変条件として表現する。

短く保つ

2文を超えるレシピは指示を希釈する。プロンプトに段落全体が必要なら、おそらく編集が2箇所あるか、対象の特定が不十分である。

よくある編集のコピー＆ペースト用レシピ

以下の各レシピはそのまま貼り付けられる。角括弧の部分を自分の状況に置き換える。推論の説明は、なぜこの言い回しで構成するのかを説明する——テキストだけでなくパターンを学び取るためである。

オブジェクトの置換

replace the [object] at [spatial anchor] with [new object]; keep the surrounding [key surface, e.g. table/floor] and lighting unchanged 推論：アンカーと保持条項が合成を自然に見せる。周囲の表面を名指しすることで、モデルがコンテキストを再レンダリングするのを防ぐ。

オブジェクトの削除

remove the [object] at [spatial anchor]; reconstruct the background behind it to match the surrounding [surface] and fill the shadow naturally 推論：削除には、その位置に何が入るかを示す必要がある。「背景を再構築」がないと、しばしば汚れや不整合なパッチが得られる。

背景の置換

replace the background with [new setting]; keep the subject's silhouette, edge detail, and lighting direction identical 推論：エッジのディテールと光の方向が、背景置換で失敗するポイントである。それらを明示することで保持できる。

看板テキストの編集

change the text on the [sign/label] to read "[new text]"; keep the font weight, perspective, and material of the sign unchanged 推論：短く曖昧さのない対象に、フォントのパースペクティブ固定を加える。新しいテキストは短く保つ——長い文字列こそアーティファクトが発生する場所である。

色と質感の変更

recolor the [object] to [color]; preserve the original texture, folds, and highlight placement 推論：「change the color to」ではなく「recolor」を使うと指示がよりコンパクトになり、テクスチャ条項が単色塗りつぶしを防ぐ。

アウトペイント / 拡張

extend the image to the [left/right/top] by roughly [fraction, e.g. one third]; continue the existing [surface, e.g. wall/ground] seamlessly and match the current lighting 推論：継続すべき表面と合わせるべき光を名指しすることが、きれいな拡張と目に見える継ぎ目を分ける鍵である。

ポーズや表情の微調整

adjust the subject's expression to a slight smile; keep head angle, hair, and the rest of the face unchanged 推論：「顔の残りの部分は不変」がガードレールとなる。隣接する特徴を囲い込まないと、顔の編集はドリフトする。

範囲制限付きのスタイル変換

apply a [style, e.g. watercolor] treatment to the foreground subject only; leave the background photographic and unchanged 推論：スタイル変換プロンプトは過剰適用の最大の発生源である。スタイルに範囲制限を課すことは任意ではなく必須である。

レシピをコードに組み込む

レシピは文字列である——コードベースでは文字列として扱い、パラメータとバージョンを付与する。

連結ではなくパラメータ化

レシピを名前付きスロット付きで保存し、呼び出し時に埋める：

RECIPES = {
    "object_replace": "replace the {object} at {anchor} with {replacement}; "
                      "keep the surrounding {surface} and lighting unchanged",
    "object_remove": "remove the {object} at {anchor}; reconstruct the background "
                     "behind it to match the surrounding {surface} and fill the shadow naturally",
}

def build(recipe_key, **slots):
    return RECIPES[recipe_key].format(**slots)

これにより言い回しが数千枚の画像に対して安定する。あるレシピの調整が必要なら、数百の呼び出し箇所ではなく1つの文字列を変えるだけで済む。

比較のたびに入力画像を固定する

レシピを調整するときは、ベースライン画像を再利用する。プロンプトと入力画像を同時に変えると、差異をどちらかに帰属できなくなる。

呼び出し前にスロットを検証する

空のアンカーは誤ったアンカーより悪い——編集範囲を静かに広げてしまう。すべてのスロットが埋まっていること、自由テキストのスロット（新しい看板テキストなど）が短いことをアサートする。

1リクエストにつき編集は1回

Kontext Max の編集は呼び出しごとに行われるため、パイプラインは巨大な1つのプロンプトではなく、各ステップが独自のレシピとパラメータを持つ一連の編集ステップとしてモデル化すべきである。レシピを順番に適用する小さなステップランナーの方が、雑多な単一指示よりデバッグしやすい。

レンダリング後のプロンプトを記録する

スロットを埋めた後のプロンプトを、出力参照とレシピバージョンとともに記録する。出力品質が変化したとき、言い回しが変わったのかモデルの挙動が変わったのかを知る必要がある。

編集結果が意図と違う場合の対処

ほとんどの失敗は3つのカテゴリに分類できる。まず症状を診断し、次に対応する修正を適用する。

症状：対象が完全に外れている

編集が別の場所で起こる、または目に見える変化がない。

• アンカーを広げて鋭くする：「ドアの上の看板」→「左側の出入り口の上に吊り下げられた木製の看板」。
• 対象が小さい場合は明示する：「右下の小さなラベル」。
• モデルが類似のオブジェクトを変えた場合は、曖昧さを解消する語を追加する：「2つの看板のうち左側のもの」。

症状：過剰編集

1箇所だけ要求したのに、モデルが3箇所変えてしまった。

• 保持条項を追加または強化する：保持すべき正確な要素を名指しする（「ポーズ、服装、背景を不変に保つ」）。
• 制約を変更指示の後ろに移動する、または末尾で繰り返す——位置が重要である。
• 積み重ねたプロンプトを個別の呼び出しに分割する。

症状：ドリフト

アイデアは正しいが、周囲の画像がずれた——色、光、ディテールが移動した。

• 曖昧な保持要求を具体的な不変条件に変える：「同じまま保つ」ではなく「元のホワイトバランス、影の方向、布のテクスチャを保つ」と書く。
• スタイル形容詞が外に染み出していないか確認する。それらに範囲制限を課す（「前景のみ」）。
• 指示を最小形式に縮小し、ベースライン画像で再テストする。

ループ

レシピを実行 → 失敗を対象外れ、過剰編集、ドリフトに分類 → 対応する単一の修正を適用 → 同じベースライン入力で再実行。各反復では1つの変数だけを変える。2つ同時に変えると、どちらが効いたのか分からなくなる。

簡単な失敗ログを維持する：レシピバージョン、埋めた後のプロンプト、症状、修正、結論。いくつかのプロジェクトを経ると、このログはどんな単一のプロンプトよりも価値を持つようになる。

自分自身のレシピライブラリを構築する

Kontext Max から安定した結果を得ているチームは、より良い使い捨てプロンプトを書いているのではない——検証済みでバージョン管理された小さなプロンプト群を維持している。

レシピのバージョンを明示する

各レシピにキーとバージョンを与える（object_replace@v2）。言い回しを変えたらバージョンを上げ、旧バージョンを使えるまま残す。わずかな言い回しの変化が明らかに異なる出力を生むため、バージョン管理のないプロンプトライブラリはサイレントなリグレッションの温床である。

固定スイートでテストする

少数の固定入力画像と既知の期待される編集——置換1回、削除1回、背景置換1回、看板編集1回——を維持する。レシピの変更はすべてこのスイートで実行する。確認すべきは2点：対象が編集されたか、周囲の画像が不変のままか。前者は優れているが後者で失敗するレシピはまだ準備ができていない。

推測ではなくレシピを比較する

2つの言い回しがどちらも妥当に見えるときは、同じベースライン入力で両方を実行し、保持条項を守れた方を残す。比較は安価だが、編集済み画像のバッチを再撮影するのはそうではない。

レシピを自然に蓄積させる

まず上記の8つのパターンから始める。チームメイトが新しい編集ケースを解決したら、なぜその言い回しが効くのかの説明を添えて追加する。時間とともに、このライブラリはチームの暗黙的なプロンプトエンジニアリング文書となり、この API に新しく触れる人の入門資料にもなる。

削除ではなく廃止

自分の記憶のコンテキストウィンドウは短い。ある種の画像で失敗するレシピが、別の種では完璧に機能することがある。引退したレシピは、なぜ非推奨になったかの注記とともにアーカイブし、次の人が同じ轍を踏まないようにする。

プロンプトをコードとして扱う：バージョン管理し、テストし、レビューし、再利用する。この規律こそが Flux-1 Kontext Max をデモからパイプラインの信頼できる一環へと変える。