まずは卸売ECを小規模でスタートしたい方へ。リーズナブルなSaaS(ASP)版『EC-Rider Primo(プリモ)』誕生! 詳しくはこちら

BtoB EC納期回答の自動化設計|在庫引当と算式

◆監修・編集責任者 小園 将隆 

B2B EC-COLUMN

この記事のポイント

  • BtoB ECの納期回答の自動化は、在庫引当ロジック・リードタイム算式・例外処理という3つの設計で決まります。
  • 改正物流効率化法と取適法という2つの法改正により、受渡日時とリードタイムの設計が実務論点になっています。
  • 全件自動化を目指さず、確定回答と暫定回答を分けて出す設計が現実的な着地点です。
原因のイメージ
▽ 写真の出典元

BtoB ECの納期回答の自動化とは-引当・リードタイム・例外の3設計で決まる

BtoB ECの納期回答の自動化とは、受注時点の在庫引当の可否と品目別のリードタイムをシステムが計算する仕組みです。人手を介さず、出荷可能日または納品可能日を取引先に提示します。経済産業省の調査では、2024年の国内BtoB-EC市場規模は514.4兆円(前年比10.6%増)です*1。EC化率は43.1%(前年比3.1ポイント増)に達しています。Web受発注の拡大に、納期回答の設計が追いついていない企業が少なくありません。

自動化の成否は、機能の有無ではなく「引当ルール・リードタイム算式・例外の切り分け」という3つの設計をどこまで明文化できるかで決まります。この3点を順に設計すれば、品目や取引条件に応じて自動化できる範囲とできない範囲を切り分けられるようになります。

自動化を決める3要素は引当ロジック・リードタイム算式・例外の切り分け

納期回答の自動化は、3つの要素で構成されます。①在庫引当ロジック(都度引当・予約引当・ATP<受注可能在庫>計算のどれを採るか)。②リードタイムの算式(受注処理から出荷準備・輸送・調達までの構成要素をどう分解するか)。③例外処理の切り分け(特注品や与信保留などをどこで有人対応に切り替えるか)。この3つを個別に設計し、後から組み合わせる進め方が現実的です。

図
納期回答の自動化は受注から回答提示まで5段階で構成されます

なぜ今か:改正物流効率化法と取適法が納期設計を実務論点にした

2026年は、荷主側の納期設計に直接関わる2つの法改正が同時に動く年です。改正物流効率化法(物効法)は施行②が2026年4月1日で、取扱貨物の重量が9万トン以上(上位3,200社程度)の事業者は特定荷主に指定されます。特定荷主には、2026年5月末までの届出と、2026年10月末(初年度のみ)までの中長期計画の提出が求められます*3

この判断基準の解説書には、第一種荷主(貨物の運送を委託する荷主)が取り組むべき事項が明記されています。「適切なリードタイムを確保すること」「受渡日時の集約」「貨物の入出荷時の日時等を分散させること」の3点です*5。EC上の納期回答ロジックは、これらの要件を満たすための実装手段の一つになります。

加えて、下請法の改正法である取適法が2026年1月1日に施行されました。書面交付義務については、中小受託事業者の承諾の有無にかかわらず、電子メールなどの電磁的方法による明示が可能になっています*4。EC上での発注内容の明示と記録が、法的にも運用しやすい形に整ったことになります。

自動化の対象範囲:全件自動を目指さないという前提

納期回答の自動化を検討する際は、最初から全品目・全条件の自動化を目標にしないことが大切です。在庫があり出荷経路が単純な品目から自動化の対象を絞り込み、特注品や与信保留などの例外は有人対応に残す設計のほうが、導入までの手戻りを抑えられます。この線引きの具体的な方法は、設計③(例外処理の切り分け)で扱います。

納期回答が属人化する原因を業務プロセスで特定する

在庫のイメージ
▽ 写真の出典元

納期回答の自動化を設計するうえでは、なぜ属人化が起きているのかを業務プロセス側から特定しておく必要があります。原因を切り分けずにシステム機能だけを追加しても、担当者への問い合わせは減りません。本稿の対象は、納期回答に絞った原因の特定です。

