自動発注の仕組みを作る｜送る前に止める業務自動化の設計

発注書を送る。請求書を出す。振込データを作る——。どれも、送ってしまえば取り消せない処理で、自動化でいちばん慎重に組む場所です。

業務自動化でできること一覧の記事では、製造業・建設業・物流業の30の業務を洗い出し、4つの処理の型に分けました。

• 取り込み型：形の決まっていない入力を読み取り、台帳に入れる
• 照合型：2つの台帳、または台帳と今日の日付を突き合わせる
• 下書き型：過去のデータを探し、文書の下書きを作る
• 実行型：発注・振込などの確定処理を実行する

この記事が扱うのは、いちばん後ろにある実行型です。前の3つの型が動いていないとこの型は組めないため、最後に取り上げます。

台帳の数字が合っていない状態で発注を任せると、間違った数量がそのまま仕入先に届きます。発注の自動化は、前の型で台帳を合わせてからの話です。

代表例は、在庫が決めた数を下回ったら発注する自動発注です。人が承認してから送る仕組みを設計図とn8nで組んだ形で示し、同じ設計を請求や振込へ広げるときの違いもまとめます。

発注も請求も振込も「取り消せない処理」

実行型の業務は、どれも同じ性質を持っています。仕組みが動いた結果が、会社の外に出ていく点です。

次の表は、この記事で扱う実行型の業務です。

業務	適性	恩恵	着手	人の接点
更新時期・点検時期からの掘り起こし	◎	売上	すぐ	承認
発注点管理と自動発注	◎	時間・ミス	要準備	承認
保守・修理の受付から手配まで	○	売上・時間	すぐ	承認
出荷と送り状・納品書の作成	○	時間	すぐ	無人
請求書の発行と送付	○	時間	すぐ	承認
支払と振込データの作成	○	時間	すぐ	承認
配車と運行計画の作成	△	時間	要準備	画面

表の記号は次のとおりです。

• 適性：◎は恩恵が大きい、○は恩恵がある、△は限定的
• 恩恵：時間（時間短縮）、ミス（ミス防止）、売上（機会損失の防止）
• 着手：「すぐ」は手元のデータで始められる、「要準備」はマスタの整備や入力の習慣づけが要る
• 人の接点：無人／通知／承認／画面の4段階

前の3つの型と違うのは、やり直しが効かない点です。取り込みで読み間違えても台帳を直せば済み、照合で差分を見落としても翌朝もう一度拾えます。

実行型は違います。仕入先に届いた発注書は電話で謝って取り消すしかなく、振込は着金してから相手に戻してもらうことになります。

そのため、この型だけは人の接点を原則として「承認」にします。無人にするのは、出荷のように前の工程で人が確かめ終わっている業務だけです。

自動発注のデメリットと事故の本当の原因

発注の事故は、自動化する前から起きています。

部材を数百品目抱える町工場を考えます。担当者は週に1度、棚と在庫表を見比べて足りない品目を拾い、品目ごとに違う仕入先へ、違う書式で発注します。

この流れでよく起きる事故は、次の3つです。

• 二重発注：同じ品目を二度発注してしまう
• 発注漏れ：発注書を作ったまま、送るのを忘れる
• 数量の桁違い：50個のつもりが500個になる

二重発注は、担当者が複数いると起きやすくなります。1人が発注したことを別の担当者が知らずに重ねて発注するほか、FAXの送信エラーのあとに念のため再送して起きることもあります。

ここで押さえたいのは、自動化すれば事故が勝手になくなるわけではない点です。自動化の条件は、今より事故を増やさない形を作ることです。

自動発注には、手作業と違うデメリットもあります。

1. 間違いを繰り返す：人なら一度で気づく二重発注も、仕組みは同じ速さで繰り返す
2. 台帳の誤りがそのまま出る：在庫数や発注点がずれていると、ずれた数量で発注する
3. 任せきりになる：自動だからと見なくなり、発注点が実情とずれても気づかない

