紙の納品書を電子データ化するOCR自動化の構成は、中小規模の業務であれば「GAS（Google Apps Script）＋Vision OCR」で十分に効果を発揮する。しかし、運用を続けるうちに処理件数が増え、定期バッチ処理としての安定稼働が求められると、GAS単体構成では限界が露呈する。本記事では、OCR精度ではなく、運用とアーキテクチャの適応力に焦点を当て、Cloud Runを加えた新構成によって何がどう改善されたのかを、現場視点で解説する。
GAS＋Vision OCR構成の成功と限界
納品書の電子化を進めた最初の構成は、「GAS＋Google Cloud Vision OCR」の非常にシンプルな構成だった。これは中小規模の業務改善には理想的とも言えるアプローチで、実際に業務効率化という成果も得られていた。だが、運用を続ける中で「件数の増加」「バッチ処理化の必要性」が浮き彫りになり、この成功構成にも限界が見えてきた。
GASは万能ではない──実行時間制限という現実
GASには1回の実行が約6分以内という明確な制限がある。この制限は小規模処理では問題にならないが、処理件数の増加により、1件あたりの処理時間が重なれば、スクリプトがタイムアウトしてしまう。OCRの精度には満足していても、「動かない」「処理が不安定になる」といった運用面での障害が出てきた。
OCR結果を「待つ」構成がボトルネック
GASからVision OCRを呼び出す際、
- PDFの取得
- OCRの完了待ち
- 結果の書き込み
といった一連の流れを同期的に待機しながら処理する構成になっていた。これにより、「すべてを1つの関数内で順番に処理する」構成が、件数増加とともに不安定化を招いていた。1件ごとのOCR処理時間のバラつきも蓄積され、全体の処理がボトルネック化していったのだ。
「正しく動く」が「運用に耐えない」に変わる瞬間
最初は動いていた構成が、次第に
- タイムアウト
- 手動での再実行
- 結果の不整合
といった「技術的には正しいが、運用では破綻する」状態に至る。これは中小企業の現場でもよくある話で、機能要件は満たしているが非機能要件（安定性・可用性）が崩れる典型例になっていた。
Cloud Runとの役割分担で実現した「待たないGAS」構成
この課題を乗り越えるために、構成そのものを分離するという判断を行った。ポイントは「OCRエンジンを変えるのではなく、その呼び出し方・運用方法を変える」という点にある。
GASは「制御と記録」に専念させる
新構成では、GASの役割を以下のように絞り込んだ。
- 処理対象の管理（Googleスプレッドシート）
- Cloud Runへの処理指示（HTTP呼び出し）
- OCR結果の記録
重たい処理、つまりPDFの読み込みやOCR実行そのものは一切GAS側で持たない。この構成変更により、GASは常に数秒以内に処理が完了するようになり、タイムアウトのリスクを完全に排除できた。
Cloud Runが「重たい処理の代行役」になる
Cloud Run側では以下の処理を担当する：
- Google DriveからPDFを取得
- 一時的にGCS（Cloud Storage）に保存
- Vision OCRを呼び出して画像認識
- 結果を整形し、GAS経由でスプレッドシートへ返却
ここで重要なのは、Cloud Runが完全に非同期で動作するということ。これにより、1件あたりの処理時間に左右されず、並列処理にも耐えられる構成が実現できた。
OCRエンジンはそのまま──変更したのは「使い方」だけ
誤解してはいけないのは、「OCR精度が問題で構成を変えたわけではない」という点。OCRエンジンそのものは、以前と同じVision OCR（DOCUMENT_TEXT_DETECTION）を使用している。構成変更の焦点は精度ではなく「運用に耐えうるアーキテクチャ」だった。
技術選定の現実解：中小企業にとっての「ちょうどいい構成」
この新しいアーキテクチャは、単に技術的に面白いというだけではなく、中小企業の現場にフィットする実用的な構成として機能している。ここに本記事の最も伝えたいポイントがある。
増え続ける処理量に耐える「スケーラブルな仕組み」
クラウドの特性を活かし、処理数が増えてもCloud Run側で処理をスケールアウトできる。これにより、「今日はPDFが多いから処理が遅い」といった問題が解消された。業務量に合わせて自動的に対応できる構成というのは、中小企業でも十分に実現可能だ。
GASを活かしつつ、無理をさせない設計が鍵
GASはあくまでスクリプトベースで扱いやすく、初心者でも理解しやすい。このメリットを活かしながら、苦手な重処理はCloud Runに任せるという分業設計が、現実的なバランスとして非常に優れている。
「動く」よりも「回る」構成を
この一連の改善から得られた最大の学びは、システムは“動くだけ”では足りないということだ。現場で毎日、継続的に「回し続けられる」構成でなければ、たとえ初期導入に成功してもすぐに破綻する。構成の見直しは“成長に耐える業務設計”の一部であり、これは中小企業にとって避けて通れない視点だ。
まとめ：中小企業こそ、持続可能な技術選定を
本記事で紹介したアーキテクチャは、あくまで一例にすぎない。しかし、「今は動く」構成が、運用フェーズで破綻する例は中小企業の現場において非常に多い。ポイントは以下の3点だ。
- GAS単体ではスクリプトの限界が業務成長に足かせになる
- Cloud Runとの組み合わせで安定性・スケーラビリティ・再実行性を確保
- 精度よりも“使い続けられる構成”を選ぶことが業務改善の鍵
同じような構成で悩んでいる中小企業の担当者には、ツールを変える前に構成を見直すという視点をぜひ持ってもらいたい。そして、必要であればクラウド構成のアドバイスや外部の支援を活用することも、賢明な判断である。
中小企業の現場には、「ちょうどいい技術選定」こそが最大のDX推進策になる。次に進むべき構成を見極める力が、経営を支える“静かな力”になるはずだ。
最後まで、お付き合いいただきありがとうございます。
また、お会いしましょ。
