01
Principleまとめてスキャンする、それだけ
複数の宅配事業者ごとに分けず、出荷分をまとめてスキャンするだけで完了。物流担当者の作業はそこで終わる。スキャンされた PDF はクラウドに自動同期され、以降の処理はすべて自動。
case-04
業務カスタムアプリプロトタイプ
数十枚の伝票から、一瞬で一枚を呼び出す
複数の宅配事業者の送り状をまとめてスキャンするだけで、出荷日と顧客名・受注Noで一瞬で検索。「探す→印刷→FAX」の連鎖を、画面操作1つに置き換える。
Overview
このシステムは、何をしている？
Overview / 概要
物流担当者は、出荷済みの送り状を まとめてスキャンするだけ。スキャンされた PDF はクラウドに自動同期され、OCR で出荷日・伝票番号・顧客名などが抽出される。事務スタッフは出荷日と顧客名・受注 No などの組み合わせで検索し、該当の PDF をそのままお客様にメール・FAX 送信できる。
Input入力
- 01
複数の宅配事業者の送り状 (紙)
- 02
出荷時にまとめてスキャン
- 03
印字品質にバラつきあり (OCR 揺れの前提)
Output出力
- 01
検索可能な送り状 PDF 台帳
- 02
出荷日・顧客名・受注 No で横断検索
- 03
メール・FAX 送信機能
Architecture & Flow
システム構成とデータフロー
送り状のスキャンから検索・閲覧・送信まで、構成と流れを 1 枚に。
PrototypeCase 04 · System Flow
External services
Google Cloud Vision APIOCRAWS Lightsail予定
Z1·On-site
各拠点
PC + 複合機 / スキャナー
Z2·Cloud
クラウドサーバー
取り込み・OCR・解析・DB・PDF 保管
Z3·Client
ブラウザ
PC / タブレット / スマホ
01取り込み· CaptureZ1 → Z2
紙の送り状
Input
Action
複合機/スキャナーで一括スキャン
物流担当が出荷分の送り状をまとめて取り込み
PDF
クラウド保管
Output
PDFUpload
02自動読み取り· OCR · Detect · ParseZ2
2 · A
OCR — 生テキスト抽出
Google Cloud Vision API に PDF を渡し、ページ単位で生テキストを取得。
●Google Cloud Vision API
5
2 · B
事業者を自動判定
01山陽自動車運送02ヤマト運輸03佐川急便04福山通運05セイノースーパーエクスプレス
2 · C
事業者別パーサー
事業者ごとのルールベースパーサーで項目を抽出。 決定論的・安定。
· 決定論的· 高速· 再現性
Extracted · 6 fields抽出項目
→ Stage 0301伝票番号
1234-5678-9012
02受注 No
ORD-204881
03届け先
東京都品川区 …
04受付日
2025-04-28
05届け日
2025-04-30
06品名
段ボール 2 口 ほか
Structured fields× 6
03保存· PersistZ2
Database
抽出項目を構造化して保存
検索・絞り込みのインデックス対象。事業者・日付・伝票番号などをキーに。
Object Storage
元の PDF 画像を保管
詳細閲覧時に OCR 結果と並列表示するための原本。
Query / Read
04活用· UseZ2 → Z3
01
ダッシュボード
総登録数 / 今日の出荷 / 土日祝お届け件数を一目で把握
02
検索
受注 No・届け先・伝票番号などキーワードで横断検索
03
絞り込み
事業者別 / 出荷日期間 / 土日祝お届け でフィルタ
04
詳細閲覧
OCR 結果と元の送り状画像を並列表示
05
メール・FAX 送信
客先への送信を画面から実行
Insight
問題の本質
依頼者が口にする問題と、本当に解くべき問題は、たいてい違う場所にあります。
01
Surface
表面の問題
送り状の現物は1枚しかなく、配送問い合わせのたびに探して確認するのが手間。
02
Core
実際に解くべき問題
問題の核は、紙の送り状そのものではなく、「電子化したけど検索できない」という中途半端な状態が温存されていること。
出荷日を勘で想定してPDFを開く、中身を目で確認する、必要な1ページを抽出する——電子化したのに「探す手間」が残ったまま、事務と現場の負担が下がりきらない。
電子化のはずが、結局「探す」工程が残る。
03
Our Lens
info-flagの着眼点
システムの仕事は、OCRで送り状を完璧に読み取ることではなく、「運用上、確実にヒットする検索条件」を成立させること。
OCR精度は印字品質に依存して揺れる——だから100%を追わず、確実に取れる情報（出荷日＝スキャン日）と誤認しにくい運用キーワード（顧客名・受注No）の組み合わせで、実用上ほぼ100%の精度でヒットさせる。
見つけた送り状は、そのまま画面操作でメール・FAX送信。「探す→印刷→FAX」の連鎖を断つ。
Design
設計のキモ
順序ではなく、並列の3本の柱。それぞれがこのシステムを支えている判断です。
三つの判断 / Three Decisions
02
PrincipleOCR 精度ではなく、運用ヒット率で設計する
送り状の印字品質にはバラつきがあり、OCR 精度 100% を追っても限界がある。確実に取れる情報（出荷日＝スキャン日）と、誤認の少ない運用キーワード（顧客名・受注 No）の組み合わせで、実用上ほぼ 100% の精度で意図する送り状をヒットさせる。
03
Principle探す→印刷→FAX を、画面操作で
見つけた送り状を、そのままシステムからお客様へメール・FAX 送信できる。「PDF を開いて、必要なページだけ抽出して、印刷して、FAX して…」という連鎖そのものを画面操作に置き換える。
Stack
使った技術・環境
Google Cloud Vision API（OCR / 日本語）事業者別ルールベースパーサー（決定論的・安定）AWS Lightsail（インフラ、予定）
Contact
聞いてみたいことがあれば、どうぞ。
中身まで見てもらった上で、「うちの場合は？」「これ応用できる？」と気になったら、聞かせてください。 具体的な問いから、もう一段踏み込んだ話ができます。
ご相談後に、こちらからしつこく営業することはありません。