AIで改善する業務の選び方――効果・データ準備度・導入負荷を並べて考える

「AIを導入したい」という希望だけでは、何を作るべきかも、役に立ったかをどう確かめるかも決まりません。最初に、業務のどの場面で誰が何を判断し、その後どんな行動を取るのかを具体的にします。たとえば「需要予測をしたい」ではなく、「担当者が毎朝、店舗ごとの補充量を決める際に、欠品を避けながら過剰在庫を抑えたい」のように、判断と困りごとを結び付けます。

次に、判断の頻度、担当者、使っている情報、判断後の作業を記録します。日次の判断と、数分ごとに状況が変わる判断では、必要なデータ更新やシステム連携が違います。例外を誰が扱っているか、担当者が何を根拠に判断を変えるかも確認すると、現場の知識を見落としにくくなります。

現状の作業時間や待ち時間を測っていない場合は、そのこと自体を候補選定の課題として扱いましょう。記録できる範囲と方法を決め、改善前の状態を把握することが、あとで結果を判断する土台になります。

• どの担当者が、どのタイミングで判断しているか
• 判断に使う情報と、判断後に起こす行動は何か
• 困りごとは作業時間、欠品、待ち時間、予測誤差など何として観察できるか
• 通常と異なる状況や、判断を人が覆す場面はどれくらいあるか

候補業務ごとに、何が変われば改善と呼べるのかを仮説として書きます。たとえば「確認作業の時間を短くできる可能性がある」「欠品につながる補充遅れを減らせるか検証する」といった形です。事前に成果を断言するのではなく、確かめる問いとして扱うことが大切です。

比較のためには、導入前の基準値を同じ単位で記録します。対象期間、対象部署や店舗、業務量、計測方法をそろえ、曜日・季節・販促・繁忙期など結果を左右しそうな条件も残します。平均値だけでは、特定の繁忙日や例外ケースで負担が増えたことを見逃す場合があります。

また、業務成果とモデルの評価指標は分けて考えます。予測誤差が小さくなっても、担当者の確認時間や例外対応が増えれば、業務全体として望ましいとは限りません。作業時間、処理量、欠品などの成果指標と、予測誤差などのモデル指標、確認負荷などの運用指標を並べると、判断材料が偏りにくくなります。

基準値やKPIの設計を詳しく確認したい場合は、AI導入の効果をどう測るか――基準値とKPIを先に決める実践手順も参考になります。

データが大量にあることと、判断に使える状態であることは同じではありません。候補業務で必要な項目がそろっているか、意思決定に合った粒度か、更新の遅れが許容できるかを確認します。店舗単位の日次判断に、全社月次の集計しかなければ、必要な比較ができないかもしれません。

欠損、重複、異常値を見つけても、すぐに削除や補完を決めるのではなく、なぜ発生したかを調べます。入力手順や業務ルールの変更が原因なら、データの問題は現場の運用にもつながっています。項目名が同じでも部門によって定義が違う場合や、コード・単位が変わった履歴が残っていない場合も、分析結果の解釈に影響します。

さらに、どの情報を何の目的で使うのか、誰がアクセスできるのかを整理します。最初から広範なデータを集めるのではなく、検証の問いに必要な範囲を特定するのが出発点です。目的に応じた確認項目は予測モデルの前に確認したいデータ品質――粒度・欠損・更新頻度の点検表で解説しています。

• 必要な項目があり、判断に合う単位・粒度で記録されているか
• 欠損や重複がどこで、どの業務条件に偏って起きているか
• 項目の定義、単位、業務ルール、更新頻度に変更履歴があるか
• 利用目的、アクセス権、必要最小限のデータ範囲を説明できるか

候補の比較では、効果の見込みだけで順位を決めないようにします。既存システムからデータを取り出せるか、結果を業務画面や作業手順にどう戻すか、導入時に誰の仕事が変わるかを確認します。技術的に分析できても、現場が結果を確認しにくかったり、必要なタイミングで届かなかったりすれば、判断にはつながりません。

誤った推奨が出たときの影響も候補ごとに異なります。影響の大きさ、発生を見つける方法、判断を人が確認・修正できる範囲、問題時に止める手順を検討しましょう。自動化の程度を一律に決める必要はありません。まずは提案だけを表示する、人の承認後に実行するなど、業務に応じた関与の仕方を比較できます。

現場の受け入れやすさは、単なる賛否ではなく、判断の根拠を確認できるか、例外を扱えるか、現在の責任分担に無理がないかとして具体化します。アクセス権や情報の扱いに関する確認も、後回しにせず候補の条件に含めます。

候補を検証に進めるときは、まず「この検証で何を判断したいのか」を一つずつ明確にします。たとえば、データから有用な予測が得られるか、担当者が推奨を確認できるか、既存業務に無理なく組み込めるかは、別々の問いです。技術的な試作だけで、日々の運用や現場負荷まで確認できたことにはなりません。

検証計画には、対象範囲、比較方法、評価指標、成功とみなす条件、停止条件を記載します。データの不足や連携上の制約など、開始前に残っている不確実性も明記しておきます。結果が期待どおりでない場合に、仮説を修正するのか、追加情報を集めるのか、いったん止めるのかを話し合えるようにするためです。

期間や目標値に普遍的な正解はありません。業務の周期、データの蓄積状況、比較可能な対象の有無に合わせて決めます。評価が良好でも、本番運用の監視、担当者、例外処理、データ管理などが未整理なら、拡大を急がず追加の検討事項として残しましょう。

以下は選定方法を示すための一般的な構想例であり、特定企業への導入実績や成果を示すものではありません。店舗別の補充判断を考えるなら、販売、在庫、納品、販促などの情報がどの単位・頻度で使えるかを確認し、担当者が補充量を決める場面を特定します。

改善仮説は「補充判断の参考情報を提示することで、欠品と過剰在庫の両方を考慮した判断を支援できるか」のように置けます。検証では、比較対象や期間を定め、欠品などの業務指標だけでなく、推奨の確認にかかる時間、例外対応、データ更新の遅れも観察します。販促や季節性といった条件も記録しなければ、結果を単純に比較できない可能性があります。

この例では、売上予測だけで候補の価値は決まりません。データの粒度、納品の制約、担当者が推奨を修正する理由、システムに結果を戻す方法まで確かめて、次の検討へ進むかを判断します。