製造業の受発注・見積業務をシステム化する

FAX・メール受注の課題

• 注文書の内容を人が基幹システムへ転記しており、繁忙期に滞留する
• 顧客ごとに品番体系が違い、自社品番への読み替えが属人化している
• 納期回答のために、在庫と工程の状況を都度確認している
• 見積の根拠が個人のExcelにあり、過去見積を参照できない
• 訂正・取消の連絡がメール本文に埋もれ、反映漏れが起きる
• 誰がいつ承認したかが残らず、条件の食い違いが後から判明する

標準フローと例外フロー

受注業務の工数の多くは例外処理に費やされます。自動化の対象を標準フローだけに置くと、効果が出ないまま運用が複雑になります。

品番・顧客・価格マスタ

• 顧客品番と自社品番の対応表（1対多、多対1の両方が発生する）
• 単価の適用ルール（契約単価、数量帯、期間、キャンペーン）
• 納入先・出荷条件（分納可否、指定便、荷姿）
• マスタの保守担当と、誰が変更を承認するか
• 基幹側とどちらを正とするか（重複管理を避ける）

見積・承認・納期回答

• 見積の入力を、過去の類似案件・図面から引ける状態にする
• 見積の版と、提出した内容の記録を残す（提出後の変更をたどれるようにする）
• 承認基準（金額、値引率、新規顧客など）を条件として持たせる
• 納期回答は、在庫、手配状況、工程の負荷のどれを根拠にするかを決める
• 回答した納期と、実際の納入日の差を記録し、後で精度を検証できるようにする

EDI・OCR・AIの使い分け

自動抽出を入れる場合は、「どの項目を自動で入れ、どの項目は必ず人が見るか」を項目単位で決めます。全項目を一律に自動化すると、確認コストが増えて逆効果になります。

見積生成の技術デモ

案件の文章から、条件と品目を対応付けたルールセットと過去案件の類似検索をもとに見積を生成し、構造化して受注・工程・原価へ引き渡す仕組みを、実際に動くデモとして公開しています。生成の根拠になったプロンプトの全文も画面で確認できます。

• デモのURL: /manufacturing/demo/quotation
• 主体（テナント）ごとにルールセットと過去案件が分かれること
• 条件で金額が変わる品目を「要確認」として区分すること
• 見積の構造化データが、そのまま製造指示と原価差異につながること

デモのデータは架空のサンプルで、入力内容は保存していません。この構成は当社が特許出願しています（特願2026-152037）。

ERP・販売・生産システムとの連携

• 受注データを基幹へ登録するタイミング（承認後か、受領時点か）
• 在庫・手配状況を参照する方式（API、DB参照、定期取り込み）
• 生産側への引き渡し（製造指示の起票をどちらで行うか）
• 訂正・取消を両システムへ反映する順序と、失敗時の復旧
• 請求・出荷との突合に必要なキーの持ち方

監査ログと訂正の扱い

• 受注内容の変更履歴（いつ、誰が、何を、なぜ変えたか）を残す
• 提出済みの見積・回答納期は上書きせず、版として保持する
• 取消・訂正は削除ではなく、取消記録として残す
• 権限（単価の閲覧・変更、承認）を役割ごとに分ける

費用と期間を左右する条件

• 受注経路の数（EDI、メール、FAX、電話、Web）
• 取引先ごとの個別仕様の数
• 品番・単価マスタの整備状況
• 承認フローの分岐の多さ
• 基幹システムとの連携方式と、相手側の改修要否
• OCR/AIを使う場合の評価と確認画面の作り込み

よくある質問

FAX受注をゼロにできますか。

取引先の運用に依存するため、短期でゼロにするのは現実的ではありません。実務では、取引量の多い先からEDIや所定フォーマットへ移行し、残るFAXは受け取り後の転記工数を減らす（OCR・AI抽出＋人の確認）方向で設計します。

注文書をAIに読ませる場合、精度はどのくらい必要ですか。

一律の基準はありません。決めるべきは「間違えたときに誰が気づくか」です。品番と数量のように誤りが即納入ミスにつながる項目は、抽出結果を確認画面で必ず人が承認する設計にします。精度目標は、その確認工数が現状の転記工数より小さくなるかで判断します。

基幹システムを変えずに受発注だけ改善できますか。

できます。受注の一次受け（受領、照合、確認、承認）を前段のシステムで行い、確定したデータだけを基幹へ登録する構成が一般的です。この場合、どちらを正とするか、訂正時にどちら側から反映するかを設計時に確定させます。