大和書房 × オモシク / OCR DXプロジェクト Phase 1

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

月1,400〜2,400枚のFAX注文書(新刊予約)を Gemini Vision で自動読取し、書店マスタ23,505件と照合してTHINKs一括入力用Excelを生成する。松本課長の手入力工数を「数十時間/月 → 30分/日」に圧縮する。

📅 最終更新: 2026-05-17 👥 編集: 西川(オモシク)/ 松本課長・廣瀬本部長(大和書房) 🏷️ Status: Phase 1 MVP 構築中 / 🎯 本稼働 Go/No-Go 目標: 2026-05-30(金)
-95%
手入力工数削減
(月数十時間 → 30分/日以内)
~100%
書店コード照合精度
(マスタ23,505件×5段階)
96%
予約数 OCR 精度
(手書き「0/1」混同のみ要確認)
100%
.xdw 自動取込
(xdwlib + XDWAPI で完全無人化)
VISION

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

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

CORE 1

FAX → THINKs 入力 Excel を自動生成

共有フォルダに届くFAX (PDF / DocuWorks .xdw) を検知 → Gemini Vision OCR → 書店マスタ照合 → THINKs 一括入力用 Excel に追記。松本課長は Excel を THINKs 画面に貼り付けるだけ。

CORE 2

書店マスタ 23,505 件 × 5 段階照合

OCR が読み取った書店コード or 書店名を、取次マスタの5段階フォールバック照合で補正。書店コード精度はほぼ 100%。OCR で多少の誤読があっても自動で正しいコードに着地する。

CORE 3

担当者名フィルタで誤読を「ファックス」に変換

担当者欄は手書きの走り書きが多く OCR 精度が最も低い箇所。「1文字/英数字のみ/カタカナのみ/『様』含む/異体字含む」の5ルールで明らかな誤読を ファックス に統一。「デタラメよりはファックスの方がマシ」という松本課長合意ベース。

CORE 4

Wチェックフラグで人間の確認対象を絞る

予約数 = 1(空欄との混同リスク)・書店コード/名前不一致・信頼度<70% など、要注意レコードに ⚠️ フラグを自動付与。松本課長は「全件確認」ではなく「フラグ付きだけ確認」で済む。

CORE 5

DocuWorks (.xdw) を Python だけで PDF 化

共有フォルダの実態は .xdw 形式。xdwlib (PyPI) + Windows 同梱の XDWAPI.DLLGUI を一切起動せず .xdw → PDF 変換。DocuWorks Desk の手動印刷も追加ライセンスも不要。

CORE 6

大和PC(NucBox4)で完全無人運用

大和書房社内に置いた小型PC上で Python / Windows Task Scheduler が朝 8 時に起動。共有フォルダ監視 → OCR → Excel 追記 → 完了通知(メール/Slack)まで自動。RDP で名古屋から保守可能。

ARCHITECTURE

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
INSIGHT
当初は BEAT-VPN 経由で名古屋PCから共有フォルダにアクセスする設計だったが、大和書房社内に小型PC(NucBox4)を置いて RDP 接続する方式に転換。VPN 不要 + 大和PC 上で完結することで、Synx・共有フォルダへのアクセスが安定し、Task Scheduler による完全無人運用が可能になった。
OUTPUT

3. 出力 Excel イメージ

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

📊 入力中
✅ 処理済み
⚠️ 要確認
order_ocr_master.xlsx
A 書店コードB 予約数C 担当者D ⚠️E 書籍名F 書籍コードG 取次H 原本
5382823三宅○○の本12345日販📎
952231ファックス⚠️ 予約数1: 空欄混同リスク××の本67890トーハン📎
1234562塚田△△の本13579トーハン📎
5381115阿部⚠️ コード/名前不一致××の本67890日販📎

※ A〜C 列を THINKs 一括入力画面(取次×書誌ごとに開く)にコピペ。D 列のフラグ付きは原本リンク(H)で目視確認してから貼付。

