商蔵奉行とEC・在庫管理システムの連携ガイド｜APIとCSVの比較と自動化事例
目次
「商蔵奉行（商奉行・蔵奉行）の在庫データと、倉庫の実在庫が合わない」「ECサイトで注文が入るたびに、手動で奉行の在庫を減らすのが限界だ」
多くの企業が基幹システムとして商蔵奉行を利用していますが、ECサイトやWMS（倉庫管理システム）との連携がうまくいかず、「売り越し（在庫がないのに注文を受けてしまう）」や「機会損失（在庫があるのに売り切れ表示）」に悩まされています。
本記事では、商蔵奉行と外部システムを連携させ、在庫データをリアルタイムに同期するための具体的な手法と、ECサイト連動の仕組みについて解説します。
商蔵奉行と在庫管理連携で実現できる3つのこと
連携によって解決できるのは「手入力の手間」だけではありません。経営に直結する以下のメリットがあります。
- 在庫差異の極小化: 手入力によるミスをなくし、理論在庫と実在庫のズレを解消します。
- ECの売り越し防止: 実店舗や卸売で在庫が減った瞬間、ECサイトの在庫数も自動で減らします。
- 適正在庫の維持: 正確な在庫推移が見えるようになり、過剰在庫や欠品を防ぐ発注が可能になります。
【比較表】3つの連携手法（API・CSV・ミドルウェア）
商蔵奉行と外部システムをつなぐ方法は主に3つあります。予算とリアルタイム性のニーズに合わせて選びましょう。
| 連携手法 | リアルタイム性 | 費用感(目安) | 特徴・推奨ケース |
|---|---|---|---|
| API連携 | ◎ (即時反映) |
高 (50万〜) |
ECサイト連携に最適 在庫変動を即座に反映できるため、売り越しを防ぎたい場合に必須。奉行クラウドならAPIが使いやすい。 |
| CSV連携 | △ (バッチ処理) |
低 (10万〜) |
コスト重視の管理に 「1日1回、朝に在庫を合わせれば良い」という業態向け。手動アップロードの手間は残る場合がある。 |
| ミドルウェア (RPA/iPaaS) |
○ (準リアルタイム) |
中 (30万〜) |
柔軟な連携に APIがない古いシステムや、独自の変換ルールを挟みたい場合に有効。ノーコードツールで構築可能。 |
在庫引当ロジックの基本（FIFO・LIFO・移動平均）
システム連携時に必ず決めておくべきなのが「どの在庫から引き落とすか（引当ロジック）」です。
- 先入先出法（FIFO）: 「古いものから順に出す」。食品や医薬品など使用期限がある商品で必須。
- 後入先出法（LIFO）: 「新しいものから出す」。建材など、手前から取り出す商材向け。
- 移動平均法: 複数の仕入れ単価を平均化して出庫単価とする。小売・卸売で一般的。
商蔵奉行側の設定と、WMS（倉庫システム）側の動きが一致していないと在庫金額ズレの原因になるため、連携設計時にすり合わせが必要です。
ECサイト（Shopify・楽天等）との在庫連動の仕組み
ECサイトとの連携には、大きく分けて「リアルタイム連動」と「バッチ連動」の2パターンがあります。
1. リアルタイム連動（API）
ECサイトで注文が確定した瞬間に、奉行の「受注データ」を作成し、在庫を引き当てます。同時に、その減った在庫数を他のモール（楽天、Amazonなど）にも即座に送信します。
メリット: 売り越しリスクがほぼゼロになる。
デメリット: 開発コストが高い。APIのリクエスト数制限に注意が必要。
2. バッチ連動（CSV/スケジュール実行）
「1時間に1回」など決まった間隔でデータを同期します。
メリット: システム負荷が低く、安価に構築できる。
デメリット: 同期のタイムラグ中に注文が集中すると、欠品が発生するリスクがある。
商蔵奉行×在庫連携の成功事例
事例詳細を見る
事例1: アパレル小売（EC強化） – 在庫切れによる機会損失ゼロへ
課題: 実店舗とECで在庫を共有していたが、手動更新のためタイムラグがあり、ECで売れたのに店舗に在庫がない（またはその逆）トラブルが多発。
解決策: 商蔵奉行クラウドとECカートシステムをAPIで連携。店舗POSの売上もリアルタイムで奉行に反映。
効果:
- 在庫切れによる注文キャンセルが月20件→0件に。
- 全在庫をECで販売できるようになり、売上が15%アップ。
事例2: 食品卸売 – 賞味期限管理の自動化
課題: 倉庫から「どの賞味期限の商品を出荷したか」の報告が遅く、奉行への入力が翌日になっていた。
解決策: ハンディターミナル導入。出荷検品の実績データを商蔵奉行へ即時CSV連携。
効果:
- 在庫差異がほぼゼロに。
- 先入先出が徹底され、廃棄ロスが大幅に削減。
よくあるトラブルと解決策
連携プロジェクトで起こりがちなトラブルと、その予防策です。
在庫数が合わない（データ不整合）
原因: 奉行側の「受注残（引当済みだが未出荷）」と、WMS側の「実在庫」の定義がズレていることが多いです。
解決策: 「有効在庫（実在庫 – 引当数）」を連携の基準にするよう、定義を統一します。
セット商品の在庫管理ができない
原因: ECでは「A+Bセット」として売るが、奉行では「商品A」「商品B」として管理している場合。
解決策: 連携システム側で「セット品変換マスタ」を持ち、ECの注文を奉行の構成品コードに分解して取り込む仕組みを作ります。
導入ステップとセキュリティ対策
導入ステップ
-
現状分析とコード統一
奉行の商品コードと、EC・倉庫システムの商品コードが一致しているか確認します。ここがズレていると連携できません。
-
連携手法の決定
APIが使えるか、CSVか。リアルタイム性が必要か、予算内で収まるか判断します。
-
テスト運用
本番環境とは別のテスト環境で、注文〜在庫引当〜出荷の流れを検証します。
セキュリティ対策
- 通信の暗号化: API/CSVの送受信は必ずHTTPS/SFTP等の暗号化通信を利用します。
- IP制限: 接続元のIPアドレスを制限し、不正アクセスを防ぎます。
よくある質問（FAQ）
Q. オンプレミス版の商蔵奉行でも連携できますか？
A. 可能ですが、工夫が必要です。
オンプレミス版はAPIがない場合が多いため、「奉行の自動実行処理でCSVを書き出し、それを連携ツールが読み取る」といった構成が一般的です。クラウド版（奉行クラウド）への移行も検討の価値があります。
Q. 商品マスタも連携できますか？
A. はい、可能です。
在庫だけでなく、新商品の登録情報（商品名、JANコード、価格など）も奉行からECサイトへ連携させると、二重登録の手間がなくなります。
まとめと定額支援のご案内
商蔵奉行と在庫管理システムの連携は、EC事業の拡大や、適正在庫によるキャッシュフロー改善に欠かせない施策です。
成功の鍵は、「自社の商売に合った連携頻度（リアルタイム or バッチ）」と「正しい在庫引当ルール」を設計することにあります。
はてなベース株式会社では、商蔵奉行を中心とした基幹システム連携の経験豊富なスタッフが、御社の業務フローに最適な自動化プランをご提案します。「API連携は難しそう」「まずは低コストでCSV連携から始めたい」など、あらゆるご相談に対応可能です。
まずは無料相談で、現在のシステム構成と課題をお聞かせください。
