順位を「毎日同じ条件で」見る：Amazon検索順位の追跡を、なぜ仕組み化したか

「今月ちょっと売上落ちてない？」。この一言が出た時点で、だいたい手遅れです。売上は結果で、結果が動くより先に動いてる数字があります。そのひとつが自然検索順位（広告枠を除いた、通常の検索結果での並び順）です。
この記事では、うちが自社・支援先の商品で毎日見てる「検索順位・価格・BSR（Amazonの売れ筋ランキング順位）」を、なぜ手作業の目視から自動追跡に仕組み化したのか、その判断と設計を、実際に動いてる仕組みの考え方とあわせて書きます。

※ 具体的な商品名・対象キーワード・競合ブランド名・実際の順位やBSRの数値は伏せています。本記事の主題は「何位だったか」ではなく、順位を“どう見るか”という設計の考え方です。記載は当社が実運用している仕組みに基づきます。

1. そもそも、なぜ「検索順位」を見るのか

Amazonの自然検索順位は、「そのキーワードで、自社の商品がどれだけ目に触れているか」の直接の指標です。そして露出が落ちると、売上が落ちるより先に順位が動きます。だから順位は売上の“先行指標”になり、早期警戒に効きます。

順位を見る価値は、3つに整理できます。

① 先に気づける

順位の低下は売上低下の前触れ。「気づいたら赤字」の前に手を打てる。

② 原因を切り分けられる

競合と横並びで見れば「自分が落ちた／市場が動いた／特定競合が攻めてきた」を区別できる。

③ 打ち手につながる

価格・クーポン・広告入札・在庫・ページ改善——どこを動かすかの判断に直結する。

肝は自社単独で見ないことやと思ってます。自社の順位が下がったとき、それが自分のせいなのか、市場全体が動いたのか、特定の競合が値下げやクーポンを仕掛けてきたのかは、競合と同じ画面・同じ日に横並びで並べて初めて分かります。だからうちは「自社1＋競合数社」をワンセットで、同じキーワードで毎日記録してます。

2. 毎日とる7つの数字と、「順位の定義」を固定する話

1つのキーワードについて、各ブランドごとに次の7項目を毎日取得しています。

取得する数字	何が分かるか
① 参考価格	値引き前の基準価格
② 値引き後価格	実際に表示されている売価
③ 値引き率	どれだけ攻めた価格にしているか
④ バッジ	ベストセラー／Amazonおすすめ／セール表示の有無
⑤ クーポン	追加の値引き施策が出ているか
⑥ 自然検索順位	そのキーワードでの“露出”の位置（最重要）
⑦ BSR（ランキング）	実際の“売れ行き”を表すカテゴリ順位

⑥の自然検索順位と⑦のBSRは似て非なるものです。順位は「露出」、BSRは「売れ行き」。両方を並べると「露出はあるのに売れていない（ページや価格に問題）」「売れているのに露出が落ちた（広告や、検索で上位に出すための対策の問題）」といったズレの診断ができます。

ここでいちばん効いたのが、「順位の定義」を最初に固定したことです。Amazonの検索結果には広告（スポンサー）枠が混ざります。これを人の目で除外してると、日によって数え方がブレて、順位が信用できなくなる。うちの仕組みは広告（スポンサー）枠を構造的に必ず除外し、同じ商品の重複も排除して、純粋な自然検索順位だけを数えるようにしてます。

「何位か」より先に「何をもって順位と呼ぶか」を決める。広告を含めるか・重複をどう扱うか・いつ・どこから見るか——この定義が毎回ブレてると、どんなにマメに記録しても比較できません。計測は、定義を固定して初めて意味を持つ。ここは痛い目を見て学びました。

3. 手作業の限界：なぜ自動化を決めたのか

もともとは、人が毎日Amazonを開いて順位を目で確認してました。私もやってましたが、まあ続きません。笑限界はすぐ来ました。

毎日同じ時刻に、欠かさず続けるのが難しい。忙しい日は飛ぶ。

スポンサー枠を人の目で除外すると、数え方が日によってブレる。

「5ブランド × 7項目」の記録・転記が地味に重く、続かない。

担当者依存。その人が休むと止まり、見方も人によって変わる。

そこで、「検索 → 数字を抜き出す → スプレッドシート（表計算シート）に記録 → 前日と比較 → 通知」までを1本の処理に仕組み化しました。1回の実行は2分弱で終わります。狙いは時短そのものより、「毎日・同じ条件・同じ定義」で記録が積み上がることでした。人は「集めて転記する」から降りて、「見て判断する」だけに集中できます。

