在庫管理をAIで内製する｜需要予測・発注点アラートをNext.jsで実装する設計と費用感

「Excelの在庫台帳が3つに分裂していて、どれが最新か分からない」「発注担当者の勘と経験に頼っていて、その人が休むと欠品が起きる」——中小企業の在庫管理の現場で、こうした声をよく聞きます。SKUが増え、拠点が増え、担当者が増えるほど、Excelでの在庫管理は静かに限界を迎えます。

この記事では、Excel在庫管理からの脱却を検討している中小企業の経営者・情シス担当者に向けて、AI（需要予測・発注点アラート）を組み込んだ在庫管理システムをNext.jsフルスクラッチで内製する場合の設計・費用感・導入手順を整理します。

先に、要点をまとめます。

• Excel在庫管理の限界は「SKU数の増加」「拠点の分散」「棚卸差異の常態化」の3つのサインで顕在化しやすく、既製の在庫管理SaaSと内製フルスクラッチにはそれぞれ向き不向きがある
• AIを組み込む場合、需要予測・発注点アラートは「候補を出す」役割に絞り、実際の発注確定・金額計算はルールベースの処理に任せるのが安全な設計
• 最小構成であれば、対象SKUを絞った上で1.5〜3ヶ月程度・実装だけで100万円台〜300万円台が目安（要件の複雑さで変動）

ただし、AIを在庫管理に組み込む際には後述する「精度が安定するまでの見極め方」に注意が必要です。この点は後半で詳しく説明します。

Excelの在庫管理はいつ限界を迎える？

SKU数・拠点数・棚卸差異率のいずれかが一定を超えたタイミングで、Excel運用は構造的に破綻し始めます。

Excelでの在庫管理は、SKU数が少なく拠点が1つの間はうまく機能します。しかし、以下のようなサインが出始めたら、システム化を検討するタイミングです。

• 複数人が同じファイルを同時編集し、上書き事故が起きる：クラウド共有していても、関数が壊れる・古いバージョンで保存されるといった事故は珍しくありません
• 拠点間・店舗間で在庫データがリアルタイムに同期されない：本部が把握している在庫数と、現場の実在庫にズレが生じ、欠品や過剰発注につながります
• 棚卸のたびに帳簿と実在庫の差異が発生する：入出庫の記録漏れ、返品処理の反映漏れなどが蓄積し、棚卸のたびに差異の原因調査に時間を取られます
• 発注担当者の経験と勘に依存し、属人化している：「このシーズンはこれくらい仕入れる」という感覚が特定の担当者にしかなく、引き継ぎができません

御社の状況がこれらの複数に当てはまるなら、Excel運用の延命ではなく、システム化を前提に検討を始める時期です。特に「拠点間の在庫データがリアルタイムに同期されない」は見落とされがちですが、本部と現場で見ている数字が違う状態が続くと、営業担当者が「在庫あり」と案内したのに実際は欠品していた、といった信用問題に発展することもあります。逆に言えば、単一拠点・SKU数も少なく、棚卸差異もほとんど出ていないのであれば、まだExcelで十分に運用できている状態です。無理にシステム化を急ぐ必要はありません。

ただし「システム化=フルスクラッチ」ではありません。次の章で、既製SaaSとフルスクラッチの向き不向きを整理します。

在庫管理は既製SaaSとフルスクラッチ、どちらを選ぶべき？

取扱商品の性質が標準的でシンプルならSaaS、業界特有のルールや他システムとの連携が複雑ならフルスクラッチが向いています。

在庫管理システムには、クラウド型の既製SaaSと、自社専用に作るフルスクラッチの大きく2つの選択肢があります。判断基準を表に整理します。

多くの中小企業にとって、まず既製SaaSで試して自社の在庫管理の型を固め、そのうえで「SaaSでは表現できない管理単位」が明確になった段階でフルスクラッチに切り替える、という順番が失敗しにくい進め方です。いきなりフルスクラッチから始めると、要件が固まる前に作り込んでしまい、後から仕様変更のコストがかさむことがあります。

実際の相談でよく出てくるのは、「SaaSは月額こそ手頃だが、自社独自のロット番号体系や、原材料と完成品を紐付けて追跡する仕組みが表現できない」というケースです。このような業界特有の管理単位は、SaaS側の設定画面で吸収しきれず、結局Excelに別表を作って二重管理になってしまうことがよくあります。二重管理が発生している時点で、SaaSの月額費用を払いながら実質的にはExcelでの手作業を続けているのと変わらない状態になっているため、フルスクラッチへの切り替えを検討する明確なサインと言えます。

AIで在庫管理はどこまで自動化できる？

AIに任せるのは「需要予測の候補提示」と「発注タイミングのアラート」までに留め、発注の確定や金額計算はルールベースの処理に任せるのが安全です。

在庫管理にAIを組み込む際によくある誤解は、「発注まで全自動でやってくれる」というイメージです。実際に安定して運用できている構成は、役割を次のように分けています。

