タイ WMS導入ガイド2026：既存倉庫のRFP・90日PoC・受入設計

タイ WMSを既存工場・既存倉庫へ導入する成否は、機能一覧の多さでは決まりません。止められない入出庫を維持しながら、品目・ロケーション・ロット・梱包単位をそろえ、ERPとの責任境界を決め、タイ語・英語・日本語の現場運用を一つの証跡へ落とせるかで決まります。本稿は、タイの工場長、物流責任者、SCM責任者、IT責任者が、RFP作成から90日PoC、受入、段階展開までを判断できる実務ガイドです。一般的な製品比較や価格相場ではなく、brownfield（稼働中の既存拠点）で事故を起こさない導入設計に焦点を絞ります。

先に結論：タイ 倉庫管理システムは「機能」ではなく7つの境界で選ぶ

WMS選定では、最初に次の7つの境界を合意してください。

1. 在庫の正本：数量・ロット・シリアル・在庫ステータスをWMSとERPのどちらが確定するか。
2. マスタの正本：品目、単位換算、荷姿、ロケーション、取引先、品質区分を誰が変更するか。
3. 業務イベント：入荷、検品、格納、補充、払出、ピッキング、梱包、出荷、返品の完了条件は何か。
4. 通信断の境界：無線が切れたとき、端末で何を継続でき、何を止め、復旧後にどう照合するか。
5. 権限と言語：作業者、班長、在庫管理者、IT、監査者が、どの言語で何を閲覧・承認できるか。
6. 証跡の境界：誰が、いつ、どの端末で、何を読み、何を訂正し、誰が承認したかをどこまで残すか。
7. 切替の境界：倉庫全体を一度に変えず、どのゾーン、品目群、取引で開始し、どの条件で拡大・停止するか。

MicrosoftのWarehouse management公式概要では、WMSは販売、購買、移送、生産、品質、返品などのソース文書と連携し、入出庫ワークフロー、ロット・シリアル、棚卸、ラベル、モバイル作業などを扱います。つまりWMSは単独の在庫画面ではなく、複数業務の境界にある実行システムです。RFPを「機能に丸を付ける表」で終わらせず、各境界の入力、処理、例外、出力、責任者、証跡を要求事項に変えることが重要です。

既存倉庫へのWMS 導入 タイで最初に見る現場

新設倉庫ならロケーション、ラベル、無線、動線をシステムに合わせて設計できます。一方、既存倉庫には、ERP上の棚と現物棚の不一致、手書きラベル、複数単位、作業者の暗黙ルール、設備死角、顧客別の例外がすでに存在します。先にパッケージを決めると、これらを「設定で吸収できるはず」と誤認し、総合テストで初めて破綻します。

RFP前の現場観察は、会議室のフロー図だけで済ませません。代表的な入荷トラックの到着から、荷下ろし、仮置き、検品、ラベル発行、格納までを追います。出庫は、受注・生産払出の指示から、引当、補充、ピッキング、照合、梱包、出荷確定までを追います。通常便だけでなく、緊急払出、数量差、破損、保留、返品、再梱包、ラベル再発行、端数、混載パレット、無線不良も観察します。

観察結果は「現行の問題」だけでなく、次の四つに分類します。

改善対象を数値化するときも、万能の目標値を置かないでください。誤出荷件数、在庫差異、探索時間、再スキャン、保留滞留、インターフェース再処理、端末停止時間などを、自社の現状測定から基準化します。公開事例の改善率をそのまま受入値にすると、測定条件の違いで判断を誤ります。

タイ WMSの適用範囲を業務イベントで切る

WMSの範囲は画面名ではなく、在庫が変化するイベントで定義します。最低限、次のイベントごとに開始条件、完了条件、在庫効果、ERP通知、取消方法を決めます。

• 入荷予定の受信、車両到着、荷下ろし、数量・外観・品質検品
• ライセンスプレートまたは容器IDの発番、ラベル印刷、再発行
• 仮置き、格納、混載可否、容量・重量・危険物などの制約
• 在庫移動、ステータス変更、ロット・シリアル変更、再梱包
• 補充、部材払出、ラインサイド供給、余剰戻し
• 引当、ウェーブ、ピッキング、ショート、代替、梱包、積込、出荷確定
• 循環棚卸、一斉棚卸、差異調査、在庫調整、承認
• 返品、隔離、廃棄、再利用、サプライヤー返却

