ホームブログTracking APIとShipping API：あなたのEコマーススタックに必要なのはどちら（それとも両方）？

Tracking APIとShipping API：あなたのEコマーススタックに必要なのはどちら（それとも両方）？

17TRACK

配送APIは、ECシステムで配送を作成し、配送ラベルを生成する必要がある場合に使用します。追跡APIは、発送後の荷物を追跡し、配送業者からの更新情報を業務運用や顧客向けの有用な情報に変換する必要がある場合に使用します。ソフトウェアで配送の作成と購入後の可視化を管理する必要がある場合は、両方の機能が必要です。ただし、必ずしも2社のプロバイダーや2つの別個の連携が必要になるわけではありません。

ECシステムにおける追跡APIと配送APIの比較

この判断を行うのは、フルフィルメントアーキテクチャの責任者です。通常は、エンジニアリングチームと連携するEC運用責任者が該当します。まず、自社のストア、倉庫、またはフルフィルメントパートナーがすでに処理している内容を確認してください。別のAPIを追加する目的は、すでに機能しているワークフローを重複させることではなく、特定の不足を補うことです。

追跡APIと配送APIの違いとは？

両者の違いは、製品カテゴリー間の厳格な境界ではなく、それぞれのAPIが担う役割にあります。配送プラットフォームに追跡エンドポイントが含まれる場合もあれば、追跡サービスが通知や顧客向けの配送更新機能を提供する場合もあります。製品名だけに頼らず、文書化されたエンドポイントとイベントの動作を評価してください。

判断項目追跡API配送API
主な役割配送状況と追跡イベントを取得または受信する。配送を作成し、ラベルや関連する配送書類を取得する。
一般的な入力追跡番号、配送業者識別子、および追加で必要となる配送情報。発送者と受取人の情報、荷物情報、サービスの選択、および該当する通関データ。
一般的な出力配送状況、イベント履歴、その他利用可能な配送情報。配送識別子、ラベル、対応書類。
主なワークフロー配送状況の可視化、例外処理、購入後の更新。倉庫からの発送と出荷準備。
想定してはいけないこと追跡アクセスに、ラベル作成や配送業者への集荷・出荷予約が含まれること。ラベル作成に、必要な追跡情報の詳細度や通知制御が含まれること。

配送業者のドキュメントは、この違いを示しています。FedExは、配送作成についてShip API documentationで、追跡機能についてtracking API documentationで説明しています。これらは異なる技術的責任の例であり、特定の配送業者の選択を推奨するものではありません。

配送を作成することと、その移動を把握することは同じではない

配送作成が成功したというレスポンスは、配送リクエストが処理されたことをソフトウェアに伝えるものです。配送業者が実際に荷物を受け取ったことを示すものではありません。同様に、追跡履歴に移動情報が表示される前に追跡番号が存在する場合もあります。

したがって、注文管理システムでは、ラベル作成、倉庫からの引き渡し、配送業者による受領、配達を区別する必要があります。これらすべてを単一の「発送済み」イベントとして扱うと、顧客への通知が早すぎたり、実際には倉庫を出ていない荷物が見落とされたりする可能性があります。

現在のボトルネックを解消する機能を選ぶ

発送が不足している場合は配送APIを選ぶ

自社アプリケーションで注文データを配送に変換する必要がある場合、配送APIが適切な出発点です。たとえば、倉庫チームが配送業者のポータルに住所を手入力している場合や、カスタム注文管理システムでラベルを生成できない場合が該当します。

連携を選ぶ前に、実際の発送ワークフローを定義してください。配送の作成だけが必要ですか。それとも、料金の取得、キャンセル、集荷依頼、通関書類、締め処理も必要ですか。これらの機能は別々のAPIである場合や、配送業者によって異なる場合、追加のアカウント権限が必要な場合があります。「配送API」と表示された製品に、すべての配送操作が含まれるとは限らないため、注意してください。

単独の解決策としては適さない例：ラベル作成は連携できるものの、カスタマーサービスチームが配送業者の各Webサイトを個別に確認しなければならない連携。発送の問題は解決できますが、配送状況の可視化はほとんど改善されない可能性があります。

配送作成がすでに機能している場合は追跡APIを選ぶ

倉庫管理システム、フルフィルメントパートナー、マーケットプレイス、または既存の配送連携によってラベルがすでに作成されている一方、配送情報が分散している場合は、追跡APIがより直接的な選択肢です。

この状況でラベル作成のワークフローを置き換えると、中心的な問題を解決できないまま移行作業が増える可能性があります。代わりに、上流で生成された追跡番号を、注文管理システム、サポートツール、顧客コミュニケーションで利用できる可視化レイヤーに接続してください。