この記事の設計は、1つ目の「繰り返す」事故を防ぐためのものです。2つ目は前段の型で台帳を合わせておくこと、3つ目は発注点の見直しと定期の点検で防ぎます。

既製の在庫管理ソフトで足りるかを確かめる

自分で組む前に、今使っているソフトの機能を確かめてください。既製の機能で足りるなら、この記事の仕組みは要りません。

自動発注に使える手段には、次のようなものがあります。きれいに分かれるものではなく、1つの製品が複数を兼ねることもあります。

手段	できること	残る手間
販売管理・在庫管理ソフトの発注点の機能	発注点を割った品目を知らせる。発注書の作成まで用意されているものもある	承認の記録や送り方は製品による
重さで数える在庫管理（IoT重量計）	部材の重さから数を数え、減ったら発注まで任せられる製品もある	計量器の設置と費用がかかる
需要予測型の自動発注システム	販売実績や天候などから発注量を予測する	小売・食品の店舗向けが多く、部材の発注とは前提が違う
表計算の在庫表	関数で、発注が要るかどうかを判定できる	発注書を作って送るのは人

クラウドの在庫管理システムの発注点の機能と料金は、小規模製造業の在庫管理システム比較で扱っています。Excelの在庫表で発注の要否を出す関数は、在庫管理表をエクセルで作る方法にまとめています。

既製の手段では足りなくなるのは、次のような場合です。

• 在庫が表計算ソフトにあり、ソフトの中に入っていない
• 発注の手段が、仕入先ごとにFAX・メール・取引先の画面に分かれている
• 承認の記録を残したいが、ソフトに承認の仕組みがない
• 発注のほかに、請求や振込も同じ形で任せたい

この記事で組むのは、台帳と承認と送信をつなぐ部分です。ソフトの発注点の通知で足りる会社は、承認と送信の決めごとだけを参考にしてください。

仕組みに任せる範囲と人に残す判断

実行型は、4つの型のなかでAIをいちばん使いません。仕組みに任せるのは答えが1つに決まる作業、人に残すのは仕組みが知らない事情の判断です。

作業	受け持ち	中身
検知する	仕組み	在庫数と発注点を比べる
発注案を作る	仕組み	品目ごとの発注先と発注量を台帳から写す
送る	仕組み	承認されたものを、決まった書式で決まった相手に送る
発注してよいか決める	人	この品目を今発注してよいか、数量は妥当か
発注先を確かめる	人	発注先は合っているか

来月に生産を止める品目や仕入先の値上げの予定は、台帳に書かれていません。承認は、そうした台帳の外の事情を判断に差し込む工程です。

発注の判断にAIを使わない

自動発注とは、在庫や販売の状況をもとに、システムが発注の案を作って発注する仕組みです。いつ・どれだけ発注するかの決め方には、大きく3つの方式があります。

方式	決め方	よく使われる場面
発注点方式（定量発注）	在庫が発注点を下回ったら、決めた量を発注する	使う量が安定している部材・消耗品
定期発注	決めた日に、その都度量を計算して発注する	発注日が決まっている品目
需要予測型	販売実績や天候などをAIが分析し、発注量を出す	売れ方が揺れる小売・食品の商品

この記事は発注点方式で組みます。発注の判断は数字の比較で決まるため、ここにAIを挟む理由がありません。

むしろ、判断の理由が追えなくなる方が問題です。「なぜこの数量になったのか」を後から説明できない発注は、仕入先にも社内にも通りません。

ルールで決めておけば、台帳の発注点と発注量を見せるだけで説明がつきます。AIを使うとしても納期の相談を添える一文を整える程度で、金額・数量・発注先は台帳の値をそのまま使います。

前提として、前段の2つの型が動いている必要があります。在庫数が合っているのは数字合わせと期限チェックの仕組みが、入荷の数字が入っているのは手入力をやめる設計が動いているからです。

発注点と発注量を先に決める