各イベントには一意な業務キーと状態遷移を持たせます。「同じメッセージが二回来ても在庫を二重加算しない」「ERPの応答が遅くても未確定を確定表示しない」「取消が元イベントと結び付く」ことを受入条件にします。再送、順序逆転、タイムアウト、部分失敗は例外ではなく、必ず起きる前提で設計します。

GS1 EPCIS 2.0.1は、識別子を読み取った事実に、いつ、どこで、何が、どの業務文脈で起きたかという可視化イベントを与える標準です。すべてのWMSでEPCISを採用する必要はありませんが、「バーコードを読んだ」ことと「入荷検品が完了した」ことを区別し、業務イベントとして意味を残す考え方は、トレーサビリティや企業間連携のRFPに有効です。

マスタ設計：WMS ERP連携 タイの成否を決める契約

WMSとERPの連携で最も危険なのは、APIがつながらないことより、同じコードが違う意味を持つことです。インターフェース仕様の前に「マスタ契約」を作ります。

品目と単位換算

購買単位が箱、在庫単位が個、生産払出がkg、出荷がパレットという品目では、換算の丸めと有効日が必要です。1箱の入数変更を過去在庫へ適用してはいけません。WMSが受け取る項目、ERPへ返す項目、変更承認者、発効時刻、旧ラベルの扱いを決めます。可変重量、二重単位、端数、キット、代替品もテストデータに含めます。

ロケーションと物流単位

ERPの保管場所、WMSの倉庫・ゾーン・棚・ビン、現物の表示が一致するとは限りません。ロケーションは表示名だけでなく、格納可否、混載、容量、温度、危険区分、FIFO/FEFO、補充元・先、作業順序を持ちます。パレットやケースを一つの物流単位として扱うなら、親子関係、分割、統合、再梱包の履歴も必要です。

ロット、シリアル、在庫ステータス

ロットはサプライヤーロット、製造ロット、社内受入ロットを区別します。有効期限、製造日、品質状態、保留理由、原産地、所有者など、引当可否を左右する属性を洗い出します。WMSが勝手に状態を変えるのか、QMS/ERP承認を待つのかを明確にします。

変更のガバナンス

本番稼働後の障害は、初期移行より日々の変更から生まれます。新規品目、包装変更、新ロケーション、顧客ラベル改定、取引先追加を、申請、検証、承認、配信、監視まで一つの標準にします。RFPには、差分配信、失敗時の再実行、監査ログ、旧値参照、複数環境への移送を含めます。

MicrosoftのWMS-only mode公式資料では、外部ERPとWMSを分離して利用する構成が示され、released products、item model groups、countries/regionsなどのマスタ・参照データ同期と、業務イベントによるデータ交換が必要とされています。特定製品の構成をそのまま採用するのではなく、「外部ERPとWMSの責任を軽量文書とイベントで分けられる」という設計例として利用できます。

ERPインターフェースを6列の契約書にする

「リアルタイム連携」は要件ではありません。各メッセージを次の6列で定義します。

入荷予定、出荷指示、移送、製造払出、実績、在庫調整、マスタ更新を同じSLAにしないことも重要です。作業者が待つ同期応答と、後で確定できる非同期通知を分けます。業務キー、相関ID、作成時刻、発効時刻、送信時刻、処理時刻を持たせると、タイムゾーンや再送の原因を追えます。

日次照合は「件数が同じ」だけでは不十分です。品目、ロット、ロケーションまたはERP保管場所、在庫ステータス、数量、単位、所有者、基準時刻で比較します。差異は自動調整せず、発生源、暫定処置、恒久対策、承認を残します。

WMS タイ語対応は翻訳ではなく作業設計

タイ語対応というチェック項目だけでは、現場で使えるか判断できません。画面翻訳、ラベル、入力、教育、サポート、監査を分けて要求します。

画面と用語

タイ語、英語、日本語で、同じ業務語が同じ状態を指す用語集を作ります。短いボタン、長いエラー文、品目説明、理由コード、ヘルプを実機で確認します。英数字コードだけに頼ると教育は速くても、類似コードの誤認が増える場合があります。逆に長文表示は小型端末で作業を遅くします。手袋、片手、騒音、暗所を前提に、1画面1判断へ近づけます。

ラベルとフォント

ラベルは、バーコードの読み取りだけでなく、人が読めるタイ語・英語、ロット、数量、単位、日付、状態を確認します。プリンタ機種、解像度、用紙、リボン、温湿度、貼付面、読取距離まで含めて現場テストします。ラベル再発行は元ラベルとの関係と理由を残し、二重使用を防ぎます。

