製造業の工程間搬送指示システム導入｜依頼から受入までの設計と選定

製造業で工程間搬送指示システムを導入するとき、台車を速く走らせることだけを目的にすると、実際の停滞は残ります。前工程が「出した」と言い、後工程が「まだ受け取っていない」と言う。その間にある仕掛品の所在、責任者、品目・ロット・数量、次の行き先が同じ取引として記録されていないからです。本稿では、人手搬送、台車、AGVが混在する工場を想定し、「搬送依頼→引取→現品照合→引渡→受入→完了」という状態を設計の中心に置きます。誤搬送と受入漏れをどう防ぐか、MES・ERP・WMSの境界をどう決めるか、RFPからFAT/SATで何を検証するかを具体的に整理します。

工程間搬送指示システムが扱う仕事の境界

工程ルートマスタは製品がどの工程を通るかを定義します。AGV制御は車両の走行や停止を扱います。WIPロットの分割・統合は系譜と数量の整合を扱います。工程間搬送指示システムが中心に据えるべきものは、その間にある「この現品を、この数量で、この場所からあの受入先へ渡す」という業務取引です。搬送手段を変えても、依頼、引取、照合、引渡、受入、完了の証跡が一貫して残ることが重要です。

たとえばプレス工程から組立工程に仕掛品コンテナを送る場合、前工程の作業完了だけで搬送完了とは言えません。運搬担当者が引き取っただけでも、まだ組立工程の在庫とは限りません。組立側が現品ラベルと受入先を確認して受け入れ、必要ならMESの工程投入可能状態に反映して初めて業務が閉じます。この「受入確認」を抜くと、現場では置き場に物があるのにシステム上は移動中、あるいはシステム上は受入済みなのに物が届かないという乖離が起こります。

ISA-95は製造オペレーション管理と企業業務の情報交換を整理する参照枠組みです。GS1は識別と可視化イベントの標準を提供します。ただし両者が本稿の六つの搬送状態、画面、承認者を義務付けているわけではありません。以下の状態モデルやチェック項目は、これらの考え方を踏まえた導入設計の提案です。既存の工程ルートマスタ設計とWIPロット分割・統合管理は、それぞれ前後の業務との接点として参照してください。

最初に決める「搬送単位」と識別子

搬送依頼の単位を曖昧にしたまま端末やスキャナを選ぶと、後から数量差異を説明できなくなります。品目だけで依頼するのか、製造オーダーとロットまで指定するのか、コンテナ単位で一意に追うのか。品質保留や期限管理が厳しい品目では、少なくともロットと現品容器の識別が必要です。個品追跡が必要な製品なら、シリアル番号まで要求します。一方、全品を個品化するとラベル、スキャン、照合作業が増えるため、対象品目のリスクと工程の粒度に合わせます。

推奨する搬送依頼IDは、ERPの伝票番号やAGVジョブ番号とは別に、再試行しても同じ業務取引を指せる不変IDです。明細には品目、製造オーダー、ロット、容器ID、要求数量と単位、出発場所、受入場所、希望時刻、優先度、理由、品質状態を持たせます。容器を途中で交換したときは「IDを上書き」せず、元容器と新容器の対応イベントを残します。部分搬送があるなら依頼ヘッダーと複数の明細・搬送実行を分け、合計数量の保存を検証します。

GS1の識別キーやアプリケーション識別子を使う場合は、既存ラベルとの整合を先に確認します。GS1はGTIN、ロット、物流単位などの識別を支援しますが、工場内だけで使うすべての容器IDにGS1キーを採用する必要があるという意味ではありません。重要なのは、読み取り値がどの名前空間に属し、他システムのどのキーに対応するかを一意に定義することです。ラベル破損、再印刷、空容器再利用の運用もデータ設計に含めます。

六つの状態と責任の移り方

搬送状態は単なる進捗表示ではありません。誰が、どの証拠をもって次の状態へ進めるかを決める契約です。現場の例外を含めて、次のように設計します。

