wan2.7-image/text-to-image と HiAPI API でEC商品画像を生成する

テキストから画像へのモデルをパックショットワークフローに組み入れるべき理由

商品カタログチームが直面するのは、通常、撮影の問題ではなく生産能力の問題です。1つのSKUには、きれいな正面パックショットが1枚必要で、場合によっては異なる角度のバリエーションも必要となり、さらにマーケットプレイスの仕様バージョンも求められることがよくあります。メインビジュアル素材や、実物商品とピクセル単位で一致する必要があるコンテンツについては、実撮影のほうが依然として優れています。生成パックショットが解決するのは、より狭く実用的なシナリオです。撮影待ち商品のプレースホルダー画像、商品詳細ページのA/Bテスト用背景バリエーション、カテゴリ企画段階のコンセプトレンダリング、そしてスタジオの枠を取る価値のないロングテールSKUの一貫した構図です。

有用な思考モデルはこうです。生成は商品データと商品掲載の間に位置するものであり、カメラマンを置き換えるものではありません。あなたのカタログにはすでに構造化された事実が含まれています。商品名、素材、色、形状、パッケージです。テキストから画像へのモデルは、これらの事実を画像候補に変換します。パイプライン上の課題は、SKUごとに手作業でプロンプトを書き直すことなく、カタログ規模でこれを再現可能に実行する方法です。

本ガイドはまさにこの課題に焦点を当てます。商品カタログ全体で視覚的に一貫したパックショットを生成できるようプロンプトをどう構成するか、プロンプトドリフトをどう診断するか、4K出力が本当に価値を持つのはいつか、そしてプロダクトコードが画像モデルと直接やり取りしないようにワークフロー全体を軽量サービスとしてどう封装するかを紹介します。本記事で使用するモデルは、HiAPI上のwan2.7-image/text-to-imageで、統一API呼び出しを通じて利用します。

HiAPIでwan2.7-image/text-to-imageを設定する

wan2.7-image/text-to-imageはHiAPI上のテキストから画像へのエンドポイントです。プロンプトのペイロードを送信すると、画像が返されます。モデルごとに個別のアカウントを開設する必要も、各ベンダーのSDKをインストールする必要も、2つ目の認証情報を管理する必要もありません。HiAPIがルーティングを担うため、モデルを追加しても置き換えても、統合面は変わりません。

ゼロから初回レンダリングまでの流れは次のとおりです。

APIキーを取得し、モデル名を確認する

HiAPIアカウントでキーを作成し、モデル一覧で正確なモデル識別子wan2.7-image/text-to-imageを確認します。識別子は設定として扱い、ハードコードされた文字列にはしないでください。環境変数や設定ファイルに置くことで、後日、呼び出し箇所を変更せずに別の画像モデルへ切り替えられます。

最小限のリクエストを送信する

呼び出し形式は意図的にシンプルに保ちます。プロンプトとモデル名だけです。まずは単一の商品を無地の背景に置いた様子を説明する一文から始め、返却結果を確認します。この時点ではテンプレートを構築しないでください。まず認証が有効であること、レスポンスにデコード可能または取得可能な画像データが含まれていること、そしてレスポンスがどんなメタデータ（サイズ、形式）を伴うかを把握します。

レスポンスをアーティファクトとして保存する

返却された画像は、メモリやデータベースにバイト列として保持するのではなく、決定的なキー名でオブジェクトストレージに書き込みます。初回呼び出しの時点から、各レンダリングを名前、プロンプトバージョン、タイムスタンプを持つアセットとして扱ってください。後から整備するのは非常に苦痛です。

プロンプトを画像と一緒に記録する

最も価値のあるメタデータは、承認された画像を生成した正確なプロンプト文字列です。これを記録してください。レビュアーが「なぜこの画像は違って見えるのか」と尋ねたとき、答えになるのはプロンプトです。

パックショットプロンプトの解剖

一度うまくいくパックショットプロンプトは偶然です。カタログ全体でうまくいくものは構造です。5つのコンポーネントを常に同じ順序で使い、SKU間で変わるのが注入されるデータだけになるようにします。

主体

具体的な物体を、そのカテゴリと輪郭を定義する1〜2の属性とともに示します。「マットなセラミック製ハンドドリップコーヒーフィルター」は「コーヒーマシン」よりもモデルに多くの情報を伝えます。マーケティング上の名称ではなく、製品タイプを述べてください。

素材と表面仕上げ

表面の挙動が商品画像のリアリティを決めます。素材と表面仕上げを明示します。マット、ヘアライン、光沢、フロストガラス、非塗工紙、陽極酸化金属などです。実物に微細なテクスチャがあれば、それも説明します。ドリフトは往々にしてここから始まります。

ライティング

パックショットには予測可能なライティングが必要です。小さな語彙を選び、カタログ全体でそれを使い続けます。柔らかく均一なスタジオ光、左上からの単一ソフトキーライト、柔らかなグラデーションの減衰などです。ドラマチックな出力を望まない限り、ドラマチックな表現は避けます。商品リストでは、芸術性よりも一貫性が勝ります。