教育と権限

作業者向けは操作手順、班長向けは例外処理、管理者向けはマスタと波動、IT向けは監視・再処理、監査向けは証跡抽出を分けます。翻訳済みマニュアルを配るだけでなく、実機のシナリオ試験で習熟を確認します。共有IDは避け、端末認証と作業者識別を分離する場合も、誰が作業したかが追える構成にします。

現地サポート

夜勤や休日に止まったとき、タイ語で一次切り分けできる時間帯、連絡手段、応答、エスカレーション、代替運用を確認します。サポートのSLAは「返信まで」か「回避策提示まで」か「復旧まで」かを分けます。

スキャンとオフライン：通信断を成功系として設計する

倉庫では金属棚、冷蔵区画、屋外ヤード、ドック、機械室周辺で電波品質が変わります。アクセスポイント図だけでは足りません。端末を持って実際のルートを歩き、ローミング、再接続、ピーク同時接続、バッテリー交換、端末落下、読み取り角度を検証します。

「オフライン対応」も一語では定義できません。ローカルに作業指示を保持できるのか、読み取りだけ蓄積するのか、在庫確定までできるのか、同じ在庫を別端末が処理しないよう予約できるのかを区別します。完全オフラインで在庫更新を許すほど競合解決は難しくなります。高リスク処理は停止し、低リスク処理だけ継続する設計も選択肢です。

復旧試験では、次を確認します。

• 読み取り直前、読み取り直後、確定直前、確定直後に通信を切る。
• アプリ強制終了、端末再起動、バッテリー切れ、セッション期限切れを起こす。
• 同じラベルを別端末で処理し、競合表示と解除権限を見る。
• 未送信件数、送信順、重複排除、失敗理由、再処理結果を監視画面で確認する。
• 復旧後にWMS、ERP、現物を照合し、孤立したトランザクションがないことを示す。

MicrosoftのWarehouse Management mobile app公式資料は、端末自体の認証と作業者アカウントを分け、複数端末への接続設定をMDM、QRコード、ファイルなどで配布する構成を説明しています。また2026年のV4移行・サポート資料は、モバイルOS、配布経路、アプリ版、バックエンド互換性を運用責任として扱う必要を示しています。製品の機能有無を一般化せず、RFPでは端末ライフサイクルと更新検証を明記してください。

PDPA・セキュリティを後付けしない

倉庫データの中心は品目と在庫でも、作業者ID、氏名、端末、位置、作業時刻、画像、サイン、車両情報などが個人に結び付けば、個人データの検討が必要です。タイのPersonal Data Protection Act（PDPA）の公式法令を基準に、収集目的、必要性、アクセス、保持、第三者提供、委託、越境、削除・匿名化、事故対応を法務・DPOと確認します。本稿は法的助言ではなく、RFPで確認漏れを防ぐための実装観点です。

RFPには次を要求します。

• データ項目ごとの目的、正本、保持期間、閲覧者、出力先
• 職務分離と最小権限、入退社・異動・派遣終了時の停止
• 端末暗号化、画面ロック、紛失時の失効、MDM、証明書・秘密情報の保護
• 通信と保管の暗号化、鍵管理、バックアップ、復元試験
• 管理者操作、マスタ変更、在庫訂正、データ出力、認証失敗の監査ログ
• 脆弱性対応、依存ソフト、保守期限、通知、パッチ検証、緊急変更
• ベンダー・クラウド・再委託先の範囲、データ所在、契約終了時の返却・削除
• インシデントの検知、封じ込め、証拠保全、連絡、業務継続、事後レビュー

NIST SP 800-161 Rev.1 Update 1は、取得するICT製品・サービスのサプライチェーンリスクを、組織のリスク管理へ統合する指針です。NISTの2026年版SP 800-18 Rev.2は、セキュリティ、プライバシー、サプライチェーンリスクの計画を相互に関連するシステム計画として扱います。タイ法への適合をNISTが保証するわけではありませんが、調達時にベンダー責任、境界、管理策、証跡、残存リスクを文書化する枠組みとして使えます。

RFPを「回答可能・採点可能・検証可能」にする

良いRFPは、製品説明を集める文書ではなく、受入試験の原型です。各要件にIDを付け、必須／推奨、回答形式、証拠、採点、PoC対象、契約条項への反映先を持たせます。

