seedream-5.0-lite の Image-to-Image 実践：5 つの高価値な業務シーンと導入の要点

なぜ Image-to-Image が Text-to-Image より業務導入に向いているのか

多くのチームは初めて画像生成に取り組むとき、Text-to-Image から始めます。プロンプトを 1 つ入力して画像を 1 枚得る、というものです。デモは順調に進みますが、業務に投入した途端に問題が露呈します。同じプロンプトでも出力のスタイルがぶれ、主要な構造を制御できず、ブランド要素は運任せになるのです。原因はモデルではなく、情報の欠落にあります。業務が本当に必要とする制約（構図、主体の形状、ブランドカラー、レイアウトの余白）は、自然言語の 1 文では安定して記述できません。

Image-to-Image はこの問題を解決します。参照画像を用意し、「どんな見た目か」は画像に任せ、「何を変えるか」はプロンプトに任せます。制約を入力側に前倒しすることで、出力の安定性が高まります。

3 種類のニーズを選別する基準

どちらの道に進むべきかを判断するには、まずこう問いかけるとよいでしょう。業務のニーズの中に、すでに「ほぼ正しい」画像が 1 枚あるか？

• Image-to-Image：参照画像がすでにあり、主体/構図/トーンの維持を前提に、スタイル化、リメイク、バリエーション派生、部分的な再加工を行うケース。典型的には商品画像の背景とライティングを統一する、メインビジュアルから複数レイアウトを派生させる、既存素材のスタイルを変換する、など。
• Text-to-Image：参照画像が一切なく、ニーズの本質が「ゼロからの創出」であるクリエイティブ探索や挿絵の補填であり、主体の形状を自由に展開できるケース。
• 従来の画像処理：ニーズが確定論的な幾何変換や色彩変換であるケース。トリミング、リサイズ、ウォーターマーク、圧縮、固定サイズの結合、簡単な切り抜きなど。こうしたタスクは OpenCV/Sharp などのライブラリの方が速く、安く、完全に予測可能であり、生成モデルに任せるのは逆に無駄です。

実用的な判断ライン

「許容できる誤差」で線を引くことができます。結果がピクセル単位で予測可能でなければならないなら従来処理、ある程度の創作上の自由度は許容するが参照画像の重要な特徴は保持しなければならないなら Image-to-Image、参照すべき特徴すらないなら Text-to-Image です。

本稿の以降のシーンでは、seedream-5.0-lite/image-to-image（提供元 ByteDance、出力は画像）を例に展開します。入力側は参照画像 + プロンプトであり、上記の「参照画像があり、特徴を保持する必要がある」という大きなカテゴリの業務ニーズをちょうどカバーしています。選定時にはまず自分がこのライン上にあるかを確認してから、導入するかどうかを検討してください。

注意すべきは、Image-to-Image は万能フィルターではないということです。業務の真の要請が「画像 A を厳密に画像 B に変える」ことであり、その差異が正確な文字組みや厳密な幾何アライメントに関わる場合、生成モデルは得意ではありません。依然としてデザインツールやテンプレートレンダリングに戻る必要があります。

着手前の準備：呼び出しチェーンと入力制約

Image-to-Image の導入は一見 API 呼び出し 1 回だけに見えますが、実際のエンジニアリングでは問題のほとんどが呼び出しの前後に発生します。チェーンを分解すると、1 回のリクエストは 5 つの段階からなります。参照画像の前処理、プロンプトの組み立て、API リクエスト、結果の検証、保存とフィードバックです。

第 1 段階：参照画像の前処理

参照画像の品質が出力の下限を直接決めます。リリース前にいくつかのハードな規範を定める必要があります。

• サイズと比率：業務で実際に必要な比率の範囲に統一し、特異な入力比率による構図の歪みを避ける。
• 容量と形式：大きな画像は適切な解像度に圧縮してからアップロードする。転送時間を短縮できるだけでなく、無関係な細部が生成を妨げるのを防げる。
• 内容のクリーンさ：目標と無関係なウォーターマーク、ステッカー、余計な文字を除去する。主体はできるだけ中央に、完全に、大きな遮蔽なく配置する。
• 一貫性のベースライン：同一バッチのタスクの参照画像は、光照、色温度、背景をできるだけ近づける。そうでなければ出力がこれらの差異を継承してしまう。