発注点と発注量を決めておくことが、自動化の前の準備です。この業務の着手が「要準備」になっているのは、このためです。

発注点は、在庫管理で広く使われる「1日の使用量×調達にかかる日数＋安全在庫」の考え方で決めます。

1. 1日に使う量に、注文から届くまでの日数を掛ける
2. そこに、切らしたときの痛みに応じた余裕分（安全在庫）を足す

たとえば1日に20本使う六角ボルトが注文から5日で届くなら、20本×5日で100本です。余裕分を40本足して、発注点は140本になります。

在庫台帳には、品目ごとに次のように書いておきます。例の値は架空のものです。

品目	在庫数	発注点	発注量	発注先
B-0042／六角ボルト	120	140	500	S0007

品目ごとの発注点が担当者の頭の中にしかないなら、先に書き出します。書き出し方は業務の属人化解消の進め方にまとめています。

発注点は一度決めて終わりではありません。使う量や納期が変わったら見直し、欠品や余りが続く品目から直します。

承認はメールかチャットで済ませる

承認のためだけに画面は作りません。承認は、台帳の「状態」の欄を書き換えるだけで済むからです。

通知に台帳の該当行を開くリンクを載せておけば、担当者はリンクを開いて欄を変えるだけです。

通知には、判断に要る次の5つだけを載せます。

• 品目
• 数量
• 発注先
• 今の在庫数と発注点
• 前回の発注日

これだけあれば、たいていの案件は短い時間で判断できます。

承認依頼はこの形で届きます。担当者は台帳のリンクを開き、状態を「承認済」に変えれば承認は終わりです。

承認依頼は1件ずつ送ります。まとめて送るとどれを承認したのかが曖昧になるため、承認の単位と発注の単位をそろえます。

承認には期限を付け、期限を過ぎた案件は自動で承認せずに差し戻して、担当者に知らせます。放っておくと承認される仕組みでは、承認を挟む意味がありません。

承認者が出張や休暇で不在のときも、同じ扱いで止まります。止まった案件が台帳に残るので、代わりの人が見て判断できます。

自動発注の設計図を描く

ここがこの記事の中心です。データの流れ、台帳の項目、状態の進み方、処理の決めごとの順に見ていきます。

データの流れ

流れは、次の4つの段階に分かれます。

1. 毎朝、在庫台帳と発注台帳を見て、発注点割れを拾う
2. 発注案を発注台帳に書き、承認者に知らせる
3. 承認された案件だけを、あとから拾って送る
4. 送った結果を発注台帳に書く

図の点線から下は人の仕事です。仕組みが受け持つのは、発注案を作って知らせるところと、承認されたものを送るところで、送ってよいかを決めるのは承認者です。

発注点割れを拾うときは、在庫台帳だけを見ません。在庫が増えるのは品物が届いてからなので、発注してから入荷するまでの間、在庫台帳は「足りない」と判定し続けます。

そのため発注台帳も一緒に見て、未完了の案件がある品目を外します。

発注台帳に持たせる項目

発注台帳には、次の項目を持たせます。例の値は架空のものです。

項目	内容	例
案件ID	発注点割れを見つけた時点で振る番号	PO-20261005-003
検知日時	発注点割れを見つけた日時。承認の期限を数える	2026-10-05 07:00
品目	品目コードと品名	B-0042／六角ボルト
数量	発注する数	500
発注先	発注先台帳の取引先コード	S0007
状態	検知／承認待ち／承認済／送信済／完了／差し戻し	承認待ち
承認者	承認した人	（空欄）
承認日時	承認した日時	（空欄）
処理済	送信に手をつけた印	（空欄）
送信日時	送信に成功した日時	（空欄）

鍵になるのは「案件ID」です。発注点割れを見つけた時点で振って最後まで変えないため、同じ案件を二度処理していないかをこの番号で確かめられます。

