大規模ECカタログ向けAI商品画像自動化ガイド

一般的なカタログの大半であれば対応可能です。ただし、プロジェクトの成否を分ける決定的な注意点が1つあります。AIは1枚の元画像から、スタジオ撮影、ゴーストマネキン、アパレルの着用写真、ライフスタイルシーンなどを安定して生成でき、スタジオを予約するよりもはるかに低コストで運用できます。しかしAIは、出力された画像が商品として正しいかを自ら判断することはできません。その判断は依然として人間が行う必要があり、この工数を予算やスケジュールに組み込んでおかないと、後から返品の急増、モールでの出品停止、パイプラインの再構築といった問題に直結します。

したがって、本当に考えるべきは「AIにできるか」ではなく、「カタログのどの部分を完全自動化でき、どの規模の確認キューが発生するか」です。現場では、通常以下のような3つのカテゴリーに分類されます。

• 完全に自動化できるもの：無地背景での定型スタジオ撮影、標準的な形状のアパレルのゴーストマネキン、承認済みカットのカラーバリエーション展開、背景やシーンの差し替え、高解像度化（アップスケール）、サブカット・ディテールカット。
• 要確認で自動化できるもの：サイズ感やドレープ感の自然さが求められるモデル着用画像、微細な質感やロゴがある商品、反射材や透明パーツを含むジュエリー、特殊な構造の衣服。
• 自動化に適さないもの：フラッグシップ商品のメイン（ヒーロー）画像、規約上またはサイズ表記の観点から実物の正確な描写が法的に必要なもの、モール側で実物の無加工写真の提出が義務付けられているカテゴリー。

ベンダーの検討を始める前に、まずは自社のSKUをこの3つに分類してください。ベンダーのデモ動画ではなく、この3区分の比率こそが実際の納期と必要な人員体制を決定づけます。

初めて自動化に取り組むチームの多くは、画像生成ばかりに気を取られ、その前後の工程を見落としがちです。生成自体はコストも低く、並列処理が可能で、仕様も明確なフェーズです。本当のコストはその前後に潜んでいます。

現実的なパイプラインは6つのフェーズで構成されており、「画像の生成」はそのうちの1つに過ぎません。

1. インテイク（取り込み）：DAM、サプライヤーのDropbox、命名規則の揃っていない共有フォルダなど、点在する元画像をシステムが処理できる状態に整える工程。特にサプライヤーから元画像が支給される場合、最も過小評価されがちなボトルネックとなります。
2. 標準化（ノーマライズ）：解像度、余白、背景色、ファイル形式、カラープロファイル、命名規則など、単一の出力仕様を策定して適用する工程。初期段階でドキュメント化し、厳格に統一します。
3. ルーティング（振り分け）：各SKUを適切な処理フローへ割り振る工程。ワンピース、指輪、スニーカーでは必要な処理が異なります。すべてを同じワークフローで処理しようとすると、全体的にクオリティの低い仕上がりになってしまいます。
4. 生成：ベンダーがアピールするパートです。並列処理が可能で高速、ボトルネックになることはほぼありません。
5. レビュー（検品）：策定した基準に沿って人間が仕上がりを確認する工程。後述の品質管理を参照してください。プロジェクトの遅延は主にここで発生します。
6. デリバリー（納品）：承認済みファイルを正しいファイル名とメタデータを付与した上で、PIM、自社ECサイト、各ECモールへ書き戻す工程。

カタログプロジェクトの工数を試算する際は、1、5、6のフェーズを正確に見積もることがプロジェクト成功の鍵です。4の生成工程だけを見て見積もると、大幅なズレが生じることになります。

納期を確定する前に、必ず以下の計算を行ってください。実現可能性に関する疑問のほとんどは、5分程度の計算で明らかになります。

