卸売業・小売業でAIやDXを進めるとき、最初に検討すべきことは、最新の需要予測AIや接客AIを選ぶことではありません。
▶ あわせて読みたい:AI導入は何から始める?最初に選ぶ業務の見極め方【業務棚卸し・優先順位表】
先に取り組むべきなのは、商品、価格、受発注、在庫、顧客、店舗、ECの情報をつなぐことです。
小売業では、POSレジやキャッシュレス決済、ECサイトをすでに導入していても、店舗在庫、EC在庫、仕入、顧客情報が別々に管理されていることがあります。卸売業では、FAXや電話で受けた注文を販売管理システムへ再入力し、得意先別の掛率や特価を営業担当者のExcelで管理しているケースも少なくありません。
この状態で生成AIや需要予測AIを導入しても、元になる商品名、価格、在庫数が正しくなければ、誤った商品説明や発注候補が出てしまいます。
卸売・小売業のAI・DX導入は、次の順序で進めることが重要です。
- 現在の業務とシステムを棚卸しする
- 商品マスターと商品コードを整える
- 受発注と在庫を一元化する
- 店舗、EC、顧客データをつなぐ
- 商品説明や販促などに生成AIを使う
- 販売実績を蓄積して需要予測へ進む
添付調査では、卸売業・小売業のIT導入度は5段階中3.5、生成AI導入度は3.0と評価されています。一方、DX成熟度は大企業4.0に対して中小企業2.5とされ、企業規模による差が示されています。主な課題は、店舗・EC・卸の在庫分断、FAX受注、商品マスター整備であり、低利益率、店舗ごとの運用差、データ品質が導入上の障壁です。
なお、これらの数値は公的な導入率ではなく、公開統計、政策資料、業界特性をもとにした調査独自の相対評価です。
卸売・小売業のIT・AI支援優先度は全業種中6位、80点と評価されています。POS、EC、受発注、在庫、CRMを組み合わせやすく、生成AIによる販促支援と需要予測の両方を展開できることが理由です。
この記事では、小売業と卸売業に分けて現在の課題を整理し、商品マスター整備から生成AI、需要予測までの具体的な進め方を解説します。
卸売・小売業のAI・DX導入は「データをつなぐこと」から始める