NOTE
シート構成は 「入力中」「処理済み」「要確認」の 3 シート 案。4/6 MTG で松本課長は「1週間ごとにタブ切替は面倒、1シート継続更新が楽」と発言。処理済みは別シートに退避(手動 or 自動)する方向で OA-4(シート管理運用設計)で詳細化中。
USER FLOW

4. ユーザー別 E2E フロー

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

松本課長
大和書房 営業管理課長 / 主オペレーター
1朝出社 → 「処理完了通知」メール/Slack を確認
2共有フォルダの order_ocr_master.xlsx を開く
3「⚠️ 要確認」シートのフラグ付きレコードを目視チェック(原本リンクでPDFも開く)
4誤読を手動修正 → A〜C 列を THINKs に取次×書誌ごとにコピペ
512:00 の確定処理前にダブルチェック
6処理済みレコードを「処理済み」シートに退避(or 自動)
廣瀬本部長
大和書房 営業本部長 / KPI監視
1月次で 処理件数・精度・要確認率を確認
20冊レコード(送ったのに何もなかったことにされる事故)の有無確認
3Wチェックフラグ多発時は OCR 改善要望を西川に
4本稼働後 KPI ダッシュボード(処理時間・コスト)で運用評価
西
西川(オモシク)
運用保守 / RDP 経由で遠隔対応
1RDP で大和PC(NucBox4)に接続
2処理ログ(JSON Lines)で異常検知
3Gemini API 料金監視(再スキャン暴走防止)
4書店マスタ更新(月1〜四半期1)/ 取次マッピング修正
5OCR 精度劣化時にプロンプト or モデル更新
DATA FLOW

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
運用負荷
Gemini 2.5-pro 再スキャンは 2.0-flash の 5-10 倍コスト。月 2,400 枚 × 再スキャン発火率 20% で 月 ¥5,000〜10,000 を想定。本稼働前に松本課長に上限承認を取る必要あり([gaps] P0-1 参照)。
SCHEMA

6. 出力データスキーマ(13列)

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

項目用途出元
A書店コードTHINKs 入力用マスタ照合の最終結果
B予約数THINKs 入力用Gemini OCR 出力
C担当者名THINKs 入力用5ルールフィルタ後の値(誤読は ファックス
DWチェックフラグ⚠️ 要確認の理由予約数1 / コード名前不一致 / 信頼度<70% etc
E書籍名参考FAX ヘッダ部から抽出
F書籍コード(5桁)参考単行本1点は ISBN 末尾5桁
G取次名参考マスタB列の取次コード(101=日販、102=トーハン暫定)
H原本パス松本課長確認用共有FDの PDF へのハイパーリンク
I書店名(OCR)デバッグGemini が読んだ生テキスト
J書店名(マスタ)デバッグマスタ照合の結果
K照合方法デバッグexact / name+code_cross / exact_name_mismatch
L備考履歴Pro 参考値 / 担当者変換前の値
MFAXタイプ分類単行本1点 / 単行本一覧 / 文庫一覧
設計思想
A〜C 列だけ THINKs に貼り付けられる構造にすることで、松本課長の操作を「列選択→コピー→貼り付け」3 ステップに圧縮。デバッグ用列(I〜L)が常に同じファイル内にあるため、誤読原因の追跡も即可能。
OCR ENGINE

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

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

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

バージョン追加機能結果
v7.0THINKSフォーマット対応 / 0件ページ残し / 取次名追加 / 書籍コード5桁追加基本要件達成
v7.1Gemini 2.5-flash 試行 + 全0は Pro 再スキャン2.5-flash は 2.0-flash より精度低 → 2.0-flash に回帰
v7.22.0-flash 回帰 + 1判定プロトコル + Pro 再スキャン拡張(全0/全同値/0含み)空ページ0件達成。ただし p1 [0,1,0] が Pro [1,1,1] で改悪
v7.3セル単位クロップOCR(OpenCV)セル座標取得不安定 → 無効化
v7.3b担当者名 5 ルールフィルタ + A3方式(0含みは Flash 維持)担当者 72 件をファックス変換、p1 [0,1,0] 保護
v7.4書店名不一致時 Pro 再スキャン + Wチェックフラグ + 書籍名追加最終版。マスタ照合 96% 達成

🎯 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)

