フォークリフト 呼び出しシステム｜配車PoC・RFP設計

フォークリフト 呼び出しシステムを検討するとき、工場の呼び出しベルを無線ボタンへ置き換えるだけでは、待ち時間は測れません。「誰かが押した」「運転者の端末が鳴った」で終わらせず、搬送要求の受付、配車、到着、積み込み、配送、完了までを一つの業務として記録する必要があります。本稿では、タイ工場で使う呼び出し・配車の要件を整理し、30日PoC、RFP、FAT/SATへつなげる方法を実務目線で解説します。

フォークリフト 呼び出しシステムは何を解決するのか

典型的な現場では、部品がなくなると作業者がベルを押す、内線する、無線で倉庫を呼ぶ、チャットへ投稿する、といった複数の連絡手段が併存します。しかし、連絡が届いた後に誰が仕事を引き受けたか、何号車が向かうか、いつ到着したか、空振りやキャンセルをどう扱ったかが残らなければ、翌日の改善会議では感覚論に戻ります。

呼び出しシステムが解決すべき課題は三つです。

1. 配車の曖昧さ：全員に鳴らして「誰かが行く」運用をやめ、担当車・担当者・優先順位を確定する。
2. 応答確認の欠落：通知到達、閲覧、受付、担当引受、到着を別の状態として残す。
3. 待ち時間の不可視：要求時刻から到着・完了までを同じ定義で計測し、場所、時間帯、品目、理由別にボトルネックを探す。

したがって、最小構成でも「呼出入力」「配車判断」「運転者への通知」「受領確認」「状態履歴」「監督者画面」が必要です。設備やWMSへ接続する場合でも、最初に決めるのはプロトコルではなく業務状態と責任者です。

安全境界：呼出・配車は衝突防止装置ではない

最重要の前提です。呼び出し・配車システムは、衝突防止装置、safety-rated control、交通ルール、警笛、警告灯、歩車分離、trained spotter、運転者教育、承認済みの緊急連絡手段の代替ではありません。 スマートフォンに「到着」と表示されても、進路が安全である証明にはなりません。現場risk assessment、タイの法令、車両メーカーの指示、EHS承認、適用規格が優先します。

米国OSHAのフォークリフト資料でも、車両と歩行者の分離、歩行者優先、見通しの悪い場所での警笛、明確な進路、必要時のspotterなどが示されています。これはタイ法の代用ではありませんが、配車アプリが物理的・運用的な交通対策を置き換えないことを理解する有用な一次資料です。OSHAは運転者の訓練と評価も求めています。システムのログイン権限を得ることと、安全に運転する力量があることは別です。

ISO 3691-4:2023はdriverless industrial truckとそのsystemの安全要求・検証を扱い、operating zoneの条件が安全運転へ大きく影響すると説明しています。有人フォークリフトへ作業を送る今回のworkflowが、自動的に同規格へ適合するわけではありません。将来AGV/AMRと共通配車する場合は、有人車の業務割当と無人車systemのsafety controlを別の設計境界として審査します。

工場 呼び出しベルから配車workflowへ

ベルは「要求が発生した」ことしか表せません。配車workflowは、要求に一意のjob_idを付け、少なくとも次の七状態を管理します。

requested → acknowledged → assigned → arrived → loaded → delivered → closed

acknowledgedとassignedを統合すると、「管制が見たが誰も向かっていない」状態が消えます。deliveredとclosedを統合すると、誤品、数量差、受取拒否の未解決が完了扱いになります。画面は簡単でも、data modelでは分けることが重要です。

作業者 呼び出し 通知の入力を標準化する

呼出点は固定ボタン、タブレット、HMI、barcode scan、Andon、MES画面などから選べます。入力方式が違っても、backendへ渡す項目は揃えます。

• call_point_id：呼出場所を一意にする。表示名の変更とIDを分離する。
• request_type：空パレット、材料補給、完成品搬出、廃棄物、緊急でない応援など。
• pickupとdestination：自由記述ではなくmasterから選ぶ。
• load_id：lot、kanban、pallet、handling unitなど、追跡単位を明示する。
• priority：作業者の気分ではなく、停止影響や計画ルールから算出する。
• requested_at：端末時刻とserver受信時刻を区別し、timezoneを持つ。
• requested_by：個人、役割、設備のどれが発信主体かを定義する。