「処理済」と「送信日時」を分けて持つのが、この台帳の要点です。処理済は送信に手をつけた印、送信日時は送れた記録で、2つが食い違う行が人の確かめる行になります。

配布するワークフローでは、承認した時点の連絡先で送れるよう、発注先の社名とメールアドレスも台帳の行に書いています。

状態は後戻りさせない

状態は、次の順にしか進みません。

検知 → 承認待ち → 承認済 → 送信済 → 完了

承認者が差し戻した案件は「差し戻し」で終わり、承認待ちには戻しません。発注し直すときは、新しい案件として作ります。

後戻りを許さないのは、重ねての実行を防ぐためです。送信済の案件を承認済に戻せる形にすると、仕組みはその案件を未送信とみなして、もう一度送ります。

状態を誰が変えるかも、次のように決めておきます。

• 承認待ち → 承認済：承認者が台帳で書き換える
• 承認済 → 送信済：送る側の仕組みが書く
• 送信済 → 完了：品物が届いたときに担当者が書き換える

トリガーと例外の決めごと

処理の決めごとを、1枚の表にまとめます。

項目	内容
トリガー	発注案を作る側は毎朝の決まった時刻、送る側は5分おき
入力	在庫台帳（品目、在庫数、発注点、発注量、発注先）、発注台帳、発注先台帳
処理	発注点割れの検知 → 未完了の案件の確認 → 発注案の作成 → 承認 → 送信
出力	発注台帳への追記、承認者への通知、仕入先への発注書、送信結果の書き込み
例外	発注先の連絡先がない、送信の失敗、承認の期限切れ

例外は、先に扱いを決めておきます。

• 発注先の連絡先がない：案件は作り、状態を「差し戻し」にして知らせる
• 送信の失敗：自動で再送せず、処理済の印を残したまま知らせる
• 承認の期限切れ：3日たっても承認されない案件は差し戻して知らせる

差し戻した案件は、送る側の仕組みが拾いません。送る側が拾うのは「承認済」の行だけだからです。

承認の期限の3日は仮の値です。急ぎの部材が多い業種では、もっと短くします。

自動発注をn8nで組むとどうなるか

設計図を n8n で組むと、2つのワークフローになります。毎朝動いて発注案を作る「判断まで」と、5分おきに台帳を見に行って送る「承認後の実行」です。

この記事では、設定の細かい手順は載せていません。手順は、配布するワークフローのJSONにまとめています。

四角の1つひとつが、小さな仕事を表しています。図の中の英語は画面に出るとおりの名前で、読み解く必要はありません。

この記事で押さえてほしいのは、次の3つの決めごとと、組む手間です。

毎朝拾い、未完了の品目は外す

起点は毎朝の決まった時刻で、在庫台帳を読み、発注点を下回った品目を拾います。入出庫のたびに動かすと1日のうちに同じ品目の発注案が何度もできるため、1日1回にまとめます。

n8nを自社のサーバーに置く場合、タイムゾーンの初期値は米国東部時間（America/New_York）です。ワークフローかサーバーのタイムゾーンを日本時間にしないと、「毎朝7時」が日本の朝7時になりません。

発注点を割った品目が見つかっても、すぐには案件を作りません。先に発注台帳を見て、その品目に未完了の案件（承認待ち・承認済・送信済）が残っていないかを確かめます。

この確認がないと、次のような事故が起きます。月曜の朝にボルトの在庫が発注点を割り、仕組みが発注案を作って「承認待ち」にします。

承認者が休んでいて火曜の朝も承認されていないと、在庫は発注点を割ったままなので、仕組みは同じ品目の発注案をもう1つ作ります。両方が承認されれば二重発注です。

送る直前に読み直して印を書く

送る側の仕組みは、5分おきに発注台帳を見に行きます。拾うのは、状態が「承認済」で「処理済」の欄が空の行です。

拾ったら、送る前にその行をもう一度読み直します。最初に読んだ時点から送る直前までの間に、別の回の実行が先に手をつけている場合があるためです。

