qwen-image-2.1-pro でEC商品画像を生成する：APIの使い方とプロンプトレシピ

EC商品画像で qwen-image-2.1-pro を選ぶ価値がある理由

EC画像の仕事が単一の作業で済むことはほとんどありません。新SKUのカタログ撮影、マーケットプレイスの商品ページ用の切り抜き、ランディングページ用のライフスタイル画像、さらにプロモーション用のコーナーバッジ付きバナー——これらをたいてい同じ週に納品する必要があります。qwen-image-2.1-pro を評価する価値があるのは、同じ商品データからこれらすべてを生み出すワークフローにおいて、生成・既存アセットの編集・透過PNG出力・画像上の文字描画を、専用ツールの寄せ集めに頼らず一つのモデルでこなせる点です。

作業量の大部分は3種類のタスク形態がカバーします：

• 透過切り抜き —— 商品が透過背景上にきれいに分離され、CMSの任意の枠にそのまま配置できます。
• シーン合成 —— 商品が説得力のあるライフスタイルやスタジオ環境に配置され、テキスト記述と参照画像から生成されます。
• 文字入りレイアウト —— ラベル、バッジ、バナー。文字は読みやすく、正しい位置にある必要があります。

スタジオの代替にならない領域：厳格なブランドライティングが求められるメインビジュアルや、商品の幾何学的形状が規制の対象となるアセット（規制対象のパッケージなど）。生成はカバレッジを広げ反復を速める手段と捉え、人間による承認ゲートは残してください——これが本ガイドの後半で扱うレビューフローの役割です。

早い段階で判断すべき実際の理由はプロンプトの設計にあります。同じモデルが切り抜き・シーン・文字レイアウトを担うと最初から分かっていれば、リクエストのたびに場当たり的にプロンプトを書くのではなく、バージョン管理された少数のプロンプトテンプレートを用意できます。この判断は初期コストがかからず、後の作り直しを防げます。

実行可能なリクエスト：curl と Python

プロンプトを設計する前に、まず画像を1枚取得してください。HiAPI上の各モデルのリクエスト形態は共通です：APIキー、モデル名、そしてリクエストボディの入力パラメータです。qwen-image-2.1-pro に必要な最小パラメータはプロンプトで、編集タスク（新規生成ではなく）の場合はさらに編集対象の入力画像が必要です。

curl

curl -X POST "https://api.hiapi.ai/v1/images/generations" \
  -H "Authorization: Bearer $HIAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen-image-2.1-pro",
    "prompt": "マットブラックのセラミック製コーヒーカップのスタジオ商品写真、4分の3ビュー、左側からの柔らかい拡散キーライト、淡いグレーのシームレス背景にわずかな反射、文字なし",
    "size": "1024x1024"
  }'

Python requests

import os
import requests

resp = requests.post(
    "https://api.hiapi.ai/v1/images/generations",
    headers={
        "Authorization": f"Bearer {os.environ['HIAPI_API_KEY']}",
        "Content-Type": "application/json",
    },
    json={
        "model": "qwen-image-2.1-pro",
        "prompt": "マットブラックのセラミック製コーヒーカップのスタジオ商品写真、"
                  "4分の3ビュー、左側からの柔らかい拡散キーライト、"
                  "淡いグレーのシームレス背景にわずかな反射、文字なし",
        "size": "1024x1024",
    },
    timeout=120,
)
resp.raise_for_status()
print(resp.json())

この段階で身につけておきたい習慣が2つあります。第一に、APIキーは環境変数から読み込み、決してハードコードしないこと——すぐにバッチ処理から実行することになります。第二に、ログ記録時にレスポンスボディ全体を残すこと。エンドポイントが返す使用量フィールドも含めます。これは後に「承認済みアセット1枚あたりのコスト」を推測ではなく測定するための根拠になります。

まず上記のような汎用プロンプトで1回リクエストを実行してください。画像が取得でき、レスポンス構造が下流のコードの想定と合っていることを確認します。その後でレシピに進みましょう——プロンプト設計は時間のかかる作業であり、途中でパイプラインの問題に気づきたくはないはずです。

透過PNGと商品シーンのプロンプトレシピ

場当たり的なプロンプトはぶれやすいものです。カタログチームは、明示的な変数スロットを持つ少数のテンプレートを維持し、APIを呼び出すコードと一緒にリポジトリでバージョン管理し、SKUごとにスロットだけを差し替えることで一貫した結果を得ています。

レシピ1：透過切り抜き

