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

FAX・メール受注の課題

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

見積・受注の業務を分解する

見積・受注は1つの作業ではなく、性質の違う工程の連なりです。工程ごとに、システムやAIが作れるのは「候補」までで、何を人が確定するかを分けておきます。

標準フローと例外フロー

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

品番・顧客・価格マスタ

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

見積・承認・納期回答

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

EDI・OCR・AIの使い分け

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

見積生成の技術デモ

案件の文章から、条件と品目を対応付けたルールセットと過去案件の類似検索をもとに見積の下書きを生成し、構造化して受注・工程・原価へ引き渡す仕組みを、実際に動く技術デモとして公開しています。顧客の実案件の成果ではなく、架空のデータで仕組みを示す技術例です。

• 見積生成の技術デモを実際に動かす — 架空の案件文を入れると見積の下書きが生成され、根拠になったプロンプトの全文も見られます

デモの出力は正式な見積ではありません。金額は架空のルールと単価によるもので、実装した場合も、担当者が確認・承認した内容だけを確定金額にする前提で設計します。顧客の図面や見積書はデモに入力しないでください。入力内容は保存していません。この構成は当社が特許出願しています（特願2026-152037）。

Dandori AIを使う場合の範囲

Dandori AIは、当社が開発した見積作成のAIエージェントです。製造業の見積に使えるかは、業務とデータを確認してから判断する候補の1つとして扱います。標準で使える機能、個別開発で足す部分、まだ検証していない部分を分けて示します。

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

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

監査ログと訂正の扱い

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

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

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

相談の前に手元で整理すること

相談の前に、次の項目を手元のメモで整理しておくと、最初の打ち合わせで標準機能で扱える範囲と個別開発が要る部分を切り分けやすくなります。すべて埋まっていなくても構いません。顧客名、注文書・見積書の実物、取引単価は書かないでください。

よくある質問

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

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

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

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

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

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