Blog

2026.10.14

AGV エレベーター連携の導入設計|多層階工場のRFPと検収

AGV エレベーター連携の導入設計|多層階工場のRFPと検収

工場の1階で受け取った部品を2階の組立工程へAGVやAMRで運びたい。こうした「AGV エレベーター 連携」は、車両の走行ルートを延ばすだけでは実現しない。搬送指示、エレベーターの呼出し、着床と扉の確認、乗降の安全、通信断からの復帰までを一つの工程として設計する必要がある。本稿はタイ・ASEANの多層階工場を想定し、発注側がRFPに何を書き、FATとSATで何を確かめるかを整理する。

まず決めること:搬送の責任境界

同じ「1階から2階へ運ぶ」でも、誰がどの信号を発行し、誰が結果を保証するかで構成は変わる。MESやWMSが搬送要求を作り、フリート管理システムがAGVへ仕事を割り当てる。エレベーターとの接続は、そのフリート管理システムまたは専用ゲートウェイが扱う。エレベーター制御盤の内部動作と保守は昇降機メーカー・保守契約の範囲に属する。曖昧なまま発注すると、入口で車両が停止したときに「車両側の故障」「扉側の故障」「ネットワークの故障」の切り分けを誰も引き受けなくなる。

RFPには少なくとも、搬送要求の起点と完了の定義、AGVとエレベーターのインターフェース提供者、通常時の状態遷移、異常時の安全停止、手動運転への切替、ログの保管と責任者を記す。契約上の責任を決める前に、現場で実測した搬送数、ピーク時刻、積荷、乗降者、扉前の混雑、各階の待機場所を一枚の工程表に置く。エレベーターは共有資源であり、AGV側の運行計画だけで利用枠を独占できるとは限らない。

「既存のエレベーターを使う」の意味を分解する

既存機の型式、制御盤、停止階、かご内寸法、有効出入口幅、定格積載量、床段差、扉保持時間、消防・停電時の運転、保守契約を調べる。車両本体だけでなく、載せるパレットや台車、上部の治具も含めた最大外形と総質量を照合する。荷重の数字が足りていても、旋回に必要なかご前スペースや、敷居を越えるときの荷崩れが成立しないことがある。エレベーターが人荷共用か貨物専用か、ロボットが人と同乗可能かも現場と昇降機提供者が確認すべき条件である。

KONEのService Robot APIはロボットによる呼出し、割り当てられたエレベーターの階・方向・扉状態、呼出し状態などを紹介する。OtisのIntegrated Dispatchもサービスロボット向けのクラウドまたはオンプレミスAPIとして案内されている。ただし、これらの公開資料は主に建物内の配送・清掃などのサービスロボットを説明している。公開ページが存在するだけで、対象工場の貨物用昇降機、特定のかご、制御盤、荷姿で利用できると判断してはいけない。対象設備の型式、利用可能な呼出し方式、API契約、改造可否、現地法令と保守条件をメーカーに個別照会する。KONE・Otis

AGV エレベーター連携の制御は「呼ぶ」「乗る」「出る」に分ける

上位システムが「2階の工程へ搬送」と指示した瞬間にAGVを扉前へ走らせる設計は危うい。扉前は歩行者やフォークリフトと交差しやすく、エレベーターが別の要求を処理していることもある。通常シーケンスを、①要求受理、②乗場前の安全な待機点へ移動、③かごの予約または呼出し、④対象かご・着床階・扉開状態の確認、⑤乗場と車内の占有確認、⑥乗車、⑦車両停止・搭乗確認、⑧行先階への移動、⑨到着・扉開・降車許可、⑩降車、⑪かご解放、⑫搬送完了通知に分ける。製品が提供しない信号は、代替手段とその安全性を個別に設計する。

各段階で要求と応答を一対一に結び、ジョブID、車両ID、かごID、出発階、到着階、要求時刻、タイムアウト、再試行回数を記録する。同じ要求を再送したとき二重にかごを予約しない「冪等性」、タイムアウト後に遅れて届いた応答を無効にする世代番号、システム再起動時に現在状態を再確認する手順が必要になる。扉が開いたという一つの状態だけでは、かごの同定、乗場との高さ、車内の空き、進入許可のすべては証明できない。

AGV エレベーター連携の導入設計|多層階工場のRFPと検収 - figure 1