在庫の所在が分かれている(EC・基幹・倉庫で在庫数が一致しない)

納期回答の担当者が電話やメールでの問い合わせに頼らざるを得ない主因の一つは、在庫数を持つシステムが分かれていることです。ECサイト・基幹システム(ERP・販売管理)・倉庫管理システム(WMS)が、それぞれ独自に在庫を保持しているケースがあります。この場合、担当者は複数画面を確認しないと回答できません。本稿が扱うのは、在庫数の同期そのものではなく回答日の算出側です。この課題は、後述する基幹システムとの連携方式の設計に直結する論点です。

リードタイムが担当者の記憶にある(品目別・取引先別・地域別)

もう一つの原因は、品目別・取引先別・地域別のリードタイムが担当者個人の経験則に依存していることです。ベテラン担当者が異動・退職すると、同じ精度で納期回答できなくなるリスクがあります。リードタイムを算式として明文化することで、この属人性を解消できます。

デジタル化の実態:紙・口頭中心が15.4%、業務効率化・データ分析は24.5%

2026年版中小企業白書によると、中小企業のデジタル化の取組段階は次のとおりです(n=12,215、資料出所は帝国データバンク「令和7年度中小企業の経営課題と事業活動に関する調査」)。段階1(紙や口頭による業務が中心)が15.4%、段階2(デジタルツールへ移行中)が57.3%です*2。段階3(業務効率化・データ分析に取り組んでいる)が24.5%、段階4(ビジネスモデルの変革)が2.8%です。約7割の企業が段階1・2にとどまっています。納期回答の自動化以前に、在庫・受注データそのものの一元化が課題になっているケースが多いと考えられます。

なお、この数値は帝国データバンクの調査を中小企業白書が引用したものです。経済産業省が実施した電子商取引に関する市場調査(キーファクトの市場規模・EC化率)とは異なる調査であり、両者を単純に比較することはできません。

ここまで見た課題を自社の在庫・受注データに当てはめて確認したい場合は、無料相談で要件を整理するのが近道です。

設計①:在庫引当のロジックを決める

基幹システムのイメージ
▽ 写真の出典元

納期回答を自動化する最初の設計要素は、在庫引当のロジックです。どの方式を選ぶかによって、システムに必要な機能とデータ更新頻度が変わります。

3つの引当方式(都度引当・予約引当・ATP計算)と選び方

在庫引当の方式は大きく3種類です。都度引当は、受注のたびに現在庫数を確認して引き当てます。予約引当では、将来の入荷予定を含めて事前に枠を確保します。ATP(Available To Promise、受注可能在庫)計算は、現在庫に入荷予定・出荷予定を加減算し「今どれだけ約束できるか」を都度算出する方式です。品目の入荷サイクルが短く在庫回転が速い商材は、都度引当で足りることが多くなります。受注生産や長納期部材が混在する商材で有効なのは、ATP計算です。

方式 仕組み 向く商材 実装負荷
都度引当 受注時点の現在庫数から即座に引き当てる。 在庫回転が速く入荷サイクルが短い定番品。 低い。在庫マスタの参照のみで実装できる。
予約引当 入荷予定を含めて事前に枠を確保する。 季節品・キャンペーン品など需要が読める商材。 中程度。入荷予定データとの連携が必要になる。
ATP計算(受注可能在庫) 現在庫に入荷・出荷予定を加減算して都度算出する。 受注生産・長納期部材が混在する商材。 高い。入出荷予定・生産計画との連携が要る。

引当の優先順位を決める(先着順・取引先ランク・出荷日順)

複数の受注が同じ在庫を取り合う場合、引当の優先順位をあらかじめ決めておく必要があります。代表的な基準は、受注日時が早い順(先着順)、取引先の契約条件によるランク、指定納品日が近い順の3つです。優先順位のルールが未設定だと、同一在庫に対して複数の確定回答を出してしまい、後から取り消す事態につながります。