物理ボタンは操作が速い一方、用件を表しにくく誤押下の確認が要ります。タブレットは詳細を入力できますが、手袋、ログイン、破損、充電が課題です。PLCやAndonから自動要求する場合、chattering、同一停止の重複発報、設備復帰前の再要求を防ぐdebounceとbusiness ruleが必要です。

リアルタイム 通知 製造現場：応答確認を三段階に分ける

リアルタイム通知 製造現場の案件で最も多い誤解は、push notificationの配信成功を業務受付とみなすことです。OSやbrokerが端末到達を返しても、人が内容を理解して仕事を引き受けたとは限りません。

通常の補給呼出なら、「90%を60秒以内にacknowledge」というSLOを例としてRFPに置けます。ただしこれは本稿の例示値で、標準値でも保証値でもありません。緊急事象へ流用せず、現状baseline、シフト人数、区域、通信条件から再計算します。60秒を超えたら、別担当、班長、管制へ段階的にescalateし、通知だけでなく責任を移します。

配車ロジックは最短距離だけで決めない

最も近い車両へ自動割当すれば効率化できるように見えます。しかし、現場では積載能力、attachment、運転資格、充電残量、区域許可、現在の荷、通路規制、時間帯、優先job、休憩・交代が効きます。RFPでは、candidate選定を次の順で説明させます。

1. 適格性filter：車種、能力、attachment、資格、区域、稼働状態を満たさない候補を除外。
2. 業務制約：同時積載禁止、品種分離、clean/dirty zone、one-way aisleなどを適用。
3. 優先順位：line stop risk、予定時刻、待ち時間、荷のcriticalityを評価。
4. 距離・負荷：残り候補からestimated travelとqueueを比較。
5. 人の承認：例外、混雑、切替時にはdispatcherがoverrideし、理由を記録。

「AI配車」というラベルより、どのinputで候補を外し、同点をどう解き、overrideを誰が承認し、変更前後を監査できるかが重要です。PoCのjob数が少ない段階では、透明なrule-based dispatchの方が検証しやすい場合があります。

待ち時間KPIをイベント時刻から作る

平均だけを見ると、少数の長時間滞留やシフト差が隠れます。最低限、次を同じdashboardに並べます。

• ack_time = acknowledged_at − requested_at
• assignment_time = assigned_at − acknowledged_at
• travel_wait = arrived_at − assigned_at
• service_time = delivered_at − arrived_at
• total_lead_time = closed_at − requested_at
• p50、p90、p95、最大値、SLO超過率、未完了件数、取消・再配車率

例として、架空の現場で1日48件、中央値11分、p90が24分、監査可能な応答確認なしが12%だったとします。これは市場平均でも顧客実績でもありません。さらに、48件×中央値11分を総待ち時間とする計算は誤りです。中央値は各eventの合計ではないからです。正しくは対象eventごとにarrived_at − requested_atを計算し、eligible callだけを合計します。

同じ架空dataで合計待ち時間が528分/日から336分/日へ減ったなら、解放時間は192分、すなわち3.2時間/日です。年間250稼働日なら理論上800時間/年ですが、これは自動的な人件費削減ではありません。生産増、残業回避、欠品停止低減などへ実際に再配置できた範囲だけをbenefitとして評価します。

KPIの分母と除外条件をRFPに書く

「95%を8分以内に到着」という例示SLOを採用するなら、8分の開始はrequestedかassignedか、到着はGPSのgeofenceかbutton操作か、荷が未準備の場合を除外するかを決めます。本稿の例示値は一つの定義済みzoneと荷準備済み条件に限る仮案です。

除外を自由記述にすると、悪いeventがすべて除外されます。planned shutdown、test call、requester取消、通信障害、車両故障、荷未準備をreason code化し、「service側の責任」「request側の責任」「共通原因」「除外不可」に分類します。月次報告ではSLO本体と除外件数を同時表示します。

ERP・WMS・MES・OTの責任境界