この順序は全工場で固定という意味ではありません。送り元で先に現品照合し、その後に引取する現場もあります。その場合は状態遷移を実態に合わせ、どの時点で誰が物理的な責任を持つかを明示します。重要なのは、引渡と受入を同一クリックにしないことです。無人受入が必要なら、受入センサーや場所スキャンなど代替証拠と例外処理を定義します。AGVの走行完了イベントを受入完了と同一視する設計は、現品が所定位置にあり、受入側で使えることまで保証できる場合に限ります。

状態遷移で防ぐべき誤搬送

誤搬送の多くは、端末が「スキャン成功」と表示したのに、業務上の組合せを照合していないところで起きます。容器IDが存在するだけでは足りません。依頼IDにひもづく品目・ロット・数量、現在位置、目的地、品質状態、許可された工程ルートを同時に照合します。品質保留中の仕掛品は、搬送そのものを禁止するのか、隔離エリアへの移動だけ許可するのかを品質部門と決めます。品質保留管理と整合しない独自フラグを作ると、解除のタイミングで二重管理になります。

推奨する防止ルールは、①予定外の容器は引取を拒否、②出発地が不一致なら監督者確認、③受入地点が不一致なら引渡を拒否、④品質状態が変化したら再照合、⑤数量差異は理由コードと承認を要求、⑥同じ容器に進行中の搬送が二つある場合は新規依頼を止める、の六つです。スキャンを省略できる例外は「速いから」ではなく、ラベル読取不能など理由と代替照合方法を指定します。解除者、時刻、前後値を監査ログに残します。

人手、台車、AGVで共通にするのは業務取引IDと現品IDです。AGV側の配車IDや走行状態は搬送実行の付随情報として関連付けます。車両が故障して人手に切り替えても、依頼を二重作成しないようにします。別車両へ再割当したときも、旧ジョブの取消を確認した後に新ジョブを発行し、両方が同じ容器を運ぶ指示にならないよう排他を設けます。

依頼、引取、引渡、受入の画面は何を見せるか

送り元画面には「何を・いくつ・どこへ・いつまでに」を一画面で示します。現場が自由記述で行き先を打つ設計は、名称揺れと誤選択を招きます。ルートマスタから候補を絞り、停止中の工程や満杯の受入棚は選択不可または注意表示にします。ただしルートマスタは「通過可能な工程」、搬送指示は「今回実際にどこへ渡すか」であり、同じデータを二重編集するべきではありません。

引取画面は作業者が手袋で使うことを想定し、スキャン結果、対象容器の写真や形状情報、数量、現在地、受入先、例外理由を大きく表示します。バーコードが読めないときの手入力は権限付きとし、入力したIDの再確認を求めます。電波が弱い場所ではオフライン許容範囲を事前に決めます。端末に「受信済み」と出てもサーバー側で確定していないなら、状態を完了に見せてはいけません。

受入画面は「届いた物」だけでなく「届くはずの物」と差異を並べます。容器スキャンだけで自動受入にすると、数量欠けや破損が見逃されます。受入者は一致、部分受入、拒否、保留を選べるようにし、差異は送り元と品質・在庫担当への通知につなぎます。受入後の工程投入は、受入確認と品質解放の両方が満たされたときに可能にする設計が安全です。実際の権限や画面項目は現場の責任分界に合わせて決めます。

滞留の可視化は「場所」と「次に動く人」を示す

搬送中の件数を数えるだけでは、改善につながりません。依頼済みで引取待ち、引取済みで移動中、引渡済みで受入待ち、受入済みでERP/MES反映待ちという滞留理由を分けます。各段階に所有者、最後のイベント時刻、次の処置、期限を表示します。たとえば引渡後30分を超えた容器を一律に赤くしても、夜勤で受入担当がいない工程と、稼働中なのに見落としている工程では対処が違います。

まず現場で許容時間を工程・品目・シフトごとに決めます。タイマーは「依頼からの総時間」だけでなく、状態ごとの滞在時間を持たせます。ダッシュボードには件数のほか、依頼から受入までの中央値・上位分位、部分受入件数、行き先差戻し件数、ラベル読取失敗率、例外承認率を表示します。これらは導入効果の測定候補であり、どの工場でも同じ数値改善を保証するものではありません。初期の実測値を基準に目標を決めます。

