チュートリアル
seedream-5.0-pro の image-to-image 実践:5 つの高価値ユースケースと導入要点
開発者向けの横断的視点:シーンをどう選び、どう接続し、コストをどう抑えるか
なぜ image-to-image でシーン別の選定を行うのか
image-to-image と text-to-image の最大の違いは、入力側に元画像が 1 枚増えることです。元画像は制約であると同時に負担でもあります。構図・色彩・主体構造を固定してくれるため、モデルがゼロから「あなたが何を求めているか」を推測する必要がなくなります。しかし同時に、出力品質の上限が入力品質によって頭打ちになり、編集指示は「何を変え、何を変えないか」を中心に書かなければならないことも意味します。
この違いは選定ロジックを直接変えます。text-to-image は「どちらが上手に描けるか」を競うので、同じプロンプトで横並びに採点すれば済みます。image-to-image は「与えられた元画像上で、どちらがより言うことを聞くか」を競います。保持率、局所編集の精度、指示への追従度、バッチ間の一貫性といった指標は、あなたの具体的なシーンに強く依存します。同じモデルが商品画像の背景差し替えで優秀でも、古い写真の修復やキャラクターのバリエーションで同様に使えるとは限りません。
したがって、より有効な方法はシーン別に選定することです。まず自分の要件をいくつかの典型的なタスクに分類し、それぞれについて入力画像の仕様、編集指示の形式、出力の受け入れ基準を明確に定義してから、実際のサンプルで検証します。本記事では ByteDance の seedream-5.0-pro/image-to-image を例に、5 つの高価値シーンを分解し、統一的な導入とコスト管理の考え方を示します。これは統一インターフェース経由で画像出力を提供し、機能は image-to-image に集中しているため、この種のシーン別検証の出発点として適しています。
実用的なメンタルモデルとして、image-to-image のフローを 3 段階に分けるとよいでしょう。入力前処理(クロップ、圧縮、ノイズ除去)、編集指示の構築(プロンプト+パラメータ)、出力ゲート(自動品質チェック+人手による抜き取り検査)です。以降の各シーンもすべてこの 3 段階に落とし込みますが、違いは制約の緩さだけです。

シーン 1:商品画像のスタイル統一とバッチ改版
EC チームで最もよくある要望は、白背景の商品画像を大量に持っていて、それをあるブランドトーン(背景、光と影、色調)に統一し、さらに一定期間ごとに全体を改版したいというものです。まさにこれが image-to-image の高価値領域です。主体は変えず、環境を描き直すのです。
入力と出力の設計
- 入力画像:固定のアスペクト比に統一してクロップし、主体を中央に置き、描き直し用に十分な背景領域を確保します。白背景画像にはモデル用の「編集可能な余白」が必要で、主体が端に接している画像は背景を変えられないことが多いです。
- 編集指示:「商品本体とそのテクスチャ、ロゴは保持し、背景のみを……に置き換え、光と影の方向は一致させる」と明示的に書きます。「変えないもの」を先に書く方が、スタイル用語を並べるより効果的です。
- 出力制約:後続の出品システムがそのまま利用できるよう、出力サイズとアスペクト比を固定します。
バッチ戦略
SKU ごとにグループ化して投入し、同じグループは同じ指示テンプレートを共有し、少数の可変スロット(背景色、シーン種別など)だけを置き換えます。これによりグループ内の一貫性を保ちつつ、少数のサンプルでまずスタイルの試し実行を行い、確認後に全体へ展開しやすくなります。バッチ処理キューは冪等性を確保する必要があります。同じ SKU の同じバージョンの重複投入は排除し、改版の途中で新旧が混在しないようにします。
よくある落とし穴
- 主体が「描き直される」:指示内の主体記述が曖昧すぎると、モデルが商品の細部を変えてしまうことがあります。「保持」「変更しない」といった表現で強化します。
- 光と影の不一致:新しい背景の光源方向が元画像と合わないと不自然に見えるため、指示に光源方向を明示します。
- 文字やロゴのにじみ:小さな文字の領域は後工程で合成することを推奨し、生成に依存しないようにします。
受け入れ指標は、単体画像の見栄えではなく主体の忠実度(構造類似度や人手による採点が利用可能)とグループ内の一貫性に注目することを推奨します。