このステップは業務コードの中に散在させるのではなく、独立した前処理関数として実装するのが望ましく、後でモデルを変更する際に全体を再利用できます。

第 2 段階：プロンプトの組み立て

Image-to-Image のプロンプトは Text-to-Image とは書き方が異なります。Text-to-Image は画面をゼロから記述しますが、Image-to-Image は「制約リスト」として書くのが適しています。何を保持し、何を変え、何の出現を禁止するか、です。固定テンプレートで組み立てることを推奨します。例えば「参照画像の主体形状と構図を保持し、背景を X に変更し、全体の色調を Y 寄りにし、文字やウォーターマークを追加しないこと」といった形です。テンプレート化により、複数人での協業時のスタイルのぶれを大幅に低減できます。

第 3 段階：リクエストとタイムアウト

呼び出し側はタイムアウトの閾値と同時実行の上限を事前に決める必要があります。画像生成は時間のかかるタスクであり、同期リクエストはインターフェースをボトルネックに陥れやすいです。業務量が多い場合は非同期キュー + コールバック/ポーリングの形態で、「送信」と「結果取得」を分離するのが適しています。

第 4 段階と第 5 段階：検証と保存

生成結果をそのまま業務データベースに入れることはできません。少なくとも 3 つの検証を通す必要があります。ファイルの完全性（正常にデコードできるか）、コンテンツのコンプライアンス（出現すべきでない要素が含まれていないか）、業務上の可用性（主体が依然として保持されているか、スタイルが基準を満たしているか）。検証に失敗したタスクは成功としてマークするのではなく、再試行キューに入れます。結果の保存では、元の参照画像とプロンプトの関連を保持し、事後の追跡とバッチ再現を容易にします。

このチェーンを先に通してから具体的なシーンを論じれば、手戻り率はかなり低くなります。

シーン 1：商品画像のスタイル統一とバッチリメイク

EC チームが最もよく直面する悩みは、同じショップに数百の SKU があり、画像が異なるサプライヤー、異なる撮影バッチに由来し、背景色、光量比、色温度がそれぞれ異なるため、リストページに並べると雑然として見え、コンバージョン率に影響する、というものです。撮り直しはコストが高く、 1 枚ずつ修正するのは人的に耐えられません。

これこそ Image-to-Image の最も典型的な使い方です。「標準画像」を 1 枚参照として使い、残りの商品画像を同じビジュアルスタイルにバッチで揃えます。

実装の要点

参照画像は正しく選ぶこと。 参照画像は「スタイルのアンカー」の役割を担います。特定の商品である必要はなく、目標とするスタイルを体現しているべきです。背景、光の方向、色温度、余白の比率、影の有無などです。高品質な標準画像を 1 枚使う方が、長いスタイルプロンプトを書くより優れています。

プロンプトは「何を変えるか」だけを記述する。 例えば、商品の主体と商標を保持し、背景と全体の色調だけを調整するよう明確に要求します。プロンプトの中で商品自体を繰り返し記述しないでください。そうしないとモデルが主体を再描画しやすく、商品の細部が崩れます。

段階的に進め、まず小ロットで確認してから全量へ。 一度に全量のタスクを送信するのはリスクが高すぎます。カテゴリやサプライヤーごとに小バッチに分け、各バッチで数枚を選んで人手で確認し、安定してから量を増やすことを推奨します。

一貫性の検証

バッチタスクで最も怖いのは「大部分は合っているが、少数が崩れる」ことです。自動検証項目を設定することを推奨します。主体領域が依然として存在するか、色ヒストグラムが目標範囲に収まっているか、余計な文字やウォーターマークが出現していないか、などです。人手による抜き取り検査の割合は、バッチの安定度に応じて徐々に下げていけます。

バッチと失敗処理

バッチ処理の鍵は同時実行数ではなく「再入可能性」です。各タスクに一意の ID を付け、失敗時は個別に再実行でき、成功済みの部分を重複して消費しません。失敗原因は分類して記録する必要があります。参照画像の不適合、プロンプトの競合、コンテンツ検証の失敗など、原因ごとに対応する修正アクションが異なり、混在させると調査が遅れます。

シーン 2：マーケティング素材の複数レイアウトへの迅速な派生