{product_name}の商品切り抜き、{distinguishing_detail}、透過背景に完全に分離。
{view_angle}ビュー、商品は中央にあり全体が収まり、周囲に少し余白がある。
柔らかく均一なスタジオライティング、背景に硬い影を落とさず、商品の真下にのみわずかな接地影を残す。
フォトリアル、シャープなエッジ、文字なし、小道具なし、背景要素なし。

スロット：{product_name}（「マットブラックのセラミック製コーヒーカップ」）、{distinguishing_detail}（「見える縁の厚みと小さなハンドル」）、{view_angle}（「4分の3」、「正面」、「真上」）。透過の条項と「背景に影を落とさない」条項はそのまま残してください。この2行が切り抜きタスクの大部分を担っています。

レシピ2：ライフスタイルシーン

{product_name}を{scene_description}に配置したライフスタイル商品写真。
商品が主役：ピントはシャープ、比率は正確、{brand_color_note}。
{lighting_note}。浅い被写界深度、背景は柔らかくぼかす。
自然でエディトリアルなスタイル。文字なし、ロゴなし、背景にブランドマークは見えない。

スロット：{scene_description}（「リネンのナプキンと朝日の差し込む窓がある、明るくミニマルなキッチンカウンター」）、{brand_color_note}（「色は変更せず、色かぶりも加えない」）、{lighting_note}（「右側からの暖かい指向性のある朝の光」）。

レシピ3：スタジオメインビジュアル

{product_name}のスタジオ商品写真、{view_angle}ビュー。
{background_description}。キーライトは{key_light_direction}から、柔らかいフィルライト、反射は制御。
フォトリアル、素材と表面の質感を豊かに描写。文字なし。

テンプレートライブラリを健全に保つルールが2つあります。スクリプト内でテンプレートを直接書き換えないこと——テンプレートファイルを編集し、バージョン番号を上げて再生成します。そして、承認済みアセットがどのレシピバージョンから生まれたかを記録すること。これにより、テンプレート変更時に古い承認が有効かどうかを判断できます。

既存の商品画像を編集する

編集リクエストは品質問題が最も多く発生する場所です。曖昧なプロンプトはモデルに商品を修正させるのではなく、商品の周囲を再生成させてしまいます。すべての編集プロンプトを明確に3つの部分に分けてください：

1. 変更するもの —— シーン、背景、ライティング、追加する小道具。
2. 保持するもの —— 商品の形状、比率、ラベルの図柄、素材、色。
3. 避けるもの —— 新しい文字、新しいロゴ、歪んだ幾何形状、重複した部品。

実用的なテンプレート：

この商品写真を編集する。
変更：背景を{new_background}に置き換える；ライティングを{new_lighting}に調整する。
保持：商品の正確な形状、比率、表面素材、およびラベルの図柄を完全にそのまま保つ。
禁止：文字の追加、ロゴの追加、商品の色の変更、幾何形状の改変。
フォトリアルな結果で、連続して撮影した1枚の写真のように見えること。

記入例：{new_background} = 「きれいな暖かいグレーのシームレス背景」、{new_lighting} = 「柔らかいトップ拡散光、商品の後方に柔らかなグラデーション」。

保持の条項は保証ではありません。長い編集——1つのプロンプトで背景置換、ライティング調整、小道具追加を同時に行う——は、モデルが商品自体をずらす余地を増やします。分割して行いましょう：まず背景置換を行い、それをレビューし、承認済みの中間結果に対して後続の編集を行って二次的な変更を加えます。各ステップはレビュアーが実際に判断できる1回の比較になります。

同時に、SKUごとに標準参照画像を1枚保管しておいてください。レビュアーが商品に変化があったか判断に迷ったとき、基準となる真実は参照画像であり、前回の生成結果ではありません。

文字描画とレイアウト制御

画像上の文字は、場当たり的なプロンプトで最も失望しやすい機能です。最終アセットに必ず含める必要のある文字は、引用符で囲み、位置を指定し、制約を加える必要があります。

{product_name}のECバナー。
レイアウト：商品は右3分の1に配置、テキストブロックは左3分の2に配置、余白を十分に確保。
文字：太字のサンセリフ体で「{headline}」をメイン見出しとして正確に描画し、その下に軽いウェイトで「{subline}」を正確に描画する。
スタイル：{color_scheme}、クリーンでモダン、可読性のための高いコントラスト。
画像内の他のいかなる場所にも文字を表示しない。すべての単語は書かれたとおりに正確に綴ること。

