n8n で NSFW 画像編集：1 枚のキャラクター参照から新しい姿をまとめて作る

n8n で NSFW キャラクターのシリーズを一括編集するには、作りたい画像ごとに 1 ジョブを用意し、そのジョブの参照画像をまとめ、すべてのバリエーションを同じ採用済みキャラクター原本から作ります。 返されたファイルを確認用フォルダーへダウンロードし、採用した画像だけを納品用フォルダーへ移します。これで、API 要求の完了を顔が維持された証拠と見なさずに、繰り返し使える制作工程を作れます。

難しいのは、通常、6 つのプロンプトを書くことではありません。別々の 6 アイテムに正しい原本、衣装参照、部屋参照を渡し、各結果と指示の対応を保ち、一時的な結果リンクが切れた後も実際に選んだ版を見つけることです。これらを決めなければ、ワークフローが完全に動いても、違うキャラクターを納品することがあります。

ここでは、架空の 34 歳のキャラクター Mara の、夜をテーマにした 6 枚のシリーズを構築します。確立した外見を保ちながら、衣装、照明、構図を変えます。公開例には透けない服と非露骨な指示を使います。同じ仕組みを許可された成人向け制作に使えますが、n8n もこのチュートリアルも、すべての NSFW 要求が受理され、意図どおり描かれるとは約束しません。

以下は、リリース済みの SpicyAPI コミュニティノードと現在の編集スキーマに基づく構成案です。新たに 6 枚のバッチを実行した報告ではありません。ノードが自動で行うことと、制作者が決めることを分けて説明します。

採用済みのキャラクター画像 1 枚を中心にする

Mara が誰かを聞かれたときに見せたい画像から始めます。顔が分かり、維持したい髪形が見え、顔の半分を隠さない照明の、きれいな比較的近い構図を選びます。例では、肩までの暗い巻き髪、少し非対称の笑顔、チャコールのジャケットの下に濃紺の透けないキャミソールを着て、緑のソファのそばに座っています。長い架空の経歴を作らなくても、編集指示を具体的にできます。

これをキャラクターのマスター画像として保存します。後で SpicyAPI へアップロードしても、自分の保存先で使える状態を保ちます。一時的な入力 URI は制作中のファイル参照には便利ですが、永久のキャラクター保管場所ではありません。mara-master-v1 のように版を付ければ、後の髪形変更が古いシリーズの原本を知らないうちに変えることを防げます。

このバッチには、追加の画像を 2 枚用意します。衣装参照は、別の顔が混ざらないよう、ハンガーやマネキンに掛けたバーガンディーの透けないサテンドレスです。部屋参照は、真鍮のランプと緑のベルベット家具がある無人のラウンジです。モデルに、人物は第 1 画像、衣服は第 2 画像、場所は第 3 画像から取るという、別々の指示を渡します。

部屋写真に目立つ別人がいると、役割分担が曖昧になります。衣装写真に別モデルの顔があっても同様です。それしかない場合、アップロード前に必要な部分へ切り抜きます。最大の参照パックを集めるのではなく、各画像が何を提供するかの曖昧さをなくすことが目的です。

最初のカメラの指示は原本に近づけます。座った斜めのポートレートは、顔を背けた極端な俯瞰より、別の座ったポートレートを作りやすい参照です。これは実務上の提案で、測定した成功率ではありません。原本に見えない特徴を新しい角度で作らせるほど、引き継げる可視情報は少なくなります。

マスター → 衣装交換 → 新しい部屋 → 新しいポーズ → 接写という鎖にしないでください。その出力ごとに顔が解釈し直されます。第 2 段階のずれが第 3 段階の出発点になり得ます。6 行とも mara-master-v1 を指し、前の結果は指しません。小さな修正で意図的な編集の連鎖を使うことはできますが、ノードの接続による偶然ではなく、別途選ぶ方法にします。

第 1 画像は外見、第 2 画像は衣服、第 3 画像は部屋に使います。図解。

自動化を組む前に編集エンドポイントを選ぶ

キャラクターの説明をプロンプトへ貼った文生図モデルではなく、画像編集モデルを使います。n8n 標準の Edit Image ノードは切り抜き、サイズ変更、合成ができても、衣装や部屋を変える生成編集モデルではありません。例のモデル ID は alibaba/qwen-image-2.1/edit です。Qwen Image 2.1 の編集ページに、実際のタスクと調整項目が記載されています。

