AGV エレベーター 連携｜RFP・FAT/SAT受入設計

AGV エレベーター 連携の成否は、呼び出しAPIが動くかではなく、予約から解放までの状態を誰が確定し、異常時にどこへ戻すかを合意できるかで決まります。本稿では、多層階搬送を一つの分散トランザクションとして定義し、RFP、FAT、SAT、運用引継ぎまで一貫させる実務的な設計方法を解説します。

結論：エレベーター移動を「9状態の取引」として発注する

最初に結論を示します。AGVがエレベーターを使う処理は、予約、割当、到着確認、乗車、車内存在確認、目的階移動、降車、退出確認、解放という9状態で発注します。それぞれについて、開始条件、成功条件、タイムアウト、再試行、冪等キー、取消、証跡、責任者を定義します。単に「AGVからエレベーターを呼べること」と書くRFPでは、デモは成功しても通信断や再起動後の復旧が受け入れられません。

また、VDA 5050 3.0を採用しても、エレベーターとの接続が自動的に標準化されるわけではありません。VDAの公開資料が定義する範囲は、移動ロボットと中央Fleet Controlの間で、ジョブや状態を交換する通信インターフェースです。エレベーターAPI、ビル側ゲートウェイ、火災運転、保守運転、扉インターロック、現場の権限設計は別の統合境界です。この境界をRFPに明記することが、AGV システム構築の最初の品質条件になります。

なぜAGVとエレベーターの連携は難しいのか

単一フロアのAGVは、走行路、交差点、充電、荷役点の調整が主な対象です。多層階になると、AGV、Fleet Control、WMS/MES、エレベーターゲートウェイ、エレベーター制御、設備担当、EHSが同じ搬送を別々の状態で観測します。どれか一つのシステムが「乗車済み」と考えていても、別のシステムは「扉前で待機中」と記録しているかもしれません。この状態のずれが、二重呼び出し、扉占有、搬送指図の重複、機体の閉じ込め、手動復旧の長期化を生みます。

エレベーターはAGV専用機とは限りません。人、台車、保全部門と共用する場合、呼び出しを受け付けたことと、AGVが安全に乗車できることは同じではありません。火災モードや点検モードへの切替は、通常の業務優先度より上位です。したがって統合設計は、正常系の最短時間を追うだけでなく、「今の状態を確定できないときに動かさない」ことと、「安全を確認して運用を再開できる」ことを両立させる必要があります。

ISO 3691-4:2023は、AGVやAMRを含む無人産業車両とそのシステムについて、安全要求と検証手段を扱い、運用区域の状態が安全運転に大きく影響するとしています。ただし、本稿は適合証明そのものではありません。実機、建物、積載物、人との共用、現地法令を踏まえたリスクアセスメントと、メーカーによる確認が別途必要です。

VDA 5050 3.0で標準化できる範囲、できない範囲

VDAのVersion 3.0発表では、複数メーカーの移動ロボットを一つの制御系で扱うためのオープンな基盤、自由走行向けのゾーン概念、path sharing、ローカル言語のエラー情報、省電力アクションなどが説明されています。VDA 5050の公開ページは、Version 3.0.0を「移動ロボットとFleet Controlの間でジョブとステータスデータを交換するインターフェース」と位置づけています。公式GitHubには仕様とJSON Schemaがありますが、差異がある場合はVDA公開PDFが有効であると明記されています。

このため、VDA 5050は混成フリートの車両側境界を整理する有力な選択肢ですが、エレベーター統合全体の完成品ではありません。エレベーター各社はKONE API Portal、Schindler Developer PortalのCloud Robot API、Otisのロボット連携資料などを公開しています。しかし、認証、コマンド、イベント、建物適合、地域提供、契約条件が同一という意味ではありません。RFPでは「VDA 5050対応」と「対象エレベーターAPI対応」を別項目で評価します。

