コード不要で在庫管理システムを作る方法（2026年版）

在庫の問題は、なぜか最後まで片づかない

どの業務チームにも、まったく同じ在庫の話があります。だいたいこう始まります。

最初はスプレッドシートです。商品のタブ、在庫数のタブ、仕入先のタブ。最初の1か月は、誰かが几帳面に更新します。ところが火曜の午後、2人目の担当者が自分のノートPCから編集を始め、ちょうど同じ時間に倉庫責任者も編集していて、バージョン競合が3週間分のデータを壊します。復元できるのは4日前のバックアップです。すでに在庫がある商品に、発注が二重に出ます。システムの表示は40個、実棚は11個だったせいで、顧客の注文が出荷できません。

そこで在庫管理ソフトを買います。6週間の設定作業と$30,000の導入費用のあと、手元に残るのは、業務の80%は見事に処理し、残りの20%とは真正面からぶつかるシステムです。しかもその20%こそ、自社の商売の独自性そのものです。そのソフトは「平均的な会社」向けに設計されていて、あなたの会社向けではありません。返品フローは標準的ではありません。仕入先のリードタイムは、システムが想定していない形で管理しています。倉庫チームが使うロケーションコードは、さらに$10,000かかる個別連携なしには取り込めません。

2026年、スプレッドシートか、高額なERPか、ほぼ合っているだけのシステムか——この三択に縛られる必要はもうありません。在庫が実際にどう動くのか（発注から棚へ、棚から販売へ、販売から再発注へ）を言葉で説明すれば、自社専用のシステムが約30分で動き始めます。

既製の在庫管理ソフトが、ライセンス料以上にかかる理由

ソフト自体が悪いわけではありません。SAP Business One、Oracle NetSuite、Fishbowl、Cin7 は、いずれも実力のあるプラットフォームです。問題は、それらが「平均的な会社」向けに作られていて、あなたの会社は平均的ではないことです。

導入コストという税金は実在する

在庫管理ソフトのベンダーの多くは、無理のなさそうなユーザー単価を掲げています。本当のコストは、導入を始めた瞬間に姿を現します。

業務チーム10〜25人規模での Oracle NetSuite:

• 基本ライセンス: 1ユーザーあたり月額$99〜$299 → 25ユーザーで年間$11,880〜$89,700
• 導入: 標準構成で$15,000〜$50,000
• コンサル業界の目安: 初年度の総額はライセンス費用の50〜80%増しで見込む
• 社内に NetSuite 管理者を置く場合: 年間$65,000〜$95,000
• 15人規模チームの初年度実質コスト: $25,000〜$80,000以上

小規模メーカー・卸向けの Fishbowl:

• 買い切りライセンス: モジュール構成により$4,395〜$10,995
• 年間保守: $1,100〜$2,700
• QuickBooks または ERP との連携構築: $2,000〜$8,000
• トレーニング: 1時間あたり$150〜$200、最低20時間
• 初年度実質コスト: $8,000〜$22,000 — しかもカスタマイズなしの前提です

SAP Business One:

• ライセンス: 1ユーザーあたり買い切り$1,357〜$1,666（クラウド版は1ユーザーあたり月額$85〜$105）
• 導入: 複雑さに応じて$25,000〜$150,000
• パートナーのマージンが総額に20〜40%上乗せ
• 15人規模チームの現実的な初年度コスト: $50,000〜$200,000以上

そして、これらのプラットフォームから実際に使うのはどこでしょうか。商品マスタ、在庫数の管理、発注モジュール、基本的なレポートダッシュボード。支払っている金額の、およそ15〜20%です。

カスタマイズの限界は3か月目あたりで見えてくる

既製の在庫管理プラットフォームも、ある程度までは設定で対応できます。項目を追加し、ステータス名を変え、簡単な自動化を組むことはできます。しかし土台のデータモデルは、「在庫を扱う会社とはこういうものだ」というベンダーの前提で固定されています。

自社の業務がその前提から外れたとき——標準外の単位、想定フローに収まらない返品処理、システムが想定していなかった複数拠点の管理——壁に突き当たります。壁には解決策があります。1時間$150〜$300を請求するコンサルタントです。最低契約は$5,000から始まります。

業務チームに時間を返すはずだった在庫システムが、今度は自分自身のプロジェクト管理という負担を生み始めます。

在庫管理システムに本当に必要なもの

何かを作り始める前に、ノイズを削ぎ落として、在庫管理システムが核心で何をしているのかを見極めると役に立ちます。