ISA-95はlogistics/businessとmanufacturing controlのintegrationを整理する技術非依存の枠組みです。本案件でも、すべてを一つのアプリへ詰め込まず正本を分けます。

たとえばMESが材料不足を検知しdispatch jobを作り、WMSがpickup binとhandling unitを返し、dispatchが車両を割当て、delivery後にWMS/MESへbusiness completionを通知します。PLCへの書込みが必要なら、monitoringとcontrolを分け、メーカー承認、change request、backup、rollback、FAT/SATを追加します。

MQTT・OPC UA・APIをどう選ぶか

MQTT 5.0はOASISの軽量publish/subscribe transportで、M2M/IoTにも使えます。呼出点が多く、疎結合にeventを配る場合の候補です。しかしQoSはmessage transferの性質であり、「搬送が一度だけ業務完了した」ことを保証しません。client retryやnetwork復旧で同一要求が再送されても、idempotency_keyで二つのactive jobを作らない設計が必要です。

OPC UAはinformation/message/communication/conformance modelを定義し、ClientServerとPubSubを支援します。PLCやindustrial gatewayのcontextを型付きで読む用途に向きますが、OPC UAを使うだけでsecurityが完成するわけではありません。公式仕様も、authentication、integrity、confidentialityの仕組みを提供しつつ、どれを要求するかはsite設計者が決めるとしています。

REST APIはWMS/MESとのrequest/responseやmaster参照に扱いやすい方式です。選択は一つに限定する必要はありません。設備側OPC UA、edge-to-platform MQTT、business system RESTという組合せもあります。RFPではprotocol名だけでなくschema version、timestamp、retry、timeout、deduplication、ordering、offline buffer、error response、certificate/key rotationまで定義します。

OT接続の具体像はタイ工場向け産業用IoTゲートウェイ選定ガイドも参照してください。呼出点を増やすほど、現場で交換できること、offline時に状態を失わないこと、誰がcertificateを更新するかが重要になります。

現場 連絡手段 効率化と通知疲れ

全員へ一斉通知すると初日は速く見えますが、不要通知が増えれば無視されます。宛先はrole、zone、shift、qualification、availabilityで絞り、一次担当が受けなければ二次へ移します。勤務時間外の個人端末へ送らない、共有端末は利用者交代を記録する、請負者accessは期限を切る、といったidentity運用も必要です。

音、振動、画面は役割を分けます。短い通常呼出は振動と短い表示、詳細は画面、運転中の入力は停止してから行う設計とします。安全上必要な警笛、警告灯、標識や既存alarmを、スマホ通知へ置換してはいけません。インカムやPTTを含む併用設計はタイ工場のインカム代替・現場連絡手段ガイドで比較できます。

Offline・再送・重複を正常系として設計する

工場の通信断は例外ではなく、保全・停電・AP再起動・WAN障害で発生します。呼出端末はonline表示だけでなく、最後のserver確認時刻、buffer件数、degraded modeを示します。offline中に受付できない方式なら、利用者へ明確に失敗を返し、代替連絡へ切り替えます。silent failureが最も危険です。

復旧時は古い要求を現在の新規要求として大量配信しません。各eventにjob_id、event_id、occurred_at、recorded_at、sequenceまたはversionを持たせ、serverは重複を排除します。順序逆転が起きたら、単純に受信順を信じずbusiness transitionを検証します。FATでは同じrequestを10回再送する試験、network断中の取消、assigned直後のserver再起動を入れ、未解決の重複active jobが0件であることを例示acceptanceにします。

Cybersecurityと個人データを後付けにしない

NIST SP 800-82 Rev.3は、OT固有のperformance、reliability、safetyを考慮したsecurity guidanceです。本案件では、call point、gateway、dispatch server、mobile device、WMS/MES interfaceをassetとして登録し、network segmentation、least privilege、allowlist、certificate/key管理、log、backup、vulnerability対応、remote maintenance、change controlをRFPに含めます。

運転者IDや端末位置を使う場合、目的を配車と業務証跡へ限定し、収集粒度、保持期間、閲覧者、従業員への説明、訂正・削除・調査時の手順をタイの法務・人事と確認します。常時の精密位置が本当に必要かを問い、zone arrivalだけで足りるなら収集を減らします。便利だから集める、は要件になりません。