POSやECを導入していてもDXが進んでいるとは限らない
POSレジ、ECサイト、販売管理システム、在庫管理システムを導入しているだけでは、必ずしもDXが進んでいるとはいえません。
重要なのは、それぞれのシステムが同じ商品、同じ在庫、同じ顧客を識別できることです。
例えば、店舗のPOSでは「国産牛ロース500g」、ECサイトでは「国産牛ロース・500グラム」、仕入管理では「牛ロースA500」と登録されているとします。担当者には同じ商品だと分かっても、システム上は別の商品として扱われる可能性があります。
その結果、次のような問題が起こります。
- 店舗とECの売上を商品別に合算できない
- 実際の在庫数を確認できない
- 商品ごとの粗利益を計算できない
- 仕入数量の判断を誤る
- 販促効果を正しく測定できない
- AIが複数の商品として分析してしまう
DXとは、紙をPDFにしたり、Excelをクラウドへ移したりするだけではありません。商品、在庫、顧客、売上などのデータを業務横断で利用し、発注、販売、販促、顧客対応の方法を改善することが必要です。
商品・在庫・受発注・顧客を同じデータ系列で管理する
卸売・小売業では、商品を中心にデータを関連づけます。最低限、次の関係が追える状態を目指します。
- どの商品を仕入れたか
- どの拠点に入荷したか
- どの店舗・EC・得意先へ販売したか
- いくらで販売したか
- 在庫がどれだけ残っているか
- 返品、値引き、廃棄がどれだけ発生したか
- どの顧客が購入したか
- 次回の仕入れがいつ必要か
この関係をつなぐためには、商品ID、受注番号、顧客ID、店舗・倉庫コードなどの共通キーが必要です。すべての情報を一つのシステムへ入れる必要はありません。ただし、「どのシステムの情報を正しい情報として扱うか」を決める必要があります。
卸売・小売業のDXへの取り組み状況
添付調査では、卸売・小売業でDXに取り組んでいる企業の割合は73.5%とされています。ただし、この数値は調査対象企業における全社的、一部部門、部門単位の取り組みを合算したものであり、小規模事業者全体をそのまま代表する数値ではありません。
また、2024年の国内EC市場は、BtoCが26.1兆円、BtoBが514.4兆円と整理されています。ただし、EC市場規模が拡大していることと、個々の企業でPOS、在庫、顧客データの連携が完了していることは別問題です。販売チャネルが増えるほど、商品マスターと在庫管理の重要性は高まります。
▶ 関連記事:卸売業・小売業のDXとは?AI需要予測・自動発注とマイクロフルフィルメント活用事例
小売業で起きているPOS・EC・店舗在庫・顧客データの分断
POSとECで商品コードや商品名が異なる
小売業では、店舗のPOSとECサイトを別の時期に導入しているケースが多くあります。POSではJANコードを使い、ECでは独自の商品番号を使っていることもあります。また、店舗では色やサイズをまとめて一商品として扱い、ECではSKUごとに分けている場合もあります。
SKUとは、色、サイズ、容量などの違いを含めた最小の在庫管理単位です。例えば、同じシャツでも、白・Mサイズ、白・Lサイズ、黒・Mサイズ、黒・Lサイズに分かれます。
店舗とECでSKUの扱いが異なると、「商品全体では在庫があるが、顧客が希望する色・サイズはない」という状態を正確に把握できません。商品コードを統一するときは、現在のコードをすべて削除するのではなく、共通の商品IDを決めたうえで、既存コードとの対応表を作る方法が現実的です。
店舗在庫とEC在庫が一致しない
店舗とECで同じ在庫を販売している場合、更新のタイミングによって売り越しが起こる可能性があります。在庫を一元化するときは、単に「現在庫数」を共有するだけでは不十分です。
| 在庫区分 | 内容 |
|---|---|
| 実在庫 | 店舗や倉庫に実際に存在する数量 |
| 引当済み在庫 | 注文を受け、他の販売に使えない数量 |
| 販売可能在庫 | 新しい注文を受けられる数量 |
| 入荷予定 | 発注済みで、今後入荷する数量 |
| 移動中在庫 | 店舗・倉庫間で移送中の数量 |
| 返品・検品中 | 返品され、再販売できるか確認中の数量 |
| 破損・廃棄予定 | 販売できない数量 |
ECに表示するべきなのは、実在庫ではなく、原則として販売可能在庫です。取り置き商品や店舗間移動中の商品を販売可能として表示すると、在庫不足が発生します。
店舗とECで顧客情報がつながっていない
店舗の会員カード、EC会員、メール配信、LINE公式アカウントなどで、別々の顧客IDを持っているケースもあります。顧客情報が分断されると、購買履歴を正しく把握できず、同じ顧客へ重複した案内を送ることがあります。
- 店舗購入者へECで同じ商品を案内してしまう
- ECの優良顧客を店舗で認識できない
- 購買頻度や購入金額を正しく集計できない
- 同じ顧客へ複数の販促メッセージを送る
- 返品・問い合わせ履歴を共有できない
顧客データを統合する際は、氏名だけで同一人物と判断してはいけません。メールアドレス、電話番号、会員番号などを組み合わせ、重複候補を人が確認する必要があります。
店舗ごとに発注や値引き判断が異なる
小売業では、店長や担当者の経験が発注精度を支えています。一方で、判断基準が個人の記憶だけに残っていると、異動や退職によって精度が低下します。
- 雨の日は売れ行きが落ちる
- 地域イベントの前は特定商品が売れる
- 給料日前後で客単価が変わる
- 近隣学校の行事で需要が増える
- 特定曜日だけ業務用需要がある
- 気温が一定水準を超えると売れ筋が変わる
将来、需要予測AIを導入する場合も、こうした条件をデータとして残す必要があります。「なぜ発注量を増やしたか」「なぜ値引きしたか」という理由も記録すると、予測結果の検証に役立ちます。
▶ 関連記事:Square(スクエア)小売業POSレジ【プラス】の機能・料金|P1・P2・P3と受発注・決済を解説
卸売業で起きているFAX受注・得意先別価格・商品コードの問題
FAXや電話注文の再入力が受注処理を遅らせる
卸売業では、取引先ごとの事情から、FAXや電話注文が残りやすい傾向があります。一般的なFAX受注の流れは、次のようになります。
- FAXを受信する
- 担当者が内容を読む
- 得意先を確認する
- 商品コードへ置き換える
- 数量と納期を入力する
- 在庫を確認する
- 得意先別価格を確認する
- 受注内容を返信する
- 出荷指示を作る
- 納品後に請求データを作る
この工程では、読み間違い、数量の入力ミス、重複登録、価格条件の選択ミスが発生しやすくなります。FAXをOCRで読み取れば、すべて解決するわけではありません。OCRは文字をデータへ変換する技術であり、取引先独自の商品名や略称を自社商品コードへ変換する仕組みが別途必要です。
- 得意先コード
- 自社商品コード
- 得意先側の商品コード
- 単位・入数
- 納品先
- 得意先別価格
- 最低注文数量
- 注文書の読み替えルール
- 確認が必要な例外条件
得意先ごとの価格条件が属人化している
卸売業では、同じ商品でも得意先によって販売価格が異なります。価格差には、基本掛率、購入数量、年間取引額、キャンペーン、個別契約、送料負担、納品頻度、支払条件などが関係します。
| 管理項目 | 例 |
|---|---|
| 得意先 | A商店 |
| 商品 | 商品コード1001 |
| 基本価格 | 1,000円 |
| 個別価格 | 850円 |
| 適用数量 | 10個以上 |
| 適用開始日 | 2026年4月1日 |
| 適用終了日 | 2026年9月30日 |
| 送料条件 | 3万円以上無料 |
| 承認者 | 営業責任者 |
価格の適用期間がないと、終了した特価をそのまま使い続ける可能性があります。生成AIへ価格表を読み込ませて回答させる場合も、古い価格表が混在していると誤案内につながります。
自社・仕入先・得意先で商品コードが異なる
卸売業では、自社、仕入先、得意先がそれぞれ異なる商品コードを使っていることがあります。すべての取引先に自社コードの使用を求めるのは現実的ではないため、自社の商品IDを中心にコード対応表を持つ方法が有効です。
| 共通商品ID | 自社コード | 仕入先コード | 得意先コード |
|---|---|---|---|
| P0001 | BP-1001 | S-A520 | C-001 |
| P0002 | BP-1002 | S-A521 | C-002 |
同じ商品でも、仕入単位がケース、販売単位が個数ということがあります。「1ケース=24個」といった単位変換も商品マスターに登録しなければ、受注数量や在庫数を誤る原因になります。
受注から請求までの情報が分断されている
受注、出荷、納品、返品、請求が別々に管理されていると、未請求、重複請求、返品反映漏れなどが起こります。受注から請求までをつなぐためには、共通の受注番号が必要です。受注番号に、出荷番号、納品番号、返品番号、請求番号を関連づけることで追跡できるようになります。
最初に整備すべき商品マスターの項目
商品マスターとは、商品に関する基本情報を一元的に管理する台帳です。商品マスターが不正確なままでは、POS、EC、在庫、CRMを連携しても、誤った情報が広がるだけです。
商品を特定する基本情報
- 共通商品ID
- 商品名・略称
- 規格・サイズ・色・容量
- 商品分類・ブランド
- JANコード
- 仕入先コード・得意先コード
- 販売単位・仕入単位・入数
- セット構成
- 販売開始日・終了日
- 取扱状態
価格と取引条件に関する情報
- 標準売価
- 店舗販売価格
- EC販売価格
- 仕入価格・標準原価
- 得意先別価格
- 数量別価格
- セール価格
- 適用開始日・終了日
- 消費税区分
- 送料条件
- 最低注文数量
- 価格承認者
在庫・物流に関する情報
- 管理拠点・保管場所
- 発注点・安全在庫・最大在庫
- 発注単位
- 標準リードタイム
- 仕入先
- ロット番号
- 賞味期限・使用期限
- 温度帯
- 返品可否
- 配送条件
- 棚卸方法
商品説明や販促に使用する情報
- 商品の正式な特徴
- 材質・原材料
- 使用方法
- 対象者
- 注意事項
- 保証内容
- 表示が許可された表現
- 使用してはいけない表現
- 商品説明の根拠資料
- 承認済み画像
- よくある質問
- 返品・交換条件
生成AIに「魅力的に書いて」とだけ指示すると、入力情報にない効果や優位性を補ってしまう可能性があります。AIへ渡す情報の範囲を限定し、「提供された事実以外は追加しない」というルールを設けます。
店舗・EC・卸売の在庫を一元化する考え方
在庫数を一つの数字だけで管理しない
在庫一元化で重要なのは、在庫の状態を区別することです。実在庫が10個あっても、EC注文で4個、店舗取り置きで2個が確保されていれば、販売可能在庫は4個です。
販売可能在庫 = 実在庫 - 引当済み在庫 - 販売停止在庫
在庫更新の基準時点を統一する
- 注文受付時
- 決済完了時
- 出荷指示時
- 出荷完了時
- 店舗販売時
どのタイミングを採用するかは業態によって異なります。注文キャンセル時に在庫を戻す処理も含め、業務ルールを決めます。
リアルタイム連携が難しい場合の始め方
- 日次で在庫データを統合する
- 売れ筋商品だけ更新頻度を上げる
- EC掲載在庫を実在庫より少なく設定する
- 在庫差異の多い店舗から改善する
- 対象商品を限定してリアルタイム連携を試す
棚卸差異の原因を記録する
- 入荷の未登録
- 販売の未登録
- 返品処理漏れ
- 破損・廃棄
- 盗難・紛失
- 店舗間移動の未処理
- 入数の設定ミス
- 商品コードの選択ミス
- 棚卸時の数え間違い
原因別に件数を集計すると、システムの問題なのか、業務手順の問題なのかを判断できます。
受発注・在庫・店舗・EC・CRMをつなぐ全体像

