公式API vs Webスクレイピング：荷物追跡の裏側

追跡APIを呼び出すと、そのデータはどこかから取得されなければなりません。すべての追跡レスポンスの裏側には、数百もの配送業者からそれぞれ異なる技術的手段で情報を取得する複雑な仕組みがあります。本記事では、主要な2つのアプローチ — 公式APIとWebスクレイピング — の違いと、追跡データの信頼性にどう影響するかを詳しく解説します。

2つのアプローチ

公式キャリアAPI

一部の配送業者は、追跡用の公式REST APIやSOAP APIを提供しています。

あなたのアプリ → WhereParcel API → 配送業者の公式API → 追跡データ

公式APIを提供している主な配送業者：

  • FedEx（OAuth 2.0認証のREST API）
  • UPS（APIキー認証のREST API）
  • DHL（APIキー認証のREST API）
  • 日本郵便（EMS API）

メリット：

  • 高い信頼性と稼働率
  • 構造化された一貫性のあるデータ形式
  • 公式にサポートされ、ドキュメントも整備
  • 高いレートリミット

制約：

  • 各配送業者との契約が必要
  • API利用の審査プロセスが必要な場合が多い
  • 有料のケースもある
  • APIを提供していない業者も多数

Webスクレイピング

世界中の配送業者の多くは、公開APIを提供していません。そのような業者からは、追跡ページをプログラムで閲覧してデータを取得します。

あなたのアプリ → WhereParcel API → 配送業者のWebサイト (HTML) → パース → 追跡データ

スクレイピングが必要な配送業者：

  • 各地域のローカル配送業者
  • 中小規模の物流会社
  • APIプログラムを持たない郵便サービス

メリット：

  • Webサイトさえあればどんな業者にも対応可能
  • 契約や事前交渉が不要
  • 500社以上の配送業者に即座に対応

課題：

  • サイトの変更によりパース処理が破損するリスク
  • IPレート制限やブロック
  • レスポンス時間が遅い
  • データの構造化が困難

アプリケーションへの影響

信頼性の違い

項目公式APIWebスクレイピング
稼働率99.9%以上95〜99%
レスポンス時間200〜500ms1〜5秒
データ一貫性高い中程度
破壊的変更バージョン管理・事前告知あり予告なし
レートリミット公開・明確予測不能

WhereParcelのハイブリッドアプローチ

WhereParcelは、各配送業者に最適な方法を自動的に選択します。

  1. 公式API優先 — 配送業者がAPIを提供している場合は、必ずそちらを使用します
  2. スクレイピングフォールバック — APIのない業者には、分散型スクレイピングインフラで安定したデータを取得します
  3. 統一レスポンス — データソースに関わらず、同じ標準化されたレスポンス形式を返します
{
  "success": true,
  "data": {
    "carrier": "kr.cjlogistics",
    "trackingNumber": "1234567890",
    "status": "in_transit",
    "source": "api",
    "events": [...]
  }
}

sourceフィールドを見れば、データがapiから取得されたのかscrapingから取得されたのかが分かるため、状況に応じた処理が可能です。

インフラの課題

本番環境でスクレイピングインフラを安定運用するには、いくつかの難しい問題を解決する必要があります。

IPローテーション

配送業者のWebサイトは、過剰なリクエストを送信するIPをブロックします。本番グレードのシステムには以下が必要です。

  • 異なるリージョンにまたがる複数のIPプール
  • ブロック検知時の自動ローテーション
  • リクエストを分散させる分散アーキテクチャ

パーシングの耐障害性

配送業者がWebサイトをリニューアルすると、スクレイピングが壊れます。以下の戦略で対処します。

  • 配送業者ごとに複数のパース戦略を用意
  • パース失敗の自動モニタリング
  • パーサー更新の迅速な対応
  • パーサー修正中はキャッシュデータで応答

データ正規化

配送業者ごとにデータの表示方法が異なるため、スクレイピングシステムでは以下を正規化する必要があります。

  • ステータスコード（業者ごとに異なる体系）
  • タイムスタンプ（さまざまな形式とタイムゾーン）
  • 地名（略称、多言語対応）
  • イベントの説明文（翻訳、標準化）

開発者向けベストプラクティス

1. データが即時に返ると想定しない

スクレイピングベースの追跡は、わずかに遅延する場合があります。UIでそれを考慮した設計をしましょう。

// コンテキスト付きのローディング表示
function TrackingStatus({ tracking }) {
  if (tracking.loading) {
    return <div>追跡データを取得中です...数秒お待ちください。</div>;
  }
  return <TrackingTimeline events={tracking.events} />;
}

2. スクレイピング依存の業者にはWebhookを活用する

スクレイピングに依存する配送業者には、Webhookの利用が特に重要です。WhereParcelがスケジュールに従って配送業者のWebサイトを確認し、変更があった場合にのみ通知を送ります。自分でポーリングしてレートリミットを消費する必要がなくなります。

3. 積極的にキャッシュする

スクレイピングはAPI呼び出しよりも遅く、予測しにくいため、追跡結果は自分のシステムでもキャッシュしましょう。

const CACHE_DURATION = {
  api: 5 * 60,      // API取得データは5分
  scraping: 15 * 60, // スクレイピングデータは15分
};

4. グレースフルデグラデーションを実装する

配送業者のWebサイトがダウンしたり、構造が変わったりする場合があります。そのようなケースにも適切に対応しましょう。

if (tracking.status === 'temporarily_unavailable') {
  // 最後に取得したデータと通知を表示
  return (
    <div>
      <TrackingTimeline events={tracking.lastKnownEvents} />
      <Notice>この配送業者のリアルタイム追跡は一時的にご利用いただけません。
        {tracking.lastUpdated}時点の最新情報を表示しています。</Notice>
    </div>
  );
}

今後の展望：APIの拡充とスクレイピングの進化

業界全体として、公式APIを提供する配送業者は徐々に増えています。しかし当面は、グローバルな包括的カバレッジを実現するためにWebスクレイピングが不可欠です。WhereParcelは両方のアプローチに積極的に投資し、500社以上の配送業者にわたって最も信頼性の高い追跡データを提供しています。

特定の配送業者のデータソースに関するご質問は、キャリアドキュメントをご確認いただくか、お問い合わせください。