製造小売企業 様
「店舗もECも卸も伸ばしたいが、在庫データがシステムごとにバラバラで、経営判断のスピードが上がらない」――。
複数チャネルを展開する製造小売業の多くが、いま同じ壁にぶつかっています。SaaSは入れ、POSもECもクラウド化をし、それでも原料・梱包材まで含めた「在庫の真実」が一画面で見えないために、機会損失と棚卸工数が膨らんでいく。
本記事では、約20店舗・複数チャネルを展開する菓子製造小売A社（匿名）の事例をもとに、在庫管理DXをどう設計し、どこから着手すべきかを、当社が実際に支援したプロジェクトの構造に沿って解説します。在庫管理に課題感を持つDX推進担当・AI推進担当の方が、自社のロードマップを描く参考になれば幸いです。
目次
製造小売業（自社で商品を作って自社で売る業態。SPAやD2Cと近い概念）は、ここ数年で店舗・EC・卸という複数チャネルを同時に育てるケースが急速に増えています。一方で、チャネルが増えるほど在庫データの管理は複雑化し、現場と経営の双方に負荷がかかります。
ECには ECカート（Shopifyなど）の在庫、店舗にはPOS（スマレジなど）の在庫、卸にはExcel管理の在庫、製造現場にはZAICOやスプレッドシートで管理する原料・半製品の在庫があり、それぞれが個別のシステムで、個別の更新タイミングで動いています。
結果として、「どこに、何が、いまいくつあるのか」を一枚のダッシュボードで把握できない状態が生まれます。経営層が知りたいのは「商品ベースの全社在庫」ですが、現場で動いているのは「システムごとの部分在庫」です。このギャップが、在庫管理DXが必要になる最大の理由です。
EC向けの製品在庫は、ロジレスのような物流SaaSである程度自動的に見えるようになります。一方で、製造現場で消費される原料・包材・半製品といった「川上の在庫」は、専用の管理ツールに乗っていないことが多く、Excelや属人的な勘で運用されているのが実情です。
これは「商品を欠品させる原因」が、製品ではなく原料側に潜んでいることを意味します。チャネルが増え、SKU（在庫管理単位。商品の色・サイズなどを区別した最小単位）が増えるほど、原料起点の欠品リスクは指数関数的に大きくなります。
もう一つの構造的な課題が、推進体制のリソース不足です。製造小売業のシステム担当・データ担当は、日々の運用トラブル対応や受発注業務の対応に時間を取られ、データ基盤の整備や業務フロー設計といった「本来やるべきDX業務」に手が回りません。
在庫管理DXは、ツール選定よりも先に、この「DXに使える時間をどう確保するか」を設計する必要があります。
ここからは、当社が在庫管理DXをご支援している菓子製造小売A社の事例を、匿名化したうえでご紹介します。
A社の概要は以下のとおりです。
・業種：菓子製造・販売（手づくり系のアルチザン菓子）
・店舗数：全国に約20店舗（百貨店・駅ビル・直営路面店など）
・チャネル構成：EC（Shopify）、店頭（POS：スマレジ）、BtoB卸売の3チャネル
・顧客データ規模：数十万人規模の会員データ資産
・管理対象アイテム数：800〜900品目（原料・包材・資材・製品を含む）
・在庫管理に関わる人数：10名前後
・既存システム：ZAICO（在庫管理）、ロジレス（物流）、Shopify（EC）、スマレジ（POS）、Excel（卸売・生産管理）
A社は、製品自体は手づくり感のあるアルチザン菓子でありながら、販売チャネルとデータ基盤は完全にデジタル化していこうという方針を掲げており、まさに「現場感とデータドリブン」を両立しようとしている企業です。
支援開始時点でのA社の状況は、多くの製造小売業が抱える典型的な課題と重なります。
A社では、在庫・物流・EC・POSそれぞれに専用のSaaSが導入されていました。各SaaSは単独では正しく動作していましたが、システム間のデータ連携が部分的にしか組まれていないため、「在庫管理SaaSの数字」「物流SaaSの数字」「ECの数字」「POSの数字」がそれぞれ別の真実として存在していました。
これは「SaaSは入れたがDXは進んでいない」状態になってしまっており、ツール導入はゴールではなく、データを統合して使える状態にして初めてDXは前進します。
データが分散していることの直接的な影響として、理論在庫（システム上の数字）と実地在庫（現物の数）が合わないという課題が顕在化していました。
この「合わない」は、単純な入力ミスではなく、入出庫フロー・棚卸フロー・製造工程の在庫消費ルールが標準化されていないために起こります。SKUが800を超える環境では、フローを標準化しない限り、人の努力では合わせきれません。
製品の在庫は物流SaaS（ロジレス）側で自動的に管理されていましたが、原料・梱包材といった川上の在庫はシステム化されておらず、製造現場での残量把握が属人的になっていました。
菓子製造業のように、季節要因・キャンペーン要因で需要が大きく変動するビジネスでは、原料側の見える化なしに販売計画は組めません。
棚卸（実際に倉庫を回って在庫数を数え、システムと突き合わせる業務）と、入庫業務（仕入れた原料・包材を倉庫に登録する業務）のフローが未整備で、現場ごとにやり方が違うという課題もありました。
この状態のまま在庫管理SaaSを「動かす」だけでは、ツールは入っても運用は安定しません。
A社の課題に対し、当社では以下の4ステップで在庫管理DXを進めています。「ツール導入で終わらせず、データ基盤と現場運用まで一気通貫で設計する」のが基本方針です。
最初に着手したのは、すでに導入されているSaaSの設定状況の棚卸です。具体的には、ZAICO（在庫管理SaaS）のユーザー権限・グループ、在庫データ、入出庫フロー、棚卸フロー、製造工程管理フロー、そしてロジレス（物流SaaS）の製品在庫管理・出荷管理・POS／EC連携状況を確認しました。
この「棚卸の棚卸」が最初に必要なのは、SaaSの設定値そのものが業務の前提条件になっているからです。フローを変える前に、いまのフローを正確に言語化することが第一歩です。
次に、Shopify（EC）の注文データ・在庫データを、ZAICO・ロジレスとどう連携させるかを設計しました。
ポイントは、「在庫を持つシステム」を1つに絞り、それ以外のシステムは在庫の参照側に回すという整理です。同じ在庫を複数システムで二重管理すると、必ずどこかでズレが起きます。どこを「真の在庫」と決め、他システムはそこを参照する設計にするだけで、運用は大きく安定します。
連携設計の中核に据えたのが、GCP BigQueryをデータの単一の置き場（Single Source of Truth）にするという考え方です。BigQueryとは、Googleが提供するクラウド型のデータウェアハウス（社内の各種データを一カ所にためて、まとめて分析できる仕組み）です。
ZAICO（在庫・製造）、ロジレス（物流・出荷）、Shopify（EC注文・顧客）、スマレジ（店頭販売）――これら全てのデータを、まずBigQueryに集約します。BigQueryに入った瞬間に、データはチャネル横断で「商品単位」「店舗単位」「日次単位」で見られる状態になり、ここから先のBI（経営ダッシュボード）構築や需要予測といった応用が、すべて同じデータをもとに進められるようになります。
「ダッシュボードを作ること」が目的ではなく、「ダッシュボードを作っても土台が壊れない構造を最初に作ること」が、在庫管理DXの肝です。
データ基盤の話と並行して、現場運用の標準化も進めています。A社では、原料・包材・半製品・製品を含む800〜900品目について、QRコードスキャン（スマートフォン：iOS・Android対応）を中心にした入出庫・棚卸の運用を整備中です。
QRコード運用を採用する理由は単純で、「数えて入力する」業務を「読み取って確認する」業務に変えると、人為的ミスが激減するからです。さらに、操作端末がスマートフォンであれば、現場スタッフが新しいPCを学ぶ必要もなく、運用定着までの時間を短縮できます。
A社の在庫管理DXは、ZAICOの本稼働を起点に、データ連携・BI構築・BtoBデジタル化と段階的に進めています。当該プロジェクトを通じて目指している効果は、大きく3つです。
在庫の真実が一画面で見えるようになると、「人気商品が欠品しているのに、別店舗には在庫がある」といった機会損失を未然に防げます。チャネル横断で在庫が見えること自体が、売上の押し上げ要因になります。
棚卸と入出庫のフローを標準化し、QRコード運用に統一することで、現場の作業時間は大きく圧縮されます。10名前後の在庫管理体制でも、800〜900品目を回せる運用に近づけることが目標です。
データがBigQueryに集約されると、経営層が見たい指標を「翌日には見られる状態」にできます。在庫回転、店舗別売上、SKU別貢献度といったKPIが、Excelの手集計に頼らず、自動で更新されるダッシュボードに乗ってきます。
これは単に「便利になる」という話ではなく、意思決定のサイクルを週次から日次に変えることを意味します。
※本プロジェクトは現在進行中（ZAICO本稼働目標：2026年8月）であり、上記効果は支援開始時点で合意した目標値・想定効果です。確定的な数値成果ではない点をご了承ください。
A社の事例から得られた示唆として、製造小売業の在庫管理DXを成功させるための要点を3つに整理します。
製品在庫だけを管理しても、欠品リスクは下がりません。原料・包材・半製品といった川上の在庫まで管理対象に含めて、初めて「機会損失を本当に減らせる」状態になります。
スタートが製品在庫の見える化からだったとしても、ロードマップ上に必ず原料・包材を載せておくことが、後戻りを防ぐコツです。
在庫SaaS・物流SaaS・EC・POSをそれぞれ最新のものに置き換えるだけでは、データの分散は解消しません。最終的にすべてのデータを集める「Single Sourceの基盤」（BigQueryなどのDWH＝データウェアハウス）を設計の中心に置くことが、長期的な投資対効果を最大化します。
当社では、BIや分析よりも先に、このデータ基盤の設計から入ることを推奨しています。
どれだけ設計が美しくても、現場で運用できなければDXは進みません。入庫・出庫・棚卸・製造工程の在庫消費ルールを、ツール導入と同じタイミングで合意し、QRコードのようなミスを減らす仕組みに落とし込むことが、定着の鍵を握ります。
推進体制（社内のシステム担当・データ担当の工数確保）も、ここに含めて設計するべき重要要素です。
本記事では、複数チャネルを展開する菓子製造小売A社の事例をもとに、製造小売業における在庫管理DXの進め方を解説しました。
要点を振り返ると、次のとおりです。
在庫管理DXは、ツール選定の話ではなく、「業務の真実をどこに置くか」を決める意思決定です。A社のように複数チャネルを抱える企業ほど、その効果は大きくなります。
当社では、製造小売業・D2C・複数チャネル展開企業向けに、在庫管理DX支援サービスを提供しています。本記事でご紹介したような、ZAICO・物流SaaS・EC・POS・BigQueryまでを含む統合的な在庫管理DXの設計から、現場運用の定着支援までを一貫してご支援可能です。
「自社にも当てはまる課題が多い」「まずは全体像を把握したい」という方向けに、サービス内容・支援範囲・事例ダイジェスト・進め方の全体像をまとめたサービス資料を無料でご用意しています。
▼ こんな方におすすめです