読み直しても処理済の欄が空なら、送る直前に処理済の印を書き、それから送ります。「送ってから印を書く」順番にはしません。

送ってから書く順番だと、送信が済んでから印を書くまでの間に仕組みが止まったとき、相手には届いたのに台帳では未送信の行が残ります。次の回の仕組みは、その行を未処理とみなして二度目を送ります。

印を先に書くと、逆に「印はあるのに送れていない行」が出ることがあります。これは発注漏れの側なので、通知で人が気づけます。

二重発注は、一度相手に届くと自動では取り消せません。迷ったときは「二度送る」より「一度も送らない」側に倒します。

失敗しても自動で再送しない

送信の失敗には、2つの場合があります。

• 発注が相手に届いていない
• 発注は届いているのに、成功の返事を受け取れなかった

後者は珍しくありません。送信サービスが送り終えた直後、結果を返す手前で通信が切れた場合などで、ここで自動で再送すると二重発注になります。

そのため、送信に失敗しても自動では再送しません。処理済の印は残し、送信日時は空のままで担当者に知らせます。

担当者は仕入先に届いたかを確かめ、届いていなければ手で送り直します。

処理済の印があって送信日時が空の行は、送ったかどうか分からない行です。この行を毎朝まとめて知らせる形にしておけば、見落としが減ります。

動かしてからの手間

この仕組みを組むときに手がかかるのは、組む作業より準備です。品目ごとの発注点が決まっていないと、仕組みは動かせません。

動かし始めてからの手間は、週に1度の点検です。送ったかどうか分からない行と、差し戻しのまま残っている案件がないかを確かめます。

請求・振込・出荷へ広げるときの違い

発注で組んだ仕組みは、ほかの実行型の業務にもほぼそのまま使えます。変わるのは、起点と送る中身と検査の項目です。

次の表は、発注との違いをまとめたものです。

業務	トリガー	入力	処理	出力	例外
発注点管理と自動発注	毎朝の定時	在庫台帳、発注台帳	発注点割れの検知 → 発注案 → 承認 → 送信	発注書	送信の失敗、承認の期限切れ
更新時期・点検時期からの掘り起こし	毎週の定時	顧客台帳、設備台帳	時期の近い顧客の抽出 → 案内文 → 承認 → 送信	案内メール	連絡先の不備、取引停止中の顧客
保守・修理の受付から手配まで	受付の到着	受付内容、担当者の予定	担当者の候補 → 承認 → 手配	手配の連絡	担当者の空きがない
出荷と送り状・納品書の作成	受注の確定	受注台帳	送り状と納品書の作成	送り状データ、納品書	住所の不備
請求書の発行と送付	月末の締め	売上台帳	請求書の作成 → 金額の検査 → 承認 → 送付	請求書	金額の外れ、送付先の変更
支払と振込データの作成	支払日の数日前	買掛台帳	振込データの作成 → 金額の検査 → 承認	総合振込データ	口座の変更、金額の外れ
配車と運行計画の作成	前日の定時	出荷予定、車両データ	配車の下書き	配車表の下書き	車両の不足

発注と違う点が大きいのは、次の3つの業務です。

1. 請求と振込：承認の前に、金額の検査を挟む
2. 出荷：前の工程で確かめ終わっているので、承認を挟まない
3. 配車：仕組みは下書きまでにして、人が画面で決める

請求と振込で人が見るのは、外れた金額だけにします。前月と比べて大きく動いた請求先や、決めた上限を超える振込を条件で拾い、印を付けて通知に載せます。

全件を目で確かめる運用にすると、締めの数日に作業が集中し、手作業と変わらなくなります。

振込は、仕組みが作るのは振込データまでにします。銀行の法人向けサービスには、全銀協の定めた形式（全銀協規定形式）の総合振込ファイルを取り込んで振り込む方法があります。