現在のエンドポイントは、1～10 枚の画像を含むリスト image_urls、必須の最大 5,000 文字の prompt、出力比率、解像度の段階、出力形式を受け取ります。1 要求につき画像 1 枚を返すため、6 枚作るなら生成タスクは 6 件です。参照を 3 枚渡しても、出力は 1 枚で、別々の 3 バリエーションではありません。

通常の複数参照バッチでは、resolution: 2k、aspect_ratio: 4:5、output_format: png、background: opaque を選びます。まず書いた指示を変更せず使うなら、enable_prompt_expansion を false にします。拡張を無効にできるのは 1k と 2k で、比較には便利ですが顔を固定するスイッチではありません。最初はシードを空にします。同じシードでも、同じ顔やファイルの再現は保証されません。

現在のスキーマには、strength、CFG、サンプリングのステップ数、独立したネガティブプロンプトの項目はありません。別のチュートリアルにあるからといって、見慣れた Stable Diffusion の項目を加えないでください。維持するものと除外するものはメインのプロンプトへ書きます。ローカルのサンプリング調整が必要なら、実際に対応する方式を選びます。

このエンドポイントには、別タスクとして、参照をちょうど 1 枚使う局所修正の mask_url もあります。3 枚の参照シリーズでは使いません。採用画像を選んだ後、衣服の縁を小さく直すなら、別のマスク付きジョブにできます。人物、衣服、部屋の参照をマスクと一緒に送ると、局所モードの入力要件を満たしません。

カタログでは、このエンドポイントは unrestricted と説明されています。NSFW 制作者の選択には重要でも、次のバッチの結果を保証するものではありません。既存の Qwen 編集の記事は、別の観察済み編集結果を扱います。このチュートリアルは参照ベースのバッチの制作工程を加えるもので、その観察を新たな一貫性のベンチマークへ変えるものではありません。

実際のノードを導入し、ワークフローのノードに名前を付ける

パッケージ、API キー設定、n8n Cloud 向け HTTP テンプレートは、SpicyAPI 公式 n8n ノードガイドを開いてください。その後、この制作に固有の場面と参照の設定を以下で進めます。

パッケージは @spicyapi/n8n-nodes-spicyapi、版は 0.1.1 です。セルフホストの n8n で Settings → Community Nodes → Install を開き、パッケージ名を入力して導入します。API キーのコンソールのキーで SpicyAPI (spicyapi.ai) API の認証情報を作ります。特別な理由がなければ API のベース URL は初期値を使います。

n8n Cloud が許可するのは検証済みコミュニティノードです。npm 公開だけでは検証済みを意味しません。ここではセルフホストでコミュニティノードを使います。Cloud では標準の HTTP Request で同じ API 呼び出しを実装できますが、このパッケージの選択欄や自動アップロードが現れるとは考えないでください。n8n の現在の導入ドキュメントに違いが説明されています。

SpicyAPI に「Edit Character」や「Batch NSFW」という独立操作はありません。Resource: Image → Operation: Generate を選び、編集モデルを指定します。編集を含む画像モデルのノード操作が Generate で、モデルの選択がタスクの内容を決めます。モデルの選択欄の開始価格は、その参照パックの最終見積もりではありません。

小さなワークフローを 2 つ作ります。第 1 は候補を生成して確認用フォルダーへ保存します。第 2 は採用済みの行を読み、選んだファイルを納品用フォルダーへ置きます。分ければ、確認中に実行を待機させず、6 枚を一緒に見られます。同じ画像を再生成して費用を払わず、納品の処理だけ再利用もできます。

重要なノードを Read Jobs、Ready Jobs、Loop Jobs、Prepare Edit、Edit Character、Attach Job、Save Candidate、Record Candidate と名付けます。後の式がこれらを参照するため、名前を変えるなら式も変えます。手動構築のガイドであり、このシリーズ専用の公式インポートテンプレートがあるという意味ではありません。

Manual Trigger から始めます。期待どおり動いてからスケジュールを追加できますが、最初は意図して選んだ 1 ジョブを実行します。新しいアップロードが入るフォルダーだけでは制作指示になりません。ジョブ表で、どのアップロードを組み合わせ、どんな出力を求めるかを定めます。

関連の薄いファイル群ではなく、6 行のジョブを作る

例では Google スプレッドシートの Jobs タブを使います。1 行が 1 出力です。固有の job_id、バッチ名、プロンプト、3 つの原本の場所、解像度、比率、試行番号、状態を持たせます。これで、他の画像全部を再生成せず、特定の画像だけ再試行できます。

6 つの制作指示は、シリーズとして役立つ程度に変化を付けます。

