次なるAIの分断：ミッドマーケット物流企業がAIを活用できるようになる前にインフラを整備すべき理由

AIに関する議論はしばしば アクセスに焦点が当たる、適切なモデルやツールへのアクセスが得られたら、次の課題はそれらの使い方を見つけることだという前提がある。ミッドマーケットの物流企業にとって、問題は必ずしもそこから始まるわけではない。

多くの倉庫やサードパーティ物流プロバイダー（3PL）において、ギャップはシステムの欠如が原因であることは稀です。倉庫管理システム（WMS）、エンタープライズリソースプランニングソフトウェア（ERP）または会計パッケージ、キャリア接続、そして大手顧客とのEDIをすでに持っていることが多い。その問題はそれらのシステム間で何が起きるかです。

ポイントツーポイントの接続は時間とともに蓄積される。顧客や取引先が一方向に接続され、別のパートナーが別の方法で接続され、最終的に誰も何が何と通信しているかを完全に把握できなくなる。統合は人にも依存し、たとえば誰かが顧客ポータルから注文を手入力したり、毎朝スプレッドシートで昨日の出荷を照合したりする場合がある。3PLは、顧客が注文の所在を問い合わせるまで取引が失敗したことに気付かないことがある。

それらはIT資産リストに現れないため、問題を過小評価しやすいのです。

問題はハンドオフにある

最大の運用上の問題は、注文、受領、出荷があるシステムまたは企業から別のシステムや企業へ移るハンドオフ時に起こりがちです：

• 遅延または不正な形式で届く入荷注文は、出荷波の欠落や出荷日遅延を招く可能性があります。
• 実際に届くものと合致しない事前出荷通知は、従業員がすべてのパレットを調査している間、受領を停止させることがあります。
• 出荷確認が顧客のシステムに届かないと、請求の遅延を招き、コンプライアンス違反に対する罰金を小売業者が差し引くチャージバックにつながることがあります。

3PLにとって、これらの問題は顧客ごとに異なるフォーマット、ルール、期待があるため増幅します。倉庫内の作業は通常円滑に進みますが、その周囲の情報フローが途切れます。

企業がAIを業務に導入する際、この区別はますます重要になります。AIは利用可能な情報だけで動作できるからです。チャットボットやコパイロットを単一のシステムに接続することはデモとしては有効かもしれませんが、複数のシステムにまたがる業務全体をそのシステムが把握できるわけではありません。

物流において、有用な質問はしばしばこれらの境界を越えるため、注文に関する回答にはWMS、ERP、そして輸送や顧客システムからの情報が必要になることがあります。プロセスの一部しか見えないAIツールは、不完全な情報に基づいて動作していることになります。

インフラが AIが必要とする情報で動作できるようにする 企業と、システムが依然として分断されたままの企業との間でギャップが拡大しており、そこに次なるAIの分断が生まれつつあります。

AIが実際に機能できる基盤が必要

真にAI対応のインフラは、技術的な用語ではなく運用的な観点で説明すべきです。注文、受領、在庫移動、出荷といったすべての重要なイベントは、共通のハブを通過すべきである、個別の接続の集合ではありません。取引先が送信するフォーマットは、もはや倉庫の問題であってはなりません。X12、EDIFACT、XML、JSONは、下流の誰もフォーマットを考える前に同一の注文に正規化されるべきです。

チームは、問題が顧客に届く前に数分以内に障害を把握する必要があります。従業員が問題の特定と解決に使用する同じ情報は、既存の権限を維持したクリーンなAPIを通じてソフトウェアやAIエージェントにも利用できる必要があります。また、AIが何かを提案した際に、誰がなぜそうしたかを確認できるよう、何が起きたかの記録も必要です。

これらの条件が整えば、AIの導入は格段にシンプルになります。これはミッドマーケット企業がテクノロジースタック全体を置き換える必要があるという意味ではありません。実際、ミッドマーケットの3PLがAI対応になるために新しいWMSやERPを導入する必要はほとんどありません。より実践的なアプローチは、コアシステムはそのままにして、システム間の接続を修正することです。

すべてのシステムとパートナーが接続する単一のハブは、個別のリンクの網よりもはるかに管理が容易です。

