HiAPI API で gpt-image-2/text-to-image を使ってEC商品画像を生成する

EC商品ビジュアル素材にテキストtoイメージを使う理由

商品画像は、商品カタログのパイプラインにおける最大のボトルネックの一つです。1つのSKUには通常、クリーンな一覧用画像、ライフスタイル画像、バナー用のクロップ画像、さらに複数のソーシャルプラットフォーム向けバリアントが必要になります。そしてパッケージが変更されれば、そのすべてを撮り直すか、レタッチし直す必要があります。テキストtoイメージモデルは、開発者チームに、既存データを使ってこれらの枠を埋めるプログラマブルな手段を提供します。

現実的なユースケースと非現実的なユースケースを区別しておく価値があります。

• バリアントの補完。 すでに持っている参考画像をもとに、撮影スタジオでの撮影を各配置枠ごとに手配するのではなく、ライフスタイル、季節、または状況に応じた背景を商品周りに生成します。
• カタログの足場づくり。 リリース初期にドラフト画像を生成し、商品運用チームとマーケティングチームが最終素材の準備を待たずにレイアウトやクロップを確認できるようにします。
• ローカライズとパーソナライズ。 商品説明を固定したまま、プロンプト変数によってシーン、季節、スタイルを差し替えます。
• プレースホルダーとテスト素材。 プレリリース環境向けに決定論的なフィラー画像を生成し、ストアのテンプレートを本物らしいコンテンツでテストできるようにします。

テキストtoイメージが置き換えられないのは、権威ある商品レコードです。生成されたビジュアル素材は、実際の商品には存在しない機能、素材、色、付属品を決して捏造してはいけません。モデルは商品データの上に重ねるレンダリング層として扱うべきであり、商品の事実の情報源ではありません。生成画像が実在しない表面仕上げや部品を示している場合、それは創造的な解釈ではなく欠陥です。

本ガイドの残りの部分はすべてこのフレームワークに基づいています。あなたの商品データと既存の参考写真が引き続き事実の情報源であり、モデルはその周囲にコンテキスト層と構図層を生成します。この境界を設定すれば、API統合の問題はごく単純になります。すなわち、リクエストテンプレートが1つ、SKUごとのプロンプト変数セット、そして検証可能な出力です。

gpt-image-2/text-to-image が HiAPI ワークフローにどう組み込まれるか

HiAPI では、gpt-image-2/text-to-image は単一のモデルエンドポイントであり、他の生成タスクに使うのと同じ統一APIインターフェースの背後に位置しています。個別のベンダー統合、個別の認証情報ストア、モダリティごとに異なるSDKは不要です。アプリケーションが HiAPI にリクエストを送信し、レスポンスで生成画像を受け取ります。

最低限のメンタルモデルは3つの部分で構成されます。

リクエスト

テキストtoイメージのリクエストは、プロンプトと、画面を制御するパラメータを運びます。中でも最も重要なのはアスペクト比です。モデルが期待される出力について持つ認識はすべてプロンプトに由来するため、プロンプトこそが真のインターフェースであり、それをきれいにパラメータ化することがエンジニアリング作業です。

モデル識別子

リクエスト内でモデルを名前で指定します。gpt-image-2/text-to-image です。モデル識別子をハードコードされたリテラルではなく設定値として保持しておけば、呼び出し箇所に触れることなく、後で簡単に差し替えたりA/Bテストしたりできます。

レスポンス

呼び出しは生成された画像データを返します。その扱い方——オブジェクトストレージに書き込む、ワーカープロセスにストリームする、一時URLを返す——はパイプライン次第ですが、統合の形は変わりません。すなわち、リクエストを構築し、送信し、結果を永続化し、メタデータを記録する、という流れです。

コードを書く前に、3つのことを決めておきましょう。プロンプトをどこに置くか（コードベースのあちこちに散らばる文字列連結ではなく、変数付きのテンプレートを使う）、出力をどこに置くか、そして検証ステップをどうするか。3つ目を飛ばしたチームは、最終的に生成画像をすべて手作業でレビューすることになり、自動生成の目的を最初から損なってしまいます。

商品に正確な出力のためのプロンプト設計

一貫したカタログ画像は、一貫したプロンプト構造から生まれます。SKUごとにまったく新しい説明文を書くのではなく、固定スロットを持つテンプレートを定義し、本当に異なる値だけを差し替えます。商品作業でうまく機能する構造は、次の順序で5つの部分から構成されます。

1. 主体

商品が何であるかを平明かつ具体的に示します。カテゴリ、形態、そして商品が実際に備える素材や表面仕上げです。これらの値は手作業で言い換えるのではなく、商品レコードから取得します。これこそがSKU間の比較可能性を保つ鍵です。

2. シーン