6 行とも batch_id: mara-evening-01 と attempt: 1 を使います。最初は M01 だけ ready にし、残りは draft にします。正しい行情報付きの候補が保存先まで届いてから、残りを ready にします。認証だけの独立テストではなく、実際の編集経路を小さく試す方法です。

character_uri、wardrobe_uri、room_uri を別々の列にします。新しく作ったアップロード URI か、API が取得できる公開画像 URL を入れられます。JSON 配列全体の文字列より、3 つの項目の方が表で読みやすくなります。Prepare Edit で固定順の image_urls 配列へまとめます。

制作指示を上書きせず、結果の列として task_id、candidate_file_id、candidate_name、review_status、review_note、delivery_file_id、actual_cost を加えます。1 ジョブに複数候補があるなら、別の Candidates タブへ candidate_id をキーに置き、Jobs には求めるショットを残します。最初は各行 1 候補ですが、M03 に 2 回必要になれば、この分離が役立ちます。

候補 ID は mara-evening-01-M03-a2 のようにすると、バッチ、画像、試行が一目で分かります。API のタスク ID は復旧に重要でも、どの衣装変更を頼んだかは分かりません。両方を残します。

状態は制作工程の値として、draft、ready、pending_review、approved、identity_fix、creative_fix、task_error、delivered を使います。自分の表の値で、SpicyAPI のタスク状態ではありません。画像は存在しても顔がシリーズに合わなければ、SpicyAPI は succeeded、表は identity_fix になります。

キャラクター参照を共通にしながら、各ジョブの衣装、ポーズ、構図を計画します。図解。

バイト列と URL を混同せず、参照を n8n へ渡す

n8n は、同じアイテムで通常の JSON 項目とバイナリファイルを運べます。URL 文字列は JSON に置きます。ダウンロードした写真は data や character などのバイナリ属性に置きます。バイナリ属性の名前も保存用の識別子も、公開画像 URL ではありません。

1 ジョブを手早く試すなら、保存先の n8n 連携で人物をダウンロードし、バイナリ項目 character に入れます。衣服は wardrobe、部屋は room へダウンロードし、プロンプトと同じ入力アイテムにそろえます。ダウンロードと生成の間に Edit Fields を置くなら、Include Binary Data をオンにします。オフだと JSON は残っても写真は失われます。

SpicyAPI ノードの Media Inputs に 3 エントリーを加えます。それぞれ image_urls を選び、Source: Binary File にして、Input Binary Field に character、wardrobe、room を指定します。同じリスト項目の繰り返しは意図したものです。ノードがバイナリをアップロードし、追加順に 1 つの参照配列へまとめます。

mask_url のような単一ファイルの項目へ 3 エントリーを入れないでください。プラグインは違いを確認し、複数入力が単一項目を指すとエラーを返します。メディア項目の選択欄は選んだモデルのスキーマから作られます。見慣れない項目なら、別のワークフローから名前をコピーする前にモデルを確認します。

同じ 3 原本を繰り返すなら、明示的なアップロードが管理しやすい方法です。各原本を n8n へダウンロードし、対応するバイナリ項目名で SpicyAPI → File → Upload を使います。結果には uri、fileId、fileName、mimeType、bytes が含まれます。このバッチの対応する原本列へ、返された uri を入れます。

アップロードは新しい JSON オブジェクトを返し、前のアイテムの reference_role のような項目を自動で引き継ぎません。3 アイテムをアップロードするなら、リンクされたアイテムの式で役割を保つか、明示的に再結合します。初心者向けには、人物、衣装、部屋を別名の 3 アップロードノードにすると確認しやすくなります。各 URI を表へコピーすれば、有料編集の前に役割も見えます。

アップロードした入力は一時的で、実装では 1 日保持されると説明されています。後のバッチを準備するときは、保存した原本から再アップロードします。先月表へ貼った spicy:// がまだ使えるとは考えないでください。元の Drive ファイル ID や自分の保存キーを一時 URI と並べて残し、再作成できるようにします。

Drive の共有ページ URL もよくある間違いです。API が必要とするのは画像のバイト列で、ログイン後にプレビューする HTML ページではありません。マスターを公開共有に変えず、Google Drive ノードで認証情報を使ってバイナリをダウンロードし、SpicyAPI ノードでアップロードします。制作者の原本フォルダーは非公開のままにできます。

6 行の例では、すべてに新しくアップロードした原本 URI を使います。3 つの Media Inputs を Source: URL にし、{{ $json.character_uri }}、{{ $json.wardrobe_uri }}、{{ $json.room_uri }} を指定します。この画面では URL として Spicy URI も使えます。3 枚分のバイナリをすべての表操作へ運ぶ必要がなくなります。

