FAX注文書 AI-OCR
自動入力 Phase 1 ビジョン

1. 最終形：何が実現されるか

FAX 注文書（新刊予約）の処理を「人手で読んで手入力」から「Pythonが自動読取してExcel出力 → 人は要確認のみ目視」に転換する。完全無人運用ではなく、人間が最後のチェッカーに残る設計。

2. システム全体像

FAX 着信から THINKs 入力まで、3 層（営業現場 → 大和PC上の自動処理 → 松本課長の確認）で完結する。VPN 不要、外部サーバなし、追加ライセンス費 0 円。

flowchart TB
    subgraph external["① 営業現場 / 外部"]
      fax["✅ 複合機
FAX 受信"]
      shop["書店
新刊予約 FAX 送信"]
    end
    subgraph share["② 大和書房 社内共有フォルダ (Synx)"]
      input["✅ 入力前データ
.xdw / .pdf"]
      pending["🟡 _pending_xdw/
(現在は xdw を退避)"]
      done["✅ 入力済データ
処理済原本"]
    end
    subgraph pc["③ 大和PC (NucBox4) — Python 自動処理"]
      watcher["✅ file_watcher
(watchdog)"]
      xdw["🟡 xdwlib_convert
.xdw → .pdf"]
      ocr["✅ OCR v7.4
Gemini 2.0-flash"]
      master["✅ 書店マスタ照合
23,505件"]
      excel["✅ Excel 追記
order_ocr_master.xlsx"]
      notifier["🟡 通知
(メール/Slack)"]
    end
    subgraph user["④ 松本課長 (RDP or 直接)"]
      review["人間チェック
Wフラグだけ目視"]
      thinks["✅ THINKs 一括入力
(コピペ)"]
    end

    shop -->|FAX 送信| fax
    fax -->|自動転送| input
    input -->|.xdw 検知| watcher
    input -->|.pdf 検知| watcher
    watcher --> xdw
    xdw --> ocr
    ocr --> master
    master --> excel
    excel --> notifier
    notifier -.->|要確認通知| user
    excel --> review
    review --> thinks
    watcher -->|処理済原本退避| done
    

3. 出力 Excel イメージ

松本課長が日次で見る Excel ファイル。「入力中」シートに新規行が追記され、Wチェックフラグだけ確認 → THINKs 画面の取次×書誌ごとに A〜C 列をコピペ。

4. ユーザー別 E2E フロー

本Phase 1 では 3 つの登場人物。営業現場（FAX を送る書店）はシステムには現れない。

5. E2E データフロー（システム×データ）

FAX 着信から Excel 追記まで、1 件あたり 30 秒〜2 分。Gemini API 呼び出し回数を最小化するため、信頼度が低いページのみ Gemini 2.5-pro に再スキャンする 2 段構成。

sequenceDiagram
    autonumber
    actor shop as 書店
    participant fax as 複合機
(FAX)
    participant share as 共有フォルダ
(Synx)
    participant watcher as file_watcher
(watchdog)
    participant xdw as xdwlib_convert
    participant ocr as OCR v7.4
    participant gem as Gemini Vision
(2.0-flash → 2.5-pro)
    participant mst as 書店マスタ
(23,505件)
    participant xlsx as order_ocr
_master.xlsx
    participant matsu as 松本課長

    rect rgb(245,245,250)
      Note over shop,share: 受信フェーズ
      shop->>fax: 新刊予約 FAX
      fax->>share: .xdw 自動保存
    end

    rect rgb(245,250,245)
      Note over watcher,xlsx: 自動処理フェーズ（朝 8:00 起動 or リアルタイム）
      share-->>watcher: 新規ファイル検知
      watcher->>watcher: ファイルサイズ安定待ち
      watcher->>xdw: .xdw を渡す
      xdw->>xdw: XDWAPI で PDF 化
      xdw->>ocr: .pdf を渡す
      ocr->>gem: 2.0-flash で各ページ OCR
      gem-->>ocr: JSON（書店コード/予約数/担当者）
      alt 全0 or 全同値 or 名前不一致
        ocr->>gem: 2.5-pro で再スキャン
        gem-->>ocr: 高精度結果
      end
      ocr->>mst: 5段階フォールバック照合
      mst-->>ocr: 補正済み書店コード
      ocr->>xlsx: 「入力中」シートに追記
      xlsx->>xlsx: Wチェックフラグ判定
    end

    rect rgb(250,247,240)
      Note over xlsx,matsu: 確認フェーズ
      xlsx-->>matsu: 処理完了通知（メール/Slack）
      matsu->>xlsx: 「要確認」を目視
      matsu->>matsu: THINKs に貼付
    end
    

6. 出力データスキーマ（13列）

v7.4 で確定した出力 Excel の列定義。A〜C 列が THINKs 入力用、D 列が要確認フラグ、E〜M 列が参考情報・デバッグ用。

7. OCRエンジン v7.4 の中身

2026-03-23 v7.0（THINKSフォーマット対応）から始まり、4/6 までに v7.4 まで進化。書店コード精度はほぼ 100%、予約数は90〜95%、担当者名は2〜3割（残りは ファックス 自動変換）。

🛠️ v7.0 → v7.4 進化の経緯

🎯 5段階マスタ照合フォールバック

flowchart LR
    s1["1️⃣ exact
コード完全一致"] --> s2["2️⃣ exact_name
書店名完全一致"]
    s2 --> s3["3️⃣ fuzzy_name
類似度80%以上"]
    s3 --> s4["4️⃣ name+code_cross
名前+末尾2桁照合"]
    s4 --> s5["5️⃣ unmatched
マスタ無し"]
    s1 -.->|名前<50%| warn["⚠️ exact_name_mismatch
→ Pro 再スキャン"]
    

📋 担当者名 5 ルール（v7.3b）

→ 82 件中 72 件を ファックス に自動変換。正しい名前（三宅、塚田、吉岡、阿部）は保持。

⚙️ 0/1 再スキャンの A3 方式

8. DocuWorks (.xdw) 自動取込

複合機 → 共有フォルダの実態は .xdw（DocuWorks 独自形式）。当初 DWVIEWER.EXE のサイレント印刷を採用予定だったが、実機検証で NG → xdwlib + Windows 同梱 XDWAPI.DLL 方式に最終決定。

import xdwlib
doc = xdwlib.xdwopen(r"\\192.168.1.114\共有\...\20260417135024.xdw")
doc.export_image(0, r"C:\tmp\out.pdf",
                 pages=doc.pages, dpi=300, color="COLOR", format="PDF")
doc.close()

9. OCR 精度の実測値（v7.4）

2026-05-18 M3b で本番フォルダ 10 件を実機検証。マスタ照合 30/30 = 100% 達成（4/5 時点の Excel ベース 96% を超え）。Kintone マスタ 97,234件への切替で件数 4 倍化、精度向上。

📊 取次コードマッピング（2026-05-18 松本課長より正式情報入手 ✅）

⚠️ 当初推定 (101=日販、102=トーハン) は誤り。正確には 001 トーハン、002 日販。`data/torituki_master.csv` として確定マスタを管理。

※ 005, 015-017 は欠番か未確認。スクショから読み取った 20 社で運用開始

10. 外部システム連携マトリクス

Phase 1 では「共有フォルダ + Gemini API + Excel + 通知」の 4 つだけで完結。THINKs への入力は手動コピペ（一括入力画面の API は無いため）。

11. ユースケース別の判断分岐

運用で必ず発生するエッジケース。それぞれ「自動判定 or 人間確認」のどちらに振るかを設計済み。

12. 実装ステップと現在地（6/2 Go/No-Go + 本番適用）

セッション協調ボード（_session_board.md）の OA-1 〜 OA-6 に対応。OCR 精度（OA-1）と DocuWorks 変換方式（OA-2a）は完了、現在は OA-2b（パイプライン統合）が主戦場。2026-06-02(月) 定例MTG で Go/No-Go 判定 + 本番適用（松本課長指示）。

📊 セッション別の進捗

📋 詳細チケット構造（親 × Step × 孫タスク）

ClickUp 親タスク 86exgwr3q（確定）配下に Step 0〜4 を配置。各 Step に細粒度の孫タスクを置き、6/2(月) Go/No-Go 逆算で開始-終了日を設定。太字 が現在進行中。

Step 0: 環境準備・前提整備（既完了）— 3/14 〜 5/17

Step 1: コア基盤統合（パイプライン）— 5/18 〜 5/22

Step 2: 出力 Excel + マスタ運用（5/21 〜 5/28、Step 1 と一部並列）

Step 3: 本番移行 + 検証（5/23 〜 5/29）

Step 4: Go/No-Go + 本稼働（5/28 〜 6/9）

13. Phase 2 / 3 の残論点

Phase 1 MVP は「新刊予約 FAX」のみ対象。Phase 2 以降で対象を拡張する。

🆕 THINKs 入力自動化 (Phase 2 候補・PoC 完了)

2026-05-18 PoC 実施。技術的に完全実現可能（条件付き）と判定。 docs/discovery/thinks-automation-feasibility.md 詳細あり。

⚙️ Phase 1 完了後の技術的余地

• セル単位クロップ OCR の再挑戦: OpenCV のセル座標検出を画像前処理（CLAHE+二値化）強化で改善できれば、予約数「1」の判別精度が大きく上がる可能性
• Gemini モデルアップグレード: 2.5-flash は精度劣化で回帰したが、将来の 3.0-flash 等で再評価
• 書籍名 → ISBN-13 自動変換: 稼働在庫マスタに ISBN 列がない。OpenBD 等の外部 API 連携で実現可能
• BigQuery 連携: 処理ログ・OCR 信頼度を BQ に蓄積し、精度トレンドを可視化（運用安定後）
• シンクアップ社平田氏に THINKs 公式 API 計画確認 → 将来公式 API が出れば GUI 自動化より望ましい

14. 不足情報と確認・依頼

本稼働 Go/No-Go 前に解消が必要な項目。優先度 P0（要決定）・P1（早期確認）・P2（運用前）で整理。

🟢 P0 — 全件解消（2026-05-18 松本課長より一括承認）

🟡 P1 — 早期確認

🟢 P2 — 運用フェーズで確認

15. 次のアクション

Step 1（5/18〜22 パイプライン統合）→ Step 2（5/21〜28 出力Excel）→ Step 3（5/23〜29 本番移行 + 検証）→ Step 4（5/30 Go/No-Go → 6/2 本稼働）。各 M-番号は Section 12 の詳細チケット表と対応。