最初に結論から：タスクインターリービングは、どんなWMSにもあるフォークリフト効率化機能の中で最も安く、投資回収が最も速い。このアイデア全体は1文に収まる——フォークリフトが荷を下ろしたら、空で戻らない。システムがその降ろし場の近くで次の作業を見つけて、その場で渡す。私は30件以上の導入でこれを展開してきた。20,000パレットの倉庫がこれをオンにすると、2週間後には空走行が35–45%から約20%まで下がる。
「インターリービング」とは実際何か
まず用語を定義して、曖昧さをなくそう。フォークリフトの走行には2種類ある。積載走行と空走行だ。空走行とは、空フォークでの移動すべて——集荷地点への移動、荷下ろし後の帰路だ。私が測定したどの倉庫でも、空走行はフォークリフト総走行の30–45%を占める。運転手はシフトの3分の1を空のフォークリフトを運転して過ごしている。
インターリービングは「降ろし」と「拾い」を1つのトリップに縫い合わせる。フォークリフトがロケーションAでパレットを格納する。システムは200メートル先のロケーションBで補充タスクが待っているのを見て、その同じ車両に割り当てる。運転手は帰り道に立ち寄る。空走行が積載走行に変わる。
しかしここで冷水を浴びせる——そしてこの記事全体で最も直感に反するポイントだが：インターリービングは「タスクが多いほど良い」ゲームではない。タスクプールが浅いと、インターリービングは空回りする。 倉庫が1日に数百件のタスクしか生成せず、どの運転手にもすでに待ち行列がある場合、システムは「ついで」のペアを組めない。インターリービングエンジンはほとんどの時間何も見つけられず、ゼロの成果のために計算資源を燃やす。大規模倉庫の5分の1の物量の小規模倉庫がこの機能を無理やりオンにしたのを見た。空走行は2ポイント下がり、運転手はタスクが飛び回ると文句を言った。私の経験則：シフトのインターリーブ対象タスクプールが300未満なら、この機能にはまだ手を出すな。まずタスクリリースのリズムを直せ。
設定プレイブック：タスクインターリービングを4ステップで
ステップ1：事前チェック（何も有効化する前に4つすべてを確認）
- すべてのフォークリフトにライブ端末が必要だ。車載端末でも運転手のハンディ端末でも構わないが、リアルタイムでオンラインでなければならない。インターリーブされたタスクは運転手にプッシュされる。まだ無線や紙でディスパッチしているなら、インターリービングはスタート地点にすら立てない。ハードゲートだ。
- タスク種別を棚卸しする。倉庫内のフォークリフトタスクをすべて列挙し、どれがインターリーブできるかフラグを立てる。格納（putaway）、補充、フルパレットピック、構内移動がコアの4つだ。クロスドックと返品検査は厳密な順序依存がある——除外する。
- WMSのタスクエンジンが「タスクチェーン」または「オポチュニスティックディスパッチ」をサポートしているか確認する。ベンダーによって呼び名は違うが、ロジックが存在しなければならない。タスクAの終了時に、システムがその終端近くのタスクBを同一設備向けに探す。それがなければ土台がない。
- 1週間のベースラインを取る。スイッチを入れる前に、3つの数字を取って保存する。空走行率、平均タスクサイクルタイム、タスク競合率だ。これが、2週間後にこの機能が元を取ったことの唯一の証拠になる。ベースラインなしに証明なし。
ステップ2：インターリーブのルールを設定する（核心部分）
ルールは通常、WMS設定の「タスク管理」または「リソーススケジューリング」の下にある。次の4つの軸をそれぞれ設定する。
- タスク種別ホワイトリスト：格納（putaway）、補充、フルパレットピック、構内移動のみにチェックを入れる。インターリーブ対象のタスクは2つの条件を同時に満たさなければならない——定義された開始点と終了点があること、厳密な順序依存がないこと。
- インターリーブ距離半径：タスクAの終了からタスクBの開始までの許容最大距離。初回導入では300メートルを推奨する。広すぎると、運転手が節約した空走行以上に迂回する。狭すぎるとマッチングがまったく成立しない。2週間後にこの数字を見直す——最初はきつめに、後で緩める。
- 優先度ウェイト：ウェーブタスクとカットオフが重要なオーダーはインターリービングより上位でなければならない。1つのルールをハードコーディングする。インターリービングが高優先度タスクからリソースを奪わないこと。緊急作業が先に捌かれる。インターリービングは残りのタスクプールに対してマッチングする。
- インターリーブ時間ウィンドウ：タスクBの計画開始は、タスクAの予想完了の前後15分以内でなければならない。広すぎると、運転手がBに着いたときにタスクがまだリリースされておらず——待たされる。狭すぎるとマッチ率が急落する。15分が初期値だ。
ステップ3：パイロットする（初日から倉庫全体でオンにしない）
- 1つのゾーンと2台のフォークリフトを選び、3日間走らせる。タスク密度が最も高いゾーンを選ぶ——インターリービングは密度を餌に育つ。
- 毎晩、3つの数字をチェックする。空走行は下がったか、平均タスク時間は長くなったか、競合率（同一ロケーションや同一パレットに2台の運転手がディスパッチされた率）は跳ね上がったか。
- 競合が出た瞬間に、距離半径か時間ウィンドウを締める。詳細は以下。
ステップ4：本展開
パイロットの数字が基準をクリアしたら（空走行が10ポイント以上低下、競合は横ばい）、倉庫全体に展開する。本展開の最初の週はダッシュボードを毎日チェックする。2週目からは通常の週次レポートに組み込む。
プロジェクト事例1：空走行42%から21%へ、2週間で
2024年秋、消費財の3PL：40,000パレットポジション、3シフトで28台のフォークリフト。導入前の測定：空走行42%、運転手は1時間あたり平均5.2タスク。現場責任者の言葉そのまま：「フォークリフトは人より忙しいのに、貨物が一向に速く動かない」。
上記の4ステップを実行し、物量最大のゾーンBでパイロットした。1週目：空走行は44%から31%に落ちた。2週目の全館展開後、約21%で安定した。平均タスク時間は11.5分から9.8分に下がった——時間も下がったことに注目してほしい。運転手が無意味な走行をやめたからだ。
1つ課題があった。運転手から「タスクが飛び回りすぎる」と苦情が出た。根本原因：時間ウィンドウを30分に設定していたため、システムが「便利そうで、実は待たされる」タスクを割り当て続けていた。ウィンドウを15分に締めたら苦情は止んだ。覚えておこう：運転手の気持ちはダッシュボードと同じくらい大事だ。現場が嫌えば、その機能はいずれ切られる。
プロジェクト事例2：緩いルール、倉庫中でフォークリフトが喧嘩
別のプロジェクト、2025年初頭、ピークシーズンを控えたECの出荷準備倉庫。クライアントは300メートル半径を「保守的すぎる」と言い、初日から800メートルに変更し、時間ウィンドウ45分にした。翌朝のシフト：3台のフォークリフトが同じ補充ゾーンにディスパッチされ、2つのパレットを奪い合い、通路を40分間塞いだ。別の車両は「便利な」タスクのために600メートル迂回した——空で戻るより遅かった。
私の修正方法：その場で半径を300メートルに、ウィンドウを15分に戻し、新ルールを1つ追加——任意の15分間に同一通路でインターリーブタスクに入れるフォークリフトは1台のみ。通路はその日のうちに解消した。この失敗は3回見てきたが、いつも同じせっかちさだ。「初日から完璧に設定する」。インターリービングの鉄則：最初はきつめに、後で緩める。 常に保守的に始め、データが裏付けてから開く。
これが破綻する最も多い3つのパターン
上の事例の「初日マキシマリズム」に加え、それぞれ3回以上見てきた失敗があと3つある。
- インターリービングを万能薬扱いする。 スロッティングがめちゃくちゃな倉庫——速い商品が奥深くに埋まり、補充ゾーンとピックゾーンが倉庫の両端にある——がインターリービングをオンにすると、システムは「便利な」タスクを勤勉に割り当て、それらはすべて無駄な走行になる。まずスロッティングを直して、それからインターリーブだ。順序が大事。
- 端末のレイテンシ。 ある現場は5年落ちの車載端末で、ディスパッチの遅延が1分近くあった。運転手が古いタスクに向かって半分進んだところで新しいタスクが飛び出す——運転手は気づく。インターリービングを有効化する前に、タスクプッシュのレイテンシを測ること。10秒を超えるなら、まずハードウェアを更新せよ。
- 誰もダッシュボードを見ない。 機能はオンだが、誰もレポートを見ないので、実質的にはオフだ。最初の1ヶ月は、誰かが空走行カーブと競合率を毎週レビューしなければならない。パラメータは調整するもので、設定して忘れるものではない。
ゴーライブ前夜チェックリスト：7つすべてにチェックが入るまで寝るな
- ホワイトリストは4つのタスク種別のみ——クロスドックや返品検査が混ざっていない
- 距離半径は300メートル以下、時間ウィンドウは15分以下（初回導入の値）
- 高優先度タスク（ウェーブ、カットオフ）に明示的なプリエンプションルールがある
- パイロット範囲が定義されている：1ゾーン、2台、3日間
- ベースラインを保存済み：空走行率、タスクサイクルタイム、競合率
- 運転手に説明済み：端末上のインターリーブタスク表示がどんな見た目か知っている
- ロールバックを確認済み：インターリービングをオフにして通常ディスパッチに戻せる（10分以内）
最後に正直な一言：タスクインターリービングはマネジメントの問題を直さない——実行を増幅するだけだ。タスクリリースがカオスでスロッティングが壊れた倉庫では、インターリービングはフォークリフトを間違ったルートで速く走らせるだけだ。まず基礎を正せ。そうすればインターリービングは、あの失われた20%を取り戻すスイッチになる。
Lin Xiao（WMS導入コンサルタント）著
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
