受注業務AI化システム 設計大枠

01設計の目的とスコープ

目的

• FAX・メールの目視と手入力による受注処理を、AIの下書き＋短時間の人の確認に置き換える。
• 発端はAIではない。BCPが動機。地方拠点は採用が難しく、人が減っても入ってこない前提で、今より少ない人員で回す体制を作りたい (00:18:15, 00:19:32)。
• 各拠点がFAXを受けているため、クラウドに上げれば他拠点からも見られ、災害時の代替手段になる (00:18:15)。

対象（案）

FAX・メールの取込と項目抽出、スマイルV2への登録準備、在庫判断と仕入先への発注準備、確認UI。

対象外（案）

スマイルV2の改修・置換、電話対応の自動化、売上計上ロジックの変更（納期到来で計上する現行運用は維持 00:11:50）。

前提

• スマイルV2（大塚商会）は5年リース中で外せない。連携させたい (00:23:20)。
• ノーカスタマイズ運用。過去に完全オーダーメイドで自分ルールが多発し、改修に費用と時間がかかった経験がある (00:14:55)。
• AI活用のルールは未整備。ChatGPT（有料）を資料作成に使う程度で、業務への落とし込みは未経験 (00:01:14, 00:05:01)。

02As-Is 業務フロー

1件あたりの処理時間についての発言はなし。要確認

03To-Be 業務フロー

Ceedが示した理想像は「FAX・メールをAIが読み、発注書・請求書、在庫判断、発注準備まで行い、人は1日10〜15分の確認のみ」(00:20:53)。熊地様からは「そこまで信用していいか分からない」との発言があった (00:22:07)。熊地様ご自身のイメージは、複合機のデータをOCRしてCSVで販売システムに入れ、人は確認だけ、という形 (00:22:07)。

04全体アーキテクチャ

FAXの受信方式（複合機か、クラウドFAXか等）は 要確認。

05データモデル

• 顧客ごとの呼び名とコードの対応表を持つ。正式名称以外で書かれるため (00:25:26)。
• マスタの正はスマイルV2とする案。業務DB側に持つ写しの範囲は 要確認。

06AI処理パイプライン

• 過去のFAXは紙で保管されている (00:26:38)。Ceedは、これをAIに事前学習させれば顧客ごとの書き方の違いも判別できると説明した (00:26:38)。量と使用可否は 要確認。
• 新しい書式では数%の誤りが起こり得るが、一度フィードバックすれば学習する、という説明 (00:26:38)。これは精度の保証値ではない。
• 信頼度の閾値は 仮置き。実データで調整する。

07スマイルV2との連携方式

• 推奨は、まずAの可否を確認し、不可ならCから始めること（Ceed案）。いずれの案でもV2側は改修しない。
• 確認事項：一括取込の有無と形式、API、マスタ・在庫データの出力方法、リース・保守契約上の制約。窓口は未確認。

08人の確認UI

先方の懸念

紙1枚を見る確認から、データの文字の羅列を確認する作業に変わること。社員に向く作業かどうか (00:27:38)。

Ceedの回答

確認すべき箇所だけを視覚的に示すUIを、社員の特性に合わせて作る (00:28:56)。熊地様の案は、左に原本画像を置き、AIが不明瞭とした箇所にチェックを付ける形 (00:28:56)。

09段階導入計画

Ceedは、3ヶ月で1つ作る形から始め、半年の契約が多いと説明した (00:38:20)。以下は計画案で、先方とは未合意。

• 費用の目安は1人月50万円 (00:37:03)。1名の単純計算で3ヶ月は150万円、6ヶ月は300万円。人数と税の扱いは 要確認。
• 先方の懸念は、急な業務変更に社員がついてこないこと (00:07:16)。旧運用に戻せる手順を用意する。

10イレギュラー対応の設計

先方は「イレギュラー対応が多く、踏み切れていない」と述べた (00:06:09)。具体例は、手書きのFAX、FAX後の電話変更、在庫のない品の納期調整 (00:16:05, 00:17:15)。

11在庫・発注の自動化

• 在庫品は自社出荷、それ以外は仕入先から直送 (00:11:50)。主な在庫はPB品（スプレーエアゾール）で、3〜6ヶ月分をまとめて持つ (00:13:23)。発注点は品目ごとに設定している (00:11:50)。
• 月次の需要を見ながら作るのに約3〜4ヶ月かかり、そのペースで発注している (00:13:23)。
• Ceedのデモは、請求書取込→在庫反映→不足分の発注先選定→人の確認→メール送信→入荷時の在庫加算という流れで、バーコードとカメラで在庫管理する例 (00:35:00, 00:35:57)。デモはワイン会社の例で、東洋化学商会向けではない。
• 方針案：最初は受注時の在庫判断と発注書の下書きまで。補充提案は後から検討し、発注は人が承認する。

在庫データの持ち方、発注点の決め方、仕入先の数と条件は 要確認。

12運用・保守・自己修復

13セキュリティと統制

• Ceedの説明は、セキュリティ専任エンジニアによる対応まで (00:39:32)。
• 未議論の論点：入力データの学習利用、利用するAIサービス、紙と個人情報の保管・廃棄。いずれも 要確認。
• 銀行経由のコンサルがAI利用ルールを検討中 (00:02:22)。関与範囲は未確認。

14KPI

Ceedは、例えば現在10時間かかっている作業を3時間に抑える、といった形でKPIを共に設定し、達成に向けた提案をすると説明した (00:40:38)。

目標値は基準の実測後に合意する。先方への説明では、費用対効果の分かりやすさが重要との指摘があった (00:50:25)。

15リスクと対策

16未確定事項・確認リスト

Ceedの宿題（翌日中に送付 00:47:47, 00:49:05）

• 提案資料のフルバージョン、過去のケーススタディ、簡易デモ。
• 受注の流れが分かる資料。熊地様のご依頼は、各段階で「ここでAIが読む」程度の粒度で、細かすぎないもの (00:49:05)。
• 契約前に、保守・運用の対応基準を言語化して合意する (00:46:09)。

未確定事項