まず結論から言う：自動倉庫（ASRS）とAMRを統合する際——いわゆるASRSとAMRの連携において——痛みの90%は、両者の「継ぎ目」にある。タスクの受け渡しがどこで行われるか、タスクを最初に知るのは誰か、タクトが合わないときに誰が待つかだ。この三つを間違えれば、クレーンがどれだけ速かろうが、ロボットを何台買おうが、入庫ドックは詰まる。話は二面ある。ひとつは物理面——受け渡しポイントをどこに置き、バッファをどれだけ持つか。もうひとつは情報面——WCSとAMRのディスパッチャーの間で、誰が誰を指揮するかだ。物理の失敗は安く直せる。情報の失敗は数ヶ月の手戻りを招く。
簡単に言うと、ASRSとAMRの機体は気質が真逆だ。ASRSは頑固者——クレーンはメトロノームのようなタクトで固定の通路を走り、単位時間あたり運ぶパレット数は決まっていて、ひとつも多くは運ばない。AMRは自由人——走り回り、よけ、並ぶが、渋滞が生まれた途端タクトが乱れる。メトロノームと自由人を結婚させるというのは、それぞれを速くすることでは決してない。同じリズムで出会わせることだ。
私が経験した落とし穴：ASRS入庫ドックの40メートル
2022年11月、中国・蘇州の自動車部品倉庫：四通路のスタッカークレーン式ASRS、入庫を支えるAMRが12台。受け入れの数値は素晴らしく見えた——クレーンあたり90パレット/時、AMRは無積載で1.8 m/s。稼働開始の初週、入庫ドックが詰まった。AMRが入庫コンベヤの前で列をなした——最大8台が待ち、最長で11分間立ち往生した。そしてクレーンは？時間の半分はアイドル状態で、パレットが届かない空っぽのドックを眺めていた。
原因は受け渡し設計だった。AMRはパレットを入庫コンベヤに置いたが、コンベヤのバッファはわずか3パレット。埋まれば、その後ろのAMRは全員ただ待つだけ。一方でWCSは入庫タスクを2–3分の遅延で発行していた——AMRは到着済みなのに、WCSがまだクレーンに回収を指示していない。片側は物理のボトルネック（バッファ3パレット）、もう片側は情報の遅延（タスク到着の遅れ）。12台のAMR機体は、本来の能力の約60%しか発揮できなかった。
救済は三つの手だった。まず、入庫バッファを3から8パレットに拡張——バッファは無駄ではなく、異なるタクトを翻訳する翻訳機だ。次に事前発番（プリディスパッチ）：AMRが受け渡しポイントの2分前まで来たら、WCSが入庫タスクを早めにクレーンに割り当て、パレット着地後の割り当てではなく先回りして待たせる。三つ目はAMR側の予約キュー——同じドック行きのロボットを事前に順序づけ、8台が同じ一点に殺到しないようにした。AMRの待ち時間は11分から40秒未満に、クレーンの稼働率は52%から88%に改善した。
間違ったところにお金を使うプロジェクトを、私は何度も見てきた：AMRが足りなければロボットを足す、ASRSが遅ければクレーンを速くする。ボトルネックは継ぎ目にあって、機械本体にはない。
ASRSとAMRの連携の二面：物理と情報の受け渡し
物理面は一枚の表に収まる——ASRSとAMRの連携における受け渡しチェックリストだ。
| 要素 | 設計ポイント | よくある失敗 | 私ならこう仕様化する |
|---|---|---|---|
| 受け渡し場所 | 入庫・出庫それぞれに専用の受け渡しステーションを設け、本線から切り離す | AMRが本線コンベヤに直接ドッキングする | 専用ステーション＋バッファゾーンで本線から分離 |
| バッファ深さ | タクト差×ばらつき係数でサイズを決める | 「見た目」の2–3パレット | 6–10パレット、少なくとも5分間の変動を吸収 |
| タクト整合 | 遅い側に合わせる | 速い側に合わせて遅い側に急かせる | 遅い側がタクトを決め、速い側は15%の余裕を持つ |
| 例外処理 | 受け渡し失敗は自動で手動ステーションにフォールバック | 技術者が来るまでデッドロック | 3分のタイムアウト後に自動で手動へ迂回＋アラーム |
| 安全分離 | AMRゾーンとクレーン通路口の堅固な分離 | 黄色い塗装ラインだけ | 物理ガード＋ライトカーテン、AMRは2 m離す |
情報面はWCS対AMRディスパッチャーの分担——そしてASRSとAMRの連携で最も手戻りしやすい部分だ。 私のルールは一文：WCSが決めるのは貨物がどこへ行くか、AMRディスパッチャーが決めるのは車両がどう行くか——両者はタスクのステータスのみを交換し、命令は出し合わない。WCSは「パレットAをドック1からポイントBへ移動せよ」と発行し、ディスパッチャーがロボット・ルート・回避を自律的に選ぶ。ステータスコールバックは四状態、少なくともこれが必要だ：受領、ピックアップ完了、納品完了、例外。最も致命的なパターンは、両者が自分をボスだと思い込むこと——WCSが各AMRの経路を逐一操縦しようとし、ディスパッチャーが勝手にタスクの優先度を変える。喧嘩して、現場はデッドロックする。
ではタクトが合わないとき、誰が待つのか？トレードオフだが、答えはこうだ：安い資産が、高い資産を待つ。 クレーンは数百万円級、AMRはその何分の一——だからAMRが待つ。例外はひとつ：AMR機体がボトルネックの場合（たとえば6台のロボットが4通路を支える）だ。その場合は逆にしてクレーンを落とす。なぜなら、並んだロボットより、数百万円のクレーンのアイドルの方が高いからだ。計算してみる：クレーンの一時間の停止——減価償却、エネルギー、失われたスループット——は、AMRの約50往復分に相当する。まずボトルネックを特定してから、誰が待つかを決める。勘で決めてはいけない。
二つ目の落とし穴：出庫の「ゴーストタスク」
2024年3月、米中西部の3PL：シャトル式ASRSがAMRに供給し、put-to-wall仕分けを行う。入庫より出庫の方がやっかいだった。WCSは回収タスクを発行し、AMRはもう走り始め、そこでカスタマーサービスが注文をキャンセルした。シャトルはパレットを出庫ドックに運び、AMRも到着したが、貨物の受け手がいない——ゴーストタスクだ。ピーク時には一日に40パレット以上の孤児パレットが溜まり、出庫バッファが埋まって、正規の出庫移動がその後ろで詰まった。
根本原因は同じ——情報の継ぎ目だ。キャンセルはWMSには届いたが、WCSにもAMRディスパッチャーにも伝わらなかった。対策：ディスパッチャーとWCSの間でタスク有効性チェックを入れる——AMRがピックアップする30秒前にタスクがまだ有効か確認し、無効ならキャンセルしてロボットを空で待機エリアに戻す。チェックはAPIコール一回、数十ミリ秒だ。それを省いた代償は、孤児パレット40個と一日三十分の片付けだった。稼働後、ゴーストタスクは一日40以上から3未満に減った（残りは30秒の窓内でキャンセルされたもので、許容できる損失だ）。
締めの一文
ASRSとAMRを結婚させる際の、直感に反する真実はこうだ：ボトルネックは車輪にもレールにもなく、情報が早く届くか遅く届くかにある。 並ぶAMR、アイドルのクレーン、ゴーストタスク——どれも結局は「知るべき人が知らなかった」という話だ。ロボットを増やす、クレーンを速くする、バッファを広げる、と話す前に、受け渡しの情報の流れを描け。順番を間違えれば、お金は消える。
Lao Mi（サプライチェーンのベテラン、20年）著
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
