「スキャンして放置」を最優先
入口を一番シンプルに保つ。INBOX フォルダに置くだけで、以降は人を介在させない。手作業が増えれば、現場で使われなくなる。
case-01
月3,000枚届く紙の納品書を、スキャンして放置するだけで、伝票番号から1発検索できる状態に。経理の請求書突合作業を、紙の山から解放する。


Overview
Overview / 概要
物品と一緒に届く紙の納品書を、スキャナで Google Drive の INBOX フォルダに置くだけ。以降の OCR・抽出・台帳化はすべて自動進行。経理は伝票番号で検索して、納品書の現物 (PDF) と抽出した金額・日付の両方を、その場で確認できる。
紙の納品書をスキャンした PDF
月 約 3,000 枚 / 取引先 200 社以上
フォーマットは取引先ごとにバラバラ
伝票番号で 1 発検索 → 該当 PDF を画面表示
日付・伝票番号・合計金額の台帳 (Records)
各社・各月の納品金額合計 (請求書突合用)
Architecture
サービスがどこに配置され、どう繋がっているか。
Flow
1枚の紙が、検索可能なレコードになるまで。誰が/何が、どんなデータを動かすか。
アーキテクチャ図が「どこに何があるか」を示すのに対し、こちらは「いつ・誰が・何のデータを」動かすかの時間軸を示します。 8 ステップ、上から下へ順に進行します。
経理に届いた紙の納品書を、スキャナーでスキャンして PDF を生成。PC のローカルフォルダ(Google Drive Desktop の同期対象)に保存される。
Google Drive Desktop App が、ローカルフォルダの新規ファイルを検知し、クラウド側の INBOX フォルダへ自動反映する。経理は何もしない。
GAS が定期的に INBOX をスキャンし、新規 PDF を検知すると、その fileId を RawData シートに「未処理」状態で追記する。
GAS が RawData の未処理行を見つけ、その fileId を Cloud Run の OCR エンドポイントへ POST する。
Cloud Run 内部で Cloud Vision OCR が PDF を解析し、本文テキストを返却。GAS は受け取ったテキストを RawData の対応行に書き込み、状態を「OCR 済み」に更新する。
GAS が OCR テキストを読み、Config シートのキーワードで取引先を判定。取引先ごとのパーサーが、日付・伝票番号・合計金額を抽出する。
抽出済みデータを Records シートへ書き込む。日付・伝票番号・金額に加えて、対応する Drive 上の PDF へのリンクも一緒に保存される。RawData の状態は「抽出済み」に更新。
経理は請求書突合の際、専用の検索 Web アプリで伝票番号を入力するだけ。該当レコードが 1 発でヒットし、保存されている PDF リンクから納品書を画面で目視確認できる。Sheets を直接開く必要はない。
Insight
依頼者が口にする問題と、本当に解くべき問題は、たいてい違う場所にあります。
煩雑な業務に伴うストレスは日常に溶け込み、声にも出されないまま蓄積していく。
中小企業の現場で、いちばん見えにくく、いちばん根深い問題。
「探さなくていい」「すぐに呼び出せる」──その小さな安心感が、毎月の我慢を強いられてきた人にとっての本当の解放になります。同時に、IT導入の恩恵を、抽象的な約束ではなく日々の手応えとして実感してもらう。
中小企業のDXで、ここを見落としてはいけない視点だと考えています。
Design
順序ではなく、並列の3本の柱。それぞれがこのシステムを支えている判断です。
入口を一番シンプルに保つ。INBOX フォルダに置くだけで、以降は人を介在させない。手作業が増えれば、現場で使われなくなる。
OCR は必ず誤認するという前提で組む。誤認そのものを検知する仕組みを実装し、間違った金額が集計値として扱われないようにしている。最終確認は現物 PDF の目視で担保するため、結果として精度は 100%。OCR そのものの精度追求にコストはかけない。
コアロジックは GAS。重い処理(OCR)だけ Cloud Run + Vision API に切り出し、従量課金で運用。月 3,000 枚の規模に大規模 SaaS や専用 OCR サービスは過剰投資。
Stack
Contact
中身まで見てもらった上で、「うちの場合は?」「これ応用できる?」と気になったら、聞かせてください。 具体的な問いから、もう一段踏み込んだ話ができます。
ご相談後に、こちらからしつこく営業することはありません。