各行が重要な理由：

• 引用符で囲んだ文字＋明確な「正確に」という指示は、書き換えや造語を減らします。
• 位置と比率（「右3分の1」、「左3分の2」）は、モデルが見出しの下に商品を埋めてしまうのを防ぎます。
• 「画像内の他のいかなる場所にも文字を表示しない」は、よくある失敗パターンを抑える条項です：隅にもっともらしい埋め草の文字が現れること。
• 短い見出し1つ＋短いサブ見出し1つは、長い文章よりもはるかに信頼できます。レイアウトに文章が必要な場合は、まずその文章を含まない画像を生成し、CMSやデザインツールで文章を組版してください。

バッジやラベル（「New」マーク、サイズ表示）については、メインビジュアルに付け加えるのではなく、それぞれ独立した小さなプロンプトとして扱ってください——引用された単語を1つ含む小さなバッジのプロンプトは、バナー全体よりもレビュー時にずっと検証しやすいものです。承認前に必ずフル解像度で綴りを確認してください。文字の誤りは発見コストが低く、公開後のコストが高いのです。

出力のレビュー：比較と承認のループ

生成されたアセットは人間の目を通さずに店舗へ公開すべきではありません。最もコストが低く信頼できるループは、アセットごとのビフォー・アフター比較です：入力写真（新規生成の場合は仕様説明）を生成出力の隣に置き、プロンプトレシピのバージョンと変数の値を記録します。

小規模チームに適した実行可能なループ：

1. 小さなバッチを生成する——カタログ全体ではなく、SKUごとにいくつかのバリエーション。
2. 並列比較表をレンダリングする：左に元画像、右に候補画像、下にプロンプトを記録。
3. 短く固定されたチェックリストでレビューする：商品の形状が変わっていない、ラベルの図柄が無傷、背景がきれい、文字の綴りが正しい、余白が十分。
4. 各候補を通過または却下とマークし、通過結果を生んだレシピバージョンを記録する。
5. ここで初めて全体に展開し、承認済みレシピを再利用する。承認後にレシピが変更された場合は、再確認するまで既存の承認を暫定的なものとみなす。

チェックリストは短く、毎回まったく同じに保ってください。一貫して使われる4項目のチェックリストは、不均一に運用される長いフォームよりも問題を発見できます。却下された候補も保存してください——あるレシピバージョンがなぜ廃止されたかの証拠になり、次の人が同じ失敗を再発見せずに済みます。

このループはコスト管理の手段でもあります。承認がレシピに紐づいているため、承認済みアセット1枚あたり何回の生成が必要かを計算でき、最も試行を要したテンプレートに対して改善を反復できます。

コスト、レイテンシ、バッチ処理の考慮事項

仮定ではなく、自分の測定値で計画してください。HiAPI上の画像モデルは出力画像単位で課金されるため、支出を支配する変数は「承認済みアセット1枚あたりの試行回数」であり、これはプロンプトの品質とレビューの厳格さに完全に依存します。現在の1枚あたりの価格はウェブサイトの料金ページにあります。数値をコードや予算文書にハードコードしないでください。

合理的な進め方：

• ベースラインを測定する。 承認済みレシピで10SKUを実行し、総生成回数と総承認数を集計して、承認済みアセット1枚あたりの試行回数を導き出します。この比率はどのベンチマークよりも問題を雄弁に示します。
• 単発で反復し、承認後にバッチ化する。 プロンプトの反復は1回に1枚で行います。レシピが承認されたら、適度な並列度と、失敗を黙って再課金せずに記録するリトライ戦略でバッチ処理します。
• レイテンシをスケジューリングパラメータとして扱う。 画像生成はミリ秒ではなく秒単位です。ジョブを非同期で起動し、結果をキューに書き込み、レビュアーがキューから処理するようにして、各呼び出しでブロックしないようにします。
• 単価ではなく比率で予算を立てる。 承認済みアセット1枚あたりの試行回数が手元にあれば、カタログの見積もりは自分の測定値に基づく単純な算術です。

最後の衛生習慣：レシピをバージョン管理し、各リクエストでレシピバージョンを記録してください。たった1フィールドのコストで、「先月このアセットがなぜ違って見えるのか？」を調査から1回のクエリに変えられます。

API経由で切り抜き・シーン・文字レイアウトを実行できる最小限のフローを構築し、プロンプトライブラリをバージョン管理された状態に保ち、何を公開できるかは期待ではなくレビューループに決定させてください。