背景

無地で中性であること、そして色を指定します。純白シームレス、淡いウォームグレー、透明に見える中性色などです。曖昧な背景は雑然とした背景を生みます。マーケットプレイスが白を要求するなら、白と書きます。

構図

クロップとカメラ位置を説明します。中央配置、商品が画面の約3分の2を占める、正面水平視点、わずかな斜め45度、どの部分もクロップしないなどです。構図によって、SKUグリッドが一揃いの商品に見えるか、雑貨の寄せ集めに見えるかが決まります。

これら5つのスロットで構築されたテンプレートにより、構造化された商品行のテーブルからカテゴリ全体を生成でき、次のセクションであるドリフトの修正もスロット単位の編集作業になります。

プロンプトへの追従性を高める

レンダリングが商品説明から外れたとき、本能はプロンプトを書き直すことです。そこはこらえてください。効果的なのは、どのコンポーネントが失敗したかを特定し、各イテレーションでその1つの変数だけを変えることです。

書き直す前に診断する

レンダリングを5つのスロットと比較します。素材は違うが構図は合っている？ それなら素材の文だけを調整します。商品は正しいが雑然としたシーンに浮いている？ 背景の節が弱すぎます。失敗したスロットを指摘することで、漠然とした「なんか違う」が具体的な編集になります。

制約を明示する。否定制約も含めて

モデルはあなたが言った内容に反応するので、重要なことは言葉にしてください。商品にロゴが見えてはいけない、不快な反射があってはいけない、手に持たれてはいけないなら、これらの除外項目をプロンプトに書きます。明確な制約は合理的なレンダリングの余地を狭め、まさにそれが追従性の意味です。

プロンプトごとのアイデア数を減らす

要素を1つ追加するたびに、小道具、他の物体の影、装飾的な表面などがモデルの注意を奪います。パックショットでは、小道具を完全に除外します。1つの物体を1つのシーンに置くことを説明するプロンプトのほうが、同時にスタイライズされたシーンを求めるプロンプトよりもはるかに信頼性の高い追従性を示します。

小さなテストセットと固定の比較ベースラインを維持する

カタログから代表的な5つのSKUを選びます。扱いにくい素材、反射する素材、小さいサイズ、大きいサイズ、印刷されたパッケージのものなどです。テンプレートを変更するときは、この5つを再レンダリングして比較します。これによりよくある失敗を発見できます。ある製品カテゴリへの修正が、別のカテゴリを静かに壊してしまうことです。毎回のレンダリングにテンプレートバージョンを記録し、出力品質の変化をプロンプトの変更に帰属できるようにします。

形容詞ではなく構造を強化する

あるスロットが継続的に失敗するなら、修正には通常、より多くの形容詞ではなく、より多くの構造が必要です。「美しいスタジオ光」を、望む具体的なライティング設定に置き換えます。「いい感じの背景」を色と表面に置き換えます。プロンプトが願望ではなく仕様表のように読めるとき、追従性は向上します。

4K出力を使う

高解像度は配置先に応じた判断であり、デフォルト値ではありません。wan2.7-image/text-to-imageは高解像度出力をサポートしますが、4Kレンダリングは毎回、標準レンダリングよりも多くの時間、ストレージ、下流処理を消費します。この選択は、画像がどこに表示されるかでルーティングするルールとして扱ってください。

解像度をユースケースにマッピングする

商品詳細ページのメインビジュアルや、ズームに使う画像には最高のティアがふさわしいです。買い物客はここで縫い目、テクスチャ、ラベルを確認します。グリッドのサムネイル、カテゴリタイル、検索結果には不要です。4Kで生成してから縮小するのは無駄です。マーケットプレイスの仕様表は通常、独自の最小サイズを公表しているので、下限はモデルの最大値ではなくマーケットプレイスの要件で設定します。それ以外すべて、内部レビュー用レンダリング、A/Bテストバリエーション、プレースホルダー画像は標準ティアに属します。

リクエスト単位ではなくアセットのライフサイクルを計画する

4K画像は大きなファイルです。フル解像度の原図を保存して配信時に小さなバリエーションを派生させるのか、それとも各配置先に必要なティアだけを保存するのかを事前に決めます。原図を保存して派生画像を生成するほうが通常は理解しやすく、モデルを再度呼び出さずに配信サイズを再レンダリングできます。それに基づいてストレージとCDNの送信量を見積もり、アセット命名に解像度ティアをエンコードして、下流サービスが誤って4K原図をサムネイルスロットに流し込まないようにします。

高解像度は遅めにレンダリングする

プロンプトのイテレーション中は標準解像度でレンダリングします。追従性の問題はどのサイズでも見え、4Kでイテレーションすると診断上の利益なしにサイクルタイムが倍増します。プロンプトのバリアントが承認されてから高解像度に引き上げます。承認されたアセットごとに1回の高解像度レンダリングであり、実験ごとではありません。