#ルール該当例理由
11 文字在、中、梯、榛、棟名前として不完全 or 注文書デフォルト記載の誤読
2英数字のみMC、2名前ではない
3カタカナのみサイトウOCR 読み取り不安定
4「様」含むいぬい様注文書テンプレートの一部
5異体字含む山下檢、トラ械明らかに誤読

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

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

Flash 結果パターン動作狙い
[0, 0, 0] 全0Pro に差し替えFAX 自体が空ページかもしれないが、要確認
[n, n, n] 全同値Pro に差し替えFlash の引きずられ誤読の可能性
[x, 0, y] 0含みFlash 維持、Pro は備考のみp1 で正解 [0,1,0] が Pro [1,1,1] に改悪された事例の保護
XDW INTAKE

8. DocuWorks (.xdw) 自動取込

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

2026-05-17 確定: C:\Windows\System32\xdwapi.dll(311関数Export)が大和PCに既にインストール済みと判明。xdwlib (PyPI) でラップして doc.export_image(format='PDF') 一発で PDF 化できる。GUI 一切起動せず、追加ライセンス不要。

最小コード

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()

実証結果(サンプル .xdw 64KB)

出力形式サイズ用途採否
PDF (300dpi COLOR 全ページ)1.0 MB⭐ 既存 v7.4 パイプライン互換◎ 採用
TIFF (300dpi MONO)1.1 MBOCR 専用ならコンパクト○ 代替
JPEG (300dpi COLOR)1.0 MBGemini 直接投入も可○ 代替
BMP (300dpi)27 MB大きすぎ×
2026-05-16 NG確定: 公式ドキュメントには記載があった DWVIEWER.EXE /p /t "DocuWorks PDF" を実機で試行 → GUI 起動扱いでタイムアウト、印刷キューにも投入されずDWVIEWER /? のヘルプフラグですら timeout(=CLI 非対応)。

推測される原因

  • 公式ドキュメントの /p /t は DocuWorks 9.x 以前のみ対応、10.x で廃止された可能性
  • DWVIEWER は元々 GUI 専用、印刷自動化は SDK 経由想定
  • プリンタ「保存ダイアログ表示」設定が ON で待機して止まっている可能性

→ プリンタ自動保存設定の追求は中止。xdwlib 採用で完全に回避。

方式コスト採否備考
DocuWorks Desk 手動印刷人件費(月3.3h)緊急時保険松本課長が朝一括 PDF 化 → 後段は自動
printToPdfFromDocuWorksFile
(eDocArrangement)
有償(数万円)第2保険xdwlib NG時のフォールバック
PDFオートコンバータEX年30万円不採用コスト過大
紙スキャン運用現場負荷増不採用OCR 精度劣化
ACCURACY

9. OCR 精度の実測値(v7.4)

2026-04-05 時点の正解データ突合結果。書店コードは事実上 100%、予約数は手書きの 0/1 混同のみが残課題、担当者は ファックス 変換で「明示的にわからない」が判明する設計。

~100%

書店コード

77 件のテストデータで 全件正解。OCR で多少誤読されても 5 段階マスタ照合で補正される。実質、新刊予約注文の自動入力で最も価値の高い列。

90〜95%

予約数

手書きの 0 と 1 の混同(空欄か「1」か)のみが残課題。該当レコードには Wチェックフラグを自動付与し、松本課長が原本リンクで確認できる仕組み。