「対応可能」だけの回答は採点できません。標準機能か、設定か、個別開発か、外部製品か、将来計画かを選択させ、前提、制限、費用、納期、保守責任、デモ証拠を記入させます。画面キャプチャではなく、指定したサンプルデータと例外を使うデモ台本を渡します。

既存の製品タイプや適用範囲を整理したい場合はWMS比較2026を、投資項目を分解したい場合はタイ工場のWMS費用・3年TCOを先に確認してください。本稿のRFPは、その後に「選んだ構成を既存拠点へどう実装し、何を証拠に受け入れるか」を具体化する位置付けです。

90日PoC：デモではなく切替判断の証拠を作る

90日PoCは、全機能を小さく作る期間ではありません。高リスク仮説を、本番に近いデータ、端末、無線、作業者、ERP接続で潰す期間です。期間は自社の稼働日・繁閑に合わせて調整し、90日という数字自体を成功条件にしません。

Day 0–15：基準線とシナリオ固定

対象を一つの倉庫またはゾーン、代表品目群、代表シフトに絞ります。現行KPI、現物と帳簿の差、例外件数、処理時間を測ります。To-Beフロー、マスタ辞書、インターフェース一覧、権限、テストシナリオ、合否判定者を確定します。PoC用のきれいなマスタだけを使わず、本番の欠損・重複・旧コードを含むコピーを評価します。

Day 16–30：マスタと接続契約

品目、単位、ロット、ロケーション、取引先、作業者を同期し、拒否・再送・訂正を確認します。ERPとの入荷予定、出荷指示、在庫実績をつなぎ、相関IDと照合表を作ります。アクセス権、ログ、端末登録、ラベル版も固定します。

Day 31–60：正常系と現場適合

入荷から格納、補充、ピッキング、梱包、出荷、棚卸を実機で流します。タイ人作業者がタイ語画面とラベルを使い、手袋や実騒音下で操作します。平均値だけでなく、ピーク、端数、混載、ロット、保留を含めます。操作の迷い、戻る操作、再スキャン、監督者呼出しも記録します。

Day 61–75：障害と不正操作

無線断、ERP停止、遅延、重複メッセージ、逆順、プリンタ停止、端末紛失、誤マスタ、権限外操作、ラベル重複を注入します。止めるべき処理が止まり、続けるべき処理が安全に続き、復旧後に照合できることを確認します。バックアップからの復元だけでなく、倉庫業務をどの順に再開するかを試します。

Day 76–90：受入と展開判定

業務、データ、性能、セキュリティ、運用、教育、切替の証拠をまとめます。未解決事項には重大度、暫定策、期限、責任者を付けます。判定は「展開」「条件付き展開」「再PoC」「中止」の四つとし、営業資料ではなく受入委員会が署名します。

受入試験は数量より証拠の連鎖を確認する

「100件処理できた」だけでは受入になりません。指示が正しく届き、作業者が正しい現物を読み、WMSの状態が変わり、ERPへ結果が返り、会計・生産・品質の後続処理へつながり、全履歴を追えることが必要です。

受入証拠パックには、少なくとも次を含めます。

1. 要件IDとテストIDのトレーサビリティ表。
2. 使用したマスタ版、設定版、アプリ版、端末、ラベル版。
3. 入力データ、期待結果、実績、画面・ログ、実行者、日時。
4. WMS・ERP・現物の前後在庫と日次照合結果。
5. 障害注入の時刻、影響、検知、暫定処置、復旧、残課題。
6. 権限外操作が拒否され、管理者操作が記録された証拠。
7. タイ語・英語・日本語の教育記録と役割別の習熟結果。
8. 未解決不具合、回避策、受入例外、契約上の期限。

合否値は自社の基準線とリスク許容度から決めます。たとえば「重大な在庫二重計上は0件」のような絶対条件と、作業時間・誤読・差異など改善を測る条件を分けます。母数、測定期間、除外、再試験条件を併記します。

本番切替：big bangを避ける段階展開

稼働中倉庫では、最初から全品目・全取引・全シフトを切り替える必要はありません。低い相互依存で始め、証拠を満たすたびに範囲を広げます。

一例として、①一つのゾーンと日勤、②同ゾーンの全シフト、③隣接ゾーン、④生産払出、⑤顧客別出荷、⑥拠点全体、⑦他拠点の順に進めます。ただし、同じ在庫を旧新システムで同時更新する並行運用は差異を増やすため、在庫単位ごとの正本は一つに固定します。並行させるのは照合や参照であり、二重入力ではありません。

