case-01

AI自動化本番運用

紙の納品書を、瞬時に「検索できるデータ」に

月3,000枚届く紙の納品書を、スキャンして放置するだけで、伝票番号から1発検索できる状態に。経理の請求書突合作業を、紙の山から解放する。

Before — 紙の納品書を山から探す
After — 伝票番号で1発検索、現物PDFを画面で確認

Overview

このシステムは、何をしている?

Overview / 概要

物品と一緒に届く紙の納品書を、スキャナで Google Drive INBOX フォルダに置くだけ。以降の OCR・抽出・台帳化はすべて自動進行。経理は伝票番号で検索して、納品書の現物 (PDF) と抽出した金額・日付の両方を、その場で確認できる。

Input入力
  • 01

    紙の納品書をスキャンした PDF

  • 02

    月 約 3,000 枚 / 取引先 200 社以上

  • 03

    フォーマットは取引先ごとにバラバラ

Output出力
  • 01

    伝票番号で 1 発検索 → 該当 PDF を画面表示

  • 02

    日付・伝票番号・合計金額の台帳 (Records)

  • 03

    各社・各月の納品金額合計 (請求書突合用)

Architecture

システム構成

サービスがどこに配置され、どう繋がっているか。

人 / Human物理スキャンと検索の利用者
スキャン担当者
紙の納品書をスキャナーで
PDF を生成
PC + Google Drive Desktop
Drive デスクトップアプリでローカルフォルダがクラウドと同期
経理担当者
伝票番号で検索し、PDF と抽出値を照合
Drive Desktop で自動同期
Drive Desktop で自動同期ローカル → クラウド (INBOX へ反映)
Google Workspaceストレージ・オーケストレーション・台帳・検索 UI
Google Drive — INBOX フォルダ
同期で届いた PDF が並ぶ取り込み待ちフォルダ
Drive ⇄ GASDrive ⇄ GAS新着 PDF の一覧化・取得
Google Apps Script(GAS)
システム全体のオーケストレーター(司令塔)
  • INBOX フォルダの新着 PDF を見つけて、台帳に登録する
  • 未処理の PDF を Cloud Run の OCR サービスへ送り、テキスト化する
  • OCR テキストから取引先を判定し、伝票番号・日付・金額を抽出する
  • 抽出結果を台帳(Records)に書き込み、処理状況を更新する
GAS ⇄ スプレッドシートGAS ⇄ スプレッドシート読み取り・書き込み
Google スプレッドシート — 納品書台帳
1 つのスプレッドシート / 3 シート構成
RawDataConfigRecords
  • RawDataB列: fileId / C列: OCR テキスト / D列: 処理状況
  • Config仕入先キーワードのマッチングルール
  • Records日付・伝票番号・金額・Drive リンクの台帳
ブラウザ ⇄ スプレッドシートブラウザ ⇄ スプレッドシートRecords を伝票番号で検索
ブラウザ(検索 UI)
Sheets を開く必要なし。専用検索アプリで伝票番号を入力するだけで 1 発でヒット。PDF リンクから現物を目視確認できる。
ブラウザ → Drive (PDF を開く)
POST fileId / OCR textPOST fileId / OCR text
Google CloudOCR ワーカーと Vision API
Cloud Run — ocr-worker
asia-northeast2 / エンドポイント /ocr で受信
https://ocr-worker-xxxxxx.asia-northeast2.run.app/ocr
内部呼び出し内部呼び出し
Cloud Vision OCR
document.text_detection で本文抽出
凡例単方向双方向Google WorkspaceGoogle Cloud

Flow

データフロー

1枚の紙が、検索可能なレコードになるまで。誰が/何が、どんなデータを動かすか。

アーキテクチャ図が「どこに何があるか」を示すのに対し、こちらは「いつ・誰が・何のデータを」動かすかの時間軸を示します。 8 ステップ、上から下へ順に進行します。

