AGV WMS連携の導入設計｜タイ工場の指示・在庫・検収

AGV WMS連携の導入で、最初に決めるべきことは車両の台数や通信方式ではありません。「どの荷物を、どこからどこへ運ぶか」を誰が決め、「搬送が終わった」と「在庫が移った」をどの証拠で確定するかです。ここを曖昧にすると、AGVは目的地に到着したのにWMSの在庫は旧ロケーションのまま、あるいは搬送未完了なのに出庫可能になった、という不一致が起きます。

この記事はタイの製造工場・倉庫が、既存WMSにAGVまたはAMRを接続するときの実務設計を扱います。車両そのものの選定、VDA 5050を使うフリート制御、ドッキング位置決めとは論点を分けます。倉庫内のロケーション管理が未整理なら、先に棚番と移動ルールを決めてください。以下では作業指示の受け渡し、物理的な受渡確認、在庫イベント、異常時の復旧、RFPとFAT/SATを、発注に使える粒度で整理します。

AGV WMS連携の範囲を一枚の図で定義する

構成は通常、上位の業務システム、WMS、搬送を調整するフリート管理または統合制御、AGV/AMR、搬送口の設備に分かれます。ERPが販売・購買・会計上の数量を持ち、MESが生産指示と工程実績を持ち、WMSが棚位置、荷姿、入庫・出庫・移動の倉庫作業を持つ、という分担は有力な出発点です。ただし製品名だけで責任を決めてはいけません。実際にはERPの在庫モジュールが倉庫作業を持つ場合や、MESが工程間の仕掛品位置を持つ場合があります。RFPには既存システムの画面名と責任者を記し、各イベントの正本を決めます。

WMSは「品目、ロット、荷物ID、数量、移動元・先、優先度、要求時刻、作業ID」を業務上の仕事として管理します。フリート側はその仕事を、使用可能な車両、地図上の経路、充電、渋滞、設備インターロックを考慮した搬送ミッションへ変換します。車両は走行と車上機構の状態を報告します。搬送口のコンベヤ、昇降機、シャッター、ドアはそれぞれ別の制御主体になり得ます。各層の間で「依頼した」「受理した」「荷物を受けた」「到着した」「荷物を渡した」「照合して確定した」を区別しなければ、同じ完了という単語が別の意味で使われます。

VDAの公式VDA 5050 Version 3.0.0は、中央のフリート制御と移動ロボットがジョブと状態を交換するインターフェースを記述します。WMSからフリートへの仕事生成、在庫の確定、ERPへの会計転記を標準化する直接APIではありません。 VDA 5050対応車を選んでも、WMS側の作業モデルとフリートへの変換、荷物確認、障害復旧は設計・テストが必要です。複数メーカー車両の相互運用を検討する場合も、仕様の対応バージョンとサポートする機能を双方で明記します。

「搬送依頼」と「倉庫作業」を同一視しない

WMSの棚移動作業には、在庫の業務上の制約が付いています。保留品を動かしてよいか、先入先出やロット制約を守るか、重量と寸法が車両・棚に合うか、同じロケーションが別作業に予約されていないか、といった判断です。AGVの走行成功だけではこれらの制約を満たしたと証明できません。SAP EWMの公式ヘルプでも倉庫タスクと倉庫オーダーの確認が倉庫実行の作業として扱われ、確認日時を記録する仕組みが説明されています。これは一製品の例であり、他社WMSにも同じデータ構造があると仮定するものではありません。

WMSから連携層へ渡すのは、可能なら「車両への経路座標」ではなく、業務上の移動要求です。例えばパレットID P、元棚 A、先の投入ステーション B、期限、優先度、必要な荷扱い条件を渡し、フリートが地図上の地点へ変換します。WMSが地図のノードIDや車両の型番を直接保持すると、地図更新や車両変更のたびに業務側の修正が必要になります。現場の制約で直接接続が適切な場合でも、座標や地点コードの所有者、変更承認、互換性を契約に残します。