• AIが担う部分：過去の出荷実績・季節要因・直近のトレンドから、SKUごとの需要予測値を算出し、「この商品は今週中に発注しないと在庫切れになる可能性があります」という形でアラートを出す
• ルールベースの処理が担う部分：発注点（在庫がここまで減ったら発注する基準数）と発注量の計算、発注書の生成、承認フローへの受け渡し
• 人が担う部分：AIが出したアラートを見て、最終的に発注するかどうかを判断し、承認する

需要予測モデルの実装は、いきなり全SKUを対象にすると精度検証に時間がかかりすぎます。現実的な進め方は、まず売上構成比の高い一部のSKU（いわゆるAランク商品）に絞ってAIに学習させ、予測値と実績のズレを月次で確認しながら、精度が安定したSKUから徐々に対象を広げていくやり方です。この「絞って検証してから広げる」進め方は、他のAI組込み型システム（問い合わせ対応の一次返信をNext.jsで自動化する設計）などでも同様に有効な考え方です。

なお、需要予測の精度は導入初月から高くは出ません。最低でも3ヶ月分の実績データを溜めながら予測ロジックを調整していく前提で計画を立てることをおすすめします。ここが、後で触れる「AI組込みの見極め方」のポイントにもつながります。

Next.jsでの実装、どんな構成になる？

Next.jsのServer Actionsで在庫データの更新を一元管理し、需要予測はバッチ処理として非同期に実行する構成が扱いやすい設計です。

在庫管理システムをNext.js × Firebase（またはSupabase等）で組む場合、典型的な構成要素は次の通りです。

• 在庫マスタ・入出庫トランザクション：SKU単位で現在庫数を保持し、入荷・出荷・棚卸修正のたびにトランザクションログを追記する設計にします。現在庫数だけを更新して履歴を残さないと、後から差異の原因を追えなくなるため、必ず「事実の記録（トランザクション）」と「集計結果（現在庫数）」を分けて持ちます
• 入出庫の登録画面：現場担当者がスマートフォンやタブレットからバーコードスキャンで入出庫を登録できる画面。Server Actionsで直接データベースを更新し、リアルタイムに在庫数へ反映します
• 需要予測バッチ：日次または週次のタイミングで、過去の出荷実績を集計し、予測モデル（シンプルな移動平均〜機械学習モデルまで、対象SKU数と精度要件に応じて選定）に投げて予測値を算出し、発注点アラートをダッシュボードに表示します
• 発注点アラート・発注書生成：予測値と現在庫数を突き合わせ、発注が必要なSKUを一覧化。担当者が確認・承認すると、発注書のPDFやCSVを生成して仕入先へ送付できる形にします

この構成のポイントは、リアルタイム性が必要な「入出庫登録」と、まとめて処理してよい「需要予測」を明確に分離することです。需要予測をリクエストのたびに同期実行してしまうと、入出庫登録の画面が重くなり、現場の使い勝手が悪化します。バッチ処理として切り離すことで、両方の処理速度を確保できます。

もう一点、実装上で軽視できないのが権限設計です。現場担当者は自分の拠点の入出庫登録だけができればよく、他拠点の在庫数や仕入単価までは見せたくない、というケースが多くあります。拠点・役職単位でのアクセス制御を最初から設計に組み込んでおかないと、後から画面ごとに権限チェックを継ぎ足すことになり、修正漏れによる情報漏洩のリスクが高まります。ダッシュボード設計の考え方は、散らばった社内データを1枚のダッシュボードに集約する設計でも扱っているので、複数拠点のデータを1画面にまとめたい場合はあわせて参考にしてください。

導入にはどれくらいの期間と費用がかかる？

対象SKUを絞った最小構成であれば、1.5〜3ヶ月・実装費用は100万円台〜300万円台が目安です。

費用感は、対象範囲によって大きく変わります。目安として3パターンに分けて整理します。

運用コストは、ホスティング費用が月数千円〜数万円程度（データ量・アクセス数による）、AI予測のAPIコストは対象SKU数や予測頻度に応じて月数千円〜数万円程度に収まることが多いです。ただし、これらは実装内容によって変わるため、あくまで目安としてご覧ください。

費用を左右する最大の要因は、「対象SKU数」と「他システムとの連携範囲」です。最初から全商品・全拠点・全システム連携を目指すと、要件定義だけで数ヶ月かかることもあります。まずは在庫金額や出荷頻度の高い一部の商品群に絞って最小構成で立ち上げ、効果を確認しながら対象を広げていくのが、投資対効果を見誤らない進め方です。

見積もりの内訳を考えるうえでは、「開発費用（初期の作り込み）」と「運用費用（作った後の維持）」を分けて捉えることも重要です。開発費用は上記の表の通りですが、運用費用には需要予測モデルの再学習・精度モニタリング・商品マスタの追加保守といった継続的な作業が含まれます。多くの見積もりで見落とされがちなのが、この「作った後、誰が予測精度を見続けるのか」という運用体制の部分です。導入して終わりではなく、月次で予測と実績のズレを確認し、モデルを調整していく前提で運用コストを見込んでおくと、後から想定外の費用が発生しにくくなります。

