📑

AI-OCR × 現場帳票で始める「脱・紙＆手入力」 #1

に公開
Python
OCR
AIOCR
tech

AI-OCR × 現場帳票で始める「脱・紙＆手入力」 #1

要件整理とアーキテクチャ設計（現場サイドの視点から）

はじめに

製造業・建設業・設備保守・物流など、現場の業務にはいまでも

  • 点検チェックシート
  • 作業日報
  • 検査成績書
  • 工事完了報告書

のような「紙の帳票」が大量に存在します。

多くの現場では、

  1. 現場で紙に手書き
  2. 事務所に戻ってから、担当者が Excel や基幹システムに「手入力」
  3. 入力ミスや記入漏れを上長がチェック
  4. 集計できるのは数日〜1ヶ月後

というフローが続いており、

  • 入力に時間が取られる
  • 転記ミスが発生する
  • データがすぐに使えない

といった課題につながっています。

本シリーズでは、

「AI-OCR × 現場帳票」で、紙と手入力が前提だった業務を
段階的にデジタル化していくための設計・実装パターン

を整理していきます。

第1回のテーマは 要件整理とアーキテクチャ設計 です。
「どんな帳票に、どういう狙いで AI-OCR を入れるのか」を、現場サイドから見て整理します。

現場帳票の「あるある」パターンを整理する

AI-OCR の話に入る前に、対象となる帳票のパターンを整理しておきます。
現場でよく見る帳票は、大きく次のように分けられます。

パターン1：レイアウト固定＋活字メイン

  • テンプレートは固定（A4 / A3 の決まったフォーマット）
  • 記入項目は主に活字（PC 打ち / ラベル貼付 等）
  • 例：
    • 機器一覧表
    • 入出庫記録（バーコード＋数量）

このパターンは「活字×決まった位置」なので、
既存の OCR でも比較的高精度に読める ことが多いです。

パターン2：レイアウト固定＋手書き数字・記号

  • テンプレートは固定
  • 現場での記入は「○ ×」「数値（温度・圧力）」「チェック欄」が中心
  • 例：
    • 日次点検チェックシート
    • 温度記録表（冷蔵庫・冷凍庫）
    • 圧力／流量の定期記録

数字と記号が中心なので、
前処理（傾き補正・二値化）＋AI-OCR でかなり実用レベルになります。

パターン3：レイアウト固定＋手書きフリーテキスト

  • テンプレートは固定
  • 「特記事項」「不具合内容」「対応内容」など、自由記述欄がある
  • 例：
    • クレーム・トラブル報告書
    • 点検結果のコメント欄

ここは 完全自動化よりも「検索できるようにする」「要約する」 方向で考えた方が現実的です。

パターン4：レイアウト半固定・複数種類

  • 日付やロゴは同じだが、部署ごとに微妙にレイアウトが違う
  • 年度ごとに少しずつフォーマットが変わっている
  • 似ているが完全には同じでない帳票が多数存在

このパターンでは、
「どの帳票テンプレートかをまず判定する」 レイヤが必要になることが多いです。

AI-OCR 導入前に決めておくべき4つのこと

現場帳票に AI-OCR を入れる前に、
最低限次の4点を決めておくと、後戻りが少なくなります。

1. 対象帳票のスコープ

  • どの帳票から始めるか
  • 1 種類に絞るのか、2〜3 種類をまとめて扱うのか
  • 手書きの割合がどの程度か

おすすめは、

まずは「1種類の帳票」に絞る

ことです。

その帳票が、

  • 件数が多い
  • 手入力の工数が大きい
  • 業務的に重要（ミスが許されない）

のどれかに当てはまると、PoC の効果が分かりやすくなります。

2. 目標精度と運用ルール

  • どれくらいの精度を目標とするか
    • 例：数値項目の 95% は自動で正しく読めること
  • 読み間違いが許されない項目はどれか
    • 例：圧力・温度の上限値に近いもの、重大な NG フラグ など
  • 人間による確認・修正フローをどうするか
    • 全件目視するのか
    • 信頼度スコアが低いものだけ確認するのか

AI-OCR は「100% を自動化する」ものではなく、

「8〜9 割を機械が先に埋めて、人間が最後を見る」

くらいの設計にしておく方が、現場への導入はスムーズです。

3. 画像の取得方法（入力チャネル）

  • スキャナでまとめて読み込むのか
  • 現場でスマホ・タブレット撮影するのか
  • MFP（複合機）から PDF を集約するのか

画像の状態（解像度・歪み・影・ブレ）は、
AI-OCR の精度に直結する一番の要因です。

PoC のときから、

  • 実際の現場と同じ条件でサンプルを集める
  • 「スキャナ前提」なのか「スマホ前提」なのかを明確にする

ことが重要です。

4. 出力先と「データの終点」

  • 読み取ったデータはどこへ入れるのか
    • Excel / CSV
    • 既存の基幹システム
    • BI ツール（Power BI 等）
  • 既存の入力フローをどう置き換えるか
    • 既存画面に RPA で自動入力する
    • 取り込み用の CSV インターフェースを用意する

