hiapi API で Nano-Banana-2-Lite を使ってEC商品画像を生成する

ECカタログ向けの商品画像を生成する場合、1枚あたりの経済性はどの1枚の画像よりも重要です。メイン画像1枚に$0.17かかるのは、10枚だけ必要なら問題ありません。しかし、1000 SKUそれぞれに3枚ずつ生成するとなると話はまったく変わります。ここでhiapi上のNano-Banana-2-Liteが埋める穴があります。1枚あたり$0.033、1K解像度、より大きなNano-Bananaモデルと同じ非同期タスクAPIを使用し、最大10枚の参照画像をサポートします。これだけで、定番のEC三点セット——白背景のメイン画像、ライフスタイルシーン画像、プレミアムなダーク系バリエーション画像——をバルク価格でこなすのに十分です。

本ガイドは、以前のNano-Banana ECワークフローの予算階層向けの姉妹記事です。以下の内容——リクエスト、出力、所要時間、コスト——はすべて、執筆時点で実際のAPIを実行した結果に基づいています。

Nano-Banana製品ラインにおけるLiteの位置づけ

以下は執筆時点でhiapiの料金ページと照合して確認した情報です：

モデル	1枚あたりの価格	解像度	参照画像
Nano-Banana-2-Lite	$0.033	1K	image_urlsで最大10枚
nano-banana	$0.05	標準	対応
nano-banana-2	$0.085（1K）/ $0.076（2K）/ $0.114（4K）	最大4K	image_input経由
nano-banana-pro	$0.17（1K/2K）/ $0.2992（4K）	最大4K	image_input経由

商品カタログ向けの判断ルールはシンプルです：

• マーケットプレイスの商品リスト、ロングテールSKU、A/Bバリエーション → Lite。1K（短辺約1024px）では、出力はほとんどのマーケットプレイスがアップロード画像を圧縮した後の基準を満たすか上回ります。
• トップページのバナー、キャンペーンのキービジュアル、印刷物 → 2K/4K出力とより強力なテキストレンダリングが必要ならnano-banana-proにアップグレードしてください。Liteは量産用、Proは重点画像用——両者は補完関係にあり、競合するものではありません。

動作するリクエスト

Nano-Banana-2-Liteはhiapiの統一非同期タスクAPI上で動作します。タスクを送信し、完了までポーリングし、結果をダウンロードします。コードの前に注意点が3つあります：

1. モデルIDは大文字小文字を区別します。 正確にNano-Banana-2-Liteを送信してください——小文字のバリエーションは400 MODEL_UNAVAILABLEを返します。
2. aspect_ratioは列挙値であり、自由形式ではありません。 許可される値：auto、1:1、2:3、3:2、3:4、4:3、4:5、5:4、9:16、16:9、21:9、1:4、4:1、1:8、8:1。resolutionフィールドはありません——Liteは1Kに固定されており、resolutionを送信するとリクエストが拒否されます。
3. 出力URLは署名付きリンクであり、期限切れになります。 タスク成功後すぐにバイト内容をダウンロードしてください。URLではなくファイルを保存してください。

curl -s -X POST https://api.hiapi.ai/v1/tasks \
  -H "Authorization: Bearer $HIAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Nano-Banana-2-Lite",
    "input": {
      "prompt": "Professional e-commerce product photo of a minimalist matte-white wireless earbuds charging case, centered on a seamless pure white background, soft even studio lighting, gentle shadow beneath, crisp edges, catalog-ready hero shot, no text, no logo",
      "aspect_ratio": "1:1"
    }
  }'

レスポンスにはtaskIdが含まれます。statusがsuccessになるまでGET /v1/tasks/{taskId}をポーリングし、その後data.output[0].urlをダウンロードします。私たちの実行では、単一タスクはポーリング時間を含めてエンドツーエンドで約55〜65秒で完了しました。

以下はこの正確なプロンプトの出力——手を加えていないLite生成画像です：

カタログ品質のメイン画像向けプロンプトの書き方

白背景の商品リスト用に、私たちにとって常に効果的なプロンプトパターン：

*Professional e-commerce product photo of [product, materials, colors], centered on a seamless pure white background, soft even studio lighting, subtle natural shadow, crisp focus, marketplace catalog style, no text, no logo*

同じテンプレートで、商品説明とアスペクト比だけを変えた別の2製品（4:5はファッション/ビューティーの縦長カテゴリ向け、4:3はシューズや電子機器向け）：

バッチ生成の実用的な注意点：

• 常に "no text, no logo" で終える。 ほとんどの画像モデルと同様、これがないとLiteはラベルの文字やブランドロゴを勝手に捏造します——実際の商品リストではコンプライアンス上の問題になります。製品に実際のラベルがある場合は、後から合成するか、以下の参照画像パスを使用してください。
• 影を明示的に要求する（"subtle natural shadow"）。これを指定しないと、マーケットプレイスで偽物に見える浮いた切り抜き効果になりがちです。
• 1枚の画像に1製品のみ。 Liteは単一被写体の構図を確実に処理できますが、複数製品を並べると、より大きなモデルが必要になり始めます。

同じ製品を新しいシーンへ：image_urlsワークフロー

本当のECのコツは一貫性にあります。1枚の標準的な製品画像を、製品が画像間で変形することなく、ライフスタイルシーンやプレミアムなシーンに再配置することです。Liteはimage_urlsフィールドで最大10枚の参照画像を受け付けます（注意：より大きなNano-Banana-2モデルではこのフィールドはimage_inputと呼ばれます——この名前変更が主な移植の落とし穴です。詳細はLite APIチュートリアルをご覧ください）。