複数の参照を 1 アイテムの中に保つ

ここには 2 種類の「複数画像」があります。6 ジョブは 6 つの n8n アイテムです。各ジョブの 3 参照は、そのジョブ内の 3 要素の配列です。配列を 3 アイテムへ分けると意味が変わり、編集モデルが参照 1 枚ずつの独立した 3 要求を受け取る可能性があります。

この違いは実際のコミュニティの質問にも現れます。Telegram アルバムの Reddit の議論では、複数画像が別々の実行を起こし、Wait を加えても個々が遅れるだけでアルバムがまとまらなかったと報告されています。共有アルバム ID で一時保存する、収集と処理を分ける、という案があります。万能な解決を証明するものではありませんが、「少し待つ」と「1 つの参照パックに組む」の違いを示します。

この表では、編集前に 3 参照を定めるため、収集の問題を避けられます。後で複数ファイルのアップロードフォームを加えるなら、収集段階で、選ばれた全ファイルと役割を持つ 1 アイテムを作ります。各ファイルで独立して Edit Character を起動させないでください。衣服のアップロードだけが、衣服単体の再設計要求になってはいけません。

前述の Media Inputs の繰り返しを使うか、Additional Parameters (JSON) でリストを作ります。JSON 欄はオブジェクト 1 つを受け取り、最後に結合されます。そのキーは Prompt、Model Parameters、Media Inputs を上書きします。動的配列には便利でも、画面で選んだと思っていた値を隠すことがあります。

例えば、次の式は準備した行から完全な入力オブジェクトを作ります。

{{ {
  prompt: $json.edit_prompt,
  image_urls: [$json.character_uri, $json.wardrobe_uri, $json.room_uri],
  resolution: $json.resolution,
  aspect_ratio: $json.aspect_ratio,
  output_format: "png",
  background: "opaque",
  enable_prompt_expansion: false
} }}

参照配列はどちらか 1 方法にします。この JSON 式なら Media Inputs は空にし、最後の上書きで置き換わるファイルを無駄にアップロードしません。画面のリストを使うなら、Additional Parameters に image_urls を書きません。API 入力は、入れ子の配列やカンマ区切り文字列ではなく、3 要素の配列 1 つにします。

スプレッドシートからの配列列は、JSON に見えても普通の文字列かもしれません。別々の URI 列ならその不確実さを避けられます。references_json 列を使うなら、生成前に配列として解析し、失敗したらその行を止めます。"[first,second,third]" のような文字列は、画像 URL のリストではありません。

解像度と真偽値も同じです。JSON 式の false は文字列 "false" ではなく真偽値で入れます。2k は推測したピクセル寸法ではなく、有効な列挙文字列として入れます。スキーマから作るフォームが便利なのは、エンドポイントが受け付ける値を示すからです。

どの画像から何を取るかが分かる最初の編集指示を書く

Prepare Edit で、固定した参照の役割の説明と、各ショットの指示から edit_prompt を作ります。Edit Fields で文字列を組み合わせられ、単純な 6 行には Code ノードは不要です。外見の指示は固定し、行から変更内容を渡します。

M01 には、次のような指示が適しています。

第 1 画像は架空の成人キャラクター、34 歳の Mara。顔の比率、肩までの暗い巻き髪、少し非対称の笑顔、座ったポーズを維持する。第 2 画像はバーガンディーの透けないサテンドレスだけを提供する。別人の外見ではなく、色、襟元、縫い目の位置を写す。第 3 画像はラウンジ、緑のベルベットのソファ、真鍮のランプだけを提供する。そのラウンジに、ドレスを着た Mara を置く。目が分かる自然なポートレートと柔らかな暖色の光にする。4:5 の座った斜め向きのポートレートにする。別人、文字、余分な装飾は加えない。

これは入力案で、実行して採点したものではありません。各画像に役割を与え、変更点と維持する特徴を示します。参照が食い違う場合も、顔は第 1 画像、衣服は第 2 画像から取ると分かります。

M02 では、ショットの文を、真鍮のランプが顔の片側を照らす腰から上のポートレートへ変えます。M01 に矛盾するカメラ用語を 10 個付け足さないでください。M03 では座り方を維持する文を、ソファ横に立ち、手を楽にして見せる明確な指示へ置き換えます。「座った姿を維持」と「立たせる」の両方は、避けられる矛盾です。

M04 は窓辺の光を求めます。巻き髪と衣服の説明は残し、冷たい窓の光と背景に残るランプを指定します。変更は光の関係と部屋内の位置で、新たな人物説明ではありません。M05 はマスターのチャコールのジャケットをドレスの上に使うと直接書きます。そうしなければ、衣服だけの参照に従うのも自然な解釈です。