ツール起点ではなく、納期起点で考えます。総画像数を納期までの総秒数で割ることで、パイプラインが維持すべき「秒間処理数（スループット）」が算出されます。次にその数値を、「APIのリクエスト上限」「1画像あたりの生成時間」「自社のレビュー処理能力」という3つの上限値と照らし合わせます。実際の処理速度はこのうち最も低い数値に制限されますが、事前の議論で見落とされがちなのがこのポイントです。

これは実際によくある問い合わせです。営業的なトークではなく現実をお伝えすると、生成AIでも、Phottaでもそれは不可能です。

48時間で5,000万枚を処理するということは、2日間ノンストップで毎秒約290枚を安定して処理し続ける必要があります。一方、PhottaのAPI上限は1アカウントあたり毎分600リクエスト（毎秒10回）であり、1回の生成処理には通常1〜4分かかります。この要件とシステムの性能には3桁もの開きがあり、プランをアップグレードしても埋められる差ではありません。

もし本当に48時間で5,000万枚を処理しなければならないのであれば、それは「画像生成」ではなく、リサイズ、フォーマット変換、トリミング、圧縮といった「決定論的変換（バッチ画像処理）」のタスクです。その作業は、汎用インフラ上で大規模な並列処理を行う専用のメディア処理サービスに適しており、技術的にも確立された分野です。そうしたケースに生成AIを用いるのは適切ではなく、実現可能だと謳うベンダーがあっても、その数値を維持することは困難です。

生成AIが真価を発揮するのは、「まだ存在しない画像」を必要とする、より絞り込まれた用途です。モデル撮影を行っていない服の着用写真、平置き写真からのゴーストマネキン画像、撮影セットのないシーン画像などがこれにあたります。その場合の対象ボリュームは通常数千万枚ではなく、数千〜数万枚規模であり、納期も数時間ではなく数週間単位で計画されます。

実際のプロジェクトを想定した具体例で計算してみましょう。アパレル5,000 SKUのゴーストマネキン画像を、4週間の納期で制作する場合を考えます。

• 生成処理数：5,000件。Phottaの利用コスト（2Kゴーストマネキン画像で1枚あたり4 credits）では、再試行を除いて20,000 creditsとなります。
• 再試行（リトライ）：一定割合で再生成が必要になると想定します。再試行には一律3 creditsかかるため、後から予期せぬコストにならないよう事前に予算化しておきます。再試行率を15%とすると、2,250 creditsが追加されます。
• レート制限：毎分600リクエストの上限に対し、5,000件のリクエスト送信自体は9分未満で完了するため、この規模では送信制限がボトルネックになることはありません。
• 所要時間：ゴーストマネキン画像の生成が1枚あたり1〜3分で、複数バッチを並行して実行した場合、システム処理にかかる実質時間は数週間ではなく数日単位です。
• レビュー（検品）：訓練を受けた担当者が1画像あたり20秒で確認すると、5,000枚のレビューには約28時間の人手による集中作業が必要です（不採用分の再作業時間は含まず）。

どの工程に最も時間がかかるかに注目してください。この規模のプロジェクトでは、人手の確認作業よりもはるかに早くシステムの生成処理が完了します。計画段階で基準にすべきは、ベンダー側の処理速度ではなく「自社のレビュー処理能力」です。

実務上の注意点として、通常の公開プランは月間最大5,000 creditsまでとなっているため、この規模の案件はセルフサーブプランの枠組みを超えます。納期を確定させる前に、あらかじめご相談ください。

トライアルの段階で直面する可能性のある制限事項も含め、率直に説明します。事前に把握しておくことが、結果的にお互いのコスト削減につながるためです。

ゴーストマネキンは一括処理に対応しています。アプリおよびAPI経由の両方でバッチ処理が可能で、バッチ内のすべての衣服に対して同一のオプション設定が一括適用されます。1バッチあたりのアイテム数はプランごとに上限があり、Sellerプランで2着、Brandプランで5着、Studioプランで10着までとなります。また、同時に実行可能なバッチ数はそれぞれ3、4、6バッチに制限されています。