切替計画には、データ凍結、最終入出庫、実地棚卸または差異確定、移行、初期在庫照合、端末配布、ラベル切替、ERPキュー、旧帳票、応援要員、意思決定時刻を含めます。ロールバックは「旧システムを起動する」だけではなく、切替後に発生した取引をどう戻し、どの時点の在庫を正とするかまで定めます。

稼働後30・60・90日のガバナンス

本番稼働は終了ではなく、統制の開始です。日次ではインターフェース失敗、未完了作業、負在庫、保留、ラベル再発行、手動訂正、端末・プリンタ障害を確認します。週次では在庫差異、作業生産性、例外上位、マスタ変更、教育課題を確認します。月次ではSLA、脆弱性・パッチ、ライセンス、容量、権限レビュー、改善バックログを扱います。

KPIを作業者の監視だけに使うと、スキャン省略や理由コード乱用を招きます。工程のボトルネック、指示品質、レイアウト、マスタ品質、システム待ちを改善するために使い、個人評価へ使う場合は目的と扱いを明確にします。PDPAの観点も含め、必要以上に詳細な行動履歴を無期限で保持しない設計が必要です。

変更管理では、設定、インターフェース、端末アプリ、OS、プリンタ、ラベル、無線、ERPを一つの依存関係として扱います。Microsoftの2026年モバイルアプリ資料が示すように、アプリ版とバックエンド互換性、配布方法、サポート期限は変化します。検証環境で代表業務と障害復旧を再試験し、展開順、停止条件、戻し方を決めてから本番へ配布します。

よくある失敗と予防策

既存業務を全部そのまま再現する

暗黙の迂回や二重台帳まで個別開発すると、費用と保守が増え、標準化の効果が消えます。「統制として必要」「移行中だけ必要」「廃止する」を分け、例外には期限と責任者を付けます。

ERPとWMSの在庫責任を曖昧にする

両方で調整できる状態は、差異原因を隠します。在庫効果を起こすイベント、調整権限、連携遅延中の表示、照合時刻を決めます。

きれいなPoCデータだけを使う

本番で問題になるのは旧コード、空欄、重複、単位変更、未完了取引です。匿名化・保護した本番相当データを使い、誤データを安全に拒否できるかを試します。

タイ語対応を画面翻訳で合格にする

実機、ラベル、理由コード、教育、夜勤サポートをタイ人作業者が評価しない限り、現場適合は分かりません。日本語話者が代理で合否を決めないことが重要です。

オフラインを「何でも継続」にする

同じ在庫への競合が増えます。通信断時の許可・禁止、端末内キュー、予約、復旧順、照合を処理別に決めます。

稼働日だけを成功条件にする

カレンダー達成は品質を示しません。重大欠陥、証跡欠落、照合差異、教育未達があれば、範囲縮小や延期を選べるガバナンスが必要です。

タイ WMSの導入チェックリスト

RFP発行前

• [ ] 現場観察に通常・例外・障害を含めた
• [ ] WMSとERPの在庫・マスタ責任を決めた
• [ ] 品目、単位、荷姿、ロケーション、ロットの辞書を作った
• [ ] タイ語・英語・日本語の用語集と役割別教育を定義した
• [ ] 無線調査と通信断時の許可・禁止処理を決めた
• [ ] 個人データ、権限、ログ、保持、委託先を整理した
• [ ] 各要件に証拠とPoCシナリオを付けた

90日PoC

• [ ] 本番相当の汚れたマスタと未完了取引を含めた
• [ ] 重複、逆順、遅延、停止、復旧を試した
• [ ] タイ人作業者が実端末・実ラベルで評価した
• [ ] WMS・ERP・現物を同じ基準時刻で照合した
• [ ] 権限外操作、端末紛失、ログ抽出を試した
• [ ] 合否値の母数、期間、除外、再試験条件を定義した

本番展開

• [ ] ゾーン・品目・取引ごとの正本を一つに固定した
• [ ] cutover、停止、縮退、rollbackの責任者と時刻を決めた
• [ ] 旧新の二重更新を避け、照合手順を用意した
• [ ] 30・60・90日のレビューと改善責任者を設定した
• [ ] アプリ、OS、端末、無線、ERPの変更管理を統合した

FAQ：タイ 倉庫管理システム導入の疑問