上のメイン画像を参照として使用し、2種類の再配置を要求しました：

{
  "model": "Nano-Banana-2-Lite",
  "input": {
    "prompt": "Place this exact product on a warm oak wooden desk next to a laptop keyboard and a small green potted plant, soft morning window light from the left, shallow depth of field, cozy home-office lifestyle e-commerce scene, keep the product design, colors and proportions unchanged",
    "aspect_ratio": "4:3",
    "image_urls": ["https://your-cdn.example.com/hero-earbuds.jpg"]
  }
}

両方のバリエーションが返され、充電ケースの比率、蓋の継ぎ目、インジケーターLEDはいずれも損なわれていませんでした。"keep the product design, colors and proportions unchanged"というフレーズはここで大いに役立ちます——すべての参照画像プロンプトに含めてください。参照URLは公開アクセス可能でなければなりません（タスクの途中で期限切れになる署名付きプライベートリンクはタスクを失敗させます）。

Pythonバッチパイプライン

タスクは独立しているため、バッチのスループットはすべてのタスクを一度に送信し、まとめてポーリングすることで得られます——私たちの実行では、5つの同時タスクの完了に要する実時間は1つのタスクとほぼ同じでした。最小限のパイプライン：

import json
import subprocess
import time

API = "https://api.hiapi.ai/v1/tasks"
TOKEN = "sk-..."  # your hiapi API key

def _curl(args):
    out = subprocess.run(["curl", "-s", *args], capture_output=True, text=True, timeout=90)
    return json.loads(out.stdout)

def submit(prompt, aspect_ratio="1:1", image_urls=None):
    inp = {"prompt": prompt, "aspect_ratio": aspect_ratio}
    if image_urls:
        inp["image_urls"] = image_urls
    data = _curl(["-X", "POST", API,
                  "-H", f"Authorization: Bearer {TOKEN}",
                  "-H", "Content-Type: application/json",
                  "-d", json.dumps({"model": "Nano-Banana-2-Lite", "input": inp})])
    return data["data"]["taskId"]

def wait(task_id, timeout_s=600):
    deadline = time.time() + timeout_s
    while time.time() < deadline:
        task = _curl([f"{API}/{task_id}", "-H", f"Authorization: Bearer {TOKEN}"])["data"]
        if task["status"] == "success":
            return task["output"][0]["url"]
        if task["status"] == "fail":
            raise RuntimeError(f"{task_id}: {task.get('error')}")
        time.sleep(5)
    raise TimeoutError(task_id)

HERO_TMPL = ("Professional e-commerce product photo of {product}, centered on a "
             "seamless pure white background, soft even studio lighting, subtle "
             "natural shadow, crisp focus, marketplace catalog style, no text, no logo")

skus = [
    {"id": "SKU-001", "product": "a matte-white wireless earbuds charging case"},
    {"id": "SKU-002", "product": "an amber glass serum bottle with black dropper cap"},
    {"id": "SKU-003", "product": "a white minimalist running sneaker with light gray sole"},
]

# 1) submit everything up front
tasks = {sku["id"]: submit(HERO_TMPL.format(product=sku["product"])) for sku in skus}

# 2) collect results and persist bytes immediately — output URLs expire
for sku_id, task_id in tasks.items():
    url = wait(task_id)
    subprocess.run(["curl", "-s", "-o", f"{sku_id}.jpg", url], timeout=120)
    print(f"{sku_id} done")

本番規模では、実装する価値のある2つのアップグレードがあります：ポーリングの代わりにwebhookコールバックを使用する（タスク作成時にcallback.urlとwhen: "final"を渡す）、そして各taskIdをSKUレコードとともに永続化し、クラッシュしたワーカーが重複して課金せずに復旧できるようにする。どちらもタスクAPIチュートリアルとhiapiドキュメントで紹介されています。

1つの商品カタログの実際のコスト

1枚あたり$0.033で、標準的な3画像処理（メイン画像＋ライフスタイル画像＋ダーク/詳細バリエーション）を採用した場合：

カタログ規模	画像数（×3）	Nano-Banana-2-Lite	同じ作業をnano-banana-proで
100 SKU	300	$9.90	$51.00
500 SKU	1,500	$49.50	$255.00
1,000 SKU	3,000	$99.00	$510.00

合理的なハイブリッド案：カタログ全体をLiteで処理し、その後収益上位20 SKUのみをnano-banana-proで2K/4Kに再撮影してトップページやキャンペーン配信に使用します。100 SKUの例では、これは$9.90＋約$10のPro画像費用です——それでも1日のスタジオ撮影費用のほんの一部にすぎません。

2回目の試行が必要なプロンプト（通常はラベル上の余分なテキスト）のために5〜10%のリトライ余裕を確保し、失敗したタスクはfailとエラーオブジェクトで報告されることを覚えておいてください——品質ゲートに通す価値があるのは成功した生成だけです。

まとめ

Nano-Banana-2-Liteはフラッグシップのキービジュアルパイプラインを置き換えるものではありません——それはPro階層の役割です。しかし、すべてのSKUに提示可能で一貫した画像が必要で、予算が1千枚単位で測られる商品カタログのロングテール部分では、1K解像度・参照画像対応で$0.033という価格は到底覆せません。

APIキーを取得して、Nano-Banana-2-Liteモデルページから始めてください——上記のリクエストはトークンを置き換えればそのまま使用でき、バッチスクリプトはそれを1 SKUから千SKUへと拡張します。