その他の機能はすべて1枚ずつの処理となります。アパレル着用生成、ジュエリー着用生成、アイウェア、フットウェア、ディテール写真、AIマネキン生成は1画像ごとにリクエストを送信します。自社のプログラムから並列処理を行うことは可能で、その場合の制限は機能ごとのバッチ上限ではなく、アカウント全体のレート制限に準拠します。

背景削除は単一画像のみ、かつアプリ内限定の機能です。一括背景削除キューや背景削除用のAPIエンドポイントは用意されていません。既存の数千枚の画像を切り抜くことが主目的である場合は、専用の背景削除サービスの利用をご検討ください。選定方法の詳細は背景削除ガイドをご確認ください。

公開APIは、非同期・ポーリングベースの設計となっています。ジョブを送信すると即座にIDが返却され、処理が完了するまでステータス確認エンドポイントをポーリングします。処理時間は機能により通常1〜4分程度です。開発時はあらかじめポーリング処理を前提として設計してください。

システム設計前に把握しておくべき2つの重要な仕様：

• 現状Webhookには対応していません。ドキュメント上にWebhookの記載がある場合でも、コールバック送信機能は未実装のため、ジョブ完了時のプッシュ通知は行われません。コールバックを待機するのではなく、必ずポーリングを行ってください。
• レート制限はキー単位ではなくアカウント単位です。すべてのプランで一律、固定枠内で毎分600リクエストとなっています。APIキーを複数発行してもスループット上限は増えず、用途別の失効管理としてのみ機能します。ダッシュボードにログインしてチームが行う操作も、この同一の制限枠内でカウントされます。

対応エンドポイントには、アパレル着用、ジュエリー着用、ゴーストマネキン（単一・バッチ）、アイウェアスタジオ、フットウェア、ディテール写真、AIマネキン生成、ポーズ、ブランドラベル、アカウント使用量が含まれます。クレジットはジョブ開始時に差し引かれ、処理が失敗した場合は自動的に返還されるため、失敗した生成に対して無駄な費用が発生することはありません。

導入検討時によく挙げられる注意点が4つあります。

• 出力品質は入力画像の品質に依存します。ライティングが不十分な写真、低解像度、または過度に圧縮された元画像からは、相応の品質の結果しか得られません。取り込み段階での画像品質を改善することが、追加のソフトウェア費用をかけずに全体の仕上がりを高める最も効果的なアプローチです。
• 同一ジョブ内でも画像ごとに使用モデルが切り替わる場合があります。生成処理はフォールバック設計となっており、特定のAIプロバイダーで障害やレート制限が発生した場合、バッチ内の該当画像は待機列にある別のモデルで処理されます。そのため、同じ実行回でも画像間で質感やライティングにわずかな差異が生じる可能性があります。カテゴリページに並べて掲載する際は留意してください。
• アップロード容量は1ファイルあたり10 MBまでです。JPG、PNG、WebPは直接受け付け可能で、HEIC、AVIF、TIFFはアップロード時に自動変換されます。元データがフル解像度のTIFFファイルである場合は、取り込み前にリサイズ・圧縮処理を挟んでください。
• 公開されたSLAや稼働率保証はありません。詳細は後述の調達・契約時の確認事項をご確認ください。

検品（レビュー）は、自動化パイプラインが業務効率化につながるか、単なる負債になるかを分ける極めて重要なフェーズですが、多くの計画で見落とされがちです。以下の2つの原則を守ることで、管理が大幅に容易になります。

生成を開始する前に、明確な判定基準をドキュメント化する。「見た目が良い」といった曖昧な基準では、複数のレビュアーで数千枚の画像をチェックする際に破綻します。商品のシルエットが崩れていないか、実物サンプルの許容色域に収まっているか、ロゴが鮮明で位置が正しいか、等倍（100%ズーム）で輪郭に不自然なノイズがないか、カテゴリの画角規定に合致しているかなど、具体的で短いチェックリストを作成してください。明確な5つの確認項目を定めるほうが、抽象的な指針を並べるよりもはるかに実用的です。