M06 は、片側に明確な余白がある、座った広い構図です。生成後の適当な切り抜きで顔を小さくするのとは違います。意図する構図をモデルへ渡し、顔を原寸で確認します。広い構図はヘッダーに便利でも、外見を判断する顔の情報は少なくなることがあります。

エンドポイントと対象者に適する範囲で、求める NSFW の表現を制作指示へ書きます。「NSFW にして」という一般的なタグだけで、衣装、表情、切り取り方、雰囲気が伝わるとは考えないでください。制作者がそれらを指定する必要があります。公開例では、大人の夜の雰囲気、透けないサテン、直接の視線で、露骨な指示を使わず狙った調子を表します。

マスターにない正確なポーズが必要なら、大量のスケジュールを組む前に、そのポーズ自身を採用済み参照として作ります。曖昧な要求を繰り返しても、ワークフローは不足する視覚情報を補えません。最初のバッチの有用な結果は、即座の採用画像 6 枚ではなく、改善された原本パックかもしれません。

生成ループと独立したタスクエラー経路を接続する

Read Jobs に Google Sheets の Get Row(s) を加え、Jobs タブからバッチの行を取得します。Ready Jobs という Filter で、status が ready の行を残します。Sheets 内で絞るなら、複数一致したとき最初の 1 行だけでなく全行を返すようにします。6 行あっても 1 アイテムしか返さなければ、6 枚のバッチではありません。

絞ったアイテムを、Batch Size 1、Reset オフの Loop Over Items、Loop Jobs へ接続します。loop 出力を Prepare Edit、次に Edit Character へつなぎます。SpicyAPI 自体が複数の入力アイテムを処理するため、複数編集するだけならループは必須ではありません。ここでは、次の要求へ進む前に、各行の保存と状態更新を終えるために使います。

Edit Character を Image → Generate にし、正確な編集モデルを選び、Prompt を準備した指示へ対応させます。選んだ方式の 3 参照か 1 JSON オブジェクトを加えます。Wait for Completion と Download Output をオンにします。Max Cost per Item (USD) は意識して上限を決めます。小さな例では、全入力の見積もりが収まるなら $0.10 が開始時の上限として使えます。

上限は 1 アイテムに適用され、表全体ではありません。100 行がそれぞれ 10 セントの上限を通る可能性があります。対象は ready の 6 行に限定し、第 2 の境界が必要なら API キーのアカウント支出上限を使います。行数制限も支出上限も画質は改善せず、誤ったスケジュールで巨大な制作表を実行するのを防ぐものです。

ノードはタスク作成前に見積もりを行い、要求全体が上限を超えると生成前にエラーになります。別の見積もりを表へ表示する必要がなければ、制作経路へ第 2 の見積もりノードを加えません。計画では Model → Get Quote で、画像を生成せず同じ参照と設定を見積もれます。

Settings の On Error は、このガイドのエラー分岐用に通常出力で続行する設定にします。続行エラーの結果には error、description、利用可能ならタスク ID があります。Edit Character の後に If を置き、error の有無を確認します。エラーは task_error とメッセージを記録し、Loop Jobs へ戻します。成功は候補を保存し、pending_review を記録して同じループ入力へ戻します。

done 出力で別の画像を生成しないでください。全処理行が戻った後のバッチ集計に使います。更新した候補表を読んだり、件数を表示したりできます。分岐を明確にし、API エラーを空ファイルとして確認用フォルダーへ送らず、完成ファイルを直接納品先へ送らないようにします。

6 件の編集なら、ノード標準の待機を使います。通常、別のコールバック構成は不要です。タスク実行中に待機が止まった場合、元のタスク ID を Task → Get へコピーし、オプションの Wait for Completion と Download Output をオンにします。Task → Get は初期状態では待たないため、オフのままではファイルのない実行中レコードが返ることがあります。別の復旧実行では、対応する Jobs 行を読み、Prepare Edit に通してから Task → Get → Attach Job → 候補保存へつなぎます。後の式が使うジョブの関連情報を保つためです。新しい Manual Trigger を直接 Task → Get へつなぐと、Prepare Edit は未実行になります。復旧したタスクが成功してダウンロードできたら、Generate へ戻さず候補を保存します。タイムアウトでは、description にタスク ID がある場合があり、独立した taskId が空でも確認できるので、代替を送る前に確認します。画面が遅いという理由で新規生成すると、元のタスクも後で成功し、別の有料タスクが増える可能性があります。