エレベーターのAPIを安全機能と取り違えない

APIで取得した扉状態や階情報は運行調整には役立つ。しかし、安全停止、挟まれ防止、エリア保護を担う信号にできるかは別問題である。通信の遅延、欠落、再送、誤った車両ID、停電時の状態を評価し、安全に関わる制御は適切な安全関連システムとして設計・検証する。ISO 3691-4:2023は無人産業車両とそのシステムの安全要求と検証を規定し、対象例にAGVとAMRを含む。ISO 12100:2010は機械のリスクアセスメントとリスク低減の方法論を示す。ISO 13849-1:2023は安全関連制御部の設計・統合方法を扱う。これらは「APIを接続すれば準拠」という認証の代用品ではなく、現場の危険源と機能を評価するために参照する規格である。ISO 3691-4:2023・ISO 12100:2010・ISO 13849-1:2023

車両・昇降機・建屋を一緒に測る

AGVのカタログにある幅や旋回半径だけを図面へ置いても、乗降可否は決まらない。現物で測る対象は、車両と積荷の最大外形、重心と揺れ、床から障害物までの高さ、敷居と床の段差、かご床のたわみ、各階での停車位置のばらつき、扉開口と有効幅、かご内の停止位置である。空車・最大積載・偏荷重の三条件を最低限区別し、タイヤ摩耗や床面の滑りがどの程度の位置ずれを作るかも試験条件に含める。

AGVが敷居に接近したとき、車両側センサーが敷居の隙間や反射面をどう見るかを確認する。荷台の上に箱が張り出す場合は車両の外形より荷姿の外形が優先する。入口で少し斜めに止まると、走行可能幅は大きく減る。床面の水平差と位置決め精度を必要な余裕に変換し、現地で合否を決める。特定の「一般的な必要幅」や「何秒の扉保持」を記事から転記して仕様値にすることはできない。数値は設備、積荷、人流、危険源に応じた測定と評価から決める。

各階の前室にはAGVの安全な待機点、歩行者の通路、手動搬送の退避経路、非常時のアクセスを配置する。待機中の車両が防火扉、避難経路、フォークリフト交差点を塞がないことも要件にする。エレベーターが詰まった際に後続車両が行列を作るなら、入口から十分離れたバッファを設け、フリート管理側で入場制限を掛ける。多層階の搬送設計は単一の車両の経路設計より、共有設備の待ち行列設計に近い。

搬送能力は走行速度よりサイクル時間で見る

1便の時間を「待機点への走行+呼出し待ち+乗車+階間移動+降車+到着後の搬送+戻りまたは次ジョブ」と分ける。複数の出発階・到着階がある場合は経路ごとに実測する。かごが人や別業務と共用なら、平均時間だけでなく、ピーク時の上位分位の待ち時間を要求にする。数式上の処理能力は、1便の実測サイクル時間と利用可能な運転時間を使って概算できるが、呼出し競合と故障停止を無視した理論値を保証値にしてはならない。

例として、時間当たり必要搬送数が20便で、テストした一往復の有効サイクルが5分なら、単純計算では1時間に12便で不足する。ただしこの数字は説明用の仮定であり、実設備の性能値ではない。車両を2台に増やしてもエレベーターが律速なら能力は倍にならない。RFPには「何台で何便」だけでなく、既存のエレベーター利用と混在したピーク時間帯に、一定時間内に何件を完了するかを記す。

インターフェースを三層に整理する

第一層は業務指示である。MES、WMS、ERPから品目、ロット、数量、出発地、行先、優先度を受け、完了や異常を返す。第二層は車両運行である。フリート管理が車両を選び、経路や待機点を指示する。第三層が昇降機との接続で、呼出し、割当て、扉状態、停止階、占有、異常を扱う。各層を同じ「API連携」の一語でまとめると、車両メーカーと昇降機メーカーの責任範囲が重なっているように見えてしまう。

VDA 5050はフリート管理システムとモバイルロボット間の標準化された通信インターフェースであり、2026年公表のv3.0は自由走行ロボットのゾーン概念と経路共有を取り込む。エレベーター制御の統一規格として読むのは誤りである。VDA 5050を採用しても、昇降機API、ゲートウェイ、現場の安全インターロックは別途仕様化しなければならない。採用する場合は、車両とフリート管理の対応バージョン、必須メッセージ、独自拡張、切断時挙動をRFPで確認する。VDAの発表・VDA 5050公式仕様