商品マスターを中心に各システムを接続する
| システム | 主に管理する情報 |
|---|---|
| 商品管理 | 商品名、規格、コード、単位、価格の基本情報 |
| POS | 店舗売上、返品、値引き、決済 |
| EC | EC注文、配送先、オンライン決済 |
| 受発注管理 | 得意先注文、仕入発注、納期 |
| 在庫管理 | 拠点別在庫、引当、入出庫、棚卸 |
| CRM | 顧客情報、購買履歴、問い合わせ |
| 販売管理 | 売上、納品、請求、入金 |
| 会計 | 売上・仕入・経費の会計処理 |
すべてのデータを一つのシステムに入れる必要はない
- API連携:システム間で自動的にデータをやり取りする
- CSV連携:一定の形式で出力・取込を行う
- 連携サービス:複数システムの間をつなぐ
- RPA:人が行っていた画面操作を自動化する
RPAで二重入力を自動化しても、商品コードの不一致は解決しません。先にデータの定義を統一し、その後に連携方法を選びます。
システムごとの責任範囲を決める
| 情報 | 正本の例 |
|---|---|
| 商品名・規格 | 商品管理システム |
| 標準価格 | 商品・価格マスター |
| 店舗売上 | POS |
| EC注文 | ECシステム |
| 拠点別在庫 | 在庫管理システム |
| 顧客基本情報 | CRM |
| 請求・入金 | 販売管理システム |
データ整備後に取り組む生成AI活用
添付調査では、卸売・小売業における有望なAI活用として、商品説明、販促、営業提案、FAQ、需要予測が挙げられています。推奨導入順序は、商品マスター統一、在庫一元化、CRM整備、生成AI、需要予測です。
商品説明の下書きを作る
生成AIは、商品情報を媒体に合わせて書き換える業務に適しています。
AIが作成した文章は、商品担当者が事実確認を行います。
- EC商品ページ
- 店舗POP
- 営業用カタログ
- メール配信・LINE配信
- SNS投稿
- 法人向け商品案内
- 社内向け商品説明
販促文やキャンペーン案を作る
「売れる文章を作って」だけでは、誇張された表現になりやすいため、目的と条件を明確にします。キャンペーン価格や期間はAIに計算させず、価格マスターから取得した確定情報を差し込む設計が安全です。
- 対象顧客
- 対象商品
- 販売時期
- 販売チャネル
- キャンペーン条件
- 過去の反応
- 文章の長さ
- 使用可能・禁止表現
卸売営業の提案書や案内文を作る
得意先別価格、在庫、納期、契約条件は、必ず販売管理システムなどの確定情報と照合します。
- 新商品案内
- 休眠顧客への再提案
- 過去購入商品の後継品案内
- 欠品商品の代替候補説明
- 季節商品の提案
- 商談後のフォローメール
- 提案書の構成
FAQと問い合わせ回答案を作る
最初は自動回答ではなく、担当者向けの回答案として使います。AIが作った回答を担当者が確認し、問題が少ない質問だけ自動化範囲を広げます。
- 在庫
- 納期
- 返品
- 使用方法
- 店舗受取
- 法人価格
- 代替商品
- 送料
生成AIの誤価格・誇大表現を防ぐ承認ルール

