先週から前半にかけて、Fエラーの系統整理 と、実際にFエラーが出た後の対処 の2本の記事を続けて書きました。書いていて改めて感じたのは、ヤフオク一本足で商売をしていると、自分では防ぎようがない出来事で売上が止まる可能性がある、ということです。
今日はその続きとして、事業者としてヤフオクにどこまで依存するか、どう分散していくか、という実務論を整理します。プラットフォームを攻撃する話ではなく、自社の売上をどう組み立てるか という、あくまで出品者側の視点でまとめています。
予防できない出来事は、思ったより多い
Fエラー記事のリサーチをしていて、共通していた「打つ手がなかった」 パターンを3つ整理しておきます。いずれも 個人の努力で回避できない構造 の話です。
1.共有IPの巻き添え
自宅の回線がマンション一括契約や、モバイルキャリアのCGNAT (Carrier-Grade NAT)経由の場合、隣人や同じIP帯を使う別ユーザーの不審な挙動が、自分のアカウント制限の材料になり得ます。実例では、家族の別端末が古い認証情報でログインし続けた結果F003 (一時制限)が発生した、というケースが繰り返し共有されています。
自分は普通に使っているのに巻き添えを食う。これは環境チェックリストで多少軽減できますが、根本的には自分ではコントロールできない 領域です。
2.大手プラットフォームの経営判断
Yahoo!JAPANは2022年4月6日から欧州 (EEA・スイス・イギリス)からのアクセスを完全に遮断しています。GDPR (EU一般データ保護規則)対応のコストと、欧州からの収益機会を天秤にかけた結果と読める判断で、公式にも告知されています。
これは、大手が採算に応じて地域単位で機能を止める という前例です。個別出品者の意思とは関係なく発生します。
3.手数料構造の変化
ヤフオクは2022年以降、落札手数料の一律10% (税込)化 (プレミアム会員優遇の廃止)や、有料オプションの改訂を続けています。同時にクーポン施策も増えていますが、クーポンの原資は基本的に手数料側で調整されている 構造です。落札者に多少還元されても、出品者から見た実質の受取比率は横ばい〜微減、ということが起きえます。
こうした改訂も、事前告知はありますが、出品者側は基本的に受け入れるか撤退するかしかありません。
3つとも、非があるかどうかの話ではなく、プラットフォームを一つに寄せている以上、こういう出来事は不定期に起きる という前提の話です。
二重出品の壁と、分散の現実的な形
分散を考える時に最初にぶつかるのが、ヤフオクの二重出品禁止ルール です。Yahoo!オークションガイドライン細則のA.出品者の禁止行為3に、次のように明記されています。
同じ商品を、他社のサービスやその他の方法によって、二重に出品すること
つまり、手元に1点しかない商品を、ヤフオクとメルカリに同時に並べることは規約違反にあたります。ここを踏まえずに「とりあえず両方に出そう」 とすると、出品削除や利用制限の対象になり得ます。
このルールを前提にすると、分散の現実的な形は次の3パターンに整理できます。
パターンA: SKU分散
プラットフォームごとに扱う商品を分ける 方法です。ヤフオクは 「オークション向き・値付けが読みにくい・入札で伸びる」 タイプの商品、メルカリは 「即決・比較的低単価・数を捌く」 タイプの商品、自社ECは 「単価が取れる・ブランド世界観が売りになる」 タイプ、といった具合に、商品と場の相性で振り分ける のが基本形です。
同一SKUを跨がなければ二重出品にはあたりません。むしろ場ごとに客層が違うので、分けたほうが1商品あたりの回転が上がることが多いです。
パターンB: 在庫連動
片方で売れた瞬間にもう片方の在庫を落とす仕組み を挟む方法です。ヤフオクストア規約でも、在庫連動できていない状態での二重出品は禁止されていますが、逆にいえば 在庫連動があれば併売の余地があります。
個人事業レベルだと、スプレッドシートで在庫台帳を管理し、各プラットフォームの管理画面を毎日巡回する運用が現実的です。商品数が増えてくると、在庫連動SaaS (月額数千円〜)の導入も選択肢に入ります。
パターンC: 逐次出品
期間ごとに主戦場を切り替える 方法です。まずヤフオクに7日出品して、売れ残ったらメルカリに 移す。それでも売れなければ 自社ECに長期展示する、といった流れ。同時には並べないので、どのプラットフォームの規約にも触れません。
一番低コストで始められますが、出品作業を都度やり直す手間があるので、商品情報のローカル保管 (後述)と組み合わせるのが実務的です。
併用先の候補と特性
メルカリ (メルカリShops含む)
個人C to Cの代表格で、出品数の多さで露出が確保しやすい市場です。匿名配送 (らくらく・ゆうゆう)が標準、手数料は10%でヤフオクと同水準。事業者はメルカリShopsで法人・個人事業主として運用でき、領収書発行や請求書対応の周辺整備も進んでいます。
楽天ラクマ
楽天エコシステム内での回遊が強く、楽天ポイント経済圏の購入層にアクセスできます。手数料は4.5〜10%で商品カテゴリと販売実績で変動。メルカリと客層が重なる部分はありますが、楽天カード・楽天モバイルユーザーの厚みが違います。
Yahoo!フリマ (旧PayPayフリマ)
同じLINEヤフー グループですが、ヤフオクIDとは別IDでの運用が可能で、制度上は独立した口として扱えます。出品自体は無料、落札手数料10%。なお、ヤフオクとの並列については ヤフオク側の二重出品ルールが適用されるため、同一SKUを跨がない扱いが基本です。
自社EC (BASE・STORES・Shopify)
手数料は3〜6%程度と低く、商品ページの構成や導線を自分の裁量で組める場所です。その代わり集客は自分でやる必要があり、SEO・SNS・広告のいずれかで動線を作らないと、単に「出せる場所」があるだけで終わります。中長期でブランド世界観を育てる場所、という位置づけが現実的です。
eBay (海外向け)
手数料はカテゴリ別 (概ね13%前後+販売手数料)、準備の手間は大きいものの、越境ECの購入層にアクセスできます。ドル建て収益が入るとリスク分散として構造的に効きますが、発送・返品対応・言語のハードルは低くありません。主軸が回っている前提での準主軸候補です。
3段構えでインフラを配置する
分散といっても、全部に同じ力を入れるのは現実的ではありません。事業者としての実務では、以下の3段構えでインフラを配置していきます。
主軸 売上の柱を置く場所です。出品数・ノウハウ・在庫の中心をここに集中させます。多くの場合ヤフオク。
準主軸 主軸とは客層・利益率が違う場所を選び、SKUを分けて並列運用します。客層違いは新規顧客獲得に、利益率違いは売上構成の安定化に効きます。メルカリ・ラクマ・自社ECのいずれか1〜2つ。
保険 アカウントを開設して、出品ノウハウは持っておくが、常時稼働はしていない場所です。主軸が突然止まった時に、手元の在庫を短期間で移せる状態を確保しておく、それが目的です。Yahoo!フリマ・自社ECが候補。
保険 は稼働頻度が低くていいのですが、ゼロ稼働だと本番で動けません。月に数件でも定期的に出品して、プラットフォーム側の仕様変更に追従できる状態を維持しておくのがコツです。
プラットフォーム非依存の資産を作る
分散設計と並行して、どのプラットフォームでも通用する資産 を作っておくと、いざ主軸を移す時のコストが大きく下がります。具体的には次の3つです。
1.商品情報のローカル保管
現行の出品をSKU・タイトル・説明文・写真すべて、自分のPCやクラウドにコピーとして持っておきます。これがあると、プラットフォームを移す時に商品ページを新規で作り直さずに済みます。
具体的にはこんな運用で十分です。
- 出品説明文はMarkdownかWordで原稿を持っておく
- 商品写真はオリジナルサイズを分類フォルダで保管
- SKU単位で 販売状態・出品先・仕入原価・売価履歴 をスプレッドシートで管理
移行の物理コストが分散を阻んでいるパターンは多い ので、これは早い段階から始めた方がよい実務です。
2. SNSでのブランド認知
X (旧Twitter)・Instagram・YouTubeなどで、自分の扱う商品ジャンルに特化した発信を続けていると、プラットフォームを跨いでファンが動きます。「あの店の商品なら他プラットフォームでも買う」 という客層が少しでもいると、主軸が止まった時の受け皿になります。
即効性はありません。週1〜2回のペースで1〜2年続けて、少しずつ効果が出てくる資産です。
3.撮影と説明文のノウハウ蓄積
商品写真と商品説明文の質は、どのプラットフォームでも直接売上に影響する 一次スキルです。撮影セットの構築、光の作り方、説明文のテンプレート化 (ここはAucKitの テンプレ機能 やAI説明文生成機能 が使えます)を主軸で磨いておくと、他のプラットフォームに移した時も 同じ品質で立ち上がります。
明日から何を始めるか
一気に全部やろうとすると、主軸のヤフオクが手薄になって本末転倒です。順番はこの3つで十分です。
今週やる
- 出品説明文と写真の原本をPCで保存し始める
- 現状の出品をSKU一覧としてスプレッドシートに書き出す
今月やる
- メルカリかYahoo!フリマに、主軸とは違うジャンルのSKUを 数件試験出品 (SKU分散パターン)
- 自社ECのプラットフォーム (BASE・STORES等)を試しに開設して、触ってみる
今四半期やる
- 準主軸プラットフォームを1つ決めて、SKU分散か在庫連動の形で運用に乗せる
- SNSアカウントの発信ペース (週1〜2回)を仕組み化する
Fエラーで足元が急に不安定になった記憶は、起きた時にはもう遅い分の学習コストです。起きる前にできることは、分散のスタートを切っておくこと。今日、説明文と写真をローカルに保存し始める、それだけでも意味のある一歩になります。