投稿者 投稿日: カテゴリー Amazon
「大口出品の運用限界とは、人が通知を処理しきれなくなる商品数のことです。」
「何SKUまでなら1人で回せますか」という質問を、規模を問わず受けます。答えは商品数そのものでは決まりません。最初に壊れるのは在庫でも受注でもなく、セラーセントラルから飛んでくる通知の処理です。100SKUで届く通知は1日に数件ですが、1,000SKUになると数十件、10,000SKUでは通知を見ることをやめる担当者が出てきます。この記事では、商品数が増えたときに何が先に壊れるのかを段階ごとに分け、人を増やす前に見るべき数字を3つに絞ります。
先に結論を置きます。人を増やす判断は「作業が終わらない」ではなく「通知の未処理が積み上がり始めた」時点で下すのが正解でした。作業は残業で吸収できてしまうため、限界のサインとして遅すぎます。
商品数が増えて最初に壊れるのは在庫ではない
在庫管理は、商品数が増えても比例して重くはなりません。発注点を決めて補充推奨を見る作業は、SKUが10倍になっても手順が10倍にはならないからです。表計算に落とせば一括で処理できます。
比例して重くなるのは、1件ずつ人が読んで判断しなければならない作業です。具体的には次の3つでした。
ひとつ目は、出品情報に対する指摘です。カタログの属性不足、画像の規約違反、商品名の文字数超過。2026年7月27日からは、メディア商品を除く全カテゴリーで商品名がスペース込み75文字以内に変更されており（アクシアルファ）、旧ルールで登録した商品を多く抱える店舗ほど指摘の総量が増えました。
ふたつ目は、購入者からの問い合わせです。件数は商品数ではなく注文数に比例しますが、SKUが増えると「どの商品の話か」を特定する時間が加わります。50商品なら記憶で処理できたものが、500商品では毎回カタログを開くことになる。
みっつ目は、相乗り出品者やカタログ統合にまつわるトラブルです。これは商品数に対して線形ではなく、階段状に増えます。ある水準を超えると、毎週どこかのASINで何かが起きている状態になりました。
現場で繰り返し見るのは、この3つ目を「たまたま今週は運が悪かった」と処理してしまうパターンです。頻度が上がったこと自体がシグナルなのに、単発の事故として扱うと打ち手が遅れます。
出品の初期設計から見直す場合は、Amazonマーケットプレイス出品の攻略に基本の流れをまとめています。
もうひとつ、壊れ方が見えにくい領域があります。価格の逆転です。仕入れ値が上がったのに販売価格を据え置いたままのSKU、クーポンを重ねた結果として利益が消えているSKU。これらは売れ続けるので、通知も警告も出ません。売上は立っているのに粗利が落ちていく状態は、商品数が増えるほど発見が遅れます。
在庫金額の偏りも同じです。SKUが増えると、上位2割の商品に在庫金額の8割が集まる構造になりやすい。残り8割のSKUは、1点ずつは小さいものの、合計すると保管手数料が無視できない額になります。FBAの長期保管手数料が発生し始めてから気づくケースが少なくありません。
この2つは、担当者の能力とは無関係に起きます。人が一覧を眺めて見つけるには件数が多すぎるからです。だからこそ、商品数が増えた店舗ほど「全SKUを機械的に洗う」作業の価値が上がります。
100SKU / 1,000SKU / 10,000SKU で変わる作業の質
段階ごとに、何が変わるのかを分けます。
100SKU前後では、担当者の記憶がシステムとして機能します。どの商品がいつ入荷して、どれが動いていないかを頭で把握できる。この規模では仕組み化のコストのほうが高くつくため、表計算と手作業で十分でした。生成AIを入れるなら、商品ページの文章作成に限定するのが合理的です。
1,000SKU前後で、記憶が追いつかなくなります。ここで起きるのは「見ていない商品」の発生です。売れ筋の上位50商品は毎日見るが、残りの950商品は月に一度も開かない。在庫切れや価格の逆転が、気づかれないまま放置されます。この段階で必要なのは人員ではなく、全SKUを機械的に一覧化して異常だけを抜き出す仕組みです。
10,000SKU規模になると、作業の性質そのものが変わります。個別対応を前提にした運用が破綻し、ルールで一括処理するしかなくなる。ここで人を増やしても、増えた人がそれぞれ別の判断基準で動くため、かえってばらつきが出ます。必要なのは判断基準の文書化と、例外だけを人に回す設計です。
段階ごとに「何が足りないか」が違う点が重要です。100SKUで仕組みを作りすぎると運用されずに形骸化し、10,000SKUで人を足すと基準が割れる。ある食品ジャンルの中規模店舗の事例では、1,200SKUの段階でパート2名を増員したものの、レビュー返信のトーンが3種類に割れてしまい、半年後に定型文の整備からやり直すことになりました。
段階の切り替えには、前触れがあります。
100SKUから1,000SKUへの移行時に最初に出るサインは、「その商品、今いくらだったっけ」という会話です。価格を即答できなくなった時点で、記憶によるシステムは限界を迎えています。ここで表計算の一覧を作っておくと、あとの移行が軽い。
1,000SKUから10,000SKU規模への移行時のサインは、同じ種類の指摘が週に3回以上届くことです。属性不足が毎週出るなら、それは個別の登録ミスではなく、登録手順そのものに欠落があります。1件ずつ直す作業を続けても終わりません。
もうひとつ、規模に関係なく出る危険なサインがあります。担当者が通知メールの受信設定を切ることです。件数が多すぎて通知が意味をなさなくなると、人は見るのをやめます。切った瞬間から、アカウント健全性に関わる通知も届かなくなる。ここは運用ルールで明示的に禁止しておくべき箇所でした。
AIに渡すと上限が上がる作業、上がらない作業
生成AIを入れたときに、1人あたりの処理能力が実際に伸びる作業と、伸びない作業があります。
伸びる作業は、入力が文章で、出力も文章のものです。商品説明文の作成、箇条書きの書き換え、レビュー返信の下書き、問い合わせへの回答案、通知文の読解と仕分け。これらは件数が10倍になっても、AIに渡す手間はほとんど変わりません。
伸びない作業は、次の3種類でした。
第1に、物理的な作業です。検品、梱包、撮影。ここはAIでは動きません。SKUが増えたときの律速がここにあるなら、外部倉庫やFBAへの切り替えが先です。
第2に、店舗固有の制約に依存する判断です。発注ロット、支払いサイト、倉庫の保管上限。AIは制約を知らないので、判断を渡しても精度が出ません。
第3に、責任が発生する意思決定です。値下げの可否、返金の可否、出品の取り下げ。ここを渡すと、あとで理由を説明できなくなります。
つまり、生成AIで上限が上がるのは「読む・書く」の総量であって、「決める」の総量ではありません。SKUが増えて苦しい理由が読み書きの量なら、AIで2〜3倍は伸びます。決めることの量なら、AIを入れても変わりません。まず自店の苦しさがどちらなのかを切り分けてください。
日次の具体的な回し方はセラーセントラルの毎日の作業をAIに渡す順番で画面別に整理しています。
判断を渡してはいけない理由を、もう少し具体的に書きます。
値下げの可否を例に取ります。AIに「このSKUは値下げすべきか」と聞くと、競合価格と販売数から「値下げを推奨します」と返ってきます。ところが実際の判断材料はそこではありません。この商品が定番なのか季節品なのか、次回入荷の原価が上がる見込みか、まとめ買いの大口見積もりが進行中か。これらは社内にしかない情報で、プロンプトに書かない限りAIは知りません。そして全部を毎回書くくらいなら、人が決めたほうが速い。
返金の可否も同じです。同じ内容のクレームでも、リピート購入の多い顧客か初回購入かで対応を変える店舗は珍しくありません。その基準は経営判断であり、外に説明できる形で持っておく必要があります。AIが決めた、では説明になりません。
逆に言えば、判断材料を作る作業は全部渡してよいということです。競合価格の推移をまとめる、過去の類似クレームを探す、返信案を3通り作る。ここまでをAIにやらせて、最後の1手だけ人が置く。この分担が、規模が増えても崩れない形でした。
人を増やす前に見る3つの数字
増員の判断材料を3つに絞ります。いずれもセラーセントラルと手元の記録から取れます。
1つ目は、通知の未処理件数の推移です。アカウント健全性と出品情報に関する指摘のうち、1週間以上手をつけていないものの件数を毎週数えます。この数が3週連続で増えていたら、処理能力を超えています。件数そのものより、傾きを見てください。
2つ目は、問い合わせの初回返信までの時間です。中央値ではなく、最も遅かった1件の時間を記録します。平均は残業で隠れますが、最悪値は隠れません。24時間を超える日が週に2回出たら黄信号です。
3つ目は、直近30日で一度も開かれていないSKUの割合です。在庫レポートと販売実績を突き合わせれば出せます。この割合が6割を超えると、価格の逆転や在庫切れが検知されないまま放置されている可能性が高い。
この3つがそろって悪化しているなら増員の判断は妥当です。1つだけが悪化しているなら、その工程だけを切り出して仕組みで解く方が安上がりでした。
数字を取るためのプロンプトを3本置きます。
以下はAmazonの在庫・販売データです。
直近30日で販売が0件のSKUを抽出し、放置リスクを判定してください。
データ：
{SKU／商品名／現在庫／直近30日販売数／現在価格／登録日 のCSVを貼り付け}
出力：
1. 直近30日の販売が0件のSKU一覧と、その構成比（％）
2. うち在庫を保有しているSKU（保管コストが発生し続けているもの）
3. 登録から90日以上経過して一度も売れていないSKU
4. 人が確認すべき項目（価格・画像・商品名のどれを先に見るべきか）
※出品を取り下げるべきという結論は書かないこと
以下はセラーセントラルの通知一覧です。
未処理のまま滞留しているものを、滞留日数順に整理してください。
通知一覧：
{通知の件名・受信日・ステータス を貼り付け}
出力：
1. 滞留7日以上のもの（件名／受信日／滞留日数）
2. 滞留しているものに共通する種類（属性不足、画像、商品名など）
3. 種類ごとの件数と、まとめて処理できるかどうかの判定
4. まとめて処理できる場合の手順（セラーセントラルのどの画面を使うか）
以下は直近{期間}の問い合わせ記録です。
人員計画の材料として集計してください。
記録：
{受信日時／初回返信日時／商品名／問い合わせ種別 を貼り付け}
出力：
1. 初回返信までの時間の中央値と最大値
2. 24時間を超えた件数と、その曜日・時間帯の偏り
3. 問い合わせ種別の構成比
4. 上位3種別のうち、商品ページの記載で防げる可能性があるもの
3つの数字を取るとき、頻度は週1回で十分です。毎日測ると数字が揺れて傾きが見えません。曜日を固定して、同じ時間に同じ手順で取る。5分で終わります。
記録先はどこでも構いませんが、1枚の表にまとめてください。別々のファイルに散らすと、3つがそろって悪化しているのか、1つだけなのかが判断できなくなります。判断の材料として使うには、横並びで見えることが条件です。
数字が悪化したときの読み方も決めておきます。未処理件数だけが増えているなら、処理の手順に詰まりがある。初回返信時間だけが伸びているなら、特定の曜日に人が足りていない。開かれていないSKUの割合だけが上がっているなら、商品数を増やしすぎている。3つのうちどれが動いたかで、打つ手が変わります。
増員より先に効く3つの打ち手
人を増やす前に試す価値がある手を挙げます。
定型文の整備が最も費用対効果に優れていました。問い合わせ種別の上位3つに対して、店舗としての回答の型を作る。AIに下書きを作らせる場合も、この型を先に渡すかどうかで出力の安定度が変わります。型がないままAIに書かせると、担当者ごとに補償の度合いが違う返信が出ていきます。
商品ページへの先回りも効きます。問い合わせの上位が「サイズ」「付属品」「納期」なら、その3点を商品の特徴の1項目目と2項目目に移す。ある家電ジャンルの店舗では、この移動だけで月間の問い合わせが3割弱減りました。減った分がそのまま人の余力になります。
見ないSKUの整理は後回しにされがちですが、効果が大きい。直近90日で1件も売れていないSKUを一覧にして、在庫を持っているものだけ処分の判断をする。SKU数が減ると、通知の総量も比例して減ります。
やってはいけないのは、苦しいからという理由だけで出品数を増やすことです。SKUを増やせば売上が増えるのは事実ですが、通知と問い合わせも同じ比率で増えます。処理能力の限界が近い状態で商品数を足すと、指標が悪化してアカウント健全性に響きます。注文不良率は1%未満、キャンセル率は2.5%未満、出荷遅延率は4%未満が維持基準とされており（株式会社そばに）、ここに触れると増やした売上ごと失いかねません。
失敗しやすい進め方も挙げておきます。
ツールを先に契約するのが典型です。在庫管理ツール、価格改定ツール、レビュー管理ツール。どれも有用ですが、律速がどこかを特定する前に入れると、使われないまま月額だけが積み上がります。3つの数字を2週間測ってから選んでも遅くありません。
担当者を分業させすぎるのも事故のもとでした。在庫担当、CS担当、広告担当と分けると、商品ページの改善が誰の仕事でもなくなります。問い合わせの内容を商品ページに反映する作業は、部門をまたぐため最も落ちやすい。この1本だけは担当を明示しておいてください。
一気に整理しようとするのも続きません。売れていないSKUの棚卸しは、全件を一度にやると数日がかりになり、途中で止まります。毎週30分、在庫金額の大きい順に20件ずつ見る形にすると、3か月で一巡しました。
費用と工数の目安
生成AIの月額は、ChatGPT Plusが20米ドル、Claude Proが20米ドル、Google AI Proが20米ドルの水準です。1,000SKU規模であれば、担当者1名分の契約から始めて問題ありません。
パート1名を増員する場合の人件費と比べると、桁が2つ違います。読み書きの量が律速になっている店舗なら、先にAIを試すほうが合理的です。ただし物理作業が律速なら、AIに払う20米ドルは1円も効きません。3つの数字で切り分けてから判断してください。
モデルの選び方も触れておきます。2026年9月時点で、OpenAIはGPT-6 Astraを最上位に置き、AnthropicはClaude Fable 5.1、GoogleはGemini 3.8 Flashと推論向けのGemini 3.1 Proを並べています。集計や仕分けのような定型処理は応答の速い下位モデルで足り、判断の材料を作らせるときだけ上位モデルに切り替える。この使い分けで月額を増やさずに処理量を伸ばせます。
規模別に、どこにお金をかけるか
同じ予算でも、規模によって効く使い道が違います。
100SKU前後であれば、お金をかける先は商品ページの質です。写真と文章に投資したほうが、運用効率化より売上に直結します。生成AIの月額20米ドルは、商品説明文と箇条書きの作成に使い切って構いません。運用ツールはまだ要りません。
1,000SKU前後では、全SKUを一覧化する仕組みに投資します。高価な在庫管理システムでなくても、セラーセントラルからCSVを書き出して表計算で突き合わせるだけで足ります。ここに月10分の手間をかけると、見ていないSKUの発生を止められます。人を増やすのはこの仕組みを作ってからです。
10,000SKU規模では、判断基準の文書化にコストをかけます。値下げの基準、返金の基準、出品取り下げの基準。これを1枚にまとめて全員が同じ判断をできる状態にするほうが、人を1名増やすより効果が大きい。基準がないまま増員すると、判断のばらつきがクレームとして返ってきます。
どの規模でも共通して効くのは、記録を残すことでした。何を、いつ、どういう理由で決めたか。これが残っていると、担当者が変わっても運用が続きます。残っていない店舗では、引き継ぎのたびに基準が作り直されていました。
これから変わりそうなこと
商品数の上限という問いは、今後2つの方向から緩みます。
ひとつは、通知処理の自動化です。ブラウザを操作するAIエージェントが実用段階に近づいており、指摘の分類と定型修正は任せられる範囲に入ってきます。ただし任せられるのは、判断を含まない作業として切り分け済みのものだけです。今のうちに「どの通知は機械的に直せるか」を文書化しておくと、そのまま設計図になります。
もうひとつは、購買側のAIです。商品ページの文章を読んで購入者の質問に答える仕組みが定着すると、問い合わせの一部は商品ページで吸収されます。ここで参照されるのは装飾された宣伝文ではなく、仕様と使用シーンが具体的に書かれた文章でした。問い合わせを減らす目的で商品ページを整える作業は、そのままAI対策にもなります。
一方で、緩まないものもあります。物理作業と、責任を伴う意思決定です。ここが律速になっている店舗は、商品数の上限がAIでは動きません。倉庫かFBAか、人の権限設計か。解くべき場所が違います。
よくある質問
1人で回せる上限は結局いくつですか。
商品数では決まりません。ただし目安を挙げるなら、読み書きの作業をAIに寄せた状態で、専任1名なら1,000〜1,500SKUが現場感覚の上限でした。物理作業を自社で持っている場合はこれより大幅に下がります。
大口出品と小口出品のどちらを選ぶべきですか。
月間の販売数が49個を超えるなら大口出品が有利です。大口出品の月額は4,900円（税抜）で、小口出品は1商品あたり100円の基本成約料がかかります。商品数の話とは別の軸なので、販売個数だけで判断してください。
SKUを増やすと指標は必ず悪化しますか。
必ずではありません。悪化するのは、処理能力が限界に近い状態で増やしたときです。通知の未処理が積み上がっていない段階であれば、SKUを増やしても指標は動きませんでした。増やす前に3つの数字を確認してください。
AIに在庫の発注を任せてもよいですか。
推奨しません。発注は資金繰り・リードタイム・最低ロットの関数で、これらは店舗ごとに違います。AIに任せてよいのは異常の検知までで、数量の決定は人が行ってください。
外注に出すべきタイミングはありますか。
物理作業が律速になっていて、かつ自社倉庫の稼働が上限に近い場合です。読み書きが律速なら、外注よりAIのほうが安く早い。切り分けを先にしてください。
通知を全部処理しなくてもよいのでは。
種類によります。アカウント健全性の主要指標に関わるものと、知的財産権の申し立ては当日対応の対象です。出品情報の軽微な指摘は週次でまとめて構いません。分類せずに全部を同じ強さで扱うと、時間が足りなくなります。
在庫を持たない出品を混ぜてもよいですか。
受注生産やドロップシッピングを混ぜると、SKU数の割に在庫金額を抑えられます。ただし出荷リードタイムが延びるため、出荷遅延率の管理は厳しくなります。在庫型と混在させる場合は、リードタイムの設定を実態に合わせて分けてください。
セール期だけ担当を増やす運用は有効ですか。
有効でした。通知と問い合わせはセール期に跳ねるため、常時の人員をそこに合わせると平常時が過剰になります。ただし短期の応援に判断を伴う作業を渡すと基準が割れるので、渡すのは定型処理に限ってください。
在庫レポートをAIに貼るとき、列は絞るべきですか。
絞ってください。セラーセントラルのCSVはそのまま貼ると列が多すぎて、AIが的外れな集計をします。SKU、商品名、現在庫、直近の販売数、価格の5〜6列に減らしてから貼ると、出力の精度が明確に上がります。
まとめ
商品数の上限は、在庫でも受注でもなく、通知と問い合わせの処理能力で決まります。生成AIで伸びるのは読み書きの総量であり、決めることの総量ではありません。
今週やることは1つです。未処理のまま1週間以上放置している通知の件数を数えてください。その数が先週より増えているなら、商品数を増やすタイミングではありません。
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
著者：齋藤竹紘（株式会社オルセル 編集長／5,000社以上のEC支援実績／書籍3冊）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