在庫の見せ方:実数か記号か(取引先別の開示範囲切り替え)

在庫引当のロジックとあわせて、在庫数をどこまで開示するかも設計事項です。正確な在庫数を見せると発注のタイミングを読まれやすくなる一方、記号表示(「◯・△・×」等)だけでは納期の精度が伝わりません。取引先の契約条件によって開示範囲を切り替える設計にすると、両方の要件を両立しやすくなります。

設計②:リードタイムを算式に分解する

連携のイメージ
▽ 写真の出典元

2つ目の設計要素は、リードタイムを構成要素ごとに分解し、算式として扱えるようにすることです。ここが属人化を解消する核心部分になります。

リードタイムの構成要素:受注処理・引当・出荷準備・輸送・調達

リードタイムは、受注処理時間・在庫引当の判定時間・出荷準備(ピッキング・検品・梱包)時間・輸送時間の合計です。これに、在庫不足時の調達・生産リードタイムが加わります。この構成要素を洗い出し、それぞれの所要時間を品目別・拠点別に登録しておけば、担当者の記憶に頼る必要はありません。なお、業界共通の「一般的な日数」は一次情報が存在しないため、基準にすべきなのは自社の実測値です。

回答日の丸め規則:出荷締め時刻・営業日カレンダー・休配日

算式で日数を算出しても、そのままでは実際の回答日になりません。出荷締め時刻を過ぎた受注は翌営業日扱いにする、土日・祝日・自社休配日をカレンダーから除外するといった丸め規則が必要です。この丸め規則が抜けていると、システムが計算した納期と実際に出荷できる日がずれる原因になります。

「適切なリードタイムの確保」を判断基準の原文から設計要件に翻訳する

国土交通省の物効法判断基準の解説書は、第一種荷主が取り組むべき事項を挙げています。「貨物の運送の委託から貨物の受渡しまでの間に、トラック事業者が他の貨物との積合せなど積載効率の向上等に係る措置を講ずるために必要な時間を把握すること等により、適切なリードタイムを確保すること」です*5

これをEC上の納期回答ロジックに翻訳すると、運送事業者側の積合せ・配車調整に必要な時間を、算式の中の輸送リードタイムに組み込むことを意味します。短納期の回答を機械的に返すのではなく、運送事業者が積載効率を高める余地を残した日数設定にすることが、法令が求める方向性と整合します。

受渡日時の集約・分散を回答ロジックに組み込む

同解説書は、他の事項も判断基準に含めています。「貨物の量の平準化、受渡日時の集約等により、貨物の出入荷量の適正化を図ること」、そして「一時に多数のトラックが集中して到着しないよう…貨物の入出荷時の日時等を分散させること」です*5

納期回答システムでこれを実装するには、候補日を1日だけ提示せず、複数の候補日(受渡日時が集約・分散できる日)を選択肢として示す設計が有効です。取引先に日時の幅を提示できれば、特定日への集中を避けながら、物効法が求める適正化にも沿った運用がしやすくなります。

設計③:自動回答しない例外を切り分ける

導入のイメージ
▽ 写真の出典元

3つ目の設計要素は、システムが自動で回答しない例外をあらかじめ定義することです。ここを曖昧にすると、誤った確定回答を出してしまうリスクが残ります。

例外の型:特注品・受注生産品・分割納品・在庫欠品・与信保留

自動回答から外すべき代表的な例外は5類型あります。仕様確定に個別調整が必要な特注品、受注してから生産する受注生産品、複数回に分けて納品する分割納品の3つです。加えて、在庫が確保できていない欠品品目、そして与信枠を超えている与信保留取引先も対象になります。この5類型を有人対応の対象として明示しておけば、システムが判断に迷う受注は機械的に振り分け可能です。

「確定回答」と「暫定回答」を分けて出す

例外に該当する受注であっても、納期の見通しを何も示さないと取引先の不満につながります。在庫引当が確定していない段階では「暫定回答(目安の日数)」として表示し、担当者の確認後に「確定回答」へ更新する2段階の表示ルールを設けることが実務的です。暫定回答であることが取引先にも分かるよう、表示上の区別を明確にする必要があります。