機能する在庫管理システムは、5つの問いに答えます。

1. 何があるのか — 各拠点の各SKUについて、今この瞬間の在庫数
2. どこにあるのか — 物理的な保管場所（棚、ロケーション、倉庫、輸送中）
3. 何が減ってきているのか — 在庫が発注点を下回った時点での自動アラート
4. 何が入ってくるのか — 未入荷の発注、入荷予定日、仕入先の動き
5. 何が出ていったのか — 受注、拠点間移動、廃棄、調整。すべて監査証跡つきで

それ以外——需要予測、ロット管理、複数通貨での仕入先請求——は、この5つの問いの上に乗る層です。まず核心を作る。層は、チームが本当に必要としたときに足す。

AgentUI で自社専用の在庫管理システムを作る

業務チームが、どうやって在庫管理システム一式を作っているのかを見ていきます。モックアップでもテンプレートでもなく、本物のデータベース、ロール別アクセス、外部連携を備えた本番品質のツールです。

ステップ1: 自社の業務をふだんの言葉で説明する

出発点は設定ファイルではなく、会話です。AgentUI にログインして、自社の業務を説明します。

「卸売業を営んでいて、倉庫は3か所あります。商品カテゴリは3つ、SKUは約800点です。定常的な仕入先12社から入荷し、月におよそ200社の顧客へ出荷しています。拠点ごとの在庫数の管理、発注の管理、SKUごとの発注点の設定、そして在庫調整をすべて『誰が、なぜ』まで含めて記録したいです。」

AI はこの説明から、あなたのデータモデルを読み取ります。事業の中に存在する対象（商品、拠点、仕入先、発注、顧客）、それらの関係、そしてチームが毎日回している業務フローです。

ステップ2: AI がシステムを構築する — データベース、画面、ロジック

AgentUI は、その説明から完全に動作するシステムを生成します。ワイヤーフレームではありません。自分で作り込むテンプレートでもありません。実際のデータベーススキーマを背後に持つ、本物のアプリケーションです。

典型的な在庫業務なら、生成されるシステムには次のものが含まれます。

商品マスタモジュール

• SKU、名称、説明、カテゴリ、単位
• 原価、販売価格
• SKUごとの発注点と発注数量
• 仕入先の割り当て（主・予備）
• スキャン連携用のバーコード / QRコード項目

在庫数モジュール

• 拠点ごとの現在数量
• 引当可能在庫と引当済み在庫の区別
• 調整履歴の全記録（誰が、何を、いつ、なぜ変更したか）
• 発注点にもとづく在庫僅少フラグ

発注モジュール

• 在庫僅少アラートから、または手動で発注を作成
• ステータス追跡: 下書き → 送信済み → 確定 → 入荷済み → クローズ
• 分割入荷への対応
• 仕入先ごとのリードタイム管理
• 入荷予定のカレンダー表示

入荷モジュール

• 入荷を未消込の発注と突き合わせ
• 差異の検知（入荷数量と発注数量の差）
• 確定時に在庫数を自動更新
• 検品が必要な品目の品質保留ステータス

レポートダッシュボード

• カテゴリ別の在庫金額
• SKUごとの回転率
• 動きの速い上位20品目
• 発注待ちリスト（発注点を下回った品目）
• 仕入先の実績（納期遵守率、差異発生率）

これらはすべて AI が作ります。ステップ2でのあなたの役割は、生成されたシステムを確認して「ここを直して」と伝えることです。設定作業を自分でやることではありません。

ステップ3: ロール別のアクセス権を追加する

チーム全員が同じ権限を必要とするわけではありません。AgentUI の権限機能なら、誰が何をできるのかを正確に定義できます。コードは書きません。

在庫チームでよくある権限構成は次のとおりです。

項目レベルのマスキングは原価データで効きます。倉庫担当には数量は見えますが、仕入価格は見えません。経理にはすべて見えます。アクセスは1件ずつ記録されます。誰が、何を、いつ、どのIPアドレスから見たかまで残ります。

ステップ4: 外部連携を設定する

在庫管理システムは単独では成り立ちません。AgentUI は連携基盤を共有しているので、データソースを一度つなげば、すべてのアプリから使えます。

在庫管理システムでよく使われる連携は次のとおりです。

メール通知 — 在庫が発注点を下回ったとき、発注が遅延しているとき、差異がしきい値を超えたときの自動アラート。

WhatsApp — WhatsApp を中心に業務を回しているチームなら、AgentUI が在庫僅少アラートや発注確定の通知をチームのグループへ直接送れます。

