競合分析はたいていスペック比較表で終わります。競合五件、十数列のパラメータ、どちらが安くどちらが高評価かは一目瞭然。
それで、次は？
スペック表が答えるのは「相手がどうか」です。必要なのは「自分が次に何をするか」で、その間には一段あり、たいてい誰も書き留めません。
成果物はパラメータではなく行動
役に立つ競合シートは、最後の三列がこうなります。
| 観察したこと | 要検証の解釈 | 次の行動 |
|---|---|---|
| 直近三か月の低評価に発熱が繰り返し出る | 放熱設計の問題か、対応機種が説明に無いだけかもしれない | 該当レビュー 20 件を原文で読み直してから改善点を決める |
| 競合三社が車載用途を前面に出している | 未対応のセグメントに対応する可能性 | 車載用途のキーワードと訴求を調査する |
| 値下げと同時期に評価が下がった | 因果とは断定できない | 観察期間を延ばし、別の根拠を補う |
中央の列の言い回しに注目してください。「かもしれない」「断定できない」。 曖昧にしているのではなく、推測を推測として印をつけています。
競合の選定理由は必ず書く
三列目は「選定理由」で、必須です。
誰かに見せるためではなく、三週間後の自分のためです。そのとき「なぜこの五件で、別の五件ではないのか」を知りたくなります。書いていなければ、選び直すしかありません。
再現しやすい順に並べた選定基準：
- 同カテゴリかつ価格帯が重なる — 最も再現しやすく、基礎条件に向く
- 主要検索語の上位結果 — どの語を、いつ見たかを記録すること
- 流入キーワードに実質的な重なりがある — 最も正確だが、先に逆引きが必要
- 経験的にこれが競合だと分かる — 有効。ただし理由を書き出すこと
四番目は逃げではありません。経験ある出品者の直感はよく当たります。ただ「経験による判断」と「30W 急速充電に対応し 25〜35 ドルに収まる唯一の商品」では、後で見返したときの価値がまるで違います。
行を比較可能に保つ
マーケットプレイスと取得日は行ごとに必須です。
同じ ASIN が今日 BSR 940、翌週 1,600 ということはあり、それは衰退を意味しません。セールが一度あっただけかもしれません。自社データが今週で競合データが先月なら、両者の差は何にも帰属できません。
最低条件は、一回分の全行が同じ取得日であること。 無理なら二回に分け、そう明記してください。
再確認日の列があるのもそのためです。競合分析は繰り返す作業であり、各回が前回と揃っている必要があります。
三つの層は組み合わせて初めて意味を持つ
項目は三層に分かれ、それぞれ一つの問いに答えます。
商品層 — 価格、BSR、月間販売数、評価、評価数、出品者数、バリエーション数：どれだけ売れているか。
キーワード層 — 共通キーワード数、自社に無い語、相手が自然順位で上位の語：流入がどこから来て、何が欠けているか。
レビュー層 — 主な不満：相手の購入者が何に不満か。
個別には数字にすぎません。組み合わせると指し示すものが出ます。
競合 B の販売数は自社の約 2.4 倍、共通キーワードは 126 語しかなく、相手が上位を取っていて自社が全く扱っていない語が 38 ある。そして低評価はスタンドの不安定さに集中している。
この三つは一つの行動を示します。その 38 語を押さえ、同時に商品ページでスタンドの安定性を訴求する。 相手が叩かれているのがまさにそこだからです。どの層も単体ではここに辿り着きません。
観察・解釈・行動を三列に分ける理由
一列に詰めるのが典型的な失敗です。だいたいこう書かれます。
競合は低評価が多い。品質が悪いからだ。だから品質を訴求すべきだ。
「低評価が多い」は観察、「品質が悪い」は推測、「品質を訴求」は行動で、三つが因果のように溶接されています。しかし低評価が多いのは販売数が多く母数が大きいからかもしれず、品質問題は特定ロットだけかもしれず、具体的な差分の無い「品質訴求」は何も言っていないに等しい。
三列に分ければ、中央が推測だと認めざるを得ず、行動も具体的に書かざるを得ません。「次の行動」の欄に「品質を訴求」と書くと、書いた本人にも薄く見えるからです。
シートから API へ切り替える時期
競合五件・月次なら手作業で十分です。商品ページとレビュー欄を読むこと自体が、どの項目にも入らないものを拾います。
競合二十件・週次では崩れます。速度ではなく、取得日が揃わなくなるからで、日付の揃わないシートでは推移を語れません。
三行目に各列の API フィールドがあります。
| 列 | API フィールド |
|---|---|
| 競合 ASIN、タイトル、ブランド | asin、title、brand |
| 価格、BSR、月間販売数 | price、bsr、units |
| 評価、評価数 | rating、ratings |
| 出品者数、バリエーション数 | sellers、variations |
| 共通キーワード・欠けている語 | items.keyword の積集合と差集合 |
| 相手が上位の自然検索語 | items.rankPosition |
| 主な不満 | レビューの content と star |
選定理由・要検証の解釈・次の行動に対応フィールドはありません。API は転記を代行できますが、判断は代行できません。他がすべて自動化された後も、この三列は人が埋めます。
収集と逆引きを Agent に任せたいなら、Cursor や Codex で競合分析を行う に再現可能な対話スクリプトがあります。あちらは「データをどう揃えるか」、こちらは「揃えた後どうするか」です。
よくある質問
競合は何件が適切ですか。 三〜七件。三件未満ではパターンが見えず、七件を超えると判断せずにセルを埋め始めます。
販売数推定のばらつきは結論に影響しますか。 思うより影響しません。競合分析が読むのは相対関係です。自社の二倍か、同じ桁か。全行が同じ提供元・同じ日なら、相対関係は安定します。
不満の分類を主観的にしないには。 先に条件を固定します。直近三か月、星 1〜2 のみ、20 件以上。そのうえで、重要だと感じた順ではなく、繰り返し出る名詞で分類します。
更新頻度は。 再確認日の列に従います。価格と BSR は動きが速く週次向き、レビューの主題とキーワード構造は遅く月次で十分です。