FAXやPDFの注文を入力する仕事、AIでどこまで減らせる？

AIを活用すれば、FAXやPDFで届く注文書の 注文番号・商品コード・数量・納期 といった定型項目を自動で抽出し、手入力作業を大幅に削減できます。まずは OCRエンジンと大規模言語モデル（LLM）を組み合わせたプロトタイプ を作り、抽出精度と例外検出の有無を確認することから始めましょう。

AIで自動抽出できる項目は何か

注文書のレイアウトを把握する

まずは社内で受領しているFAXやPDFの注文書を 数件程度サンプルとして収集 します。注文番号、商品コード、数量、納期といった必須項目がどの位置に記載されているかを目視で確認し、ページ構成やフォントサイズ、項目間の区切り文字を 表形式・自由文書形式のどちらか に分類します。

レイアウトが複数に分かれる場合は、各パターンごとに フィールドマッピング表 を作成し、AIに渡す入力指示を明確にしておくと後の学習がスムーズです。

続いて、レイアウトごとのサンプル画像 と 正解データ（抽出すべき項目とその値） を Excel などで整理します。この段階で、同一書式でも手書きの文字やスキャン品質の差があることが分かるはずです。こうしたバリエーションを データセットに組み込む ことで、OCRエンジンが実運用時に遭遇するノイズに強くなります。

レイアウト把握が終わったら、次は実際に OCR と LLM を組み合わせた抽出パイプラインを構築します。

OCRとLLMの組み合わせ活用法

OCRは画像から文字列を取り出す役割を担い、LLM は取り出した文字列を 構造化データ（キーとバリュー） に変換します。

まずは、Google Cloud Vision、Microsoft Azure Form Recognizer、またはオープンソースのTesseract といった実績ある OCR を試し、文字認識率（CER）を測定します。

認識精度が実運用に支障がないレベルであることを確認できたら、次は LLM に 「注文番号は数字 8 桁、商品コードはアルファベット＋数字」 といったプロンプトを与えて、正規表現で抽出させます。

この二段階プロセスのポイントは、OCR の出力を そのまま LLM に渡すのではなく、前処理で改行や余計な文字を除去 することです。前処理を入れるだけで、LLM の誤抽出が大幅に減ります。

実装は Python の pandas と正規表現を組み合わせたスクリプトで簡単に行えますが、テストデータで十分な件数 を走らせて 抽出成功率（Precision/Recall） を算出し、組織が設定した目標水準を上回ることを確認すると安心です。

抽出精度を評価する指標

抽出精度は単に文字が正しく読めたかだけでなく、ビジネス上の正確性 も評価対象です。まずは 項目別の正解率 を算出し、どの項目がボトルネックになっているかを可視化します。次に、例外率（欠品・変更が検出できなかった件数）を測ります。

例外率については、組織の許容範囲と照らし合わせて判断し、AI が自動処理できる案件が十分に多いかどうかを評価します。

評価結果は スプレッドシートや BI ツール にまとめ、関係部門（営業・在庫管理）と共有します。ここで「精度が低い項目は人手で二重チェック」する方針を決めておくと、導入後の運用がスムーズです。評価サイクルは 月次で再測定 し、改善策（OCR の再学習やプロンプト修正）を随時反映させることで、継続的に精度を向上させられます。

例外（欠品・変更）を見極める基準は

欠品判定のロジック設計

欠品判定は在庫管理システムと連携させることが前提です。AI が抽出した 商品コードと数量 をリアルタイムで在庫データベースに照合し、在庫数が不足している場合は 「欠品フラグ」 を付与します。このフラグは単なる数値比較ではなく、安全在庫レベルやリードタイム を考慮したロジックにすると、誤検知が減ります。

たとえば、安全在庫を 10 個、リードタイムを 3 日と設定し、在庫が 10 個以下かつ納期が 3 日以内の場合は欠品と判定します。

ロジックを実装したら、過去 3 ヶ月分の受注データ でシミュレーションを行い、実際に欠品が発生したケースと比較します。シミュ結果が実績と合致すれば、本番導入時の 例外通知メール（担当者宛）や ダッシュボード に自動反映させる準備が整います。シミュで差異が出た場合は、在庫データの更新頻度や安全在庫設定を見直すことが重要です。

変更注文の検出ポイント

変更注文は「数量増減」や「納期変更」だけでなく、商品コード自体が変わるケース もあります。AI が抽出した情報と、既存の受注情報を ハッシュ比較 することで、差分を自動的に検出できます。差分が見つかったら、「変更フラグ」 とともに 変更前後の値 を表示し、担当者が確認できる画面を用意します。

検出ロジックは 「同一注文番号で一定期間内に再送信があった場合」 といった時間的条件（例：24 時間）を加えると、誤検知が減少する可能性があります。実装後は、過去の変更注文データ を使ってリコールテストを行い、検出率が組織の目標水準を満たすことを確認します。

検出できなかったケースは、手動での例外登録 手順を別途用意し、例外処理が抜け落ちないようにします。

例外データの人手フラグ付け

AI が自動で処理できない例外（欠品・変更・不明文字）は、「人手フラグ」 を付与してワークフローに回します。このフラグはデータベース上のステータス列として管理し、「未処理」「処理中」「完了」 の三段階で進捗を追跡します。

フラグ付けのタイミングは、AI が抽出結果を保存した直後に自動トリガーで実行し、担当者が 専用の一覧画面 で一括確認できるようにします。

