食品通販で三温度帯（常温・冷蔵・冷凍）の送料・同梱・別梱を上手く制御して販売するには？

三温度帯とは、配送や保管時の温度指定のことで、常温、冷蔵、冷凍の3区分に分類されます。 食品をオンラインで取り扱う販売の現場では、商品ごとに定められた温度帯での在庫管理に加え、商品を発送する際の温度帯に応じた送料設定がECサイトのバックヤード側の管理機能として必要です。

常温、冷蔵、冷凍の各温度帯のみを単体で取り扱うECサイトであれば、1種類の送料設定や配送の仕組みに対応したECカートシステムで運用が可能です。 しかし異なる温度帯の商品を取り扱うECサイトも多く存在しており、そのような場合には、温度帯に応じた配送料金の設定や在庫管理が必須になります。

ECサイト上で、常温便の商品とクール便（冷蔵/冷凍）の商品を混在して販売しているが、思い通りの送料設定ができていない。
異なる温度帯の商品を同時に購入された場合は、運用フローでカバーしているが対応コストや人的ミスの課題がある。

このような課題を解決するために、三温度帯商材を取り扱うEC事業者が、ECサイトの構築や、システム選定の際に抑えておくべきポイントをまとめましたので、事例を交えて解説していきます。

目次

1. 食品ECでの三温度帯（常温・冷蔵・冷凍）対応のポイント
2. 別梱・同梱時の送料設定がうまくできないとどうなるか
3. 商材によっては必要になる温度帯（常温・冷蔵・冷凍）関連の機能
4. 三温度帯（常温・冷蔵・冷凍）対応のECサイトを構築する方法
5. まとめ

三温度帯の送料設定

配送料金の設定は、食品のECサイトの運営において重要なポイントになります。一般的なECカートやECサイト構築パッケージでは、以下のような送料の設定項目があるはずです。

　・都道府県別の送料計算
　・購入金額に応じた送料計算
　・購入商品の重量に応じた送料計算
　・送料無料条件の指定

温度帯の異なる商品を一つのECサイトで扱う場合にはこれらの一般的な送料計算に対し、まずはクール便（冷蔵・冷凍）に応じたオプション料金の加算が必要です。

クール便の方が送料負担が大きいため、冷蔵・冷凍商品の注文の際にはきっちりと加算分の送料を注文の合計金額に含めたい事業者様がほとんどだと思います。

ここまでは商品毎に温度帯の設定項目があるか、特定の商品のグループやカテゴリに対してオプションの送料設定ができれば対応可能です。

しかし、複数の温度帯商品を同時に購入するケースを考慮していくと、システム上必要な機能は複雑化していきます。

異なる温度帯の商品は同梱可能とするか、別々で送る方が良いのかについて、本来理想としている注文や発送の形式ではなく、 システム上の制約を優先とした形式になってしまいやすいポイントです。

この同梱設定の複雑なポイントについて見ていきます。

温度帯の異なる商品の同梱・別梱設定

例えば、 フルーツショップ・青果店のECサイトでりんごと冷凍のブルーベリーを扱っているとします。

通常加工前のりんごは夏の期間を除いて常温で送られるケースが多いと思いますが、冷凍のブルーベリーを同じお客様が注文された場合に、 品質を維持してお客様のご自宅で保管してもらうためにも、りんごを冷凍タイプのクール便にまとめて入れてしまう訳にはいきません。

この場合、もしECサイト上で一緒に購入された場合は、 それぞれ別の梱包を行い、発送伝票を準備し、

りんごの分の常温の通常送料 + 冷凍ブルーベリーのクール便の送料 = 合計送料

として送料を計算したいはずです。

では、同じフルーツショップでフルーツケーキの商品も展開しており、 冷凍のいちごのケーキと、別売りで誕生日用の数字の形をしたろうそくを販売していて、同時に購入があったとします。

ろうそくは冷凍ケーキと一緒に入れてしまっても品質上問題ない商品なので、 この場合は冷凍のクール便として一つのパッケージとして発送する方が購入者にとっての金額負担が少ないだけでなく、ショップにとっても梱包業務が楽になります。

そのため送料は単純に、

冷凍ケーキのクール便の送料 = 合計送料　

としたいでしょう。