30日PoCの範囲を小さく、例外を広くする

本稿では、2 zone、3 call point、2 shift、最低120 callを例示PoC範囲とします。TOMAS TECHの実装patternであり、標準や成功保証ではありません。対象siteのcall頻度とriskに応じて再計算してください。

PoCで見るのはhappy pathだけではありません。二重押下、誤ったpickup、荷未準備、担当拒否、shift交代、端末電池切れ、AP断、server再起動、job取消、優先度変更、車両故障を含めます。baselineとPoCを同じtimestamp定義で比較しなければ、改善率は作れません。

PoCの合否はSLOと業務結果を分ける

例として、通常補給callの90%を60秒以内にacknowledge、一つの定義zoneで荷準備済みcallの95%を8分以内にarrival、再送後の未解決duplicate active jobを0件、監査可能なackなしを12%から2%未満、p90を24分から14分へ、というgateを置けます。すべて本稿の架空例です。

通信latencyが短くても到着が遅ければ配車は改善していません。到着が速くても欠品や誤配送が増えればbusiness outcomeは悪化しています。次の四層を別々に判定します。

• 技術：delivery、latency、offline recovery、security、device health。
• workflow：ack、assignment、arrival、exception、closureの完全性。
• 現場：line待ち、走行の偏り、荷未準備、operator負荷、notification fatigue。
• 経営：停止回避、throughput、残業、在庫差、運用費、展開可能性。

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

RFPでは「リアルタイム」「簡単」「連携可能」といった形容詞を、試験できる文へ変えます。

業務・機能

• 七状態と許可transition、取消、再配車、優先度変更、manual overrideを提示する。
• 一意job IDとevent historyを保持し、誰がいつ何を変更したかexportできる。
• role/zone/shift/資格/車両能力からcandidateを絞り、理由を説明できる。
• dashboardは未受付、未割当、SLO超過、offline call pointを区別する。
• Thai/Japanese/Englishなどsite言語で、短く誤解のないoperator表示を提供する。

非機能・運用

• availability、latency、batteryは測定窓、分母、planned maintenance、degraded modeを含めて提案する。
• offline buffer、最大保持、overflow、再送、deduplication、順序逆転を定義する。
• backup/restore、monitoring、incident、patch、certificate renewal、log retention、support languageを定義する。
• 端末交換、call point移設、zone/master変更を現地担当が行える範囲を示す。
• license、device、SIM/network、cloud/on-prem、integration、support、更新を5年TCOで分ける。

安全・責任境界

• 本systemが安全機能でないこと、既存の交通対策と緊急経路を置き換えないことを明記する。
• PLC/controlへwriteする範囲はread-only monitoringから分離し、承認とrollbackを設ける。
• vendor、工場物流、製造、IT/OT、EHS、保全のRACIを提出する。
• subcontractor、cloud region、remote access、data ownership、契約終了時exportを開示する。

FATで確認すること

FATはfactory floorを完全再現する場ではなく、logic、interface、異常系を再現可能なtest evidenceにする場です。versionを固定したtest environmentで、次を実行します。

1. 全request typeと全許可transition、禁止transition。
2. 同一buttonの連打、同一API requestの10回再送、out-of-order event。
3. primary dispatcher不在、assignment拒否、timeout escalation、manual override。
4. gateway断、broker断、WMS/MES timeout、端末offline、復旧後reconciliation。
5. role違反、期限切れcertificate、無効token、退職者account、log改ざん検知。
6. dashboardとCSV/API exportが元eventと一致すること。

FAT合格は現場安全やnetwork coverageの合格ではありません。simulatorの条件、未試験項目、known limitationを記録し、SATへ移します。

SATで確認すること

SATでは実際のzone、rack、door、shift、vehicle、accessory、Wi-Fi、WMS/MES、operatorを使います。通常稼働だけでなく、昼休み、shift交代、混雑、荷未準備、blind corner付近の運用、network planned interruptionを安全計画の下で確認します。

arrivalの証拠がbuttonなら押し忘れ、BLE/geofenceなら誤検知、barcodeならscan負担を測ります。system表示と現物状態がずれたときのauthoritative sourceを決めます。安全機能の試験は資格を持つ責任者と承認済み手順で別途行い、dispatch SATのチェックで代用しません。