AGV エレベーター連携の導入設計|多層階工場のRFPと検収 - figure 2

APIか接点かは現場条件で選ぶ

既設昇降機にAPIが使えるなら、設備側が許可する呼出しと状態取得の範囲を確認する。APIが無い場合でも、許可された外部インターフェースで信号を授受できる場合がある。ただし昇降機制御盤へ独断で接点を追加したり、ボタンを機械的に押す装置を安全評価なしに取り付けたりしてはいけない。昇降機メーカー、保守会社、現地の検査・許認可担当と改造範囲を合意する。ネットワーク方式の選択は情報システムだけでなく、停止時に誰が復旧し、誰が安全を確認するかを含む運用設計である。

KONEの公開資料ではWebSocketによる通信と、呼出し状態のAllocated、Arriving、Served、Canceledなどが示される。これは状態遷移の考え方を理解する例になるが、他社の機器でも同じ項目が取得できるという意味ではない。Otisはサービスロボット向けにクラウドまたはオンプレミスの選択肢、シミュレーション環境、現場設置を案内する。いずれも対応機種と契約を確認するまで採用前提には置かない。KONE・Otis

安全設計は扉前だけで終わらない

危険源の洗い出しは各階の乗場、敷居、かご内、行先階の降車地点、手動回収ルートに分ける。歩行者が車両と扉の間へ入る、荷物が扉に干渉する、着床誤差で車輪が敷居に引っ掛かる、通信断で車両が停止したまま扉が閉まる、停電や消防運転で想定外の階へ向かう、といった場面を扱う。運用中だけでなく、清掃、保守、手動移動、復旧時の危険も含める。

リスク低減策には、進入前の占有確認、車両の速度制限、障害物検知、待機線、扉閉鎖時の進入禁止、安全停止、復帰の権限管理、現地表示などがある。どの策をどの主体が実装するかを表にする。検知機器の選択と安全機能の性能水準は、現場のリスク評価と適用法規・規格に従い専門家が決める。「センサーが付いている」だけではリスク低減を確認したことにならない。ISO 3691-4:2023の適用範囲と現地の昇降機規制を並べ、車両側・昇降機側・システム統合側の評価を別々に終わらせず、境界部を合同で検証する。ISO 3691-4:2023

人と貨物が同じかごを使う場合

人が乗る可能性のあるかごへ車両を自動進入させるなら、無人を前提とした制御をそのまま使えない。運用時間を分ける、対象かごを限定する、乗降者を検知してAGVを待機させる、係員の許可を必要とする、といった候補を評価する。どの案が採用可能かは設備の仕様と保守・法令条件次第であり、記事だけでは決められない。搬送の効率を理由に非常運転、火災管制、保守モードよりAGVを優先する設計は避ける。

異常復帰を先に書くと、設計が具体的になる

通常運転のデモでは、入口で止まったAGVの処理は見えない。RFPには少なくとも、呼出し拒否、割当て後の取消し、扉が開かない、異なる階へ着床、車両が乗車できない、車内で停止、到着階で降車できない、ネットワーク断、電源断、非常停止、火災運転、かご保守中のシナリオを入れる。各シナリオで「安全な停止位置」「タイムアウト」「誰が通知を受けるか」「自動再試行の条件」「手動回収の条件」「ジョブ完了か未完了か」を決める。

たとえば扉開の通知を受けた後に通信が切れた場合、AGVがまだ乗場にいるか、敷居を越えたか、かご内にいるかで許される動作は異なる。再接続後に過去の「扉開」をそのまま信じて進める設計は危険である。現在のかご位置と扉状態、車両位置を再取得し、一致しなければ停止して係員に引き渡す。エレベーター側の通常運転へ戻す条件も定義し、AGVが取り残されたまま無関係な呼出しを処理しないようにする。これは上位システムと昇降機の両側にまたがるため、片側のベンダーだけに復旧手順を委ねない。

AGV エレベーター連携の導入設計|多層階工場のRFPと検収 - figure 3

ログは事故調査用だけでなく日々の改善に使う