保存前にジョブの識別情報を戻す

成功時、ノードはタスク記録とダウンロードしたバイナリを出力します。JSON は元の表の行に数項目を足したものではありません。taskId、state、cost、settled、output などの情報です。プロンプトに正しい行を使っても、後の {{ $json.job_id }} が空になるのはこのためです。

成功分岐の後に Edit Fields の Attach Job を加えます。タスク JSON を保ち、Include Binary Data をオンにし、リンクされたアイテムの式で制作項目を追加します。コミュニティノードは item pairing を提供するので、バッチの先頭行ではなく、対応する Prepare Edit のアイテムを参照できます。

{{ $('Prepare Edit').item.json.job_id }} を job_id に使い、batch_id、attempt、edit_prompt、原本の版名にも同じ形式を使います。現在のタスク記録から task_id を、{{ $json.taskId }} で取ります。バッチ、ジョブ、試行から candidate_id を作り、ファイル名の基礎にします。

全行の識別に $('Read Jobs').first() を使わないでください。先頭の結果を取るため、6 出力すべてを M01 と名付ける可能性があります。片方の分岐を並べ替えたり絞ったりした後、位置だけで対応を作り直すのも避けます。明確な関係がある間は item pairing が使えますが、後で意図的に分割・集約するなら、明示的な job_id を一緒に保ちます。

最初のダウンロード資産は、初期状態でバイナリ data です。追加は data_1、data_2 などです。例の編集モデルは 1 枚を返すため、保存へ渡す項目は data です。複数資産を返す別のモデルへ変えるなら、data の保存だけで全部保存できたと考えず、候補にどれを使うか決めるか、資産を別名の候補記録へ展開します。

JSON の output.assets[].url は結果リンクで、ダウンロードした内容ではありません。パッケージの説明によると約 20 分で期限が切れます。URL だけの表は直後には便利でも、後で戻ると開けないかもしれません。Download Output が、保存ノードに実際のバイト列を渡します。

バイナリにも恒久的な保存先が必要です。署名 URL の短い期限は引き継がなくても、n8n の実行データは削除される可能性があります。成功した実行は保管場所ではありません。実行中に候補を保存するからこそ、翌日も再生成せず画像へ戻れます。

候補を保存してから、目で次の修正を判断する

非公開の mara-evening-01/review フォルダーを保存先へ作ります。例では Save Candidate に Google Drive の File → Upload を加え、Input Data Field Name を data、ファイル名を候補 ID に .png を加えたもの、保存先を確認用フォルダーにします。Drive ノードのドキュメントにバイナリのアップロード項目が説明されています。

名前は実際の出力形式に合わせます。JPEG に .png と付けても変換されません。例ではモデル要求で PNG を選びました。分かりやすい名前だけでなく、保存サービスが返したファイル ID を残します。同じフォルダーに同名ファイルがあり得るため、後の納品には曖昧さのない原本が必要です。

Drive のアップロードは、完全な候補記録ではなくファイルのメタデータを返します。Record Candidate では、現在のアイテムのアップロード済み ID と、Attach Job のリンクされた候補 ID、ジョブ ID、タスク ID、費用を使います。Append or Update Row で candidate_id を照合し、Candidates タブへ手動で対応させます。別の試行が最初の記録を上書きするのを防げます。

Jobs も更新するなら、対応する job_id 行を pending_review にします。最後の表更新の出力を Loop Jobs へ戻します。エラー分岐では、戻る前に Prepare Edit の元のジョブ ID、エラーの説明、利用可能なタスク ID を記録します。両分岐がループへ届かなければ、最初の成功・失敗アイテムでバッチが止まることがあります。

保存した 6 枚を、2 つのサイズで一緒に確認します。サムネイルでは、同じ人物、一貫した衣装と部屋、ショット間の十分な変化があり、意図したシリーズかを見ます。原寸では原本と候補の目、鼻、口の形、顎の輪郭、生え際、特徴的な非対称さを比較します。実務的な確認点で、自動の生体認証採点ではありません。

表では外見の失敗と制作意図の失敗を分けます。Mara と分かるがランプの場所が違う画像と、別人の美しい画像では次の指示が違います。顔は良く構図が違うなら creative_fix にして不足する変更を書きます。人物が変わったなら identity_fix にし、顎が細くなった、生え際が違う、など変化を記録します。

state が succeeded、または自動キャプションが正しい衣装を説明したというだけで採用にしないでください。説明モデルがバーガンディーのドレスを認識しても、既存シリーズの顔かは判断しないことがあります。確認メモを提案する補助 AI は加えられますが、実際の採用判断は別に、見える形で残します。