商品が置かれる環境を説明します。無地のスタジオ背景、キッチンカウンター、屋外の表面などです。シーンはカタログ全体における差異の大部分の源泉となるべきです。低コストで変更でき、商品を歪めるリスクがないからです。

3. ライティング

光を明確にします。柔らかな拡散昼光、フィルライト付きの指向性スタジオキーライト、暖かな室内光などです。ライティングは知覚品質に大きな影響を与え、カタログ全体で視覚的一貫性を実現するために最も標準化しやすい項目の一つです。

4. 構図

商品が画面内のどこに位置するか、相対的な大きさ、撮影角度を指定します。正面中央、斜め45度のアングル、上面のクローズアップクロップなどです。ここで次のセクションで説明するストアレイアウトの要件をエンコードします。

5. スタイル

レンダリングの意図で締めくくります。クリーンな商用商品写真、ミニマルなエディトリアルスタイル、柔らかなニュートラルトーンなどです。スタイル記述子は短く、画像バッチ内で一貫しているべきです。

いくつかの実用的なルールが、ほとんどの悪い出力を防ぎます。

• 商品にないディテールを追加しない。 ロゴ、余分なボタン、付属品を捏造してはいけません。商品データにないディテールは、プロンプトにも含めるべきではありません。
• 否定項目は明確かつ簡潔に保つ。 「文字のオーバーレイなし、余分な物体なし、人物の反射なし」のほうが、長々とした禁止リストよりも信頼できます。
• テンプレートを固定し、変数を変化させる。 SKUごとにプロンプトの文言が異なれば、デバッグできない理由で出力も変動します。
• テンプレートをバージョン管理する。 テンプレートバージョンを生成された各素材とともに保存し、出力をそれを生み出したプロンプトまで遡れるようにします。

最小テンプレートは次のようになり、角括弧内のスロットは商品データから埋められます。

[商品説明]、[シーン]、[ライティング]、
[構図とアングル]、[スタイル記述子]、
文字のオーバーレイなし、余分な物体なし

ストアレイアウトに合わせたアスペクト比の選択

アスペクト比は配置枠に基づいて選びます。その逆ではありません。正方形画像を生成してからワイドバナーにクロップすれば、構図の制御を失います。モデルは正方形として構図を作り、クロップが残りを決めてしまうからです。目標比率で生成してこそ、プロンプトの構図指示が実際に機能します。

まずストアの画像枠を洗い出し、それから比率を割り当てます。

正方形（1:1）

商品グリッドのタイル、マーケットプレイスの一覧、統一されたカードグリッドレイアウトを使うあらゆる場所でのデフォルトの選択です。中央で正面向きの構図がここでは最適です。画面が対称的であり、遅延読み込みのシーンではクロップが小さくなりがちだからです。

縦長（4:5、2:3）

商品詳細のメイン画像、モバイルファーストのフィード、カタログ風レイアウトでよく見られます。縦長の画面は縦長の商品に余裕を与え、主体の上下に、フロントエンドで商品運用要素を重ねるためのスペースを残します。

横長（16:9、3:2）

カテゴリバナー、ヒーロー枠、メールヘッダー、コレクションカバーなどです。横長の画面は単一の物体よりもシーンに適しています。文脈の中に置かれた商品と片側の余白は、広く空いた画面の中央に置かれた物体よりも読みやすくなります。

縦長・高細（9:16、4:5 ストーリーズ形式）

ストーリーズ形式や縦型プロモーション枠です。ここでの構図は明示的に縦長にすべきです。主体は低めまたは中央に配置し、上部に十分なスペースを残し、横方向に広い要素を含めません。

ワークフロー上の注意点が2つあります。第一に、1枚のマスター画像を各配置枠にサイズ調整してはめ込むのではなく、配置枠ごとに個別に生成します。プロンプトの構図条項は比率に応じて変わるべきであり、それは個別のリクエストを意味します。第二に、各SKUについて標準の正方形または縦長のマスター画像をアーカイブ用およびまだ列挙していない配置枠用に保持し、派生した比率は保存すべき素材ではなく再生成可能な出力として扱います。

配置枠から比率へのマッピングが存在すれば、それはプロンプトテンプレートと一緒に設定に置かれるべきです。商品運用がレイアウトを変えたら、値を1つ変更するだけで、その配置枠の次回生成は新しい画面を使います。コードの変更は不要です。

HiAPI 経由で実用的なテキストtoイメージリクエストを送信する

テンプレートと比率が決まれば、リクエスト自体は機械的なものです。以下のワークフローは、一度構築してSKUごとに再利用するものです。

ステップ1——プロンプトを組み立てる

テンプレートを読み込み、商品レコードから主体スロットを埋め、対象の配置枠の設定からシーン、ライティング、構図、スタイルのスロットを埋めます。テンプレートバージョンと変数値をリクエストとともに記録し、出力を再現可能にします。