このように、商品同士の組み合わせによっては、 同梱にしてできるだけ送料を少なくしたいこともあれば、商品の特性によって別梱とせざるおえないこともあります。

商材によってこの同梱の取り扱いは様々なケースがあります。

取り扱い商材による温度帯（常温・冷蔵・冷凍）の混在の例

業種	常温	冷蔵	冷凍
ベーカリー・パン屋	・クッキー ・ビスケット	・サンドイッチ ・クリームパン	・冷凍パン生地 ・クロワッサンの冷凍製品
海産物店・魚屋	・缶詰のツナ ・鰹節	・刺身 ・イクラ	・冷凍エビ ・冷凍サバ
カフェやティーショップ	・コーヒー豆 ・紅茶の茶葉	・デザート（ティラミス ・プリンなど）	・アイスコーヒー用の氷入りコーヒーキューブ ・冷凍ケーキ
精肉店	・肉用のスパイスミックス ・調味料	・鶏肉の手羽先 ・ハンバーグミンチ	・冷凍焼肉用のスライス牛肉 ・冷凍豚バラ
お菓子専門店	・チョコレート菓子 ・クッキー缶	・生チョコ ・チーズケーキ	・冷凍マカロン ・アイスキャンディ

可能であれば商品の組み合わせによって、柔軟に送料計算ができる仕組みを構築して、 できるだけお客様が購入しやすく、正しい温度帯の配送便で商品が届くように配慮したいところです。

とはいえ商品の同梱・別梱の管理には複雑なロジックが必要になるため、そこまで細かく設定ができないシステム上の仕様となっているケースも多いです。 柔軟に計算結果をコントロールができる仕組みになっていない場合の苦肉の対処方法として、以下のようなパターンがあります。

・温度帯の異なる商品同士は同時にカートに入れて注文しないで欲しい旨の注意書きを記載する
・温度帯の異なる商品同士では同時に購入ができないようにする(同時購入の制限)

一注文に対して一温度帯という原則になるため管理は楽になります。

また、購入者側も明らかに温度帯が違う商品の場合に配送がどのようにされるのかは気になるポイントでもあるので、 全く受け入れられないような仕様という性質のものではなく、実際の食品の本店ECサイトでもよく見かけるパターンです。

しかし、注意書きだけで制限する場合は一定数、温度帯の異なる商品が混在した注文が送料が不足した形で発生することを許容して対応しなければなりません。

またシステム上、温度帯の異なる商品同士では同時に購入ができないようにする制限はできたとしても、以下のデメリットが生じます。

購入フローが複雑化・煩雑化する

温度帯の異なる商品同士では同時に購入ができないようにする制限を行なった場合、以下のようなパターンでカート内の商品をチェックしてエラーを表示する形になります。

・商品をカートに追加するタイミングで「カートの中の商品とは温度帯が異なるため同時に購入することができません」とエラーが出る。
・購入手続きを進めようとすると、「カート内商品と同梱できない商品が追加されました。お手数ですが該当商品を削除のうえ別途ご注文をお願いします。」というエラーが出る。

ECサイトでお買い物中のユーザーにとって、温度帯の違いによって表示されるエラーは予期することが難しく、 大きなストレスになる可能性が高いです。

予期しないタイミングでのエラーに対してユーザーが一度で状況を理解することは実は難しく、 何度か同じエラーが表示されてやっと意味を理解するため、 最悪の場合、理解する前に購入をやめてサイトから離脱してしまう可能性があります。

「ついで買い」「せっかくならご一緒に」を訴求する施策が機能しなくなる

ECサイト上において、一回ECサイトに訪れてもらったタイミングでできるだけたくさんの商品を購入してもらい、注文単価を高くすることはとても重要です。 よくある販促の施策としては次のようなものがあります。

・一万円以上で送料無料
・8,000円以上の購入にのみ適用できるクーポン
・累計の購入金額が30,000円以上で、ポイント2倍

当然同時に購入できる商品を制限してしまうと、こういった施策から訴求をすべき「ついで買い商品」も限られてきてしまうので、 販促施策の効果に制限をかけてしまう形になります。

さらには冷凍商品には冷凍商品をレコメンドしないと辻褄が合わなくなってしまうなど、 かえって温度帯によって管理する項目が増えてしまうことにも繋がります。

これらのデメリットを回避するためにも、できり限り温度帯の異なる商品も一度の購入操作で注文することができるサイトを構築することが望ましいです。