失敗ごとに具体的な次の編集を決める

M01 が近くても、衣装参照のマネキンの髪形を取り込んだとします。まず第 2 画像に競合する頭が本当にないか確かめ、あるなら衣服へ切り抜きます。その後、第 2 画像はドレスだけ、巻き髪と生え際は第 1 画像だけから取ると明確にします。ずれた候補ではなく、元のマスターに対する試行 2 として送ります。

M02 が Mara に見えてもドレスの襟元が違うなら、衣服参照を改善します。襟元が隠れる暗い写真では、維持すべき情報が少なくなります。縫い目が明確な部分を切り抜き、腰から上の構図を保ちつつ、その構造を指定します。漠然と似たドレスを増やすと、曖昧さが増す場合があります。

M03 の立ち姿には、2 種類の失敗があります。姿勢は自然でも顔が違うなら、カメラの変更を減らし、顔をカメラへ向けた斜めの立ち姿を試します。顔は保てても体が不自然なら、ソファの横で手を楽に見せる単純な姿勢を求めます。難しいひねり、組んだ腕、極端な照明を同時に要求すると、原因が分かりにくくなります。

M04 は顔を保っていても、光が冷たく暗すぎて比較しにくいかもしれません。外見のずれとして捨てる前に、ニュートラルな見え方で照明と顔の比率の変更を区別します。次は窓辺を残し、顔の細部が見える光と柔らかい影を求められます。色調で同じ人物が見慣れなくなっただけなら、自動的に別の人物参照を足さないでください。

M05 ではジャケットが別の衣装へ発展し、バーガンディーのドレスが消えることがあります。元のチャコールのジャケットを開けてドレスの上に着せ、ドレスの構造を見せると書きます。ほぼ良い画像でジャケットの縁 1 か所だけがおかしいなら、全体編集より、採用候補の局所マスク修正を検討します。これは選んだ候補だけを原本にする新規ジョブで、元の 3 参照要求ではありません。

M06 は余白を作れても、表紙用として頭が小さすぎるかもしれません。座ったミディアムポートレート、左に部屋、顔は十分に分かる大きさ、と構図を調整します。比率変更だけではタイトルの場所は伝わりません。4:5 や 16:9 を列挙するだけでなく、配置を説明します。

内容の拒否は、外見修正ではなくタスクエラーの経路です。理由を読み、適切で許可された要求やモデルを選び、同じ拒否入力を繰り返さないでください。生成済みでも不適切な結果は別で、生成が成功したため課金される場合があります。確認表で区別し、制作意図に合わなかった試行の費用を見えるようにします。

最初は 2 回など、意識して試行上限を決めて修正分岐を止めます。制作上の選択で、2 回で十分という予測ではありません。難しいショットは原本準備や手動編集へ戻せます。留守中に関連の薄い 20 案を作るより、問題を見えて再現できる状態にすることが、自動化の有用な使い方です。

顔の比率と巻き髪を、背景の構図やランプの位置と分けて比較します。図解。

採用したファイルを再生成せず納品する

確認後、選んだ候補の行を approved にします。他の試行はメモ付きで確認用に残します。M03 は試行 2 を採用し、試行 1 を identity_fix のまま残すかもしれません。納品は Candidates を読み、フォルダー内の最新ファイルから勝者を推測しないようにします。

第 2 のワークフローを Manual Trigger、Google Sheets の Get Row(s)、review_status が approved かつ delivery_file_id が空の行を選ぶ Filter で作ります。Batch Size 1 の Loop Over Items を加えます。保存した Drive ファイル ID で候補をバイナリ data にダウンロードし、納品用の名前でバッチの approved フォルダーへアップロードします。

ここでは、一時的な SpicyAPI の結果 URL ではなく、保存した候補を使います。それが実際に確認した画像です。同じシードや高い解像度で Image → Generate を呼び直し、採用済みのままだと思わないでください。新しい生成は顔、衣装、構図が変わり得るため、新たな確認が必要です。

採用フォルダーへのアップロード後、候補行に delivery_file_id と review_status: delivered を記録し、必要なら Jobs に選んだ候補 ID を記録します。更新をループへ戻します。ファイル ID は納品した版を安定して取得する手段になり、通常の再実行で、採用済みの全行を未完了扱いするのを防ぎます。

ここではバイナリの受け渡しが明確な、ダウンロードとアップロードによるコピーを使います。保存先に元のバイト列を保つコピー操作があれば、それでも構いません。採用画像をコピーし、編集モデルを再実行しないという制作上の原則は同じです。