マーケティング側のニーズは往々にして「1 稿を複数チャネルに投入する」ことです。メインビジュアルを 1 枚仕上げたら、すぐに異なるチャネルに適合する複数のレイアウトを生成する必要があります。フィード用の横長画像、詳細ページ用の縦長画像、SNS 用の正方形画像、開屏用の縦長画像などです。従来の方法ではデザイナーが手作業でリメイクし、メインビジュアル 1 枚から 5〜6 版を派生させるのに半日かかります。

Image-to-Image はこのステップを 1 回のバッチ派生に短縮できます。メインビジュアルを参照画像とし、各レイアウトに対して個別にタスクを送信します。

レイアウトの鍵は「余白の管理」

レイアウトごとにコピー領域への要求が異なります。派生前に、各レイアウトで文字をどこに置き、どれだけのスペースを確保するかを明確に考える必要があります。プロンプトでこれを明示的に制約すべきです。例えば、主体を左寄りにし、右側に清潔な背景領域を確保するよう要求します。モデルの出力で主体がコピー位置を覆ってしまったら、その版は使えません。だからこそプロンプトには「目標項目」だけでなく「禁止項目」を書く必要があります。

サイズ戦略

2 つの考え方があります。1 つは各レイアウトに対応する比率で参照画像をトリミングしてから生成する方法、もう 1 つは統一した参照画像で生成してからトリミングする方法です。前者は出力がより自然ですがコストが高く（各レイアウトが 1 回の生成）、後者はコストが低いですが構図がトリミングで崩れる可能性があります。主体がシンプルな素材は後者、主体が密集した素材は前者を推奨します。

派生は描き直しではない

モデルに「メインビジュアルの核心要素を保持する」よう明確に伝える必要があります。主要色、主体形状、全体的な雰囲気を含みます。各レイアウトをモデルが自由に展開すると、最終的に一連の素材の間に統一感が欠け、逆にブランド認知を弱めます。派生品質を評価する基準は、単体が美しいかどうかではなく、このセットを並べたときに同じキャンペーンに見えるかどうかです。

プロセスの提案

派生タスクを「メインビジュアル → レイアウトリスト → バッチ送信 → まとめてレビュー」のパイプラインにします。レビュー段階では 1 枚ずつ見るのではなく、レイアウトごとにグループ化することで、スタイルの断絶をより早く発見できます。承認されたバージョンは素材ライブラリに入り、対応する参照画像とパラメータを記録します。次回同種のキャンペーンではテンプレートを直接再利用できます。

シーン 3：ブランドビジュアルの一貫性を参照画像で駆動する生成

ブランドの一貫性の難しさは、バッチをまたぎ、時間をまたぐことにあります。今日作ったポスターと 3 か月後に作ったバナーでスタイルが統一されていなければ、ユーザーが知覚するのは「これは同じブランドではない」ということです。Text-to-Image ではこの問題を解決しにくいです。プロンプトは人によって異なるバージョンで書かれ、モデルのバージョン更新もスタイルのぶれをもたらします。

Image-to-Image の考え方は、ブランドのトーンを 1 枚（または 1 組）の固定された参照画像に定着させ、すべての生成タスクをそれをアンカーとするものです。スタイルはプロンプトの文言に依存せず、バージョン管理可能な資産に依存します。

「ブランド参照画像ライブラリ」を構築する

ブランドのために 1 枚ではなく 1 組の参照画像を維持することを推奨します。少なくとも以下をカバーします。主要色の雰囲気画像、典型的な構図のサンプル、材質/ライティングのサンプル。シーンごとに異なるアンカー画像を選びます。商品画像にはライティングのアンカー、イベントページには雰囲気のアンカーを使います。これらの画像はバージョン管理に入れ、変更はすべてレビューを通す必要があります。これらが出力のブランド表現を直接決めるからです。

プロンプトは「シーン」だけを担当する

ブランドの制約を参照画像が担った後は、プロンプトは非常に軽く書けます。今回の具体的な内容と用途だけを記述します。これにより、異なるチーム、異なる時期の呼び出しでもスタイルのベースラインは安定し、差異はコンテンツ層のみになります。

一貫性をどう検証するか

目視で 1 枚ずつ判断することはできません。実現可能な方法は定量的な指標を構築することです。主要色の比率がブランド色の範囲に収まっているか、全体の明度/彩度の分布が基準に近いか、構図の重心位置が安定しているか。これらの指標はバッチ出力のたびに自動で実行し、閾値を超えて逸脱したものは人手で再確認します。

