在庫管理システムの比較を始めるとき、多くの担当者はまず製品名の一覧表を作ろうとします。しかしタイやベトナムの工場で本当に必要なのは、製品リストではなく「自社にとっての物差し」です。倉庫だけを対象にするのか、購買から生産、出荷までつなぐのか。合わせたいのは数量なのか金額なのか。この前提が揃っていない状態でデモを何本見ても、印象で決めることになります。
本記事では、在庫管理システム比較のための物差しを3本提示します。システムを4タイプに整理する軸、費用を5層に分解する軸、そして在庫差異の原因を6つに分ける軸です。あわせて、タイ・ベトナムの日系工場だからこそ効いてくる論点(多言語、多通貨、BOI在庫、法定コスト、2次元コードへの移行)と、90日で現実的に立ち上げる進め方までを扱います。日本本社への説明資料としてそのまま流用できる粒度で書いていますので、必要な章だけを抜き出して使っていただいて構いません。
なお本記事の立場をはじめに明確にしておきます。在庫管理システムを入れれば在庫差異が消える、ということはありません。差異の原因のうちシステムで構造的に潰せるものは半分程度で、残りは現場の運用ルールと責任分担でしか直りません。この線引きをせずに導入すると、「高い費用を払って入力作業を増やしただけ」という最悪の結果になります。切り分けの具体的なやり方も後半で説明します。
在庫管理システムの比較で最初に決めるべき3つの前提
比較表を作る前に、社内で合意しておくべきことが3つあります。ここが曖昧なままだと、ベンダーごとに違う前提の見積が並び、比較そのものが成立しません。
前提1: 何の在庫を、どの粒度で合わせるのか
工場の在庫は一枚岩ではありません。原材料、購入部品、仕掛品、完成品、予備品・保全部品、副資材・消耗品、治工具・金型と、性質がまったく違うものが同じ「在庫」という言葉に押し込められています。
ここで決めるべきは対象範囲と粒度です。粒度とは、たとえば次のような選択です。
- 品目単位で数量を合わせるのか、ロット単位まで追うのか
- 倉庫単位で合わせるのか、棚番(ロケーション)単位まで合わせるのか
- 締めのタイミングで合っていればよいのか、リアルタイムで合っている必要があるのか
「ロット単位・棚番単位・リアルタイム」をすべて選ぶと、必要な現場入力回数は数倍になります。それを支えるだけの端末台数と教育工数を確保できるかまで含めて決める話です。逆に「月末に品目単位で合えばよい」なら、投資は一気に軽くなります。
前提2: 今の在庫精度を数字で把握する
比較の前に、現状値がないと効果を語れません。在庫精度は一般に「実地棚卸で数えた結果と、システム上の在庫が一致した品目の割合」で測ります。
業界のベンチマークとしては、在庫精度97%が最低ラインで、ベストインクラスは99%以上とされています。一方でバーコードスキャナ運用のWMSを入れた現場でも実力値は95〜98%にとどまるという調査もあります(出典: Factory AI)。
この数字は具体的に想像したほうがよいものです。管理品目が5,000品目ある工場で考えると、次のようになります。
- 在庫精度95%:合っていない品目は250品目
- 在庫精度97%:合っていない品目は150品目
- 在庫精度99%:合っていない品目は50品目
97%から99%へ上げるというのは、5,000品目のうち差異品目を150から50へ、つまり100品目減らすという作業です。「在庫差異をなくす」という曖昧な目標より、この形にしたほうが本社にも進捗を説明できます。
現状値を持っていない場合は、次章以降の比較に入る前に、まず100〜200品目を抜き出して数えてみることをおすすめします。全数棚卸をやり直す必要はありません。
前提3: システムで直す範囲と運用で直す範囲の線を引く
3つめが最も重要です。在庫差異の原因には、システムが構造的に防げるものと、ルールと責任分担でしか防げないものがあります。前者だけを期待して導入すると必ず失望します。
タイ製造業の足元は決して楽な環境ではありません。タイ工業経済局が公表する製造業生産指数(MPI)は2026年6月に前年同月比マイナス3.10%となり、前年11月以来で最大の下げ幅を記録しました。2026年第2四半期はマイナス1.79%で、第2四半期の平均稼働率は57.47%でした(出典: Xinhua、2026年7月27日)。6月単月の落ち込みは四半期平均より1.31ポイント大きく、自動車・石油関連の減産が主因とされています。
稼働率57.47%は、裏を返せば設備能力の42.53%が動いていないということです。稼働が落ちている局面では、作りかけの仕掛品と売れ残りの部品在庫が滞留しやすくなります。だからこそ在庫の見える化に投資する意味はあるのですが、同時に投資回収の説明はより厳しく問われます。「入れれば直ります」と説明して外すと、次の投資が通らなくなります。
在庫管理システムの4タイプ比較
在庫管理システムという言葉は、実際には性格の異なる4つのカテゴリを指しています。横軸に「カバー範囲(倉庫だけか、調達から生産・出荷までか)」、縦軸に「カスタマイズ性(低いか高いか)」を置くと、それぞれの位置がはっきりします。