このカテゴリーでは、17TRACK Tracking APIが関連する連携オプションです。そのofficial API documentationでは、プッシュ通知を含む追跡番号の登録や追跡データのワークフローについて説明しています。これらのワークフローを、必要な配送業者、配送種別、アプリケーションアーキテクチャと照らし合わせて評価してください。これは追跡レイヤーに関する検討であり、このサービスがラベル生成連携の代替になることを示すものではありません。

単独の解決策としては適さない例：ソフトウェアに、発送を担当する配送を作成する手段がまだない状態で追跡APIを導入すること。追跡の可視化では、配送実行機能の不足は解決できません。

アプリケーションが発送と配送状況の可視化を担う場合は両方を使う

システムでラベルを生成し、その後も配送の進捗を確実に把握する必要がある場合は、両方の機能が適しています。1つのプラットフォーム、別々のサービス、または配送業者との連携と追跡レイヤーの組み合わせで実現できます。

配送機能と追跡機能が、不要な妥協を強いることなく文書化された要件を満たす場合は、1つの連携を優先してください。既存の配送ワークフローを維持する価値がある場合や、追跡要件がそのワークフローの提供機能と大きく異なる場合は、別々の連携を検討します。別の追跡プロバイダーが自動的に優れているわけではありません。追加の連携、請求、運用上の管理責任を正当化できる必要があります。

両方のAPIをECシステムに組み込む方法

実用的な設計では、注文、配送、追跡イベントを別々のレコードとして管理します。1つの注文から複数の荷物が発生する場合があり、各荷物には固有の追跡履歴が存在する可能性があります。顧客向けの注文状況は、これらの配送レコードから導出し、配送レコードを上書きしないようにしてください。

  1. 注文がフルフィルメント可能になる。ストアまたは注文管理システムが、必要なフルフィルメントデータを担当する倉庫に送信します。
  2. 配送ワークフローが配送を作成する。アプリケーションは、返された配送識別子、追跡番号、配送業者、サービス、ラベル参照を保存します。
  3. 倉庫が引き渡しを完了する。倉庫による確認と配送業者による受領は、区別可能なイベントとして扱います。
  4. 追跡ワークフローが開始される。選択した連携の要件に従い、アプリケーションが追跡番号を登録または送信します。
  5. 追跡更新がアプリケーションに届く。Webhook、ポーリング、または対応する組み合わせによって、配送レコードが更新されます。
  6. ビジネスルールが次の処理を決定する。関連する条件が満たされた時点で、システムが顧客向けステータスを更新したり、業務タスクを作成したり、メッセージを送信したりします。

たとえば、第三者のフルフィルメント倉庫を利用する販売業者の場合、自社ソフトウェアでは手順4から6だけが必要になることがあります。配送の作成はすでに倉庫が担っているためです。自社で倉庫を運営している販売業者の場合は、完全なフローが必要になる可能性があります。

後続処理ごとに1つの担当システムを割り当てる

両方の連携から追跡更新が提供される場合は、顧客通知とストアに表示する配送状況をどのシステムが管理するかを決めてください。そうしないと、顧客に重複したメッセージが届いたり、相反する配送状況が表示されたりする可能性があります。

調査用に二次データを保持することはできますが、すべての情報源からメールを送信できるようにはしないでください。配送業者からの元のイベントを社内のステータスマッピングと併せて保存し、サポート担当者が、なぜシステムが特定の方法で配送を分類したのかを理解できるようにします。

機能名ではなく運用上の適合性を比較する

実際に利用する配送業者とサービスを確認する

配送業者への対応は、単純なイエスかノーかの問題ではありません。あるサービスが特定の配送業者の追跡に対応していても、その配送業者のラベル作成には対応していない場合があります。ラベル作成は、発送元の国、配送業者アカウントの設定、サービスの利用資格にも左右される可能性があります。

実際の配送ルートに基づいてテストリストを作成してください。国内の荷物、国際配送、輸送パートナー間の引き渡しを含めます。それぞれについて、配送の作成、追跡、またはその両方という必要な操作を確認してください。幅広い対応範囲を示す説明よりも、自社が依存するサービスでのテストに成功することの方が有用です。

イベントの意味とデータの完全性を確認する

追跡については、初回スキャン前、配送例外の発生中、配達試行の失敗後、配達完了時に何が起こるかをテストしてください。タイムスタンプにタイムゾーン情報が含まれているか、配送業者の元の説明が利用可能なままかを確認します。

正規化されたステータスを、すべての配送業者で同一のデータが得られることの保証だと解釈しないでください。配達予定日、位置情報、配達証明情報は、基盤となる配送業者や配送内容によって異なる場合があります。これらの項目が存在しない場合に、インターフェースがどのように動作するかを決めておきます。

双方の障害復旧を確認する

配送では、配送作成中のタイムアウトに特に注意が必要です。アプリケーションがレスポンスを受信できなくても、リクエスト自体は成功している可能性があります。無条件に再試行する前に、プロバイダーが対応する重複防止および照合メカニズムを確認してください。

