コラム
商品画像のサイズ・規定・更新経路が9モールで全部違った — モールを増やすと増えるもの
楽天は4:3で1600×1200、Amazonはメイン画像が純白背景必須、TEMUは3:4の縦長で既存商品は差し替えができない。商品画像のサイズと規定はモールごとに違います。14の販路を運営する中小ECが、同じ1枚の写真を全モールへ出すまでに踏んだ仕様差を、サイズ・更新経路・カラー別対応の3つの軸で整理しました。
出店を1つ増やせば、売上も1つぶん増える。そう思っていました。
実際にやってみると、増えたのは売上だけではありませんでした。同じ商品を、モールの数だけ別の仕様で作り直す作業が増えました。しかもそれは、出店を決めた時点の見積りには一行も入っていません。
私たちは現在、モールと卸を合わせて14の販路で商品を販売しています。楽天市場、Amazon、Yahoo!ショッピング、Shopify、Qoo10、TEMU、Shopeeといった名前を並べると横展開が進んでいるように見えますが、その裏側で毎回引っかかっていたのが商品画像でした。
サイズが違う。規定が違う。そして一番効いたのが、更新のしかたが違うことでした。
この記事は、自社倉庫で撮った1枚の写真を全モールに出すまでに何が起きたかの記録です。ECモールの出店を増やそうとしている方に、見積りに入れておいたほうがいい項目として読んでいただければと思います。
出店を1つ増やせば、売上も1つぶん増えると思っていた
新しいモールに出店するとき、私たちが事前に比較していたのは月額料金と手数料と集客力でした。どのモールのユーザー数が多いか、販売手数料が何%か、初期費用はいくらか。ECモールの出店比較記事に載っている項目は、だいたいこの3つです。
その比較で抜け落ちるのが、商品を1つ登録するのに何をしなければならないかという部分です。
出店の翌週、商品が並び始めて分かりました。増えたのは「店」であって「売れる状態の商品ページ」ではありません。商品データは一元管理システムから流し込めても、画像だけは毎回ひとつずつ引っかかる。ここが想定外でした。
モールを1つ増やすと、増えるのは「出す・見せる・測る」の3種類の仕様差
14販路を運営してみて、モール間で揃わないものは大きく3つに分けられると分かりました。
- 出す — 商品を登録する経路。CSVかAPIか管理画面か
- 見せる — 画像とテキストの仕様。サイズ、枚数、規定
- 測る — 実績データの粒度。日次で取れるか月次までか
このうち「出す」は、一元管理システムを入れればある程度まで吸収できます。「測る」は、粒度が粗いモールでも我慢すれば運用は回ります（この話はモールごとの検索ロジックを自社商品で検証した記事に書きました）。
吸収が効かなかったのが「見せる」でした。 画像は最後まで、モールの数だけ作り分けが必要でした。
商品画像のサイズは、モールごとに違う
まずサイズと形式です。「商品画像のサイズ」でモール名ごとに検索されているのは、要するに全部違うからです。実際に私たちが合わせている仕様を挙げます。
楽天の商品画像サイズ
R-Cabinet（楽天の画像管理機能）にアップロードする画像は、1600×1200ピクセル・縦横比4:3・1枚2MB以下を基準にしています。商品ページの画像枠は最大20枠で、うち数枠は共通バナーが占めます。
意外な制約として、ファイル名の文字数にも上限があります。品番と色名と用途を全部つないだ長いファイル名にすると、アップロードの段階で弾かれます。
Amazonの商品画像サイズ
Amazonは推奨が1024×1536ピクセル・縦横比2:3で、楽天と縦横が逆です。そして最大の違いが、メイン画像は純白背景でなければ登録できないという点です。
これは推奨ではなく仕様で、マネキンやトルソーが写っている画像をメインに指定するとエラーコードが返り、登録自体が通りません。私たちは背景除去の処理を挟んで白抜き画像を別途作っています。
一方で、サブ画像の枠はトルソー撮影のままで通ります。 メイン1枚＋サブ8枚という構成で、規定が厳しいのはメインの1枚だけでした。ここを勘違いすると、全カットを白抜きにする不要な作業が発生します。
TEMUの商品画像サイズ
TEMUは900×1200ピクセル・縦横比3:4の縦長が必須です。比率が違うとエラーになります。
さらに運用上大きいのが、画像を設定できるのが新規登録のときだけという点です。あとから差し替えても反映されません。つまりTEMUだけは、登録の時点で画像を決め切るという前提で作業を組む必要があります。他のモールのように「とりあえず出して後で良い画像に差し替える」が使えません。
その他のモールの制約
残りは、細かいけれど確実に作業を止めるタイプの制約です。
- マルイ — CSVで渡す画像は1MB未満、しかも拡張子が小文字でないと通りません。
.JPGは弾かれます。加えて管理画面の稼働時間が9:00〜21:00で、夜間の作業ができません - au PAY マーケット — gifとjpgとjpegのみ。PNGとWebPが通りません。画像URLは255バイト以内
- Yahoo!ショッピング — 1枚2MB以下、画像枠は最大21
- ロコンド — JPG形式、縦横600ピクセル以上（推奨1100ピクセル）。反映に最大24時間
- Shopee — 色（バリエーション）ごとに画像を持てるかわりに、アップロードするZIPが3MB上限
結論として私たちは、楽天基準の1600×1200・4:3を共通マスタとして先に作り、各モールの要件に合わせて縮小・クロップする運用に落ち着きました。一番大きく作っておけば縮小はできますが、逆はできないからです。
ただしこの共通マスタ方式にも例外があります。TEMUは3:4なので作り直し、Shopeeは色数ぶんファイルを分ける必要があります。1枚作れば全部に出せる、とはなりませんでした。
もっと違ったのは「サイズ」ではなく「更新できるかどうか」だった
サイズの違いは、一度表にまとめれば片付きます。実際に運用を圧迫したのは別のところでした。
その画像を、どうやってモールに届けるかです。
経路が4種類ある
現時点で、私たちが画像を実際に差し替えられる経路を確立しているのは9モールです。残りは未確立のまま残っています。そしてその9モールの経路が、4種類に分かれます。
- API直接 — Amazon、楽天、Shopify
- FTPでZIPを送る — au PAY マーケット（画像を送ってから、別途CSVで商品に紐付ける2段階）
- CSVに画像URLを書く — Yahoo!ショッピング、SHOPLIST、マルイ
- 管理画面にファイルをアップロードする — ロコンド
同じ「画像を1枚足す」という作業でも、書くコードも待ち時間もまったく別物になります。au PAY マーケットは画像の取り込みバッチが約6分、そこからCSVでの紐付けにさらに2〜3分。SHOPLISTは画像のミラー化に約6分、商品への紐付けにさらに10〜15分。ロコンドは反映まで最大24時間。「投入した」と「見えている」のあいだに、モールごとに違う時差があります。
残る5つの販路は、画像の更新経路が社内で確立していません。BtoB卸のSUPER DELIVERYは再出品時に旧品番の画像を引き継ぐ設計なので画像は触らない運用にしていますし、Qoo10とメルカリShopsは経路の調査自体が途中です。14販路のうち、画像を能動的に更新できるのは9というのが正直な現状です。
同じCSVでも「空欄」の意味が真逆になる
一番危なかったのはここです。
CSVで商品情報を更新するとき、空欄のセルをどう解釈するかがモールによって逆でした。
- au PAY マーケット — 書かなかった列は更新されない（据え置き）
- Yahoo!ショッピング — 空欄で送ると、その項目がクリアされる
前者の感覚で後者を触ると、触ったつもりのない項目が消えます。 私たちはこれを踏まえて、Yahoo!ショッピングに送るCSVは必要な列だけを抜き出した形にせず、全列を保持したまま該当セルだけ書き換える方式に統一しました。
モールを1つ増やすというのは、こういう逆向きのルールをもう1本、頭の中に置くことでもあります。
色ごとに画像を出し分けられるモール、分けられないモール
アパレルなので、1つの商品に色が5つも6つもあります。「赤を選んだら赤の写真が出る」という当たり前を実現できるかどうかも、モールによって違いました。
色ごとに画像を割り当てられるのは、私たちが確認できている範囲でAmazon、マルイ、Shopeeです。Shopifyは機能としては持っていますが、私たちの側の実装が追いついていません。残りは未確認か、そもそも1商品1行の構造で色別の概念がありません。
出し分けができないモールでは、4色を2×2に並べた1枚のコラージュ画像を作って、色名のラベルを焼き込んで対応しています。画像枠が足りない商品でも、1枠で複数色を見せられるためです。
ここで1つ、地味ですが効いた学びがあります。ラベルに焼き込む色名は、見た目ではなく商品マスタの正式名を使うことにしました。実物が薄紫に見えてもマスタ上は「グレー」という商品があり、見た目で書くとお客様が注文画面で選ぶ色名と、画像に書いてある色名が食い違います。
逆に、Amazonではコラージュを使いません。Amazonは色ごとに商品ページが分かれるので、どのページを開いても同じコラージュが出てくると、色選びの助けにならないからです。同じ「色を見せる」という目的でも、モールの構造に合わせて手段が逆になりました。
それでも増やすなら、出店前に確認したい4項目
否定的なことばかり書きましたが、販路を増やすこと自体は有効でした。実際、自社倉庫で撮影した実物写真を、1日で3モール64枚まで展開できるところまでは仕組み化できています。ある商品では7つのモールに一括で画像を投入しました。仕様差は、把握してしまえば作業に落とせます。
問題は、把握する前に出店してしまうことです。私たちが今なら出店前に確認する項目は4つです。
- 画像のサイズ・比率・形式・容量 — 特に縦横比。共通マスタから作れるかどうかが決まります
- 画像の更新経路があるか — 登録できることと、あとから直せることは別問題です。TEMUのように新規登録時にしか設定できない設計だと、運用の組み方が変わります
- CSVの空欄がどう解釈されるか — 据え置きかクリアか。ここを取り違えると、意図しない項目が消えます
- 色ごとに画像を分けられるか — 分けられない場合の見せ方（コラージュ等）を先に決めておく
この4項目は、どのモールの公式ガイドラインにもまとまった形では載っていません。モールごとのヘルプページを4本読んで、自分で表にするしかないというのが実情です。私たちはそれを14販路ぶん、出店した後に作りました。先に作れたら、もっと楽でした。
よくある質問
Q. 商品画像のサイズを全モール共通にできますか？
完全な共通化はできません。縦横比が異なるモール（Amazonは2:3、TEMUは3:4、楽天は4:3）があるためです。ただし、一番大きい仕様で共通マスタを1枚作り、各モール向けに縮小・クロップする方式にすれば、撮影と編集の工数は1回で済みます。
Q. モールを増やすと商品登録の工数は何倍になりますか？
単純な比例にはなりません。商品データ（商品名・価格・在庫）は一元管理システムでかなり吸収できます。比例して増えるのは、画像の作り分けと、モール固有の規定に対応する部分です。私たちの実感では、2店舗目までは倍増に近く、そこから先は共通マスタを作るほど増分が小さくなります。
Q. 商品登録代行に頼むなら、どの部分を頼むべきですか？
判断の要らない繰り返し作業、つまり規定に合わせた画像の変換と登録作業です。逆に、どの画像をメインにするか、色をどう見せるかといった部分は売上に直結するので、社内に残すことをおすすめします。ここを外に出すと、なぜその画像なのかが社内に残りません。
Q. 画像を1枚差し替えると、全モールに反映されるまでどのくらいかかりますか？
モールによって数分から最大24時間まで開きます。取り込みバッチと商品への紐付けが別工程になっているモールもあるため、セール開始に合わせて画像を差し替える場合は、前日までに投入して反映を確認する運用にしています。
販路を増やす前に、仕様差を棚卸ししませんか
私たちは14の販路を運営するなかで、モールごとの画像仕様・更新経路・データ粒度を自社で表にまとめ、社内ツールとして運用しています。この整理は出店してから作りましたが、本来は出店を決める前に作るべきものでした。
出店するモールを増やそうとしている、あるいは増やしたものの運用が追いついていないという場合は、EC運営コンサルティングでこの棚卸しからお手伝いしています。自社で運営しながら踏んだ失敗をそのままお渡しできるのが、私たちの強みです。
商品登録や画像運用の体制づくりについては、お問い合わせからお気軽にご相談ください。
関連記事として、Amazonと楽天、出店するならどっちが先かと、ネットショップ運営を外注せず内製化した話もあわせてどうぞ。