よくある誤解

参照画像を「完全に同一でなければならない」テンプレートと見なすことです。参照画像の役割はトーンを制約することで、画面を固定することではありません。過度な制約は出力の応用力を奪い、新しいシーンに遭遇すると生成に失敗します。合理的な目標は「並べたときに同じブランドだと分かる」ことであり、「すべてがコピーのように見える」ことではありません。

シーン 4：デザイン稿からビジュアル稿への迅速な探索

デザインレビュー前で最も時間がかかるのは「探索」です。ワイヤーフレームやスケッチから出発し、いくつかのビジュアル方向を試してから議論に持ち込みます。手作業で 3 版のビジュアル稿を作ると 1 日かかるかもしれません。方向性がすべて間違っていれば、1 日の投資が無駄になります。

ここでの Image-to-Image の価値はデザイナーを代替することではなく、探索段階を「日」から「時間」に短縮することです。ワイヤーフレームやスケッチを参照画像として、複数の方向のビジュアル稿を迅速に生成し、内部で方向性を揃えるために使い、方向が確定してから精緻なデザインに進みます。

入力の準備

スケッチを参照画像とする場合、情報密度が低く線が抽象的であるため、モデルが「自由に展開」しすぎる可能性があります。送信前にスケッチを適度に補完することを推奨します。主要なブロックを注釈し、強調したいビジュアルフォーカスを示します。一部のチームは簡単な色ブロックで領域を塗り、粗い明暗関係を与えます。これにより出力の安定性が明らかに向上します。

1 つの方向を何度も調整するのではなく、複数の方向を一度に送信する

探索段階の目標は候補空間を広げることであり、単体を磨くことではありません。やり方は参照画像を固定し、差異の明らかな数組のプロンプトでそれぞれ送信します。例えば「シンプルな幾何学寄り」「写実的な質感寄り」「イラスト風寄り」などです。結果を得たら横並びで比較する方が、1 枚を繰り返し微調整するより速く方向性を見つけられます。

出力の位置づけを明確にする

探索稿は議論の材料であり、成果物ではありません。この点はプロセス上で明確にすべきです。ビジュアル稿の解像度、細部の精度は納品基準に達する必要はなく、重点は方向性、雰囲気、情報階層です。探索稿をそのまま完成品として使うと、後期の手戻りコストが高くなります。

デザインフローとの連携

生成結果をデザインコラボレーションツールにアーカイブし、対応するスケッチ、プロンプトと一緒に置いて「方向探索記録」を形成することを推奨します。レビュー時に「どの方向を検討し、なぜこれを選んだか」が明確に見え、後の振り返りや新しい人の引き継ぎに非常に有用です。生成はあくまでアクセラレータであり、意思決定は依然として人にあります。

シーン 5：既存素材のインテリジェントな再加工

ほとんどの企業の本当の画像資産は「生成待ち」の中にはなく、「既存の素材ライブラリ」の中にあります。長年蓄積された商品画像、イベント画像、過去の素材です。これらの素材は品質がまちまちでスタイルも古くなっていますが、コンテンツ自体には価値があります。全量をやり直すのは現実的ではなく、Image-to-Image は再加工の道を提供します。

よくあるニーズは 3 種類です。スタイル変換（古い素材を現在のビジュアル言語に更新する）、部分的な再描画（古くなった背景や要素を置き換える）、仕様適応（新しいサイズと比率の規範に統一する）。

画像の選定はパラメータ調整より重要

既存素材ライブラリの最大の問題は品質分布が極端に不均一なことです。そのまま全量を実行すると、使えない結果が大量に得られ、予算を無駄に消費します。まず取り込み段階で 1 回選別することを推奨します。主体が明確で、遮蔽がなく、解像度が基準を満たす素材だけを再加工キューに入れます。低品質の素材は個別にマークし、人手で処理するか直接除外します。

このステップの投資対効果が最も高いです。選別がうまくいけば、後の生成成功率は明らかに向上します。

バッチとサンプリング

再加工は通常、大量のバッチタスクです。「素材の出所 + 年代 + カテゴリ」ごとにバッチ化し、各バッチの規模をレビュー可能な範囲に抑えることを推奨します。各バッチでまず小ロット（例えば総数の数パーセント）を実行し、スタイルが期待に合致することを人手で確認してから量を増やします。品質の抜き取り検査は最後の受け入れ時だけでなく、全体を通して行うべきです。問題の発見が早いほど、無駄が少なくなります。

