「発送まで3日」と「3日で届く」は同じではない。前者は事業者が荷物を出すまで、後者は受取人の手元へ着くまでを指す。しかも営業日、検品完了、サイト上の発送表示、配送会社の引受記録が混ざると、同じ注文でも数え方が変わる。僕は、速さを比べる前に時計の始点と終点をそろえるべきだと考える。
この記事では2026年9月2日に確認した公表値を整理する。筆者自身の注文を使った配達実績ではないため、実日数の欄は測定方法だけを示し、数字を作らない。僕なら、公表値と未測定の実績を同じセルへ入れず、後から追記できる形にする。
配送を五つの時点へ分けると、言葉のずれが見える。
| 記号 | 記録する時点 | 主な証拠 |
|---|---|---|
| T0 | カードを獲得した時刻 | 当選履歴 |
| T1 | 発送依頼が受理された時刻 | 依頼完了画面、メール |
| T2 | サイト上で発送済みになった時刻 | 発送履歴、通知 |
| T3 | 配送会社が最初に引受処理した時刻 | 追跡の初回スキャン |
| T4 | 配達完了または実受領の時刻 | 追跡、受領記録 |
ユーザーが待った総時間はT4－T1、事業者から配送網へ渡るまでの時間はT3－T1、配送会社内の時間はT4－T3だ。T2は事業者側のステータスなので、物理的な引受時刻T3と一致するとは限らない。僕は、発送通知だけを到着日数の終点にしない。
DOPA!のFAQでは、検品と梱包が完了すると発送済み表示になり、配送会社の集荷状況によって追跡への反映に時間差が出る旨が案内されている。これはT2とT3を分ける根拠になる。僕なら、サイト通知と追跡初回スキャンを両方保存する。
獲得時刻T0から数える方法もあるが、ユーザーが発送依頼を保留した期間まで事業者の処理時間へ入ってしまう。発送速度の比較ではT1を始点にし、獲得から受領までの体感時間は別列に置く方が公平だ。
公表日数は、同じ定義へ無理に丸めず、原文が示す区間と単位を残す。2026年9月2日時点で確認できた表示は次の通りだった。
| サービス | 公表されている処理目安 | 到着側の案内 | 読む際の留意点 |
|---|---|---|---|
| DOPA! | 発送依頼から発送まで原則1〜3営業日 | 発送後、地域により1〜3日程度 | T1→T2/T3とT3→T4が分かれている |
| 日本トレカセンター | 特商法表示では発送依頼後、原則24時間以内 | 別の現行画面には通常5営業日との表示もある | 同じサービス内の二つの公開表示を併記する |
| Cloveオリパ | 発送依頼画面で1〜7営業日、商品や導線により1〜10営業日の表示 | 予約商品などは個別条件 | 対象商品と申請画面を保存する |
日本トレカセンターは特定商取引法に基づく表記の24時間表示と、読み込み後の現行案内にある通常5営業日表示が一致していない。どちらかを勝手に消すと、比較時点の事実を失う。僕は「最短24時間」と一行だけにせず、表示面、確認日、対象条件を並べる。
Cloveオリパは、発送依頼の経路や対象によって目安表示が異なる。予約品と通常品も同じ時計では測れない。僕なら、サービス名だけで一つの日数を固定せず、実際に申請する商品の画面を採用する。
DOPA!のように発送前と発送後が分かれている場合、単純合算はカレンダーや地域条件を確認してから行う。1〜3営業日と1〜3日を足して「2〜6営業日」と書くのは誤りだ。後半は暦日であり得るからだ。
オリくじの今日のラインナップを見る提供割合を公開している店／登録は無料第一の差は始点だ。発送依頼の送信、依頼の受付、本人確認や住所確認の完了は同じ時刻とは限らない。第二の差は終点で、梱包完了、発送済み表示、配送会社引受、到着のどれを指すかが違う。
第三は営業日の扱いだ。金曜夜の依頼から月曜までを暦日で数えれば三日だが、事業者の休業日を除けば処理日数は別になる。祝日、年末年始、大型連休、配送会社の運行も影響する。僕は、営業日とだけ書かれている場合、公式の営業日定義を確認できない限り独自の休日表を足さない。
第四は商品の経路だ。通常在庫、予約商品、取り寄せ、複数商品の同梱、住所不備、本人確認待ちでは処理が違う可能性がある。遅延例外を通常値へ混ぜても、通常値だけで例外を消しても比較は歪む。
公表値は契約条件の読み取りに使えるが、特定時点の混雑を示す実測ではない。逆に、一件の実測はその注文の記録であり、全利用者の平均にはならない。僕なら、公表レンジ、個別実測、集計統計を三層に分ける。
実際の注文を測るなら、T2－T1をサイト処理時間、T3－T1を物理引渡しまでの時間、T4－T3を配送時間、T4－T1を総待ち時間として保存する。実輸送の起点に使うのはT3だ。T2しか記録できない場合は、「配送会社引受は未確認」と明示する。
営業日ベースと暦日ベースも両方残す。たとえば依頼日時と受領日時の差を時間単位で保存しておけば、後から公式カレンダーに合わせて再集計できる。最初から「3日」と丸めると、時刻境界や休業日の検証ができない。
複数件が集まったら、平均だけでなく中央値、90パーセンタイル、最短、最長、件数を見る。少数の長期遅延で平均が動く一方、中央値だけでは遅い裾が見えないからだ。僕は、母数が一件なら「平均1日」と一般化せず、「観測1件、1日」と書く。
この記事の調査では注文も発送依頼も行っていないため、T1からT4の実測値は未測定だ。僕なら、空欄を公表値で埋めない。公表1〜3営業日と実測未測定は、情報量が違っても矛盾ではない。
目安を超えたように見えたら、まず依頼受付時刻、住所確定、本人確認、休業日、予約条件を確認する。それでも公表上限を過ぎている場合は、注文や発送の識別情報と、T1の証拠を添えて公式サポートへ確認する。カード内容や個人情報を公開SNSへ載せる必要はない。
追跡番号が発行されても、配送会社の初回スキャンがなければT3はまだ確定しない。反対に、追跡が動いているなら、その後の遅れは事業者処理と配送網のどちらで起きたかを分けられる。僕は、問い合わせ先を決めるためにもT2とT3を分離する。
公表ページは更新され得る。発送依頼日の表示を保存しておけば、後日変わった条件と混同せずに済む。僕なら、現在のページだけで過去注文を裁定せず、注文時点の証拠を優先する。
比較表には、サービス名、公表レンジ、始点、終点、営業日か暦日か、対象商品、確認日、実測件数を置く。公表値しかなければ実測欄は未測定。追跡がなければT3は不明。条件の違う数字を一列へ押し込まない。
僕は、速さだけで発送先を選ばない。送料、補償、梱包、追跡、保管期限、問い合わせ条件も、カードが無事に届くまでの一部だと考える。それでも日数を比べるなら、T1からT4まで同じ定義で測る。
僕なら最後に、各社の公表レンジとサイト側で蓄積された発送情報を照合する。現在の比較表を確認したい人は、オリパチェックの発送日数比較へ進める。
https://oripa-check.com/column/oripa-hassou-nissu-hikaku/
この記事の内容を踏まえて事業者を比べるなら、提供割合・排出履歴・交換ポイントの公開状況と、 第三者計測による還元率を先に見てください。 自分の予算で何が起きるかは高額カードの相場とシミュレーターで試算できます。