タイ WMSと在庫管理システムの違いは何ですか？

一般に在庫管理システムは数量や入出庫記録を中心に扱い、WMSはロケーション、作業指示、補充、ピッキング、梱包、端末、ラベル、波動など倉庫実行をより細かく制御します。ただし製品名だけで範囲は決まりません。自社の業務イベントと責任境界で比較してください。

WMS タイ語対応では何を確認すべきですか？

画面翻訳に加え、端末サイズでの表示、タイ語入力、ラベルフォント、理由コード、教育教材、管理者画面、夜勤サポートを確認します。タイ人作業者が実物・実環境でシナリオを完遂できることを証拠にします。

WMS ERP連携 タイでリアルタイムは必須ですか？

すべてを同期リアルタイムにする必要はありません。作業者が即時判断する処理と、非同期で照合できる処理を分けます。重要なのは遅延、重複、逆順、取消、再送でも在庫が壊れず、状態を追跡できることです。

WMS 導入 タイのPoCは90日で十分ですか？

90日は実務上の枠組みであり、十分性は対象範囲、シフト、繁閑、連携数で変わります。正常系のデモだけなら長すぎても価値はありません。高リスクなマスタ、ERP接続、多言語、通信断、復旧、照合を含み、判断に必要な証拠が揃う期間を設定してください。

既存倉庫はいつ止めて切り替えますか？

倉庫全体を一度に止める前提ではなく、ゾーンや取引で段階化します。各範囲で在庫正本を一つに固定し、データ凍結、最終取引、移行、初期照合、再開判定を時刻付きで計画します。戻す場合も切替後取引の扱いまで決めます。

PDPA対応はWMSベンダーに任せればよいですか？

いいえ。ベンダーは技術・運用情報を提供できますが、データ利用目的、法的根拠、役割、保持、委託、越境などの判断は利用企業側の責任者、法務、DPOと行う必要があります。契約と設定が一致しているかも受入で確認します。

まとめ：WMSを倉庫の共通言語にする

タイ WMSの導入で調達すべきものは、豊富な画面ではなく、現物、作業、WMS、ERP、管理者を結ぶ検証可能な運用です。brownfieldでは、現行の例外を観察し、業務イベントを定義し、マスタと責任を契約し、多言語・端末・通信断・セキュリティを現場で試すことが欠かせません。90日PoCでは、正常系の見栄えより、障害後に在庫と証跡が戻るかを確認します。受入証拠がそろった範囲だけ段階的に広げれば、稼働日を守るために品質を妥協する必要はありません。

TOMAS TECHでは、タイの既存工場・倉庫を対象に、現場観察、RFP整理、ERPインターフェース設計、多言語PoC、受入証跡づくりを支援しています。製品が未決定の構想段階や、既存WMSを残して連携だけ見直す段階でも、お問い合わせからご相談いただけます。

参考情報

• Microsoft Learn, “Warehouse management overview”: https://learn.microsoft.com/en-us/dynamics365/supply-chain/warehousing/warehouse-management-overview
• Microsoft Learn, “Warehouse management only mode overview”: https://learn.microsoft.com/en-us/dynamics365/supply-chain/warehousing/wms-only-mode-overview
• Microsoft Learn, “Enable and configure Warehouse management only mode”: https://learn.microsoft.com/en-us/dynamics365/supply-chain/warehousing/wms-only-mode-setup
• Microsoft Learn, “Install the Warehouse Management mobile app”: https://learn.microsoft.com/en-us/dynamics365/supply-chain/warehousing/install-configure-warehouse-management-app
• Microsoft Learn, “Warehouse Management mobile app release schedule”: https://learn.microsoft.com/en-us/dynamics365/supply-chain/warehousing/warehouse-app-control-updates
• GS1, “EPCIS Standard 2.0.1”: https://ref.gs1.org/standards/epcis/2.0.1/
• Royal Thai Government Gazette, “Personal Data Protection Act B.E. 2562”: https://ratchakitcha.soc.go.th/documents/17082307.pdf
• NIST, “SP 800-161 Rev. 1 Update 1”: https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final
• NIST, “SP 800-18 Rev. 2”: https://csrc.nist.gov/pubs/sp/800/18/r2/final

※本稿は2026年9月7日時点の公開情報に基づく一般的な実務整理であり、法的助言、特定製品の保証、投資成果の保証ではありません。法令・契約・セキュリティ要件は、貴社の責任者および専門家と確認してください。