イベント履歴には、ID、時刻、場所、作業者または設備、状態、数量、例外理由、端末時刻とサーバー受信時刻を保存します。GS1 EPCISが示す「何が、いつ、どこで、なぜ」の考え方は履歴設計の参考になります。EPCIS準拠を名乗るなら、実際のイベント構造と語彙まで適合を確認する必要があります。本稿のイベント項目を使うだけで自動的に準拠するわけではありません。

ERP・MES・WMS・搬送実行の責任分界

システム境界は、製品名ではなく「どの事実を誰が正とするか」で決めます。ERPは製造オーダーや会計・計画上の在庫、MESは工程実績・WIPの現場状態、WMSは保管場所と入出庫、搬送実行は台車・人・AGVの割当と移動に強みがあります。しかし既存システムの機能範囲は工場ごとに違います。ISA-95のレベル3/4の整理を手掛かりに、実際の正本と更新タイミングを一枚の表に落とします。

ERP、MES、WMSの全てに「搬送完了」を同時に書くと、通信障害時にどれが正か分からなくなります。推奨は、受入イベントを正本で確定し、外部システムにはイベントID付きで通知する方式です。相手側が同じイベントIDを二度受けても二重計上しない冪等処理を持たせます。受信失敗は再送キューに残し、再送の上限と手動復旧手順を決めます。ERP在庫の移動をいつ確定するかは、会計・棚卸の要件に左右されるため、受入前か受入後かを関係部門と承認します。

連携項目表にはシステム名だけでなく、キー、データ型、必須条件、イベント発火点、重複時の動き、順序逆転、取消、時刻帯、監視責任者まで書きます。タイと日本など複数拠点で運用するなら、保存時刻はUTCなど一つの基準に正規化し、画面で現地時刻を表示します。日付をまたぐ夜勤、サーバー遅延、端末の時刻ずれはFAT/SATで試験します。ネットワーク断の後に古いイベントが遅れて届いても、完了済み取引が「引取」に戻らないよう、状態の版番号を使います。

人手・台車・AGVを一つの業務モデルで扱う

自動化の段階にかかわらず、同じ依頼モデルを使うと、搬送手段を変更しても現品の追跡が途切れません。人手搬送では担当者と端末が引取・引渡を記録します。台車搬送では台車IDも記録します。AGV搬送では配車システムにジョブを発行し、車両の到着通知を搬送指示システムの状態に対応付けます。どの場合も受入側の確認は別イベントです。

AGVの走行経路、障害物回避、安全制御は車両・フリートシステム側の責務です。搬送指示システムが同じロジックを実装すると、経路変更や安全停止の判断が分裂します。一方、AGV側は製造オーダーや品質保留の意味を知らないことがあります。搬送指示システムが対象現品と目的地を確定し、AGV側には必要最小限のジョブを渡す境界が明快です。台車や人に切り替える場合のジョブ取消、引継ぎ、重複搬送防止を共同で試験します。

搬送手段の最適化は、この業務の土台が整った後の拡張です。まず「依頼から受入までが閉じる」「誰が詰まっているか分かる」「誤った現品が進めない」を達成し、その上で配車や順序最適化を検討します。設備投資の大きなAGVを先に入れる場合でも、受入確認と例外処理を要件から外さないことが重要です。

例外処理を仕様の中心に置く

実運用では、依頼取消、急ぎの行き先変更、容器のラベル剥がれ、数量差、混載、部分引渡、品質保留への切替、設備故障が起こります。通常フローだけのデモではこれらの処理能力が分かりません。各例外について「発生可能な状態」「許可者」「現品の物理置き場」「システムの戻し方」「関連システムへの通知」を表にします。進行中の依頼を消すのではなく、取消イベントと理由を残します。

特に引渡済みで受入拒否になった現品の扱いを決めます。送り元へ戻すのか、隔離棚に置くのか、品質判定を待つのか。戻す場合も、元依頼を未実行に書き換えるのではなく、戻し搬送を別取引として関連付ける方が履歴を説明しやすくなります。数量が不足したら、受入済み数量と未着数量を分け、残数の再搬送か差異確定かを選択できるようにします。混載を許す場合は容器単位の照合を省略せず、積載単位と内訳の関連を保存します。