AIへ価格を自由に生成させない
価格情報は、生成AIが文章の流れから推測したり、古い資料を参照したりしない設計が必要です。AIは価格を決めるのではなく、確定した価格情報を読みやすい文章へ整える役割に限定します。
- 商品コード
- 適用する顧客・得意先
- 標準価格・個別価格
- 税込・税抜区分
- 適用開始日・終了日
- 数量条件
- 送料条件
- キャンペーン条件
使用できる商品表現と禁止表現を管理する
- 絶対に効果がある
- 業界で最も優れている
- 誰でも簡単に成果が出る
- 完全に安全である
- 必ず満足できる
- 他社製品より圧倒的に優れている
このような断定や比較表現には、客観的な根拠が必要です。商品マスターには、使用可能表現、条件付き表現、禁止表現、根拠資料、承認部門、過去の修正履歴を持たせると安全です。
公開前の承認者を決める
| 生成物 | 主な確認者 |
|---|---|
| 商品説明 | 商品担当者 |
| EC掲載文 | 商品担当者・EC責任者 |
| 販促文 | 販促責任者 |
| 得意先提案 | 営業担当者・営業責任者 |
| 価格表示 | 価格管理責任者 |
| FAQ | 顧客対応責任者 |
| 品質・安全に関する説明 | 品質管理担当者 |
| 法令に関係する表現 | 社内担当者または専門家 |
生成から公開までの記録を残す
- 使用した商品情報
- 使用した指示文
- AIが作成した初稿
- 人が修正した内容
- 確認者
- 承認日
- 公開日
- 掲載媒体
- 変更履歴
用途別に承認レベルを変える
| 用途 | 承認方法の例 |
|---|---|
| 社内のアイデア出し | 作成者が確認 |
| 社内資料の下書き | 部門内確認 |
| 営業提案書 | 営業責任者が確認 |
| EC商品ページ | 商品・EC担当者が確認 |
| 価格表示 | 価格マスターと照合 |
| 品質・安全の説明 | 専門担当者が確認 |
| 自動回答 | 対象質問を限定し、ログを定期確認 |
金額、契約、在庫確約、納期確約、品質保証などは、人の確認を必須にすることが基本です。
需要予測・欠品削減・廃棄削減へ進む方法
需要予測に必要なデータをそろえる
- 日別・店舗別・商品別売上
- 販売価格・値引き
- 在庫・入荷・発注
- 欠品・返品・廃棄
- キャンペーン
- 曜日・祝日・季節
- 天候・地域イベント
- 店舗休業日
売上ゼロと欠品を区別する
売上がゼロでも、需要がなかったとは限りません。在庫切れで販売できなかった可能性があります。欠品中の売上をゼロとして学習すると、AIは「この商品は売れない」と判断することがあります。
- 在庫があったが売れなかった
- 開店時点から在庫がなかった
- 営業途中で欠品した
- EC掲載を停止していた
- 販売価格が通常と異なっていた
- 店舗が休業していた
予測結果をそのまま自動発注しない
需要予測AIを導入した直後から、自動で仕入先へ発注するのは避けます。最初は発注候補を提示し、担当者が最低発注数量、発注単位、保管スペース、賞味期限、仕入資金、納期、既存発注残、代替商品、販促予定などと照合します。
欠品・廃棄削減のKPIを設定する
| KPI | 確認すること |
|---|---|
| 欠品率 | 販売機会を失っていないか |
| 在庫回転率 | 在庫が適切に動いているか |
| 滞留在庫額 | 長期間売れない在庫が増えていないか |
| 廃棄率 | 期限切れや劣化による損失が減ったか |
| 値引き率 | 売り切るための値引きが減ったか |
| 発注修正率 | AI提案を人がどれだけ変更したか |
| 緊急発注件数 | 予定外の発注が減ったか |
| 店舗間移動件数 | 在庫偏在が減ったか |
卸売・小売業のAI・DX導入を5段階で進める
ステップ1.現状のシステムとExcelを棚卸しする
POS、ECサイト、受注管理、販売管理、在庫管理、仕入管理、CRM、会計、Excel、紙台帳、FAX注文書、電話注文メモを一覧化します。
入力担当者、入力頻度、入力項目、出力先、承認者、例外処理、二重入力、待ち時間、ミス件数も整理します。
ステップ2.商品コードと商品マスターを統一する
全システムの商品一覧を出し、重複候補を抽出します。同一商品かを人が確認し、共通商品IDと既存コードの対応表を作ります。
商品マスターは一度整備して終わりではなく、新商品、終売、価格改定、規格変更があるたびに更新します。
ステップ3.在庫・受発注・顧客データを接続する
EC注文と在庫、POS売上と在庫、FAX受注と共通受注データ、店舗間移動、顧客ID、受注から請求までを段階的につなぎます。
ステップ4.生成AIを社内作業から試す
商品説明の下書き、店舗POP案、メール配信案、FAQ回答案、営業提案の構成、会議要約、売上報告の文章化など、低リスクな用途から始めます。
ステップ5.需要予測と発注支援へ進む
一店舗、一カテゴリー、売れ筋上位商品、廃棄が多い商品、欠品が多い商品など、対象範囲を小さくして検証します。
卸売・小売業のAI・DX導入に失敗しやすいケース
商品マスターを整理せずAIだけ導入する
商品名や価格が複数存在する状態では、生成AIも需要予測も正しい結果を出しにくくなります。AIの性能を上げる前に、入力データの品質を確認します。
システムを追加して二重入力を増やす
新しいツールの入力が増えただけにならないよう、連携元、連携先、廃止できる入力、エラー時の対応を確認します。
全店舗・全商品を一度に変える
まず一店舗、一部の商品、一部の得意先で試し、運用ルールを固めてから広げます。
需要予測の精度だけを追う
欠品、廃棄、在庫金額、粗利益、担当者の作業時間をあわせて評価します。
AI生成物の確認責任が曖昧
誰が作成し、誰が事実確認し、誰が公開を承認するかを決めます。
導入効果を測るKPI
受発注業務のKPI
- FAX・電話受注の比率
- 受注1件当たりの入力時間
- 受注入力ミス件数
- 重複受注件数
- 受注から回答までの時間
- 保留注文件数
在庫・仕入業務のKPI
- 欠品率
- 在庫回転率
- 棚卸差異
- 滞留在庫額
- 廃棄率
- 値引き率
- 緊急発注件数
- 店舗間移動件数
- 発注修正率
販促・営業業務のKPI
- 商品説明作成時間
- 販促文作成本数
- 営業提案書作成時間
- FAQ回答時間
- 問い合わせ一次回答時間
- リピート率
- AI生成文の採用率・差戻し率
データ品質のKPI
- 重複商品コード数
- 商品マスター未入力率
- 価格有効期限切れ件数
- 在庫連携エラー数
- 顧客重複件数
- 二重入力回数
- 手動修正件数
添付調査でも、卸売・小売業の効果指標として、欠品、滞留在庫、受注処理、販促作成、リピート率が挙げられています。また、誇大表示と価格誤りへの注意が必要とされています。
想定例1.複数店舗を運営する地域小売店