有人エスカレーションの導線と応答時間の決め方

例外として切り分けた受注は、誰が・どのくらいの時間内に確認するのかを決めておく必要があります。エスカレーション先の部門・担当者と、確認から暫定回答更新までの目標時間をあらかじめ定義しておくことが、滞留を防ぐ条件です。この設計を怠ると、自動化した部分の効果が例外処理の遅延で相殺されてしまいます。

この例外処理をどこまで自社で作り込めるかを判断するには、必要スキル・工数を把握しておく必要があります。設計に必要な知識は、在庫引当ロジックの設計・リードタイム算式の構築・基幹システムとの連携仕様の整理という3領域です。社内の受注担当・情報システム担当だけで賄うのは、負荷が大きい場合があります。要件を誤ると、確定回答と実際の出荷日がずれ続け、取引先からの信頼低下につながるおそれもあります。

基幹システム連携はリアルタイムAPI・定期バッチ・中間テーブルの3方式から選ぶ

在庫引当とリードタイムの設計ができても、実際の在庫データを持つ基幹システム(ERP・販売管理・WMS)との連携方式が固まらなければ、納期回答は自動化できません。

なお、企業間の受発注を標準化したEDIとして、GS1 Japan(一般財団法人流通システム開発センター)の流通BMS(流通ビジネスメッセージ標準)があります。基本形Ver.1.0は発注・出荷・受領・返品・請求・支払の6業務8種の標準メッセージで構成され、2007年4月に公開されました*6。この6業務に納期回答は含まれないため、取引先へ出荷可能日を返す仕組みは、標準メッセージの外側で自社が設計する領域になります。

連携方式の比較:リアルタイムAPI・定期バッチ・中間テーブル

基幹システムとの連携方式は、リアルタイムAPI連携、定期バッチ連携、中間テーブル経由の3つに大別できます。リアルタイムAPI連携は在庫数の鮮度が最も高い一方、基幹システム側の改修負荷が大きくなりがちです。定期バッチは実装しやすい反面、更新間隔の分だけ在庫数にずれが生じます。中間テーブル方式は、基幹システムの改修を最小限にしながら段階的に連携範囲を広げられる折衷案です。

連携方式 在庫の鮮度 実装負荷 注意点
リアルタイムAPI連携 高い。受注の都度、最新在庫を参照できる。 高い。基幹システム側にAPIが無ければ追加開発が要る。 基幹システムの処理負荷・同時アクセス数を事前に確認する必要がある。
定期バッチ連携 更新間隔(例:1日数回)に応じて低下する。 低い。既存の連携基盤で対応できることが多い。 更新間隔と実在庫のずれを、丸め規則や暫定回答で吸収する設計が要る。
中間テーブル経由 中程度。連携範囲を段階的に広げやすい。 中程度。中間テーブルの設計・保守が追加で発生する。 中間テーブルへの反映漏れが起きないよう、整合性チェックの仕組みが要る。

在庫の鮮度をどこまで求めるか(更新間隔と回答精度のトレードオフ)

在庫の更新間隔を短くするほど回答精度は上がりますが、基幹システムへの負荷や開発コストも増えます。ただし、すべての品目に同じ鮮度を求める設計は過剰です。受注頻度が高い主力品目はリアルタイムに近い連携にし、それ以外は定期バッチで運用するといった品目別の切り分けが、現実的な落とし所になります。

連携できないときの現実解(EC側で引当可能数を持つ設計)

基幹システムの改修がすぐには進められない場合、EC側に「引当可能数」という社内管理用の在庫バッファを持たせる方法があります。定期的に基幹システムの在庫数と突き合わせて調整する設計が現実的です。基幹システムそのものを変更せずに始められるため、段階的な導入計画(次章で扱います)とも相性がよい方法です。

段階導入の進め方と、取適法・物効法で残すべき記録

ここまでの3つの設計要素と連携方式を踏まえ、実際にどう導入を進めるか、そして法令対応としてどのような記録を残すべきかを整理します。