受入成果物には、as-built diagram、IP/port、account/role、certificate一覧、master、backup、restore test、training record、SOP、incident/escalation、保守連絡、license、source/config export条件を含めます。画面が動くことだけを検収にしないでください。

BuyかDoかを決める比較表

選定demoには自社の例外scenarioとsample dataを渡し、vendor操作ではなく現場supervisorに操作してもらいます。点数表は機能数ではなく、必須scenarioの完遂、証跡、復旧、5年TCO、現地保守で重み付けします。

展開時はzoneごとの標準化率を管理する

PoCから全工場へ一括展開すると、場所名、request type、priority rule、車両masterが拠点ごとに増殖します。global templateとlocal extensionを分け、共通KPIのtimestamp定義は固定します。一方、交通ルール、言語、shift、車両、network、法令・EHS要求はsite差を認めます。

pilot zoneで合格しても、長距離yard、冷凍庫、危険場所、屋外、請負運転者へ自動展開しません。zoneごとにreadiness checklistを通し、call pointと車両を一度に増やしすぎず、support capacityと一緒に拡大します。

FAQ

フォークリフト 呼び出しシステムとは何ですか？

作業者や設備から搬送要求を受け、受付、配車、到着、配送、完了を追跡するworkflowです。単なるベルや通知アプリと違い、担当責任と待ち時間をeventとして残します。ただし衝突防止装置や安全制御ではありません。

工場 呼び出しベルは無線化するだけで十分ですか？

呼出範囲が小さく、一人が必ず応答するなら改善になる場合があります。しかし待ち時間削減と監査が目的なら、job ID、ack、assignment、arrival、exception、KPIが必要です。通信方式より先に状態と責任を定義してください。

作業者 呼び出し 通知は誰へ送るべきですか？

全員ではなく、role、zone、shift、資格、車両能力、現在の負荷から候補を絞ります。一次担当が時間内に受けないときだけ段階的にescalateし、通知疲れを防ぎます。

リアルタイム 通知 製造現場の「リアルタイム」は何秒ですか？

普遍的な秒数はありません。業務riskとbaselineからSLOを決めます。本稿の「90%を60秒以内にack」は通常補給の架空例で、緊急用途や全工場の標準ではありません。測定開始・終了と除外条件をRFPへ書きます。

現場 連絡手段 効率化の効果はどう計算しますか？

各jobのevent時刻から実待ち時間を合計し、同じ範囲・時間帯でbaselineと比較します。中央値に件数を掛けて総時間を作らないでください。解放時間は、その後に生産増や残業回避へ再配置できた範囲だけ金額化します。

30日PoCの費用はどのように見積もりますか？

call point、端末、gateway/network、workflow設定、WMS/MES連携、security、現地作業、training、support、撤去・本番移行を分けます。2 zone・3 call point・2 shift・120 callは本稿の例であり、現地調査後に再見積りします。

フォークリフトの安全装置も同時に置き換えられますか？

いいえ。呼出・配車systemは業務調整用です。衝突防止、警笛、警告灯、歩車分離、spotter、交通ルール、教育、緊急通信を置き換えません。安全対策はsite risk assessmentとEHS承認の下で別に設計・検証します。

まとめ

フォークリフト 呼び出しシステムの価値は、ベルをデジタル化することではなく、搬送要求を七状態で追い、誰が引き受け、いつ到着し、どの例外で遅れたかを改善可能なdataへ変えることです。応答確認を配信成功と混同せず、配車条件、KPIの分母、offline recovery、ERP/WMS/MES/OTの正本、安全境界をRFPに書いてください。30日PoCでは小さな範囲で多くの例外を試し、FATでlogic、SATで現場条件を検証すると、Buy/Doの判断を数字と証跡で行えます。

タイ工場で呼出点、配車rule、WMS/MES連携、30日PoCの範囲を整理する段階から相談できます。既存の交通ルールと安全対策を維持したまま、現状計測とRFP/FAT/SATの受入基準を作りたい場合は、TOMAS TECHへお問い合わせください。