4. 仕組みの全体図：取得 → 記録 → 通知

全体は3つのまとまりでできています。

① 取得（実ブラウザで人間のように検索）

専用のパソコンが実際のブラウザを自動で操作し、検索ボックスに入力 → スポンサー除外 → 順位・価格・バッジ・クーポンを抽出。商品ページからBSRも取得。

▼

② 記録（スプレッドシートに当日行を追記）

当日の日付行を探し、各ブランドの列に書き込む。通貨・％などの書式も自動で揃える。失敗したときは手元にCSVファイル（表計算ソフトで開けるデータ）で退避。

▼

③ 通知（前日比つきでチャットへ）

直近の推移を表の画像にして、前日比（↑↓）つきメッセージとともにチャットへ自動投稿。朝、見るだけで状況が分かる。

実行は専用のパソコンで毎朝1回。当初はクラウド（インターネット上の他社サーバー）で動かそうとしたんですが、ここで大きな落とし穴にぶつかりました（後述）。記録は分析のために蓄積し、通知は判断のために前日からの変化を出す。「貯める場所」と「気づかせる場所」を分けるのが効きました。

5. 「誤ったデータは流さない」ための門番

自動化でいちばん怖いのは、壊れたデータが、正しい顔をしてチャットに流れることやと思ってます。順位が取れなかった日に「0位」や空欄が共有されたら、見た人が誤った判断をする。そこで、通知の直前に必ず“門番”を置きました。

判定	条件	動き
正常	自社順位が数値で取れている／半数以上のブランドが有効	ランキング用チャンネルへ画像つきで自動投稿
不完全	圏外多発・取得失敗が目立つ	チャンネルには出さず、担当者へ個別に「要確認・手動で再実行を」とメッセージを送る

自動化に「沈黙の失敗」を作らない。取れなかったときに“何も言わずそれっぽい数字を出す”のがいちばん危ないです。正常なら全員に、不完全なら担当者だけにそっと知らせる。この一段があるだけで、自動化されたデータを安心して信じられるようになりました。

6. つまずいて学んだこと

うまくいった話だけ並べても役に立たないので、こけたところも正直に書きます。

海外から見ると、全部「圏外」になった

最初は海外にあるクラウドのサーバーで動かそうとしたところ、検索結果が日本と別物になり順位が取れませんでした。順位は「どこから見るか」で変わる。当たり前なんですけど、動かすまで気づいてませんでした。日本市場を見るなら日本から見なあかんので、国内に置いた専用のパソコンに集約しました。

画像ファイルの上書きで処理が止まった

通知用の画像を毎回同じ名前で出力してたら、ファイルの取り合いが起きて処理が止まりました。日付つきのファイル名に分けて解決。自動化は本体より“周辺の細部”でこける、という典型でした。笑

いちばんの学び：計測条件こそが命

スポンサー除外・重複排除・取得時刻・取得地——この計測条件を固定したことで、初めて日々の小さな変動と前日比を信頼して読めるようになりました。数字を集めることより、同じ条件で集め続けることのほうが、はるかに価値があると思ってます。

7. 他の指標にも使える「定点観測の型」

これはAmazonの順位の話ですけど、考え方は売上・在庫・広告・SNSなど、毎日変わる数字ならだいたい同じやと思ってます。型にしてみます。

「定義」を先に固定してから自動化する

何をその指標と呼ぶか（除外・重複・時刻・取得地）を決め切る。定義がブレると蓄積が無価値になる。

自社単独でなく「競合横並び＋文脈」で取る

価格・セール・クーポンも一緒に記録すれば、変動の“原因”まで読める。

「貯める場所」と「気づかせる場所」を分ける

記録は蓄積・分析用、通知は前日比など“変化”で判断の起点に。

「不完全なデータは流さない」門番を置く

取れた時だけ共有し、壊れた時は人にそっと上げる。沈黙の失敗を作らない。

人は「集める」から降りて「判断する」に集中する

自動化の目的は時短ではなく、人の時間を“考える側”に寄せること。

「順位が落ちた理由が分からない」とき

うちは、Amazon運用を“勘”ではなく“毎日の数字”で回してます。順位・価格・BSRを同じ条件で見える化して、競合と横並びで原因を切り分けるところから一緒にやります。
同じことで困ってる人がいたら、まず何を毎日見るかを決めるところから話しましょう。

LINEで相談する

順位を「毎日同じ条件で」見る ― Amazon検索順位の追跡を、なぜ仕組み化したか