ここを曖昧にすると、AGVベンダーは「エレベーターAPIが指示を受けない」と説明し、エレベーターベンダーは「ロボット側が状態を更新しない」と説明し、ユーザー企業だけが復旧判断を背負う構図になります。契約前に境界を表にし、各状態のownerとevidence ownerを割り当てるべきです。

AGV エレベーター 連携を9状態へ分解する

9状態は、設備ブランドに依存しない業務の共通語彙です。実際のAPI名が異なっても、「今どこまで確定したか」を比較できます。重要なのは、コマンドを送った事実ではなく、次の状態へ移ったことを観測可能な証跡で確認することです。

状態遷移には共通の相関IDを使います。搬送指図ID、AGVミッションID、エレベーター予約ID、設備イベントIDを一つのトレースに関連付け、後から順序を再構成できるようにします。一つのIDへ無理に統一する必要はありませんが、相互の対応表がログに残ることは必須です。

「車内存在確認」は特に重要です。乗車コマンドが完了しただけでは、AGVが車内に正しく収まったと断定できません。AGVの位置、エレベーター側の検知、扉の許可状態を組み合わせ、どの情報を正とするか決めます。センサーを追加する場合も、単一センサーのONだけで安全判断を完結させず、故障時の挙動を含めて設備メーカーと合意します。

timeout・retry・idempotencyをRFPに書く

分散システムでは、「応答がない」は「処理されなかった」と同義ではありません。予約要求を送った直後に応答経路だけが切れた場合、設備側では予約が成立している可能性があります。そこで同じ要求を再送すると、予約が二重化する恐れがあります。RFPでは、各更新要求に冪等キーを付け、同一キーの再送は同じ結果を返すか、現状態を照会して収束できることを求めます。

タイムアウト値はベンダーに一律の秒数を押し付けるのではなく、状態ごとに設計根拠を提出させます。ネットワーク応答、エレベーター待ち、AGVの物理移動、扉動作では時間特性が違います。タイムアウト後も、即座に別号機を呼んでよい状態と、人または設備の確認まで新しい呼出を禁止すべき状態があります。時間だけで遷移せず、最後に確認できた安全状態と設備モードを合わせて判定します。

再試行ポリシーに必要な項目

• どのコマンドが再送可能か、照会のみ可能か、手動確認が必要か。
• 同一冪等キーを保持する期間と、保存先、再起動後の復元方法。
• 指数バックオフや上限回数など、設備APIを過負荷にしない方法。
• 重複イベント、遅延イベント、順序逆転イベントの扱い。
• 取消と完了が競合したときに、どちらを優先し誰へ通知するか。
• タイムアウト中に火災・保守モードへ変化した場合の中断条件。
• 自動復旧から手動保留へ切り替える条件と、解除権限。

retryは「成功するまで繰り返す」機能ではありません。上限を超えたらManual Holdへ移します。AGVを安全な待機位置へ移動できるのは、実位置、設備状態、安全な経路を確認できた場合に限ります。車内にいる可能性がある、または状態不明ならその場で停止保持し、Manual Holdのまま予約・占有を解放しません。自動化の成熟度は再試行回数の多さではなく、誤った状態を増やさずに停止し、短い手順で復旧できることに表れます。

通信断と再起動復旧の状態機械

通信断は、AGV無線、Fleet Control、建物ネットワーク、クラウドAPI、エレベーターゲートウェイのどこでも起こり得ます。RFPに「通信復旧後は自動再開」とだけ書くと危険です。復旧したプロセスは、停止直前のメモリではなく、AGVの実位置、扉・階床・運転モード、永続化されたトランザクション、WMS/MESの搬送状態を再照合しなければなりません。

復旧処理は、まず新規ミッションの発行を抑止し、未完了トランザクションを列挙します。次に、AGVの実位置とエレベーターの階床・扉・運転モードを照合します。両方を確認できた場合に限り、オペレーター承認の遷移として、Waiting、Boarding、In Car、Exitingのうち実証済みの一状態へ戻します。Recoveringから任意の過去状態へ自動で戻してはいけません。照合不能ならRecoveringからの遷移先はManual Holdだけです。車内にAGVがいる可能性を排除できない場合、予約を解放して通常運転へ戻すべきではありません。設備担当による現認と、定めた権限での解除が必要です。