ACTORAIシステム
  1. 01
    STEP 01 / 08

    紙の納品書をスキャン

    経理に届いた紙の納品書を、スキャナーでスキャンして PDF を生成。PC のローカルフォルダ(Google Drive Desktop の同期対象)に保存される。

    紙の納品書
    physical
    scan.pdf
    local file
    次へsaved to local folder
  2. 02
    システムSTEP 02 / 08

    ローカル PC → クラウドへ自動同期

    Google Drive Desktop App が、ローカルフォルダの新規ファイルを検知し、クラウド側の INBOX フォルダへ自動反映する。経理は何もしない。

    scan.pdf
    local
    INBOX/scan.pdf
    cloud
    次へDrive sync
  3. 03
    システムSTEP 03 / 08

    新着 PDF を台帳に登録

    GAS が定期的に INBOX をスキャンし、新規 PDF を検知すると、その fileId を RawData シートに「未処理」状態で追記する。

    INBOX 新着 PDF
    Drive
    RawData 行
    status: 未処理
    次へGAS time trigger
  4. 04
    システムSTEP 04 / 08

    未処理 PDF を OCR ワーカーへ送信

    GAS が RawData の未処理行を見つけ、その fileId を Cloud Run の OCR エンドポイントへ POST する。

    fileId
    from RawData
    POST /ocr
    Cloud Run worker
    次へHTTPS request
  5. 05
    AISTEP 05 / 08

    PDF からテキストを認識

    Cloud Run 内部で Cloud Vision OCR が PDF を解析し、本文テキストを返却。GAS は受け取ったテキストを RawData の対応行に書き込み、状態を「OCR 済み」に更新する。

    PDF bytes
    input document
    本文テキスト
    plain text
    次へOCR result
  6. 06
    AISTEP 06 / 08

    取引先と項目を抽出

    GAS が OCR テキストを読み、Config シートのキーワードで取引先を判定。取引先ごとのパーサーが、日付・伝票番号・合計金額を抽出する。

    本文テキスト
    raw OCR
    { 日付, 伝票番号, 金額 }
    structured
    次へparser by vendor
  7. 07
    システムSTEP 07 / 08

    台帳(Records)へ登録

    抽出済みデータを Records シートへ書き込む。日付・伝票番号・金額に加えて、対応する Drive 上の PDF へのリンクも一緒に保存される。RawData の状態は「抽出済み」に更新。

    構造化データ + リンク
    values + Drive URL
    Records 行
    Sheets ledger
    次へappend row
  8. 08
    STEP 08 / 08

    経理担当が伝票番号で検索 → PDF を開く

    経理は請求書突合の際、専用の検索 Web アプリで伝票番号を入力するだけ。該当レコードが 1 発でヒットし、保存されている PDF リンクから納品書を画面で目視確認できる。Sheets を直接開く必要はない。

    "INV-2024-0421"
    filter query
    PDF + 抽出値
    verified
HUMAN TOUCHPOINTS
2/ 8 steps
スキャン投入と、最後の検索のみ。
AUTOMATED HOPS
6/ 8 steps
同期・登録・OCR・抽出・保存を無人で実行。
DATA SHAPE CHANGES
紙 → PDF → 行 → テキスト → 構造化
5 つの形態を経て検索可能なレコードに到達。

Insight

問題の本質

依頼者が口にする問題と、本当に解くべき問題は、たいてい違う場所にあります。

01
Surface
表面の問題

紙の納品書を山から探すのが大変。検索できるようにしたい。

02
Core
実際に解くべき問題

問題の核は、作業量そのものではなく、それを「仕方ない」と諦めて毎月続けている従業員の心的な負担です。

煩雑な業務に伴うストレスは日常に溶け込み、声にも出されないまま蓄積していく。

中小企業の現場で、いちばん見えにくく、いちばん根深い問題。
03
Our Lens
info-flagの着眼点

システムの仕事は、データを整理することではなく、現場の心的な負担を肩代わりすること。

「探さなくていい」「すぐに呼び出せる」──その小さな安心感が、毎月の我慢を強いられてきた人にとっての本当の解放になります。同時に、IT導入の恩恵を、抽象的な約束ではなく日々の手応えとして実感してもらう。

中小企業のDXで、ここを見落としてはいけない視点だと考えています。

Design

設計のキモ

順序ではなく、並列の3本の柱。それぞれがこのシステムを支えている判断です。

三つの判断 / Three Decisions
01
Principle

「スキャンして放置」を最優先

入口を一番シンプルに保つ。INBOX フォルダに置くだけで、以降は人を介在させない。手作業が増えれば、現場で使われなくなる。

02
Principle

OCR 精度に依存しない設計

OCR は必ず誤認するという前提で組む。誤認そのものを検知する仕組みを実装し、間違った金額が集計値として扱われないようにしている。最終確認は現物 PDF の目視で担保するため、結果として精度は 100%。OCR そのものの精度追求にコストはかけない。

03
Principle

GAS + Cloud Run で安価に

コアロジックは GAS。重い処理(OCR)だけ Cloud Run + Vision API に切り出し、従量課金で運用。月 3,000 枚の規模に大規模 SaaS や専用 OCR サービスは過剰投資。

Stack

使った技術・環境

Google Apps Script(GAS)Google Drive(INBOX フォルダ)Google Sheets(RawData / Config / Records)Cloud Run(asia-northeast2)Cloud Vision OCR

Contact

聞いてみたいことがあれば、どうぞ。

中身まで見てもらった上で、「うちの場合は?」「これ応用できる?」と気になったら、聞かせてください。 具体的な問いから、もう一段踏み込んだ話ができます。

ご相談後に、こちらからしつこく営業することはありません。