AIはインフラ構築に役立つ

こここそが、AIがミッドマーケット企業に特に有用となる領域です。従来、統合はパートナーの仕様書を読み、手作業でフィールドをマッピングし、取引先ごとにマッピングをテストする必要がありました。単一のパートナーマップを作成するだけでも、数週間にわたるハンズオン作業、テスト、そしてパートナーとのやり取りが必要です。

現在のAIモデルは仕様書やサンプルファイルを読み取り、マッピングを提案し、実際の取引に対してテストすることが可能です。その結果は人がレビューし、承認できます。

AIはEDIマッピングの最初のバージョンを作成する際に必要な手作業を削減できます。専門家はドラフトから開始し、パートナーの既存のレビューサイクルに送る前にレビューと修正を行うことで、フィールドごとにマッピングを構築する時間を短縮しつつ、最終成果物に対するコントロールを保持できます。

しかし、AIを統合に利用することと、統合そのものをAIに委ねることの間には重要な違いがあります。

この作業を行う際、私は「提案、根拠付け、検証、確認」と呼ぶアプローチを使用します。

AIはパートナー設定とフィールドマッピングを提案します。これは実際の仕様書やサンプルファイルに基づいており、フィールドやコードを創作するものではありません。別途用意された検証プロセスが、マッピングを実際の文書とフィールド単位で比較します。その後、担当者が結果を確認し、ライブの顧客フローに組み込まれる前に承認します。

我々は、AI生成マップを実際の運用文書と比較テストすることで、この手順が重要である理由を学びました。

あるテストでは、AI生成マップが倉庫転送文書をゼロエラーで読み取りながら、15件すべてのラインアイテムを落としてしまいました。別のテストでは、出荷指示書の6つの関係者すべてを保持したものの、どの関係者が送付先かを示すコードと住所情報が失われました。我々の自動チェックはマップを「クリーン」と判定しましたが、EDIスペシャリストがその欠落を発見しました。

参照データ自体が誤っていることもあります。クロスチェック済みと主張された標準ファイルは、テストしたすべての争点セグメントで公開標準と食い違っていました。

教訓は、部分的な結果は欠落した結果よりも見つけにくいことです。検証は、実際の文書のすべてのフィールドをマップが捉えた内容と比較しなければなりません。文書が解析できることを確認するだけでは不十分です。

信頼できる結果は、モデルの使用方法から出力のレビュー方法に至るまでの一連の手順に依存します。

AIが意思決定を行う前に価値は生まれる

インフラ整備は、AIエージェントが運用上の提言を行うはるか以前に価値があります。我々が関わったある3PLは、倉庫システムと並行してSAPを稼働させていました。すべての入荷受領には手作業で3〜5分かかり、SAP上の在庫情報はドックから約20分遅れて更新されていました。

二つのシステムを直接接続した結果、その遅延はほぼリアルタイムになりました。この取り組みにより、年間で980時間以上の労働時間が削減され、うち775時間は出荷作業に関するものでした。スプレッドシートでの追跡は不要となり、ラベルや船荷証券、梱包リストが自動生成されるようになりました。倉庫は既存のワークフローを維持したため、現場の従業員が再教育を受ける必要はありませんでした。

このプロジェクトから得た教訓は、労働時間削減以上の価値があるということです。二つのシステムが同一の最新情報を共有できれば、その情報こそがAIエージェントにとって有用になるのです。

それらを接続することが、以降のすべてを可能にするステップです。

AIの準備は統合から始まる

どこから手を付けるかを決める企業にとって、まずは統合を行い、統合作業の多くをAIに任せるべきです。多くの現場で見られる誤りは、AIをプロセスの最後だけに位置付けてしまうことです。AIは統合作業を初期段階でより迅速かつ低コストに進めるのに役立ち、その基盤が整ったら、意思決定を支援することができます。

ミッドマーケットの物流企業が必ずしも追加のテクノロジーを必要としているわけではありません。多くはすでに必要なシステムを保有しています。課題はそれらのシステムを連携させることにあります。ここでAIは、画面上で別の回答を生成するだけにとどまらない役割を果たすことができます。