同じ時刻基準で、搬送要求、予約、割当て、扉状態、車両位置、乗降完了、異常コード、オペレーター操作を残す。個人情報を含む映像やIDがある場合は保存範囲とアクセス権を決める。ログがあれば、エレベーター待ちがボトルネックなのか、入口の障害物なのか、車両の位置決めなのかを区別できる。復旧を早くするためにも、現場HMIで「車両停止」「かご呼出し待ち」「手動回収待ち」を読み分けられる表示にする。

RFPに書くべき項目を一枚にまとめる

項目発注時に必要な情報受入時の確認例
対象設備各かごの型式、停止階、契約、改造可能範囲メーカーの適合回答と現地実機
荷姿最大外形、総質量、重心、積載条件最大荷重での乗降と敷居通過
搬送要求起点・完了、優先度、ピーク便数MES/WMSから完了までの一貫記録
インターフェースメッセージ、状態、認証、責任者再送、遅延、切断、再起動
安全各階・かご内・保守時の危険源と対策停止、進入禁止、手動回収
能力ピーク時の要求完了率と許容待ち時間人・他業務が混在する時間帯の実測
保守昇降機・車両・ゲートウェイの窓口故障切分け、復旧時間、ログ取得

この表は仕様の見出しであって、合否値そのものではない。発注前の現地調査でベースラインを取る。例えば「扉開を受けてから何秒以内に進入するか」は、扉の保持時間、積荷、車両加減速、歩行者対策が分かって初めて設定できる。メーカーの見積書に「エレベーター連携対応」とだけ書かれている場合は、対象機種、インターフェースと改造費、現地試験、保守契約変更、障害時の責任分担まで見積範囲へ戻す。

費用の比較は車両価格以外を揃える

比較する総費用は車両・フリート管理だけでなく、昇降機インターフェースの提供費、改造、ネットワーク、各階のセンサーと表示、床と敷居の改善、消防・安全評価、FAT/SAT、教育、保守を含む。APIに月額利用料がある場合は契約期間で見る。予備車両を買ってもエレベーターが単一点の故障なら搬送は止まる。業務停止の影響と手動バックアップの費用も同じ表で評価する。異なるベンダーの見積は責任境界と含む工事が違うため、総額だけで優劣を決めない。

FATとSATは別の問いを持つ

FAT(工場出荷前試験)では、実機やシミュレーターを使ってインターフェースの状態遷移と例外処理を検証する。要求ID重複、応答遅延、呼出し取消し、誤った階通知、ネットワーク断、アプリ再起動を試し、二重予約や誤進入が起きないかを見る。Otisはサービスロボットの開発者向けにオンラインシミュレーション環境を案内しているが、採用機種・契約で利用可能かを確認する必要がある。Otis

SAT(現地受入試験)では、実際の扉、敷居、人流、床、無線通信、既存のエレベーター運用を含めて確認する。空車・最大積載・偏荷重、各階、各かご、昼休みなどの混雑、手動割込、非常停止、保守モード、停電からの復帰を試験表にする。FATでAPI応答が正しかったことは、SATで荷物が安全に敷居を越えたことを意味しない。検収では、成功率だけでなく異常が起きた回数、原因、復旧に要した時間、手動介入の回数を記録する。合否の測定方法と試験回数は発注者と関係ベンダーが事前に合意する。

本番切替は階・便・時間帯を限定する

初日からすべての階と全搬送を切り替えるより、1かご、2階間、限定荷姿、限定時間帯で運転し、実測値と異常を確認して広げる。手動搬送への戻し方を先に訓練し、作業者が迷わずに運用を止められるようにする。フリート管理が進入を止めても、上位のMES/WMSに仕事が残り続けるなら現場に二重指示が生じる。切替時の未完了ジョブをどちらのシステムが保持するかまで決める。

よくある質問

AGVとAMRは同じエレベーター連携方式で使えますか?

エレベーターへの呼出しという業務上の要求は共通化できる。ただし、車両の位置決め、進入速度、経路変更、障害物回避、復帰方法は製品ごとに違う。フリート管理と車両の間にVDA 5050を使っていても、昇降機との接続が自動的に統一されるわけではない。候補車両ごとに乗降と異常復帰を現物で確認する。

既設の貨物用エレベーターにもAPI接続できますか?

