Google Virtual Try-On API の価格：1枚あたり $0.1075

平置きの衣類画像はすでにあるので、そこに着用イメージを1枚追加したい。予算は結果の枚数にそのまま比例します。Google Virtual Try-On は人物写真と衣類画像を受け取り、1回のリクエストごとに試着結果を1枚返します。

TL;DR

1枚あたり$0.1075で、費用はリクエストした枚数に応じて計算されます。予算の計算を見る。現在 num_images は 1 固定です。複数の衣類や複数の人物が必要な場合は、それぞれ個別にリクエストを送信します。モデルはプロンプトを必要とせず、画像の選択がテキストでの説明より直接的です。

単価と予算の計算方法

予定する結果枚数	計算	予算
1	1 × $0.1075	$0.1075
10	10 × $0.1075	$1.075
100	100 × $0.1075	$10.75
1,000	1,000 × $0.1075	$107.50

たとえば、上衣10着にそれぞれ人物3人を組み合わせ、各組み合わせで1枚生成すると合計30枚になり、予算は$3.225です。各組み合わせでもう1枚候補を生成すると総枚数は60枚になり、予算は$6.45です。これは枚数を掛け合わせただけの予算であり、画像を人が選別したり素材を整理したりする作業は含まれていません。

1枚の結果から確認できること

画像をアップロードして試す →。プロンプトは不要です。

この結果では、グレーの背景、ジーンズ、白い靴が保たれ、白いタンクトップが赤白のボーダーTシャツに置き換わっています。服の色、袖丈、全体のコーディネートを確認するのに適していますが、実際のサイズが合うかどうかは商品のサイズ情報と併せて判断する必要があります。事例ページでは人物画像、衣類画像、結果を並べて表示しているため、どこが変化したかを判断しやすくなっています。

まずは初回の範囲を絞る

まず身体の輪郭がはっきりした人物写真を1枚選び、次に衣類の縁が完全に写った平置き画像またはハンガー掛け画像を1枚選びます。初回は num_images: 1 で、襟元、裾、手の付近の変化を確認してから、候補を増やすかどうかを決めます。同じ入力セットを繰り返し送信しても予定枚数は増えるため、予算には候補分も含めて計算します。

インターフェースには prompt も、価格帯を選ぶための解像度や品質の設定もありません。具体的なフィールドと送信例については導入ページを参照してください。

衣類の組み合わせごとに予算を配分する

予算表の枚数は、実際に表示する組み合わせから導くべきです。まず衣類を列挙し、次に各衣類に組み合わせたい人物を列挙します。本当に表示する組み合わせだけを生成リストに入れます。同じ上衣で人物を変える場合は衣類画像を保持して人物画像を置き換え、同じ人物で服を変える場合は人物画像を保持して衣類画像を置き換えます。各組み合わせは個別に送信し、num_images を大きくして一度に済ませることはできません。

先ほどの上衣10着・人物3人の例は、すべての組み合わせを表示する計画です。もし各服に適した人物を1人だけ見つければよいのであれば、まず人物を選んでから送信する組み合わせを計算すべきで、すべての人物を自動的に試す必要はありません。人物と商品の対応関係を事前に確定しておけば、以降の費用が新しい組み合わせによるものか、同じ組み合わせの追加候補によるものかを区別しやすくなります。

候補分の予算は別枠で確保できます。初回は各組み合わせの結果が用途に合っているかを確認します。色やデザインが正しいか、襟元や裾が許容範囲か、人物や靴に許されない変化がないかを見ます。要件を満たした組み合わせは追加を止め、明確な問題がある組み合わせはまず入力を変えるべきか判断します。全バッチで候補を増やす場合と、少数の組み合わせだけ画像を追加する場合とでは計画が異なります。追加リクエストも1枚あたりの価格で計算されるため、1回の選別の予算をそのまま納品可能な画像枚数と見なすことはできません。

パラメータと課金の境界

1回の試着には人物画像と衣類画像が必要で、2枚の入力が共同で1枚の結果を生成します。1枚 $0.1075 は結果の枚数に対応するもので、2枚の入力それぞれに課金されるわけではありません。現在 num_images は 1 のみ許可されており、prompt、品質、解像度のフィールドで価格を切り替える方法はありません。

ここでの計算は、正常に送信されたリクエストを計画するためのものです。公開されている価格資料には、失敗したタスク、送信タイムアウト、重複リクエストの完全な精算・返金ルールが示されていないため、これらの状況をあらかじめ無料として計算しないでください。送信が taskId を返した場合は、引き続きそのタスクを照会します。ブラウザの待機が終了したりネットワークが切断されたりしても、それだけでサーバー側にタスクが作成されていないと判断することはできません。結果を待つために送信を繰り返さないことで、予算リストとタスクリストの対応を保てます。

送信前に済ませるべき画像選定作業

人物画像は、服を置き換える領域がはっきり見える必要があります。衣類画像は、襟元、袖、裾を完全に示している必要があります。商品画像自体で袖口が切れている場合、候補を繰り返し生成しても信頼できる商品の根拠を補うことはできません。袖丈を結果から推測するより、完全な画像を先に探す方が商品表示に適しています。正面であること、身体の輪郭がはっきりしていること、背景がきれいであることは画像選定の推奨事項であり、インターフェースのチェックで効果を保証できる条件ではありません。

変化してはいけない領域も事前に書き出しておくべきです。たとえば上衣だけを見せる場合、ズボンと靴は保持すべきコーディネートに属するかもしれませんが、ワンピースの事例では靴が変化しています。用途上、アクセサリーを厳密に保持する必要があるなら、画像を1枚ずつ人が確認する時間を確保する必要があります。API の予算には、商品画像の整理、人物の肖像の確認、結果の修正といった人手作業は含まれません。正常に返された画像でも、商品の細部が要件を満たさず使えないことがあります。

納品前に、採用した結果を対応する2枚の入力と一緒に保存し、採用理由を記録します。そうすれば、今後人物や衣類を追加するときに、すでに確定した画像選定基準をそのまま使えます。実際のサイズ、生地の厚さ、着心地の確認が主な目的であれば、商品データや実際の試着情報が依然として必要であり、候補の枚数を増やしてもこれらの情報の代わりにはなりません。

よくある質問

一度に複数枚をリクエストできますか？

現在 num_images で使用できる値は 1 で、1回のリクエストで1枚です。複数の候補が必要な場合は、個別にタスクを送信します。

価格はアップロードした画像の枚数で計算されますか？

リクエストした結果の枚数で計算されます。人物画像と衣類画像は、同じ試着に必要な2枚の入力画像です。

プロンプトがないと使用に影響しますか？

いいえ。このモデルは人物画像と衣類画像を入力とし、プロンプトのフィールドは提供されていません。

結果をサイズの測定として使えますか？

結果は着用時の見た目を確認するためのものです。サイズの判断には商品の寸法と実際の試着情報が別途必要です。

続けて読む

API 導入 · 事例と画像選定 · Google Virtual Try-On