再起動試験はFATの疑似障害だけで終わらせません。SATで実際の建物ネットワーク、無線ローミング、設備ゲートウェイ、運用端末を含め、各状態の途中で計画的に切断し、証跡を残します。試験後に「動いた」ではなく、誤った二重予約がない、搬送指図が一度だけ完了する、残存ロックがない、監査ログで復旧判断を追えることを確認します。

火災・保守モード・人との共用を最上位要件にする

火災運転や保守運転は、通常のAGV搬送より常に優先されるべき設備状態です。ただし具体的な挙動はエレベーターメーカー、建物設備、適用要件によって異なるため、AGV側だけで一般化して決めてはいけません。RFPでは、モード情報をどこから取得し、どの状態でAGV要求を拒否し、車内にAGVがいる場合に誰が判断し、通常運転復帰後にどの手順で再開するかを、メーカー承認を含めて要求します。

人と共用するエレベーターでは、AGVが人を検知できるかだけでなく、運用方針が必要です。専用時間帯、専用号機、共用可否、最大占有条件、乗場での待機位置、押しボタン利用者との競合、台車のはみ出し、扉付近の立ち止まりを設計します。「センサーが止めるから安全」とせず、侵入しやすい導線を作らない、表示や教育を用意する、異常時の連絡先を明確にするという多層防御にします。

AGV 安全対策の設計境界

安全機能の割当は、API仕様書だけでは完結しません。ISO 3691-4:2023が示すように、運用区域の準備も重要です。段差、床の隙間、扉敷居、停止精度、無線、照度、死角、避難導線、荷崩れなどを現場で確認し、リスクアセスメントの結果をSAT項目と運用手順へつなげます。

AGV WMS 連携から設備制御までの責任分界

WMS/MESは「どの荷を、どこからどこへ、いつまでに運ぶか」を扱い、Fleet Controlは機体と経路を割り当てます。エレベーターゲートウェイは業務要求を対象設備のコマンドやイベントへ変換し、エレベーター制御は正規の安全・運転ロジックに従います。この分担を崩してWMS/MESが直接号機や扉を細かく制御すると、設備更新や複数号機への拡張時に結合が強くなります。

搬送指図の完了地点も合意が必要です。「目的階へ到着」でWMS/MESへ完了を返すのか、「降車して退出確認」で返すのか、「次工程の受渡し点へ荷を置く」まで待つのかで、在庫状態と再指図の挙動が変わります。工程間搬送 自動化では、エレベーター通過だけを成功にしても、荷が次工程に届かなければ業務は完了していません。設備トランザクションと業務トランザクションを分け、両方の相関を残します。

RACIでは、Command OwnerとState Evidence Ownerを分けて考えます。たとえばFleet Controlが予約を指示しても、予約成立の証跡はエレベーターゲートウェイにあり得ます。安全インターロックのownerは設備メーカーの設計範囲であり、AGV側が勝手に代替できません。FAT証跡は模擬設備を含む統合範囲、SAT証跡は実建物と運用を含む全範囲をカバーします。

RFPにそのまま使える要求項目

RFPは機能一覧ではなく、受入可能な契約言語にします。「対応すること」だけでなく、提出物、例外、試験方法、合格証跡を指定します。次の要求をプロジェクト条件に合わせて調整してください。

1. アーキテクチャとインターフェース

• 対応するVDA 5050のバージョン、使用機能、未対応機能、独自拡張を一覧提出する。
• VDA 5050はAGVとFleet Control間の範囲であり、エレベーターAPIは別境界として仕様を提出する。
• WMS/MES、Fleet Control、AGV、ゲートウェイ、エレベーター制御の論理・物理構成図を提出する。
• 認証方式、証明書更新、時刻同期、ネットワーク経路、ポート、名前解決、監視点を提出する。
• APIのコマンド、イベント、状態、エラー、レート制限、互換性、廃止方針を明示する。