※以下は実在企業の導入実績ではなく、業務を理解するための想定例です。
3店舗とECサイトを運営する小売企業では、店舗ごとに在庫を管理し、EC掲載在庫は担当者が手作業で更新していました。店舗で商品が売れてもEC在庫へ反映されるのは翌日で、売り越しや注文キャンセルが発生していました。
- POSとECの商品一覧を出力する
- 商品コードの対応表を作る
- 共通商品IDを付ける
- 店舗別の実在庫と引当在庫を分ける
- ECへ販売可能在庫を連携する
- 店舗間移動をシステムへ登録する
- 商品説明を生成AIで下書きする
これにより、店舗で欠品していても他店舗の在庫を確認し、取り寄せを案内しやすくなります。EC商品説明は商品マスターの承認済み情報から作成し、商品担当者が確認します。
想定例2.FAX受注が多い地域卸

地域の小売店や事業者からFAX注文を受ける卸売企業では、営業事務担当者が注文内容を販売管理システムへ入力していました。得意先ごとに商品名の略し方が違い、価格条件も担当営業のExcelに保存されていました。
- 得意先ごとの注文書形式を収集する
- 得意先コードと商品コードの対応表を作る
- FAXをOCRで読み取る
- 商品候補を自動表示する
- 得意先別価格をマスターから表示する
- 担当者が数量・商品・価格を確認する
- 確認後に受注を確定する
完全自動登録ではなく、判断が必要な項目を目立たせ、担当者が確認する設計にします。将来的には、注文頻度の高い得意先からWeb注文へ移行することも検討できます。
想定例3.食品を扱う小売・卸売事業者

