物流・卸売業の受発注・在庫管理、SaaSの限界からフルスクラッチ刷新を考える【2026年8月版】
「クラウド型WMS（倉庫管理システム）を入れたのに、結局Excelとの二重入力が残っている」「取引先ごとにEDIの形式が違って、システムを増やすたびに設定が増えていく」——物流・卸売業の受発注・在庫管理の現場から、こうした声をよく伺います。
2026年4月には改正物流効率化法が本格施行され、一定規模以上の荷主・物流事業者には物流統括管理者（CLO）の選任や中長期計画の提出が義務化されました。「2024年問題」への対応が一段落した企業でも、次は「業務そのものの効率化」という宿題に向き合う段階に入っています。
クラウド型WMSやSaaS型の受発注システムは、導入のしやすさから中小の物流・卸売企業でも広く使われるようになりました。ただし、複数拠点の在庫を横断で見たい、取引先ごとに異なるEDI形式に対応したい、自社の商慣行に合わせた画面にしたい——といった要件が積み重なると、標準機能だけでは対応しきれない場面が出てきます。
この記事では、SaaS型WMS・受発注システムがどこで限界を迎えやすいのか、そして限界を感じたときに何を検討すればいいのかを、発注者目線で整理します。
先に、この記事の結論をまとめます。
- クラウド型WMSは月額1万〜15万円程度から始められる手軽さが利点だが、取引先ごとに異なるEDI形式への対応や複数拠点の横断管理では、標準機能・汎用プラグインだけでは対応しきれないことがある
- 2026年4月施行の改正物流効率化法により、一定規模の事業者は中長期計画の提出（初回は2026年10月末期限）が義務化され、システムの整備状況を対外的に説明する場面が増えている
- 「SaaSでは限界」と感じたら、全業務を作り直すのではなく、周辺業務はSaaSのまま残し、EDI連携や複数拠点在庫の一元化など核となる部分だけをフルスクラッチで作り込む選択肢がある
※本記事は2026年8月時点の公開情報にもとづく整理です。統計・料金は変動するため、最新の一次情報とあわせてご確認ください。
なぜ今、物流・卸売業でシステムの見直しが必要なのか？
2024年問題への対応が「意識改革」から「構造改革」の段階に移り、あわせて2026年4月に改正物流効率化法が本格施行されたことで、業務効率化そのものへの取り組みが対外的にも問われる段階に入っています。
物流業界では、2024年4月の時間外労働上限規制（年960時間）施行から、意識改革フェーズ（2024年）・移行期間（2025年）を経て、2026年は構造改革フェーズに位置づけられています。荷待ち・荷役時間の削減や積載効率の向上といった根本課題は、依然として解決しきれていないという指摘もあります。
あわせて2026年4月には、改正物流効率化法が第二段階施行されました。年間取扱貨物量9万トン以上の荷主等が「特定事業者」に指定され、次が義務化されています。
- 物流統括管理者（CLO）の選任
- 中長期計画の作成・提出（初回提出期限は2026年10月末）
- 定期報告書の提出
未対応の場合は勧告・命令の対象になります。2025年4月にはすべての荷主に対して、荷待ち・荷役時間の短縮などの努力義務も先行して施行されています。
輸送力不足の見通しは、当初の試算（2030年度に対策なしで34%不足）から下方修正され、2026年3月の検討会では「2024年問題対応で34%のうち約14%は克服できた」と評価されました。現在の見通しは2030年度に平均約7%〜最大約25%の不足とされています。数字が改善したとはいえ、不足そのものが解消したわけではなく、輸配送の効率化を業務・システムの両面でどこまで進められるかが、引き続き問われている状況です。
こうした背景から、これまで「まずは動けばいい」で導入してきたクラウド型WMSや受発注システムについても、「この先の事業規模・取引先数の拡大に耐えられる作りになっているか」を見直すタイミングに来ている企業が増えています。
クラウド型WMS・受発注SaaSで何が起きるか？
クラウド型WMSは月額1万〜15万円程度からと導入しやすい一方、取引先ごとに異なるEDI形式への対応や、複数拠点の在庫を横断して見る要件では、標準機能だけでは対応しきれないことがあります。
クラウド型WMSの市場は拡大が続いており、日本国内のWMS市場規模は2025年に3億8,080万米ドル、2034年までに28億2,990万米ドルへ拡大すると予測されています（年平均成長率24.97%、市場調査レポートより）。ロジザードZERO・ロジクラ・クラウドロジといった主要サービスが、業態やEC・通販特化などの切り口でシェアを広げています。
料金相場は、クラウド型で月額1万〜15万円程度、初期費用は数万円程度からというケースが多く、オンプレミス型（初期費用1,000万円〜数千万円、月額20万円以上が目安）と比べると、導入のハードルは大きく下がっています。
ただし、次のような場面で限界が表面化することがあります。
- 取引先ごとに異なるEDI形式への対応: 従来型のWMSでは、取引先ごとに異なる通信手順・手段（流通BMS対応等）に、都度の設備増強・アプリ改修が必要になることがあります。専用設備の準備に個別対応の期間とコストがかかり、EDI通信コスト自体もユーザー負担で発生するため、取引先が増えるほど月次経費が変動しやすくなります
- 複数拠点・複数ベンダーの横断管理: API・CSV・EDIなど複数の連携方式を一つの基盤で扱える設計になっていないと、拠点ごと・ベンダーごとに個別対応が必要になり、在庫状況をリアルタイムで横断して把握することが難しくなります
- 業務プロセス自体が変わらない: ツール・パッケージを導入しても、既存の業務プロセス自体を見直さないまま運用してしまい、期待したほどの生産性向上につながらないケースが少なくないと指摘されています。「既存システムをどう変えていいか分からない」「IT人材が不在」という悩みは、中小企業に共通する典型的な壁です
これらは「SaaSが悪い」という話ではありません。汎用的なクラウドサービスが前提とする運用と、自社の取引先構成・拠点数・商慣行との間にズレがあるときに表面化する、という理解が実務的です。
「SaaSの限界」を感じたら、何から検討すべきか？
まず自社の運用のどこがボトルネックになっているかを切り分けることが第一歩です。全業務をフルスクラッチに置き換える必要はなく、周辺業務はSaaSのまま残し、核となる部分だけを作り込む選択肢もあります。
- ボトルネックの特定: 「EDI形式の違いへの対応に手間がかかっている」のか、「複数拠点の在庫を横断で見られない」のか、「他システムとの連携でデータの二重入力が発生している」のか。原因によって解決策が変わります。ここを曖昧にしたまま「とりあえずフルスクラッチにする」と決めてしまうと、本来SaaS側の設定変更や運用改善で解決できた問題まで、大規模な開発対象にしてしまうリスクがあります
- 周辺業務とコア業務の切り分け: 経理・勤怠管理などの定型業務はSaaSのまま残し、EDI連携や複数拠点の在庫一元化など、自社の商慣行に直結する部分だけをフルスクラッチで作り込む、という併用が現実的です。「全部を作り直す」と「全部SaaSのまま我慢する」の間には、幅広い選択肢があります
- 段階的な移行: 一度に全システムを置き換えるのではなく、影響の大きい業務から順に移行することで、リスクとコストを抑えられます。最初の移行対象は、最も業務への影響が大きく、かつ効果が見えやすい範囲を選ぶのが定石です
実際に、当社が卸売企業様（非公開）向けに構築した事例では、商品登録・タグ付け・説明文作成をすべて手作業で行っていた運用を、商品データの一括取り込みと自動登録、AIによるタグ・説明文の草稿生成に置き換えました。ポイントは、生成されたタグや説明文をそのまま確定させず、担当者が確認・修正してから反映する運用フローを残したことです。全自動化を目指すのではなく、「人が最後に判断する部分」を明確に残す設計が、現場に受け入れられる分かれ目になります。詳細は卸売の商品登録自動化システム＋AIタグ付け・商品説明でも紹介しています。
物流・卸売業のシステム刷新判断フロー。SaaSの限界を感じたら、まずボトルネックが「EDI形式対応」「複数拠点の横断管理」「他システム連携」のどれかを切り分け、周辺業務はSaaSのまま残しつつ核心部分だけをフルスクラッチで作り込む段階的な進め方を示す
他システムとの連携で起きがちな問題
受発注・在庫管理は、会計ソフトや配送管理システムなど、他のシステムと連携して初めて業務全体が回ります。連携が不十分だと、データの二重入力という見えにくいコストが発生します。
複数のシステムを組み合わせて運用していると、次のような問題が起きがちです。
- データの二重入力: 受発注システムと会計ソフトが連携していないと、同じ情報を両方に手入力する手間が発生します。入力ミス・入力漏れによるデータの不整合を招く原因にもなり、営業所と経理部のように部署をまたいで同じ情報を別々に入力しているケースは特に見落とされがちです
- 連携できる範囲の制約: SaaS同士の連携はAPIやCSV連携で実現されることが多いですが、対応していないシステムの組み合わせや、連携できても一部の項目しか同期できないケースがあります
- リアルタイム性の欠如: CSV連携の場合、日次・週次などのバッチ処理でデータを同期することが多く、リアルタイムでの在庫状況把握が難しいことがあります。出荷判断や発注判断をリアルタイムのデータで行いたい場合、このタイムラグが業務上の支障になることがあります
- EDI通信コストの積み上がり: 取引先ごとに異なるEDI規格・通信手段が必要になると、そのたびに設備増強や個別のアプリ改修が発生し、通信コストも取引先の数に応じて積み上がっていきます
API連携が可能な組み合わせであれば、出荷・入荷情報を自動で会計システムに反映し、二重入力を解消できます。ただし、自社が使っているシステムの組み合わせがAPI連携に対応しているかどうかは、事前の確認が必要です。対応していない組み合わせの場合、連携部分だけをフルスクラッチで開発し、間を橋渡しする、という選択肢も検討の余地があります。
インフラ構成の選び方という観点では、Next.js × Supabase × Vercelで作る業務システム開発のように、受発注・在庫管理の基盤をシンプルな構成で作る事例も増えています。
AI活用で受発注・在庫管理はどこまで自動化できるか？
需要予測・配送ルート最適化・帳票処理の分野では、AI活用が実証段階から実運用フェーズに移りつつあります。ただし精度を左右するのは、AIモデルそのものより元データの整備状況です。
2026年時点で、物流・卸売業のAI活用は次のような領域で実運用が進んでいます。
- 配送ルートの最適化: 納品先の位置・時間指定・車両積載率・リアルタイムの交通渋滞情報を統合分析し、最短ルートを自動生成する事例では、配送コストの削減効果が報告されています
- 需要予測: 季節変動や外部要因を考慮した発注自動化の実装が進んでいます
- 帳票処理の効率化: AI-OCRによる手書き帳票の読み取りで、入力にかかる作業時間を大幅に削減した事例が報告されています
ただし、AIによる需要予測や自動発注の精度は、元になる受発注・在庫データがどれだけ正確に、リアルタイムに近い形で蓄積されているかに左右されます。受発注・在庫管理のシステムがEDI形式の違いや拠点間の連携不備で分断されたままだと、AIに読ませるデータ自体が欠けたり遅れたりして、期待した精度が出ないことがあります。AI活用を見据えるほど、まず土台となる受発注・在庫データを一元的に扱える基盤を整えることの重要性が増します。
SaaSからフルスクラッチへ移行する場合の進め方
いきなり全システムを置き換えるのではなく、最も課題を感じている業務から段階的に移行するのが現実的です。
- 現状の運用を棚卸しする: どのSaaSを、何のために、誰が使っているかを整理します。あわせて、データの二重入力や個別対応のEDI連携がどこで発生しているかも洗い出します。現場担当者へのヒアリングを丁寧に行うことが、後の設計の精度を左右します
- ボトルネックを特定する: EDI形式の個別対応なのか、複数拠点の横断管理なのか、他システムとの連携なのか。原因によって、移行すべき範囲・優先順位が変わります
- 移行範囲を決める: 全業務を一度に置き換えるのではなく、最も課題が大きい業務から着手します。範囲を絞ることで、移行にかかる期間・費用のコントロールがしやすくなります
- 並行運用の期間を設ける: 新システムと旧システム（SaaS）を並行して稼働させ、データの整合性を確認しながら段階的に切り替えます。並行運用の期間を短く切り上げすぎると、想定外の不具合に対応する余裕がなくなるため、十分な検証期間を確保することをおすすめします
- 周辺業務との連携を設計する: 移行した業務と、引き続きSaaSで運用する業務との間のデータ連携を設計します。ここを軽視すると、移行後も結局データの二重入力が残ってしまい、当初の目的が達成できません
この進め方であれば、業務を止めることなく、段階的にフルスクラッチへの移行を進められます。急いで一度に全部を切り替えようとすると、現場の混乱や想定外のトラブルにつながりやすいため、焦らず段階を踏むことが結果的に近道になります。
老朽化した基幹システム全体の刷新を検討する段階であれば、老朽化した社内システムをいつ・どう刷新するかの判断基準もあわせてご覧ください。
発注先を選ぶときに確認しておきたいこと
SaaSの限界に対応した開発を依頼する場合、「なぜSaaSでは対応できないのか」を正しく理解した上で提案してくれる発注先を選ぶことが重要です。
- ボトルネックの診断力: 「SaaSの限界」と一言でいっても原因は様々です。EDI形式の個別対応なのか、複数拠点管理なのか、他システム連携なのかを正確に診断できるか。「とりあえず全部フルスクラッチにしましょう」という提案しかできない発注先は、診断が不十分な可能性があります
- 既存SaaSとの共存設計: 全部をフルスクラッチに置き換えるのではなく、周辺業務はSaaSのまま残す設計を提案できるか。既存のSaaS運用を無理に否定せず、必要な部分だけを見極める提案力が重要です
- EDI・API連携の実績: 既存のSaaSやシステムとのデータ連携、移行作業の実績があるか。連携部分の設計・実装は、想定以上に手間がかかることが多い工程です
- 物流・卸売業の業務理解: 取引先ごとのEDI形式の違い、複数拠点の在庫管理、商流と物流が分かれる卸売特有の商慣行を理解した上で設計できるか
- 段階的な移行提案: 一括での全面刷新だけでなく、影響の大きい業務から順に区切って進める提案ができるか
SaaSの限界を感じている部分を具体的に伝えられる状態で相談すると、発注先とのすり合わせがスムーズに進みます。「何がどう困っているか」を事前に整理しておくことは、見積もりの精度を上げることにもつながります。
なお、フルスクラッチでの全面刷新は少し大きい、もっと軽く始めたいという場合は、業種別パッケージ×スクラッチの組み合わせで、バーコード・WMSによる入出庫管理から着手する規模感もあります。参考: 物流倉庫の在庫差異をなくす｜バーコード・WMSで入出庫を正確に管理する方法（よりどころべーす）。
SaaSの月額費用と、移行にかかる費用感の考え方
SaaSは月額費用が積み重なる料金体系、フルスクラッチは初期費用がまとまってかかる料金体系という違いがあります。長期的な視点で比較することをおすすめします。
クラウド型WMS・受発注SaaSは、初期費用を抑えて始められる一方、月額利用料・EDI通信コストが継続的にかかります。取引先数や拠点数が増えるほど、月額費用も積み上がっていく傾向があります。実際に、ユーザー数・取引先数の増加に伴って、当初想定の3倍までランニングコストが膨らんだ事例も紹介されています。
一方でフルスクラッチは、初期の開発費用はまとまった金額になりますが、その後の月額費用は保守費用程度に抑えられることが一般的です。長期的に見ると、次のような視点で比較することが現実的です。
- 今後何年、その業務システムを使い続ける予定か: 短期的な利用であればSaaSの月額費用の方が有利なことが多く、長期的に使い続ける前提であれば、初期投資をかけてでもフルスクラッチにする方が総コストを抑えられることがあります
- 取引先数・拠点数の拡大予定: SaaSは取引先数・利用範囲に応じて費用が増える料金体系が多く、事業の拡大とともに月額費用も増加します
- EDI対応・連携の積み重ね状況: 既に複数のEDI形式・外部連携を個別対応で積み重ねている場合、その運用・保守にかかっている見えないコスト（担当者の工数等）も含めて比較することをおすすめします
パッケージ型の基幹システム（大塚商会「スーパーカクテルCore」、アイル「アラジンオフィス」等）は、いずれも料金が個別見積り制で、標準機能でどこまでカバーできるかによって費用感が大きく変わります。自社の商慣行が標準機能からどれだけ外れているかを、早い段階で発注先とすり合わせることが、見積もり精度を上げる近道です。
ちなみに、システム開発全体の見積もりの読み方についてはシステム開発の見積書、どう読む？で整理しています。
よくある質問
Q. クラウド型WMSをやめて、全部フルスクラッチにすべきですか？
A. 必ずしもそうとは限りません。クラウド型WMSが対応できている業務はそのまま残し、EDI形式の個別対応や複数拠点の横断管理など、SaaSでは解決しにくい部分だけをフルスクラッチで補う、という併用も現実的な選択肢です。まずはボトルネックがどこにあるかを切り分けることをおすすめします。
Q. 改正物流効率化法のCLO選任・中長期計画の提出は、うちの会社も対象になりますか？
A. 年間取扱貨物量9万トン以上の荷主・貨物自動車運送事業者・倉庫業者等が「特定事業者」として対象になります。該当するかどうかは規模・業態によって異なるため、国土交通省の物流効率化法ポータルで最新の対象要件を確認することをおすすめします。なお、対象規模に満たない事業者にも、荷待ち・荷役時間短縮などの努力義務は課されています。
Q. 取引先ごとにEDI形式が違うのは、システムを変えれば解決しますか？
A. システム側の対応力に左右される部分はありますが、完全にゼロになるとは限りません。取引先の数が多いほど、複数のEDI規格・通信手段に対応できる基盤設計が重要になります。自社開発であれば、頻度の高い取引先の形式を優先的に自動化し、稀な形式は個別対応に留めるといった、費用対効果を意識した段階的な対応も可能です。
Q. AI活用を見据えて、まず何から整備すべきですか？
A. 受発注・在庫データを正確かつリアルタイムに近い形で一元管理できる基盤を、まず整えることをおすすめします。需要予測や自動発注のAIは、元データが分断されていたり遅れていたりすると、期待した精度が出ません。データ基盤の整備が、AI活用の土台になります。
Q. まずは何から相談すればいいですか？
A. 「SaaSのどこに限界を感じているか」を具体的に整理した状態でご相談いただけると、話が早く進みます。EDI形式の対応・複数拠点管理・他システム連携など、症状ごとに解決のアプローチが変わるためです。
まとめ：物流・卸売業のシステム刷新は「切り分け」から始まる
この記事を読んで、自社の受発注・在庫管理のどこにボトルネックがあるか、当てはめながら考えるきっかけにしていただければと思います。
最後に、本記事の要点を整理します。
- クラウド型WMSは月額1万〜15万円程度から導入できる手軽さがある一方、取引先ごとに異なるEDI形式への対応や複数拠点の横断管理では限界を迎えることがある
- 2026年4月施行の改正物流効率化法により、一定規模の事業者はCLO選任・中長期計画の提出が義務化された。対象外の事業者にも努力義務があり、業務効率化への取り組みが対外的にも問われる段階に入っている
- これはツールの欠陥ではなく、汎用的なSaaSが前提とする運用と、自社の取引先構成・拠点数・商慣行との間にズレがあるときに表面化する
- 他システムとの連携が不十分だと、データの二重入力という見えにくいコストが発生する。API連携が可能な組み合わせであれば自動化できるが、対応していない場合は連携部分の開発を検討する余地がある
- AI活用の精度は、受発注・在庫データの整備状況に左右される。データ基盤の整備が先、AI活用はその上に乗る
- 「SaaSの限界」を感じたら、まずボトルネックを切り分け、周辺業務はSaaSのまま残しつつ核となる部分だけをフルスクラッチにする選択肢がある
まずは今使っているシステムのうち、「取引先とのやり取りで一番手間がかかっている工程」を1つだけ思い浮かべてみてください。そこが、最初に見直すべき箇所である可能性が高いです。
「クラウド型WMSで受発注・在庫管理をしているが、そろそろ限界を感じている」という段階のご相談でも構いません。まずは現状の運用のどこに課題があるか、お問い合わせください。
具体的に検討する段階になったら、老朽化したシステムの刷新を含めて相談できるシステムリプレース開発もあわせてご覧ください。
※本記事に記載した内容は2026年8月時点の公開情報にもとづく整理です。統計・料金は変動するため、最新の一次情報とあわせてご確認ください。
運営・編集