ちゃんと回るサイクルカウント: すべてを決めるのは2つの設定

結論から： サイクルカウントが倉庫で成功するかどうかは、どのWMSを買ったかとは関係ない。すべては2つの設定にかかっている：タスク生成ルール（何を、どの頻度で数えるか）と差異レビューのワークフロー（差異が出たときに誰が、どこまで調べるか）だ。設定を正しくやれば、パートタイムのカウント担当1人で精度を維持できる。設定を間違えると、フルタイムの担当が10人いても帳簿はぐちゃぐちゃのままになる。このまったく同じ失敗を私は3回見たが、毎回まったく同じ脚本だった。

年1回の全面棚卸しが行き詰まりの理由

多くの倉庫では今も年3日間シャットダウンし、扉を閉めて全部を数える。問題は残業代ではない。差異がそのままシステムに12か月も残り続けることだ。3月になくなったカートンが見つかるのは12月。その頃には前後の入出庫記録はとっくに消えている。再現できないものは調査できない。

サイクルカウントはこの発想を逆転させる。倉庫を小さく分割し、毎日少しずつ数える。1年かけてすべてのロケーションを何度も数え、差異は発生から数か月後ではなく数日後に見つかる。差異の発見が早いほど、調査コストは安い。これが鉄則だ。

ただし「毎日少しずつ数える」が機能するのは、ルールを正確に設定した場合だけだ。曖昧なルールは稼働開始から3週間で形が崩れる。

設定1: ABCカウント頻度

現実に耐える頻度テーブルはこうだ（例 — ABC分類は出庫金額基準。SKU数基準ではない）：

階層	目安	頻度	ロジック
A	出庫金額上位約20%のSKU	毎週	回転が速い。ミスは高くつく
B	中位約30%	毎月	ルーチンのカバレッジ
C	残り約50%のロングテール	四半期	低頻度のスポットチェック

実在の失敗から学んだ注意点3つ：

ABC分類は出庫金額基準、SKU数基準ではない。 かつてある倉庫がSKU数を3等分した。A階層は年2回しか動かないデッドストックで埋まり、毎日出荷する商品がBに落ちた。カウントの時間はすべて無駄になった。
ABCは四半期ごとに再計算する。 季節商品は動く。前期Q4のA商品が今期Q2のC商品になることもある。ABC再計算は手作業ではなく、WMSの定期ジョブにする。
新規SKUは最初の1か月はA階層に置く。 新商品のマスターデータはエラー率が最も高い（バーコード、梱包仕様、単位換算）。安定するまで徹底的に数え、その後格下げする。

ここからが意外な話：カウント頻度を上げても、在庫精度は上がらない。 カウントのたびにロケーションはロックされ、作業が止まる。A商品を毎日数えれば、毎日生産を止めることになる。あるプロジェクトの実測では、A階層を毎日→毎週に落としたところ、ピッカーの待ち時間が約40%減り、差異検出の遅れは数日だけだった。カウントは手段であって目的ではない。カウントで生産を止めてはならない。

設定2: タスク生成ルール — 7項目のチェックリスト

タスク生成ルールは3つの問いに答える。どのロケーションを、いつタスクを生成し、誰が実行するかだ。この7項目を順に設定すれば稼働できる：