リサイズ、切り抜き、圧縮した書き出しは別フォルダーにします。同じ原本からでも、正方形サムネイルと原寸の採用ポートレートは別ファイルです。採用した原本を残せば、生成料金なしで別の書き出しを作れます。切り抜きで髪が切れたり人物の見せ方が変わったりしたら、用途に合わせて書き出しも確認します。

このワークフローには SNS 投稿ノードはありません。納品は、ファイルと選ばれた候補の表で終わります。ページ制作者への受け渡し、非公開ギャラリーの準備、手動の公開先選択には十分です。用途別の公開を後で加えられますが、生成と確認から切り離せない構成にはしません。

選択欄だけでなく、実際の参照パックを見積もる

開始価格はモデルを探すための目安です。全参照と設定が要求の見積もりを決めます。カタログの Qwen Image 2.1 Edit の開始額は 1k が $0.036、2k が $0.048、1.5k が $0.072 です。参照 3 枚、透過なしの PNG、拡張無効の公開見積もりは、1k が $0.060、2k が $0.048 です。1k は追加 2 参照で $0.024 加算され、見積もった 2k にはその追加がありません。中間解像度が 2k より安い、参照追加料金が各段階で同じ、と考えないでください。

追加の 5 行を ready にする前に、同じ image_urls、プロンプト、設定で Model → Get Quote を使います。見積もりと一緒に組み立てた入力も返るため、3 参照が対応付け後も残ったかを確認できます。この計画操作は必要に応じてバイナリ参照をアップロードしても、画像は生成しません。

計画する 3 参照の 2k は、現在の $0.048 の見積もりなら、最初の 6 候補で $0.288、12 要求で $0.576 です。同じ 3 参照を 1k で 6 件なら $0.360 です。見積もりに基づく制作予算で、実行済みバッチの領収書や画質比較ではありません。実行前に自分の原本と設定で見積もり直します。保存先と n8n のホスティングや契約の費用は別です。

試行はタスクとして数えます。有料候補の一部が指示に合わなければ、採用 6 枚に成功生成が 6 件以上かかることがあります。最初を見積もり、各ショット 2 回を上限にするなら、計画する生成試行は最大 12 件です。代替の余地を考えない「6 枚のバッチ 1 回」より有用な予算です。

プラグインは各アイテムに冪等性キーを送ります。同じ実行内の同じノード呼び出しの再試行は、重複課金ではなく既存タスクを復旧する設計です。新しい実行、変更した入力、別のループ通過は新規作業です。Execute Workflow の押し直しは、元のタスク ID の復旧とは違います。

行にタスク ID があれば、技術的な中断の代替を送る前に、そのタスクを確認・復旧します。成功したが Drive の失敗で保存されなかったなら、出力を取得して保存を終えます。保存先の認証期限が切れても顔は良くならないため、別の生成へ払う制作上の理由はありません。

説明では、失敗・期限切れタスクは通常予約額を解放し、拒否要求はモデルページに別記がなければ課金されません。自分の確認で不採用にした成功候補は API 失敗と違います。精算済みタスクの actual_cost を残し、各納品ショットに実際いくら必要だったかを後で確認します。

最初のジョブを原本から納品まで動かしてから増やす

全 6 行を有効にする前に、M01 を生成、保存、確認まで通します。確認用フォルダーの実ファイルを開きます。行が M01、プロンプトの参照の役割が正しく、返されたファイルが今見ているものかを確かめます。実行画面のプレビューが正しくても、保存候補の名前と表の対応が正しい証拠にはなりません。

その候補を採用して納品を 1 回実行します。採用フォルダーを開き、選んだ画像と同じか確かめます。表の状態を変えず再実行すると、納品 ID がある行は飛ばすはずです。後で ID を手動削除すると再び対象になるため、実際に別のコピーが必要な場合だけ行います。

次に M02～M06 を ready にします。生成ループは各ジョブに候補記録 1 件か、具体的なエラー記録を作るはずです。一覧を確認して短く具体的なメモを書き、そのメモで必要と判断した代替試行だけ作ります。通常の代替ショットでも、マスターを原本に保ちます。

これで、明確なキャラクター原本、役割を付けた参照、別々の編集ジョブ、正しいバイナリと URI の扱い、読みやすい制作指示、選んだ画像だけの納品フォルダーを持つ、実用的な n8n NSFW image-to-image ワークフローになります。自動化が材料を運び、制作を保存します。公開する価値のあるシリーズになるかは、ショットの設計と選択で決まります。