昨秋、私はカリフォルニア州インランド・エンパイアの3PL倉庫（約120,000平方フィート）のコンサルをしていた。そこではAIによる補充予測モデルを導入したばかりだった。受入検査書にはサイン済み。ベンダーのチームは3週目に撤収した。そして96日目、倉庫マネージャーから電話があった。「Lao Miさん、システムが壊れたみたいです。補充の提案が週を追うごとに滅茶苦茶になってきています。」
私は3つ質問した。先週のモデル予測精度は？彼は知らなかった。アラートメールはどこに届く？確認しに行った――そして、ベンダーのプロジェクトチームが設定したメールボックスに今も届き続けていることが分かった。そのチームは2カ月前に解散していた。アラートは誰も開かない受信ボックスに届き続けていた。3つ目の質問：ドリフトの閾値は誰が決めた？電話の向こうは沈黙だった。
これは珍しい話ではない。ここ数年、同じ死に方をするAIプロジェクトをいくつか見てきた。選定フェーズでも開発フェーズでもなく、Go-Live後の3カ月で死ぬのだ。設備を受け入れるとき、フォークリフトが勝手に車線変更することはない。AIは違う。毎日新しいデータを食べ、データが変わればモデルも変わる。誰も見ていなければ、3カ月後にあなたが「所有」している「AIシステム」は、もはやあなたがサインしたものではない。
Go-Liveの日は、プロジェクトで最もリスクの高い日
直感に反する見方をしよう。AIプロジェクトにとって、受入サインは終わりではなく始まりだ。
受入テストは静的な条件で行われる。データはベンダーが事前にきれいに整え、テストセットは厳選され、シーズンミックスは手選びだ。受入指標をよく見せたいのは当然だ――最終支払いがかかっている。不誠実なのではない、人間の性だ。
だが実データが流れ始めると、すべてが変わる。新規顧客が新しい注文パターンを持ち込む。SKUミックスが変わる。包装仕様が切り替わる。繁忙期と閑散期が入れ替わる。これが、学習時にモデルが一度も見たことのない「汚いデータ」だ。ある倉庫では、受入時の予測精度92%が2カ月後には78%に落ちたのを私は見た。原因はほとんど笑い話だった：学習データにQ4繁忙期のSKU組み合わせが入っておらず、繁忙期に突入した途端、モデルが滅茶苦茶な推測を始めたのだ。
だから私の結論は単刀直入だ。受入基準には90日後の再テスト条項を入れなければならない。サインは2回――Go-Live時にシステムが動いていることを確認するサインと、90日目に実データ相手でもモデルが持ちこたえていることを確認するサインだ。2回目のテストに落ちたら、最終支払いは保留のまま、ベンダーが戻ってきてチューニングする。契約の1条項は、受入当日の追加指標10個より効く。
これを要求するのを怖がる買い手は多い。ベンダーが不信感の表れと受け取ると心配するのだ。私は逆だと思う。この条項にサインできるベンダーは、自社のモデルを本当に信じているベンダーだ。
モデルは突然死しない。ゆっくりバカになる。
これが、AI運用と従来のIT運用の最大の違いだ。サーバーダウンは突然だ――アラームが鳴り、全員が気づく。モデルドリフトは慢性疾患だ。今日少し悪く、明日少し悪く、3カ月後には気づけば静かに役立たずになっている。
ドリフトは平たく言えば2種類だ。1つ目はデータが変わった：以前は1日8,000件出荷していたのが、今は12,000件になった。顧客Aが以前は出荷量の60%を占めていたのに、今は顧客Bが支配的だ。モデルは古いデータのパターンを学習し、新しいデータはそれに従わない。2つ目は関係性が変わった：「週末は忙しい」がかつては正しかったのに、顧客の注文習慣が変わって週末は静かになった。データそのものは同じに見えるのに、データの「意味」が動いたのだ。
怖いのはドリフト自体ではない――誰も見ていないことだ。インランド・エンパイアの倉庫では、システムが何週間もアラートを送り続けていた。ドリフト指標はすでに閾値を超えていた。だがアラートは誰も読まない受信ボックスに届いていた。それはアラートがないのと同じだ。これが私の言う運用の空白だ。システムは喋っているのに、誰も聞いていない。
どう埋めるか。責任分担表は受入前に決めなければならず、実名で書かなければならない――「顧客の責任」では通用しない。私は3層を推奨する。
倉庫オペレーションは日次で業務指標を見る。予測品質を誰よりも早く肌で感じるのはオペレーションだ――補充提案が的外れになれば、ピッカーが最初に文句を言う。シンプルなルールを1つ与えよう：提案数量が現実と3日連続で一定の比率以上に乖離したら、エスカレーションする。アルゴリズムの知識はいらない。数字を読むだけだ。
IT――またはベンダー――は週次でモデル指標を見る。ドリフトスコア、特徴量分布、予測の信頼度。何を見ているか分かる人が必要だ。社内にその人がいなければ、契約でベンダーのリモートモデルサポートを買いなさい。四半期払いで構わない。ここはケチってはいけない。省けば、既に使った何十万も水の泡になる。
マネジメントは月次でトレンドをレビューする。精度カーブは上がっているか下がっているか？再学習にいくらかかり、元は取れたか？30分で十分だが、会議はやらなければならない。さもなければ四半期レビューで、モデルが3カ月も壊れていたことを知る。手遅れだ。
ドリフトの閾値は誰が決めるか？私の答え：ベンダーが提案し、買い手が決める。ベンダーはモデルを知り、何が正常な変動かを知っている。買い手はビジネスを知り、どの程度の誤差が許されないかを知っている。一緒に決め、SOPに書き、壁に貼り出すのだ。
契約にない引継ぎは、なかったことになる
これは私が落ちた一番深い落とし穴だ。ある倉庫のAI外観検査プロジェクトでは、契約書に「ベンダーはトレーニングを提供する」と書いてあった。受入前にベンダーは確かにトレーニングを提供した――2時間のスライドだった。3カ月後にモデルが暴れ、オペレーションエンジニアは特徴量パイプラインがどこにあるのかすら知らなかった。データはどのテーブルから来て、モデルファイルはどのサーバーにあるのか――3つの質問に答えはゼロだった。ベンダーに電話した。プロジェクトチームは消えていた。サポート担当は「有償サポートチケットを切れます」と言った。
だから今では、買い手に受入サインの前に引継ぎチェックリストを1項目ずつ確認させる。4項目だ。1つでも欠けたらサインしない。
1つ目、モデル文書。特徴量リスト、学習データのバージョン、モデリングの前提――「SKU数は一定と仮定」「注文構造は安定と仮定」といった類のものだ。これらの前提は将来のドリフト警告線になる。前提が崩れた瞬間、モデルは再学習が必要だ。文書は立派である必要はない。読めればいい。
2つ目、アラート設定。誰がアラートを受け、誰がCCに入り、どの頻度でレビューし、誰がエスカレーションするか。メールアドレスを1つ1つ書き出し、受入当日にテストアラートを送って届くことを確認する。笑わないでほしい――アラートアドレスのスペルミスが、Go-Live後に発覚したプロジェクトを見たことがある。
3つ目、再学習プロセス。誰が再学習を発動し、発動条件は何で、誰が実行し、誰が払うか。再学習は無料ではない――データ準備、計算、検証、すべて金がかかる。前もって決めなければ、壊れたときに両者が責任のなすりつけ合いを始める。4カ月も争いが続いたケースを見た。モデルは4カ月間、ただ腐っていった。
4つ目、ロールバック計画。モデルが暴れたとき、ワンスイッチで旧ルールエンジンに戻すにはどうするか。スイッチはどこにあり、誰に切る権限があり、切った後ビジネスはどう回すのか。これが一番よく省略されるが、トラブル時には命綱になる。
契約にはあと2条項が必要だ。チーム撤収後6カ月から12カ月のベンダーリモートサポート、応答時間を明記したもの。そしてデータの所有権――学習データ、モデルファイル、特徴量パイプライン――買い手はその全部の完全なコピーをもらう。ベンダーは去っていい。資産は残る。
結論を言おう。AIプロジェクトが設備の購入と違うのは根本的に1点だ。設備は一度きりの納品だが、AIは進化し続けるものだ。あなたが受け入れるのは機械ではない。継続的に餌を与えなければならない生き物だ。契約に「誰が餌をやるか」が書いていなければ、餓死するのは時間の問題だ。
最後に1つ問いを残そう。あなたのAIプロジェクトが明日Go-Liveしたら、90日目のアラートメールが誰の受信ボックスに届くか――そしてそれを開く責任は誰にあるか、名前を挙げられるか？挙げられないなら、受入書にまだサインしてはいけない。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