機種、制御盤、契約、保守体制による。サービスロボット向けAPIの紹介ページは、その工場の貨物用設備への適用保証ではない。機器番号と制御盤情報を昇降機メーカー・保守会社に渡し、利用可能なインターフェース、改造可否、検査と費用を回答してもらう。独自配線で代替する前に安全と契約の条件を確認する。

エレベーター連携の費用はいくらですか?

設備構成と改造範囲が不明な段階で一律の金額は出せない。車両台数だけでなく、昇降機APIまたは接点、ゲートウェイ、床と乗場、安全対策、ソフトウェア、現地試験、継続契約を含めて同じ範囲で比較する。最初の見積依頼には機器型式、階数、荷姿、必要便数、運転時間、既存の保守契約を添える。

人と同じエレベーターにAGVを乗せられますか?

自動的に可能とは言えない。人流、昇降機の仕様、運用方法、適用法規、危険源評価によって決まる。人との同乗を前提にする場合は、車内の占有と乗降者の確認、優先運転、手動介入、非常運転との関係を具体的に決め、メーカーと安全担当を交えてSATで確認する。

発注前の現地調査で残す証拠

見積依頼に添える資料は、平面図だけでは足りない。各階の乗場と敷居を同じ測定方法で撮影し、車両の待機線、歩行者の横断位置、フォークリフトの動線、既存設備の扉開閉時間を記録する。荷姿については空箱の寸法だけでなく、最大積載時に上部・側面へどこまで張り出すかを示す。車両の型式がまだ決まっていないなら、候補の最大外形を包む仮の条件を作り、後の選定で縮める。実測値と設計値を混ぜないよう、資料には測定日、測定者、運転条件、図面の改訂番号を付ける。

現地調査ではエレベーターの運用者にも聞き取りを行う。平常時に誰が呼出しを優先するか、台車搬入の時間帯があるか、定期点検の停止が何曜日か、火災時の運転と停電時の扱いを確認する。これらはAGVの走行地図には表れないが、搬送能力と異常復帰には直結する。夜間だけの自動搬送を考える場合も、その時間に昇降機保守担当が遠隔または現地で対応できるかを確認する。人が少ない時間帯は、故障時の安全確認を機械任せにできるという意味ではない。

最後に、現在の手動搬送をベースラインとして記録する。1便の所要時間だけでなく、呼出し待ち、積み替え、階ごとの滞留、荷傷み、誤配、作業者の割込みを区別する。導入後の効果を「人を何人減らせたか」に一本化すると、納期遅延の低減や工程間在庫の改善を見落とす。目的を搬送の安定化とするなら、要求から引渡しまでの時間分布と未完了件数を指標にする。自動化後も同じ定義で記録できるよう、MES/WMSとフリート管理のイベントを紐付けるIDをRFPに含める。

ベンダー回答で確認する五つの質問

第一に、候補エレベーターのどの型式・制御盤まで実績または適合確認があるか。第二に、呼出し後の割当て、着床、扉開閉、取消しをどの信号で識別するか。第三に、AGVが敷居上またはかご内で止まったとき誰がどの手順で回収するか。第四に、メーカーや保守会社の承認が必要な工事を見積に含めているか。第五に、FATとSATで何を成功条件とし、どの試験が両社立会いになるか。回答が「対応可能」の一語なら、対象設備と試験項目が確定するまで仕様承認を保留する。発注者がこの五点を揃えて比較すると、車両価格だけでは見えなかった実装と保守の差が明確になる。

まとめ

多層階工場のAGV導入では、エレベーターをルート上の「点」として扱わず、予約、乗降、安全、異常復帰、保守を持つ共有設備として扱う。発注側はまず設備適合性と責任境界を確定し、呼出しから降車までを状態遷移として書き、実物の荷姿とピーク時の待ち時間を測る。VDA 5050は車両とフリート管理の接続に、昇降機メーカーのAPIは対象機器で確認された範囲に使う。FATでは論理を、SATでは現場と人流を検証してから搬送範囲を広げる。

既にAGVの経路と台数を検討している場合は、AGVレイアウト設計の記事が通路・床・停止精度の論点を補う。移載部の設計にはコンベヤ上AMR連携の記事も参照できる。多層階の搬送条件を整理する段階でも、対象設備の情報と工程表があればTOMAS TECHへ相談できる。

参考資料