AI-OCR はあくまで「中間工程」です。
最終的にどこにデータを載せたいのかを最初に決めておくと、
アーキテクチャがブレにくくなります。

現場帳票向け AI-OCR の基本アーキテクチャ

ここからは、典型的なアーキテクチャをテキストで整理します。

全体ブロック図（テキスト）

シンプルな構成は、次のように分解できます。

  1. 入力レイヤ

    • スキャナ / MFP / カメラ
    • 画像アップロード UI

  2. 前処理レイヤ

    • 傾き補正
    • トリミング
    • ノイズ除去・二値化
    • 解像度調整

  3. OCR エンジンレイヤ

    • クラウド OCR（各種 API）
    • オンプレ／OSS（Tesseract, PaddleOCR 等）

  4. 後処理レイヤ

    • レイアウト解析（どのマスがどの項目か）
    • 数値の補正（0 と 8, 1 と 7 等）
    • 正規化（単位変換、桁揃え）

  5. 確認・修正レイヤ

    • Web UI 上での目視確認
    • 差分表示（原票画像との比較）
    • 修正履歴の保存

  6. 出力・連携レイヤ

    • CSV エクスポート
    • DB への保存
    • 既存システム・RPA との連携

この中で AI-OCR が担当するのは 3（+一部 2,4） だけです。
1,5,6 は「システム設計」と「業務フロー設計」の領域になります。

クラウド／オンプレ構成パターンの比較

AI-OCR を現場帳票に入れるとき、
よく検討されるのが「クラウド前提か、オンプレ前提か」です。

クラウド前提（各種OCR API）

  • 特徴

    • セットアップが早い
    • 手書き・多言語などに強いサービスも多い
    • スケールアウトが容易（同時処理数が増えても対応しやすい）

  • 典型的な使い方

    • 現場帳票の画像をサーバへアップロード
    • サーバ側からクラウド OCR API を呼び出し
    • 結果 JSON を後処理レイヤへ渡す

  • 注意点

    • ネットワーク接続が必須
    • 情報セキュリティ・個人情報保護の要件を満たす必要がある
    • API 利用料（従量課金）のコスト試算

オンプレ／エッジ前提（OSS＋自前モデル等）

  • 特徴

    • インターネット非接続環境でも動作
    • データが外部に出ない
    • ハードウェア選定とモデルチューニングが鍵になる

  • 典型的な使い方

    • Edge デバイス（PC / サーバ）上で前処理〜OCR〜後処理まで完結させる
    • 現場 LAN 内でのみ運用する

  • 注意点

    • 初期構築の難易度はやや高い
    • モデル更新・チューニングの運用設計が必要

現場帳票の場合、

  • インターネット禁止・閉域網前提の現場 → オンプレ／エッジ
  • クラウド利用可・本社集約したい → クラウド

という切り分けになることが多いです。

「PoC → 本番」へのステップ

最後に、現場帳票向け AI-OCR を
PoC から本番まで持っていく際のステップをまとめます。

Step 1：帳票を1種類に絞り、サンプルを集める

  • 対象帳票を 1種類に絞る
  • 過去の紙帳票を 100〜300 枚程度スキャン
  • 可能であれば「正解データ」（手入力された Excel 等）も揃える

この時点で、「帳票のバリエーション（書き方のクセ）」も見えてきます。

Step 2：前処理＋AI-OCR＋後処理の PoC パイプライン

  • 簡易的な前処理（傾き補正・トリミング）
  • AI-OCR エンジン（クラウド／オンプレのどちらか）
  • 最低限の後処理（座標→項目マッピング）

を Python 等でつなぎ、「バッチ処理で CSV を吐く」ラインを先に作ります。

ここでは UI は作らず、

  • 精度の見積もり
  • 読み間違いの傾向分析（0/8、1/7、チェック欄など）

に集中するのがおすすめです。

Step 3：確認画面と簡易ダッシュボード

PoC の精度が見えてきたら、

  • Web ベースの確認画面
    • 左に原票画像、右に読み取り結果
    • 修正結果を保存
  • 集計ダッシュボード
    • 帳票単位のエラー率
    • 項目別のエラー傾向

を追加します。

この段階になると、現場の担当者・管理者との会話も
「使い方」と「運用」の話に変わっていきます。

まとめと次回予告

本記事では、

  • 現場帳票のパターン整理
  • AI-OCR 導入前に決めておくべき4つのこと
  • 現場帳票向け AI-OCR の基本アーキテクチャ
  • クラウド前提／オンプレ前提の構成パターン
  • PoC → 本番へのステップ

を、現場側の視点で整理しました。

次回以降は、実装寄りの内容として、

  • Python + AI-OCR API を使った「現場帳票の最小サンプル」
  • 帳票レイアウトに応じた「座標→項目マッピング」の実装パターン
  • 手書き数字・チェックボックスに強い前処理の工夫

などを、コード例とともに紹介していきます。

Discussion