段階的な進め方:対象品目の絞り込みから確定回答へ

納期回答の自動化は、いきなり全品目を対象にしない進め方が現実的です。対象品目を絞り込み、まず暫定回答から始めて、精度が確認できた範囲を確定回答に切り替えていきます。在庫回転が速く在庫引当ロジックが単純な品目から着手すれば、早い段階で効果を確認しながら対象範囲を広げられます。

回答精度の測り方(回答納期と実出荷日の差分をKPIにする)

自動化の効果を検証するには、システムが回答した納期と実際の出荷日との差分を継続的に記録し、KPIとして追跡することが有効です。差分が大きい品目や取引先が分かれば、リードタイム算式の見直しや、例外処理への振り分け条件の調整に役立ちます。

発注内容の明示と記録の保存:取適法で押さえる要点

公正取引委員会のリーフレットによると、取適法では委託事業者に4つの義務と11の遵守事項が課されています*4。このうち、納期回答の設計と関わる4つの義務は次のとおりです。第一に、発注内容(給付の内容・代金の額・支払期日・支払方法)等を書面または電磁的方法により明示しなければなりません。第二に、取引に関する記録を書類または電磁的記録として作成し、2年間保存する義務です。第三に、発注した物品等を受領した日から起算して60日以内のできる限り短い期間内で支払期日を定めます。第四に、支払遅延や減額等を行った場合は、遅延した日数や減じた額に応じて遅延利息(年率14.6%)を支払う義務です*4

これらの義務は書面交付義務についてのみ、中小受託事業者の承諾の有無にかかわらず電子メールなどの電磁的方法によることが可能になった点が2026年の改正点です*4。BtoB ECで納期回答とあわせて発注内容の明示・記録保存をシステム化しておけば、この義務を運用の一部として満たしやすくなります。

特定荷主は中長期計画・定期報告に接続する

取扱貨物の重量が9万トン以上(上位3,200社程度)の事業者は、改正物効法の特定荷主・特定連鎖化事業者に指定されます*3。2026年4月1日の施行後、2026年5月末までに届出、2026年10月末(初年度のみ、以降は7月末〆)までに中長期計画の提出が求められます。

納期回答の自動化で組み込んだ受渡日時の集約・分散、リードタイムの確保に関する設計は、この中長期計画に記載する具体施策の裏づけとしても活用できます。システム設計と法令対応を別々に進めるのではなく、同じ実装を両方の目的に接続する視点が欠かせません。

まとめ:納期回答の自動化を決める3つの設計軸

本稿では、BtoB ECの納期回答を自動化するための設計を、在庫引当ロジック・リードタイム算式・例外処理の3軸で整理しました。要点を3つに集約すると、第一に、在庫引当は都度引当・予約引当・ATP計算のいずれかを商材特性に応じて選ぶこと。第二に、リードタイムは構成要素に分解し、丸め規則とあわせて算式化すること。第三に、特注品や与信保留などの例外は確定回答と暫定回答を分けて有人対応に残すことです。この3軸を明文化できれば、自社の品目・在庫状況に応じて自動化できる範囲とできない範囲を切り分けられます。

導入前に確認する優先順5点/順位根拠:着手順序の依存関係

  1. 在庫データがEC・基幹・倉庫のどこに、どの精度であるかを棚卸しする。
  2. 品目ごとに都度引当・予約引当・ATP計算のどれが向くかを分類する。
  3. 受注処理から輸送までのリードタイム構成要素を品目別・拠点別に洗い出す。
  4. 特注品・受注生産品・分割納品・在庫欠品・与信保留の5類型を例外として定義する。
  5. 基幹システムとの連携方式(リアルタイムAPI・定期バッチ・中間テーブル)を品目の重要度に応じて選ぶ。


ご不明な点はお問い合わせフォームからもご連絡いただけます。

BtoB通販システムのご相談

貴社の商習慣に合わせたご提案をいたします。

無料相談はこちら

よくある質問

在庫がない商品の納期はどう回答すればよいですか。

