2024 年春、ダラス郊外の 3PL のオペレーションマネージャーが、ドローン搭載型 AI 在庫システムの契約にサインした。デモは見事だった。ラックの上を滑るように進むドローン、自動で生成される差異レポート。彼は年間サブスクリプションにサインした。そして現実がやってきた。倉庫は 10 年落ちの WMS で動いており、IT が必要としたカスタムデータインターフェースは、すでに 2 四半期先まで埋まっていた。契約書の「認識精度」はベンダー自身のテストセットで測られたもので、パレットとバラ箱が混在するゾーンでテストした者は誰もいなかった。システムがたった 1 つのデータソースにも接続しないまま、1 年分のサブスクリプション料金が消えていった。
技術は悪くなかった。オーナーが間違っていたのだ。
私はこの映画を、反対側からも見てきた。中規模倉庫の受入検査用ビジョン AI システムという、IT 主導のプロジェクトだ。IT ディレクターは教科書どおりにやった。ベンダー 3 社を呼び、精度・レイテンシ・API プロトコルのスペックシートを比較し、ラボ数値が最良の 1 社を選んだ。彼が一度もしなかったのは、受入ドックを現場クルーと一緒に歩くことだった。本物の倉庫では、ラックの照明がまぶしく反射し、ラベルは斜めに貼られ、シュリンクフィルムは光を捉える。そんなことはスペックシートには載っていない。初週から、誤検知でクルーの検証時間は 2 倍になった。受入リーダーは「スキャナガンの方が速い」とはっきり言った。2、3 か月のうちに、夜勤はシステムの電源を入れなくなった。
倉庫 AI についての不快な真実はこうだ。難しかったのはモデルではなかった。3 つの問いだ——データはどこから来るのか、「正しい」の定義は誰が決めるのか、結果の責任は誰が取るのか。IT だけでは 3 つ全部に答えられない。現場だけでも 3 つ全部に答えられない。2024 年に公表された RAND のレポート「The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed」によると、AI プロジェクトの 80 パーセント以上が期待された価値を届けられず、その根源は多くの場合アルゴリズムではなく組織とデータにあるという。
誰よりも金を使える Amazon ですら、アルゴリズムだけでループを閉じさせない。2024 年 6 月、同社は Project P.I.（"private investigator"）を発表した。北米の複数のフルフィルメントセンターにある画像トンネルで、生成 AI とコンピュータビジョンを組み合わせ、出荷前に破損品や色・サイズ違いを検出するシステムだ。重要なポイントはこうだ。システムがフラグを立てた商品は Amazon のアソシエイトがレビューし、値引きするか、寄付するか、そのまま流すかを決める。最終判断は人間が下す。Amazon が機械だけに倉庫を任せないなら、50 人規模の 3PL がそれを試みるべきではないのは明らかだ。
IT 主導の罠と現場主導の罠は、同じ罠だ
2 つの失敗モードは正反対に見えるが、失敗する理由は同じだ。建物の一方が、両方を必要とする意思決定を独占している。
IT が単独でオーナーになると、技術のおもちゃが生まれる。デモは拍手を浴びるが、現場はそれを迂回する。IT は測れるものを評価する——きれいなデータでの精度、稼働率、統合工数——そして、定着を決めるものを軽視する。ラック 3 段目の反射、午前 2 時にもクルーが実際に従うプロセス、第 4 四半期に商品ミックスが変わったときにモデルを再学習するのは誰か。
現場が単独でオーナーになると、プロジェクト不在の発注書が生まれる。現場は痛みを完璧に説明できるが、納品までの道筋を評価できない。ベンダーの営業はシステムを動かすためではなく、サインをもらうために報酬を得ている——そして現場主導の購買担当者は、レガシー WMS と接触した瞬間に崩壊するデモに最も簡単に魅了される、建物で一番の人物なのだ。
私が今すべてのクライアントに勧めている修正策は、ダブルリード体制だ。ビジネスリードとテクノロジーリードの 2 人が対等な立場で結果を共有する。書き出すまでは綺麗事に聞こえる。ビジネスリードは 3 つを担う。問題の定義（棚卸サイクルが遅いのか、差異が大きいのか——1 つを選べ）、データ作業のための人と時間の投入、効果の承認だ。テクノロジーリードは別の 3 つを担う。ベンダーとアーキテクチャの選定、WMS とハードウェアの統合、データセキュリティだ。真ん中の重なり——翻訳——は、省けないビジネスアナリストの役割に属する。
その BA は書類係ではない。2 つの言語を話せる人間だ。棚卸クルーと半日を過ごし、戻ってきて、あるラックの 3 段目が光を反射することをベンダーに技術用語で説明できる。ベンダーが「モデルには数千枚のラベル付き画像が必要」と言えば、「棚卸チームが 3 日を差し出す」に翻訳できる。ベテランのスーパーバイザーを昇格させるか、外部アドバイザーを雇え——この役割なしにプロジェクトを回すな。翻訳者がいなければ、IT と現場の会議は 2 つの独白だ。IT が無理なビジネス要求に屈するか、現場が誰も好まないツールに強制されるかのどちらかだ。
1 年を燃やさずにパイロットを回す方法
パイロットは軽く、だが固定で固めろ。BA を 1 人、プロジェクトにフルタイムで。IT 側のカウンターパートを 1 人、パートタイムで構わないが、毎週同じ人間であること。現場オペレーターを 2 人、期間中固定で、ローテーション禁止——パイロットを腐らせる最速の方法は、測定対象を変え続けることだ。そしてベンダーの導入スペシャリストを 1 人。ケイデンスは、毎週 30 分のスタンドアップで、扱うのは 3 つだけ——データが示したこと、詰まっていること、次にテストすること——と、トレンドを見る月 1 時間のレビューだ。私の経験則は、パイロットは 6〜8 週間で結論を出すこと。Go か no-go か。3 か月を超えて漂うパイロットはほぼ確実に静かに死ぬ。金も信頼も失って。
受け入れは、私が厳しくなるところだ。1 枚の紙に、2 つの署名欄。ビジネスリードは効果にサインする。本番環境で、本番シフトで、連続 2 週間、プロジェクト開始前に書き下ろしたミス率と誤警報の数値に到達すること。テクノロジーリードは技術面にサインする。安定したインターフェース、WMS へのデータ還流、アクセス制御の整備だ。署名が 1 つでも欠ければ、プロジェクトは終わっていない。そして受け入れ基準はキックオフ前に存在しなければならない——受け入れ当日に書かれた基準は、ベンダーが必ずパスする基準だ。
1 人か 2 人の倉庫でもできる
小規模事業者はこれを読んでこう思う。マネージャーは 2 人しかいないのに、どこからダブルリードを捻出するのか。答えはこうだ。小さいほど、体制は軽く——しかし同時に、より文字どおりに——しなければならない。
1 つの動きに煮詰めろ。翻訳者の役割を、名指しの 1 人に固定することだ。システムに最も敵対的でない倉庫スーパーバイザーか、実際に現場を歩く IT の人間を選べ。パイロット期間中の肩書き——この AI プロジェクトのビジネス側カウンターパート——と、1 日 1 時間の保護時間を与えろ。その 1 時間はソフトウェアライセンスより重要だ。なぜなら 10 回のうち 9 回、AI プロジェクトは「モデルが間違っていた」ではなく「現場の誰も協力しなかった」で死ぬからだ。
選定では、バンドルに抵抗しろ。痛みのポイントは 1 つだけに絞れ。棚卸差異、格納先検索、出荷検証のいずれかだ。ベンダーが追加モジュールを勧めてきたら、ノーと言え。契約書に入れる条項は 3 つだ。パイロット結果に連動した支払いと、パイロット失敗時の無条件撤退。データインターフェース作業とそのスケジュールを書面で添付すること。スーパーバイザーだけでなく、現場オペレーターへのトレーニング。そして厳しい受け入れテストは 3 つだ。本番環境で 2 週間、キックオフ前に合意した数値に実際に到達すること、そして——最も重要なのは——オペレーターが自発的にシステムの電源を入れること。世界一正確なシステムも、クルーが起動しなければ無価値だ。
明日やるべきエクササイズはこれだ。今走らせている、あるいは計画中の AI プロジェクトを取り上げ、1 枚の紙に書け。解決する問題は何か、受け入れ基準は何か、ビジネスリードとテクノロジーリードの名前は何か——下部に 2 つの空白の署名欄を添えて。その紙が書けないなら、あるいは両方の欄に同じ名前しか入らないなら、それは冒頭の物語に出てきた埃をかぶった機器と同じ構成を見ていることになる。早めに潰せ。予算を燃やしてから幕を引くより、ずっと見苦しくない。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
