ブログ /
海外発の Shopify 在庫管理アプリは日本商習慣に合わない？月末締め・お中元・約束手形の壁
TL;DR
- 海外発の在庫管理アプリ（Inventory Planner / Fabrikatör / Prediko）は 機能としては優秀 だが、日本商習慣との 5 つのギャップがある。
- 主なギャップ: 月末締め支払サイト / 約束手形 / お中元・お歳暮・お盆等の季節性 / 振込文化 / 税区分（軽減税率）。
- 「使えなくはない」が「運用上の摩擦が継続的に発生」する。月数時間〜数日のロスになる。
- ストア規模 / SKU 数 / 取引仕入先の数によって 致命度が変わる。年商 1 億円超えてくると無視できない領域。
海外発の主要 4 アプリ概観
Stocky 終了後に Shopify が推す（または他のレビューサイトで推奨される）海外発の在庫管理アプリ:
| アプリ | 開発元 | 価格帯 | 強み |
|---|---|---|---|
| Inventory Planner | Sage 系（英米） | 中-高 | 機能網羅、複数倉庫、複数通貨 |
| Fabrikatör | トルコ | $99-350/月 | Stocky 移行人手サポート、PO 機能充実 |
| Prediko | フランス | 中 | AI 需要予測、UI モダン |
| Stockie | オーストラリア | $5-60/月 | 価格レンジ広い、小規模向け |
機能としては どれも優れています。需要予測・PO 作成・在庫アラート・複数ロケーション等、Stocky 以上のスペックを持つアプリも複数あります。
問題は 日本商習慣との適合性。
5 つのギャップ
ギャップ 1: 月末締め / 翌月末払い（NET 30 EOM）
海外の標準
仕入先への支払条件は NET 30（請求から 30 日以内）が一般的。Order placed → 30 days later, payment due のシンプルな期日計算。
日本の標準
「月末締め翌月末払い」（30 日締め翌月末払い）が圧倒的に多い:
- 5 月 1 日に発注 → 5 月末で締め → 6 月末に支払い
- 同じく 5 月 31 日に発注 → 5 月末で締め → 6 月末に支払い
- 結果: 支払サイクルは「カレンダー月末ベースで丸める」
ギャップ
海外アプリの PO 機能は payment_due_date = order_date + 30 days のような 日数加算ロジックしか持たないことが多い。月末ベースの計算が標準フィールドに無い。
影響
- PO の支払期日が「カレンダー月末」と一致しない → 経理側で別途エクセル管理に逆戻り
- キャッシュフロー予測の精度低下
- 仕入先からの請求書とアプリ側の支払予定がズレる
対処
- カスタムフィールド（custom field）で「締め日」「支払サイト」を別管理
- 月末計算は手動で外部スクリプトを噛ませる
- → 運用の手間が継続発生
ギャップ 2: 約束手形 / でんさい
日本の現実
中堅以上の B2B 取引では、いまだに 約束手形または電子記録債権（でんさい）での支払が一定数残っています。経済産業省の方針で 2026 年中に手形は廃止方向だが、実務では混在。
支払条件の例:
- 5 月 31 日締め、7 月末日 90 日手形
- 実支払日: 受領 + 90 日後 = 10 月末
海外アプリの対応
ほぼ 対応していない。Promissory Note のような概念は P2P 送金や旧米国制度では存在するが、日本式の「2 ステップ支払（手形受領 → 期日決済）」を扱える在庫管理アプリは皆無に近い。
影響
- 仕入先への支払予定日が アプリ上は「請求書発行日 + 30 日」表示だが、実際には「手形期日 = 請求から 90 日後」
- キャッシュフロー予測が大きくズレる
- 手形管理は 完全に経理ソフト（freee / マネーフォワード等）の領域
対処
- 在庫管理アプリは「発注・入荷管理」までに割り切る
- 「支払」は経理ソフトに完全に投げる
- 二重管理になるが現実的な運用
ギャップ 3: 季節性（お中元・お歳暮・お盆・GW）
海外モデルの想定
需要予測モデルは欧米のシーズナリティを基準にしている:
- Black Friday（11 月末）
- Cyber Monday（11 月末）
- Christmas（12 月）
- Easter（春先）
- Mother’s Day（5 月、5 月第 2 日曜固定で日本と日付ズレ）
日本固有のシーズナリティ
| 時期 | 影響 |
|---|---|
| お正月（12 月下旬-1 月） | おせち・正月食材・年賀状 |
| バレンタイン（2 月 14 日） | チョコ・ギフト食品 |
| ホワイトデー（3 月 14 日） | 同上、海外モデル想定外 |
| 入学・新生活（3-4 月） | 文具・家電・食器 |
| GW（5 月初旬） | アウトドア・旅行用品（海外には無いタイミング） |
| 父の日 / 母の日 | 日本特有のギフト食品傾向 |
| お中元（7 月） | ギフト食品・調味料・ビール、海外モデルに完全に無い概念 |
| お盆（8 月中旬） | 帰省土産・仏花、同上 |
| 敬老の日（9 月第 3 月曜） | ギフト食品 |
| ハロウィン（10 月末） | 仮装・お菓子（海外と部分一致） |
| ブラックフライデー（11 月末） | EC 全般（海外と一致） |
| お歳暮（12 月） | ギフト食品、同上 |
太字（お中元・お盆・お歳暮）は 海外モデルが完全に想定していないピーク。
影響
- 海外アプリの予測ロジックは「7 月の販売増」を 異常値として除外してしまう
- 結果、お中元前の発注タイミングを逃す
- 在庫切れが「7 月だけ集中して発生」する
対処
- 季節係数を 手動入力できるアプリならまだ運用可能
- できないアプリは 毎年予測精度が改善しない → モデルが学習しても「7 月は売れる」を学ばない
UreyukiBox の方向
UreyukiBox は v1 で「販売速度に基づくリマインダー」（SMA）路線、v1.x で 日本季節係数の自動適用 を予定しています。「お中元 7 月」「お盆 8 月」「お歳暮 12 月」をデフォルトで認識する設計。
ギャップ 4: 振込文化 / クレカ嫌い
海外の標準
B2B 支払は クレジットカードまたは ACH（米国の銀行間送金）。期日には自動で引き落とされる前提。
日本の現実
- B2B 取引は 銀行振込が圧倒的多数（クレカ手数料を嫌う文化）
- 期日に 手動振込 or 自動振込（FB データ） で送金
- 振込手数料は支払側 or 受取側、明示が必要
影響
- 海外アプリの「Mark as paid」は クレカ自動決済前提で UI が組まれている
- 「振込日」「振込手数料負担」「振込完了の確認手段」のフィールドが無い
- 経理 → 在庫管理アプリへの「支払完了」フィードバックが手動必要
対処
- 在庫管理アプリ上で「Mark as paid」は形式的に押すだけ
- 実際の振込管理は経理ソフト
- → ギャップ 2 と同じく二重管理
ギャップ 5: 軽減税率 / 税区分の複雑さ
日本の標準
- 標準税率 10%
- 軽減税率 8%（食品 + 一部新聞）
- 非課税（医療・教育・住宅家賃等）
- 不課税（給与・配当）
- 免税（輸出 0%）
商品ごとに税率を設定する必要があり、PO や仕入時にも税区分の整合性が求められる。
海外アプリの対応
- VAT / GST 等の 単一税率前提が多い
- 軽減税率 + 標準税率の 併用シナリオを扱えない
- 商品ごとの税率設定は Shopify 標準機能で対応できるが、PO 側の税計算 は不対応のものが多い
影響
- PO に複数税率の商品を含めると 合計税額の計算が手動
- 仕訳データ出力時に税区分が抜ける
- 経理処理で再分類の作業が発生
対処
- 食品系・物品系で別 PO に分ける
- 税計算を経理ソフトに丸投げ
ストア規模別の致命度
| ストア規模 | SKU 数 | 仕入先数 | 致命度 |
|---|---|---|---|
| 個人 EC（年商 1,000 万円以下） | < 500 | 1-3 | 低（Excel で凌げる） |
| 小規模（〜年商 5,000 万円） | 500-2,000 | 3-10 | 中（運用工数月数時間） |
| 中堅（〜年商 5 億円） | 2,000-10,000 | 10-50 | 高（経理工数月 1-2 日） |
| 大規模（年商 5 億円以上） | 10,000+ | 50+ | 致命（要日本特化 ERP） |
「致命度」が 中以上になると、海外アプリは 機能優秀でも運用上のボトルネックになります。
どう判断すべきか
海外アプリで OK なケース
- 個人 EC / 小規模ストア
- 仕入先が 3 社以下
- 商品が単一税区分（10% のみ）
- 月末締め以外の支払サイト（前払い・着払い等）
日本特化が必要なケース
- 中堅以上のストア
- 仕入先が 10 社以上
- 食品 + 雑貨で税区分混在
- 月末締め支払が中心
- お中元・お歳暮で年商の 30% 以上
UreyukiBox の方向性
UreyukiBox は 日本特化 + Shopify Native という立ち位置で開発中:
- 月末締め支払サイト をネイティブ対応（custom field 不要）
- お中元・お歳暮・お盆 を需要予測モデルに係数として組込み（v1.x）
- 軽減税率 / 標準税率 を商品マスタと PO で整合管理
- 手形・振込は経理ソフト（freee / マネーフォワード）に投げる前提（在庫管理は発注・入荷まで）
「全部やる」のではなく「日本商習慣の中核ギャップだけを埋める」設計。
中堅以上のストアで、海外アプリの運用工数に困っている場合は試す価値あり、という想定です。
FAQ
Q. Inventory Planner と UreyukiBox を比較したい
A. 機能網羅性は Inventory Planner、日本商習慣適合は UreyukiBox という棲み分けです。複数倉庫・複数通貨・複雑な MRP が必要なら Inventory Planner、月末締めお中元の運用ストレスを減らしたいなら UreyukiBox が向きます。
Q. 海外アプリ + 経理ソフト連携で十分？
A. 規模次第。年商 1 億円程度なら経理ソフト連携で凌げる。1 億円超えると データ量と仕訳パターンが多すぎて連携工数が上回るケースが出てきます。
Q. 全部 Shopify 標準で済まないの？
A. Shopify 標準の在庫管理は「在庫数を表示する」までで、需要予測・PO・仕入先・棚卸は全て不対応。Stocky / Inventory Planner / UreyukiBox 等のアプリ補完が必要。
Q. Stocky 移行 + 日本特化、どっちを優先？
A. 8 月 31 日までは Stocky 移行（データ救出）が最優先。日本特化の運用最適化は移行後の運用で改善するもの。
まとめ
海外発のアプリは機能としては良くできていますが、日本の商習慣との接続部分で年間数十時間の運用ロスが発生しがち。
「機能比較 + 価格」だけで選ぶと、運用フェーズで後悔するケースが多い領域です。自店舗の商習慣にとって致命的なギャップが何かを先に定義してから、アプリ選定する流れが安全。
UreyukiBox は 日本商習慣の中核ギャップを埋める ことを差別化軸として開発中（2026 年 7 月 15 日ローンチ予定）。