全数検査ではなく、例外ベースで確認する。数千枚を超える規模で全画像を細かく確認するのは現実的ではありません。難易度の低いカテゴリーは一定比率のサンプリング抽出にとどめ、難易度の高いカテゴリーのみ全数検査を行います。もし抽出チェックで不合格率が基準値を超えた場合は、そのまま作業を続けず、一度パイプラインを停止して原因を特定してください。

生成AI特有の不具合はある程度決まったパターンで現れます。以下のポイントをレビュアーに周知することで、検品速度を大幅に向上させることができます。

• シルエットの崩れ（ドリフト）：裾の長さ、袖幅、襟ぐりの形状など、衣服のカッティングが微妙に変化してしまう現象。商品の誤認につながるため、EC運用において最もリスクの高い不具合です。
• 存在しないディテールの生成：実際の商品にはないボタン、縫い目、ステッチ、柄の繰り返しなどが勝手に追加される現象。
• ロゴやテキストの劣化：ブランドロゴや文字がぼやけたり、歪んだり、スペルが崩れたりする現象。必ず等倍表示で確認してください。
• 色味のズレ：特に彩度の高い色やメタリック調の質感において、出力結果が実物サンプルの色合いから外れてしまう現象。
• モデル着用写真における身体の不自然さ：手や指先の描写の乱れは、現在でも最も典型的なAI生成の兆候です。

特に最初の3項目に該当する場合は、全体の見た目がどれほど良くても出品用画像としては差し戻す必要があります。販売していない商品の魅力的な写真は、売上ではなく返品の増加につながるためです。

ユーザーは商品画像を1枚ずつ単体で見るだけでなく、カテゴリーページで一度に何十枚も目にします。そのため、全体の一貫性の欠如は、個々の画像の微細な欠陥以上にクオリティの低さを印象付けてしまいます。一貫性を保つための3つの基本ポイントは以下のとおりです。

• 仕様を一度固定したら、SKUごとに個別の変更を加えない。カテゴリーごとに、背景色、余白、アスペクト比、解像度を1つの値に決定します。例外を認めず、文書化された仕様を一律に適用してください。
• 同じ商品シリーズには同一の仮想モデルを再利用する。着用画像を生成する場合、ベースとなるマネキンを一度作成してシリーズ全体で使い回すことで、体型やスキントーンを均一に保てます。SKUごとに都度新しいモデルを生成すると、統一感が失われます。
• 可能な限り同一カテゴリーは1つのバッチ・同時期に生成する。同じ設定でまとめて生成された画像群は、数週間空けて生成されたものよりもトーンが揃いやすくなります。カテゴリーページに並んだ際、この差は明確に現れます。

また、要件に適した解像度を事前に決めておくことも重要です。高解像度になるほど1画像あたりのコストが上がります（ゴーストマネキンの場合、2Kが4 creditsに対して4Kは5 credits）。一般的なECサイトやモールの掲載用途では2Kで十分なケースが多く、4Kは拡大ズーム表示や印刷用途など必要な場合に絞って利用することをおすすめします。

システム検討の際は、「外部連携に対応」という言葉が具体的に何を指しているかを明確に切り分ける必要があります。

Phottaのカタログ画像生成ツールには、ShopifyやAmazon向けのネイティブアプリは用意されていません。生成された画像を自社ストアの商品データへ自動で直接書き戻すワンクリック連携機能はありません。連携はAPIを介して行い、自社のPIM（商品情報管理システム）やDAM（デジタルアセット管理）を経由して元画像の取得、ジョブの送信、ステータスのポーリング、承認済みファイルの反映を行う構成となります。すでにPIMを運用している企業にとっては、データの一元管理を維持できるため適した構成です。PIMを導入していない場合は、画像納品（デリバリー）フェーズの開発工数をあらかじめ確保しておく必要があります。