初期スコープを一つのルートに絞ることは有効ですが、「一台を動かすだけ」の試験では不十分です。入庫、部材補給、工程間搬送、完成品引取では、在庫を動かすタイミングも例外も異なります。先に一つの業務シナリオを選び、開始条件、終了条件、許容荷姿、手動迂回、異常時の責任までを決めます。工場内物流の改善手順で搬送回数と単位荷量を確かめれば、車両化する仕事と工程改善で消せる仕事を分けやすくなります。

作業ID・荷物ID・ロケーションIDを先に揃える

連携データの核は、各システムの参照番号を一対一に結び付けることです。WMS作業ID、統合層の要求ID、フリートのミッションID、車両ID、パレットまたは容器IDを別項目で保持します。同じ文字列に統一する必要はありませんが、後から一つの業務作業に関する全ログを検索できなければなりません。IDが再利用される場合は発行元と発行日時を組み合わせ、別日の作業を誤って同一と判定しないようにします。

元・先ロケーションも単なる文字列比較では危険です。WMSの棚番、設備の受渡地点、フリート地図のノードは意味が違います。対応表には有効期間、管理者、改訂番号、受入可能な荷姿、方向、停止位置、設備状態の条件を持たせます。受渡地点が一時閉鎖されたとき、WMS作業を保留するのか、代替地点へ再割当てするのかも明示します。変更後に地図だけ更新され、WMSの移動先が旧地点のまま残る事故を避けるため、改訂の検証をSATに入れます。

荷物識別はバーコード、二次元コード、RFIDなど現場に合う方法を選びます。重要なのは技術名ではなく、どこで何を読み、読取失敗や誤読をどう扱うかです。発地のスキャンで「依頼されたパレットが実在する」こと、搬送口のセンサーで「受け渡した」こと、着地のスキャンで「意図した荷物が意図した場所へ着いた」ことを、それぞれ別の証拠として扱います。スキャナーのない自動受渡なら、設備側の荷有り信号や重量確認、搬送口IDとの組合せが必要かを評価します。どれも単独で万能な証明ではありません。

WMSからフリートへ渡すイベントを状態遷移で決める

実装前に状態遷移表を作り、各状態の発火条件、送信者、受信者、再送規則、取消可能範囲を定義します。単純な成功経路でも「作業作成→受理→車両割当→発地到着→荷物受領→走行→着地到着→荷物引渡→着地確認→WMS作業確定」と段階があります。フリートの「到着」は、受渡設備が荷物を受けたことでも、WMSの在庫が更新されたことでもありません。受入テストではこの三つを別のログで検証します。

「在庫移動は発地で出庫し、着地で入庫する」のか、「途中状態を設け、着地で一括確定する」のかはWMSの機能と現場の管理方針によります。どちらも中断中の荷物がどこに見えるかを決める必要があります。走行中を一時ロケーションとして扱うなら、そのロケーションの在庫引当可否、棚卸し対象、品質保留の扱いまで仕様に入れます。車両の電池切れで立ち往生した荷物が帳簿上だけ着地済みになるような設計は避けます。

在庫イベントの照合は「少なくとも一回届く」を前提にする

ネットワーク障害や再送により、同じイベントが二度届くことがあります。接続仕様には一意のイベントID、元の作業ID、イベント時刻と受信時刻、発行元、スキーマ版、荷物ID、元・先、数量または荷姿、結果を定義します。受信側は既処理イベントを識別し、二回目を在庫の二重移動にしない冪等処理を持つべきです。これは「通信が完全に一回だけ届く」という保証を前提にせず、再送できる仕組みにするためです。

ただしイベントIDが違えばすべて新規と判断するだけでは足りません。同じパレットの同じ作業に対し、二つの車両から着地完了が来たら、衝突として保留する必要があります。逆に通信断後に到着イベントだけ遅れて届いた場合、すでに手動で処理された作業へ自動適用してはいけません。受信の前に作業の現状態、荷物の所在、イベントの順序、取消履歴を確認します。順序が入れ替わる可能性を考慮し、「前提状態に合わないイベント」を待機・調査・却下する規則を決めます。

