去年の初め、私は Inland Empire の 3PL のレビュー会議に同席した。彼らは AI 目視検証システムの 3 か月間のパイロットを終えたばかりだった。出荷前にすべての荷物と出荷ラベルをカメラでスキャンし、商品違い・ラベル違い・ラベル曲がりを検出するものだ。オペレーション責任者は上機嫌だった。検証チームはシフトあたり数十人から数人に減った。誤出荷は目に見えて減り、顧客クレームも減少していた。
そのとき CFO が一つ質問した。「で、結局いくら儲かったの？」
沈黙。
スライドには ROI のページがあった、もちろん。見栄えは抜群だった。ソフトウェア購読料を差し引いた 1 年分の人件費削減で、回収は数か月。私は 3 つ質問した。データラベリングの請求書は入っているか？ パイロットの面倒を見るのにかかったエンジニアリングとオペレーションの工数は？ 検証ステーションの改修——新しい照明、カメラの再配置、コンベア速度の調整——AI がラベルを確実に読めるようにするための工事は？
誰も答えられなかった。そのパイロットは 18 か月後の今も「トライアル」のままだ。誰も本格展開を提案しない。誰も中止する勇気もない。お金は流れ続け、結果は「良い」ように見えて、それが本当に価値があったのか誰も言えない。
私はこの光景を倉庫という倉庫で見てきた。ほとんどの AI パイロットは、技術が失敗して死ぬのではない。会計が失敗して死ぬ。帳簿を間違えれば、パイロットはずっと高価なおもちゃのままだ。
目に見えるコストだけ数えるな
私が見る AI パイロットの予算は、ほぼすべてソフトウェア購読料を並べて終わりだ。本当のコスト台帳には最低 7 つの行がある。
購読料やライセンス料は最も目立つ行だが、多くの場合最小の項目の一つだ。次に実装とインテグレーション：WMS への接続、カメラ角度の調整、データインターフェースの構築、ベンダーエンジニアの数日にわたる常駐。そしてデータクリーニングとラベリング——隠れた巨人だ。倉庫のデータは決してきれいではない。モデルが何かを学ぶ前に、誰かが数か月分の注文と画像を手作業で掃除しなければならない。ほとんどの計画はこれにゼロ予算だ。
そして社内の工数。オペレーションスタッフ、IT、エンジニア——パイロットを生かし続けた全員を、諸経費込みの時間単価で計上する。プロセス改修は最も「忘れられがち」な項目だ。ステーションの再配置、照明の追加、ネットワーク配線の増強、コンベア速度の再調整。このお金は施設予算に眠り、パイロットの帳簿には見えない。トレーニングと変革管理、そして継続的なメンテナンスも加える——モデルは一度の導入で終わらない。新しいデータと定期的な再調整がなければ、精度は数か月で劣化し始める。
私のクライアントへのルールは率直だ。ROI レポートに「ソフトウェア購読料」と「人件費削減」しか書いていないなら、捨ててしまえ。それは会計ではない。願い事リストだ。不完全なコスト台帳から生まれた数字はすべてプラセボだ。
利益は 3 つの台帳に分けて数える
利益側の古典的な間違いは、人数だけを数えることだ。労働時間の削減は確かにあるが、式は「諸経費込み時間単価 × 削減時間」で、残業とやり直しを差し引く。多くの人は時間ではなく職位を数える。それは全く別の数字だ。
2 つ目の台帳はエラー率の削減で、往々にして人件費削減より価値が大きい。誤出荷 1 件——返送運賃、対応工数、顧客へのクレジット——は通常、普通の注文のマージンの数倍から数十倍かかる。エラー率を 1 桁台前半から小数点以下レベルに下げることは、1 年で本物の金額になる。鍵は測定の規律だ。パイロット前に誤出荷・不足・破損・ラベルエラーのベースラインを取り、毎週追跡し、パイロット中も全く同じ定義を使うこと。途中で定義を変えたら、その数字は無意味だ。
3 つ目の台帳はスループットとカットオフ時刻だ。同じシフト、同じフロアで——1 日にあと何件出荷できるか？ 注文締め切りを 1 時間早められるか？ これはやがて顧客維持と新規ビジネスに変わるもので、短期的には最も定量化が難しく、長期的には最も価値が高い。私のアプローチは、「労働時間あたりの処理件数」を今のハードな指標として固定し、顧客側の利益は無理に金額化せず別の定性台帳で管理すること。無理やり出した数字は偽物の数字だ。
3 つの台帳は別々に列挙する。それだけが CFO が尊重する形式だ。1 つの大きな数字に混ぜたら、何も計算していないのと同じだ。
対照群がなければ、信頼できる数字はない
前後比較は最も弱い証拠だ。3 か月の間に季節性は変わり、人員は入れ替わり、顧客構成は変わる。指標が改善した——それは AI のおかげか、カレンダーのおかげか？ 対照群を作れ。同じ建物の 2 つのラインや 2 つのシフトで、片方に AI、もう片方にはなし。あるいは同等の 2 棟で、片方だけパイロットする。パイロット前に最低 4〜6 週間のベースラインデータを取り、パイロット中も同じ長さの期間で取る。
観察者効果にも注意だ。パイロット中は全員が見られていると知っているから、少し頑張る。私のローテクな対策は、両グループに「業務改善調査」の一環だと伝えることだ。どちらにも「AI に置き換えられる」グループだとは絶対に知らせない。人的変数を管理しなければ、データはノイズだ。
キルラインは始める前に決める
ストップロス基準を初日にプロジェクト憲章に書け。この金額を超えたら、この月数を超えたら、この改善閾値に届かなかったら——止める。署名して、壁に貼る。私の経験則はこうだ。3 か月後に改善の「方向性」の兆しがなければ、それ以上お金を入れない。注意したいのは「方向性」であり「目標達成」ではないこと。パイロットは方向を試すためにある。正しい方向ならさらに時間が与えられる。間違った方向は、お金を積んでも直らない。
失敗した AI パイロットで最も高くつく部分は、ソフトウェアであることは稀だ。それは失敗を認める心理的コストだ。倉庫の人間は毎日デッドストックと向き合っている——売れない在庫をどう処分するか、私たちは知っている。うまくいっていないパイロットも同じ扱いがふさわしい。早期の中止は失敗ではない。次の本当に価値のあるパイロットに予算を残すことだ。
だから率直に聞きたい。今「まあまあ良さそう」に見えるパイロットを動かしているなら、明日 ROI レポートに署名して、自分の名前をかけられるか？
無理なら、問題はおそらく AI ではない。帳簿だ。7 つのコストをすべて計上し、3 つの利益台帳を分け、本物の対照群で回せ。それができれば、数字が価値があったかどうか教えてくれる——願い事リスト抜きで。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
