資料

AIで在庫管理システムを「自分で作ってみた」私が、先に知りたかった5つのこと

この資料は、Excelやスプレッドシートでの在庫管理に限界を感じている方、そして「ChatGPTやClaude Codeを使えば、自分でもシステムが作れるのでは？」と考え始めている方に向けて書いています。

はじめに

私自身、精肉の在庫管理をスプレッドシートで運用していた一人です。関数が複雑になって壊れ、作った本人しか触れなくなる——という限界を経験して、「それなら、ちゃんとしたシステムを自分で作ろう」と考えました。

ちょうどAIで開発するツールが話題になっていた時期です。「日本語で指示するだけでアプリが作れる」という話は本当で、実際、思っていたよりずっと早く「動くもの」はできました。

ただ、実際にやってみて分かったのは、「動くものを作る」ことと「現場で安心して使い続けられるものを作る」ことは、まったく別物だということです。

この資料では、私が実際につまずいたポイントを5つ、専門用語を使わずにお伝えします。これから自分で作ってみようという方が、同じ穴に落ちる前に知っておける内容です。

その1：最初の「分類ルール決め」で、後戻りできない差がつく

システム作りは、家づくりに似ています。壁紙の色は後から変えられますが、間取りは後から変えられません。

在庫管理でいう「間取り」にあたるのが、商品をどう分類するかのルール決めです。たとえば精肉なら——

• 部位をどこまで細かく分けるか（「ロース」で1つにするか、「リブロース」「サーロイン」まで分けるか）
• 輸入肉の部位名はどうするか（ラベルに書いてある海外の呼び方のまま登録するか、日本の部位名に読み替えるか）
• 牛と鶏で分け方を変えるか（牛は細かく分けたいが、鶏は部位が少ないので不要、など）

私はここで一度失敗しました。AIに「部位をもっと細かく分けられるようにして」と頼んだら、たしかにその通りのものができたのですが、できあがってから「自分が欲しかった分け方と違う」と気づいたのです。

AIは、指示されたものを作るのはとても速い。でも「その分け方があなたのお店の実態に合っているか」までは考えてくれません。そして分類ルールは、データを入れ始めた後に変えると、それまで入れたデータを全部直すはめになります。

先に紙に書いて、現場の人と「この分け方で困らないか」を確認してから作り始める。 遠回りに見えて、これが一番の近道でした。

その2：数字のズレは「静かに」起こる

これが、私が一番ヒヤッとした話です。

私のシステムには「入力を間違えたときの取り消しボタン」がありました。取り消すと、在庫の数はちゃんと元に戻ります。見た目上は完璧に動いていました。

ところが後から分かったのですが、在庫の「数」は戻っていたのに、裏側で計算している「原価」が戻っていなかったのです。

家計簿でたとえると、こうです。買い物をキャンセルして品物は棚に戻したのに、家計簿の支出だけ消し忘れている状態。品物を見ても異常はないので、誰も気づきません。でも月末に締めてみると、なぜか利益が実際より良く見える——。

怖いのは、エラーも出ないし、画面上は何も変に見えないことです。日々の業務では完全に正常に動いているように見えて、数字だけが静かにズレていく。私はたまたま数字を突き合わせる機会があって気づけましたが、気づかないまま「うちは儲かってる」と判断していたら、と思うとゾッとします。AIに作ってもらったシステムは「普通の操作」はだいたい正しく動きます。ズレが生まれるのは、取り消し・返品・棚卸での修正といった「たまにしかしない操作」です。そして、そこのテストを自分で思いつけるかどうかは、AIではなく作る人の経験にかかっています。

その3：トレーサビリティは、あとから付けられない

食品を扱う以上、お客様からの指摘やクレームがあったとき、「この商品はいつ、どこから仕入れたものか」を遡れる必要があります。いわゆるトレーサビリティです。

これはシステムの世界では、最初から設計に入れておかないと、後付けがほぼ不可能な代表例です。

理由はシンプルで、トレーサビリティというのは「入荷したとき」「加工したとき」「売り場に出したとき」——すべての場面で記録がつながっていることで初めて成立するからです。鎖と同じで、一箇所でも輪が抜けていたら、そこから先は遡れません。

「まず動くものを作って、記録まわりは後で足そう」と考えると、結局ぜんぶ作り直しになります。私も最初からこれを軸に据えて設計しましたが、逆に言えば、もし後回しにしていたらと考えると、作り直しの手間は想像したくないレベルです。

その4：「自分一人なら動く」と「お店で回る」の間には壁がある

自分一人で使っているときは何の問題もなかったものが、複数の人で使い始めると、急にほころびが出ます。

• 二人が同時に同じ在庫をいじったら、どうなる？
• 入力ミスに気づいたとき、「取り消す」のか「上書きで直す」のか、ルールは決まってる？
• パートさんに見せていい画面と、店長だけが見るべき画面、分けてある？

これらは不具合ではなく「決めごと」の問題なので、AIが勝手に正解を出してくれるものではありません。作る前に「誰が・どの場面で・何をするか」を洗い出しておかないと、使い始めてから「これ、決めてなかったね」が次々に出てきます。

その5：完成してからが、本当のスタート

ここまでの4つを乗り越えて現場で使い始めても、「完成」は来ません。

実際に運用すると、想定していなかった使われ方や、現場ならではのイレギュラーが必ず出てきます。私自身、リリース後も月に数回のペースで手直しが続いています。これは腕の問題ではなく、業務システムとはそういうものなのだと、作ってみて初めて分かりました。

つまり自作を選ぶということは、「作る時間」だけでなく、「この先ずっと直し続ける時間」を確保し続けるということです。本業のかたわらでそれを続けられるか——ここが、一番現実的な分かれ目だと思います。

自分で作るか、できているものを使うか

ここまで読んで、「それでも作ってみたい」と思った方は、ぜひ挑戦してみてほしいです。作る過程で業務の解像度が上がること自体に、大きな価値があります。私自身、その道を通って本当に良かったと思っています。

一方で、こう感じた方もいると思います。

「やりたいのはシステム作りじゃなくて、お店の管理をラクにすることなんだよな」

もしそちらなら、これらの壁をすでに越えてあるものを使うのが、目的への最短ルートです。

MeatShipという選択肢

私はこの経験を経て、精肉店・スーパー精肉部門専用の在庫管理システム「MeatShip」を作り、いまも運用と改善を続けています。この資料に書いた5つのつまずきは、すべてMeatShipの開発で実際にぶつかり、乗り越えてきたものです。

• 部位の分類は、精肉の実態（畜種ごとの違い・輸入肉の表記）に合わせて調整済み
• 取り消し・返品・棚卸修正を含めた「数字がズレない」仕組みを、テストを重ねて維持
• 仕入れまで遡れる記録は、最初から設計の軸に

「自分で作る大変さ」を知っている人間が作ったシステムです。同じ課題をお持ちなら、まずは実際の画面を触ってみてください。