タイプA: 在庫専用クラウド(SaaS型在庫管理)
入出庫と在庫残高の管理に機能を絞ったクラウドサービスです。ブラウザとスマートフォンで動くものが多く、契約すればすぐ使い始められます。
強いのは立ち上げの速さと初期費用の軽さです。弱いのは製造業固有の要件で、部品表(BOM)に基づく所要量計算、工程ごとの仕掛品、ロット・製造番号のトレーサビリティといった領域はカバー範囲外か、あっても簡易的です。カスタマイズはできない前提で、自社の運用を製品側に合わせる覚悟が必要です。
タイプB: WMS(倉庫管理システム)
倉庫の中の作業を最適化するためのシステムです。ロケーション管理、入荷検品、ピッキング指示、ロット・先入先出(FIFO)の強制、ハンディターミナルでの作業実績登録が中心になります。
「あるはずのものが見つからない」「古いロットが奥に残る」といった倉庫内起因の問題には最も効きます。一方で、製造指示や工程実績とは本来つながっていないため、仕掛品の管理や原価計算までは面倒を見ません。倉庫と物流側の全体像は東南アジアの物流DXとWMSの実務の記事でも整理しています。
WMS市場そのものは拡大しています。Mordor Intelligenceの推計では、市場規模は2025年の40.4億米ドルから2026年に47.7億米ドルへ、2026〜2031年の年平均成長率(CAGR)は17.98%とされています。2025年から2026年の伸びは単純計算で約18.1%で、示されているCAGRとほぼ同水準です。この成長率がそのまま続くと仮定して単純計算すると、5年で市場規模は約2.29倍、2031年には約109億米ドルの水準になります。牽引役はクラウド型です。
タイプC: 生産管理・ERPの在庫モジュール
生産管理システムやERPの一部として在庫を持つ形です。部品表と所要量計算、購買発注、工程実績、原価計算と在庫が同じデータベースの上に載るため、「在庫が動いた理由」が業務プロセスとして残ります。
最大の利点は、在庫差異の原因追跡が業務単位でできることです。欠点は導入の重さで、マスタ整備の範囲が広く、関係部門が増え、意思決定にも時間がかかります。生産管理システム側からの視点はタイ工場の生産管理システム導入で扱っていますので、あわせてご覧ください。
タイプD: スクラッチ開発
自社専用に作る方式です。既存の紙帳票や独自の管理単位にそのまま合わせられるため、現場の抵抗が最も小さく済むことがあります。
一方で、作った後の保守と、担当者が変わったときの引き継ぎがリスクになります。とくに海外拠点では、開発したベンダーとの関係が続くかどうかが実質的な事業継続リスクです。ソースコードとドキュメントの帰属を契約書で明記しておかないと、数年後に手を出せない箱になります。
4タイプの比較表
| 比較軸 | A 在庫専用クラウド | B WMS | C 生産管理・ERP在庫 | D スクラッチ開発 |
|---|---|---|---|---|
| カバー範囲 | 入出庫と在庫残高 | 倉庫内作業全般 | 調達から生産・出荷 | 定義した範囲のみ |
| カスタマイズ性 | 低い | 中程度 | 中程度から高い | 最も高い |
| 初期費用の重さ | 軽い | 中程度 | 重い | 中程度から重い |
| 立ち上げ期間の目安 | 1〜2か月 | 3〜6か月 | 6〜12か月 | 6か月以上 |
| ロケーション管理 | 簡易または非対応 | 得意 | 製品により差が大きい | 作り込み次第 |
| 仕掛品・工程連動 | 弱い | 弱い | 得意 | 作り込み次第 |
| 多言語UI | 製品依存で英語中心 | 製品依存 | 主要製品は多言語対応 | 自由に設計可能 |
| 保守の継続性 | ベンダー任せで安定 | 比較的安定 | 安定 | 属人化リスクが高い |
| 向いているケース | まず数量を合わせたい | 倉庫内で物が迷子になる | 原価と在庫を一体で見たい | 既存業務を変えられない |
| 典型的な落とし穴 | 製造要件に届かない | 生産側と二重入力になる | 稼働までに息切れする | 数年後に改修不能になる |
立ち上げ期間はあくまで当社が現地案件で見てきた傾向で、対象品目数、拠点数、既存システムとの連携本数によって大きく変わります。
この表の使い方には注意点があります。「カバー範囲が広いほど良い」わけではありません。倉庫内で物が見つからないことが最大の問題なら、ERPの在庫モジュールを入れてもロケーション管理が弱ければ解決しません。逆に、原価と在庫の乖離を本社から問われているなら、WMSをいくら磨いても答えになりません。問題の所在と、タイプの得意領域を一致させるのが比較の本質です。
在庫管理システムの費用を5層に分解する
在庫管理システムの費用を聞かれたとき、ライセンス費だけを答えると必ず後で揉めます。実際の支出は5つの層に分かれており、ライセンス費はそのうちの一部にすぎません。