追跡では、重複通知、遅延イベント、Webhook配信の失敗、一時的なエンドポイント停止をテストしてください。関連するドキュメントで、認証、再試行動作、復旧オプションを確認します。更新を再生しても同じ顧客通知が再度送信されないように、イベント処理を設計してください。

料金モデルを決めつけず、総運用コストを比較する

API料金を送料や配送業者アカウントの料金と分けて考えてください。配送サービスと追跡サービスでは課金単位が異なる場合があり、統合プラットフォームでは機能のパッケージ方法も異なる可能性があります。実際に実行する予定のワークフローについて、見積もりを取得するか、該当するプランを確認してください。

課金対象の利用量がどのように定義されるか、失敗したリクエストがカウントされるか、追跡の再送信がどのように処理されるか、利用量が上限を超えた場合に何が起こるかを確認してください。エンジニアリングの保守、サポート工数、2つの連携の整合性を維持するコストも含めます。配送内容と現在の商用条件が定義されていない状態で、どちらのカテゴリーが安いと断定するのは誤解を招きます。

セキュリティとデータ保持を確認する

配送連携では、受取人の住所や通関情報を処理する場合があります。追跡連携でも、配送識別子や関連する顧客データを処理する可能性があります。必要な項目を確認し、認証情報へのアクセスを必要最小限に制限し、ブラウザ側のコードに秘密情報を含めないでください。

自社の要件に照らして、保持、削除、アクセス制御を確認してください。便利な連携であっても、ワークフローに不要な顧客情報の送信を要求すべきではありません。

導入を決定する前の実践的な検証計画

クイックスタートガイドの成功例だけでなく、代表的な配送を使って概念実証を実施してください。運用、エンジニアリング、カスタマーサポートと受け入れ基準を合意します。

  • 発送：必要なラベル形式を生成し、倉庫設備で利用できることを確認する。
  • 注文マッピング：分割配送、複数荷物、交換配送をテストし、元の履歴が失われないことを確認する。
  • 追跡：自社にとって重要な配送業者とルートについて、実際のイベントシーケンスを確認する。
  • 例外：対応が必要な配送問題が適切なチームに届き、通常とは異なるすべてのスキャンが自動的に失敗扱いされないことを確認する。
  • 復旧：リクエストまたはWebhookエンドポイントを中断し、アプリケーションが不足情報をどのように照合するかを実証する。
  • コミュニケーション：各顧客通知を指定されたシステムだけが送信することを確認する。
  • 商用面の適合性：予想使用量とプロバイダーが確認した課金定義に基づいて料金を見積もる。

判断の原則：不足している機能をまず導入してください。発送がすでに機能している場合は、フルフィルメントを再構築せずに追跡連携を評価します。ラベル作成が不足している場合は、まず配送実行を解決してください。アプリケーションが配送ライフサイクル全体を担う場合は、両方の機能を検証し、統合型と分離型のどちらのアーキテクチャがチームにとって運用しやすいかを選択してください。

FAQ

配送APIには必ず追跡機能が含まれますか？

いいえ。両方の機能を含むサービスもあれば、別々のエンドポイント、製品、プランで提供するサービスもあります。追跡機能が含まれている場合でも、それを購入後の追跡ソリューションとして扱う前に、イベントの詳細度、更新の配信方法、対応配送業者、利用条件を確認してください。

フルフィルメントパートナーが作成したラベルの荷物を追跡できますか？

可能性はあります。アプリケーションには、通常は追跡番号を含み、必要に応じて配送業者識別子や追加の確認情報を含む、追跡連携に必要な識別子が必要です。パートナーが利用する配送業者への対応を確認し、追跡番号が確実に自社システムへ流れるようにしてください。

追跡APIによって配送業者のスキャンが早く行われるようになりますか？

物理的な配送業者のスキャンを発生させることはできません。追跡情報の提供元から利用可能な情報を、アプリケーションが取得、整理、配信するのを支援できます。APIがすべての移動を即時に可視化することを保証すると想定せず、実際の配送で更新動作を評価してください。

両方の機能を使うには、2つのAPIプロバイダーが必要ですか？

いいえ。必要なのは2つの機能であり、必ずしも2社のベンダーではありません。1つのプロバイダーで配送と追跡の要件を満たせる場合は、そのプロバイダーを利用してください。既存のワークフローを維持できる場合や、統合型の選択肢では満たせない特定の要件がある場合は、分けて利用します。

追跡APIで注文管理システムを置き換えられますか？

いいえ。追跡データは注文管理への入力であり、在庫の割り当て、フルフィルメントの判断、支払い処理、注文レコードの代替ではありません。アプリケーションでは、各配送を正しい注文に関連付け、配送イベントが業務ワークフローに与える影響を判断する必要があります。

出典

Loading