2〜3割

担当者名

手書きの走り書きが多く、最も読取困難。5 ルールフィルタで誤読は ファックス に統一。「デタラメよりはファックスのほうがマシ」という松本課長合意。

52→50

マスタ照合成功率 96%

v6.1 基準の 52 件中 50 件成功。書店コードと書店名のクロスチェックで、コードだけ合っていて別店舗になる事故も検知(exact_name_mismatch)。

0 件

空ページ取りこぼし

v7.2 で達成。送信されたページは全て出力に残る。「送ってくれたのに何もなかったことにされる」(廣瀬本部長)事故を構造的に防止。

対決済

Gemini vs Claude 比較

マスタ完全一致: Gemini 68% / Claude 46%。空ページ救出は Claude 優位だが、書店コード精度は Gemini が圧勝。メインエンジンは Gemini で確定。

📊 取次コードマッピング(暫定 → 確認待ち)

コード取次名件数確度
101日販9,924◎ 5桁コードの 67.6%
102トーハン9,821◎ 6桁コードの 73.8%
103大阪屋栗田(推測)2,616△ 要確認
104〜未確認❌ 松本課長に確認
INTEGRATION

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

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

連携先 方式 頻度 自動度 Phase 備考
共有フォルダ (Synx) SMB マウント(大和PC直接) 常時監視 完全自動 P1 watchdog で新規 .xdw / .pdf 検知
Gemini Vision API REST(HTTPS) ページごと 完全自動 P1 2.0-flash → 必要時 2.5-pro
DocuWorks API (XDWAPI.DLL) ctypes(Windows 同梱) ファイルごと 完全自動 P1 xdwlib 経由、追加ライセンス不要
書店マスタ (Excel) ローカルファイル 起動時ロード 完全自動 P1 23,505件 / 月1〜四半期1 で手動更新
THINKs(基幹) 手動コピペ(一括入力画面) 日次 手動 P1 取次×書誌ごとに画面を開いて貼付
通知(メール/Slack/Teams) SMTP / Webhook 処理完了時 準自動 P1 チャネル選定中(B4-1 確認待ち)
Windows Task Scheduler OS 標準 朝 8:00 完全自動 P1 RDP 切断中でも動作
稼働在庫マスタ(書籍) ローカルファイル 起動時 完全自動 P1 1,226 件 / 書籍名表示用
kintone(書誌DB) REST API 非同期 対象外 P3 THINKs リプレース時に統合検討
BEAT-VPN 廃止 大和PC直接運用で不要に
USE CASE

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

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

A. 手書きの「0」と「1」混同
Flash 出力が [0,1,0] の「0含み」パターン → Flash 維持
Flash 出力が [0,0,0] 全0 → Pro で再スキャン
Flash 出力が [1,1,1] 全同値 → Pro で再スキャン
Wチェックフラグ + 原本リンク で松本課長が目視
B. 書店コードと書店名の不一致
マスタ完全一致でも OCR 書店名とマスタ書店名の類似度 < 50% → exact_name_mismatch
→ Pro で再スキャン
→ 例: 「ジュンク堂池袋」だが「谷島屋浜松」コードが付いた → 正しい「ジュンク堂池袋」コード 95223 に補正
C. 0冊レコード(送ったのに何もない)
予約数 0 のレコードも削除せず全て残す
全冊数が 0 のページは empty_page として「⚠️ 要確認」フラグ付きで残す
→ 廣瀬本部長「送ってくれたのに何もなかったことにされるのが一番まずい」対応
D. 担当者欄が読めない
5 ルールフィルタに該当 → ファックス に自動変換
ルール非該当の値(漢字氏名)→ そのまま採用
→ 「明示的にわからない」と「正解」を区別。「デタラメ採用」を排除
E. FAX 形式の違い(単行本 1点 / 一覧 / 文庫一覧)
単行本 1 点 → v3 ベースプロンプト
一覧(複数書誌) → v4 ベースプロンプト
→ ハイブリッド方式で形式判定 → 適切なプロンプトで OCR
F. .xdw 多ページ案件
doc.pages でページ数取得 → export_image(0, path, pages=doc.pages, format='PDF') で全ページ一括 PDF 化
→ 1 PDF にまとめてから OCR パイプラインに投入
→ 現状 PoC は 1 ページ .xdw のみ確認、多ページ要再検証([gaps] P0-3)
ROADMAP