シーン 2:デザイン案から多サイズのマーケティング素材へ
1 枚のキービジュアルから、スプラッシュ、バナー、スクエア型フィード、縦型ストーリーページなど多様なサイズを派生させることがよくあります。従来はデザイナーが 1 つずつ改版するため、コストが高く、崩れやすいものでした。image-to-image は「再レイアウト」の工程をモデルに任せられますが、勝手に変更されないよう制約することが必須です。
鍵は制約にあり、創造性ではない
この種のタスクの本質はレイアウトの再構築であり、再創作ではありません。方法としては 2 つの路線があります。
- 外側拡張+再配置:まず目標のアスペクト比に合わせてキャンバスを外側に拡張し(または元画像の外周に背景を補い)、次に指示でモデルに新しいキャンバス内で要素の位置を再配置させます。主体とコピーの内容は変えません。
- 局所的な描き直し:主体領域を固定し、端と空白部分だけを生成します。サイズ変化が小さいシーンに適しています。
指示の書き方
デザイン案の要素を 1 つずつ名指しします。「人物の主体、商品、メインタイトルの文字内容を保持し、画面を横長から縦長に変更し、主体を上部に置き、下部にタイトル領域を確保し、配色は原稿を踏襲する」といった具合です。要素の名指しが具体的であるほど、逸脱の確率が下がります。
出力と人手の工程
多サイズのタスクでは、1 回の生成ですべてが基準を満たすことを期待しないでください。推奨フローは、まず低解像度のプレビューを生成してレイアウトを確認し、確認後に正式サイズを出力するというものです。文字領域の精度が不足する場合は、書き出し時に文字レイヤーを残し、デザインツールで重ねます。これによりコストを抑えつつ、生成モデルが字形を苦手とするという本質的な弱点も回避できます。
受け入れ基準には要素の完全性(あるべきものが揃っている)、レイアウトの適合性(セーフエリア、余白)、文字領域の差し替え可能性の 3 項目を含めるべきです。
シーン 3:古い写真や低品質画像の修復・強化
修復・強化は image-to-image の中で入力品質に最も敏感な種類です。同じ「修復」でも、軽度に色あせた集合写真と、深刻な傷・ピンボケ・低解像度の古い写真では、達成できる効果に雲泥の差があります。まず入力品質を評価し、それから生成に投資するか決めることが、このシーンで最も重要なエンジニアリング規律です。
入力品質ゲート
モデルを呼び出す前に、軽量なチェックを一巡実行します。解像度の下限、ぼけ度(ラプラシアン分散系の指標)、ノイズレベル、大面積の遮蔽や破損の有無などです。しきい値を下回る画像は直接「人手介入」の分岐に回すか、従来の画像前処理(ノイズ除去、超解像)を行ってからモデルに投入します。修復不可能な画像を生成前に遮断する方が、生成後に不良判定するよりはるかに安価です。
許容できる境界
修復系タスクでは、事前にビジネス側と次の 2 点をすり合わせる必要があります。
- 忠実さ vs 美化:できるだけ元の姿を再現する(年代感の保持を含む)のか、見栄えの向上を追求するのか。指示はまったく異なります。前者は「人物の五官の特徴を変えない」ことを強調し、後者は緩めにできます。
- 復元不可能な内容:欠損領域は補完するのか、空白のままにするのか。補完は生成であり、虚構のリスクがあります。証明書や人物写真などの機微な内容では明確に禁止すべきです。
失敗の判定
失敗を 3 種類定義することを推奨します。主体の失眞(顔や文字の崩れ)、過度な平滑化(プラスチック感)、構造の誤り(肢体、背景の論理的な誤り)です。前 2 種類は元画像との構造比較で自動的にふるい分けでき、3 番目は抜き取り検査が必要です。修復タスクは一般に再試行率が高いため、フロー内に再試行の予算を必ず確保してください。詳細はコストの節を参照してください。