通信障害時は、端末がローカルに記録できる操作と、サーバー確認が必要な操作を分けます。オフラインで引取を許すなら、同じ容器を別端末がオンラインで引き取れない保証が難しくなります。ネットワークの実態に応じ、オフラインは参照だけ、あるいは限定エリアで単一端末に限るなど安全側の設計を選びます。復旧後は重複・順序逆転・時刻ずれを自動検出し、要確認キューに入れます。現場判断で強制完了できる権限は最小化し、理由と承認を必須にします。

RFPに書くべき機能要件と非機能要件

取引データ契約を先に合意する

画面見積の前に、搬送依頼を他システムへ渡すデータ契約のサンプルを作ると、後からの手戻りを減らせます。依頼ID、イベントID、依頼版番号、出発地、到着地、現品識別子、予定数量、実績数量、単位、品質状態、発生時刻、記録時刻、理由コード、関連する元依頼IDを一つの例に入れます。各キーに対し、生成元、変更できるシステム、桁数、空値の扱いを決めます。たとえば「場所」は画面表示名ではなく不変の場所IDで交換し、名称は言語別マスタから表示する方式にします。これならタイ語と英語で棚の名称が違っても同じ場所を指せます。

もう一つの論点は、一つの依頼に複数容器が載る場合です。依頼全体の状態を単純に「完了」にすると、一部だけ未着でも隠れてしまいます。ヘッダーには「全明細受入済み」「部分受入」「差異処理中」を集約表示し、容器明細ごとの状態を残します。残数量は予定から実績を機械的に差し引くだけでなく、廃棄・返品・再計量など承認済みの調整を反映します。単位換算が必要なら、換算率と適用版を保存します。容器重量を製品数量と混同しないため、正味数量と容器数も分けます。

イベントを訂正するときは元イベントを消してはいけません。誤スキャンや二重送信を特定し、取消イベントに対象イベントIDと理由を持たせます。監査画面には現在値だけでなく、元の報告、訂正、承認、外部システムへの反映を時系列で見せます。個人情報に当たる作業者IDの閲覧範囲や保存期間は、現地の社内規程に合わせて決めます。ここで述べる項目は実装の推奨例であり、業種別の規制適合を保証するものではありません。

RFPでは「搬送を見える化したい」という表現だけでは比較できません。対象工程、品目、1日当たりの依頼件数、ピーク同時処理数、容器の種類、手段別比率、拠点、言語、無線LANの範囲、既存システム、ラベル規格を提示します。その上でベンダーに、状態遷移図、画面案、連携方式、例外処理、導入範囲、データ移行、運用体制を具体的に回答してもらいます。

機能要件は①依頼作成と重複抑止、②現品照合、③引取・引渡・受入の記録、④部分数量・混載、⑤品質保留との連携、⑥滞留と通知、⑦人手・台車・AGV切替、⑧監査履歴、⑨権限・承認、⑩ERP/MES/WMS連携を最低限の比較軸にします。各項目を「標準機能」「設定」「追加開発」「外部製品」で回答させ、デモで実際に操作を見ます。画面の多言語化だけでなく、マスタ名称、例外理由、通知文、手順書が現場の使用言語に対応するかも確かめます。

非機能要件には、ピーク時の画面応答、スキャンから状態確定までの時間、可用性、再送の回復時間、監査ログ保持期間、権限分離、バックアップ、脆弱性対応、端末紛失時の失効を含めます。目標値は工場の業務停止許容時間から逆算し、RFPに明記します。一般論として「リアルタイム」「高可用」と書くだけでは検収できません。クラウドか構内かの構成は通信制約、保守体制、データ保管要件を踏まえて決めます。導入価格は端末、ラベル、無線、連携、教育、保守を含む総費用で比較します。

FAT・SATで「動く」だけでなく「閉じる」を確認する