12. 実装ステップと現在地(5月末 Go/No-Go 逆算)

セッション協調ボード(_session_board.md)の OA-1 〜 OA-6 に対応。OCR 精度(OA-1)と DocuWorks 変換方式(OA-2a)は完了、現在は OA-2b(パイプライン統合)が主戦場。本稼働 Go/No-Go を 5/30(金)に置き、残り 2 週間で逆算配置

SCHEDULE
完了マイルストーン: 2026-05-30(金) 本稼働 Go/No-Go / 2026-06-02(月) 本稼働開始。OA-3 と OA-4 は依存関係がないため 並列実行。クリティカルパスは OA-2b → OA-2c → OA-3 → OA-6(5/18〜5/30、計13日)。
3/14
OA-0 キックオフ 完了
松本課長 / 廣瀬本部長との初回 MTG。AS-IS 業務理解、Phase 1 MVP スコープ合意。
3/23〜4/6
OA-1 OCR 精度確定 完了 (96%)
v7.0 〜 v7.4 まで段階的に精度改善。書店コード ~100%、予約数 90〜95%、マスタ照合 96% 達成。全量実行は OA-2b 検証後に再開。
4/20〜5/16
OA-2a Discovery — 共有FD + DocuWorks 方式 完了
UNCパス疎通確認 ✅ / .xdw 4 件退避 ✅ / DWVIEWER NG判定 ✅ / xdwlib + XDWAPI.DLL 方式確定 ✅。
5/17〜5/22
OA-2b パイプライン統合 進行中 (5日)
5/18(月) 開始 → 5/22(木) 完了目標
xdwlib_convert.py 実装 / run_pipeline_demo.py 統合 / 多ページ.xdw検証 / Excel プロトタイプ松本課長レビュー / 通知チャネル決定 + 実装 / T-B3-1〜8 検証。
5/23〜5/25
OA-2c 本番フォルダ移行 3日
5/23(金) 開始 → 5/25(日) 完了目標
本番共有FDの UNC パス確定 / 1日分(50-70枚)の E2E カットオーバーリハ / docs/cutover-plan.md 完成。
5/26〜5/27
OA-3 THINKs 一括入力 突合検証 2日 / 並列可
5/26(月) 開始 → 5/27(火) 完了目標
RDP 経由で松本課長と同席 → 取次×書誌画面への貼付フロー実機検証 → 1日所要 ≤30 分達成確認。OA-4 と並列実行。
5/26〜5/28
OA-4 シート管理運用設計 3日 / 並列可
5/26(月) 開始 → 5/28(水) 完了目標
「入力中」「処理済み」「要確認」3 シート方式の運用ルール策定。月末退避・再現性担保。OA-3 と並列実行。
5/27〜5/29
OA-5 自動実行+監視 3日
5/27(火) 開始 → 5/29(木) 完了目標
Windows Task Scheduler 朝 8:00 起動 / JSON Lines ログ / 異常通知 / 短期連続稼働確認(48時間以上)。OA-3, OA-4 完了後の検証込み。
5/30
OA-6 本稼働 Go/No-Go 判定 1日 / マイルストーン
5/30(金) MTG
運用マニュアル最終版 / 実運用 1 日シミュレーション / ロールバック手順確立 / KPI 計測開始 / 松本課長サインオフ。
6/2〜
🚀 本稼働開始
6/2(月) より本番運用。初週はダブルチェック運用(松本課長が手入力と並行確認)→ 6/9 から自動化のみに移行。

