ローソン、アスクルが現場の課題解決のAI活用で気付いた“実際に動く仕組み”の大切さ

アスクル：物流倉庫の高度化が生んだメインテナンスの課題をAIで解決

　アスクルは、企業向け事務用品通販の「アスクル」と、個人向け通販の「Lohaco」を合わせて600万商品を取り扱っている。それらを管理する倉庫として現在、全国に9つのセンターを持っている。

　すべての倉庫は24時間／365日ノンストップで稼働しており、自動化が進んでいる。最新の倉庫では全工程の80％を自動化した。ところが「自動化によって、倉庫にある、さまざまな装置のメインテナンスが大きな問題になってきた」と同社の先端テクノロジー主任研究員の三井 康行 氏は明かす（写真2）。

写真2：同社の先端テクノロジー主任研究員の三井 康行 氏

　倉庫の設備の停止は、商品の出荷停止につながるため、各倉庫には設備の専門スタッフが常駐し、トラブルには24時間体制で修復に当たっている。ただ専門スタッフには、フォークリフトの運転など特殊な技能も要求されるだけに、慢性的に人員不足な状態にある。

　そこでアスクルが取り組んでいるのが、装置メンテナンスをこれまでの予防保全から予知保全に転換することだ。故障を事前に予測して部品を交換するなどで、稼働状態を維持すると同時に、メインテナンス人員の適正化を測るのが狙いだ。故障の確率が高い部分から保守するため、無駄な設備交換が不要になる。

現場が理解しやすいUIの提供が重要

　予防保全への転換に向けて、三井氏が率いるチームでは手始めに、倉庫内を移動する段ボールやコンテナに貼られたバーコードを読み取るバーコードリーダー（BCR）の故障対策に取り組んだ。

　BCRは倉庫管理システム（WMS）に入力すべきデータの読み取り装置だけに、BCRが故障すると倉庫の機能が止まってしまう。しかし、倉庫内には数百のBCRが点在し、1日に180万回もバーコードを読み取っている。読み取りエラー（NRE）も非常に数多く発生していたが、その原因が装置の問題なのか、バーコードの問題なのかの切り分けすらできなかった。

　そこで三井氏のチームは、エラーが頻発するBCRをいち早く見つける検知システムを開発した。すべてのBCRについて、正常な通過回数と読み取りエラーを起こした回数を15分間隔で取得し、GCP（Google Cloud Platform）のデータウエアハウス「Big Query」に蓄積する。

　Big Query上のデータから一定時間内のエラー回数とエラー率を計算し異常なBCRを推定する。担当者は、過去数日間に急にエラーが増えたBCRと共に、Slack上で異常なBCRの修理など対応を依頼する。対応が完了すれば、その旨がSlackに返信され、異常なBCRは「対応済み」として管理される。

　同システムを開発するうえで三井氏が一番重視したのは、現場の作業員が簡単に扱えること。「倉庫内に数百あるBCRのどれが異常かを容易に示せなければ、いくら検知精度が高くてもメインテナンスの改善につながらない。そのため特定のBCRについて、グラフでエラー率を表示するなど、直観的でわかりやすいUIに力を入れた」（三井氏）という。

　現場からは、「エラーが頻発しているBCRに重大なエラーが起きる前に対応できるようになった」「エラー多発の要因分析ができるようになった」など好反応が得られている。「この仕組みを他の機器にも使いたいという声も挙がっている」（三井氏）ともいう。

　アスクルは現在、エラーと、その対応結果の相関を分析し、エラー時の対応マニュアルを見直している。今後は、入出荷データなど、業務データを含む全システムのデータをGCP上で連携させ、倉庫全体の予知保全を実現したい考えである。