GS1 EPCIS/CBVの公式ガイドは、可視化すべき業務ステップと、物理的な荷物に識別子を付けて実際に読み取れるかを設計時に考えるよう示しています。EPCISはイベント記録の共通語彙として参照できますが、導入しただけでWMSとAGVが自動接続されるものではありません。 当該現場で必要な粒度を決め、誰がどの読取点で証拠を生成するかを定義するために使います。タイ工場で荷物ラベルが作業途中で貼り替わるなら、その変換イベントも追跡できるようにします。

発注前のレビューでは、一つの実際のパレットを選び、棚での引当から搬送口での受領までを時系列に書き出すと境界が見えます。WMSが出庫予約を作った時点、フリートが依頼を受理した時点、車両が発地に着いた時点、荷物を積んだ時点、目的地へ到着した時点、受側が荷札を読んだ時点を別々の出来事として扱います。どの出来事で予約を解き、どの出来事で所在を変え、どの出来事で作業を完了にするかを一つずつ決めてください。到着という車両の状態をそのまま受領という倉庫の状態に写す設計では、搬送口に荷物が置けなかった場合や誤った荷物を読んだ場合を区別できません。フリート側の完了通知は照合を開始する根拠にはなっても、WMSの在庫確定を無条件に許可する根拠にはしない方が検収しやすくなります。

同じ作業について複数の通知を受ける前提で、照合台帳に「作業ID、荷物ID、期待した発地と着地、最後に確認した現物、最後に受理したイベント、保留理由、手動処理者」を並べます。監視画面の色だけで判断せず、保留中の荷物を現場で見つける手順と、WMS上の予約を解除できる権限を対応させます。ネットワーク復旧後の一括再送では、単純に受信時刻の新しい通知を優先すると古い作業の完了を上書きするおそれがあります。元のイベント時刻だけにも依存せず、現在の業務状態とイベントID、取消や手動介入の履歴を合わせて判断します。処理済みとして無視した通知と、人の判断待ちにした通知はログで区別し、後日の原因調査で再現できるようにします。

例えば荷物が発地で積載できず手動でラインへ運ばれたとき、WMS上の手動完了と、遅れて来る車両側の「積載・到着」通知の競合をFATの試験ケースにします。試験では同じ荷物に対する在庫移動を一度だけ認め、遅延通知は消去せず保留記録に残し、現物確認の担当者と復旧操作を追えることを合格条件にします。逆に車両が目的地に到着しても受側のスキャンが無いときは、搬送完了と在庫確定を別状態で保留します。こうした例をRFPに添えると、各ベンダーがどこまでを標準機能、設定、個別開発、現場運用で担うのかを同じ条件で比較できます。合否判定に使う画面とログの出力例も契約前に確認しておくと、導入後に「どちらのシステムの責任か」を調べる時間を減らせます。

例外復旧は自動化の後付け項目にしない

正常走行はデモで確認しやすい一方、運用負荷を決めるのは例外です。発地に荷物がない、バーコードが読めない、違う荷物が載った、受渡設備が満杯、ドアが開かない、人やフォークリフトで通路が塞がる、通信が途絶する、車両が停止する、WMS側で作業が取り消される。これらを「エラー表示」として一括りにせず、荷物の物理位置、WMSの予約状態、ミッション状態、再開条件をケースごとに表にします。

復旧操作は「再送」「再割当」「手動搬送」「返品・元棚へ戻す」「作業取消」に分けます。いずれも、まず荷物を現場で確認し、作業IDと荷物IDを照合してから状態を進めます。手動搬送した後で遅れて到着した自動イベントを適用すると、帳簿が二重に動きます。手動処理に切り替えるときは元ミッションを停止・無効化し、遅延イベントの扱いを記録します。再送ボタンは安全な操作に見えますが、前の要求が実行中か不明なまま押せば二重指示になります。

復旧権限も役割別にします。現場作業者は荷物確認と安全な停止を行い、倉庫責任者は在庫の保留・再割当を承認し、設備保全は車両・センサー・設備の故障を診断し、IT担当は連携ログと再送を管理します。夜間は誰が何分以内に呼び出されるか、手動迂回で生産を続ける条件は何かを決めてください。数値の目標は現場の搬送頻度と停止損失に合わせて設定します。根拠のない「99.9%稼働」などの共通値を仕様書へ転記しても、停止時の荷物所在は分かりません。