📊 セッション別の進捗

OA-1 OCR 精度100%
OA-2a Discovery(共有FD + .xdw)100%
OA-2b パイプライン統合60%
OA-2c 本番移行0%
OA-3 THINKs 突合0%
OA-4 シート管理0%
OA-5 自動実行+監視0%
OA-6 本稼働 Go/No-Go0%

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

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

✅ Done 完了
🔄 Now 進行中
📋 Next 次に着手
⏳ Wait 依存待ち

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

IDタスク名担当開始終了期間ステータス
M-preOCRエンジン v7.4 確立(書店マスタ照合96%、担当者5ルール)西川3/234/0615日✅ Done
M0大和PC NucBox4 セットアップ + RDP環境構築(VPN不要化)西川+情シス4/104/101日✅ Done
M0.5共有フォルダ疎通確認 + テスト用パス開設西川4/214/211日✅ Done
M0.6パイプラインプロトタイプ(watchdog + Excel追記 + 通知スタブ)西川4/214/211日✅ Done
M0.7DocuWorks(.xdw)変換方式 実機検証 → xdwlib + XDWAPI.DLL 確定西川5/165/172日✅ Done

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

IDタスク名担当開始終了期間ステータス
M1xdwlib_convert.py 新規モジュール作成(xdw_to_pdf 関数)西川5/18(月)5/18(月)1日🔄 Now
M2run_pipeline_demo.py 統合改修(.xdw を SUPPORTED_EXTENSIONS に追加 / OCR前に変換挿入)西川5/19(火)5/19(火)1日📋 Next
M3多ページ .xdw 動作検証(_pending_xdw/ 全4件で変換 → OCR精度同等性確認)西川5/20(水)5/20(水)1日⏳ Wait (M2)
M4通知チャネル決定(メール/Slack/Teams)+ pipeline_notifier.py 実装西川+松本5/21(木)5/22(木)2日⏳ Wait (P0-2)
M4.5T-B3-1〜8 回帰テスト(正常PDF×.xdw×破損ファイル×並列etc)西川5/22(木)5/22(木)1日⏳ Wait

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

IDタスク名担当開始終了期間ステータス
M5Excel プロトタイプ生成(ダミー30件)+ 松本課長レビューMTG西川+松本5/21(木)5/22(木)2日📋 Next
M6シート管理運用ルール策定(入力中/処理済み/要確認の3シート方式 確定)西川+松本5/26(月)5/28(水)3日⏳ Wait (M5)
M7取次コードマッピング確認(103以降)+ マスタ更新フロー確定松本→西川5/22(木)5/22(木)1日⏳ Wait (P0-5)

Step 3: 本番移行 + 検証(5/23 〜 5/29)

IDタスク名担当開始終了期間ステータス
M8本番共有フォルダ UNCパス確定 + 権限・命名規則・形式比率把握松本+西川5/23(金)5/23(金)1日⏳ Wait (P0-4)
M9E2E カットオーバーリハ(本番1日分 50-70枚で全工程テスト)西川5/24(土)5/25(日)2日⏳ Wait (M8)
M10THINKs 一括入力 突合検証(松本課長同席、貼付フロー実機 ≤30分達成)松本+西川5/26(月)5/27(火)2日⏳ Wait (M9)
M11自動実行 + 監視構築(Windows Task Scheduler 朝8:00 / JSON Lines ログ / 異常通知)西川5/27(火)5/29(木)3日⏳ Wait (M9)
M11.548時間連続稼働テスト(RDP切断中も継続動作確認)西川5/28(水)5/29(木)2日⏳ Wait (M11)

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

