Tracking APIの料金モデルを解説：コール単位 vs 出荷単位、実際のコストの見積もり方
コール単位のトラッキングAPI料金は課金対象リクエストに対して課金され、配送単位の料金は、登録済みの追跡番号など、定義されたトラッキング単位に対して課金されます。どちらが自動的に安いというわけではありません。実際のコストを見積もるには、同じ出荷量、更新要件、追跡期間、課金ルールを前提に両方のモデルを比較し、プラットフォーム料金、超過料金、統合コストを加算してください。
エンジニアリング、運用、調達の各チームにとって、比較すべきなのは単純なコール単位の価格と配送単位の価格ではありません。自社に必要な配送可視化を提供するための総コストです。リクエスト頻度が低くても、頻繁なポーリングによって高額になる可能性があります。一方、配送単位の料金が低くても、追跡期間や含まれるサービスがワークフローに適合しなければ、誤解を招くことがあります。
各料金モデルが実際に測定するもの
最初のステップは、APIリクエスト、配送登録、追跡更新の3つを区別することです。これらは異なるイベントであり、契約によってそれぞれに異なる課金処理が割り当てられる場合があります。
| 比較項目 | コール単位の料金 | 配送単位の料金 |
|---|---|---|
| 課金基準 | 課金対象として定義されたリクエストまたはリクエスト単位 | 課金対象として定義された配送単位 |
| 主なコスト要因 | アプリケーションが課金対象リクエストを行う頻度 | 課金対象のトラッキング単位が対象範囲に入る、または残る数 |
| 解決すべき課金上の疑問 | どのエンドポイント、レスポンス、バッチ項目がカウントされるか | 1件の配送とは何を指し、追跡はどの期間含まれるか |
| 想定されるコスト要因 | 繰り返しのポーリング、再試行、不要な検索 | 重複登録、複数の荷物、追跡期間の制限 |
| 条件付きで適合しやすいケース | リクエスト量を管理できる低頻度の検索 | 更新が配送料金に含まれる継続的なモニタリング |
コール単位の料金でも、すべてのHTTPリクエストが同じ費用になるとは限らない
見積もりでは、課金対象のエンドポイントとその単位を明確にする必要があります。追跡番号の登録、保存済み結果の取得、更新の要求、サブスクリプションの管理では、異なる扱いになる可能性があります。失敗したリクエストが無料である、または成功したリクエストが常に課金対象であると想定しないでください。
バッチ処理についても明確な定義が必要です。100個の追跡番号を含む1回のリクエストが、1リクエスト、100トラッキング単位、または契約で定められた別の数量としてカウントされる可能性があります。メータリングルールがそれを認めていない限り、ネットワークトラフィックを削減しても課金額が下がるとは限りません。
配送単位の料金でも、必ずしも注文単位とは限らない
ECの1つの注文から複数の荷物が発送されることがあります。課金単位が追跡番号であれば、分割注文は複数の単位を消費します。返品、交換発送、配送業者間の引き渡しについても、明確な扱いが必要です。
料金によって購入できる追跡が、指定期間、定義された完了イベントまで、または別の制限の下で提供されるのかを確認してください。また、すでに登録済みの配送が次の課金期間に新たな料金を発生させるかどうかも確認します。これらの詳細は、料金プランの名称より重要です。
注文数だけでなく、ワークフローからコストを見積もる
代表的な運用期間を設定し、配送単位のデータから予測を作成します。新しい配送だけでなく、引き続きモニタリングが必要な古い配送も含めてください。データが不完全な場合は、結果を正確な見積もりとして提示するのではなく、前提条件を明示します。
- 追跡可能な荷物を数える。チェックアウトの注文ではなく、一意の荷物追跡単位から始めます。課金上の扱いが確認できるまで、発送、返品、交換品を分けて管理します。
- モニタリング期間を測定する。関連する場合は輸送前の期間や例外期間も含め、各配送で更新が必要な期間を見積もります。
- 必要な更新頻度を定義する。アプリケーションが最新情報を必要とする頻度と、配送状況によってそれが変わるかどうかを指定します。
- APIワークフローを整理する。統合で使用する登録、結果検索、更新要求、修正、再試行、その他のエンドポイントを一覧化します。
- 課金ルールを適用する。提案された契約に基づき、技術上のアクティビティを課金対象のコールまたは配送単位に変換します。
- 利用量以外の料金を加算する。該当するサブスクリプション、最低利用額、オプションサービス、導入または運用コストを含めます。
1回の検索につき1つの追跡番号を使用する単純なポーリング統合では、開始時の見積もりは次のとおりです。
検索リクエスト数 = モニタリング対象の配送数 × 平均モニタリング日数 × 1日あたりの検索回数
この簡易計算は、すべての配送が同じ平均スケジュールに従うことを前提としています。より正確なモデルでは、配送または配送コホートごとのリクエストを合計し、登録コールやその他の課金対象アクティビティを加算します。配送が月末をまたいで有効なままの場合は、リクエストが発生した課金期間に割り当てます。
計算例：より安いモデルが変わる場合
以下の数値は計算方法を示すためだけに作成したものです。17TRACKの価格、サプライヤーの見積もり、市場ベンチマークではありません。
同じ想定期間内に10,000個の荷物を登録し、完全にモニタリングするとします。各荷物には、1回の登録リクエストと、8日間にわたる1日3回の検索リクエストが必要です。すべてのリクエストが課金対象で、各リクエストが1個の荷物に関するものとし、再試行、バッチ割引、無料枠、固定料金はないものとします。
- 登録リクエスト：10,000。
- 検索リクエスト：10,000 × 8 × 3 = 240,000。
- 課金対象リクエストの合計：250,000。
- 例示的なコール単価：$0.002。
- 例示的な配送単価：必要なモニタリングを含めて$0.04。
コール単位の利用料金は250,000 × $0.002 = $500です。配送単位の利用料金は10,000 × $0.04 = $400です。この前提では、配送単位の料金のほうが利用料金で$100安くなります。
ここで検索頻度だけを1日1回に変更します。リクエスト数は、10,000回の登録と80,000回の検索、つまり合計90,000コールになります。コール単位の利用料金は$180に下がりますが、例示的な配送単位の利用料金は$400のままです。優れたモデルが変わるのは、どちらかの料金体系が本質的に優れているからではなく、ワークロードが変わるためです。
損益分岐点を見つける
両方のプランに固定料金、無料枠、追加料金がない場合は、次を使用します。
配送あたりの損益分岐課金コール数 = 配送単価 ÷ コール単価
この例では、$0.04 ÷ $0.002 = 配送あたり20回の課金対象コールです。20回を超えると配送料金のほうが安くなり、20回未満ではコール料金のほうが安くなります。この例の前提では、登録コールもこの基準に含まれます。
この簡易計算は、段階料金、前払いクレジット、エンドポイントごとに異なる料金、最低利用額には不十分です。これらのプランでは、表示された単価を比較するのではなく、予測される各利用量について請求額全体を計算してください。
Webhookはポーリングを減らせるが、課金の確認は必要
ポーリングとは、アプリケーションが追跡情報を繰り返し要求することです。Webhookを使うと、サービスがアプリケーションにイベントを送信できるため、イベントストリームが要件を満たす場合は繰り返し検索する必要性を減らせます。
ただし、検索リクエストが減っても、請求額が自動的に下がるとは限りません。Webhook配信が含まれているか、配信や再試行が計測されるか、照合のための検索が引き続き必要かを確認してください。また、アプリケーションは重複イベントや順序が前後したイベントを安全に処理し、配信失敗から復旧できる必要があります。
もう1つ区別すべき点があります。より頻繁に情報を要求しても、基盤となる配送業者が新しいスキャン情報を生成したことが保証されるわけではありません。運用上の価値がほとんどない可能性のあるポーリング頻度に料金を支払う前に、検索結果の内容とデータ更新の仕組みを確認してください。
表示された単価に隠れている可能性のあるコスト
含まれる無料枠、最低料金、前払い残高
最低請求額と、利用量が含まれるサブスクリプションを区別してください。最低請求額は支出の下限を設定する場合があり、無料枠は超過料金が適用される前の一定数量をカバーする場合があります。前払いクレジットでは、有効期限、返金、未使用残高について別途確認が必要です。
無料枠が超過料金より先に差し引かれるプランでは、次の構成が役立ちます。
API請求額 = 固定プラン料金 + 課金対象の超過利用料金 + 該当する追加料金
この計算式は契約内容と一致する場合にのみ使用してください。同じ無料利用分を二重に加算したり、すべてのプランが同じ方法で限界料金を適用すると想定したりしないでください。
長期間継続する配送と再登録
ポーリング方式では、モニタリング期間が長くなるほど検索量が増えます。配送単位の料金では、元の料金がその期間をカバーするかどうかが重要です。すぐに配達が完了するケースだけでなく、例外や遅延した配送も検証してください。
同じ追跡番号が2回送信された場合、修正された場合、削除後に再追加された場合、または別の配送業者に関連付けられた場合の扱いも確認します。必要に応じて重複防止を実装しますが、アプリケーションレベルの重複排除がサプライヤーの課金上の識別単位と完全に一致すると想定しないでください。
レート制限とピーク時の容量
手頃な月間無料枠があっても、統合が大規模なインポートやトラフィック急増に対応できることにはなりません。リクエストレート制限、バッチ制限、同時実行制限、制限に達した際の想定動作を確認してください。月間利用量を満たしていても、必要なワークフローをサポートできないプランは、同等の選択肢ではありません。
エンジニアリングおよび運用コスト
API請求額と総保有コストを分けて考えてください。社内費用には、統合開発、Webhookホスティング、キュー、モニタリング、インシデント対応、データ保存、保守などが含まれる場合があります。
自社の人件費とインフラ費用の見積もりを使用してください。より高価なサブスクリプションでも、運用作業を明確に削減できるなら経済的な場合があります。ただし、その削減効果は想定ではなく検証すべきです。
見積もりを比較し、候補を検証する方法
各サプライヤーに、同じワークロード仕様で価格を提示してもらいます。仕様には、荷物量、配送構成、モニタリング期間、更新要件、エンドポイント、ピーク負荷、必要なサービスを含めます。課金単位の説明を書面で求め、請求額の計算例も依頼してください。
17TRACKを検討するチームにとって、公式Tracking APIページとAPIドキュメントが、製品および統合評価の出発点となります。予測にモデルを割り当てる前に、適用される価格と課金定義を直接確認してください。この記事では、現在の17TRACKプランの価格提示や分類は行っていません。
契約する前に、代表的な配送を使って管理されたパイロットを実施してください。分割注文、重複送信、遅延した荷物、国境を越える輸送、課金境界をまたぐ配送を含めます。失敗や再試行の動作は、サービスで許可された方法でのみテストしてください。
- 自社のリクエストログとサプライヤーの利用記録を比較する。
- 登録した追跡単位と請求された配送単位を照合する。
- 必要な更新頻度が実際に達成されているか確認する。
- ピーク時の需要を月間消費量とは別に測定する。
- コストを外挿する前に、説明のつかない差異を調査する。
少なくとも、通常運用、季節的ピーク、輸送長期化の3つの予測を作成してください。請求額に任意の割合を加えるのではなく、基礎となる要因を変えます。たとえば、ピーク時には荷物数を増やし、遅延シナリオではモニタリング期間を長く設定します。
どちらのモデルを選ぶべきか
コール単位の料金を選ぶべきケースは、検索頻度が低く、リクエスト需要を測定でき、登録やその他の課金対象アクティビティを含めても予測が損益分岐点を下回る場合です。頻繁なポーリングや予測しにくいモニタリング期間によって、リクエスト量へのエクスポージャーが大きくなる場合は、魅力が下がります。
配送単位の料金を選ぶべきケースは、継続的なモニタリングが必要で、提示された配送料金に必要な更新頻度、追跡期間、配信方式が含まれている場合です。ほとんど利用しないモニタリングに料金を支払う場合や、配送の定義によって予想外の追加単位が発生する場合は、魅力が下がります。
最終的な判断では、運用上の荷物1個あたりの総コストを使用してください。これは、API請求額に帰属可能な運用コストを加え、業務上モニタリングが必要な一意の荷物数で割ったものです。サプライヤーごとに課金単位が異なる場合でも、見積もり間で社内の荷物定義を統一してください。
FAQ
失敗したAPIリクエストは課金対象ですか？
どちらとも想定しないでください。バリデーションエラー、認証失敗、レート制限レスポンス、サーバーエラー、タイムアウトの扱いを確認します。タイムアウトの場合、アプリケーションが再試行する前にリクエストが処理されたかどうかが不明になることもあります。
1つの注文は常に1つの配送としてカウントされますか？
いいえ。1つの注文に、個別に追跡される複数の荷物が含まれる場合があります。予算作成では、注文を追跡単位に対応付け、その後サプライヤーの定義を適用してください。返品、交換品、配送業者間の引き渡しがどのようにカウントされるかを確認します。
バッチリクエストで請求額は下がりますか？
課金ルールがバッチ処理を優遇する場合に限ります。バッチによってネットワークリクエストは減っても、課金対象の追跡単位は減らない可能性があります。バッチ上限と、課金がリクエスト単位、項目単位、または加重単位のいずれで適用されるかを確認してください。
Webhookですべての検索リクエストをなくせますか？
通常のポーリングの多くをなくせる可能性はありますが、初回取得、イベントを受信できなかった場合の復旧、定期的な照合が設計上必要になる場合があります。それらのコールを見積もりに含め、Webhook配信に料金がかかるか確認してください。
翌月も有効な配送について、どのように予算を組むべきですか？
コール単位の料金では、その配送が次の期間に生成するリクエストを予測します。配送単位の料金では、モニタリングが引き続きカバーされるのか、別の料金が発生するのかを確認します。継続的なワークロードを見積もる際に、新しく作成された配送だけを数えないでください。
出典
上記の計算では、公開されたサプライヤー価格ではなく、明示的に仮定した入力値を使用しています。17TRACKの評価では、以下の公式リファレンスページを使用し、商用条件を直接確認してください。
