結論から言うと、倉庫ビジョンAIがデプロイ後に精度を落とすとき、本当の問題はモデルであることはほとんどない。本当の問題はモデルを取り巻くすべてだ——光、カメラ、データ、そして新バージョンの出し方である。
この場面を私は何度も見てきた。ベンダーはノートPCでデモをする。学習データでは精度99%、プロジェクターにはきれいなグラフが映り、部屋中が拍手する。稼働から2か月後、現場の精度は90%台前半まで下がり、作業員はすべての注文を手で再チェックし、上司は金がどこへ消えたのか知りたがる。ベンダーは肩をすくめる。「現場の条件が変わりました」。
学習データでの精度は持ち込み不可の試験だ。本番は持ち込み可の試験で、誰かがずっと照明を点けたり消したりしている。
根本原因を一つずつ見ていこう。まず光。倉庫の光は決してじっとしていない。ドックのドアが開いて日光がコンベアに当たる。夜勤は昼勤とは違う照明で働く。秋になれば太陽の角度が変わり、6月に問題なく動いていたステーションが突然グレアだらけになる。ある公開事例をよく覚えている。Jetson Orinのハードウェアで動くビジョン検査システムはラボで99.8%を記録したが、デプロイ後に誤検出が15–20%に急増した——原因は窓から差し込む日光で、金属部品の反射が欠陥に見えたことだった。段ボール、テープ、ストレッチフィルム——倉庫の表面はすべて鏡だ。これからは誰も逃れられない。
二つ目はカメラが動くこと。フォークリフトが取付ブラケットにぶつかって角度が数度ずれる。3か月でレンズにほこりが積もる。コンベアの振動で画像がにじむ。数度と聞くと些細に思えるが、位置決めや計数をするモデルにとって、新しい角度は実質的に新しいデータセットだ。
三つ目は商品が変わること。新しいSKUが入ってきて、ブランドが箱の色を変え、ロゴがリニューアルされ、ストレッチフィルムが透明から黒に切り替わる——どれも学習データには入っていない。四つ目は、もっと陰険で、本番の前処理が学習時と一致していないことだ。モデルは正規化された画像で学習したのに、エンジニアが数ミリ秒のレイテンシを削るために正規化ステップを省いた。こうした学習-サービングのスキューはエラーを出さない。静かに精度を食い続けるだけだ。
五つ目は、アルゴリズムチームでさえ見落とすことが多い点だ。ラベル自体がドリフトする。同じ品質検査チームでも、「この傷は欠陥に数えるか」の判断は1月と7月で異なる。モデルは動く標的から学習しているのだ。
まとめるとこうだ。モデルが悪くなったのではない。世界が変わったのだ。そしてほとんどの倉庫ビジョンのデプロイは、変わる世界にまったく備えていない。
モデルのバージョン管理はスロッティングと同じように
まず醜い習慣から直そう。プロジェクトが多すぎると、モデル管理とはmodel_final_v2_real_final.pthが入ったフォルダのことだ。それを学習したデータセットは？ハイパーパラメータは？前処理は変わっていないか？誰も答えられない。何かが壊れてロールバックしたい——ロールバック先とは、正確にはどこなのか？
バージョン管理には譲れないルールが一つある。本番に出たことのあるモデルはすべて完全に再現可能でなければならない。バージョン番号は三つのものを結びつける——データセットのバージョン、コードのバージョン、そしてハイパーパラメータと乱数のシードだ。学習データは不変のアーティファクトとしてスナップショットされ、後から誰も触らない。どれか一つでも欠ければ、何かが壊れた日にどのリンクが変わったのか推測する羽目になる。
データセットのスナップショットを大げさにせず取るには？簡単だ。学習のたびに学習セットのファイル一覧とハッシュ値を保存し、サンプリング比率と拡張手法を学習ログに書き込む。「このバージョンは何で学習したのか」と聞かれて3分で答えられれば合格だ。答えられないチームは迷信でデバッグすることになる。
二つ目の生き残り条件はロールバックだ。ビジョンモデルのイテレーションの標準はワンクリックのロールバック。悪い新バージョンは数分で直近の安定版に差し替えられる——再学習なし、コード変更なしだ。これができなければ、イテレーションなど語ってはいけない。精度が崩壊した恐怖の話を見てみろ。災害の正体は「新バージョンが悪かった」ことではなく、「新バージョンが悪かったのに戻り道がなかった」ことであることが多い。だから現場は壊れたモデルで何週間も回り続けたのだ。
次はデプロイ戦略の判断で、私の見解をはっきり言う。業界標準の三つのパターンがある。シャドーモード、カナリアデプロイ、ブルーグリーンデプロイだ。シャドーモードは新モデルを旧モデルと並べて本番トラフィックで動かす——新モデルの出力はログに記録されるが、実際に使われることはない。リスクはゼロで、「本番トラフィックでこのモデルがどう振る舞うか」に答えるための専用手段だ。カナリアデプロイは新モデルに本番トラフィックの一部——たとえば1週間5%——を処理させ、問題がなければ20%、50%、100%と段階的に引き上げる。被害範囲を小さく保てる。ブルーグリーンデプロイは二つの完全な環境を瞬時に切り替える方式で、カメラモデルの変更や前処理の大改修といった「切り替えなければならない」場面に向いている。
倉庫ビジョンに対する私の推奨はこうだ。標準ルートはシャドー2週間、その後カナリアで引き上げる。シャドーを飛ばしてカナリアに直行してはいけない——カナリアが処理する注文はすべて本物のビジネスで、品質検査の誤判定一つが誤出荷一つになる。シャドーの誤った予測はログの一行にすぎない。順序が大事なのだ。
そのシャドーの2週間も遊んでいるわけではない。三つの数字を見る。新モデルと旧モデルの不一致率、不一致が集中するSKU、そして高確信サンプルで新モデルが明らかに安定しているかだ。不一致率が高いままカナリアに進めば、目隠しで飛ぶようなものだ。カナリア中は技術指標だけでなくビジネス指標を見る。再チェックの人手は減ったか、誤出荷率は動いたか。技術指標は良いのにビジネス指標が横ばいのアップグレードは、アップグレードではない。ただの変更だ。
アラートが多すぎるのはアラートがゼロと同じこと
稼働後の第二の戦場は監視だ。多くのプロジェクトは稼働日にピークを迎える。モデルが腐り始めたことに誰も気づかないからだ。運用チームが異常を感じた頃には、モデルはすでに2か月劣化し続けている。
まず正しい指標を見ること。誤検出率と検出漏れ率は別々に追わなければならない。燃える金の種類が違うからだ。誤検出は人件費を燃やす。モデルが存在しない問題を指摘し、指摘された注文はすべて誰かが手を止めて再チェックする。誤検出率を上げすぎれば、作業員はシステムを無視し始める——AI投資は最初から死んでいる。検出漏れは本物の現金を燃やす。不良品がすり抜けて顧客に出荷され、返品とチャージバックになる。「総合精度」だけのダッシュボードは自己欺瞞だ。精度95%のモデルは、誤検出2.5%＋検出漏れ2.5%かもしれないし、4.5%と0.5%かもしれない。これはまったく別の二つのビジネスだ。
「壊れた」の四つの種類も区別する必要がある。データドリフト（入力が変わった——照明、新しい包装）、予測ドリフト（モデルの出力分布が変わった）、コンセプトドリフト（入力と答えの関係自体が変わった——たとえば品質基準が厳しくなった）、そして単なるエンジニアリングのバグ（特徴量パイプラインが落ちた）だ。原因が違えば対処も違う。精度が下がった瞬間に「データを増やして再学習」に飛びつくのは、十中八九間違った病気を治療している。カメラが傾いているなら、100回再学習しても何も変わらない。
最後にアラート疲れだ。最もよくある死に方なので、あえて挙げる。しきい値を緩くしすぎれば、腐りかけのモデルは誰にも警告しない。厳しくしすぎれば、当番の人は1日に何十件ものアラートを受け取り、読まずに一括却下し始める。私の経験では、アラートは二階層まで。それ以上は要らない。一層目：精度がベースラインを割り込んだ。今日対応する。二層目：トレンドが悪化している。今週中に見る。三階層以上のアラート設計は、実質アラート設計がないのと同じだ。
終わりに大げさな理論はいらない。明日からできることを一つだけ。
今日から、システムに本番画像を保存させ、毎日100枚をランダムに抽出し、人間が再チェックして、誤検出と検出漏れが何件あったかを記録する。これを2週間続ける。手に入るのは、このプロジェクト全体で最も価値のある資産だ。現場からの真の精度曲線である。バージョン管理も、カナリアリリースも、アラートのしきい値も、すべてはこの曲線があって初めて機能する。これがなければ、調整するパラメータはすべて推測だ。
この業界で勝つのは、最も精度の高いモデルを持つチームではない。自分のモデルが精度を失ったことを最初に知るチームだ。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
