倉庫アラートのエスカレーションを正しく：SMSは重大アラート専用

結論から先に：WMSや自動化の本番稼働（go-live）では、四段階のアラート階層を設定してください——Tier 1（SMS＋電話）、Tier 2（WeComオンコールグループでの@メンション）、Tier 3（通常のWeComメッセージ）、Tier 4（メールダイジェスト）——対応SLAはそれぞれ5分、30分、4時間、翌日です。「全部SMSで送る」方式を三回見ました。三回ともアラート疲れで死にました。オンコール担当は47通目で読むのをやめ、48通目が本物の火事でした。

アラート階層化は運用の問題ではなく実装の問題

多くのプロジェクトはアラートを「本番後に運用が何とかするもの」と扱い、実装コンサルタントは去っていきます。30回以上のgo-liveを経て、はっきり言います。**アラートルールはUAT中に確定させなければなりません。**階層化はインシデント対応プロセスを定義するもので、インシデント対応は署名されるWMSブループリントの一部だからです。

November 2023、中国・深圳の越境ECクライアント、本番稼働から二か月目。深夜2:14、統合キューが滞留し始めたため在庫フリーズのアラートが発報しました——しかしメールのみでした。当直のスーパーバイザーはおやすみモードをオンにしており、メールは受信トレイで未読のまま。朝8時までに、在庫がフリーズしているため2,000件以上の注文が出荷できなくなりました。カスタマーサービスはパンク。直接損害：その日だけで約18,000件が出荷できず、平均注文単価$22——マーケットプレイスの遅延出荷ペナルティを除いても、一日で約$400,000の売上が消えました。この失敗は三回見ました。毎回「アラートは発報したのに、誰も見ていなかった」のです。

ここが直感に反する点です。**見落としアラートの90%はチャネルの問題ではなく階層化の問題です。**逆の極端な例も見ました——米国東部の3PLでは、コールドチェーンの温度プローブが測定値のふらつきのたびにSMSを送り、一晩に60通以上。三日目にはオンコールマネージャーがアラート番号をブロックリストに入れました。アラートが多すぎることは、アラートが無いことと同じです。階層化はオンコール担当の注意力を守るために存在し、本当に命取りになる事象だけが彼らを起こすのです。

エスカレーション連鎖を構築する四ステップ

ステップ1：まず階層を定義——Tier 1のカテゴリーは五つまで

二つの軸だけで階層化します：影響範囲 × 不可逆的損害までの時間。Tier 1とは「今誰も動かなければ一時間以内に生産インシデントが発生する」ことです。私の標準的なクライアントテンプレートは次の通りです。

Tier 1のリストは短く保ってください。私の鉄則：**五カテゴリーまで。**五つを超えるということは、優先順位を区別できなかったということです。つまり、階層化していないのと同じです。

ステップ2：オンコールローテーションを作る——連続二週間を超えて当番させない

プライマリ＋バックアップのペア制にします。プライマリが対応し、バックアップはプライマリが10分以内に確認（acknowledge）しなかった場合にのみ電話を受けます。週次ローテーション、最長二週間。あるクライアントが一人に一か月連続でオンコールをさせていたのを見ました——三週目には対応時間が明らかに劣化していました。理由を聞くと、どのアラートも誤報だと思い込む癖がついていたとのこと。

ローテーションはシステム内に置かなければなりません。アラートプラットフォーム（WeComボット、SMSゲートウェイ）は日付に応じて当番者に自動でルーティングします。手動転送は禁止。手動転送は最大の単一障害点です——March 2024、中国東部の3PLではオンコールスーパーバイザーが休暇中。SMSは彼の携帯に届きましたが、彼は圏外の高速鉄道の中におり、バックアップは自分がバックアップであることすら知りませんでした。これはTier 1でした。AS/RSスタッカークレーンの故障でラインが3時間停止し、9,000ケースが出荷不足になりました。

ステップ3：エスカレーション連鎖を作る——タイムアウトで自動エスカレーション

これは最もスキップされがちで、最もあなたを救う可能性が高い部分です。ルールはシンプルです。

1. Tier 1発報。プライマリが5分以内にシステムで「確認」ボタンを押さなければ、自動でバックアップに電話。
2. さらに10分間確認がなければ、自動でオペレーションマネージャーに電話。
3. さらに15分間確認がなければ、ゼネラルマネージャーに直接電話し、WeCom管理グループで@全体にメンション。

すべてのエスカレーションを記録してください。誰が何時に確認し、何をしたか。記録は責めるためではなく、事後検証のためです。記録のないアラートプロセスは、次も同じ失敗をします。

ステップ4：go-live前夜のチェックリスト——アラートを機能としてテスト

これは私の持論で、毎回のgo-live前夜にやっていることです。

• 各Tier 1カテゴリーについて手動で発報させ、SMS＋電話が1分以内に当番の携帯に届くことを確認
• プライマリが出ない場合をシミュレートし、5分でバックアップへ自動エスカレーションされることを確認
• WeComボットのトークンが本番用であることを確認（テスト用ボットはテスト用グループに投稿します——go-live時に切り替え）
• SMSゲートウェイに残高があることを確認（笑いたければ笑ってください——三日目に残高切れでテキストが止まったクライアントがいました）
• ローテーションが今後4週間をカバーし、システムで正しくルーティングされることを確認
• Tier 4ダイジェストの宛先リストにクライアントのIT責任者が含まれていることを確認

三回以上見てきた三つの失敗パターン

**失敗パターン1：テスト用と本番用のアラートが混ざる。**テスターが深夜に負荷テストを行い、SMSアラートが大量発報。オンコール担当は三回起こされ、すべてのアラートをノイズとして扱い始めます。対策：テスト環境のアラートはWeComテストグループのみに送る。SMSチャネルには絶対に触れない。

**失敗パターン2：Tier 1リストが増え続ける。**go-liveから半年後、各部門がロビー活動を始めます。「うちのも重要だからTier 1にして」。半年後には20以上のTier 1カテゴリーができ、SMSチャネルは再び詰まります。対策：階層リストの変更はレビューを通す。プロジェクトを離れる前に、レビュープロセスを運用ハンドブックに書き込みます——Tier 1アラートの追加には、オペレーションマネージャーとIT責任者のダブル承認が必要です。

**失敗パターン3：打ちっぱなし。**アラートはシステム上「送信済み」と表示されるのに、SMSゲートウェイが30%を黙って落としていました。対策：毎月アラートの健全性チェックを行う——送信数 vs 到達数。到達率が95%を下回ったら？ゲートウェイを切り替えましょう。このチェックを月次運用会議のアジェンダに入れる。意志の力に頼らない。

計算してみましょう。この仕組み全体のコストは、小規模倉庫なら年間約RMB 5,000–8,000のSMSとプラットフォーム費用、大規模倉庫ならRMB 20,000–30,000です。深夜2時のTier 1アラート一件の見落としがもたらすのは、上の二つの事例が示した通り。一日で$400,000の売上が消えるか、3時間のライン停止で9,000ケースが出荷不足になるか。この計算はご自分でどうぞ。

実践的な学びを一つ：今まさにWMSの選定や実装をしているなら、「アラート階層化プラン」を契約の付属書に入れ、ブループリントと一緒に署名してください。深夜3時の電話で、誰もこれを決めていなかったと気づく前に。

Lin Xiao（WMS導入コンサルタント）著

英語版からの翻訳。内容に相違がある場合は英語版を優先します。