費用の5層とその中身
| 層 | 費用の中身 | 中位ケースの構成比 | 見落とされやすい点 |
|---|---|---|---|
| 1 ライセンス・サブスク | 利用料、ユーザー数課金、オプション機能 | 20% | ユーザー追加で毎年増える |
| 2 ハードウェア・現場機器 | ハンディ端末、ラベルプリンタ、無線AP、サーバー | 15% | 端末の予備機と修理費 |
| 3 マスタ整備・現物カウント | 品目マスタ整理、単位定義、棚番付与、初期棚卸 | 25% | 自社の工数として計上されない |
| 4 既存システム連携 | 会計・購買・生産システムとのデータ連携開発 | 25% | 連携本数で線形に増える |
| 5 初年度運用・教育 | 教育、多言語手順書、問い合わせ対応、初期改修 | 15% | 稼働後3か月が最も手がかかる |
構成比は5層で合計100%になるように置いた中位ケースの目安です。この比率を前提にすると、ライセンス費を1としたときの総額は約5倍(100 ÷ 20 = 5)になります。
案件の幅を見ると、当社が現地で関わってきた範囲では、ライセンス費を1としたときの各層はおおむね次のレンジに収まる傾向があります。
- 第2層 ハードウェア:0.3〜1.0
- 第3層 マスタ整備・現物カウント:0.5〜1.5
- 第4層 既存システム連携:0.5〜2.0
- 第5層 初年度運用・教育:0.3〜0.8
この下限をすべて足すと 1 + 0.3 + 0.5 + 0.5 + 0.3 = 2.6、上限をすべて足すと 1 + 1.0 + 1.5 + 2.0 + 0.8 = 6.3 です。つまり総額はライセンス費の2.6〜6.3倍、実務的には3〜6倍を見ておくのが安全ということになります。中位ケースの5倍はこのレンジの中に収まっています。
見積を比較するときは、この5層のうちどこまでが含まれているかを必ず確認してください。ライセンス費だけを提示するベンダーと、マスタ整備と連携まで含めて提示するベンダーの金額を並べても、意味のある比較にはなりません。
公開されている費用相場との距離
日本市場の相場としては、クラウド型は初期費用0〜数万円に月額2〜5万円程度、オンプレミス型は初期費用100〜1,000万円に年額10〜40万円程度というレンジが紹介されています(出典: システム幹事)。この数字を使って3年・5年の総額に置き直すと、比較の見え方が変わります。
クラウド型の年額は、月額2万円なら24万円、月額5万円なら60万円です。3年総額は72〜180万円にわずかな初期費用を加えた水準、5年総額は120〜300万円に初期費用を加えた水準になります。
オンプレミス型の3年総額は、初期100万円+年額10万円×3年で130万円、初期1,000万円+年額40万円×3年で1,120万円という幅です。5年では初期100万円+年額10万円×5年で150万円、初期1,000万円+年額40万円×5年で1,200万円となります。
つまり5年で見ると、クラウド型の上限側300万円に対してオンプレミス型の上限側は1,200万円で、4倍の開きがあります。一方で下限側を比べるとクラウド型120万円、オンプレミス型150万円と大きな差はありません。「クラウドは安く、オンプレは高い」という単純な図式ではなく、オンプレミス型は上限方向の幅が非常に広い、というのがこのレンジの読み方です。
ここで重要なのは、この日本市場のレンジをそのままタイやベトナムの相場として本社に説明してはいけないということです。現地の相場は、現地法人の規模、日本語対応の要否、現地でのサポート体制の有無、そして上記の第3層と第4層をどこまで外注するかで大きく変わります。同じ製品でも、日本での価格と現地での実質負担額は一致しません。
とくに海外拠点で膨らみやすいのは第3層と第5層です。品目マスタが日本本社と現地で二重管理されている、単位が現場によって「箱」「個」「キログラム」で混在している、手順書を日本語・英語・タイ語(またはベトナム語)の3言語で作らなければならない。こうした事情が工数に直接乗ってきます。棚卸そのものの費用構造についてはRFIDを使った工場棚卸の費用の記事で、機器コストまで踏み込んで整理しています。
効果側の試算をどう作るか
投資額だけを並べても本社の決裁は通りません。効果側の試算も必要ですが、ここで実在しない数字を持ち出すと後で必ず崩れます。おすすめは、仮定であることを明示した単純モデルを1本だけ置く方法です。
以下は実在の案件数値ではなく、説明用に置いた仮の数字です。在庫金額が5,000万バーツ、在庫回転が年6回の工場を考えます。このとき年間の払出額は 5,000万 × 6 = 3億バーツです。回転を年8回に上げられたとすると、必要な在庫金額は 3億 ÷ 8 = 3,750万バーツになり、在庫は1,250万バーツ減ります。
この計算の意味は「在庫が1,250万バーツ減る」という予測ではありません。回転を1回上げることが金額にしてどれくらいのインパクトなのかを、自社の数字で把握しておくことにあります。自社の在庫金額と回転数を入れて計算すれば、投資額と同じ桁で議論ができるようになります。
もうひとつ、棚卸の直接工数も計算しておくと説明が具体になります。作業者20人が2日間かかっているなら40人日です。バンコクや東部集積地の法定最低賃金である日額400バーツで単純計算しても16,000バーツ、年4回の実施なら64,000バーツです。実際の賃金はこれより高く、残業・休日出勤の割増、間接部門の立会工数、棚卸のための出荷停止による機会損失はこの計算に含まれていません。あくまで下限値として押さえる数字です。
なぜ在庫差異は消えないのか — 原因を6つに分解する
ここが本記事の中心です。在庫差異の原因を6つに分けて、それぞれ「システムで直る度合い」を明示します。
| 原因 | 現場での症状 | システムで直る度合い | 現場運用で決めるべきこと |
|---|---|---|---|
| 1 入荷検収の数量未確認 | 納品書の数量を信じて登録している | 部分的 | 全数か抜取りかの基準と抜取り率 |
| 2 出庫入力の後回し | 先に物が出て、入力は翌日以降 | 高い | 入力を作業の一部にする動線設計 |
| 3 単位・入目の換算ミス | 箱と個と重量が混在している | 高い | 発注単位と払出単位の統一ルール |
| 4 緊急払出の非公式運用 | 後で戻す前提で持ち出している | 低い | 誰が承認し、いつまでに戻すか |
| 5 不良・スクラップの未計上 | 捨てた分が帳簿に残っている | 部分的 | 廃棄伝票の発行者と締切 |
| 6 ロケーション未定義 | 帳簿にはあるが見つからない | 高い | 棚番の付与ルールと定位置の維持 |
システムで構造的に潰せる3つ
単位・入目の換算ミス(原因3)は、システムの得意分野です。品目マスタで基本単位と換算係数を1か所に定義し、発注は箱、払出は個で入力しても内部では同じ単位に揃うようにすれば、人の暗算による誤りは消えます。ただしこれは「マスタを正しく整備した場合」の話で、費用の第3層に直結します。
ロケーション未定義(原因6)も同じです。棚番を付けて、入庫時に棚番を記録し、ピッキング時に棚番を指示すれば、「あるはずなのに見つからない」は大きく減ります。ハンディターミナルを使うWMSが最も効く領域です。
出庫入力の後回し(原因2)は、システムと運用の境界にあります。端末を出庫場所に置いて、物を出す動作と入力を同時にできるようにすれば大幅に改善します。逆に、事務所のPCで後からまとめて入力する運用のままシステムを替えても、差異は減りません。端末の設置場所と台数が、この原因の改善度をほぼ決めます。ここを節約すると投資全体が無駄になります。
運用でしか直らない3つ
緊急払出の非公式運用(原因4)は、システムでは止められません。ラインが止まりそうなときに、担当者が倉庫から部品を持ち出して後で伝票を書く、あるいは書かない。これは善意から起きるので、罰則で抑えても地下化するだけです。有効なのは「緊急払出そのものを認めた上で、簡易な記録手段を用意する」方向です。専用の伝票番号を用意し、24時間以内に正式伝票へ振り替える、といったルールを決めます。
不良・スクラップの未計上(原因5)は、廃棄の意思決定を誰がするかという組織の問題です。工程内不良を出した本人が廃棄伝票を出すのは心理的に難しく、結果として物理的には捨てられているのに帳簿に残ります。品質保証部門が定期的に廃棄処理をまとめる、といった責任の切り分けが必要です。
入荷検収の数量未確認(原因1)は、部分的にはシステムで支援できます(発注数量との突合、差異のアラート)が、そもそも数えていなければ検知できません。全数検収するのか、抜取りにするのか、抜取りなら何パーセントか。これは自社で決めるしかない基準です。
サイクルカウントの本当の目的
年次または四半期ごとの全数棚卸に加えて、日常的に一部を数え続ける手法をサイクルカウント(循環棚卸)と呼びます。在庫を止めずに、対象を回転させながら数えていく方式です。
ここで誤解されやすいのは目的です。サイクルカウントの目的は数字を修正することではなく、差異の原因を特定することにあります(出典: Factory AI)。数字を合わせるだけなら年1回の全数棚卸で足りますが、それでは原因が分かりません。差異が見つかった直後に、直前の入出庫履歴をたどって原因の6分類のどれに当たるかを判定する。この作業を毎週続けることで、はじめて構造的な改善が可能になります。
言い換えると、サイクルカウントは在庫精度を上げる施策ではなく、上記6原因のうち自社で今どれが支配的なのかを知るための計測手段です。システム選定の前にこれを2〜3週間回すと、比較の軸が自然に定まります。
Excelの在庫管理が限界を迎えるサイン
Excelによる在庫管理は、決して悪い選択ではありません。品目数が少なく、担当者が固定で、拠点が1つなら、十分に機能します。問題は限界を超えたときに気づきにくいことです。以下のうち3つ以上に当てはまるなら、移行の検討時期です。
- 同じファイルの複数バージョンが存在している。 「最新版」「最新版2」「最新版_修正」といったファイル名が並んでいる。誰の手元の数字が正しいのか分からない状態です。
- 月次締めに3日以上かかっている。 集計とチェックに時間を取られ、締めた瞬間には既に古い数字になっています。
- 数式が壊れても誰も気づかない。 行の挿入で参照範囲がずれ、合計が合わなくなっていることに月末まで気づかない。
- 発注点が人の記憶になっている。 「この部品はだいたい200個切ったら発注」という知識が、特定の担当者の頭の中だけにある。その人が休むと欠品します。
- 在庫金額が会計側の在庫残高と合わない。 現場管理のExcelと会計システムで違う数字を持っており、差の理由を誰も説明できない。
- 1人しか触れないファイルになっている。 マクロや複雑な数式が入り、作った人以外がメンテナンスできない。属人化の典型です。
- 品目数が増えてファイルが重い。 開くのに時間がかかり、フィルタ操作でフリーズする。数千行を超えたあたりから顕著になります。
- 複数拠点・複数倉庫の在庫を合算できない。 拠点ごとにファイルが分かれ、全社在庫を出すのに手集計が必要になっている。
ここで重要な補足があります。Excelをやめてもこれらの問題が全部消えるわけではありません。とくに項目4(発注点の属人化)は、システムに発注点の数値を登録する作業をしなければ、そのまま残ります。「システムが自動で適正在庫を決めてくれる」ということはなく、誰かがリードタイムと需要変動から数値を決め、定期的に見直す必要があります。この作業のオーナーを決めないままシステムを入れるのが、よくある失敗です。
タイ・ベトナム工場ならではの5つの論点
日本国内向けの比較記事には出てこない、しかし現地では避けて通れない論点があります。
論点1: 多言語UIとマスタの多言語化は別問題
画面の言語切り替えができることと、品目名がタイ語やベトナム語で表示されることは、まったく別の話です。前者は製品機能ですが、後者はマスタの整備作業です。品目マスタに「日本語名称」「英語名称」「現地語名称」の3フィールドを持たせるかどうか、持たせるなら誰が翻訳するのか。数千品目分の翻訳工数は、費用の第3層に確実に乗ります。
現場作業者がタイ語話者だけでなく、ミャンマー語やカンボジア語を第一言語とする場合もあります。この場合、言語を増やすより「画面上の文字を減らして、コード・色・写真で判断できるようにする」ほうが実務的です。品目マスタに写真を1枚持たせるだけで、取り違えが目に見えて減ることがあります。
論点2: 多通貨と在庫評価
購買がタイバーツ、米ドル、日本円の混在になるのは日系工場では普通です。在庫の受入単価をどの通貨・どのレートで持つのか、月次の評価替えをどうするのかは、会計方針の話でもあります。在庫管理システム側が単一通貨しか持てない場合、会計システムとの差異が構造的に発生します。比較の段階で、多通貨の受入単価を持てるか、レートの適用ルールを設定できるかを必ず確認してください。
論点3: BOI恩典を受けている原材料在庫
BOI(タイ投資委員会)の恩典で原材料を免税輸入している場合、免税枠と実在庫の数量整合が求められます。社内管理用の在庫数量とは別に、BOI報告用の数量管理が必要になるケースがあり、この二重管理をシステムでどう扱うかは早めに決めるべき論点です。実地棚卸の結果と報告数量が食い違うと、単なる社内問題では済みません。
BOIの投資申請自体は活発です。2026年上期のタイBOIへの投資申請は1,299件・1兆4,730億バーツで、前年同期比プラス37%となりました。うちデジタル産業が1兆1,150億バーツ(90件)で申請額全体の約76%、電子・電機が1,202.3億バーツ(179件)で約8%を占めます。外国直接投資(FDI)は877件・1兆3,680億バーツでプラス80%、金額では申請額全体の約93%に相当します(出典: The Nation)。
工場のIT投資に直接関係するのは「Smart and Sustainable Industry」措置で、こちらは132件・171.58億バーツでした。申請額全体に占める比率は約1.2%にとどまりますが、1件あたりでは約1億3,000万バーツ(171.58億バーツ ÷ 132件)の規模です。対象には機械更新、省エネ、デジタル技術の導入、自動化とロボットが含まれます。なお申請額全体の1件あたり平均は約11億3,000万バーツで、デジタル産業だけを見ると1件あたり約124億バーツという突出した水準です。データセンター系の大型案件が金額を押し上げていると読むのが自然で、この平均額を自社の投資規模の参考にはできません。
論点4: depa 200%損金算入は使えるのか
タイでは、勅令802号(仏暦2569年)が2026年2月6日に官報公布され、depa(デジタル経済振興機構)のThailand Digital Catalogに登録されたソフトウェア、ハードウェア、スマートデバイス、デジタルサービスの購入・委託・利用料について200%損金算入が認められました。上限は30万バーツ、支出期限は2027年12月31日です(出典: Mahanakorn Partners)。
ただし対象要件が重要です。払込資本金500万バーツ以下、かつ売上3,000万バーツ以下のSMEが対象で、汎用のノートPCやデスクトップPCは対象外です。日系製造業の現地法人は、払込資本金も売上もこの要件を大きく上回るケースが大半で、実際には適用できないことが多いのが正直なところです。
さらに上限30万バーツという金額は、在庫管理システムの導入規模から見ると小さいものです。費用の第3層(マスタ整備・現物カウント)の外注費だけでこの枠を使い切ってしまう水準と考えたほうがよいでしょう。この制度を投資判断の前提に置かないことをおすすめします。適用可能性がありそうな場合は、必ず税務アドバイザーに個別確認してください。
論点5: GS1 Sunrise 2027と2次元コードへの移行
ラベル設計に関わる話です。GS1が主導する「Sunrise 2027」は、2027年末までに小売のPOSが1次元バーコードとGS1準拠の2次元コード(GS1 DataMatrixやGS1 Digital LinkのQR)の両方を読めるようにする国際イニシアチブです。移行期間中は1次元と2次元を併記し、2028年以降は2次元コードのみでの運用が可能になります。48か国、世界GDPの約88%に相当する地域の企業が準備を進めているとされています(出典: GS1 US)。
工場内部だけで使うラベルなら形式は自由ですが、取引先や小売向けに表示するラベルは影響を受けます。これから在庫管理システムを選ぶなら、ラベル発行機能が2次元コードに対応しているか、1次元と2次元の併記レイアウトを作れるかを確認しておくと、数年後の作り直しを避けられます。2次元コードは同じ面積に多くの情報を入れられるため、ロット番号や有効期限を1つのコードに収められるという実務的な利点もあります。ラベルや帳票の電子化全般については工場の電子帳票とペーパーレス化の記事もご参照ください。
参考: ベトナム拠点の状況
ベトナムに拠点がある場合、需要環境はタイと異なります。ベトナムの製造業PMIは2026年6月に51.8で、5月の52.8から1.0ポイント低下したものの、好不況の分岐点である50を1.8ポイント上回る水準を維持しました。生産は14か月連続で拡大し、6月の生産拡大ペースは2月以来最速でした。2026年上期の製造業付加価値はプラス9.97%と、約10%の伸びです(出典: VietnamPlus)。
増産局面で在庫管理が追いつかなくなるパターンは、減産局面とは症状が違います。減産局面では滞留在庫と評価損が問題になりますが、増産局面では欠品による生産停止と、急な追加発注による輸送費の増加が問題になります。同じ「在庫管理システムを入れる」でも、タイ拠点とベトナム拠点で優先すべき機能が変わりうることに注意してください。ベトナム拠点では発注点管理と安全在庫の適正化が、タイ拠点では滞留在庫の可視化と長期在庫の判定ルールが、それぞれ先に来ることが多いという印象です。
部品・予備品・仕掛品 — 在庫の種類ごとに要件が変わる
前提1で触れた点を具体化します。在庫の種類によって、必要な機能はまったく違います。すべてを同じ方式で管理しようとすると、どこかで無理が出ます。
原材料・購入部品は、発注点管理と安全在庫の設定が中心です。輸入品はリードタイムが長く、変動も大きいため、安全在庫の設定根拠を持っておく必要があります。ロット管理とFIFOの強制が必要かどうかは、業種と顧客要求によります。
仕掛品(WIP)は、在庫管理システム単体では扱いにくい領域です。工程実績の登録と連動していなければ、仕掛品の数量は把握できません。ここは生産管理システムやMESの領域で、在庫管理システムだけを導入した工場が最初につまずくポイントでもあります。「仕掛品も見たい」という要求が出たら、それはタイプCの検討に入るという意味です。
完成品は、出荷指示との引当、ロットの逆引き(出荷先からロットをたどる、またはロットから出荷先をたどる)が要件になります。品質問題が起きたときの回収範囲の特定に直結するため、トレーサビリティの設計と一体で考えるべき領域です。詳しくはトレーサビリティシステム構築の費用の記事で扱っています。
予備品・保全部品(MRO)は最も扱いが難しい在庫です。需要が散発的で発注点の統計的な計算が効かず、単価が高く回転が低い。設備が止まったときにないと困るので減らせない。この在庫は「数量を合わせる」よりも「どこにあるかが分かる」ことのほうが価値が高いケースが多く、棚番管理と現物ラベルの整備が優先されます。
副資材・消耗品は、逆に個別管理しないほうが安いことが多い在庫です。手袋、ウエス、ネジ類などを1個単位で入出庫登録すると、管理コストが在庫金額を上回ります。消費点に置いてカンバン方式で補充し、月次で購入額だけを費用処理する、といった割り切りが現実的です。在庫管理システムの導入時に「全品目を登録する」と決めてしまうと、この判断ができなくなります。
治工具・金型は数量ではなく所在の管理です。誰が持ち出して、いまどこにあるか。用途としてはRFIDが向く領域ですが、金属に貼るタグの選定や読み取り環境の設計に固有の難しさがあります。
| 在庫の種類 | 主要な要件 | 適したタイプ | 管理を軽くする判断 |
|---|---|---|---|
| 原材料・購入部品 | 発注点、安全在庫、ロット | A / B / C | 単価の低い品目は発注点だけ管理 |
| 仕掛品 | 工程実績との連動 | C | 工程数を絞って中間在庫点を減らす |
| 完成品 | 引当、ロット逆引き | B / C | 出荷単位をパレット単位に統一 |
| 予備品・保全部品 | 所在把握、棚番 | B | 数量精度より棚番精度を優先 |
| 副資材・消耗品 | 補充の切れ目防止 | 対象外でよい | 個別登録せずカンバン補充 |
| 治工具・金型 | 持ち出しと所在の記録 | B または専用 | 台数が少なければ台帳運用で足りる |
この表の一番右の列が実務では最も価値があります。管理対象を増やさない判断を明示的にしておかないと、システム導入は必ず入力作業の増加として現場に着地します。
導入の進め方 — 90日ロードマップ
在庫管理システムの導入で最初にやるべきことは、システムの選定ではありません。現物を数えることです。以下は3フェーズ・90日の進め方で、タイプA(在庫専用クラウド)またはタイプB(WMS)を前提としています。