IDタスク名担当開始終了期間ステータス
M12運用マニュアル v1 作成(手順 / トラブルシュート / ロールバック)西川5/28(水)5/29(木)2日⏳ Wait
M13実運用 1日シミュレーション(松本課長同席で AS-IS 業務並行確認)松本+西川5/29(木)5/29(木)1日⏳ Wait
M14本稼働 Go/No-Go MTG(松本課長サインオフ) 🎯 マイルストーン松本+廣瀬+西川5/30(金)5/30(金)1日⏳ Wait
M15a🚀 本稼働開始 + 初週ダブルチェック運用松本6/02(月)6/06(金)5日⏳ Wait (M14)
M15b初週レビュー → 自動化のみに移行(手入力廃止)松本+西川6/09(月)6/09(月)1日⏳ Wait (M15a)
CRITICAL PATH
M1 → M2 → M3 → M9 → M10 → M14(5/18→5/30 計13日)。M4・M7 は松本課長の承認待ちで開始日が後ろにずれるリスク。P0-2(通知チャネル)・P0-4(本番UNC)・P0-5(取次コード)の早期解消がスケジュール厳守の鍵。
PHASE 2 / 3

13. Phase 2 / 3 の残論点

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

Phaseカバー範囲論点確度
Phase 2 即出荷(在庫品の追加発注) FAX フォーマットが新刊予約と異なる。既存マスタへのマッピングを再設計。OCR プロンプトは v7.4 系列を派生
Phase 2 チェーン一括(複数店舗まとめ発注) 1 FAX に複数店舗が並ぶ形式。Gemini の表構造認識能力を再評価。Phase 1 では対象外
Phase 2 セット売り(1 セット = 5 点等) 1 行に複数書誌が紐づく。スキーマ拡張要。Phase 1 では対象外で松本課長と合意
Phase 3 全カテゴリ対応 返品・調整・特殊取引等。FAX 件数の Long Tail 部分。Phase 1〜2 の運用安定後
Phase 4 kintone UI 置き換え Excel コピペを廃止し、kintone 上で承認・台帳化まで一気通貫。THINKs リプレースとセットで設計

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

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

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

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

🔴 P0 — 本稼働判定までに必須

P0-1
Gemini Pro 再スキャン費用の上限承認
月 ¥5,000〜10,000 を想定。API 費用は西川負担 vs 大和書房負担も含めて確認要。
松本課長へ: 月額 ¥10,000 までの再スキャン API 費用を承認いただけるか?
P0-2
エラー通知チャネル決定
メール / Slack / Teams のどれを使うか未定。本稼働開始時には決まっている必要あり。
松本課長へ: 異常通知はメール/Slack/Teams のどれが望ましいか?
P0-3
多ページ .xdw での xdwlib 変換確認
PoC は 1 ページ .xdw でのみ確認。20260404100153.xdw (270KB) のような多ページ案件で再検証が必要。
西川: 次回大和PC作業時に多ページ .xdw で動作確認 → docuworks-probe-result.md に追記
P0-4
本番共有フォルダの UNC パス確定
現在のテスト用フォルダ \\192.168.1.114\共有\omoshiku作業用 とは別の本番格納先がある可能性。
松本課長 or 窪田部長へ: 本番 FAX 格納の共有フォルダ UNC パスを教えてほしい
P0-5
取次コード 103 以降のマッピング
101=日販、102=トーハンは推定。103=大阪屋栗田 は未確定、104〜は完全未知。
松本課長へ: マスタにある取次コード(101〜)の正式な取次名一覧をご提供いただけるか?

🟡 P1 — 早期確認