フラグ付け後は、担当者への通知（Slack/メール） と 期限設定（例：48 時間以内） を組み合わせることで、例外が放置されるリスクを低減します。また、例外処理が完了したらステータスを「完了」に変更し、処理履歴をログとして残す ことで、後日の監査や改善活動に活用できます。

こうした仕組みを整えることで、AI の自動化範囲と人手が必要な範囲が明確になり、業務全体の可視化が進みます。

人手が必要な承認プロセスの設計

承認フローの段階と担当者

受注確定には 営業部門の承認 と 在庫管理部門の最終確認 が必要です。AI が抽出・例外判定を行った後、まずは 「一次承認」 として営業担当者に注文内容を提示します。この段階では、注文番号・商品コード・数量・納期の 要約情報 と例外フラグの有無だけを表示し、承認・却下のボタンを設置します。

一次承認が完了したら、「二次承認」 として在庫管理部門へ自動で回します。二次承認では、在庫照合結果や欠品フラグの詳細を提示し、在庫確保の可否を判断させます。承認が得られたら、システムは 「受注確定」 ステータスに遷移し、受注情報を ERP や受注管理システムへ自動送信します。

各段階で 承認者の署名やコメント を記録できるようにすれば、後日のトレーサビリティが確保できます。

人手レビューの情報提供方法

人手が介在するレビュー画面は、情報過多にならない ことが重要です。AI が抽出した項目は テーブル形式 で表示し、例外がある行だけは 色付け して目立たせます。さらに、「変更前後」 の比較や 「在庫残量」 を同時に表示することで、判断材料が一目で分かります。

画面上部に 「承認コメント」 入力欄を設け、承認・却下の理由を必須入力にすれば、意思決定の根拠が残ります。

また、モバイル対応 した通知リンクを Slack や Teams に送ることで、外出先でも迅速に承認できる環境を整えます。承認が遅延した場合は自動でリマインダーが送られる仕組みを組み込むと、業務遅延の防止につながります。こうした UI/UX の工夫は、AI が自動化した部分と人手が介在する部分のスムーズなハンドオーバーを実現します。

確定後のシステム連携手順

受注が最終承認されたら、システムは 「受注確定」 ステータスを付与し、ERP（例：SAP、Oracle）や基幹受注管理システムへ API 連携 でデータを送ります。送信データは JSON 形式で、注文番号・商品コード・数量・納期・承認者情報を含めます。

受信側は 受注登録 API を用意し、受領確認のレスポンスを返すことで、送信側は 送信成功フラグ を更新します。

連携が完了したら、「受注完了メール」 を顧客に自動送信し、同時に 社内の出荷指示システム へも情報を流します。この一連の流れを バッチ処理かリアルタイム処理か で選択できますが、受注確定のタイムラグが業務上問題になる場合は リアルタイム Webhook を推奨します。

連携テストは本番環境と同様のデータで ステージング環境 を用意し、エラーハンドリング（再送・手動修正フロー）も併せて検証しておくと、運用開始後のトラブルを最小化できます。

安全に運用するためのリスク管理

データ保護とアクセス制御

FAX や PDF に含まれる注文情報は 顧客の取引情報 であり、機密性が高いデータです。まずは 保存先サーバーを適切に暗号化し、アクセス権限を最小化 します。AI 処理を行うサーバーは、社内ネットワーク内の限定された IP アドレスからのみアクセス可能 に設定し、外部からの直接接続は遮断します。

また、処理結果のデータベースには ロールベースのアクセス制御（RBAC） を導入し、承認者以外は閲覧できないようにします。

さらに、ログの保存期間 を社内規程に合わせて設定し、監査ログ（誰がいつどのデータにアクセスしたか）を定期的にレビューします。万が一情報漏洩が疑われた場合は、インシデント対応手順（情報の切り離し、関係者への報告、原因調査）を速やかに実行できる体制を整えておくことが重要です。

これらの対策は、IPA が提示する生成AIのセキュリティリスクガイドラインにも合致します。

AIモデルの学習データ管理

AI が正しく動作するためには、学習データの品質管理 が欠かせません。注文書のサンプルは個人情報や取引先情報を含むため、学習データとして使用する際は 個人情報保護法に基づく匿名化 を徹底します。具体的には、顧客名や住所をマスクし、商品コードや数量だけを残す形でデータセットを作成します。

学習データは バージョン管理システム（Git LFS など） で管理し、変更履歴を残すことで、モデルの再学習や問題発生時のロールバックが容易になります。また、モデル自体も 社内サーバー上でホスティング し、外部クラウドサービスへのデータ送信は最小限に抑えることで、情報流出リスクを低減します。

モデルの更新は 四半期ごとに評価 し、精度が低下した場合のみ再学習を行う方針を決めておくと、運用コストとリスクのバランスが取れます。

セキュリティチェックリストの活用

導入・運用段階でのセキュリティ対策は、チェックリスト形式で管理 すると抜け漏れが防げます。まずは IPA のガイドラインを参考に、以下の項目をリスト化します：

1. データ暗号化の有無
2. アクセス権限の最小化
3. ログ保存と監査体制
4. 学習データの匿名化手順
5. モデルホスティング環境の隔離
6. インシデント対応フローの整備
7. 定期的な脆弱性診断の実施

各項目について 担当者と期限 を設定し、月次レビュー で進捗を確認します。チェックリストは社内の情報セキュリティポリシーに組み込み、新規導入時の承認プロセス にも組み込むことで、導入時点でのリスクを事前に把握できます。チェックリストの活用は、AI 活用に対する社内の不安感を軽減し、継続的な安全運用を支える基盤となります。