商品パイプラインでAPI呼び出しを行う

呼び出し自体は1行のロジックです。作業はそれをプロダクトコードから遠ざけることにあります。4つの責務を担う軽量な内部サービスとして封装します。

バージョン管理されたデータとしてのプロンプトテンプレート

5スロットのテンプレートはアプリケーションの外に、カテゴリをキーとして保存します。サービスは構造化された商品データを受け取り、スロットを埋め、レンダリングを生成したテンプレートバージョンを記録します。テンプレートを編集しても、古いアセットはそれを生成したバージョンまで追跡できます。

明確な入出力を持つ生成関数

サービスはgeneratePackshot(productId, category, options)のようなインターフェースを公開し、生のバイト列ではなくアセット参照を返します。オプションには解像度ティアとテンプレートバージョンが含まれます。HiAPI呼び出しに関するすべて、認証、モデル識別子、リクエスト形式はこの境界の中に存在します。後日モデル文字列を変更しても、別の画像モデルを追加しても、プロダクトコードは変わりません。他のモダリティをHiAPIで扱うチームも同様です。1つの統合パターン、1つの認証情報です。

限られた予算でのリトライ

生成はリモートモデルへのネットワーク呼び出しです。一時的な失敗はリトライしますが、試行回数を制限し、ジッター付きのバックオフを使います。さらに重要なのは、リトライ可能な失敗と決して成功しないリクエストを区別することです。不正な形式のテンプレートはリトライ予算を消費するのではなく、素早く明確に失敗すべきです。アセットに試行回数を記録し、レンダリングが2回目の試行を必要とする頻度を観察します。

予測可能なアセット命名

すでに持っているデータでアセットを命名します。商品ID、カテゴリ、テンプレートバージョン、解像度ティア、短い内容ハッシュです。決定的な名前は冪等性を可能にし、すでにアセットを生成済みのリトライタスクは再生成をスキップでき、特定のSKUに対する各レンダリングの検索も容易になります。

サービスはステートレスに保ちます。タスクをキューに入れ、処理し、アセットを書き込み、イベントを発行します。これにより、カタログ全体のバックフィルも単一商品のリクエストも同じ経路を通ります。

画像が店頭に届く前の品質チェック

生成画像は公開前に順番に各ゲートを通過すべきです。低コストのチェックは自動化し、判断を要する事項は人間のレビューに委ねます。

ゲート1：技術的な有効性

ファイルはデコード可能で、想定形式に適合し、要求された解像度ティア以上でなければなりません。サイズ不足や破損したファイルは保存前に拒否します。このゲートは完全に自動化され、決して静かに失敗してはいけません。

ゲート2：リスティング要件への準拠

対象プラットフォームの実際のルールに基づいて画像をチェックします。最小サイズ、アスペクト比、白背景が要求される場合の背景色の許容差、ファイルサイズ制限などです。マーケットプレイスの仕様をデータとしてエンコードし、仕様変更が設定変更になるようにします。これは最も気まずい失敗を捕まえるゲートです。美しいレンダリングがサイズのためにマーケットプレイスに拒否されることです。

ゲート3：内容の妥当性

ここでの自動化チェックは弱いものですが、安価なヒューリスティックが役立ちます。画像が空白またはほぼ均一でないこと、主要な背景が要求された色に合致すること、主体が画面のかなりの割合を占めることを確認します。失敗は破棄ではなくレビューキューにルーティングします。ヒューリスティックの誤判定はアセットを失うのではなく、人間が一目見るべきものです。

ゲート4：人間による抜き取り検査

テンプレートバージョンとカテゴリごとに一定割合のレンダリングを人間のレビュー対象として抽出し、新しいテンプレートの最初の100%をレビューします。テンプレートが承認されたら、抜き取りに下げます。レビュアーは画像、プロンプト、商品レコードを並べて見るべきです。この文脈がチェックを迅速にします。

4つのゲートすべてを通過したときだけ、アセットは公開可能としてマークされます。ゲート結果はアセットとともに保存し、監査時にチェックを再実行しなくて済むようにします。

今週どこから始めるか

少なくとも十数のSKUを持つカテゴリと、生成画像を許容できる配置先を1つ選びます。そのカテゴリ用に5スロットのテンプレートを書き、HiAPI上のwan2.7-image/text-to-imageを中心に軽量生成サービスを構築し、標準解像度でカテゴリ全体を一通り実行します。ゲートを自動化する前に、出力を手作業で4つのゲートに通します。最初の結果をレビューすることから学べることは、どんなプロンプト理論よりも多いでしょう。

あるテンプレートがカタログ走査で合格し、追従性が許容範囲になったら、そのテンプレートをバージョン管理し、自動化ゲートを接続し、その後でどの配置先が高解像度レンダリングに値するかを決めます。