P1-1
シート管理方針(案A / 案B)
4/6 MTG では案A(単一スプシ継続)志向。最終確定要。
松本課長へ: シート管理は「単一スプシ+処理済み別シート」で確定でよいか?
P1-2
出力 Excel 列順の最終確認
A=書店コード / B=予約数 / C=担当者名 / D=Wチェックフラグ で確定か。THINKs 画面の貼付順と合致しているか。
松本課長へ: 上記列順で THINKs 貼付が滞りなくできるか実機確認
P1-3
セット売りの Phase 1 対応要否
本ビジョンでは Phase 2 延期と整理。再合意要。
松本課長へ: セット売りは Phase 1 では対象外、Phase 2 で実装する方針で問題ないか?
P1-4
RDP 切断中の Task Scheduler 動作確認
朝 8:00 自動実行時、RDP 接続なしでも動くか実機検証要。
西川: OA-5 で実機検証。原則動くはずだが、スリープ設定等で停止する可能性
P1-5
書店マスタの更新頻度
月1 or 四半期1 のどちらの運用か。マスタ古いと新規開店書店が照合できない。
松本課長へ: 書店マスタ(23,505件)の更新頻度と提供方法を確認

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

P2-1
監査ログ保持期間
JSON Lines ログの保持期間(1 ヶ月 / 半年 / 1 年)を確定。コンプライアンス次第。
窪田部長へ: 半年保持で問題ないか確認
P2-2
Gemini モデルアップグレード時の運用
2.5-flash で精度劣化した経緯あり。自動アップグレード or 検証後採用のどちらか。
西川: 検証後採用とし、月次レビューで判断
P2-3
大和PC の冗長化方針
NucBox4 故障時の代替機。クラウド退避の必要性。
窪田部長へ: Phase 1 では NucBox4 単機運用、故障時は手入力に戻すロールバック手順で運用
NEXT

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 の詳細チケット表と対応。

📋 直近 1 週間のアクション(Step 1-2 / 5/18〜5/22)

  1. 1
    [M1] xdwlib_convert.py 新規モジュール作成(西川・1日 / 5/18(月)projects/order-ocr/scripts/xdwlib_convert.py に xdw_to_pdf() 関数を定義
  2. 2
    [M2] run_pipeline_demo.py 統合改修(西川・1日 / 5/19(火)PENDING_EXTENSIONS から .xdw 撤去 / SUPPORTED_EXTENSIONS に .xdw 追加 / OCR 直前に変換挿入
  3. 3
    [M3] 多ページ .xdw 動作確認 + OCR 精度同等性(西川・1日 / 5/20(水)_pending_xdw/ の 4 件全てで変換 → v7.4 投入 → マスタ照合 ≥95% 確認
  4. 4
    [M5] Excel プロトタイプ松本課長レビュー(西川 + 松本課長・2日 / 5/21(木)〜5/22(木)ダミー 30 件で生成した order_ocr_master.xlsx を画面共有 → フィードバック反映
  5. 5
    [M4] 通知チャネル決定 + pipeline_notifier.py 実装(松本承認 → 西川実装・2日 / 5/21〜5/22P0-2 の松本課長承認待ち。メール / Slack / Teams のいずれか

📅 大和書房側へのお願い(5/22(木) までにご回答希望)

  1. 1
    本番 FAX 共有フォルダの UNC パス テスト用 \\192.168.1.114\... 以外の本番格納先があれば
  2. 2
    取次コード 103 以降のマッピング表 マスタ B 列の取次コード → 正式取次名の対応一覧
  3. 3
    Gemini API 再スキャン費用の上限承認(月 ¥10,000 想定) 本稼働後の月額負担をどちらが持つかも含めて
  4. 4
    異常通知のチャネル決定 メール / Slack / Teams のどれが日常で見ていただきやすいか
  5. 5
    書店マスタの更新頻度・提供フォーマット 月1 or 四半期1、ファイル受領 or 共有 FD 配置
SO WHAT
Phase 1 の技術的ブロッカーは 2026-05-17 時点で全て解消。残る論点は「運用合意 5 項目(P0)」と「コード実装 5 タスク」のみ。5/30(金) 本稼働 Go/No-Go → 6/2(月) 本稼働開始 を目標に逆算(クリティカルパス 13日)。P0 項目の早期解消が成否を分ける。