基本的には、常温・冷蔵・冷蔵商品を判別し、自動で発送小口を分類した上で送料計算を実施する仕組みがECサイト上での、 温度帯管理として必要な仕様になりますが、これに関連する機能性や、より細かい管理が必要になるケースについて記載していきます。

夏季冷蔵便の設定

日本には四季があり、季節によって温度が変化します。気温の低い時期は常温便で配送できる商品であっても、気温の高い時期は 冷蔵便での発送が必須となるケースがあります。

冒頭に例示した、りんごも通常は常温で送る方がことがほとんどですが、夏の暑い期間は冷蔵で送られることも多い商品です。

そのほか、和菓子や洋菓子（特に生菓子）などの鮮度を保つ必要がある食品は夏季のみ冷蔵便として発送する運用が発生します。

このような、時期によって配送温度帯が変わる商品は、1年中冷蔵便で発送する商品とは区別を付け、「夏季冷蔵便」として別途登録できる仕組みがあると方が望ましいです。
夏季冷蔵にあたる期間を日付ベースで設定し、該当期間にのみクール便オプション料金を加算することができる仕組みです。

例えば、こちらの商品をご覧ください。

利用中のECカートシステム：aiship

商品画像内のアイコン「常温便（夏季冷蔵便）」の表示からも分かるように、季節によって配送便を切り替えるように商品登録しています。

こちらのオンラインショップでは夏季冷蔵期間をバックヤード側の設定で、4月下旬～11月上旬まで（1日単位で日付指定可）と設定し運用頂いております。この設定期間内で購入操作をすると、自動的にクール便の送料として計算され、それ以外の期間での購入は、常温の送料が計算されます。

より正確な配送日時指定

クール便で発送する商品を扱う場合に、できる限り促進した方が良い内容が「配送日を指定してもらい、お客様に認識してもらったうえで注文を受け付ける」ことです。

というのも、クール便は配送会社での保管期限が常温商品より短く設定されています。

2025年1月時点では、以下のようになっています。

ヤマト運輸：最初のご不在連絡票をお届け日した日を含め3日間
クール宅急便の保管期間はいつまでですか？ | クール宅急便| ヤマト運輸

佐川急便　飛脚クール便：初回配達日を含む4日間
【佐川急便】営業所受取サービス利用規約（荷受人さま向け）｜配送・受け取りサービスご利用規約｜輸送料金｜荷物を送る・受け取る

これは商品の品質劣化を防ぐ目的で、通常便よりも保管期間が短く設定されており、しかも、保管期間中の品質も保証は約束されていないことが一般的です。
再配達による受け取りのタイミングが合わないことが数回重なってしまうと、 「商品は傷んだ上に、注文もキャンセルになり返金せざるおえない」ということも起こりえます。

宅配便の再配達問題は、社会問題としても取り上げられているように、配達日時指定の正確性は一段と重要度を増しています。 特に鮮度が重要なクール便の場合は、通常便よりも正確性が求められます。

注文者が確実に受け取れる日時を指定した上で注文ができるよう、ECシステム側の機能で、配送先に対して確実に商品を届けられる日時を算出する必要があります。

ヤマト運輸サービスレベル対応でお届け先ごとにお届け可能日時を自動算出｜aiship

また、配送希望日を選択できる仕様に合わせて、できれば対応しておきたいのが、 商品詳細ページ（カートに商品を追加する前のページ）の時点で最短お届け日を表示することです。

楽天やamazonといったECモールでは、当たり前のように表示されているのですが、 自社ECサイトでは注文手続きの中でしか確認できないことが多いです。

注文をしようとしている日付に対しての、最短お届け日がわかることで、 「早めに注文を完了させておこう」という心理から購入してもらえる可能性が高くなるため、 受け取り日をきちんと意識してもらう意味でも、商品ページに表示しておいて損のない情報となります。

自社ECの商品詳細ページで配送先都道府県ごとの最短お届け日を表示｜クラウド型ECサイト構築ASP「aiship」

出荷日別での在庫管理

発送日時指定の設定と密接に関係してくるのが、日別の在庫設定です。

商品の在庫数を豊富に抱え、注文が殺到しても商品を用意できる場合はこの項目に対する考慮は不要です。 しかし、農産物・お菓子など、クール便で発送する商材には、日ごとに生産できる数、或いは出荷できる数に限りがあることが多く見受けられます。

