発注業務を自動化するには

発注業務の自動化は、最初からAIに数量の判断と送信を任せることではありません。
転記、数量の候補づくり、承認、仕入先への送信を分けると、自動化できる部分と人が確認すべき部分を決めやすくなります。

この記事では、品目マスタと発注候補表の作り方、誤発注を止める確認項目を紹介します。
計算例は説明用の架空データです。実際の発注や、AIによる需要予測の性能を検証した事例ではありません。

自動化したい発注作業を四つに分ける

転記と数量判断は、別の問題として扱う

同じ「発注が大変」でも、困っている場所は異なります。
注文内容を何度も入力しているのか、何個買うべきかの判断に時間がかかるのかを分けて書き出します。

商品コードと数量が整った表から別の表へ移すだけなら、連携機能や決まったルールで処理できる場合があります。
一方、書式の違うメールから候補を抜き出す場面ではAIの利用を検討できますが、読み取り結果を品目マスタや原文と照合する工程が必要です。

「使える機能」より「誰が確定するか」を先に決める

kintoneの受発注管理の公式案内では、項目の管理、担当者と進捗の管理、連携サービスによるフォームや帳票の活用が紹介されています。
自社が必要とする機能が標準なのか、追加サービスなのかは、契約前に切り分けて確認します。

ツールを選ぶ前に、発注候補を誰へ渡し、誰が承認すると送れるのかを図や表にします。
担当者が休みの場合や、承認後に価格が変わった場合の扱いまで決めると、運用の穴を見つけやすくなります。

品目マスタと取引条件を整える

商品名だけで同じ品目と判断しない

商品名が似ていても、容量、色、型番、入り数が違うことがあります。
自社コードと仕入先コードを対応させ、どちらのコードで発注するかを明確にします。

「1箱」と「1個」を同じ数量欄で混ぜないことも大切です。
注文単位と在庫の管理単位が異なる場合は、換算条件を持たせます。条件が不明ならAIに推測させず、候補を止めます。

在庫と入荷予定には時点を付ける

現在庫、出荷のために確保した数量、未入荷の発注分は、別の項目にします。
同じ発注分を「現在庫」と「入荷予定」の両方へ入れると、使える数量を多く見積もってしまいます。

また、古い在庫数を最新の受注と組み合わせないよう、更新時刻と集計対象を保存します。
入荷日は確定しているか、必要な時期に間に合うかも確認します。入荷の可能性があるだけの数量を、確実に使える数量として扱いません。

発注候補は、条件と計算の理由を見える形にする

発注点と補充する量を分ける

発注点は、補充を検討し始める基準です。
その基準に達したときに何個補充するかは、発注単位や保管条件なども含め、別に決めます。

需要予測を導入する前でも、まず社内で合意したルールから候補を作り、人の判断と比較できます。
需要が大きく変動する商品、期限の短い商品、代替品のある部材などに、同じ計算を一律に使うのは避けます。

架空の包装資材で計算する

次は、品目P-101という架空の包装資材を使った説明例です。
予約済みの数量は出荷用に確保した分、入荷予定は必要な時期までに確実に届くと確認できた未入荷分、という前提です。別途、期間中の需要予測は加減しません。

この例で判定に使う数量は、42−8＋20＝54個です。
60個以下なので候補を作り、100個との差である46個を、12個の倍数へ切り上げます。
結果は48個で、最低注文数量24個も満たします。単価だけの小計は48×80＝3,840円です。

48個を追加した計算上の数量は102個となり、目安の100個を少し上回ります。
この差を許容できるか、保管場所や使用期限に問題がないかは、担当者が確認します。計算が合っていても、発注してよいとは限りません。

なお、これは記事用に定義した簡略ルールです。
需要予測を使う設計では、確定した受注と予測需要を二重に引かないことや、入荷前に欠品しないかを時系列で確認する必要があります。

候補表には承認前の状態を残す

担当者が数量を変える場合は、元の候補、変更後の値、理由、確認者を残します。
「AIが出したから」「いつもこの数だから」で確定せず、どの条件で決めたかを後から説明できるようにします。

誤発注を止める条件を先に試す

正常に動く例だけで完了にしない

この記事では、前述の架空データを使い、候補作成の条件をローカルの簡単なプログラムで照合しました。
通常時と、データの不一致・不足がある場合を合わせた10条件で、設定した結果になることを確認しています。

検証したのは、この例の計算と停止分岐です。
外部への送信、複数人の同時操作、本番システムとの接続、AIの読み取り精度は、この検証の対象に含めていません。

停止した案件は一覧に残し、担当者へ理由と元資料を渡します。
止めるだけで誰にも伝わらない仕組みでは、必要な発注が抜けるためです。

送信の成否が分からないときに、同じ注文を再送しない

送信の途中で通信が切れた場合、画面に成功が出なくても、相手側では受け付けられている可能性があります。
結果が不明な状態を「未送信」と混ぜず、受付番号や相手側の記録を確認してから次の操作を決めます。

設計時には、注文ごとの識別子、送信内容の版、承認記録、送信結果を対応させます。
重複防止は担当者の目視だけに頼らず、同時操作を含む登録・送信側の仕組みでも確認します。

承認後に数量や仕入先が変わったら、承認をやり直すルールにします。
取消ボタンを押せることと、取引先で取消が受け付けられたことも別です。取引条件に沿った確認と記録が必要です。

効果は、修正と例外対応まで含めて測る

作成時間だけを短縮率にしない

候補表を作る時間が減っても、誤りの確認や修正に時間がかかれば、業務全体は軽くなっていないかもしれません。
準備、入力、確認、差し戻し、例外対応を同じ範囲で記録します。

停止が多い場合は、基準を緩める前にマスタや入荷予定の更新が追いついているかを確認します。
また、売上や繁忙期の変化も記録し、自動化だけの効果と断定しないようにします。

小さな範囲で、人の判断と並べて確認する

最初は品目と仕入先を絞り、候補だけを作って、これまでの担当者の判断と比較します。
差があったら、人が正しいともシステムが正しいとも決めつけず、使ったデータと条件を照合します。

実際に送信する範囲を広げるのは、担当者、停止条件、復旧手順、取引先との受け渡しを確認してからです。
需要予測の導入も、履歴の量だけでなく、終売や欠品、特売をどう記録しているかを見て判断します。

よくある質問

AIが発注数量をすべて決められますか？

自社のデータや運用条件を確認せず、すべて任せる判断はできません。
需要の候補を出すAIと、仕入先へ発注する権限は分けて考えます。高額、例外、情報不足の案件は人の確認へ戻す設計から始めましょう。

Excelの管理から始められますか？

項目や計算ルールの整理は、いまの表から始められます。
ただし複数人の同時編集、承認履歴、アクセス権、重複防止まで必要な場合は、その表だけで管理できるかを確認します。
表の計算が動くことと、本番の発注を安全に実行できることは別です。

必ず需要予測AIを導入した方がよいですか？

転記や帳票作成が主な負担なら、既存システムの連携やルールによる処理から改善できる場合があります。
数量判断のばらつきが主な課題なら、データの状態と予測を使う場面を整理して検討します。技術の名前から導入範囲を決めないことが大切です。

一つの品目から、止める条件を決める

最初の作業は、現在庫と入荷予定をそろえ、ひとつの品目で発注候補を作ることです。
正常な計算だけでなく、不足情報や重複があるときに止まり、担当者へ戻るところまで確認しましょう。

業務に合わせたAI活用や、導入後の見直しについては、AI顧問の支援内容をご覧ください。