SQL への直接接続 — すでに ERP や会計システムがあるなら、AgentUI はそこから直接読み書きできます。手入力や CSV の書き出しをはさまずに、在庫システムと会計システムの数字がそろい続けます。

Webhook トリガー — 入荷したら出荷システムへ Webhook を送る。発注が承認されたら、仕入先ポータルへ確定情報を送る。

独自ドメイン — 在庫管理システムは inventory.yourcompany.com で動きます。AgentUI の汎用URLではありません。

ステップ5: ガバナンス込みで本番へ移す

ここが、スプレッドシートや「試作品どまりのノーコードツール」と AgentUI が分かれるところです。

本番稼働の前に、システムは環境を順に通っていきます。

1. 開発環境 — AI が作り、あなたが試す場所。実データへのリスクはありません。
2. ステージング環境 — 実際の商品データを入れ、チームで実際の業務フローを回し、稼働前にすべてを確認します。
3. 本番環境 — 稼働率99.9%のSLAが付いた、ロックされた環境。本番への変更はステージングからの明示的な昇格が必要です。稼働中のシステムを誰かがうっかり上書きすることはありません。

昇格はすべて記録されます。コードの変更はすべて、本番に届く前に AgentUI の22ルールのセキュリティスキャナ（Semgrep ベース）を通ります。重大な指摘が出ればデプロイは止まります。情シス部門は、システム全体のセキュリティスコア（0〜100点と評価レター）を確認できます。

ガバナンスが最初から組み込まれている状態の在庫管理とは、こういうものです。

実例: 中南米の物流会社

AgentUI のある顧客は、4か国にまたがる地域物流・流通の事業を運営しています。従業員は約60人、稼働SKUは1,200点、仕入先は15社です。

AgentUI を導入する前、在庫情報は3つのシステムに分散していました。導入から12年が経つ旧来のERP、ERPが遅すぎるために倉庫チームが日常的に使っていたExcelファイル、そして購買マネージャーが補充依頼を投稿していた WhatsApp グループです。

結果は予想どおりでした。Excel と ERP は常にずれていました。ERP のデータは誰も信用していませんでした。購買マネージャーは毎週月曜に4時間かけて2つのシステムを突き合わせ、週次の在庫レポートを作っていましたが、そのレポートは火曜にはもう古くなっていました。

彼らは自社の業務を AgentUI に説明しました。3日後——AgentUI のエンジニアチームによるレビューの1日を含めて——本番システムが手元にありました。倉庫チームは入荷と調整を AgentUI に記録します。購買マネージャーは発注を AgentUI で管理します。経理はレポートを直接取り出します。WhatsApp グループは今もありますが、データ入力ではなく、本来の会話のために使われています。

月曜の突き合わせ作業はなくなりました。在庫精度は最初の1か月で、自己申告の約82%から、検証済みの97%超になりました。購買マネージャーは毎週およそ4時間を取り戻しました。

本当に意味のあるコスト比較

在庫管理の選択肢を比べるとき、見るべき数字はライセンス料ではありません。初年度の総保有コストと、その対価として実際に手に入るものです。

AgentUI の年間$3,000には、社内ユーザー25名、環境数無制限、監査ログ、コードスキャン、SSO、そしてサポートチームとの共有Slackチャンネルが含まれます。エンジニアは初期設定のときだけでなく、業務の変化に合わせた継続的な調整にも対応します。

AgentUI が最初から解決する、よくある在庫の課題

複数拠点の在庫管理

複数の倉庫、店舗、あるいは国をまたいで事業を運営しているなら、在庫システムは全社合計の数量だけでなく、拠点単位で在庫を把握する必要があります。

AgentUI は、実際の構成に合わせた拠点の階層を生成します。在庫の動きは拠点単位で記録されます。レポートは拠点で絞り込むことも、全拠点を合算することもできます。拠点間の移動は、必要であれば承認フローを通す形にできます。

仕入先リードタイムの管理

たいていの在庫システムは発注を管理します。しかし、その後の仕入判断に本当に効く形で仕入先の実績を測るものは、ごくわずかです。

AgentUI では、完了した発注はすべて入荷予定日と突き合わせられます。仕入先ごとの納期遵守率は自動で計算されます。ある仕入先が慢性的に遅れていれば、システムがそれを示します。その仕入先のSKUについて、発注点を引き上げるといった調整ができます。

本当に役に立つ在庫僅少アラート