在庫が無い品目は、都度引当だけでなくATP(受注可能在庫)計算に切り替え、調達・生産のリードタイムを加算して回答します。調達先の納期が変動しやすい品目は、確定回答ではなく暫定回答として提示し、確定後に更新する運用が現実的です。

基幹システムと連携しないと納期回答は自動化できませんか。

連携が難しい場合でも、EC側に引当可能数という社内管理用の在庫バッファを持たせ、定期的に基幹システムの在庫数と突き合わせる方法で始められます。基幹システムの改修を待たずに、対象品目を絞って着手することが可能です。

自動回答した納期を守れなかった場合はどうすればよいですか。

確定回答と暫定回答を明確に分けておくことが前提です。確定回答後に守れない事態が生じた場合は、有人エスカレーションの導線であらかじめ定めた担当者・応答時間に沿って速やかに取引先へ連絡します。そのうえで、リードタイム算式や在庫バッファの見直しにつなげます。

納期回答の自動化にはどのくらいの期間がかかりますか。

対象品目の絞り込み、在庫引当ロジックの設計、基幹システムとの連携方式の確定という3つの工程が必要です。具体的な期間は品目数や連携方式によって異なるため、まずは自社の在庫データの棚卸しから着手することをおすすめします。

◆監修・編集責任者

小園 将隆

株式会社フライトソリューションズ ECサービス部 マネージャー

BtoB通販のパッケージシステム「EC-Rider B2B Ⅱ」の導入支援をはじめ、製造業、卸売業をはじめとした法人向け通販サイト構築を多数手掛ける。卸売領域の専門知識をもとに、日本の商習慣に固有の課題をパッケージシステムの機能追加によって解決。BtoB流通の販路拡大を支援する。

  1. *1 出典:経済産業省「令和6年度電子商取引に関する市場調査」(2025年8月26日公表) https://www.meti.go.jp/press/2025/08/20250826005/20250826005.html
  2. *2 出典:中小企業庁「2026年版 中小企業白書・小規模企業白書の概要」(2026年4月公表、資料出所:株式会社帝国データバンク「令和7年度中小企業の経営課題と事業活動に関する調査」) https://www.chusho.meti.go.jp/pamflet/hakusyo/2026/PDF/2026gaiyou.pdf
  3. *3 出典:国土交通省・経済産業省・農林水産省「改正物効法に基づく特定事業者の対応について」(2025年9月17日・18日) https://www.meti.go.jp/policy/economy/distribution/250917-18_material.pdf
  4. *4 出典:公正取引委員会「取適法リーフレットNo.01」(令和7年8月) https://www.jftc.go.jp/file/toriteki_leaflet.pdf
  5. *5 出典:国土交通省「荷主等の判断基準に関する解説書(物流効率化法)」(2026年3月) https://www.mlit.go.jp/seisakutokatsu/freight/content/001984869.pdf
  6. *6 出典:GS1 Japan(一般財団法人流通システム開発センター)「流通BMS」 https://www.gs1jp.org/standard/edi/ryutsu-bms.html

画像の出典元

  1. 原因のイメージ/Photo by Agence Olloweb on Unsplash
  2. 在庫のイメージ/Photo by Lance Chang on Unsplash
  3. 基幹システムのイメージ/Photo by Tyler on Unsplash
  4. 連携のイメージ/Photo by Milad Fakurian on Unsplash
  5. 導入のイメージ/Photo by ThisisEngineering on Unsplash

◆この記事について

独自調査以外の一次情報は、省庁・公的機関を中心とした信頼性の高い情報源から引用し、出典を明記しています。
年次更新される統計については、引用元の最新版を確認したうえで掲載しています。

※この記事は上記の監修・編集責任者がAIの協力を得て制作しています。

監修確認日:

記事内容に関するお問い合わせ:お問い合わせフォーム

BtoB EC(受発注)サイト構築システム「EC-Rider B2B Ⅱ」への
各種お問い合わせ

ページTOPへ戻る
無料相談を予約 お見積
平日10:00~18:00
page
top