まずスクレイパーが本当に解決することから書きます。そうしないと以降が売り込みに読めてしまうからです。
一回限りで、小規模で、項目が単純な要件なら、自分でスクリプトを書くのがたいてい最短です。 ASIN 100 件のタイトルと価格を一度だけ取る、という話なら、書くのに半日、走らせて 10 分。API を評価して登録して接続するより速い。この場合、自前は正しい選択です。
費用がおかしくなるのは別の場合です。スクリプトが動いたあとで、誰かが「じゃあ毎日回そう」と言う瞬間。
そこから先、これは一回限りの開発ではなく保守が要るデータパイプラインになり、四つの費用が時計を回し始めます。
費用 1：ボット対策は継続投資であって一度きりではない
初版が動いたという事実が持つ情報量は、多くの人が思うより小さいものです。
それが証明しているのは「今日のこのページ構造で、この頻度で、この場所からなら、取得できた」ということだけです。 この四条件のうち自分の制御下にあるのは一つ目だけで、その一つ目も変わります。
本当の支出は安定性の側にあります。昨日まで問題なかったスクリプトが、今日は空配列を返す。エラーは出ず、ただ静かにデータが三分の一減っている。この種の問題にスタックトレースは無く、人が突き合わせるしかありません。しかも発生時刻はランダムで、たいてい平日の日中ではありません。
この費用の形はこうです。開発工数は一回限り、調査工数は周期的で、その周期を決めるのは自分ではない。 予算表から抜け落ちるのは二つ目です。立ち上げ時点ではまだ存在していないからです。
この記事は検知を回避する方法を一切扱いません。実現可能性が相手方の技術的措置を回避できるかどうかに依存する計画なら、調整すべきは計画の範囲であって手法ではありません。
費用 2：項目の定義を自分で決めなければならない
最も過小評価される項目です。費用のように見えないからです。
ページには BSR があります。ページに「月間販売数」はありません。
取得できるのはモデルの入力であって、出力ではありません。 順位から販売数を得るには順位と販売数の換算曲線が必要で、その曲線を当てはめるには実際の販売数が付いた標本が要ります。実売はセラー自身のアカウントの中にしかありません。これは技術的な難しさではなく、その標本が手元に無いという話です。
同じ問題が多くの項目で繰り返されます。
| 一つの項目を取っているつもり | 実際に先に決めるべきこと |
|---|---|
| 価格 | 定価か、セール価格か、クーポン適用後か。出品者ごとに表示が違う |
| BSR | 大カテゴリの順位か小カテゴリの順位か。カテゴリ階層は複数ある |
| 販売数 | ページに無い。採らないか、自分でモデルを作るか |
| 評価数 | 親でまとめた数か、個別の子のものか |
| カテゴリ | パンくずの表示名か、ノード ID か。表示名は変わり、ID は比較的安定 |
どの行も人が決着させるべき定義です。API は定義付きの契約を納品し、スクレイパーはその日ページに表示されていたものを納品します。 同じページを二人が取得して違う数字になり、しかもどちらもコードを間違えていない —— 自前のパイプラインではこれが常態です。
さらに厄介なのは、これらの定義がたいてい書き残されないことです。セレクタを書いた人の頭の中にしかありません。三か月後、その列が何を指すのか誰も説明できなくなります。
事実の項目と推算の項目の境界については、Amazon の販売数データで分かること・分からないことがより詳しく扱っています。
費用 3：コンプライアンスとアカウントのリスク
これは技術的な問題ではないため、エンジニアリング側の評価から抜け落ちがちです。
検討すべきは、プラットフォームの利用規約、データの利用範囲、そしてそれが自社のセラーアカウントとどう関係するかです。リスクを負うのは事業側であってスクリプトを書いた人ではありませんが、立ち上げ時の議論にはエンジニアしかいないことが多い。
実務的な進め方を一つ。着手前に、事業側に「この収集経路がアカウントレベルの問題を起こしたとき誰が負うのか」を明確に答えてもらってください。複雑な答えは要りませんが、誰かが答える必要があります。誰も答えたがらないなら、そのリスクは受け入れられたのではなく先送りされただけです。
費用 4：担当者の離職はデータの停止と同義
前の三つは金と時間で解決できます。これは解決できません。
スクレイパーの本当の知識は、ほとんどコードの中にありません。なぜこのセレクタがこう書かれているのか、どの項目がどのサイトで違うのか、どの失敗を再試行しどれを飛ばすのか、前回の改修をどう直したのか。書いた時点では「自明」だったので、文書には残りません。
書いた人が去った後、次のページ改修が終点になります。 直せないからではなく、直す費用が高すぎて誰も承認しないからです。引き継いだ人は全体のロジックを逆算するところから始めることになり、唯一の仕様書はコードそのものです。
このリスクはチーム規模に反比例します。三人のチームでは、収集層を本当に理解しているのはたいてい一人です。
四つの費用の形
| 一回限り | 周期的 | 予測不能 | |
|---|---|---|---|
| ボット対策 | 初版開発 | 調査と修正 | 改修が来る時期 |
| 項目定義 | 項目を決める | 定義のずれの確認 | ページ構造の変更 |
| コンプライアンス | 一度の評価 | — | 問題が顕在化する時期 |
| 担当者 | — | 引き継ぎと文書化 | 離職の時期 |
この表の要点は三列目です。見積もれる費用は怖くありません。怖いのは予測できない費用です。 サードパーティ API の継続費用は二列目に入ります —— 呼び出し量に従い、計算でき、事業成長に線形に伸びます。自前のパイプラインの主要な費用は三列目に入ります。
これは自前が必ず高いという意味ではありません。高さの種類が違うということです。金額が大きいのではなく、いつ払うことになるか分からない。
それでも自前が成立する場合
判定基準はほぼ一つで足ります。その項目を必要としているのは自分だけか。
- 一般的な需要 → ほぼ確実に既存の API が覆っており、車輪の再発明になる
- 本当に自社固有 → 自前が成立する。他に選択肢が無いため
条件を二つ足すとより安全です。要件が一回限りか低頻度であること、そして項目が単純で定義を決める必要がないこと。三つとも満たすならスクリプトを書く。一つでも欠けるなら、まずカタログを見てください。
API カタログ46 の API を商品・キーワード・市場・流入・商標で分類。必要な項目がすでに覆われているか先に確認できますまだどの道を行くか決まっていないなら、Amazon データ API の選び方が公式 SP-API、サードパーティ API、自前収集の三つで何が取れるかを比較しています。この記事はその比較の「自前収集」の列を展開したものです。
よくある質問
小規模なスクレイピングは割に合いますか。 一回限りで項目が単純なら割に合います。毎日動く定時ジョブになった時点で、この四つの費用が時計を回し始めます。
スクレイピングは API より安いですか。 初期は安く済みます。開発工数だけだからです。調査工数、定義のずれ、担当者リスクを数えると、たいてい安くありません。重要な違いは総額ではなく予測可能性です。
販売数はスクレイピングできますか。 その項目はページにありません。取得できるのは BSR で、BSR から販売数に変換するには曲線が必要、その曲線には実売が付いた標本が必要です。その標本は公開データの中にありません。
両方を併用できますか。 できますし、よくある構成です。一般的な項目は API に通し、自社にしか必要ないロングテールの項目だけ自前で採る。こうすれば自前の部分が十分小さくなり、四つの費用すべてが制御可能な範囲に収まります。