コラム

配送会社の追跡ページをスクレイピングして分かった、自作をすすめない理由

2026.07.09・読了約7分

「追跡ページをスクレイピングすれば自作できるのでは？」— 正解です。最初の1週間は。私たちは配送会社の追跡データを取得・正規化することを本業にしているチームです。この記事では、実際に運用して初めて分かる落とし穴を、ポジショントークを承知のうえで正直に書きます。

最初は簡単に見える

ヤマト運輸や佐川急便の追跡ページはHTMLを返すので、PythonならrequestsとBeautifulSoupで30分もあれば動くものが書けます。

# The 30-minute prototype that works — for now
import requests
from bs4 import BeautifulSoup

html = requests.get(TRACKING_URL, params={"no": "490381075682"}).text
soup = BeautifulSoup(html, "html.parser")
status = soup.select_one(".tracking-status").text  # breaks silently someday

動きます。デモも通ります。問題はここからです。

運用して分かる5つの落とし穴

1. HTMLは予告なく変わる — しかも静かに壊れる

配送会社の追跡ページはAPIではないので、後方互換の義務がありません。クラス名の変更、テーブル構造の入れ替え、文言の微修正 — どれもある日突然きます。最悪なのは例外で落ちるのではなく、セレクタが空を返して「配送情報なし」として静かに壊れるパターンです。気づくのはお客様からの問い合わせです。

2. アクセス制限とボット対策

一定頻度を超えるアクセスは制限されますし、対策は年々強化されます。回避しようとする行為は各社の利用規約に抵触するおそれもあります。業務システムの土台を「いつ止められても文句を言えないもの」の上に建てることになります。

3. ステータス表記のゆれ — 実は正規化が本体

「配達完了」「お届け済み」「投函完了」「調査中」— 同じ意味でも会社ごと・サービスごとに表記が違い、扱うステータスの種類も違います。スクレイパーを書く作業の本体はHTML解析ではなく、この表記のゆれを自社システムの状態にマッピングし続ける運用です。新しい表記は予告なく増えます。

4. 対応会社が増えるたびに線形に増える工数

ヤマトで動いたコードは佐川では動きません。3社対応なら、スクレイパー3つ・監視3つ・表記マッピング3つを別々に保守することになります。EC事業者にとってこれは差別化になりません。

5. 深夜に壊れて、直すのは自分

配送は土日も年末も動きます。追跡ページの変更も、こちらの都合を待ってくれません。「繁忙期の月曜朝、先週分の追跡が全部欠けていた」を経験すると、自作の総所有コストが見えてきます。

それでも自作に向いているケース

公平のために書くと、学習目的、ごく低頻度の自分専用ツール、単発の調査なら自作は良い選択です。壊れても困るのが自分だけなら、スクレイピングは楽しい題材でもあります。ただしその場合も、対象サイトの利用規約とrobots.txtは必ず確認してください。

私たちはそれを本業にした

荷物追跡APIは、上の1〜5をサービスとして肩代わりします。ヤマト運輸・佐川急便・日本郵便の追跡を単一のREST APIで照会でき、ステータスは正規化済みのコード（DELIVERED など）で返ります。HTML変更の追従・表記マッピング・監視は私たちの仕事です。

curl https://api.trackingapi.jp/v1/tracking/trace \
  -H "Authorization: Bearer pk_***:sk_***" \
  -H "Content-Type: application/json" \
  -d '{
    "items": [
      { "courierCode": "yamato", "trackingNumber": "490381075682" },
      { "courierCode": "sagawa", "trackingNumber": "452274774416" }
    ]
  }'

形式不正（INVALID_TRACKING_NUMBER）や準備中の配送会社への照会は課金されません。ポーリングをやめたい場合はWebhookで「変化したときだけ」通知を受け取れます。月3,000件まで無料なので、自作スクレイパーの隣で試してから判断できます。