この2年間、私は倉庫AIパイロットを回した20人以上の実務家にインタビューしてきた——3PLのオペレーション責任者、ECフルフィルメントセンターのITリーダー、自動化ベンダーのプリセールスエンジニアだ。「パイロットはどうでしたか」と聞くと、半数以上は成功か失敗かでは答えなかった。日付で答えたのだ。「2か月ほどで終わった」「3か月目に畳んだ」「90日目のレビューで殺された」。倉庫AIパイロットは、倉庫デジタル化の中で最も奇妙な存在になった。ベンダーは壇上で成功事例を発表する一方で、はるかに多くのプロジェクトが90日目を待たずに静かに死んでいく。本稿は、パイロットシナリオの選び方やROIの算出方法の話ではない。3つの本当の失敗の検死報告である——それぞれがどこで死んだのか、そしてなぜ技術は死因ではなかったのか。

3つの倉庫AIパイロット、3つの死因

ケース1：データドリフトに殺されたビジョン選別システム。

2025年1月、アメリカ中西部の3PL倉庫（アパレル受注を処理）がビジョン式の品質検査パイロットを立ち上げた。コンベア上部の工業用カメラ2台、破損した小包や読み取り不能な配送ラベルをAIモデルが検出し、フルタイムの品質検査員2名の代替を目指すというものだった。タイムラインは教科書通り。第1–4週：設置と統合。第5–8週：モデルのチューニング。第9週：試運転。精度はベンダーが約束した98%に到達——ただし測定対象は、注記しておくが、ピークシーズンの標準カートンプロファイルだった。転機は第10週の後に訪れた。オフシーズンの品揃えが来たのだ。不規則な小包や小ロットSKUが標準箱に取って代わり、モデルが学習した形状、テープの色、ラベル位置が現実と合わなくなった。誤検知率は2%から15%超へ上昇。検査員は手作業で全小包を確認する体制に戻り、システムは飾りになった。第12週のレビューで、オペレーション責任者が電源を抜いた。プロジェクトマネージャーはこう語った、そのまま引用する。「モデルが駄目になったんじゃない。倉庫の方が先に変わった」。教訓は精密だ。学習分布がカバーしていたのはピークシーズンだけで、受入テストはオフシーズンにぶつかった。データドリフトは技術問題ではなかった。スケジュールの問題だった。

ケース2：成功を誰も望まなかった組織に殺されたAMRピッキング最適化。

2025年6月、中国東部のアパレルEC倉庫が、AIによるピッキングタスク割当のためにAMR6台を導入した。技術的にはうまくいった。最初の3週間で、ピッカーの平均移動距離は約20%減少——倉庫のWMSログで検証可能な数字だ。奇妙なことが始まったのは第4週からだ。ピッカーがロボットの充電を「忘れ」始めた。誰かが空のトートをAMRの走行レーンに積み上げた。ピッキングチームのリーダーはインタビューでこう率直に言った。「システムがタスクを全部割り振って、全部記録する。このデータが年末評価で俺たちに不利に使われないなんて、誰が分かる」。パイロットのKPIはIT部門のものだった。オペレーションは成果に対する説明責任を持っていなかった。ビジネスオーナーがいなかった——パイロットの成功に自分の仕事がかかっている人間がいなかったのだ。第8週までに、6台中4台のAMRが充電エリアに恒常的に停まっていた。プロジェクトは放置されて死んだ。技術は100%を届けた。組織はゼロを届けた。

ケース3：ベンダーの約束に殺された需要予測リプレニッシュ。

2024年11月、欧州の自動車部品倉庫がAI予測SaaSベンダーと契約した。売り文句は「箱から出してすぐ、2週間で稼働」。WMSとの統合には実際9週間かかった——過去の出庫データを口径、単位、欠損値のレベルで項目ごとに作り直す必要があったのだ。さらに悪かったのは契約だ。パイロットの成功判定は稼働開始とされ、データ品質のベースラインも、予測精度が目標に届かなかった場合のエグジット条項もなかった。システムはようやく2025年2月に稼働した。補充提案は、15年の経験を持つプランナーの判断と何度も食い違った。両者は互いを信頼しなかった。第6週までにプランナーは経験でシステムを上書きするようになり、誰もシステムのレポートを開かなくなった。パイロットは60日目前後で凍結された。最終支払いは全額行われた——契約には「稼働開始＝受入」と書いてあった。

倉庫AIシステムをデバッグするエンジニア

帰属のフレームワーク：AIパイロット死亡の4分類

並べてみると、3つの死は4つの分類に整理される。

分類 典型的な症状 ケース 襲ってくる時期
データ 学習分布が現場の実態とずれる。データ品質のベースラインなし ケース1 試運転フェーズ（第8–12週）
シナリオ 「最も痛いが最も難しい」シナリオを選ぶ。KPIが測定不能・帰属不能 — プロジェクト立ち上げ時
組織 ビジネスオーナーなし。現場のインセンティブがパイロット目標と対立 ケース2 全期間
ベンダー 約束と納品のギャップ。統合の過小評価。契約にエグジット条項なし ケース3 調達と稼働開始時

シナリオ分類はこの3ケースでは襲わなかったが、他のインタビュー全体では立ち上げフェーズで最も多い罠だ。サンプルが少なくルールがぐちゃぐちゃなロングテールの例外処理にAIを当てると、3か月のパイロットは最初から評価不能になる。

直観に反する結論：技術は一度も主因ではなかった

3ケースとも、アルゴリズムチームは稼働するモデルをスケジュール通りに納め、精度の数字はそれぞれのテストセットで「合格」した。パイロットを殺したのはパイロットの設計そのものだった。データが準備されていない、シナリオが難しすぎる、成果に責任を持つ人間がいない、リスクを買い手側に全部残す契約。言い換えれば、AIパイロットが失敗するのは「AIが使えない」からではめったにない。パイロットという組織行為そのものが設計されていなかったからだ。ある国際コンサルタントによる2025年の物流技術サーベイでは、企業はAI導入の障壁として「データ準備の不足」と「社内調整の難しさ」を上位2つに挙げ、技術の成熟度はそれより下だった——私のインタビューの結論と一致する順位だ。

トレンド判断：2026年、パイロットの論理が変わりつつある

時系列で見ると、2024–2025年のパイロットの多くは「技術検証」の論理だった。まず技術を買い、使い方は後で考える。2026年以降、私が出会う新しいプロジェクトは次第に「組織検証」の論理に変わっている。パイロットの承認前にAIレディネス評価（データ・プロセス・人の採点）があり、契約もライセンス買い切りからマイルストーン払いへ移っている——データ統合の完了で一区切り、合意した精度の達成でもう一区切り。このシフトの意味は、市場がパイロットを「技術の購入」から「組織変革のプロジェクト」へ再定義していることだ。技術はますます安くなる。難しかったのはいつも組織の方だ。

この3ケースを振り返りながら、私は一つの問いを繰り返し考えている。90日を逆の順序で並べ直したらどうだろう——30日をデータと組織の準備に、30日を小規模での検証に、そして残りの30日で初めて拡張の話をする。そうすれば90日目に死ぬプロジェクトはまだこんなに多いだろうか。標準的な答えはない。だが2026年に倉庫AIパイロットを考えるすべての人が、サインの前に自分自身に問う価値のある問いかもしれない。

Dr. Chen（サプライチェーン研究者）著

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