2. トランザクションと異常処理

• 9状態ごとの開始・成功・失敗・取消条件、timeout、retry、idempotencyを状態遷移図で提出する。
• 重複、遅延、順序逆転、応答喪失、部分成功を再現する試験手段を提供する。
• 再起動後に未完了トランザクションを永続データから再構築し、現状態と照合する。
• 自動復旧、Manual Hold、現認、解除、再開の権限と操作履歴を定義する。
• 予約、ゾーン、搬送指図の残存ロックを検出・可視化・解放できるようにする。

3. 安全・設備モード・共用運用

• 火災、保守、点検、手動優先、利用停止の各モードでAGV要求がどう扱われるか提出する。
• 人、台車、他ロボットとの共用条件、禁止条件、乗場の待機・退避位置を定義する。
• AGVとエレベーター双方の安全機能、インターロック、責任境界を設備メーカー承認付きで示す。
• リスクアセスメント、残留リスク、教育、標識、PPE、緊急連絡、復旧SOPを提出する。
• ソフトウェア更新、設備改修、フロア変更時の再評価と回帰試験を変更管理へ含める。

4. 監視・ログ・引継ぎ

• 共通相関IDで、WMS/MESから設備イベントまで一つの時系列に追跡できるようにする。
• ログ時刻の基準、保存期間、アクセス権、個人情報、エクスポート形式を合意する。
• 稼働監視に、未完了時間、Manual Hold、再試行、残存予約、モード変更を含める。
• 運用手順、障害切分け表、連絡網、予備品、バックアップ、復元、教育教材を提出する。
• ソース、設定、ライセンス、API契約、証明書、管理者アカウントの引継ぎ範囲を明記する。

FAT/SATで何を証拠として受け取るか

FATは工場出荷前にロジックと統合を早期検証する場、SATは実サイトで建物・ネットワーク・人・運用を含めて確認する場です。FAT合格をSAT免除の理由にしてはいけません。一方で、すべてをSATまで先送りすると、改修コストと停止影響が増えます。設備シミュレータやhardware-in-the-loopを使い、異常系の大部分をFATで潰し、SATでは現場固有条件とエンドツーエンドを重点確認します。

証跡パッケージは、試験仕様書、承認済み手順、構成バージョン、テストデータ、API trace、機器ログ、画面記録、動画、不具合票、再試験結果、署名済み判定を含めます。ログだけでは現場位置が分からず、動画だけではAPIの順序が分かりません。両者を共通時刻と相関IDで結びます。

合格判定に「問題なく動作すること」と書くのは不十分です。たとえばT02なら、「同じ予約キーの新規予約が増えず、既存予約の状態照会で処理が収束し、最終的に残存予約がゼロであること」のように観測可能にします。秒数の閾値は、設備仕様、搬送能力、業務要求、リスク評価からプロジェクトごとに設定し、根拠を記録します。

導入前PoCと本番受入を混同しない

PoCはAPI接続や基本動線の不確実性を減らすために有効ですが、本番受入の代わりではありません。PoCで正常に1回乗れたとしても、同時要求、モード切替、再起動、無線断、人との共用、シフト引継ぎは証明されません。PoCの終了条件には、次段階で未検証の項目、制約、必要改修、概算構成を残します。

ベンダー選定では、動画の見栄えより、状態遷移表、API仕様、異常注入手段、ログ、責任分界、メーカー連携体制を評価します。既存設備へ接続する場合は、対象建物・号機・制御盤・ソフトウェアがAPI連携に適合するか、現地でメーカーに確認します。公開APIポータルがあることは、すべての既設号機で即利用できることを意味しません。