FAT（工場受入前の試験）では、予定された状態遷移と、禁止すべき遷移の両方を試します。正しい容器が正しい受入先へ届く基本ケースに加え、別ロットのスキャン、品質保留中の引取、二重引取、数量不足、行き先変更、部分受入、受入拒否、AGVジョブ失敗、通知の再送を試験票にします。試験データに依頼ID、容器ID、ロット、数量、場所、期待状態、期待イベントを含めると、画面表示だけでなくデータの整合まで確認できます。

SAT（現地受入試験）では、実際の作業者、台車、スキャナ、無線環境、シフト、既存システムを使います。ラックの死角や金属容器で読取が難しい場所、夜勤、ネットワーク瞬断、端末電池切れを含めます。受入場所の物理標識とシステムの場所マスタが一致しているかも重要です。訓練済みの担当者だけが成功する試験では定着を判断できないため、新任者が手順書を見て例外を処理できるか確認します。

検収基準は「全画面が開く」ではなく、たとえば「誤ロットを引取できない」「受入拒否後に在庫が増えない」「同一受入イベントの再送で数量が二重計上されない」「搬送途中の品質保留変更が反映される」といった業務結果で表現します。合否を出せない項目は、仕様が曖昧な可能性があります。ベンダーと発注側で期待結果を先に合意します。

導入順序と効果測定

初期導入は、全工場一斉よりも、誤搬送または滞留の影響が大きく、かつ受入先が限定された一つの工程間から始めるのが管理しやすいでしょう。現状調査では紙票、電話、口頭依頼、WIP棚、ERP/MES/WMSの更新タイミングを現品に沿って追います。現状の依頼件数、受入までの時間、誤行き先、探索時間、未完了依頼を実測し、導入後と比較できる基準を作ります。

次に搬送単位と場所IDを決め、ラベルの読取テストをします。状態遷移と例外表を現場・品質・倉庫・ITで合意し、連携表を作ります。試行ではまず人手・台車のフローを安定させ、その後AGVとの接続を追加できます。ただしAGVが現場の主手段なら、最初からジョブ失敗と手動切替を試験範囲に含めます。導入後は未完了取引を毎日確認し、差異の理由を分類してルールを調整します。

効果は「搬送時間が何％短縮」と先に約束するより、基準値と測定方法を固定してから判断します。依頼から引取、引取から引渡、引渡から受入の時間を別々に測ります。再スキャン率や例外率が初期に上がっても、隠れていた差異が見えるようになった結果かもしれません。記録が定着した段階で、滞留時間、誤搬送、探索工数、ライン停止など本来の指標を評価します。ダッシュボードの数字を毎週レビューし、運用変更の責任者を決めます。

現場ヒアリングで確認する具体的な場面

仕様を決める会議では、システム画面だけを見て議論せず、仕掛品一つを選んで前工程の出口から後工程の受入棚まで歩いて確認します。送り元の完了時刻、現品ラベルの貼付位置、容器の積み方、台車の待機場所、搬送依頼を誰が発行するか、引取担当がどこで現品を見つけるか、受入者が何を確認しているかを記録します。紙の付箋や口頭の「急ぎ」が実際の優先順位を変えているなら、その判断条件と承認者も聞きます。夜勤、休憩、設備停止時に同じ手順が通るか、担当者を替えて確かめます。

その上で、直近に起きた一件の差異を時系列で再現します。たとえば、コンテナは組立棚にあったのにMESでは前工程に残っていたケースなら、どの時点で物理状態とシステム状態が分かれたかを調べます。前工程が出荷扱いにしただけなのか、運搬者が別棚に置いたのか、受入スキャンが通信断で保留されたのかで、必要な対策は変わります。「作業者の入力ミス」で一括りにせず、画面の候補選択、場所ID、端末通信、責任移転の設計に原因がないかを見るべきです。

ヒアリング票には、工程・場所・シフトごとに、通常時の流れ、例外時の逃げ道、許可者、記録に使う媒体、後で照合する帳票、未完了案件を誰が閉じるかを並べます。設計レビューではこの票から「依頼者は確定したが現品が準備されていない」「引取後に品質保留が掛かった」「受入担当が不在」「ラベルが読めず手入力した」「AGVが到着したが棚が満杯」などを試験シナリオに変換します。実際の現品と作業を起点に要件を書くことで、設備連携はできたのに業務取引が閉じない、という導入失敗を避けやすくなります。