シーン 4:ローカライズとコンプライアンス対応の差し替え
海外展開やマルチリージョン運営では、同じ素材セットを異なる市場に適合させる必要がよくあります。画面内の文字、通貨記号、パッケージラベルを差し替えたり、特定地域で不適切な要素を除去したりします。この種のタスクの中心的な要件は局所的な正確な差し替え、全体の構図は動かさないことです。
局所的な描き直しの正しいやり方
画像全体を再生成するのではなく、マスクや領域記述で編集範囲を限定します。指示には「何を変えるか」と「周囲は変えない」を同時に示します。例えば「マスク領域の文字を空白のクリーンな背景に置き換え、周辺のテクスチャ、光と影、パースを連続させ保持する」といった具合です。差し替え系タスクではエッジの融合が成否の鍵であり、マスクのエッジを少し外側に広げる方が、境界にぴったり合わせるより自然な結果になることが多いです。
文字差し替えの現実的な制約
生成モデルは字形の精度が信頼できません。特に小さい文字サイズや多言語では顕著です。実務的な方法は、image-to-image で元の文字を消去し、きれいな受け皿面(単色ラベル、布のしわなど)を生成し、その上に組版システムやデザインツールでローカライズしたコピーを重ねるというものです。これにより文字の可読性とコンプライアンスを確保しつつ、生成の視覚的な融合能力を活用できます。
コンプライアンス対応の差し替え
文化的に敏感な要素が関わる場合は、「禁止リスト」を維持し、プロンプト内に出現してはならない内容を明示的に宣言し、出力側に自動審査を 1 段加えることを推奨します。差し替えの前後で差分比較を行い、対象領域だけが変更され、それ以外のピクセル変化がしきい値内であることを確認します。
受け入れ指標:対象領域の差し替え正解率、非対象領域の摂動度、エッジの連続性。
シーン 5:ゲーム・コンテンツ制作における素材バリエーション
ゲーム運営、IP コンテンツ、SNS 素材では、同じキャラクターやアセットを中心に大量のバリエーションを生み出す必要があります。表情、動作、服装、季節テーマなどです。image-to-image がこのシーンで価値を持つのは、キャラクターの識別性を保ちながら大量に展開することです。
一貫性は参照画像から生まれる
キャラクターの一貫性はテキスト記述だけに頼ることはできず、参照画像でアンカーする必要があります。方法は、1 枚(または 1 組)のキャラクター基準画像を入力として固定し、バリエーションの指示では限られた次元だけを変更することです。表情、姿勢、服装、シーンなどです。一度に 1〜2 次元だけを動かす方が、一度に大きく変えるより似ている状態を保ちやすいです。
「キャラクターカード」の構築
キャラクターの重要な特徴(髪色、瞳の色、象徴的なアクセサリー、体型の比率)を再利用可能な記述テンプレートとして書き、基準画像と一緒に固定します。すべてのバリエーションタスクは、この「キャラクターカード+単一次元の変更」という指示構造で投入し、源流からスタイルの漂いを抑えます。
バリエーションマトリクスと選別
大量のバリエーションは当然ながら不良率が高くなります。展開自体にランダム性があるためです。「次元×数量」で生成マトリクスを構築し、まず小バッチで試し実行してスタイルの方向性を確認してから、量を拡大することを推奨します。出力側では自動の一次選別(キャラクター特徴の検出、構図の適合性)を行い、高スコアの候補だけを人手の選別に回します。
アセットのアーカイブ
生成結果のそれぞれに、入力基準画像 ID、指示バージョン、パラメータセット、生成時刻を付けて、追跡可能なアセットライブラリを形成します。これは著作権とコンプライアンスの必要性であると同時に、後日どの指示セットの生産率が最も高かったかを振り返るのにも便利です。
コストモデルとスループット計画
seedream-5.0-pro/image-to-image は枚数課金のため、コストモデルは非常に直感的です。総コスト = 生成枚数 × 単価です。本当に管理すべきなのは単価ではなく、「利用可能な完成品 1 枚あたりの実効コスト」です。
再試行の増幅効果
1 回の生成の可用率を p とすると、完成品 1 枚を得るには平均で 1/p 回の生成が必要です。p が半分しかなければ、実効コストは公称単価の 2 倍になります。シーン 3 の修復系タスクやシーン 5 のバリエーション展開は再試行が多発する領域であり、一方シーン 1 のバッチスタイル統一は指示が安定すれば p を高くできます。予算を立てるときは、公称単価に需要量を掛けるのではなく、「需要量 ÷ 推定可用率」を用いてください。
不良率を下げる 3 つのレバー
- 事前検証:不合格の入力画像は直接遮断し、失敗が確実な画像にコストをかけない。
- 指示のテンプレート化:検証済みの高可用な指示をテンプレートとして固定し、自由な記述による分散を減らす。
- 小サンプルの試し実行:新しいシーンはまず少量のサンプルで方向性を確認してから、全体へ展開する。
キャッシュと重複排除
同じ入力画像+同じ指示+同じパラメータの重複リクエストはキャッシュにヒットさせ、過去の結果を直接返すべきです。バッチ改版のシーンでは、変更のない SKU は前バージョンの成果物をそのまま再利用でき、本当に変更された部分だけを再生成すれば済みます。
スループット計画
枚数課金のモデルは通常、並列数とレート制限の制約があります。計画時には「日次生成量」と「ピーク並列数」の両方を考慮する必要があります。バッチ処理タスクはキュー+バックオフ再試行で構成し、緊急でないバッチタスクを低負荷の時間帯にずらし、リアルタイムリクエストと割り当てを奪い合わないようにすることを推奨します。モニタリングでは少なくとも 4 つの指標を追跡します。投入量、成功率、可用率、完成品 1 枚あたりのコストです。いずれかがずれれば、指示か入力品質に問題が生じています。
導入チェックリストとよくあるトラブルシューティング
上記 5 つのシーンを、再利用可能な実装チェックリストに収束させます。
認証とリクエスト
- キーは環境変数またはシークレット管理サービスを経由し、コードリポジトリやフロントエンドに書かない。
- 画像入力はサイズと容量を統一的に整形し、巨大画像でリクエストが遅くなったり拒否されたりするのを避ける。
- リクエストボディに目標の出力サイズとアスペクト比を明示し、デフォルト値に依存しない。
タイムアウトと再試行
- image-to-image は text-to-image より時間がかかるため、タイムアウトのしきい値は個別に設定し、テキスト API のものを流用しない。
- 再試行は回復可能なエラー(タイムアウト、レート制限、5xx)のみを対象とする。パラメータエラーやコンテンツ拒否への再試行は無意味で、コストを増やすだけ。
- 指数バックオフ+ジッターを用い、同じ論理タスクに冪等キーを付けて重複課金を防ぐ。
結果のアーカイブ
各生成レコードには少なくとも次を保存します。入力画像の参照、指示全文、パラメータセット、出力アドレス、所要時間、ステータスコード。これはトラブルシューティングと効果の回帰の基礎であり、コストの帰属の根拠でもあります。
効果の回帰
- 固定の小規模な評価セット(5 つのシーンの典型的なサンプルをカバー)を構築し、モデルバージョンを変えるたび、または指示テンプレートを変更するたびに再実行する。
- 可用率、主体の忠実度、一貫性の 3 種類の指標で縦方向に比較し、肉眼の感覚に頼らない。
- 拒否と異常を分類集計し、コンテンツ審査系の拒否はプロンプト規範へフィードバックする。
よくあるトラブルシューティングの対照表
- 出力が入力とほぼ無関係:入力画像が過度に圧縮されていないか、指示に「保持」の制約が欠けていないかを確認する。
- 局所編集が全体に波及:マスク範囲とエッジの外側拡張を確認し、指示に「周囲は変えない」を補う。
- バッチ間でスタイルが跳ねる:可変スロットが固定されていないか、異なる基準画像が混在していないかを確認する。
- 成功率が突然低下:まずレート制限と割り当てを確認し、次に入力分布が変化していないかを見る。
このチェックリストを一巡すれば、image-to-image は「お試し」から「運用可能」な状態へ移行できます。すぐに検証したい場合は、seedream-5.0-pro/image-to-image のモデルページから最初のバッチサンプルを実行してみてください。
関連記事
すべての記事を見る →-
チュートリアル
HiAPI API で hailuo-2.3-fast/image-to-video を呼び出す方法:curl と Python の実践
高速・低コストな画像から動画へのティアにおける最初の実行可能なリクエスト — モデル ID から MP4 のダウンロードまで
-
チュートリアル
HiAPI APIでhailuo-2.3/text-to-videoを呼び出す方法:curl、Python、実行可能なリクエスト例
-
チュートリアル
HiAPI で Kandinsky 6.0 Pro のテキストto動画を使用する:curl と Python チュートリアル
リクエスト優先の実践デモ:プロンプトから動画クリップへの呼び出しを構築し、リクエストを送信し、完了状態をポーリングし、結果をダウンロードする