在庫管理システムの開発でAIを活用するとき、本記事で推奨する併用設計では、自作の対象を在庫管理SaaSの標準機能の外側にある業務に絞ります。入出庫の記録や現在庫の把握、バーコード棚卸しはSaaSに残し、数量や入出庫履歴の正式な記録元（正のデータ）を一本化したうえで、自社固有の発注ルール、受注・生産・工事との連動、複数拠点・複数販売チャネルの在庫突合、原価・粗利の集計といった個別要件を自作の検討対象とします。AIは要件定義やコード生成といった「システム開発を効率化する手段」として使う場合と、稼働後に需要予測などの「判断補助」として組み込む場合があります。どちらの場合も、AIを導入すること自体が目的ではなく、どこまでを既製SaaSに任せてどこからを自作するかという線引きを決めることが先決です。
在庫管理SaaSに残す業務と自作する業務の判断表【早見表】
在庫管理の業務を、感覚ではなく次の10項目で仕分けます。契約中のSaaSを1つずつ表に当てはめてください。
判定は4種類です。「残す」はそのままSaaSに置くもの、「残す（プラン要確認）」は上位プラン限定の場合があるもの、「残す（連携要確認）」は対象プランや追加契約の確認が必要なもの、「作り替え候補」は標準機能の外側にあり内製の検討対象になるものを指します。表の用語について、「ロケーション」は倉庫内の棚番地など保管場所、「発注点」は発注の基準となる在庫数量、「API」はシステム同士が自動でデータをやり取りする接続口、「CSV」は表計算ソフトで開けるデータ形式、「OMS」は受注管理システム、「POS」はレジの販売管理システムを指します。
| 業務 | 判定 | 理由 |
|---|---|---|
| 入出庫の記録 | 残す | 入庫・出庫のたびに数量を記録する機能は在庫SaaSの中心機能 |
| 現在庫の把握 | 残す | 品目ごとの現在庫数をリアルタイムで確認する機能は在庫SaaSの中心機能 |
| ロケーション（棚番地）管理 | 残す（プラン要確認） | 棚単位の在庫管理は上位プラン限定の場合がある（ロジクラはPremiumプラン以上）。作り替えではなくプラン見直しで対応できる領域 |
| バーコード・QR・スマホでの棚卸し | 残す（プラン要確認） | スキャン等による棚卸し機能の提供範囲や対象プランは製品ごとに異なる（zaicoは全プランでスキャン棚卸し対応、ロジクラはアプリでの入荷・出荷検品が標準で棚卸機能の提供範囲はプラン要確認）。まずは契約プランで確認する領域 |
| 発注点アラート（標準的な閾値） | 残す（プラン要確認） | 発注点を下回った在庫の一覧表示・アラートは在庫SaaSの提供機能の範囲内だが、上位プラン限定の場合がある（zaicoはベーシックプラン以上）。まず契約プランの引き上げで足りないかを確認する |
| 自社固有の発注ルール（ロット・仕入先条件・季節変動） | 作り替え候補 | 仕入先ごとの最低発注ロットや季節変動を織り込んだ発注数の計算は標準機能の外側になりやすい |
| 受注・生産・工事との連動 | 作り替え候補 | 受注や生産計画、工事の進行と在庫を連動させる仕組みは業務固有で、標準連携の範囲を超えやすい |
| 複数拠点・複数販売チャネルの在庫突合 | 作り替え候補（プラン要確認） | 複数拠点の在庫移動やチャネル連携は上位プランや連携機能で対応できる場合がある（ロジクラPremiumの拠点間入出荷など）。これらで賄えない独自ルール（状態別の在庫差異検出や特定条件での引当）がある場合に自作候補となる |
| 会計・請求との連携 | 残す（連携要確認） | 会計ソフトや請求書サービスとの連携機能がある製品なら既存連携を使うのが早いが、対応プランや追加契約・オプション費用の有無は製品ごとに確認が必要 |
| 原価・粗利の集計 | 作り替え候補 | 拠点や仕入先条件をまたいだ原価・粗利の集計は標準の集計項目に収まりきらず、表計算運用になりやすい |
表の中で「作り替え候補」に挙げた業務であっても、いきなり開発を始める必要はありません。該当する業務が1つでも複数あっても、まずは現行SaaSの上位プランや標準連携機能でカバーできないかを必ず確認します。仕入先条件や現場固有の運用フローにより、設定やプラン変更ではどうしても吸収できない要件が明確になった段階で、自作や専用システムの併用を検討します。
在庫データの正を在庫SaaSに残して自作を進める理由
在庫管理において、SaaSの利用自体が法律で義務付けられているわけではありません（ただし税務・会計上の棚卸資産の記録や、業種ごとの管理台帳要件などの記録義務は法令上存在します）。それでも入出庫の記録・現在庫の把握・棚卸しを在庫SaaSに残すのは、数量や入出庫履歴の正式な記録元（正のデータ）を1か所に決めておかないと、あとから作るどの仕組みも信用できなくなるからです。発注計算も、拠点間の突合も、原価集計も、入力元は「品目コードごとに、いまどの拠点で、どの状態（実在庫・引当済・移動中など）の在庫がいくつあるか」という確定データです。この数字の確定元を分散させると、突合作業そのものが新しい業務として増えてしまいます。zaicoやロジクラのような在庫SaaSは、バーコード等によるスキャン入力から現在庫の更新までを一貫して管理できるため、正式な記録元としての役割に向いています。なお、棚卸資産の評価方法や会計処理が適切かどうかの個別判断は、税理士等の専門家にご相談ください。
確定データを保持する業務データベースと、AIによる生成・計算処理の役割を切り分けて設計した考え方の例は、事例集の〈CASE 06｜業務DBと生成AIを、あえて分ける〉（設計の考え方の参考）で紹介しています。
zaico・ロジクラの料金プランと標準機能の境界【zaico等は2026年9月9日／ロジクラ料金は2026年10月9日確認】
zaicoの公式サイトによれば、料金プランは3段階です。スタータープランは月額8,980円（税込9,878円）で、基本ユーザー数はフル3名・閲覧10名（フルユーザーは追加可）、データ登録数は50,000件が推奨値です（ベーシックプランも同じ推奨値です）。ベーシックプランは月額49,800円（税込54,780円）、プロフェッショナルプランは月額150,000円～（税込165,000円～。ユーザー数・データ登録数は要見積り）です。QRコード・バーコードをスキャンして棚卸しをする機能は3プランとも回数制限なく利用できます。写真を撮影してAIが品目を識別する機能も3プランで使えますが、スタータープランは月10回までです。発注点を下回った在庫のアラート表示は、公式サイトの機能説明ではベーシックプラン以上の機能として案内されており、スタータープランには含まれていません。外部サービス連携は、会計ソフトfreee・マネーフォワード クラウド請求書との連携が全プランで、kintone（一部機能はプロフェッショナルプラン限定）・ネクストエンジン・Square・ユビレジとの連携がベーシックプラン以上で案内されています（ネクストエンジン連携は別途月額3,300円税込）。
ロジクラの公式サイトによれば（料金・保守費用は2026年10月9日再確認）、料金プランはLite・Premium・Enterpriseの3段階です（金額表示は税抜）。Liteプランは年契約で月額16,000円（月契約は19,000円）、月300件までの出荷は追加料金なしで、301件目以降は出荷1件につき25円が加算されます。利用できる拠点数は1拠点です。Premiumプランは年契約で月額40,000円（月契約は49,000円）、月2,000件までの出荷は追加料金なしで、それを超えると段階的な従量課金になります。利用できる拠点数は2拠点です。年間契約の場合、12か月分の基本料金はLiteプランで年額192,000円（月契約を12か月継続した場合は年額228,000円、差額36,000円）、Premiumプランで年額480,000円（月契約を12か月継続した場合は年額588,000円、差額108,000円）となります（出荷従量料金・オプション・初期費用を除く）。Enterpriseプランは個別見積りで、外部システムとの連携機能（このうちOMS・POS連携は追加10,000円・税抜。課金周期は公式サイトに明示がないため要確認）などカスタマイズに対応すると案内されています。ロット管理・ロケーション管理・拠点間の入出荷は、公式サイトの料金表ではPremiumプラン以上の機能として案内されており、Liteプランには含まれていません。バーコードスキャンによる入荷・出荷検品はアプリの標準機能として案内されています。なお、本契約から1年経過後に毎年30,000円（税抜）の年間保守費用が発生するのはPremiumプランです。また、導入時サポートに伴う初期費用も別途設定されています。
両社に共通するのは、標準機能とは別に「上位プラン限定」「連携」「オプション」の区分がある点です。この区分の外側にあるものが、作り替えを検討する対象になります。優劣を比較する記事ではありません。最新のプラン内容・金額は各公式サイトでご確認ください。
自作の検討対象となる標準機能の外側にある4つの業務
標準機能の外側は、主に4つに集中します。
- 発注ルールの属人化: 最低発注ロット（1回あたりの最小発注数量単位）や納品までのリードタイム（発注から納品までの日数）、季節ごとの需要変動を複雑に組み合わせて発注数を決めている状態です。担当者の頭の中にしか計算基準がない場合、標準の発注点アラート（在庫が閾値を下回った際に通知する機能）だけでは適正発注数を算出できません
- 受注・生産・工事との連動: 受注や生産工程に対して在庫を割り当てる「引当（出荷予定として確保する処理）」が手動のままだと、引当済みの在庫を別の出荷に回す取り違えが起きます。工事の進捗に応じた分割出庫など、業務フロー固有の要件は標準機能では賄いにくい領域です
- 複数拠点・複数チャネルの突合: 拠点ごと・販売チャネルごとに在庫が分かれている場合、単に総数を足し算するだけでなく、品目コード・拠点・状態（実在庫、引当済、移動中）・対象時点を揃えた差異の確認が必要です。拠点をまたぐ在庫移動や引当を判断するたびに、複雑な突合処理が発生します
- 原価・粗利の集計: 仕入先ごとの値引き条件や拠点間の移動コストを含めた個別原価の計算、および粗利（売上高から売上原価を引いた利益）の集計は、在庫SaaSの標準項目に収まらないことが多く、表計算ソフトでの再集計になりやすい領域です
これらは、在庫SaaSの性能不足というよりも、各社の商流や製造・流通手順に根ざした業務固有の要素です。入出庫・現在庫・棚卸しといった共通業務はSaaSに任せ、個別ルールが色濃く出るこれら周辺の処理について自作や自動化を検討します。
大量のデータを人の目視ではなく機械による判定に任せるアプローチについては、事例集の〈CASE 31｜目視できない量は、機械に判定させる〉（処理方法の参考）も参考になります。
エクセルでの在庫管理と自作システムの分かれ目
在庫管理をエクセルで行っている現場が自作を検討する際、表計算を高度に作り込むか専用システムを組むかの選択肢があります。どちらを選ぶ場合でも、まず日々の入出庫や現在庫の正（正式な記録元）をどこに固定するかを決めることが設計の大前提です。正式な記録元が在庫SaaSに定まっているなら、エクセルも専用システムもその外側で計算を担う手段にすぎません。そのうえでエクセル継続か専用システム化かを分けるのは、データ量や更新頻度、そして計算式の属人化を防ぎ引き継ぎや障害復旧ができる体制にあるかどうかです。
表計算ソフトで運用が残りやすいのは、発注数の計算、拠点間の在庫突合、原価や粗利の集計という3つの処理です。これはエクセルというツールの問題ではなく、各社固有の計算ロジックを受け止めている結果です。データ量が少なく更新頻度も限定的で、計算式や手順書が整備されており、担当者の不在時にも引き継ぎや障害復旧ができる状態であれば、エクセル運用を無理に廃止する必要はありません。
見直しの契機となるのは、更新頻度やデータ量が増えてファイルの破損や二重入力が多発したり、担当者交代によって計算ロジックがブラックボックス化したりした時点です。ただし、いきなりSaaSや専用システムに全移行するのではなく、現在のエクセルで管理している項目のうち「数量・入出庫履歴の正式な記録」と「周辺の計算処理」を切り分け、業務上の支障が出ている箇所から段階的に見直すことが推奨されます。
併用設計 — 在庫SaaSのデータを正とし外側だけを自作する
現実的な進め方は、全面移行ではなく併用です。在庫SaaSの入出庫・現在庫データを正（正式な記録元）とし、発注計画・受注や生産との連動・拠点間の突合・原価集計だけを自社専用システムで持ち、在庫SaaSとはCSV出力やAPIでやり取りする設計です。
モデルケースとして、拠点数3拠点・品目数800点・在庫管理の担当者2名の卸売業で、仕入先ごとに最低発注ロットが異なり、担当者が表計算ソフトで発注数を計算しているケースを想定します（架空の想定であり、実在の企業ではありません。なお、3拠点に対応するSaaSプランやオプション費用は要件に応じた確認が必要です）。入出庫の記録・現在庫の把握・バーコードでの棚卸しは在庫SaaSに残したまま、専用システム側で在庫SaaSから在庫データをAPIやCSV経由で取得し、自社固有の条件を加味して発注案を計算します。担当者がその計算結果を確認・確定したうえで、発注書を発行したり、発注予定データをCSVやAPI経由でSaaS等に登録したりする設計例です。ここで注意すべきは、「発注予定データを登録しても現在庫は増えない」という点です。確定した発注は、実際に納品されて在庫SaaS上で入荷・入庫スキャンを完了して初めて現在庫に反映されます。また、在庫SaaSと会計ソフトの標準連携を利用している場合、その連携仕様を崩さないよう、専用システムは在庫SaaSの前工程のデータ処理に専念させることが基本です。削減額や開発期間は、契約プラン・拠点数・発注ルールの複雑さによって前提が変わるため、本記事では断定しません。
- 1. 在庫SaaSから確定データの抽出 在庫SaaSに記録されている品目別・拠点別・状態別（実在庫・引当済・移動中）・対象時点の確定在庫データをAPIまたはCSVで取得。
- 2. 自作システムで発注案の自動計算 取得した在庫データに、仕入先ごとの最低発注ロット、リードタイム、季節変動などの自社固有ルールを掛け合わせて発注案を算出。
- 3. 担当者による確認と発注確定 自作システムが出力した発注案を担当者が確認し、発注を確定。仕入先への発注書送付や、在庫SaaSへの発注予定データ登録を実施。
- 4. 実商品の納品と現場スキャン 仕入先から商品が届いた時点で、現場スタッフが在庫SaaSのモバイルアプリ等を用いてバーコード入荷・入庫検品を実行。
- 5. 在庫SaaSの現在庫に反映 入庫検品の完了をもって在庫SaaS側の正式な現在庫数が増加。発注データ作成時点では在庫は増えず、検品時に正のデータが更新される。
発注予定データの登録先・取込方法は利用SaaSの仕様により異なります。発注登録だけで現在庫は増加せず、物理的な入庫検品を経てSaaS側の正式データが更新されます。
自社のどの業務が標準機能の外側にあるかを整理したい場合は、無料のAI自動化診断が出発点になります。
AI駆動開発で作り替えると、何がどう変わるか
自社固有の発注ルールや拠点間の突合を専用システムで構築する場合、入出庫や棚卸しを担う在庫SaaSの契約は継続したまま、その外側に自社専用の処理環境を追加する構成になります。画面や項目は自社の発注ルールや拠点構成に合わせて柔軟に設計できます。開発の進め方としては、いきなり全業務をシステム化するのではなく、発注計算や突合処理などの最もボトルネックとなっている1業務に絞り、実用最小限の機能を持つMVP（Minimum Viable Product）として小さく開発し、現場で検証しながら段階的に拡張していくのが現実的です。外部パートナーを活用する場合は、要件定義から実装・運用定着まで一貫して支援するFDE（Forward Deployed Engineer：現場伴走型エンジニア）体制をとる選択肢もあります（FDE型AI導入支援とは）。この場合の費用は、自作システムの初期開発費用および保守運用費用が発生する一方で、在庫SaaS側の継続月額費用や、利用プランに応じた費用（ロジクラPremiumの年間保守費用30,000円・税抜や初期費用など）も引き続き必要となります。削れるオプション費用と新規に発生する開発・保守費用を総合的に比較することが不可欠です。なお、単一拠点で標準的な入出庫管理のみを行い、標準の発注点アラートで十分に足りている現場であれば、自作を行わず既製SaaSの標準機能をそのまま継続利用することを検討できます。共有型のSaaSと専用環境をどう見分けるかは、業務システムは共有型か専用型かで整理しています。
よくある質問
在庫SaaSを使っているのに、なぜ発注業務だけ大変なのですか？
自社固有の発注ルールを前提に設計されていないためです。仕入先ごとの最低発注ロットや季節変動を織り込んだ発注数の判断は標準機能の外側になりやすく、表計算での手作業が残りがちです。
zaico・ロジクラを、AI駆動開発システムに完全に置き換えるべきですか？
いいえ。本記事で推奨する併用設計では、入出庫の記録・現在庫の把握・バーコードでの棚卸しを入出庫データの正として在庫SaaSに残す構成をとります。自作・作り替えの対象は、標準機能の外側にある業務に絞ることを推奨します。
複数拠点・複数チャネルの在庫突合は、どこまでが「標準機能の外側」なのですか？
上位プランや標準連携機能を確認したうえで、なお吸収できない独自要件がある場合です。品目コードの違いの名寄せや、拠点・在庫状態（実在庫・引当済・移動中）・対象時点を揃えた差異の自動確認、自社固有の優先順位による引当など、製品機能でカバーできない独自ルールが必要な場合に標準機能の外側となります。
残す／作り替えを判断するとき、最初に何を確認すればよいですか？
契約中の在庫SaaSの機能を、本記事の判断表の10項目に当てはめ、標準機能の外側にある業務がどれだけあるかを洗い出すのが最初の一歩です。
在庫管理をAIで自作する場合、どこまで業務を自動化できますか？
本記事の併用設計では、自作の対象を発注計算や拠点間突合、原価集計といった標準機能の外側にある業務に絞り、入出庫の記録や現在庫の把握は在庫SaaSに残す構成を推奨しています。どこまで自動化できるかは発注ルールの複雑さに応じて変わるため、一概には断定できません。
エクセルで在庫管理をしている場合、何から作り替えに着手すべきですか？
まずは現在のエクセルにおける正式な記録元（在庫データの正）や、二重入力・属人化などの運用上の問題を確認し、エクセル運用の継続で足りるか在庫SaaS等への移行が必要かを判断します。そのうえで移行や自作を進める場合は、発注数の計算、拠点間の突合、原価や粗利の集計など業務上の支障が出ている処理をひとつ選んで段階的に見直すのが現実的です。
在庫管理システムを自作することにデメリットはありますか？
在庫データの正が二重化しやすい点と、構築後の保守管理を自社で担う必要がある点が挙げられます。現在庫や棚卸しなどの基本機能は自作せず、在庫データの正を在庫SaaSに集約し、標準機能の外側にある計算処理だけを切り分けて作る設計が大切です。
複数拠点の在庫突合は、SaaSの標準機能では対応できないのでしょうか？
一概に対応できないわけではありません。例えばロジクラのPremiumプランでは2拠点での利用や拠点間入出荷機能が標準で提供されています。まずは契約プランや上位プランの機能で対応できないかを確認します。そのうえで、品目コードの違いの自動名寄せ、実在庫・引当済・移動中といった状態ごとの在庫差異の自動検出、自社固有の優先順位による拠点間在庫の引当など、製品機能でカバーできない独自ルールが必要な場合に、標準機能の外側として自作を検討します。
業務別の判断基準は、CRM・SFA・勤怠・請求・見積の各記事でも扱っています。SaaS費用の考え方を横断的に整理する場合は「SaaS is dead」とは何か、残す／置き換えの基本は残すSaaSと置き換えるSaaSの見極め基準、契約中の全SaaSの棚卸し手順はSaaS費用の棚卸し実務、解約・データ移行等の個別論点は脱SaaSのよくある質問20、製造業での在庫・現場管理の考え方は製造業のAI活用、建設業での資材・在庫管理の考え方は建設業のAI活用をご覧ください。パッケージ型の在庫管理システムがサポート終了を迎えた場合の判断は奉行11シリーズのサポート終了はいつかで扱っています。
自社のどの業務からAI化すべきかを知りたい方は、無料のAI自動化診断をご利用ください。自社の業務に合わせたシステムをAI駆動開発で作る場合の相談・見積りは、株式会社Walkersのシステム開発事業で受け付けています。本記事は、FDE型のAI導入支援を行う株式会社Walkersが運営しています。
参考
執筆時点（zaicoおよび各機能情報は2026年9月9日確認、ロジクラの料金プラン・年間保守費用は2026年10月9日再確認）の各公式サイトの公開情報に基づきます。制度・仕様・料金は予告なく変更される場合があるため、最新情報は各公式サイトでご確認ください。
- 料金プラン｜zaico（取得日 2026-09-09）
- 発注管理｜zaicoの機能（取得日 2026-09-09）
- 棚卸｜zaicoの機能（取得日 2026-09-09）
- 在庫の確認・検索｜zaicoの機能（取得日 2026-09-09）
- 外部サービス連携｜zaicoの機能（取得日 2026-09-09）
- 料金プラン｜在庫管理ソフト「ロジクラ」（取得日 2026-10-09）
- 主な機能｜在庫管理ソフト「ロジクラ」（取得日 2026-09-09）
- 入荷・入庫｜ロジクラの機能（取得日 2026-09-09）
- 出荷・出庫｜ロジクラの機能（取得日 2026-09-09）
- 株式会社Walkers「AI駆動開発費用の相場まとめ」（取得日 2026-09-09）
- 株式会社Walkers「FDE型AI導入支援とは」（取得日 2026-09-09）
