◆監修・編集責任者
B2B EC-COLUMN
この記事のポイント
- BtoB ECの出荷案内通知は、項目・契機と宛先・保存の3つの軸で設計します。
- 出荷案内に送り状に通常記載される事項が載る場合、電子帳簿保存法上の取引情報に該当し得ます。
- 納品予定の事前通知は、物流効率化法が定める荷待ち時間の削減にも関わってきます。
目次
BtoB ECの出荷案内通知とは(項目・契機・保存の3軸で決める)
BtoB ECの出荷案内通知の設計とは、出荷確定の事実と納品予定を、誰に・どの契機で・どの項目で伝え、どう保存するかを決める作業です。項目は流通BMSの出荷系メッセージに寄せ、通知データが取引情報に該当し得る場合は検索要件を満たす設計にします*3。
この通知が扱う情報は、出荷が確定した事実と納品予定日という2種類に整理できます。前者は取引先の検品準備、後者は受入体制の確保に使われるため、どちらを欠いても問い合わせが残ります。
出荷案内通知の定義と、受注確認メールとの違い
受注確認メールは注文を受け付けた事実を伝える通知です。一方、出荷案内通知は出荷が確定した事実と、納品予定日という新しい情報を伝える通知になります。両者は発生する契機が異なり、受注確認は受注時点、出荷案内は出荷指示から出荷確定までのいずれかの時点で送ります。
BtoB取引では受注確認だけでは「いつ届くのか分からない」という問い合わせが残ります。出荷案内通知を独立した通知として設計することが、この問い合わせを減らす出発点になります。
設計を分ける3つの軸:項目・契機と宛先・保存
出荷案内通知の設計は3つの軸に分けて進めます。第一に、何を伝えるかという項目の軸です。第二に、いつ・誰に送るかという契機と宛先の軸です。第三に、送ったデータをどう残すかという保存の軸です。この3軸を個別に決めておけば、後から通知内容を見直すときも影響範囲を切り分けられるはずです。
「お知らせ」ではなく「取引情報」になり得るという前提
出荷案内通知は担当者からすると単なる「お知らせメール」に見えます。しかし出荷日・品目・数量・送り状番号のような、送り状に通常記載される事項が載る設計にすると、電子帳簿保存法上の取引情報に該当し得ます*1。この前提を持たずに項目を増やすと、保存の要件が後から追いかけてくる形になります。次節以降で項目・契機・保存の順に具体的な設計を見ていきます。
出荷案内に載せる項目をどう決めるか:標準に寄せて漏れを防ぐ
出荷案内に載せる項目は、独自に決める前に業界標準の項目名を確認することが実務上安く済みます。ここでは基本項目と、標準への寄せ方を整理します。
出荷案内の基本項目:出荷日・納品予定日・品目・数量・梱包数・送り状番号
出荷案内に最低限含める項目は、出荷日、納品予定日、品目、数量、梱包数、送り状番号です。出荷日と納品予定日は受入側の受け入れ準備に直結するため必須項目にします。品目・数量は検品の基準になり、梱包数は受領時の数量差異を防ぐ役割を担うものです。
出荷案内の項目を決める優先順5点/順位根拠:重要度
- 出荷日と納品予定日を必須項目にします。受入側の受け入れ準備に直結するためです。
- 品目・数量を出荷案内に明記します。検品時の照合基準として使われます。
- 梱包数・梱包単位を示します。受領時に発生しやすい数量差異を防ぎます。
- 送り状番号を含めます。配送状況を追跡する際の照合キーになります。
- 独自項目を追加する前に、流通BMSの「出荷」「出荷梱包」等の名称に寄せます。将来のEDI接続を妨げない設計になります*4*5。
独自項目を作る前に標準に寄せる:流通BMSの「出荷」「出荷梱包」メッセージ
流通BMSは、消費財流通業界の標準となることを目標に策定されているメッセージと通信プロトコルのEDI標準仕様です*4。GS1 Japan(一般財団法人流通システム開発センター)が管理する標準準拠企業・メッセージ一覧があります。そこには「出荷」「出荷梱包(紐付けあり)」「出荷梱包(紐付けなし)」「出荷荷姿」という標準メッセージ名が確認できます*5。
流通BMSは任意の業界標準であり、従わなければならない義務があるものではありません。ただし、将来的にEDI接続や取引先の標準準拠を検討する場合、自社だけの項目名を先に決めてしまうと後で対応表を作り直す手間が生じます。項目名を標準の呼称に寄せておくことが、この手間を避ける実務的な判断になります。
項目ごとの取得元:EC・基幹・WMS・配送事業者の対応
出荷案内の各項目は、単一のシステムだけでは揃いません。出荷実績はWMS(倉庫管理システム、入出荷や在庫を管理するシステム)側にあることが多く、受注情報はEC側、送り状番号は配送事業者側から取得します。どのシステムがどの項目を持つかを決めておくことが、通知機能を設計する前提になります。
| 項目 | 内容 | 取得元システム | 必須/任意 | 標準の対応メッセージ |
|---|---|---|---|---|
| 出荷日 | 出荷が確定した日付 | WMS | 必須 | 出荷 |
| 納品予定日 | 発注者・受入担当への到着予定日 | 基幹・WMS | 必須 | 出荷 |
| 品目・数量 | 出荷する商品と数量 | EC・基幹 | 必須 | 出荷梱包(紐付けあり) |
| 梱包数・梱包単位 | 何個口で出荷するか | WMS | 任意 | 出荷梱包(紐付けなし)。出荷荷姿 |
| 送り状番号 | 配送事業者が発行する伝票番号 | 配送事業者・WMS | 任意 | 出荷 |
いつ・誰に送るか:契機と宛先の設計
出荷案内をいつ送るかは、出荷指示・出荷確定・集荷完了のいずれかを起点にします。契機を単一にしないと、同じ出荷について複数回通知が届き、受け取る側に無視される原因になります。
契機の候補:出荷指示・出荷確定・集荷完了・翌日一括
出荷案内の契機には、出荷指示時点、出荷確定時点、集荷完了時点、翌日一括送信の4つが考えられます。出荷確定時点を起点にすると、納品予定日を含む正確な情報を1回で送れます。集荷完了時点を起点にすれば、送り状番号を含めた状態で送れるのが利点です。どちらを主契機にするかは、送り状番号を即時に必要とする取引先の割合によって決めます。
宛先の分離:発注者・購買部門・納品先の受入担当・自社営業
BtoBの出荷案内は、発注者本人だけに送れば足りるわけではありません。発注者と納品先の受入担当が異なる組織である場合、両方に送る必要があります。購買部門と自社営業は、必要に応じて参照できる状態にしておけば十分で、毎回の通知対象に含めるかどうかは取引先ごとに判断します。
例外時の出し分け:分納・欠品・納品予定日の変更
分納が発生した場合は、どの梱包がどの出荷案内に対応するかを明示する出し分けが必要になります。欠品や納品予定日の変更が起きた場合も、通常の出荷案内とは別の文言・項目で知らせる設計が必要です。分納そのものの受注・帳票設計や、遅延発生後の連絡運用は、それぞれ扱う範囲が広い別テーマです。本稿では出荷案内側の契機の一つとして位置づけるところまでを扱います。
| 契機 | 発注者 | 購買部門 | 納品先受入担当 | 自社営業 |
|---|---|---|---|---|
| 出荷指示時 | 送らない | 送らない | 送らない | 社内共有のみ |
| 出荷確定時 | 送る(出荷案内) | 任意 | 送る(納品予定) | 任意 |
| 集荷完了時 | 任意(送り状番号を追記) | 送らない | 任意 | 送らない |
| 納品予定日変更時 | 送る | 送る | 送る | 任意 |
| 欠品・分納発生時 | 送る(分割の明示) | 送る | 送る | 送る |
出荷案内の通知データと電子帳簿保存法
出荷案内通知の設計で最も見落とされやすいのが、保存の軸です。ここでは電子帳簿保存法の一次情報に基づき、通知機能に流れ込む要件を整理します。
「取引情報」には送り状が含まれる:どこから保存対象になるのか
電子帳簿保存法上の「取引情報」とは、取引に関して受領し、又は交付する注文書、契約書、送り状、領収書、見積書その他これらに準ずる書類に通常記載される事項をいいます*1。出荷案内通知に、送り状に通常記載される出荷日・品目・数量・送り状番号のような事項が載る場合、その通知データは取引情報に該当し得ます。断定はできず、記載内容によって判断が変わるため、個別の判断は税務署や税理士への確認をおすすめします。
EDI経由・サイト経由のどちらでも電子取引に当たる
国税庁の一問一答では、特定の取引に係るEDIシステムを利用する場合も「電子取引」に該当すると考えられるとしています*2。インターネット上にサイトを設け、そのサイトを通じて取引情報を授受する取引も電子取引に含まれます*1。つまりBtoB ECサイト経由で出荷案内を出す場合も、EDIシステム経由で出す場合も、取引情報が載る限りは同じ保存義務の対象になります。
検索機能の確保:取引年月日その他の日付・取引金額・取引先
電子取引の取引情報を保存する際は、次の検索機能を確保する必要があります。第一に、取引年月日その他の日付・取引金額・取引先を検索条件に設定できること。第二に、日付又は金額の記録項目について範囲を指定できること。第三に、2つ以上の記録項目を組み合わせて条件を設定できることです*3。税務職員による質問検査権に基づくダウンロードの求めに応じられるようにしている場合は、第二・第三の要件が不要になります。そのうえで判定期間に係る基準期間の売上高が5,000万円以下の事業者であれば、すべての検索機能の要件が不要になります*3。つまり売上高の要件だけで免除されるわけではなく、ダウンロードの求めに応じられる状態が前提になります。この検索要件を満たさない設計のまま保存すると、税務調査の際に必要なデータをすぐに提示できません。その結果、後から保存方法を作り直す手間が発生します。
改ざん防止措置の選び方:訂正削除の記録が残るシステムか、事務処理規程か
電子請求書等の授受に係るクラウドサービスや、特定の取引に係るEDIシステムを利用する場合は、次の措置で要件を満たせます。訂正削除の記録が残るシステム、又は訂正削除ができないシステムを利用して授受・保存していれば、電子取引の保存要件を満たすと考えられます*2。一方、サイトからダウンロードしたデータを自社側で保存するような形態では、受領者側でデータを訂正削除できるため、タイムスタンプの付与又は事務処理規程に基づく管理が必要になります*2。自社のBtoB ECがどちらの形態に当たるかを先に見極めることが、措置の選び方を決める前提です。
通知データの検索要件・改ざん防止措置を自社だけで設計するには、電子帳簿保存法の実務知識と、基幹・WMS側のデータ構造の理解の両方が必要になります。自社の要件を整理するために、無料相談で要件を整理するのも一つの手段です。
出荷案内は荷待ち時間の削減に関わる(物流効率化法)
出荷案内は取引先への配慮だけでなく、自社の法対応にも関わってきます。同法が掲げる目標と、出荷案内の位置づけを見ていきます。
物流効率化法の目標:1運行2時間以内・1回の受渡し1時間以内
物流効率化法は、正式名称「物資の流通の効率化に関する法律」です*6。同法の基本方針が掲げる目標のうち、荷待ち時間・荷役等時間に関わるものは次の2点です。1運行あたりの荷待ち時間・荷役等時間の合計を2時間以内にすること。1回の受渡しごとの荷待ち時間・荷役等時間を1時間以内にすることです*7。これはドライバー1人当たり年間125時間の拘束時間短縮という目標の内訳として示されたもので、事業者ごとに講ずべき措置を定めた判断基準とは別の位置づけになります。納品予定を事前に通知し、受入側が受け入れ準備を整えられる状態にしておくことは、この荷待ち時間の削減に直接関わる打ち手です*7。
荷待ち時間・荷役等時間の定義:何が算入されるか
荷待ち時間とは、ドライバーが集荷・配達する場所やその周辺で、荷主や場所の管理者、連鎖化事業者の都合により貨物の受渡しのために待機した時間です*8。荷役等時間とは、荷積み・荷卸し、検品、荷造り、搬出・搬入、保管、仕分、商品陳列、ラベル貼りなど、運転業務に付帯する作業に従事した時間です*8。出荷案内で納品予定日をあらかじめ共有しておくことは、受入側の検品・荷卸しの準備を早め、この荷待ち時間の発生を抑える方向に働きます。
2026年4月からの特定事業者の義務と、通知設計の位置づけ
物流効率化法は2025年4月から荷主・物流事業者への努力義務が施行されています*6。2026年4月からは、一定規模以上の事業者が「特定事業者」として指定されます。対象は、取扱貨物の重量が9万トン以上の荷主・連鎖化事業者、保有車両150台以上の貨物自動車運送事業者等、保管量70万トン以上の倉庫業者です。これらの特定事業者には、中長期計画の作成・提出と定期報告の提出が義務付けられます。さらに特定事業者のうち荷主には、物流統括管理者(CLO)の選任も義務付けられます*6*7。CLOとは、物流の中長期計画の作成や取引先との調整を統括する役職です。取組が不十分な場合は指導・助言に加えて勧告・命令の対象になる仕組みも用意されています*6。すべての荷主に義務が及ぶわけではありません。努力義務と特定事業者の義務は規模要件で区別されますが、荷待ち時間の削減という方向性そのものは業界全体の課題です。出荷案内の通知設計はその実務的な打ち手の一つになります。
通知手段の選択:メール・マイページ・CSV・EDI
出荷案内をどの手段で送るかは、項目・契機の設計が終わった後に決める順番になります。
メールだけに寄せたときに起きること:到達・保存・検索の弱さ
出荷案内をメールだけに寄せると、到達確認の手段が弱く、迷惑メール判定で取引先の担当者に届かないことがあります。また、メール本文に取引情報を直接記載する設計は、検索要件を満たす形で保存する仕組みを別途用意しない限り、保存義務への対応が後手に回りやすくなります。
マイページ(画面参照)と通知の役割分担
マイページは、取引先が自分の意思で最新の出荷状況を確認できる手段です。通知は「今、何が起きたか」を能動的に伝える役割で、マイページは「いつでも確認できる状態」を保つ役割です。両者を併用し、通知には要点だけを載せ、詳細はマイページで確認する設計にすると、通知内容を絞りやすくなります。
EDI接続を将来やるなら、いま何を揃えておくか
EDI接続を将来検討する場合に、出荷案内側で先に揃えておくべきものは項目名だけではありません。取引先コード・商品コードの体系、梱包単位の粒度、送信の単位(出荷1件か伝票1件か)の3点は、接続時に取り決めが求められる項目です。この3点を出荷案内の設計段階で自社の値として確定しておくと、接続の要件定義がコード対応表の作成だけで済みます。EDIとECサイトの使い分けそのものは別の論点になるため、本稿では出荷案内側の設計に必要な範囲までを扱います。
通知を増やしすぎない線引き
出荷案内以外にも、受注確認・単価改定・パスワード再発行など、BtoB ECには様々な通知が存在します。通知を増やすほど、1件ごとの開封率は下がる傾向にあります。出荷案内はその中でも取引先が必要とする情報に絞り、通知全体の設計思想や配信基盤の話は別のテーマとして扱います。
出荷案内通知の要件定義チェックリスト
ここまでの項目・契機と宛先・保存の3軸を、要件定義の場でそのまま使える形にまとめます。
項目・契機・宛先・保存の4区分でのチェック項目
- 出荷案内に含める必須項目(出荷日・納品予定日・品目・数量)を決めたか
- 任意項目(梱包数・送り状番号)の取得元システムを特定したか
- 独自項目を追加する前に流通BMSの標準メッセージ名を確認したか
- 出荷案内の主契機(出荷指示・出荷確定・集荷完了のいずれか)を1つに決めたか
- 発注者と納品先受入担当を別宛先として扱うかを決めたか
- 分納・欠品・納品予定日変更時の出し分けルールを決めたか
- 通知データが取引情報に該当し得るかを、送り状に通常記載される事項の有無で確認したか
- 検索要件(取引年月日・取引金額・取引先)を満たす保存先を決めたか
- 改ざん防止措置をEC側・基幹側のどちらで持つかを決めたか
RFPに書くときの記述例:機能要件と非機能要件の分け方
RFP(提案依頼書)に「出荷通知メール機能」と一行だけ書くと、項目・契機・保存の要件が伝わりません。機能要件には「出荷確定を契機に、出荷日・納品予定日・品目・数量・送り状番号を通知する」のように契機と項目を明記します。非機能要件に書くのは「通知データを検索要件(取引年月日・取引金額・取引先)を満たす形で保存する」といった条件です。「訂正削除の記録が残る形で保存する」のように、電子帳簿保存法に対応する保存条件も明記します。
まとめ:出荷案内通知を設計する3つの判断軸
本稿ではBtoB ECの出荷案内通知の設計を、項目・契機と宛先・保存の3つの軸に分けて整理しました。要点を3つに集約すると次の通りです。第一に、項目は独自に決めず流通BMSの標準メッセージ名に寄せます。第二に、契機は出荷確定を中心とした単一のタイミングに定め、発注者と納品先受入担当を別宛先として扱います。第三に、通知データが取引情報に該当し得る場合は、検索要件と改ざん防止措置を通知機能の非機能要件に含めます。この3軸が決まれば、要件定義書やRFPにそのまま反映できる状態になります。
自社だけで基幹・WMSとの役割分担や、取引先別の出し分けまで決めきるのは難易度が高い作業です。項目と契機の判断軸を自社の要件に当てはめる段階で、専門知見のあるパートナーと一度整理すると、後からの設計変更を減らせます。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
よくある質問
出荷案内の通知は法律で義務づけられていますか。
出荷案内通知そのものを義務づける法律はありません。ただし、通知に送り状に通常記載される事項が載る場合、電子帳簿保存法上の取引情報に該当し得るため、その場合は保存に関する要件への対応が必要になります*1。
出荷案内メールも保存しなければなりませんか。
出荷案内メールに取引情報(送り状に通常記載される事項)が記載されている場合は、電子取引に係る電磁的記録として保存が必要になります*1*2。記載内容がない、または取引情報に当たらない案内であれば対象外です。個別の判断は税務署や税理士へ確認することをおすすめします。
出荷案内と納品書は同じものですか。
出荷案内と納品書は役割が異なります。出荷案内は出荷が確定した事実と納品予定を伝える通知で、納品書は納品内容を証する書類です。納品書の記載事項や出力の詳細は別テーマとして扱い、本稿では通知としてのデータに限定して解説しています。
出荷案内はいつ送るのが適切ですか。
出荷確定を契機にするのが基本です。出荷確定時点であれば納品予定日を含む正確な情報を1回で送れます。送り状番号を必須とする取引先が多い場合は、集荷完了時点を主契機に据える選択もあります。
出荷案内の項目に決まった標準はありますか。
法的に定められた標準はありませんが、流通BMSという業界標準に「出荷」「出荷梱包(紐付けあり/なし)」「出荷荷姿」という標準メッセージ名が存在します*4*5。義務ではありませんが、独自項目を作る前に確認しておくと将来のEDI接続で手間が減ります。
- *1 出典:国税庁「電子帳簿保存法一問一答【電子取引関係】問2」(令和8年7月)
- *2 出典:国税庁「電子帳簿保存法一問一答【電子取引関係】問5」(令和8年7月)
- *3 出典:国税庁「電子帳簿保存法一問一答【電子取引関係】問48」(令和8年7月)
- *4 出典:GS1 Japan(一般財団法人流通システム開発センター)「流通BMS|EDI(電子データ交換)|標準化活動」
- *5 出典:流通BMS協議会(GS1 Japan)「標準準拠企業・メッセージ一覧」
- *6 出典:国土交通省「物流効率化法について(荷主・物流事業者の皆様へ)」(2026年5月15日更新)
- *7 出典:国土交通省ほか「「物流効率化法」理解促進ポータルサイト」(2025年)
- *8 出典:国土交通省ほか「「荷待ち時間」と「荷役等時間」の算定方法について」(2025年)
画像の出典元
- 曇りの空の下での大型船舶/Photo by Anastasios Antoniadis on Unsplash
- 電子帳簿のイメージ/Photo by Sear Greyson on Unsplash
- 物流のイメージ/Photo by Jacques Dillies on Unsplash
- 要件定義のイメージ/Photo by Vitaly Gariev on Unsplash
- チェックリストのイメージ/Photo by Jakub Żerdzicki on Unsplash