すでに単一フロア搬送を検討している場合は、タイ工場のAGVシステム統合ガイドで上位システム、Fleet Control、現場設計の全体像を確認できます。荷の受渡し方式を比較したい場合は、コンベヤトップAMRの導入設計も参考になります。夜間自動運転を含める場合は、無人夜間運転の設計要点と合わせ、復旧権限と呼出体制を整合させてください。

タイ工場での工程間搬送 自動化とBOI検討

タイで自動化投資を計画する場合、技術RFPと投資優遇の確認を並行して進めると、対象設備、契約分割、証憑、スケジュールの手戻りを減らせます。BOIのSmart and Sustainable Industry関連ページには、対象条件の確認を前提として、最低投資額100万THB（土地・運転資本を除く）と機械輸入関税免除が記載されています。既存事業の高度化では、土地・運転資本を除く対象投資額の50%を上限とする3年間の法人所得税免除が示されています。本プロジェクトで使用または更新する機械、automation system、roboticsの総価値の30%以上がタイ国内のautomation産業にリンクする場合は、土地・運転資本を除く対象投資額の100%相当を上限とする3年間の法人所得税免除が示されています。

ただし、これらは本記事公開時点の計画参考情報です。対象活動、既存・新規事業の区分、投資額の算定、対象機械、国内自動化産業とのリンク、申請時期、承認条件は個別にBOIまたは専門家へ確認してください。優遇条件を満たすことと、AGV・エレベーター統合が安全であることは別問題です。税務上の設備範囲を理由に、安全機能、ログ、FAT/SAT、教育を削減してはいけません。

調達では、AGV本体、Fleet Control、WMS/MES改修、エレベーターAPI・ゲートウェイ、盤改造、ネットワーク、床・乗場工事、試験、教育、保守を分けて見積もります。誰の見積にも入っていない境界作業がないかを確認します。BOI申請用の設備明細と、RFPの機能・受入項目を対応付けておけば、変更時の影響を追いやすくなります。

本番立上げの段階計画

一斉切替ではなく、状態と責任を確認できる段階に分けます。最初にデジタル接続だけを確認し、次に無荷重のAGV、試験荷、限定時間帯、限定フロア、通常シフトへ広げます。各段階で停止条件、ロールバック、承認者、監視項目を定めます。問題が起きたときに次段階へ進まない仕組みが重要です。

段階ごとの出口条件

監視指標は、平均値だけでなく分布と異常の内訳を見ます。予約待ち、号機待ち、乗車、移動、退出の時間を分け、Manual Holdの件数と原因、再試行、取消、残存ロック、モード切替を記録します。本稿では一般的な目標値を置きません。建物構成、号機利用、人との共用、搬送波動が異なるため、ベースラインを計測し、業務要件と安全要求からサイトごとに決めるべきだからです。

変更管理では、AGVソフトウェア、Fleet Control、エレベーターゲートウェイ、制御盤、ネットワーク、証明書、WMS/MES、フロアレイアウトの変更を対象にします。更新前に影響する状態と試験ケースを選び、更新後に回帰試験を行います。VDA 5050のバージョン変更も、JSONが通るかだけでなく、使用しているアクション、状態、拡張、エラー処理が同じ意味を保つかを確認します。

発注者が避けるべき5つの落とし穴

落とし穴1：呼出成功を連携成功とみなす

呼出APIの200応答は、AGVが安全に目的階へ出たことを示しません。9状態を最後まで追い、退出確認と解放を分けます。

落とし穴2：VDA 5050が建物設備も標準化すると考える

VDA 5050 3.0の中心は移動ロボットとFleet Control間です。エレベーターAPI、設備モード、現場インターロックは別仕様として受け入れます。

落とし穴3：タイムアウト後に新しい要求を作る

応答喪失時は、設備側で処理済みかもしれません。冪等キーと状態照会で収束させ、状態不明ならManual Holdへ移します。

落とし穴4：FATの正常系だけでSATを短縮する

