倉庫の判断アプリで「LLM全部入り」をやめた本当の理由
複数のExcelを毎回開き直し、頭の中で在庫と計画を足し引きして「どの倉庫に入れるか」を判断している方へ。
ベテランの勘に頼った判断はブレ、新人への引き継ぎもうまくいかない。
そんな状況をアプリ1本で整えようとした試行錯誤と、途中で気づいた大事な「順番」を残します。
判断材料が5か所に散らばっていた
倉庫の搬入・搬出を判断する立場になって、最初に驚いたのは「判断材料が散らばっている」ことでした。
現在の在庫はAファイル。
移動の予定はBファイル。
廃却の予定はCファイル。
品番の特性はDファイル。
倉庫の容量はEファイル。
1件の依頼を裁くために、毎回5つのExcelを開き直していました。
しかも、ベテランの判断は「経験」と「肌感」で動いています。
本人は説明できるのに、文章にすると曖昧になる。
新しい担当者に渡そうとした瞬間、ルールの輪郭が消えてしまうのです。
これは「人が悪い」のではなく「道具が足りない」状態だと感じました。
判断そのものを楽にする前に、判断材料を1か所にまとめる必要がある。
ここが今回のアプリの出発点です。
最初の失敗：「AIなら全部やってくれる」の思い込み
最初の壁は、思い込みでした。
「最近のAIなら、自然文で依頼を投げれば全部やってくれるはず」。
そう思って、ノーコード系のAIツール（Dify）でPoCを作りました。
確かに動きはします。
ただ、個人PCで常駐させるには重く、起動も遅い。
Excelとの連携も毎回ひと工夫いる。
何より、改めて業務を整理してみると——判断の中身は「決まりきったルール」がほとんどでした。
「この品番は2段積みまで」「面積借りの倉庫を優先する」「廃却予定は計算から除く」
これはLLMで会話する必要はありません。
条件を整理して、プログラムに渡せばいい話でした。
「最先端の道具」を使いたい気持ちが、課題設定を曇らせていました。
そのことに気づいたとき、少し恥ずかしくなりました。AIを使う理由が「課題の解決」ではなく「新しい道具を試したい」になっていたのです。
次の失敗：ルールを「強くしすぎた」
二つ目の失敗は、ルール設計のミスです。
倉庫には種類があり、面積で借りているもの、個別で借りているものが混在します。
当初は「搬入なら面積借りを優先、搬出なら個別借りを優先」を絶対条件にしました。
ところが、絶対条件にすると候補がゼロになる依頼が出てきます。
近くに合う倉庫がなければ、少し条件を緩めてでも候補を出すべきなのに、機械はバッサリ切ってしまう。
「あれ、この依頼、どこにも入れられないことになってる」
動作確認中にそう気づいて、ルールの強さを設計し直す必要を理解しました。
「この条件が合うなら高スコア」の加点方式に変えると、ベストではない倉庫も次善候補として並ぶようになり、ゼロ候補の問題は解消されました。
最終的に選んだ構成
最終的に選んだ構成はとてもシンプルです。
Pythonで判定ロジックを書き、SQLiteに在庫や計画をまとめ、軽いWeb画面を1つ用意する。
DockerもLLMも使いません。
データのテーブルは5つに整理しました。
倉庫の情報、品番の情報、現在の在庫、移動の計画、廃却の計画。
Excelからの取り込みは、定期実行のスクリプトに任せます。
搬入は「面積」で見る。
品番ごとに「1山あたり何㎡か」「何段積めるか」を持っておき、依頼数量から必要な床面積を計算する。
倉庫の空き面積と比べて、入るかどうかを判断します。
搬出は「数量」で見る。
現在の在庫から、これから出ていく予定を引き、これから入ってくる予定を足す。
廃却予定も忘れずに引く。
これで「実質の在庫」が出てきます。
そのうえで、候補をスコアで並べました。
余力がある／エリアが一致する／倉庫種別が合う、それぞれを点数化する。
ぴったり一致しない倉庫もスコアで並ぶので、ゼロ候補が出ません。
点数が同じなら、エリア一致→倉庫種別→余力の大きさ→IDの順で並べる。
これだけのルールで、第1候補と上位3件がきれいに出るようになりました。
加えて、画面には「有効計画反映済み: ◯月◯日まで」と表示しました。
古いデータで判断していないか、ひと目でわかる安心材料になります。
やってみてわかった2つのこと
構成が軽くなったことは、大きな安心でした。
PythonとSQLiteなら個人PCで十分動きます。
ロジックを直したいときに、自分の手で書き換えられる——それが「道具を持った感覚」に変わりました。
転んだ点が2つあります。
ひとつ目は、テーブルの列名を曖昧にしてしまったこと。
最初は倉庫の容量を「最大保管量」という名前で持っていました。
ところが実体は「面積」です。
途中で「最大面積」に直すことになり、関連箇所をまとめて書き換えるはめになりました。
最初から実体に合った名前を付けるべきでした。
ふたつ目は、優先ルールを強くしすぎたこと。
前の節で書いたとおり、倉庫種別の優先を絶対条件にしたら、候補ゼロになる依頼が出ました。
加点要素に直したら、「ベストではないけど次善の倉庫」がちゃんと提示されるようになりました。
業務ルールは、強さを段階で設計するのが正解でした。
ふり返ると、両方とも「言葉の曖昧さ」が原因です。
名前付けと、ルールの強さ。
このふたつは、最初に時間をかける価値があります。
この経験から引き出した3つの学び
1）最先端の道具と、自分の課題は別物
LLMやAIエージェントは魅力的に見えます。
ただ、自分のやりたいことが「決まったルールでの判定」なら、ルールベースで十分です。
道具に課題を寄せるのではなく、課題に道具を合わせる。
2）絶対条件は最後まで疑う
業務ルールには「これは外せない」と感じる条件がたくさんあります。
でも、本当に外せないのか、加点で表現できないのか、一度立ち止まる価値があります。
強すぎるルールは、機械に渡すと候補ゼロを生みます。
3）データの集約が先、判定は後
判定ロジックを凝る前に、判断材料を1か所にまとめる。
これだけで人間の負担はかなり下がります。
アプリ化する前に、データのかたちを揃える時間を惜しまないこと。
明日から試せる一歩
非エンジニアの方でも、今日から試せるステップです。
自分の判断ルールを、紙に箇条書きで書き出す
判断に使うデータが、いまどこに散らばっているか地図にする
それぞれの条件が「絶対」か「加点」か、印を付け直す
「これがないと候補が出ない」条件は、本当に外せないか自問する
まずデータを1つの場所にまとめてみる（Excel1ファイルでもよい）
道具は後からで大丈夫です。
判断のかたちが見えてくれば、自然と「ここはアプリに渡せる」と分かります。
次の一手（#AI活用100本ノック）
次は、自然文での依頼入力に挑戦します。
「A品を30個、拠点Aに搬入したい」と打てば、判定が走る入口を試します。
ここで初めて、軽くLLMの出番がやってきます。
ルールベースで土台を固めたうえで、入口だけAIに任せる。
この組み合わせが、個人運用にちょうどいい温度感だと感じています。
関連記事：
この記事が参考になったら「スキ」で教えてください。次の実験の励みになります。
#AI活用100本ノック 進捗：76/100
次回の実験：自然文入力からのフォーム自動抽出（精度と誤抽出の境目を見る）
このnoteでは、現場改善・AI活用・小さな自作ツールの試行錯誤を記録しています。
初めての方はこちらからどうぞ。
▶ はじめての方へ｜このnoteで書いていること