多くの在庫アラートの問題は、後追いであることです。アラートを見た時点で、在庫はもうゼロです。補充を機能させるということは、在庫が発注点に達した時点で動くことであって、なくなってから動くことではありません。

AgentUI の在庫僅少アラートは、数量がSKUごとに設定した発注点を下回った時点で発火します。アラートは適切な担当者（倉庫担当ではなく購買）に届きます。内容には現在数量、発注点、優先仕入先、そして発注の下書きをワンクリックで作成するアクションが含まれます。

監査人が納得する調整履歴

在庫が動くたびに——販売、入荷、実地棚卸による調整、廃棄——AgentUI はその変更を記録します。実行したユーザー、タイムスタンプ、変更前後の数量、入力されたメモまで残ります。

規制業種の企業や監査を控えている企業にとって、これは「あれば嬉しい機能」ではありません。指摘なしで終わる監査と、指摘が残る監査を分けるものです。履歴はいつでも、任意の期間で書き出せます。ユーザー、SKU、拠点、調整種別でのフィルタも使えます。

バーコード・QRコード連携

AgentUI の在庫モジュールは、すべての商品でバーコードとQRコードの項目に対応しています。バーコードリーダーを使う倉庫チームは、スキャンするだけで入荷や調整を記録できます。入力は不要です。独自のバーコード体系がある場合や、特定のスキャン機器との連携が必要な場合は、Enterprise プランで AgentUI のエンジニアチームが対応します。

スプレッドシートにはできず、AgentUI にできること

AgentUI で作った在庫システムが、よく整理されたスプレッドシートや、マクロ入りの複雑なExcelファイルとも根本的に違う理由を、はっきり書いておきます。

本物のリレーショナルデータベース。 データはフラットファイルではなく、正式なデータベースに保存されます。商品レコードは発注とつながります。発注は仕入先のレコードとつながります。在庫の動きは、商品とその変更を行ったユーザーの両方につながります。この構造があるから、スプレッドシートでは原理的に不可能なクエリ、レポート、外部連携が成立します。

複数人が同時に使えるリアルタイムのアクセス。 バージョン競合なしに、何人もが同時に使えます。入荷処理をしている倉庫責任者、発注を承認している購買マネージャー、レポートを見ている業務責任者が、全員同じ最新データの上で作業しています。

稼働率保証つきの本番ホスティング。 AgentUI は稼働率99.9%のSLAでアプリケーションをホストします。誰かが共有のGoogleスプレッドシートを開いたままにしているか、ローカルサーバーが動いているか——そういうことに左右されません。チームが必要とするとき、システムは使える状態にあります。

CISO が確認できるセキュリティ統制。 SOC 2 Type II 準拠。GDPR 対応。HIPAA サポートも利用可能。テナントごとに分離されたコンピュートとストレージ。機微な原価データへの項目レベルのマスキング。そして、コンサルタントの解説なしに情シス部門が読めるセキュリティスコア。

背後にいるチーム。 ここが、市場の他のどのプラットフォームとも本当に違うところです。詰まったとき——新しい仕入先のリードタイムの持ち方が変わっているとき、生鮮品向けに品質保留のフローを足したいとき、連携が壊れたとき——あなたの Slack チャンネルには実在のエンジニアがいます。見知らぬ人だらけの Discord ではありません。SLA 48時間のチケット待ち行列でもありません。エンジニアです。

はじめ方

在庫管理システムの最初のバージョンは、説明から始まります。要件定義書ではありません。システム設計書でもありません。ただ、何を売っているのか、それが自社の業務をどう流れていくのか、チームが毎日何を見る必要があるのか。それだけです。

無料で始められます。クレジットカードは不要です。AI が最初の動作するバージョンを約30分で生成します。稼働前にエンジニアのレビューを受けたい場合、それはすべての有料プランに含まれています。

月額$250の Team プランには、本格的な在庫業務を回すのに必要なものが揃っています。社内ユーザー25名、環境数無制限、監査ログ、コードスキャン、SSO、そしてチームとの専用Slackチャンネルです。

新しいユーザーからいちばんよく聞く感想は、「もっと早く始めればよかった」です。システムの構築に時間がかかったからではなく、そうする必要がなかったのに、何か月もスプレッドシートの混乱と付き合っていたからです。

無料で作り始めてください。クレジットカードは不要です。

Nessim Btesh は AgentUI の創業者です。業務、財務、物流の現場で10年を過ごしたのち、「こういうものがあればよかった」と思い続けたプラットフォームを自ら作りました。サポートのメールには本人が返信しています。