設備・ドア・ドッキングと業務APIの境界

WMS連携が完成しても、物理的な荷受けが成立しなければ業務は完了しません。コンベヤとの受渡では両側の荷有り、受入可、動作許可、完了、故障の信号を確認します。自動ドアでは車両の接近要求と開扉許可、閉鎖条件、避難経路を設備側の安全設計と整合させます。AGVの停止位置、荷台高さ、パレットのはみ出し、床状態も現場で測ります。詳細なドッキング位置決め方式は別記事で扱っています。

ドアやコンベヤの制御をWMSのAPIレスポンスだけで判断しないことが大切です。WMSは荷物の業務上の行先を知っていても、設備の安全状態を直接保証しません。現場のPLCまたは設備制御がインターロックを扱い、フリートが利用可能状態を受け取り、WMSは結果の業務イベントを受ける、という分担が基本になります。OPC FoundationのOPC UA公式仕様は装置からMES・ERPまでの情報交換の共通インフラを説明していますが、採用するだけでドアの安全機能や在庫確定条件が定義されるわけではありません。通信プロトコル、信号の意味、フェイル時の安全状態を個別に検証します。

人と車両が混在する通路では、通路幅、曲がり角の見通し、床の段差、手動車両との交差、充電場所、非常停止、復帰手順を現場で評価します。安全装置の選定と法規適合は、車両・設備・工場全体のリスクアセスメントに基づく専門設計が必要です。この記事は通信と業務整合を主題とし、特定の車両構成の安全適合を保証するものではありません。FATでソフトウェアの正常動作を見ても、混在通路でのSATを省略できません。

タイ工場で先に収集する現状データ

RFPの前に二週間程度の実運用を観察し、少なくとも対象ルートの出発地・到着地、時間帯ごとの搬送件数、荷物寸法・重量の分布、空容器の戻り、ピーク時の待ち行列、通路の干渉、手動運搬の例外を記録します。「二週間」は計画例であり、変動の大きい工場では月末・繁忙期・段取り替えを含めた観測が必要です。平均件数だけで設計すると、シフト交替直後や出荷締め時刻のピークを吸収できないことがあります。

現行WMSから、作業種別、作成・確認時刻、取消率、再割当、在庫差異、ロケーション使用率を抽出します。紙や口頭で処理している動きは、WMSログに現れないので現場観察が必要です。車両導入前の基準を作るときは、運搬時間だけでなく、荷物待ちによる工程停止、誤搬送、棚卸し修正、応援人員、夜間対応も記録します。AGVが速く走っても、投入ステーションで荷受けできなければ工程の成果は改善しません。

現場ヒアリングは日本語・タイ語の双方で確認すると誤解を減らせます。「受領」は車両が荷物を取った意味か、着地の作業者が確認した意味かで変わります。「入庫済」はパレットが棚の前にあることか、WMSで確定したことかも異なります。用語表に英語の技術語、タイ語の現場語、日本語の管理語を並べ、画面表示と手順書で同じ状態名を使います。多言語化は翻訳の問題だけでなく、誰が何を確認するかという業務ルールの統一です。

RFPに入れるべき接続仕様

発注仕様には、対象の業務シナリオと除外範囲を最初に置きます。例えば「原材料倉庫の指定棚から組立ライン供給口まで、パレット単位の補給を行う。品質保留品、危険物、手持ち搬送、出荷は対象外」と具体化します。次にWMS、ERP、MES、フリート、車両、PLC、スキャナーの責任主体と製品・版を記します。見積に「WMS連携一式」とだけ書かせると、片方向の搬送要求だけが含まれ、在庫照合や例外復旧が別費用になる可能性があります。

最低限、接続点ごとにデータ辞書を求めます。作業ID、荷物ID、元・先、数量・単位、荷姿、優先度、期限、状態、イベントID、送受信日時、タイムゾーン、エラーコード、版数を定義します。各項目について必須・任意、発行元、変更権限、欠損時の扱い、保存期間を明記します。メッセージのサンプルは正常、重複、順序逆転、取消、タイムアウト、通信復旧後の一括再送を含めます。API名だけでは業務の正しさを比較できません。