銀行によっては、振込をAPIで依頼することもできます。たとえばGMOあおぞらネット銀行は振込依頼や総合振込依頼のAPIを公開しており、自社で接続するには申込と審査が要ります。

どちらの方法でも、銀行に送る最後の操作は人が行う形にします。着金したお金は、仕組みの側から取り消せないためです。

請求書をデータで送る場合は、インボイス制度の記載事項と、電子取引としての保存の要件があります。要件は国税庁のインボイス制度の特集ページや顧問の税理士に確かめてください。

送った請求書の保存先の決め方は、電子取引データの保存先を決めるにまとめています。

出荷と送り状の作成だけは、人の接点が無人です。起点になるのは確定した受注で、中身は取り込みの段階で担当者が承認しているため、もう一度承認させても確かめる材料が増えません。

配車は、仕組みが最後まで決めません。車両と運転者の組み合わせには、その日の体調や荷主との相性など台帳にない事情が多く入るため、この業務だけは下書きまでにして画面で決めます。

運用でつまずかないための事前対策

取り消せない処理の自動化は、組むこと自体はそれほど難しくなく、つまずくのは動かしたあとです。よく出る3つの問題と、仕組みを止めるときの備えを挙げます。

手動の再実行で重ねて送る

送信が失敗したと思った担当者が、手で再実行してしまうことがあります。送る処理が長引いたときに、次の回が重なって動くこともあります。

これを完全に防ぐことはできません。だから、重ねて実行しても結果が変わらない作りにします。

この性質を、べき等性（idempotency）と呼びます。案件IDで行を特定し、送る前に処理済の印を書く設計は、べき等性を台帳で持たせるためのものです。

承認のあとに台帳を書き換えない

承認してから送るまでの間に、台帳の数量や発注先を書き換えたくなることがあります。承認されたのは、そのときの数量と発注先です。

承認済の行は書き換えない決まりにし、変えたいときは差し戻して、新しい案件として作り直します。

送る側の仕組みは、送る直前に読み直した台帳の行の値で送ります。発注先の連絡先も行に持たせておけば、承認のあとで発注先台帳が変わっても、承認した時点の宛先で送れます。

送信先の連絡先が古くなる

仕入先の担当者やメールアドレスは、思ったより変わります。発注先台帳の連絡先は、半年に1度は確かめる運用にします。

送信の失敗が続く発注先があれば、まず連絡先の変更を疑います。

止められる、見える、戻れる形にする

取り消せない処理を任せる仕組みには、次の3つの備えを置きます。

1. 止められる：担当者が押せる場所に、送信を止めるスイッチを置く
2. 見える：引っかかっている行を、毎朝まとめて知らせる
3. 戻れる：止めたときに手作業へ戻す手順を、先に書いておく

止めるスイッチは、n8nの画面を開かなくても使えるようにします。台帳に「停止」の欄を作り、印が付いていたら送る側の仕組みが送らない形です。

知らせるのは、送ったかどうか分からない行と、差し戻しのまま残っている案件です。正常に動いていることではなく、引っかかっていることを知らせます。

戻る手順には、どの台帳を見て、誰がどの順で手で送るかを書きます。書いていないと、止めた日に現場が混乱します。

AIやクラウドが止まったときの備えはAIが止まると業務も止まるに、月ごとの点検の進め方は運用と保守の記事にまとめています。

まとめ

取り消せない処理を任せる設計とは、送る前に止める場所と、二度送らない仕掛けを作ることです。発注点割れを拾うときは発注台帳も見て、状態は後戻りさせません。

この記事で組んだワークフローは、JSONで配布しています。記事で説明した中心の流れだけを組んだもので、承認の期限切れの差し戻しや、送ったかどうか分からない行の朝のまとめ通知は、運用に乗せるときに足す前提です。

ワークフローのJSONを受け取る

ほかの業務の自動化の向き不向きは、業務自動化でできること一覧にまとめています。承認の前に見積りなどの文書をAIで下書きする型は、次の記事で扱っています。