日ごとの出荷管理が機能として用意されていないと、手動での在庫管理が必要となり、最悪のケースでは、指定された日時に商品を発送できないといった事態に陥ります。 商品自体の在庫数とは別に、日別に在庫管理できる仕組みをECサイトに備えておくと、その後の運用コストを大きく下げることに繋がります。

こちらの商品は日ごとに出荷数を制限しています。

利用中のECカートシステム：aiship

一見、商品ページを見ただけでは判別がつきませんが、商品をカートに入れ、配送希望日時選択画面に進んだ画面がこちらです。

上記キャプチャにおいて11月2日以降のお届け希望日の中で、選択肢として表示されていない日があることにお気付きでしょうか。11月4日や8日は、カート画面で希望日時を選択できません。これは、その日にお届けできる商品を出荷するための在庫が用意できない為です。

出荷日別在庫管理機能｜クラウド型ECサイト構築ASP「aiship」

ECサイトを構築する方法は、様々あり、こちらの記事にて詳しく解説しておりますが、三温度帯のような、食品ECなどに特化した機能を備えたカートシステムを用意する方法は、大きく2通りです。

スクラッチ開発（ECパッケージやオープンソース含む）

自社のニーズにマッチするカートシステムを用意する方法として、ゼロからシステムを構築するスクラッチ開発や、ECパッケージやオープンソースなどの既存ソースを利用しつつ、カスタマイズ開発を行う方法が思い当たります。
しかしこの方法では、開発費用を莫大に用意し、またメンテナンスについても自社で管理していく必要があります。

また、三温帯などの食品EC専用サイトを構築するためのノウハウが無い場合、本来必要な機能が漏れていることが実際に運用フェーズにて分かったり、実際は使われない機能を過度に用意してしまうなど、失敗するリスクもあります。

一昔前までは、自社の要望を実現するためにはスクラッチ開発が必要でしたが、最近では、三温度帯機能に対応したASPカートの選択肢が増えています。

ASP/クラウド型のECカートシステム

ASP/クラウド型のECカートシステムは、ECサイトの構築運営に必要な機能が揃っており、スクラッチ開発と比べて、開発コストにおいても導入スピードにおいても優位性があります。ただし、多くのEC事業者に利用されることを前提として機能が汎用的に作られていることで、運用面で工夫が必要になってくるケースがあるため、トライアル期間などを活用して、自社の運用にマッチするかを確認は必須です。

運用開始後は、システムはASP事業者の責任にてセキュリティも含めて常に最新にバージョンアップされていきます。困ったときにはサポートに頼ることができるだけでなく、今後追加される新機能も利用できるため、トレンドに乗ったEC運営が可能です。

もし、スクラッチ開発で検討を進めていたとしても、まずはASP/クラウド型のECカートシステムを利用して、実際に運営してノウハウを蓄積してから、次のステップとしてスクラッチ開発に挑んでも遅くはありません。

いかがでしたでしょうか。三温度帯に対応したECサイトを構築するために、ASP/クラウド型のカートシステムが良いと判断した場合、食品やギフトECサイトの構築に特化したASPカートのaishipをおすすめします。

「aiship」では、本記事でご紹介した「三温度帯の送料設定」「夏季冷蔵便」「正確な配送日時指定」「出荷日別在庫管理」「商品の同梱/別梱設定」の各機能を備えております。

正確な配送日時指定の算出では、ヤマト運輸のサービスレベルに対応しています。サービスレベルとは、出荷場所から注文者が入力した配送場所に届けるまでに必要な日数をヤマト運輸のデータベースを参照し、瞬時にカート側の配送希望日時個所に自動計算して表示させます。これにより、正確なお届け日時を算出し、配送トラブルを限りなく減らすことにも繋がっています。

今回の記事でご紹介した内容について、少しでも気になった点がございましたら、お気軽にお問い合わせください。

また、現在、他社カートシステムやスクラッチ型を利用している場合、ASP/クラウド型のカートシステムへの移行も簡単です。 詳しい手順はこちらの記事で解説していますのであわせてご参考いただけますと幸いです。
またEC-CUBEからの切替の場合はこちらの記事をあわせてご確認ください。