ステップ2——画面を設定する

対象の配置枠に対応するアスペクト比を渡します。プロンプトの構図文言と比率は一致しているべきです。16:9画面での「商品を中央に、上部に十分なスペース」という条項は、4:5での同じ条項とは異なる結果を生みます。

ステップ3——リクエストを送信する

HiAPI の認証情報で認証しつつ、HiAPI API を通じて gpt-image-2/text-to-image モデルにテキストtoイメージリクエストを送信します。モデル識別子、比率、プロンプトテンプレートを設定入力として扱い、同じコードパスがすべてのSKUと配置枠に対応できるようにします。

HiAPI 画像生成エンドポイントに POST リクエストを送信する
  model:  gpt-image-2/text-to-image
  prompt: <組み立て済みテンプレート>
  aspect_ratio: <対象配置枠に対応する比率>

これをサービスに組み込む前に、正確なエンドポイントパス、認証ヘッダー形式、パラメータ名については HiAPI のドキュメントを参照してください。これらの詳細が契約であり、ブログ記事からコピーすることこそが統合のずれの始まりです。

ステップ4——レスポンスを処理する

生成された画像を受け取り、すぐに永続化します。バイナリをオブジェクトストレージに書き込み、キー名にSKU、配置枠、テンプレートバージョンをエンコードし、素材テーブルにプロンプトテキスト、比率、モデル、タイムスタンプを含むリクエストメタデータの行を記録します。これをリクエストハンドラ内で、別のタスクとしてではなく行うことで、素材をその出所と一緒に保てます。

ステップ5——出力をゲートする

生成画像がストアに届く前に、レビューステップを通します。少なくとも、商品がレコードと一致しているか、画面が要求された比率か、架空のディテールや文字のアーティファクトがないかを確認します。可能な限り自動化し（比率チェック、基本的な画像健全性チェック）、残りは初期運用期間中は手動レビューキューに回します。

ステップ6——参照を返す

生のレスポンスペイロードではなく、安定したストレージキーまたはURLをストアに渡します。フロントエンドは画像が生成リクエストに由来することを知る必要も気にする必要もなく、他のあらゆるカタログ画像と同じ素材契約を見るべきです。

商品カタログ全体への生成のスケール

動作する1つのリクエストはデモです。カタログパイプラインはキューです。前者から後者への移行は、主に分離性と可観測性にあります。

各SKUを1つのジョブにする

リクエストワークフローを、明確な入力（SKU、配置枠、テンプレートバージョン）と明確な出力（保存された素材キー、ステータス、リクエストメタデータ）を持つジョブとしてラップします。あるSKUのジョブの失敗がバッチ全体をブロックすべきではありません。リトライは安全であるべきです。各実行がパラメータ化されているため、失敗したジョブを再実行すると、謎の重複素材ではなく比較可能な結果が得られます。

プロンプト作成と実行を分離する

プロンプトテンプレートと配置枠から比率へのマッピングは、ワーカーに埋め込まれたコードではなく、バージョン管理されレビューされるデータであるべきです。これにより商品運用チームとマーケティングチームはデプロイなしで文言と構図を反復でき、出力品質が変化したときに同じSKUセットに対してテンプレートバージョンを比較できます。

予算とレートの規律

生成コストはトラフィックとともに増えるため、バッチごとに何件のリクエストを送信するかを追跡し、配置枠を意識的に選びます。すべてのSKUについてすべての比率をデフォルトで生成しないでください。課金は生成エンドポイントの使用量に従い、現在の料金は本ガイドではなく HiAPI アカウントの料金パネルにあります。プロンプトを組み立てて記録するだけで送信しないドライランモードは早めに構築する価値があります。テンプレートの誤りをコストが発生する前に捕捉できます。

生成したものを監査する

リクエストメタデータを各素材に恒久的に添付します。商品運用担当者が、なぜある商品がある配置枠でおかしく見えるのかと尋ねたとき、ログから再構築するのではなく、1回のクエリで正確なプロンプト、比率、テンプレートバージョンを引き出せるようにしたいものです。

受け入れ基準を事前に定義する

大規模生成の前に、「ストアにとって十分に良い」とは何かを明確にします。レコードに対する商品の忠実性、正しい画面、偽の文字がないこと、バッチ内のライティングの一貫性などです。自動化できるチェックをエンコードし、手動レビューキューは恒久的な負担ではなく徐々に縮小するステップとして扱います。

テンプレート、比率マッピング、ジョブラッパーを正しく作れば、カタログ全体へのスケールは再設計作業ではなくスループット作業になります。単一のSKUと単一の配置枠から始め、リクエストワークフローをエンドツーエンドで確認し、それからカタログ全体にジョブを広げてください。