はじめに：物流2026年問題で配送コストはどう動くか
ECを運営していると、ここ数年「送料」という固定費だと思っていた項目が、じわじわと変動費のように膨らんでいくのを感じている方が多いのではないでしょうか。商品単価は据え置きにしているのに、出荷一件あたりの利益が前より薄くなっている。その犯人を探していくと、かなりの割合で配送コストにたどり着きます。
背景にあるのが、いわゆる「物流2026年問題」と呼ばれる構造的な変化です。発端は2024年4月に施行された、トラックドライバーの時間外労働の上限規制でした。長時間労働が制限されたことで、一人のドライバーが運べる距離や荷物量が減り、輸送能力そのものが縮小すると指摘されています。この影響は単年で終わるものではなく、人手不足や燃料費、再配達のコストなどと絡み合いながら、数年単位で配送料金や納期に効いてくると見られています。
ここで強調しておきたいのは、具体的な値上げ率や輸送能力の不足量について、さまざまな試算が出回っているということです。数字は調査機関や前提条件によって幅があり、断定的に「何パーセント上がる」と言える性質のものではありません。本記事では特定の予測値を根拠にするのではなく、「配送コストは上がりやすく、下がりにくい方向に環境が変わっている」という前提だけを置いて話を進めます。
そのうえで本記事がお伝えしたいのは、精神論で送料を我慢するのではなく、自社の配送データを数字で分解して、どこにコストが偏っているかを把握しようという考え方です。配送費は「全体でいくら」と眺めているうちは打ち手が見えませんが、地域別・サイズ別・再配達有無といった切り口でばらすと、改善できる場所がはっきりしてきます。その分解の道具として、BigQuery は相性の良い選択肢です。
なお、配送会社との契約料金や具体的な改善幅は、事業者ごとの取扱量や商材によって大きく変わります。本記事のSQLや数字はあくまで考え方を示すための例であり、自社のデータに当てはめて検証していただくことを前提にしています。「他社でこう改善した」という事例をそのまま持ち込むのではなく、自分の手元の数字から判断材料を作る、という姿勢が一番の近道です。
なぜ配送コストの分析にBigQueryが向くのか
配送コストの分析が難しいのは、必要なデータが複数の場所に散らばっているからです。受注情報はECカートや受注管理システムに、配送実績は運送会社の管理画面やCSVに、商品のサイズや重量はマスタ管理の表計算ファイルに、といった具合に、別々のシステムが別々の形式で持っています。これを毎月手作業で突き合わせていると、それ自体が立派な人件費になってしまいます。
BigQuery を使う利点は、こうしたバラバラのデータを一か所に集約し、SQL という共通の言葉でまとめて集計できる点にあります。受注データと配送データと商品マスタを結合し、「東京都向けの60サイズの送料合計」といった切り口を、その都度集計し直せます。データ量が増えても処理速度が落ちにくく、月次のレポートだけでなく、思いついた仮説をすぐ検証する探索的な使い方にも耐えます。
費用面でも、中小規模のECであれば過度に身構える必要はありません。配送データは画像や動画と違って一件あたりのサイズが小さく、年間の出荷件数が数万件程度であれば、保管コストはごくわずかです。集計クエリも、無駄にテーブル全体を読まない書き方を心がければ、月々の費用は抑えられます。
もうひとつの利点は、表計算ソフトでは扱いきれない規模になっても破綻しにくいことです。出荷件数が増えてくると、表計算ファイルは動作が重くなったり、関数が壊れたりしがちです。BigQueryなら、データが増えても同じクエリがそのまま使えるため、事業が伸びたときに分析の仕組みを作り直す手間がかかりません。最初に土台を整えておけば、長く使い続けられる点も、配送コストのように継続的に追いたいテーマと相性が良い理由です。
受注・配送データをBigQueryに集約する
最初のステップは、分析の土台となるデータをBigQueryに集める設計です。理想を高く持ちすぎて全システムを完璧に連携しようとすると、いつまでも始められません。まずは配送コストの分解に最低限必要な項目だけを揃える、という割り切りをおすすめします。
集約したいテーブルは、大きく三つです。一つ目が受注テーブルで、注文ID・注文日・配送先の都道府県・注文金額などを持ちます。二つ目が配送実績テーブルで、注文IDに紐づく配送業者・配送サイズ・実際の配送料金・再配達の有無などを持ちます。三つ目が商品マスタで、商品ごとの寸法や重量、保管している倉庫の情報を持ちます。これらが注文IDや商品IDで結合できる状態になっていれば、ひととおりの分析ができます。
実際のテーブル構造をイメージしやすいよう、配送実績テーブルの最小構成を示します。
-- 配送実績テーブル（shipping_records）のイメージ
CREATE TABLE IF NOT EXISTS `your_project.ec_mart.shipping_records` (
order_id STRING, -- 注文ID（受注テーブルと結合するキー）
shipped_date DATE, -- 出荷日
prefecture STRING, -- 配送先の都道府県
package_size STRING, -- 配送サイズ（例: 60, 80, 100）
carrier STRING, -- 配送業者
shipping_cost INT64, -- 実際にかかった配送料金（円）
is_redelivery BOOL -- 再配達が発生したか
);データの入れ方は、運送会社やカートが出力するCSVを定期的に取り込む形が現実的です。手動アップロードから始めて構いませんが、毎月の運用に乗せるなら、取り込みと集計を自動化しておくと負担がぐっと減ります。スケジュール実行で日次集計テーブルを更新する仕組みについては、BigQueryのスケジュールクエリでデータマートを毎日自動更新するで具体的に触れています。
なお、配送先住所などの個人情報を扱う場合は、分析に必要な粒度まで絞り込むことが大切です。都道府県別のコスト分析であれば、番地まで持つ必要はありません。氏名や詳細住所は分析テーブルから外し、都道府県コードだけを残すといった設計にしておくと、安全性と扱いやすさの両方が上がります。
データの粒度については、もうひとつ意識しておきたい点があります。配送サイズや再配達の有無といった項目は、運送会社のデータにそのまま入っていないこともあります。その場合は、梱包実績や問い合わせ履歴など別の記録から補う必要が出てきますが、最初から完璧に揃えようとすると挫折しがちです。手に入る項目だけでまず集計を始め、足りない項目は分析の過程で「これがあればもっと分かる」と気づいたタイミングで足していく、という順番がおすすめです。分析は一度作って終わりではなく、見えてきた課題に合わせて少しずつ育てていくものだと考えると、気が楽になります。
配送コストの要因を分解する
データが揃ったら、いよいよコストの要因分解です。ここでの目的は、「配送費が高い」という漠然とした感覚を、「どの条件のときに高いのか」という具体的な事実に置き換えることです。代表的な切り口を順番に見ていきます。
地域別に配送コストを見る
まず効くのが地域別の集計です。配送料金は配送先までの距離帯で決まることが多く、遠方や離島向けの出荷が多いと、平均送料が押し上げられます。都道府県ごとに出荷件数と送料合計、一件あたりの平均送料を出してみましょう。
SELECT
prefecture,
COUNT(*) AS shipment_count,
SUM(shipping_cost) AS total_cost,
ROUND(AVG(shipping_cost), 0) AS avg_cost_per_shipment
FROM `your_project.ec_mart.shipping_records`
WHERE shipped_date BETWEEN '2026-01-01' AND '2026-06-30'
GROUP BY prefecture
ORDER BY total_cost DESC;このクエリを実行すると、送料総額に効いている地域が一目で分かります。件数は少ないのに平均送料が突出して高い地域があれば、その地域向けの送料設定や、近隣倉庫からの出荷を検討する余地があるかもしれません。
地域別に見るときのコツは、「総額」と「平均」の両方を並べることです。総額が大きい地域は、出荷件数が多い主力エリアであることが多く、ここを少し改善するだけで全体への効き目が大きくなります。一方、平均送料が高い地域は、一件あたりの効率が悪いエリアで、送料設定の見直し対象になりやすい場所です。この二つは別の意味を持つので、片方だけを見て判断しないようにします。
サイズ別・再配達別に掘り下げる
次に、配送サイズと再配達の影響を見ます。サイズは料金区分に直結するため、想定より大きい梱包が多いと、そのぶん送料が膨らみます。再配達は、一度の配送で届かなかったことで追加のコストや手間が発生する典型的なロスです。
SELECT
package_size,
is_redelivery,
COUNT(*) AS shipment_count,
ROUND(AVG(shipping_cost), 0) AS avg_cost
FROM `your_project.ec_mart.shipping_records`
WHERE shipped_date BETWEEN '2026-01-01' AND '2026-06-30'
GROUP BY package_size, is_redelivery
ORDER BY package_size, is_redelivery;サイズ別に並べると、「80サイズと100サイズで送料が大きく変わる境目」が見えてきます。あと少し梱包を小さくできれば一段下の区分に収まる商品が多いなら、梱包資材の見直しが効くサインです。再配達の行を比べれば、再配達がどれだけ平均コストを押し上げているかも把握できます。
商品単位で送料負担率を見る
最後に、受注テーブルや商品マスタと結合して、商品単位での送料負担を見ます。注文金額に対して送料が占める割合が高い商品は、利益を削りやすい商品です。
SELECT
o.product_id,
COUNT(*) AS order_count,
ROUND(AVG(s.shipping_cost), 0) AS avg_shipping_cost,
ROUND(AVG(o.order_amount), 0) AS avg_order_amount,
ROUND(SUM(s.shipping_cost) / SUM(o.order_amount), 3) AS shipping_cost_ratio
FROM `your_project.ec_mart.orders` AS o
JOIN `your_project.ec_mart.shipping_records` AS s
ON o.order_id = s.order_id
WHERE s.shipped_date BETWEEN '2026-01-01' AND '2026-06-30'
GROUP BY o.product_id
ORDER BY shipping_cost_ratio DESC;送料負担率が高い商品ほど、単品で売ると採算が合いにくい商品です。こうした商品をどう扱うかが、次の打ち手につながります。
ここで注意したいのは、送料負担率が高い商品を単純に「やめるべき商品」と決めつけないことです。低単価でも、まとめ買いのきっかけになっていたり、リピートにつながっていたりする商品は、単品の採算だけで判断すると本来の役割を見落とします。負担率はあくまで「送料が利益を圧迫しやすい商品を見つけるための入口」と捉え、その商品が他の注文とどう一緒に買われているかまで見たうえで打ち手を決めると、判断を誤りにくくなります。
月次の推移で変化を追う
要因分解は一度やって終わりではなく、月ごとの推移で追うと、施策の効果や環境の変化が見えてきます。たとえば梱包資材を見直した翌月に、平均送料がどう動いたかを確認するといった使い方です。
SELECT
FORMAT_DATE('%Y-%m', shipped_date) AS ship_month,
COUNT(*) AS shipment_count,
ROUND(AVG(shipping_cost), 0) AS avg_cost,
ROUND(AVG(IF(is_redelivery, 1, 0)) * 100, 1) AS redelivery_rate_pct
FROM `your_project.ec_mart.shipping_records`
GROUP BY ship_month
ORDER BY ship_month;平均送料と再配達率を月次で並べると、配送コストが上がっているのか下がっているのか、その背景に再配達の増減があるのかが追えます。物流2026年問題のように環境がじわじわ変わる局面では、こうした定点観測の数字を持っておくこと自体が、値上げ交渉や送料改定の判断材料になります。
分析結果を送料設計・同梱・在庫配置に活かす
数字が見えたら、改善の打ち手に翻訳します。要因分解の結果は、おおむね次の三つの方向に活かせます。
一つ目が送料設計です。地域別・サイズ別のコストが分かれば、送料体系が実態に合っているかを検証できます。たとえば全国一律送料にしている場合、遠方向けの出荷で赤字が出ていないか確認できます。逆に、平均送料に対して送料無料ラインが低すぎると、注文ごとに自社負担が膨らみます。「送料無料ラインをいくらに設定すれば、平均的な注文で負担が見合うか」を、平均送料と平均注文金額から逆算できるようになります。
二つ目が同梱の促進です。送料負担率が高い小型・低単価の商品は、単品で買われると採算が合いにくい一方、他の商品とまとめて一回の配送に乗せられれば、一件あたりの送料を分散できます。商品単位の集計から「単品注文が多く、送料負担率が高い商品」を洗い出し、関連商品とのセット販売やまとめ買いの提案につなげる、といった使い方ができます。あわせて死に筋在庫の動かし方を考える際には、ECの在庫回転率をGA4×BigQueryで商品別に可視化して死に筋を特定するの視点と組み合わせると、在庫と配送の両面から判断しやすくなります。
三つ目が在庫配置です。地域別の出荷分析で、特定エリア向けの出荷が多く、かつそのエリアへの送料が高いと分かったら、近い倉庫に在庫を寄せたり、地域に近い拠点からの出荷を検討したりする材料になります。複数拠点を持つ判断は固定費との兼ね合いなので慎重に行うべきですが、少なくとも「どのエリアの配送コストが重いか」という事実を持っておくと、議論が感覚論になりません。
これらはいずれも、いきなり大きく変える必要はありません。送料負担率の高い上位商品から同梱を試す、コストの重い地域だけ送料設定を見直す、というように、データで優先順位をつけて小さく始めるのが現実的です。
加えて、再配達対策は配送会社まかせにせず、自社でできることが意外と多い領域です。置き配の案内を分かりやすくする、配送日時の指定をしやすくする、出荷通知のタイミングを見直すといった工夫は、いずれも再配達率を下げる方向に効きます。先ほどの月次クエリで再配達率を追っておけば、こうした施策の前後で数字がどう動いたかを確認でき、効果のある施策を見極めやすくなります。配送コストの改善は、料金の交渉だけでなく、こうした「届け方の工夫」の積み重ねでも進められます。
まとめ
物流2026年問題は、配送コストが上がりやすく下がりにくい方向へ環境が変わっていることを示すキーワードです。具体的な値上げ幅は試算によって幅があり断定はできませんが、だからこそ、自社の配送データを数字で把握しておく価値が高まっています。
受注・配送・商品マスタをBigQueryに集約すれば、配送コストを地域別・サイズ別・再配達別・商品別といった切り口で分解できます。その結果は、送料設計の見直し、同梱の促進、在庫配置の検討という具体的な打ち手に翻訳できます。まずは手元にあるCSVを一か所に集め、平均送料を地域別に出してみるところから始めてみてください。漠然とした「送料が高い」が、改善できる具体的な数字に変わっていくはずです。