なお、タイプC(生産管理・ERPの在庫モジュール)を全面的に導入する場合、90日は現実的ではありません。その場合は「在庫の範囲だけを先行稼働させる」という区切り方をして、この90日を第1段として位置づけるのが現実的です。ERP全面刷新を3か月で終える話ではない、という点は本社にも早めに伝えておくべきです。
フェーズ1(1日目〜30日目): 現物カウントと現状把握
やること
- 対象品目の棚卸(全数でなくてもよい。金額上位品目とトラブルが多い品目から)
- 品目マスタの重複・廃止品の洗い出し
- 単位(UOM)の実態調査。どの品目がどの単位で発注・払出されているか
- サイクルカウントを週1回のペースで開始し、差異の原因を6分類で記録
- 現状の在庫精度の測定と記録
このフェーズのゴールは、システムを選ぶための現状値を持つことです。在庫精度が何パーセントで、差異の原因の内訳がどうなっているか。これが分かれば、必要な機能が絞られます。
よくある失敗は、このフェーズを飛ばしてベンダー選定に入ることです。現状値がないと、ベンダーの提案が自社の問題に効くのか判断できません。
フェーズ2(31日目〜60日目): ロケーション定義とマスタ整備
やること
- 棚番(ロケーション)の付与ルール決定と現物へのラベル貼付
- 品目マスタの整備。基本単位と換算係数の定義
- 現場入力の動線設計。端末をどこに何台置くか
- 帳票・レポートの要求整理。本社報告に必要な様式の確認
- 差異発生時の是正フロー(誰が調査し、誰が承認するか)の文書化
- 多言語の用語集作成。同じものを指す日本語・英語・現地語の対応表
このフェーズが最も地味で、最も重要です。棚番の付与ルールは一度決めると変えにくいため、拡張を見込んだ設計にしておきます。通路・棚・段・間口の4階層が基本形ですが、倉庫の規模が小さければ簡略化してかまいません。むしろ最初から細かくしすぎて、現物ラベルの貼り替えが追いつかなくなるほうが問題です。
多言語の用語集は軽視されがちですが、これがないと現場のタイ語表現と本社の日本語表現が対応せず、問い合わせのたびに翻訳作業が発生します。30〜50語の対応表を作るだけで、稼働後の混乱が大きく減ります。
フェーズ3(61日目〜90日目): PoCから本稼働へ
やること
- 1つの倉庫または1つの品目群に絞ったPoC(実証運用)
- PoC期間中も従来の管理を並行させ、差異を毎日比較
- 現場からの改善要求の受付と、対応・非対応の切り分け
- 教育。手順書は文字を減らし、写真と画面キャプチャを中心に
- 本稼働の判定基準を事前に決める(例: PoC対象品目の在庫精度が2週間続けて目標値以上)
- 本稼働開始と、旧運用の停止日の明示
PoCを「うまくいったら本稼働」という曖昧な形にすると、いつまでも並行運用が続きます。判定基準と旧運用の停止日を先に決めることが、稼働のコツです。
30日+30日+30日で合計90日という配分ですが、フェーズ2のマスタ整備と棚番ラベル貼付の分量が想定を超えることはよくあります。その場合はフェーズ2を延ばし、フェーズ3を縮めないことをおすすめします。教育と並行運用の期間を削ると、稼働直後の混乱が長引きます。全体が90日から120日に伸びても、稼働後に差異が続くよりはるかに安く済みます。
失敗パターンと回避策
当社が現地案件で見てきた範囲で、繰り返し現れるパターンを挙げます。
1. マスタ整備を後回しにして稼働する。 「動かしながら直そう」で始めると、誤ったマスタに基づく取引データが積み上がり、後からの修正コストが膨らみます。品目マスタの重複と単位定義だけは、稼働前に必ず終わらせてください。
2. 現物を数えずに帳簿の数字を初期在庫にする。 導入の効果を測る基準点そのものが狂います。全数でなくてよいので、金額上位品目は必ず数えてから初期在庫を入れます。
3. ロケーションを付けずに「倉庫1」だけで始める。 後から棚番を追加するのは、稼働中のデータを持ったままの作業になり、初期に付けるより手間が増えます。棚番の桁数だけでも先に決めておくべきです。
4. 現場端末を必要数買わない。 ハンディターミナルを1台だけ買って「まず試してみる」と、順番待ちが発生して結果として後回し入力が定着します。原因2(出庫入力の後回し)が改善しないまま、システム費用だけが発生する構図です。予備機を含めた台数を最初から確保してください。
5. 本社の要求帳票に合わせて設計する。 本社が求める分析軸をすべて満たそうとすると、現場の入力項目が増えます。「その項目は誰が、いつ、どの画面で入力するのか」を必ず確認してください。入力者が特定できない項目は、必ず空欄になります。
6. 全品目・全倉庫を一斉に切り替える。 問題が起きたときの切り戻し先がなくなります。倉庫単位または品目群単位で区切って進めるほうが、結果的に早く終わります。
7. 差異が出たときの是正フローを決めていない。 差異を見つけても誰が調査して誰が帳簿を修正するかが決まっていないと、差異リストが放置されます。差異の金額基準(この金額以下は現場判断で修正、超えたら管理部門の承認)まで含めて決めてください。
8. 言語をローカライズしただけで用語集を作らない。 画面がタイ語になっても、品目名や作業名の呼び方が現場と本社で違えば、コミュニケーションコストは下がりません。
9. 適正在庫の見直しオーナーを決めない。 発注点と安全在庫の数値は、需要とリードタイムが変わればずれます。誰が、どのくらいの頻度で見直すのかを決めておかないと、システム上の発注点は導入時の数値のまま化石化します。
10. 現場が使わない理由を教育不足だと決めつける。 稼働後に「現場が入力してくれない」という相談を受けることがありますが、原因はたいてい教育ではなく動線か言語です。動線の問題とは、端末が作業場所から離れていて、物を動かす動作と入力を同時にできないことです。この場合は端末を増やすか設置場所を変えるしかなく、教育を増やしても改善しません。言語の問題とは、画面の用語が現場の呼び方と違うことで、これは用語集を作ってシステム上の表記を現場側に合わせます。どちらでもない場合は入力項目が多すぎる可能性があるので、「その項目を誰がいつ入力するのか」を1項目ずつ確認し、答えられない項目を削るところから始めてください。
本社への説明資料をどう組み立てるか
海外拠点のIT投資でよくある障害は、技術的な問題ではなく説明の問題です。以下の順で1枚ずつ作ると、意思決定の議論がしやすくなります。
- 現状の在庫精度と差異原因の内訳。 フェーズ1で測った実測値を出します。「在庫精度が今95%で、差異の原因は入力遅れが4割、単位換算ミスが3割」という形で、事実から始めます。
- システムで直る範囲と運用で直る範囲の切り分け。 原因6分類の表をそのまま使えます。この1枚があると、「システムを入れれば全部直る」という期待値を最初に調整できます。
- 4タイプの中で自社が選ぶタイプとその理由。 選んだ理由ではなく、選ばなかった理由を書くのがコツです。「WMSではなくERPの在庫モジュールを選んだのは、本社から求められているのが原価と在庫の整合だから」といった形です。
- 費用の5層内訳。 ライセンス費だけでなく5層すべてを出し、うち何が自社工数で、何が外部支出かを分けます。総額がライセンス費の3〜6倍になる理由が説明できていれば、後からの追加予算申請を避けられます。
- 効果側の試算と、その仮定。 在庫回転の改善による在庫金額のインパクト、棚卸工数の削減、欠品による生産停止の削減。それぞれについて、仮定を明示します。仮定を隠すより明示したほうが信頼されます。
- 90日ロードマップと判定基準。 いつ何が終わるのか、本稼働の判定基準は何かを書きます。
タイのコスト環境についても補足しておくと説明が通りやすくなります。タイの最低賃金は2025年7月1日施行でバンコク都の全業種が日額400バーツとなりました(従前372バーツで、差は28バーツ、上げ幅は約7.5%)。製造業が集積するチョンブリー、ラヨーンなど4県1郡では2025年1月から400バーツが適用されています。2026年に入っても据え置きで、全国では日額337〜400バーツの水準が続いています(出典: JETRO)。日額28バーツの差は、月26日稼働で計算すると1人あたり月728バーツの増加です。
社会保険も変わりました。2025年12月12日に官報公布された省令により、2026年1月1日から社会保険料の算定基礎賃金の上限が月額15,000バーツから17,500バーツへ引き上げられました(下限は1,650バーツ)。上限の引き上げ幅は2,500バーツ、率にして約16.7%です。月額の拠出上限は労使各750バーツから875バーツへ増えました。いずれも算定基礎の5%(750 ÷ 15,000 = 5%、875 ÷ 17,500 = 5%)にあたる水準で、率そのものは変わっていません。上限はその後も2029年1月から20,000バーツ、2032年1月から23,000バーツへ段階的に引き上げられる予定です(出典: JETRO)。
会社負担の増加は1人あたり月125バーツ、年間1,500バーツです。仮に該当者が200人いれば年間30万バーツの追加負担になります。ただし注意点があり、この増加が満額発生するのは月額賃金が17,500バーツ以上の従業員です。日額400バーツの作業者は月26日稼働で10,400バーツとなり、従来の上限15,000バーツにも達しません。つまりこの負担増は主に事務・技術・管理職層に効いてくる性質のもので、直接作業者の人数では計算できません。
興味深いのは金額感の一致です。上で計算した年間30万バーツという追加負担は、depa 200%損金算入の上限30万バーツとほぼ同じ規模です。片方は毎年発生する固定費の増加、もう片方は限られた期間・限られた対象にのみ使える一度きりの優遇であり、優遇制度を投資判断の中心に置くべきでない理由がここにも表れています。
こうした法定コストの上昇局面では、「人を増やして在庫を管理する」方向の説明は通りにくくなります。逆に言えば、棚卸工数や入力工数の削減を効果として示す説明は、以前より受け入れられやすくなっているということです。
よくある質問
在庫管理システムの費用はいくらかかりますか
ライセンス費だけを見ると誤ります。本記事で示した5層(ライセンス、ハードウェア、マスタ整備、既存システム連携、初年度運用)の合計で見るべきで、総額はライセンス費の3〜6倍になる傾向があります。日本市場で紹介されている相場としては、クラウド型が初期費用0〜数万円に月額2〜5万円程度、オンプレミス型が初期費用100〜1,000万円に年額10〜40万円程度というレンジがあります(出典: システム幹事)。ただしこれは日本市場の数字で、タイやベトナムの現地法人での実質負担額は、日本語対応の要否、現地サポート体制、マスタ整備と連携をどこまで外注するかで大きく変わります。見積を比較する際は、5層のどこまでが含まれているかを揃えてから並べてください。
WMSと在庫管理システムの違いは何ですか
カバーする範囲が違います。WMS(倉庫管理システム)は倉庫の中の作業を最適化するもので、ロケーション管理、入荷検品、ピッキング指示、先入先出の強制、ハンディターミナルでの作業実績登録が中心です。一般的な在庫管理システムは入出庫と在庫残高の管理に絞られており、倉庫内の作業指示までは持ちません。判断の目安として、「あるはずのものが見つからない」「古いロットが奥に残る」が主症状ならWMS寄り、「数量そのものが合わない」が主症状なら在庫管理システムでも足りることが多いです。ただしどちらも仕掛品と工程実績は扱わないため、そこまで必要なら生産管理システムの検討になります。
Excelから在庫管理システムへ移行するタイミングはいつですか
本記事で挙げた8つのサインのうち3つ以上に当てはまったら検討時期です。とくに「同じファイルの複数バージョンが存在する」「月次締めに3日以上かかる」「発注点が特定の人の記憶になっている」の3つは、移行を急ぐべき兆候です。逆に、品目数が少なく担当者が固定で拠点も1つなら、Excelを続けたほうが総コストは安いこともあります。移行を決めたら、Excelのフォーマットをそのままシステム化しようとしないでください。Excelは1人が全体を見る前提で作られており、複数人が分担する前提のシステムとは構造が違います。
在庫差異はゼロにできますか
現実的にはできません。業界のベンチマークでも在庫精度97%が最低ライン、ベストインクラスが99%以上とされており、スキャナ運用のWMSを導入した現場でも実力値は95〜98%という調査があります(出典: Factory AI)。管理品目が5,000品目なら、99%でも50品目は合わないという計算になります。目指すべきはゼロではなく、差異の原因が説明できる状態です。原因が分かっていれば、金額の大きい品目から優先的に対策できます。原因不明の差異が減ることのほうが、精度の小数点以下を追うより価値があります。
クラウド型とオンプレミス型はどちらを選ぶべきですか
判断軸は3つです。第1に、工場のネットワーク環境。回線が不安定な工業団地では、オフライン時に現場作業が止まらない仕組みが必要で、これはクラウド型でも端末側にキャッシュを持つ設計なら対応できます。第2に、既存システムとの連携本数。生産設備や会計システムと多数の連携が必要なら、オンプレミス型のほうが素直に組めることがあります。第3に、社内のIT運用体制。現地にサーバー管理ができる人材がいないなら、クラウド型のほうが安全です。費用面では、日本市場のレンジで5年総額を計算すると、クラウド型は120〜300万円に初期費用、オンプレミス型は150〜1,200万円となり、上限側で4倍の開きがあります。
タイのdepa 200%損金算入は日系工場でも使えますか
多くの場合、使えません。勅令802号(仏暦2569年)は2026年2月6日に官報公布され、depaのThailand Digital Catalog登録済みのソフトウェア・ハードウェア・スマートデバイス・デジタルサービスに200%損金算入を認めていますが、対象は払込資本金500万バーツ以下かつ売上3,000万バーツ以下のSMEです(出典: Mahanakorn Partners)。日系製造業の現地法人はこの要件を上回るケースが大半です。上限も30万バーツで、在庫管理システムの導入規模から見れば小さい枠です。汎用のノートPCやデスクトップPCは対象外で、支出期限は2027年12月31日です。適用可能性がありそうな場合は税務アドバイザーへの個別確認をおすすめしますが、この制度を投資判断の前提に置くことはおすすめしません。BOI恩典の「Smart and Sustainable Industry」措置(2026年上期で132件・171.58億バーツ)のほうが、規模の面では現実的な検討先です。
棚卸の回数は減らせますか
回数を減らすというより、性質を変えるのが実務的です。年次または四半期の全数棚卸は、会計上の要請から回数を減らしにくいことが多いですが、そこに日常的なサイクルカウント(循環棚卸)を加えることで、全数棚卸のときに出る差異の量を減らせます。サイクルカウントの目的は数字の修正ではなく差異の原因特定にあるので(出典: Factory AI)、少数の品目を週1回数えるだけでも意味があります。棚卸の直接工数は計算しておく価値があります。作業者20人が2日間なら40人日で、タイの法定最低賃金の日額400バーツで単純計算しても16,000バーツ、年4回で64,000バーツです。実際の賃金、残業割増、間接部門の立会工数、出荷停止の機会損失は含まれていない下限値です。
まとめ
在庫管理システムの比較で必要なのは製品リストではなく、判断のための物差しです。本記事で示した3本の軸を、最後に整理します。
1本目は4タイプの位置づけです。在庫専用クラウド、WMS、生産管理・ERPの在庫モジュール、スクラッチ開発は、カバー範囲とカスタマイズ性の2軸で性格が分かれます。「カバー範囲が広いほど良い」わけではなく、自社の問題の所在とタイプの得意領域を一致させることが本質です。
2本目は費用の5層です。ライセンス、ハードウェア、マスタ整備、既存システム連携、初年度運用の5つに分けると、総額はライセンス費の3〜6倍になる傾向が見えてきます。見積を並べる前に、この5層のどこまでが含まれているかを揃えてください。
3本目は在庫差異の6原因です。単位換算ミス、ロケーション未定義、出庫入力の後回しはシステムで構造的に潰せますが、緊急払出の非公式運用、不良・スクラップの未計上、入荷検収の数量未確認は、ルールと責任分担でしか直りません。この切り分けを最初に文書化しておくことが、導入の成否を分けます。
そして進め方は、システム選定より現物カウントが先です。90日ロードマップの第1フェーズで在庫精度の現状値と差異原因の内訳を測れば、必要な機能は自然に絞られます。この30日を飛ばした案件が、後で最も苦労します。
タイの製造業生産指数は2026年6月に前年同月比マイナス3.10%、第2四半期の平均稼働率は57.47%(出典: Xinhua)。一方でベトナムの製造業PMIは6月に51.8で50超を維持し、上期の製造業付加価値はプラス9.97%(出典: VietnamPlus)。同じASEAN域内でも局面が異なり、拠点ごとに優先すべき機能が違います。減産局面のタイ拠点では滞留在庫の可視化が、増産局面のベトナム拠点では欠品防止が先に来ることが多い、という違いを踏まえて計画を立ててください。
在庫管理システムは、正しく使えば在庫差異の半分を構造的に減らせる道具です。しかし残りの半分は、現場のルールと責任分担の話です。この2つを混同しない誠実な計画が、結果として最も早く成果につながります。
自社の在庫精度をどう測るか、差異の原因をどう分類するか、5層の費用を自社の条件でどう見積もるか。こうした整理の段階でお困りのことがあれば、お問い合わせフォームからお気軽にご相談ください。当社はバンコクを拠点に、タイ・ASEANの日系製造業向けに工場ITと生産管理システムの導入を手がけており、PEGASUS生産管理システムの在庫機能も提供していますが、まずは自社に合うタイプが4つのうちどれなのかを一緒に整理するところから始めるのが有効だと考えています。製品の押し売りではなく、判断材料の整理としてご利用いただければと思います。