供給者比較では、車両本体価格に加え、WMS側改修、フリートライセンス、PLC工事、スキャナー、ネットワーク、充電、設備改造、教育、保守、障害時の手動運用を分けて見積もります。車両を追加したときの接続料金や、WMS更新時の改修責任も確認します。定量的な効果予測は現状データを使い、何台でどのピーク作業量を捌くかを示してもらいます。根拠のない一般的なROIや市場規模は、個別工場の投資判断には使えません。

FATはメッセージと異常系を工場搬入前に潰す

FATでは実車・設備がすべてそろわないことがあります。その場合でも、WMSとフリートの接続部分を試験環境やシミュレーターで確認できます。テスト対象のソフト版、設定、マスタ、模擬設備、テストデータを固定し、試験後の改訂を記録します。Rockwell Automationの公式マニュアルは、受入試験で要求仕様に沿うテストケースと合否基準を定義し、インターフェース、劣化モード、障害・例外を試験する考え方を示しています。これは制御システムの資料なので、本記事では検収設計の原則として参照します。

FATの最小セットは、正常搬送、作業拒否、同じ要求の再送、異なる要求IDで同一荷物を二重指示、読取不一致、途中取消、イベント順序逆転、タイムアウト後の再接続、WMS停止中のバッファ、権限のない手動確定です。各ケースに入力、前提状態、予想するWMS在庫、フリート状態、車両状態、ログ、復旧手順を記入します。合否は「画面にエラーが出た」だけでは足りません。誤った在庫移動が起きず、荷物の所在を調べられることまで確認します。

同じ作業を再実行するとき、テストデータが前回の残骸を含むと結果が読めません。FATでは初期化手順と証跡の保存を明示し、失敗時は修正後に関連ケースを再試験します。供給者が「外部WMSの仕様に依存する」と回答した項目は、双方の担当者を決めて共同試験を計画します。片方の画面だけのスクリーンショットでは、連携境界を通った証拠になりません。

SATは実物の荷物と現場の混雑で検収する

SATでは本番相当のラベル、荷姿、棚、搬送口、ドア、ネットワーク、ピークに近い運用を使います。最初に低リスクのルートで単一作業を確認し、次に複数作業、優先度変更、通路遮断、設備停止、通信断、電池残量低下、手動搬送へ広げます。各ケースで現物の所在、WMSの在庫・予約、フリートのミッション、設備信号を同時に記録します。実車が到着した時刻だけを性能指標にすると、受渡待ちやWMS確認遅延を見落とします。

受入基準は工場固有に決めます。例えば「対象荷姿で誤荷物が確定しない」「通信再開後に同じイベントが二重適用されない」「停止した荷物を所定時間内に追跡できる」「代替手順で生産供給を維持できる」など、業務上の結果を条件にします。搬送能力は平均だけでなく、要求から着地確認までの時間分布、ピーク時の待ち、車両稼働と充電時間、手動介入件数で評価します。サンプル数、測定時間帯、除外条件を合意したうえで測ります。

安全試験は設備・車両の責任者が立会い、危険な状態を作らずに承認済みの手順で実施します。非常停止や安全センサーを作動させた後の復帰に、誤った在庫確定や二重ミッションが伴わないかも連携側で確認します。地図や棚番、搬送口の設定をSAT後に変更した場合は、影響範囲を評価して再試験します。最終的な引渡資料に、版数、設定バックアップ、状態遷移表、テスト結果、未解決課題、緊急連絡先、手動復旧手順を含めます。

稼働後の運用指標と変更管理

公開後の運用では「車両の稼働率」だけで成功を測れません。WMS作業の要求から受理まで、受理から荷受けまで、荷受けから荷降ろしまで、荷降ろしから在庫確定までを分けて計測します。これにより車両不足、発地の準備遅れ、搬送口の詰まり、確認作業の遅れを区別できます。重複イベント数、未照合荷物、手動復旧件数、予約在庫の長期滞留も監視します。改善会議では上位の平均値だけでなく、例外上位の作業IDを現物記録と照合します。

