INSIGHT
注文は取り消せた。それだけで、倉庫の出荷も止まったと思うな
注文を変更した後、倉庫でどこまで処理が進んでいるか確かめられるか。
AIで注文メールと受注台帳、倉庫への出荷指示をつないだ。取消依頼にも対応させ、試験用の注文は画面で「取消済み」に変わった。これで出荷も止まったと思ったが、倉庫側の作業と送り状がどうなったかは見ていない。
しかし、受注業務は最初の注文で終わらない。顧客が数量を減らす、送付先を変える、注文を取り消す。変更が届いた時点で、在庫は引当済みか、倉庫は梱包済みか、送り状は発行済みかによって、できる操作が変わる。登録成功の画面は、その後の状態を正しく扱える証拠にならない。
注文の表示を取り消しただけで、在庫、倉庫作業、出荷、請求まで取り消されたことにしてはいけない。
正常な一件では、注文の一生を確認できない
注文には、受付、内容確認、承認、在庫引当、出荷準備、出荷確定、請求などの状態がある。取消済み、変更待ち、保留、返品へ移る場合もある。状態遷移は、注文が現在どの状態にあり、どの条件と権限で次へ進めるかを定めたものだ。
通常の一件が通った試験で分かるのは、その入力とその時点で、予定した順番を進めたことだけである。数量変更が在庫引当後に届く、住所変更が送り状発行後に届く、取消が出荷確定後に届く、といった場面は別に確かめなければならない。
画面や台帳に「変更済み」と表示されても、倉庫のピッキング指示、送り状、請求予定まで変わったとは限らない。逆に、すべてを元の状態へ戻そうとすると、すでに完了した作業を消し、何が起きたか追えなくなる場合がある。取り消せる状態と、別の訂正・返品手続きへ移す状態を分ける。
ここで止めるのは、AIによる注文候補の作成ではない。状態と変更の到達先を確認せず、AIの判断だけで在庫・出荷・請求を確定させる経路である。候補登録と確定操作の境界を戻す。
数量変更は、在庫と倉庫作業の両方へ届かせる
顧客が100個の注文を60個へ変更した場面を考える。受付直後なら、注文候補を書き換えれば足りるかもしれない。在庫を100個引き当てた後なら、40個分を解放する必要がある。倉庫が100個をピッキング済みなら、指示の変更だけでなく、40個を在庫へ戻す確認が要る。
変更記録には、元の数量、新しい数量、顧客からの依頼、受付時刻、現在の注文状態、影響する処理を残す。AIは差分と影響候補を提示できる。しかし、顧客側の依頼権限、契約条件、倉庫の締切、値引きや送料の再計算などを確認してから、権限を持つ担当者が変更を確定する。
注文台帳だけが60個になり、倉庫指示が100個のままなら、表示上は変更成功でも業務は不一致である。逆に倉庫作業だけを止め、顧客への回答や請求予定が古いままでも完了とは言えない。受注、在庫、倉庫、出荷、請求、顧客連絡の各担当が、どの状態を正本とするかを決める。
変更を受け付けられない締切を過ぎていた場合も、AIが元注文を上書きしない。変更不能として顧客へ返す、特別承認へ回す、返品・再配送の手続きへ移すなど、現在の状態に合う処理を選ぶ。
受付時には変更可能でも、確認している間に倉庫が出荷を確定することがある。変更を反映する直前にも、対象の注文と現在状態を照合し、古い状態への承認で上書きしない。変更と出荷が同時に届く試験を担当者と行い、どちらを先に確定し、もう一方を誰へ戻すかを確かめる。
「注文を更新した」で終えず、在庫の解放、倉庫指示、金額、顧客への回答まで、変更が届いたことを確かめる。
住所変更と取消は、時点によって処理が変わる
送付先の変更は、注文受付中なら登録情報の修正で済む場合がある。送り状発行後なら、送り状の取消・再発行や倉庫への連絡が必要になる。出荷後なら、配送事業者との手続きや顧客への案内へ移る。AIが新住所を読み取れたことと、その住所へ変更できることは別である。
住所変更では、依頼者の確認、変更できる対象、締切、配送・請求先の区別、追加費用を確かめる。メールに書かれた新住所を、顧客マスター全体へ自動で反映しない。今回の注文だけの変更か、今後の登録先変更かで、必要な承認が異なる。
取消も同様である。在庫引当前なら注文を取消状態へ移せる。引当後なら在庫を解放する。梱包後は倉庫作業を止められるか確認し、出荷後は「出荷前の取消」へ戻さず、返品や受取拒否など別の業務へ渡す。履歴を削除せず、いつ、誰の依頼で、どの状態から何へ移ったかを残す。
AIが取消依頼を分類できても、顧客との契約、取消期限、費用、すでに完了した作業を確定する権限は別にある。状態ごとに、AIが作る候補、担当者が確認する証拠、確定できる役割を分ける。
一般資料を、受注処理の性能証明にしない
NIST AI 600-1 は、生成AIの虚偽出力、人とAIの役割、情報の完全性、継続評価などを整理する任意のリスク管理資料である。受注、在庫、出荷の業務状態や、個別システムの性能を実証する資料ではない。
デジタル庁の生成AIの調達・利活用ガイドライン第2.0版 は、2026年6月12日付の政府情報システム向け指針として、業務の性質、利用範囲、人の判断を経るかなどに応じたリスク評価を扱う。国の各府省庁を対象とする文書で、民間企業や地方公共団体の受注業務へ一律に適用されるルールではない。
したがって、状態図や変更手順は、これらの資料に書かれた受注モデルを転記したものではない。一般的なリスク管理の観点を、実際の受注フロー、契約、権限表、試験結果へ当てはめる編集上の提案である。採用するシステムと業務について、担当部門が正本と遷移を定める必要がある。
ガイドラインを添えたことを、変更・取消が正しく動く証拠にしない。証拠は自社の状態、権限、例外を通した試験記録で作る。
再開条件は、変更と取消を最後まで通して決める
確定操作を含む自動化を再検討できるのは、少なくとも次の条件がそろい、会社が対象と権限を承認したときである。
- 受付、承認、引当、出荷準備、出荷確定、取消、返品などの状態と、許される遷移が定義されている
- 数量・住所・納期・取消の依頼について、本人性、依頼権限、契約条件、受付締切を確認できる
- 変更が注文台帳、在庫引当、倉庫指示、送り状、請求、顧客連絡の必要箇所へ届く
- 変更不能や出荷後の依頼が上書きされず、保留・特別承認・返品などへ正しく分岐する
- AI停止時に未処理・処理中・確定済みを区別し、担当者が手作業へ引き継げる
- 各例外を業務に近い条件で試し、正本と操作記録を業務責任者が確認している
管理担当と合意した試験環境では、最初の注文だけでなく、引当前の変更、引当後の数量減、送り状発行後の住所変更、出荷前の取消、出荷後の取消依頼を通す。本番の倉庫作業や送り状を、作成者の独断で取り消して試さない。すべてを自動で処理できる必要はなく、正しく止まり、担当者へ必要な情報を渡せることも合格である。
再開範囲は状態ごとに決める。たとえば注文候補の登録までは自動、在庫引当は担当者確認後、変更と取消はすべて人が確定、と段階を残せる。対象商品の種類、金額、配送方法を限定し、監視担当と停止権限を置く。
条件が変わったら見直す。倉庫の締切、配送連携、契約、顧客マスター、AIや周辺システムの変更が、状態遷移と試験へ影響するかを確認する。以前の正常系の成功を、変更後の再開根拠にしない。
取消済みの表示で終えず、倉庫・配送・請求へ変更が届いたかを確かめる
受注から出荷までの自動化は、最初の注文を登録できたかでは評価できない。注文は途中で変わり、取り消され、ある時点を過ぎれば単純に元へ戻せなくなる。数量、住所、取消が届いた時点で、在庫、倉庫、配送、請求をどう扱うかが業務の中心である。
取消処理を加える前に、出荷前と出荷後で何が変わるかを業務担当と確かめる。注文番号をたどり、台帳、倉庫、送り状、請求のどこまで変更が届くかを試験で残す。自分の画面に「取消済み」と出ても、相手側の状態が分からなければ完了と返さず、確認できる担当へ渡す。