なお、PhottaはECサイトに組み込んで使用するバーチャル試着ウィジェットも提供しており、こちらはShopify、WooCommerce、BigCommerce、Wix、Squarespaceに対応しています。ただし、これはエンドユーザーがサイト上で試着体験をするための別プロダクトであり、本記事で解説しているカタログ画像の自動生成パイプラインとは用途が異なります。

モールごとの画像規約はプラットフォームによって異なり、予告なく改定されることがあります。メイン画像に関しては白背景の指定や実物の正確な描写など厳格なルールが設けられているのが一般的ですが、サブ画像やライフスタイル画像は比較的柔軟に認められています。規約内容は変更される可能性があるため、公開前に各モールの最新スタイルガイドをご確認ください。正確性や表記に関する考え方については、AI生成した商品写真の利用規約についてをご参照ください。

ベンダーの正式選定にあたっては、以下の項目を確認することをおすすめします。導入から数か月後に予期せぬ制約に直面するリスクを防ぐため、事前に確認しておくべき重要なポイントです。

• 「一括処理の上限と同時実行数の上限は、書面で提示可能か？」これらの数値を明確に開示できないベンダーには注意が必要です。Phottaの制限値は前述のとおり公開しています。
• 「SLAや稼働率（アップタイム）の保証はあるか？」Phottaでは現在SLAの公開保証は行っていません。契約上の稼働率保証が必須要件である場合は、パイロットテスト開始前にご相談ください。選定基準に合致するかどうかを早期に判断できます。
• 「セキュリティやデータ取り扱いに関するドキュメントはあるか？」Phottaでは現在、セキュリティホワイトペーパー、SOC 2レポート、標準DPA（データ処理契約書）をWeb上で公開していません。調達規定でこれらが必須となる場合は、サービスページに「エンタープライズ対応」と記載されていても事前に確認してください。
• 「生成に失敗した場合のクレジットはどうなるか？」失敗分のクレジットは返還される必要があります。Phottaではジョブが失敗した場合、消費されたクレジットは自動的に返還されます。
• 「条件の厳しい自社の実データでテスト可能か？」信頼できるベンダーであれば問題なく対応します。用意されたデモ画像は品質が良いものを選定しているため、自社カタログの中で最も処理が難しい上位10%の画像でテストすることが実用性を測る唯一の方法です。

自サービスの制限事項を率直に開示するベンダーこそが、実運用において信頼できるパートナーとなります。

パイロットテストの目的は、単なるデモ体験ではなく導入の可否を正しく判断することです。以下の手順で検証を進めてください。

1. ベストな写真ではなく、実際の品質のばらつきを反映した50 SKUを選定する。複雑な構造の服、反射の強いアイテム、元画像の画質がやや粗い商品などもあえて含めます。
2. 生成結果を見る前に、出力仕様と検品チェックリストを策定する。結果を見てから基準を作ると、生成された画像の仕上がりに無意識に合わせてしまいます。
3. 追跡する指標を2つに絞る。「人の手を介さずに承認された割合」と「承認画像1枚あたりにかかった人間の平均確認時間（分）」の2点のみを測定します。導入判断に必要なデータはこの2つに集約されます。
4. 全体の数値へ正確に試算を拡張する。全カタログの規模に数値を掛け合わせ、パイロットで省略したインテイクと納品の工数を加算した上で、ゼロベースではなく既存の画像制作コストと比較します。
5. 全体一括ではなく、カテゴリーごとに導入を判断する。現実的には、カタログの一部のカテゴリーでは大幅な業務効率化が達成され、別のカテゴリーでは従来の手法が適しているという結果になります。これは失敗ではなく、大規模カタログ運用においてはハイブリッド構成が一般的な最適解です。

自社のカタログ規模、商品カテゴリー構成、納期に応じた最適なパイプライン設計については、お問い合わせフォームよりお気軽にご相談ください。適合しないケースも含め、実現可能性を率直にお伝えします。