費用対効果の試算でも、この現場観察が基準になります。手書きの依頼票作成や現品探索の時間は工数として測れますが、誤搬送の発生頻度が低い場合に架空の削減率を置くべきではありません。差異の再発を防ぐ仕組みとして、工程停止や品質隔離の回避可能性を定性的に評価し、観測可能な指標と分けて投資判断に載せます。導入範囲外の工程に問題が移る可能性も追跡し、試行区域だけの見かけの改善にしないようにします。

よくある質問

工程間搬送の指示管理はMESだけでできますか？

できますが、MESの機能と運用範囲次第です。MESが搬送依頼ID、現品照合、引取・引渡・受入、例外、監査履歴、外部連携を持てるなら、専用製品を増やさずMES内で実装する選択があります。搬送手段の配車や倉庫横断の仕事が広い場合は別システムが適することもあります。製品名より正本と責任分界で判断してください。

仕掛品の搬送依頼と在庫移動は同じですか？

同じとは限りません。搬送依頼は物理的な移動の要求と状態、在庫移動は場所や勘定上の数量変更です。引取時に在庫を移すか、受入時に移すかは会計・棚卸・品質の要件で決めます。途中で失敗した際の取消・戻しも設計に含めます。

搬送完了の現品照合はどこで行いますか？

推奨は送り元での引取照合と受入先での再照合です。前者は誤った容器の持出しを防ぎ、後者は誤った場所への置き去りと数量差を検出します。無人受入の場合は、場所スキャンや設備センサーなど代替証拠の信頼性を試験して決めます。

AGVを導入していなくても必要ですか？

必要性は誤搬送、探索、滞留、受入漏れの程度で決まります。人手や台車だけの工場でも、依頼と現品を結ぶ記録が無ければ同じ問題が起きます。先に業務モデルを整えれば、将来AGVを接続しやすくなります。

RFPとFAT/SATで特に重視する項目は何ですか？

正常な搬送画面よりも、重複、数量差、品質保留、受入拒否、通信断、再送を重視してください。これらが業務を止めず、しかも履歴と在庫を壊さず処理できるかが運用の分かれ目です。期待結果を依頼IDとイベント単位で試験票に書きます。

まとめ

工程間搬送指示システムの導入では、搬送手段より先に、現品を一意に識別し、依頼から受入までの責任移転を設計することが重要です。引渡と受入を分け、誤ロット・誤行き先・品質保留を状態遷移で止める。滞留は場所だけでなく、次に動く担当者と期限まで見せる。ERP・MES・WMS・AGVの各システムには正本と通知先を明示し、重複・再送・失敗から復旧できるようにする。RFPとFAT/SATでは、正常系だけでなく例外の業務結果を検収します。

現在の紙票、MES、WMS、AGVの構成でどこから着手すべきか検討中であれば、TOMAS TECHへのお問い合わせで工程間の現品・状態・連携境界を一緒に整理できます。構想段階での相談でも構いません。

参考情報と設計上の位置付け

• ISA, ISA-95 Series of Standards：企業業務と製造オペレーション管理の境界・情報交換の参照枠組み。六状態の指定ではありません。
• ISA, Business-to-Manufacturing Transactions：レベル3/4間の取引モデルの説明。
• GS1, EPCIS：現品のイベントをwhat/when/where/whyで扱う考え方。
• GS1, Global Traceability Standard：追跡対象の識別粒度を決めるための参照。
• GS1, Application Identifiers：ラベルのデータ要素と意味。
• OMG, BPMN 2.0：部門をまたぐ業務過程を記述する標準。具体的な搬送画面や閾値は規定しません。

本稿の状態、照合ルール、KPI、RFP・試験項目は導入時の推奨設計であり、各標準がそのまま義務付ける仕様や、特定工場で実証済みの改善率ではありません。