実建物の無線、床、扉敷居、人の動線、火災・保守運用はFATだけでは確認できません。異常注入はFAT、現場固有条件はSATという役割を明確にします。

落とし穴5：運用部門を最後に教育する

復旧権限、アラーム、設備モード、共用ルールは設計そのものです。設備・EHS・IT/OT・生産・物流・保守をRFPと試験レビューから参加させます。

FAQ

AGV エレベーター 連携とは何を統合することですか？

AGVの移動だけでなく、WMS/MESの搬送指図、Fleet Controlの機体・経路割当、エレベーターの予約・号機・扉・行先・運転モード、現場の安全・復旧手順を一つの業務として統合することです。API接続はその一部です。予約から解放までの9状態と責任・証跡を定義すると、ベンダー間の境界を管理しやすくなります。

VDA 5050 3.0対応ならエレベーターAPIも共通ですか？

いいえ。VDA 5050 3.0は移動ロボットと中央Fleet Controlの通信を対象とします。エレベーターAPIや建物ゲートウェイを自動的に共通化する仕様ではありません。対象号機、メーカーAPI、認証、コマンド、イベント、設備モードを別途確認し、統合試験が必要です。

AGV システム構築のRFPで最初に決めることは何ですか？

対象業務と完了地点、9状態、システム境界、owner、異常時の安全状態、FAT/SATの証跡です。機体仕様だけを先に決めると、エレベーター改修や上位連携が後から追加費用になりやすいため、建物・ネットワーク・運用を含む全体構成で発注します。

AGV WMS 連携では完了をいつ返しますか？

業務要件で決めます。目的階到着、退出確認、次工程への荷渡しは別の状態です。一般化して一つを正解にはできません。設備トランザクションと業務トランザクションを分け、WMS/MESが在庫や再指図を誤らない完了地点を合意します。

AGV 安全対策で通信断時に自動再開してよいですか？

最後の確認済み安全状態と、復旧時の実状態が一致し、未完了要求や設備モードに矛盾がない場合に限って検討します。車内存在や旧要求の実行有無が不明なら、自動再開せずManual Holdとして現認・承認後に復旧します。

工程間搬送 自動化のFATとSATはどう分けますか？

FATではシミュレータや実機を使い、状態機械、重複、遅延、通信断、再起動などを再現します。SATでは実建物の号機、無線、床、扉、荷、人の動線、設備モード、運用引継ぎを含むエンドツーエンドを確認します。両方で相関ID付きのログと現場記録を残します。

タイのBOI優遇はAGVとエレベーター改修に使えますか？

対象活動、設備、投資区分、申請時期などにより判断が変わります。BOIの現行案内には最低投資額や税・関税上の条件が示されていますが、適用可否は個別確認が必要です。技術RFPと設備明細を対応付け、申請前にBOIまたは専門家へ確認してください。

まとめ

AGVとエレベーターの統合は、APIを一本つなぐ作業ではありません。予約、割当、到着確認、乗車、車内存在確認、目的階移動、降車、退出確認、解放の9状態を、timeout、retry、idempotency、通信断、再起動、火災・保守モード、人との共用まで含めて設計する分散トランザクションです。VDA 5050 3.0はAGVとFleet Control間を整える有力な標準ですが、エレベーター境界は別途設計・受入が必要です。RFPに責任と証跡を書き、FATで異常系、SATで実建物と運用を確認することで、本番で復旧できる工程間搬送へ近づけます。

対象号機やベンダーが未確定の要件整理段階でも、AGV・上位系・エレベーターの境界とFAT/SAT計画をご相談いただけます。

参考情報

• VDA: Version 3.0 of VDA 5050 released
• VDA: VDA 5050 Version 3.0.0 publication
• VDA5050 official GitHub repository
• ISO 3691-4:2023
• KONE API Portal
• Schindler Developer Portal: Cloud Robot API
• Otis robot integration datasheet
• Thailand BOI: Smart and Sustainable Industry