導入でよくある失敗と、その回避策は？

「全SKU・全拠点を一度に対応しようとする」「AIの予測精度を過信して発注を全自動化する」の2つが典型的な失敗パターンです。

在庫管理システムの導入でつまずきやすいポイントを整理します。

• 失敗パターン1：最初から全SKU・全拠点を対象にする：要件定義が終わらないまま開発が長期化し、途中で頓挫するリスクが高まります。回避策は、在庫金額や出荷頻度の上位2〜3割の商品に絞って最小構成でリリースし、効果を確認しながら段階的に対象を広げることです
• 失敗パターン2：AIの需要予測をそのまま自動発注に直結させる：冒頭で触れた「精度が安定するまでの見極め方」がまさにこの点です。立ち上げ初期は予測精度が安定していないため、欠品や過剰在庫が発生するリスクがあります。回避策は、最初の数ヶ月は「AIがアラートを出す→人が確認して発注する」という半自動運用にとどめ、予測精度が実績で確認できてから自動化の範囲を広げることです
• 失敗パターン3：現場の入出庫登録が定着しない：どれだけ精緻な需要予測を組んでも、入出庫データの記録が現場で徹底されなければ予測の前提データ自体が狂います。回避策は、バーコードスキャンなど現場の負担が最小になる登録画面を優先して作り込み、入力の手間を後回しにしないことです
• 失敗パターン4：棚卸との整合を取る仕組みがない：システム上の在庫数と実棚卸の数字がずれたまま放置されると、システムへの信頼が失われて結局Excelに戻ってしまいます。回避策は、棚卸差異が発生した際にトランザクションログとして「棚卸修正」を必ず記録し、差異の傾向を追跡できるようにしておくことです

これらの失敗は、いずれも「最初から完璧を目指す」ことに起因しています。範囲を絞って小さく始め、実績を見ながら広げるという進め方が、結果的に投資を無駄にしない一番の近道です。

まとめ：この記事で持ち帰れること

ここまでの内容で、次の2点を判断できるようになったはずです。

• 自社のExcel在庫管理が「システム化を検討すべき段階」にあるかどうかの見極め方
• AIを組み込む場合に、どこまでをAIに任せ、どこを人の判断に残すべきかの設計方針

まずは今日、対象にしたい商品群の直近1ヶ月分の出荷データを、Excelでもよいので一度眺めてみてください。出荷頻度の上位2〜3割がどの商品か、発注のタイミングがどれくらいばらついているかを見るだけでも、最小構成で対象にすべき範囲のイメージがつかめます。

私たちは、Next.js × Firebase構成での業務システム開発を、中小企業の実際の業務フローに合わせて内製する形でお手伝いしています。在庫管理に限らず、「この業務のここだけAIに手伝わせたい」という部分的な相談も歓迎します。15分のカジュアルな相談も受け付けていますので、要件が固まっていない段階でもお気軽にご相談ください。

よくある質問

Q. 既製の在庫管理SaaSを使わずに内製するメリットは何ですか？

A. 標準的な単品管理で足りるなら既製SaaSのほうが総コストで有利なケースが多いです。内製が有利になるのは、ロット管理や独自の拠点構成など業界特有の管理単位がある場合や、受発注・会計など他の基幹システムとリアルタイムに連携させたい場合です。

Q. AIの需要予測はどれくらいの精度が出ますか？

A. 商品特性やデータ量によって大きく変わるため、一概には言えません。目安として、過去の実績データが十分にある主力商品ほど精度が安定しやすく、逆に新商品や季節性の強い商品は予測が難しくなります。導入初期は精度を実績で確認しながら、自動化の範囲を段階的に広げる進め方をおすすめします。

Q. 全商品を一気にシステム化する必要がありますか？

A. おすすめしません。在庫金額や出荷頻度の高い一部の商品群に絞って最小構成で立ち上げ、運用が定着してから対象を広げる進め方のほうが、要件定義の長期化や開発の頓挫を避けやすくなります。

Q. 発注は自動化できますか？

A. 技術的には可能ですが、導入初期からの全自動化はおすすめしません。AIが出す需要予測やアラートはあくまで候補として扱い、発注の最終判断は人が確認・承認する半自動運用から始めて、予測精度が実績で確認できてから自動化の範囲を広げるのが安全です。

Q. 既存のExcel台帳からのデータ移行は大変ですか？

A. 対象SKU数や現状のExcelの整理状況によります。商品マスタと現在庫数の移行自体はCSVインポートで比較的短期間に済みますが、過去の出荷実績データが整理されていない場合は、需要予測の学習データとして使えるように整形する作業に時間がかかることがあります。着手前にどの程度のデータが整理された状態で残っているかを確認しておくとスムーズです。