タスクはロケーション＋SKU単位で生成する。パレット単位は不可。 混載パレットが普通だ。パレット単位のタスクでは、担当者がパレット全体を一瞥で確認してしまい、内部の差異は絶対に表に出ない。
タスクは固定時刻に生成する。シフト開始の1時間前。 シフト中の動的生成は厳禁。タスクの割り込みで全員のルートが崩れる。2時間おきに再生成するシステムを見たことがある。担当者は毎日4回ルートを組み直し、最後にはシステムを無視した。
同じロケーションのカウント間隔に最小間隔を設ける。 今週A階層のSKUを数えたら、来週まで再生成できない。タスクのアルゴリズムは怠け者だ。放っておけば楽なロケーションばかり配り続ける。
作業中のロケーションは自動スキップする。 未完了の入庫・ピッキングタスクがあるロケーションはスキップして翌日に回す。作業中のロケーションを数えれば、数は絶対に合わない。
階層別にブラインド／オープンを設定する： Aはブラインド（帳簿数量を表示しない。担当者が帳簿に「合わせる」のを防ぐ）、BとCはオープン（帳簿数量を表示。速度優先）。全面ブラインドは遅い。全面オープンは茶番だ。
1日のタスク量は実力に合わせる： タスク数＝人数 × 1人1日あたり実測ロケーション数 × 0.8。数値は自倉庫で測る。勘で決めない。再カウント用の20%の余裕を残す。
週末とピーク前3日間は自動で頻度を下げる。 大規模セール前は全員が荷揃えに追われる。そのタイミングでカウントタスクを出せば妨害行為だ。カレンダー例外をルールに組み込む。

このまったく同じ失敗を私は3回見た。2024年6月、蘇州郊外の自動車部品を扱う3PL倉庫は「全ロケーションを順番に回す」というルールでタスクを生成していた。システムは12,000ロケーションを1か月で勤勉に数えた。紙の上では見事だ。だがその12,000の中に埋もれた高速回転のAロケーションは、1日数十回転しているのに約30日に1回しか訪れなかった。差異は発見まで1か月寝かされ、差異率は3%を超えた。対策：「全面カバー」を捨て、上記のABCテーブルに切り替え、A階層は例外なく毎週。2か月後、差異率は1%以下に戻った。間違ったルールを勤勉に回せば、間違った結果が速く出るだけだ。

サイクルカウント作業中

設定3: 差異しきい値とレビューのワークフロー

差異を見つけることは問題ではない。すべての差異を同じ扱いにすることが問題だ。このテーブルをそのままコピーしよう（しきい値は例。商品の単価に合わせて調整）：

レベル	目安	アクション	レビュアー
L1 — 自動クリア	数量差異±1、かつ金額約$8未満	システムが自動調整・記録	なし
L2 — 本人再確認	数量差異±5以内、または金額約$80未満	当日その場で再カウント	カウント担当本人
L3 — 上長レビュー	L2超え、または同一SKUで月2回目の差異	別人がブラインド再カウント、移動履歴を確認	倉庫スーパーバイザー
L4 — 調査	金額約$800以上、または紛失・盗難の疑い	ロケーションを凍結、カメラ映像と書類を確認	倉庫マネージャー＋経理

大事な4点：

L1差異は自動クリアする。 バラピッキングの±1は毎日出る。これをいちいち人のレビューに回せば、3日でキューが詰まる。自動クリアは怠慢ではない、算数だ。調査の人件費が差異の価値を上回れば、赤字になる。
L3レビューは人を変える。 自分で数えて自分でレビューしてもレビューにならない。「レビュアー ≠ カウント担当本人」を回避不可のハードバリデーションにする。
差異理由はドロップダウンにする。「その他」禁止。 選択肢は少ない。マスターデータの誤り（バーコード／単位）、誤ロケーション入庫、ピッキング過不足、未報告の破損、システム不具合だ。「その他」を許すと3か月後には差異の80%が「その他」になる。何も教えてくれない。
カウント権限と調整権限は分離する。 カウント担当は数字を報告する。調整はレビュー後にスーパーバイザーが上げる。数えることも調整することもできる1人は、内部統制の穴だ。

2つ目の話：2025年3月、天津のEC倉庫はレベル分けなしでレビューしていた。すべての差異が1つのキューに。毎日400件超の差異。2人のレビュアーは夜明けから日没まで働き、すべてバラピッキングの±1ノイズ。実際のL3 — 売れ筋商品のフルカートン2箱消失、金額は5桁 — はキューで11日間放置され、カメラ映像の保存期限が切れた。対策は上記のテーブルだ。L1自動クリアの後、1日のキューは400件超から30件未満に減り、レビュアーはようやく大事なことに時間を使えた。蘇州、天津、そして2023年の寧波。3回とも、まったく同じ脚本だった：問題は人ではなかった。ルールだった。