ルート追加、棚番変更、荷姿変更、WMS更新、車両追加、VDA 5050の版変更は、それぞれ別の影響を持ちます。変更要求には関係するデータ辞書、地点対応表、API、設備信号、教育資料、テストケースを紐付け、承認後に本番へ反映します。VDA 5050 3.0.0の発表後も、現場の車両やフリートがどの版・どの機能を実装しているかは個別確認が必要です。規格名だけで互換性を約束しないよう、実機と接続試験の結果を保存します。

データの保有とアクセスも決めます。車両位置や作業ログは、現場の故障解析、在庫監査、労務管理に利用され得ます。誰が閲覧できるか、どれだけ保存するか、外部クラウドへ送るか、タイ国内と他国拠点の間で共有するかを、社内の情報管理方針に合わせて設計してください。停止中も現場で荷物所在を追える最低限の記録と、復旧後の差分照合手順を残すことが重要です。

FAQ：AGV WMS連携の導入でよくある質問

WMSがなくてもAGVを導入できますか？

定点間の搬送だけなら、フリート管理や現場ボタンからミッションを発行する構成は可能です。ただし荷物ID、元・先、誰が受領したかを在庫システムへどう反映するかは残ります。WMSがない現場では、先にロケーション管理のルールと記録責任を決め、将来接続のために作業IDとイベントを保存する方がよいでしょう。

VDA 5050対応ならWMSとの直接接続は不要ですか？

不要にはなりません。VDA 5050はフリート制御と車両の通信を定めます。WMSの倉庫作業からミッションを作る変換、荷物照合、在庫確定、取消・再送の設計は別です。対応バージョンと実装範囲も調べ、実際の業務シナリオで試験します。

在庫はAGVが目的地に到着した時点で更新しますか？

一律には決められません。到着は車両の位置を示すだけで、荷物の引渡や棚入れを証明しません。荷降ろし信号、着地の荷物スキャン、設備側の受領、担当者の確認など、対象業務に必要な証拠を決め、その時点でWMSが作業を確定します。途中状態が必要なら走行中在庫の扱いも設計します。

通信断や二重メッセージはどう扱いますか？

作業IDと一意のイベントIDで記録し、受信側に冪等処理を持たせます。再接続後は未完了作業と現物を照合し、遅延イベントを自動適用してよい状態か確認します。前の搬送が動作中か不明なまま新規ミッションを発行しないことが基本です。

FATとSATでは何を分けて確認しますか？

FATでは接続仕様、状態遷移、重複・順序逆転・取消などを試験環境で確認します。SATでは実物の荷物、通路、搬送口、ドア、人との混在、現場ネットワークと手動復旧を確認します。双方で同じ作業IDを使ってWMS・フリート・車両・設備の証跡を結べるようにします。

まとめ：業務の確定点から接続を設計する

AGV WMS連携の成否は、車両が走ることより、倉庫作業と現物の状態が矛盾なく進むことにあります。WMSの作業、フリートのミッション、車両の走行、設備の受渡、在庫確定を別の状態として定義してください。作業IDと荷物IDで証跡を結び、重複・遅延・取消・手動迂回を設計し、FATで論理を、SATで現物と現場条件を検収します。

タイ工場で既存WMSとAGVの接続範囲を整理している段階なら、対象ルートの作業票、棚・搬送口の一覧、現状の例外記録から着手できます。TOMAS TECHでは、業務イベントと設備側の受渡条件を一緒に確認し、RFPや検収項目の整理をお手伝いできます。お問い合わせから検討中の課題をお知らせください。

参照した一次資料

• VDA, VDA 5050 Version 3.0.0（2026年3月） — フリート制御と移動ロボットの通信範囲。
• VDA/VDMA公式GitHubの仕様本文 — バージョン、ジョブ・状態、適用範囲。
• SAP Help, Manual Confirmation of Warehouse Tasks — 倉庫作業の確認と記録の製品例。
• GS1, EPCIS/CBV Implementation Guideline — 可視化イベントの選定と識別の考え方。
• GS1, EPCIS 2.0.1 Standard — イベント参照インターフェース。
• OPC Foundation, OPC UA Overview and Concepts — 産業システム間の情報交換モデル。
• Rockwell Automation, Functional Acceptance Testing — 要件、インターフェース、例外に基づく受入試験の原則。