食品を扱う企業では、欠品だけでなく、賞味期限切れや値引き、廃棄の削減が重要です。
- 入荷日
- 賞味期限
- ロット
- 値引き日・理由
- 廃棄日・理由
- 欠品日時
- 発注数量
- 納品数量
まず、販売実績から発注候補を作り、仕入担当者が確認します。AIが12ケースを提案しても、在庫スペースや賞味期限を考慮し、担当者が8ケースへ変更する場合があります。変更理由を記録し、予測モデルや発注ルールを改善します。
導入ツールや支援会社を選ぶポイント
既存システムとの連携方法を確認する
- API連携
- CSVの出力・取込
- 商品コード変換
- 更新頻度
- 連携エラー確認
- 一括修正
- 将来の移行性
「連携可能」と書かれていても、追加費用や個別開発が必要なことがあります。連携する項目、方向、頻度、費用まで確認します。
商品・価格・在庫の管理元を決められるか
- 商品マスター管理
- 得意先別価格
- 価格の有効期間
- 変更履歴
- 権限管理
- 承認機能
- 拠点別在庫
- 引当管理
- ロット・期限管理
- 商品コード対応表
自社の業態に必要な管理項目を先に決め、その後にツールを比較します。
現場が使える入力方法か
- スマートフォン入力
- バーコード
- 入荷・移動の簡易登録
- 通信不安定時の利用
- 操作権限
- 選択式入力
本部で使いやすくても、店舗や倉庫で入力されなければデータは整いません。
AI機能だけで比較しない
- 参照データの限定
- 出力根拠の確認
- 人の承認
- 利用履歴
- 入力データの学習利用
- 権限管理
- 誤回答時の停止
AIの文章作成機能より、商品マスターとの連携や承認機能の方が重要な場合があります。
費用と効果を業務単位で確認する
- 初期設定
- データ移行
- 商品マスター整備
- API連携
- 個別開発
- 端末・機器
- 操作研修
- 保守・導入後支援
人件費削減だけでなく、欠品防止や販売機会の増加も含めて判断します。
補助金を利用して導入する場合の確認事項
POS、受発注、在庫管理、顧客管理、AIツールなどは、制度や登録内容によって補助対象となる可能性があります。ただし、一般に販売されている製品のすべてのプランや機能が対象になるとは限りません。
- 対象となる事業者
- 対象となるITツール
- 登録されているプラン
- 対象経費
- 契約期間
- 導入時期
- 契約・発注・支払いの時期
- データ移行費の扱い
- API連携や個別開発の扱い
- ハードウェアの扱い
- 保守費用の扱い
- 実績報告や効果報告
補助金を起点にツールを選ぶのではなく、業務課題、KPI、必要機能を決めた後に、制度との適合性を確認することが重要です。制度内容や対象範囲は変更される場合があります。最新の公募要領、事務局案内、ITツール登録情報を確認してください。採択や補助を保証するものではありません。
▶ 関連記事:Bカートの機能・料金|デジタル化・AI導入補助金のP-01・P-02・P-03を解説
▶ 関連記事:GoQSystemの機能・料金|EC受注一元管理とデジタル化・AI導入補助金のP-02・P-03を解説
まとめ|AIの前に商品・価格・在庫をつなぐ
卸売・小売業のAI・DX導入では、生成AIや需要予測AIを先に選ぶのではなく、商品、価格、受発注、在庫、顧客のデータを整えることが重要です。
小売業では、POS、EC、店舗在庫、顧客情報の分断を解消します。卸売業では、FAX受注、得意先別価格、商品コードの不統一、受注から請求までの分断を整理します。
生成AIが作成した商品説明や販促文は、そのまま公開せず、人が事実、価格、在庫、表現を確認します。需要予測も、最初から発注を完全自動化するのではなく、発注候補を提示し、担当者が確認する方法から始めます。
全店舗、全商品を一度に変える必要はありません。在庫差異が多い店舗、FAX受注が多い得意先、欠品や廃棄が多い商品など、効果を測りやすい範囲から始めることが成功への近道です。
- 業務とシステムを棚卸しする
- 商品マスターを統一する
- 在庫と受発注をつなぐ
- 店舗・EC・顧客情報をつなぐ
- 商品説明、販促、営業提案、FAQに生成AIを使う
- 販売・在庫データを蓄積して需要予測へ進む
よくある質問
POSを導入済みでもDXは必要ですか?
必要な場合があります。POSを導入していても、EC、在庫、仕入、顧客、会計と連携していなければ、二重入力や手作業集計が残ります。POSの有無ではなく、データが業務横断で使える状態かを確認してください。
FAX受注はすぐに廃止すべきですか?
必ずしも一度に廃止する必要はありません。取引先の事情によりFAXが残る場合は、受信後の社内処理をデータ化する方法があります。OCR、商品コード対応表、得意先別価格マスターを組み合わせ、担当者が確認して受注を確定します。
生成AIに商品説明を任せても問題ありませんか?
下書き作成には活用できますが、そのまま公開するのは避けるべきです。商品マスターの承認済み情報だけを使用させ、価格、性能、安全性、比較表現などを商品担当者が確認してください。
需要予測AIはデータが少なくても使えますか?
限定的な検証は可能ですが、販売、在庫、欠品、値引き、廃棄、販促などのデータが不足すると精度が安定しません。最初は一店舗、一カテゴリーなどに対象を絞り、発注候補の提示から始める方法が現実的です。
中小企業はどの業務から始めるべきですか?
商品コードの不統一、在庫差異、FAX受注など、件数が多く、効果を測りやすい業務から始めます。生成AIの導入より先に、商品マスターと在庫情報の整備を優先してください。
卸売・小売業のAI・DX導入を、ツール選びの前に整理しませんか?
POSやECを導入していても、商品、価格、在庫、顧客情報がつながっていなければ、生成AIや需要予測の効果は限定されます。
また、現在のシステムをすべて入れ替えることが、必ずしも最適とは限りません。既存のPOS、EC、販売管理、在庫管理を確認しながら、どのデータが分断されているか、どの商品・店舗・得意先から試すかを整理することが重要です。
ご相談の際は、現在利用しているシステム、店舗・倉庫数、商品点数、月間受注件数、FAX受注の比率、在庫や欠品に関する課題をご用意いただくと、導入順序を整理しやすくなります。
- どのデータが分断されているか
- 商品マスターのどこを整備すべきか
- どのシステムを管理元にするか
- どの店舗・商品・得意先から試すか
- 生成AIを安全に使える業務は何か
- 人による承認が必要な業務は何か
- 需要予測へ進む前に何を記録すべきか
ご相談はこちら:AI導入支援サービス/お問い合わせ
