倉庫の判断アプリで「LLM全部入り」をやめた後、本当に効いたのは「採用しない条件」を先に書くことだった
判断材料が散らばった業務をアプリ1本にまとめたのに、現場で「結局アプリを開かない人」が出た経験はないでしょうか。
道具は整ったのに使われない。
原因は機能の不足ではなく、「アプリの結論をどう扱うか」を決めていないことでした。
今回は、前回紹介した倉庫の判断アプリを運用に乗せたあと、ノートに残した運用メモの中身を共有します。
倉庫の判断アプリを運用に乗せて気づいたこと
前回の記事では、LLM全部入りをやめてPython＋SQLite＋軽い画面に絞った話を書きました。
判断材料を1か所に集め、加点スコアで第1候補と上位3件を出す。設計としては自分でも納得していました。
ところが、いざ運用に乗せた瞬間、決めていなかったことが一気に出てきます。
「この依頼は急ぎだから、画面を見ずに判断してしまった」
「上位3件のスコアがほぼ同じだった。どれを選べばいい？」
「面積では入るのに、積み下ろし通路がなくて実際は入らない、と現場から言われた」
アプリは正しく動いています。
にもかかわらず、結論をどう扱えばいいのかが揺れる。
LLMを外した代償として、機械の責任範囲が小さくなった分、人の責任範囲が増えていました。
そしてその範囲は、誰も明文化していませんでした。
壁はどこにあったか
壁は「アプリの結論」ではなく「結論の使い方」にありました。
たとえば、画面の上部には「有効計画反映済み：◯月◯日まで」と出ます。データが古いまま判断していないかを示す表示です。
ところが運用では、「今日は反映が遅れている。前日のデータで考えよう」という場面が出てきます。
そのとき、いつまでなら前日データで判断していいのか、誰も決めていませんでした。
スコアの僅差も同じです。
1位50点、2位48点、3位47点。画面ではきれいに並びますが、現場は「どれを選んでもいい」とは受け取りません。
点差が何点以内なら人の判断に戻すか、どこにも書いていないからです。
候補ゼロや、面積では入るのに通路の関係で物理的に置けない例外もありました。
こうしたケースを毎回口頭で確認していると、結局アプリではなくベテランに聞きに行くほうが早くなります。
道具を入れて、かえって手数が増えた状態でした。
問題は機能ではなく、判断の境界線が言語化されていないことだったのです。
この出来事から学べること
アプリの結論よりも、「アプリの結論を採用しない条件」を先に書いておく。
これが今回の一番大きな学びでした。
機械が出すのは候補です。
採用するかどうかは人の責任になります。
ところが、候補を出す側ばかり丁寧に設計して、採用判断のほうは「現場が考える」になっていました。
これは実質、属人化を別の場所に移しただけです。
採用判断の境界線とは、たとえばこういうものです。
データ反映の遅延が一定時間を超えたら、前日データでは判断しない
上位3件のスコア差が一定の幅以内なら、現場担当の最終確認を必須にする
通路や荷姿の制約は、アプリでは見ない。最終チェックは人が行う
こうした「機械に任せない条件」が書いてあると、現場は安心して残りを機械に任せられます。
逆に、境界線がないと、すべての結論を疑うか、すべての結論を盲信するかの両極になります。
どちらも長続きしません。
任せる範囲は、任せない範囲を先に書いてから決まる。
次にLLMをアプリに戻すときにも、そのまま使える原則だと感じています。
実際に試したこと
運用メモは大きく4つに分けました。手順書ではなく、判断書として書きます。
1）データ更新の鮮度ルール
画面上部の「有効計画反映済み」表示と組み合わせます。
反映済み日が当日なら、そのまま使う
前日までなら、急ぎ依頼に限り使ってよい。ただし採用結果は手元メモに残す
2日以上前なら、判断を保留してデータ更新を待つ
数字は厳密でなくて構いません。「いつまで使うか」を一行決めるだけで、現場の迷いが減りました。
2）人に戻す条件
スコアの僅差や候補ゼロのときの基準を書きました。
上位3件のスコア差が3点以内なら、第1候補を採用せず3件を並べて現場確認する
候補ゼロのときは、加点条件を1つ緩めて再計算する。それでもゼロなら依頼者に戻す
通路・荷姿・出庫頻度の事情は、アプリでは見ない。アプリの結論に「人の最終チェック」をかける
ここで大事なのは、「迷ったら止める」ではなく「迷う条件をあらかじめ書く」ことでした。
止め方が決まっていれば、止めること自体に罪悪感がなくなります。
3）スコアの重みを誰がいつ触るか
重み（エリア一致◯点、倉庫種別◯点、余力◯点）は、運用に乗せた直後ほど直したくなります。
直したくなったら、まず1か月は触らないと決めました。
1か月分の「人がアプリの結論を覆した記録」を集めてから、月1回だけ重みを見直します。
触る人は1人。理由を一行残します。
これで重みが現場の感情で動かなくなりました。
4）アプリの判断を覆した記録
これが一番効きました。
覆したときの依頼内容、採用した倉庫、覆した理由を一行で残す欄を画面に足しました。
データではなく、ただの自由記述欄です。
1か月集めると、「通路制約が3割」「急ぎで近い倉庫を選んだが2割」のような傾向が見えてきます。
重みを直す根拠を、感覚ではなくこの記録から拾えるようになりました。
やってみて分かったこと
良かった点は、現場の「アプリを開かない」が減ったことです。
アプリを使う前に、どの場面で人に戻していいかが書いてある。
それだけで、開く心理的なハードルが下がりました。
道具の使い勝手より、責任範囲の明確さが定着を決めるのだと感じました。
失敗もありました。
ひとつ目は、運用メモを最初「手順書」として書いてしまったことです。
「画面を開く→候補を確認する→採用する」と動作の順番を書いて配ったら、ほとんど読まれませんでした。
動作はアプリを触れば分かります。
読みたいのは「迷ったときどうするか」だったのに、肝心のそこが薄かったのです。
書き直して判断の分岐だけを残したら、ようやく現場で参照されるようになりました。
ふたつ目は、最初から数字を細かく決めようとしたことです。
スコア差の閾値や、データ鮮度の許容時間を、いきなり「2.5点以内」「6時間以内」と決めようとしました。
根拠がないので、現場から「なぜその数字？」と聞かれて答えられません。
最初は「3点以内」「前日まで」のようなざっくりした数字に戻し、覆し記録から徐々に詰めていく形に変えました。
判断書は完璧に作るものではなく、運用しながら鍛えるものでした。
明日から試せる一歩
非エンジニアの方でも、今日から始められる手順です。
自分の業務で「アプリやツールの結論を採用しない場面」を3つ書き出す
それぞれの場面に「いつ人に戻すか」の境界線を一行で書く
数字は最初ざっくりでよい（「◯件以上」「◯時間以内」など）
結論を覆したときに、理由を一行残す欄を作る（紙でもExcelでもよい）
1か月分集まったら、その記録を見ながら境界線を見直す
順番は「ツールを直す」より「採用しない条件を書く」のほうが先です。
ツールに不満があるときほど、まず使い方の境界線を疑ってみる価値があります。
次の一手（#AI活用100本ノック）
次は、自然文での依頼入力に挑戦します。
「A品を30個、拠点Aに搬入したい」と打って判定が走る入口に、軽くLLMの出番がやってきます。
ただし、LLMを入れる場所は今回の運用メモが決めます。
人の責任範囲が固まっていない場所には、機械を増やしません。
入口の文章解釈までは任せ、判断と採用は今まで通り——を出発点に試します。
関連記事：
この記事が参考になったら「スキ」で教えてください。次の実験の励みになります。
#AI活用100本ノック 進捗：82/100
次回の実験：自然文での依頼入力に、入口だけLLMを試す（人の責任範囲は変えない）
このnoteでは、現場改善・AI活用・小さな自作ツールの試行錯誤を記録しています。
初めての方はこちらからどうぞ。
▶ はじめての方へ｜このnoteで書いていること