追跡可能なチェーンを保持する

再加工後の素材は元画像と関連付けられなければなりません。元画像 ID、使用した参照画像、プロンプト、生成日時を記録します。これはコンプライアンス上の要求であると同時に、後のスタイル調整の根拠にもなります。あるスタイル変換が「ずれている」と判断された場合、どのバッチのタスク、どのパラメータの組が原因かを迅速に特定できます。

部分的な再描画の境界

部分的な再描画は背景の置き換えや古くなった装飾要素の除去に適しています。ただし注意すべきは、元素材の構図自体が現在の規範に合っていない場合（例えば主体が小さすぎる、余白が不足している）、部分的な再描画では解決できず、修正ではなく再生成に進むべきです。判断基準は「問題が局所か全体か」であり、全体の問題を局所的なツールに任せてはいけません。

導入とコスト：バッチ、再試行、統一 API 層

前述の 5 つのシーンをエンジニアリングに落とし込むと、最終的には 3 つのことに収束します。コストをどう見積もるか、バッチをどうやるか、モデルの差異をどう隔離するか。

コスト見積もり：枚数課金

seedream-5.0-lite/image-to-image は枚数課金の口径を採用しており、画像を 1 枚正常に生成するごとに 1 回の料金が発生します。これにより直接的な見積もり方法が導かれます。1 回のタスクのコスト ≈ 生成が必要な画像の枚数 × 1 枚あたりの価格。

予算に本当に影響するのは単価ではなく「無効な生成の割合」です。あるシーンで 10 枚のうち 3 枚しか使えないなら、実際の有効コストは名目コストの数倍になります。したがって最適化の方向は常に一発通過率を高めることであり、単により安いモデルを探すことではありません。通過率を高めるレバーは 3 つあります。参照画像の前処理品質、プロンプトのテンプレート化、そして少量のサンプルで先に検証してから量を増やすことです。

具体的な単価はサイトの価格パネルを基準とし、見積もり時にはその時点の課金口径を代入すればよいです。

バッチと再試行の設計

バッチタスクの核心は冪等性と再入可能性です。

• 各サブタスクに一意の業務 ID を持たせ、成功後に状態を書き込み、再実行時には完了済みの項目をスキップする。
• 失敗は原因ごとに分類する。入力の不適合、コンテンツ検証の不通過、タイムアウト。前 2 種類は再試行しても無意味であり、人手または上流での修正が必要です。自動再試行に値するのはタイムアウトやネットワーク系の失敗のみです。
• 再試行の上限とバックオフ戦略を設定し、異常なタスクが無限に予算を消費するのを防ぐ。
• バッチタスクには総予算の上限を設け、超過したら一時停止し、パラメータの記述ミスによる予期せぬ消費を防ぐ。

統一 API 層：モデルの差異を業務の外に追い出す

画像モデルは進化が速く、今日選んだモデルが明日より適切なものに置き換わる可能性があります。業務コードが特定の 1 社に直接接続していると、置き換えは全量の改修になります。業務とモデルの間に統一 API 層を 1 層追加し、4 つのことを担わせることを推奨します。

1. リクエストの正規化：業務は参照画像、プロンプト、比率などの意味的なパラメータだけを渡し、この層が具体的なモデルの入参に変換する。
2. 結果の正規化：返却構造を統一し、異なるモデルのステータスコード、エラーメッセージ、結果フィールドの差異を吸収する。
3. ルーティングとフォールバック：シーンごとにモデルを選択し、メインモデルに異常があれば代替に切り替える。
4. 課金と観測：呼び出し量、成功率、平均所要時間を統一的に記録し、コストと品質を測定可能にする。

この層は過度に重くする必要はありませんが、最初の導入時に構築すべきです。複数モデルの並行運用になってから補うと、改修コストははるかに高くなります。画像生成を統一インターフェース層に接続すれば、後のモデル変更や追加は設定の変更だけで済み、業務側はほぼ意識する必要がありません。

まず 1 つのシーンを選んで小ロットを通し、検証とコスト指標を蓄積してから外に拡張するのが、リスクが最も低い進め方です。