目次
「手書きの帳票が、いまだに紙のまま回っている」——中小企業の現場では珍しくありません。誰かが後からシステムに手で打ち直し、その転記に時間がかかり、たまに打ち間違える。この繰り返しです。
最近は生成AIの画像認識が進み、手書きの紙をスマホで撮るだけで、そこそこ読めるようになりました。ただ、これを「業務で毎日使える仕組み」にするには、読み取りの精度以外に決めることがいくつもあります。
先日、手書きの日程表を生成AIのOCRで構造化し、担当者が画面で確認・修正してから基幹データへ書き込む——という仕組みを実案件（匿名）で構築しました。この記事では、そこで分かったことを整理します。
作った仕組みの全体像
流れはシンプルです。紙をスマホで撮る、AIが読んで項目ごとに分解する、担当者が画面で確認して直す、確定したら基幹データに書き込む。
ポイントは3番目の「人が確認して直す」を、最初から工程に組み込んでいることです。ここを省こうとすると、たいてい失敗します。
精度を上げたのは、モデルではなくプロンプト
手書きの読み取り精度は、最終的に85〜90%程度まで出せました。
意外に思われるかもしれませんが、この精度に効いたのは「どのAIモデルを使うか」ではありませんでした。効いたのは、その業務の知識をプロンプトに書き込むことです。
具体的には、次のようなルールを言語化して渡しました。
- 元号の判定ルール：日付欄に元号が省略されて書かれている場合、どう解釈するか
- 記載ゆれの正規化ルール：同じ意味で複数の書き方がある項目を、どの表記に寄せるか
汎用のOCRに「読んでください」と投げると、書いてある文字をそのまま返してきます。しかし業務帳票には、その現場でしか通じない省略や書き癖があり、それを知らないと正しく解釈できない欄が必ずあります。逆に言えば、そのルールを渡せば精度は上がります。
つまり、AI-OCRの精度改善は技術の話というより、現場の暗黙知を文章にする作業に近いのです。ここは業務を知っている人でないと書けません。
なお、生成AIの仕様やモデルは頻繁に変わるため、実装時の最新条件は必ず公式で確認してください。
100%を目指さない：プレフィル前提の設計
85〜90%という数字を見て「残りの10〜15%はどうするのか」と思われるはずです。答えは、人が直すです。
ここは意図的な設計です。手書き文字の読み取りで100%を狙うと、コストが跳ね上がるわりに、結局どこかで誤りが出ます。しかも「たまに間違う自動化」は、人が全件を疑って見直すことになり、かえって手間が増えます。
そこで、AIの出力は「完成品」ではなく**下書き（プレフィル）**と位置づけました。
| 全自動を目指す設計 | プレフィル前提の設計 | |
|---|---|---|
| AIの役割 | 正解を出す | 下書きを埋める |
| 人の役割 | 例外のときだけ介入 | 必ず確認して確定する |
| 誤りの扱い | 気づかず通過するリスク | 確定前に必ず止まる |
| 現場の心理 | 信用しきれず二重チェック | 直すのが前提なので安心 |
手作業でゼロから入力していた工程が、「埋まっているものを見て、違うところだけ直す」に変わります。全部を自動化しなくても、入力の大部分が消えれば十分に効果が出るわけです。
そして「人が確認する」を前提にすると、次の論点が最重要になります。確認と修正がやりやすい画面かどうかです。
つまずいたのはUI：AppSheetからGAS WebAppへ
当初はAppSheetのダッシュボード機能で確認画面を作ろうとしました。撮った画像と、AIが読み取った項目を並べて表示し、その場で直せればいい——という発想です。
ところが、実際に触ってみると分かりにくい。画像と入力欄の対応が追いにくく、「いま何行目を確認しているのか」が見失われやすい。毎日使う画面としては厳しい、という判断になりました。
そこで、GAS（Google Apps Script）のWebApp単独で確認画面を作り直しました。左に撮影した帳票の画像、右に読み取り結果の入力欄、という2ペイン構成です。ノーコードツールの枠に収まらない要件だったため、必要な形をそのまま作った、という選択です。
GAS WebApp特有の罠
ただし、GAS WebAppには独特の癖があります。実際に踏んだものを2つ挙げます。
- iframe内でviewportが効かない：GAS WebAppはiframeの中で動くため、スマホ向けのviewport指定が期待どおりに効きません。画面幅を前提としたレイアウト設計をやり直すことになりました。
- stickyが効かない：ヘッダーや画像を固定表示しようとしてもCSSのstickyが機能せず、左右の2ペインをそれぞれ独立してスクロールする構成に変更しました。結果的には、画像を追いながら入力欄を送れるので、この形の方が使いやすくなりました。
いずれも「調べれば分かる」類の話ですが、やってみるまで出てこない種類のつまずきでもあります。ノーコードで済ませるか、WebAppまで作り込むかは、こうした実装コストを含めて判断する必要があります。
教訓：分担の設計と、UIの作り込み
この案件から持ち帰った学びは、次の3つに集約されます。
- 精度はプロンプトで上げる：モデル選びより、元号の扱いや表記ゆれといった現場のルールを言語化する方が効きます。
- AIと人の分担を先に決める：100%を狙わず、AIは下書き、人が確定。この線引きを最初に決めると、設計がぶれません。
- UIまで作り込んで初めて定着する：読み取れても、確認しづらい画面なら現場は使いません。毎日使える画面が最後のハードルです。
特に3つ目は見落とされがちです。「AIで読める」と「業務が回る」の間には、確認画面という地味だが決定的な工程があります。ここに手を抜くと、精度がいくら高くても紙の運用に戻ります。
自社で検討するときの進め方
手書き帳票のデジタル化を考えるなら、次の順で確認するのが現実的です。
| 手順 | 確認すること |
|---|---|
| 1. 対象を1帳票に絞る | 一番枚数が多く、転記に時間がかかっている帳票はどれか |
| 2. 業務ルールを書き出す | 省略記法・表記ゆれ・日付の書き方など、現場の暗黙知 |
| 3. 精度の目標を決める | 100%ではなく「人が直す前提で何%あれば楽になるか」 |
| 4. 確認画面を設計する | 誰が、いつ、どの端末で確認するか |
| 5. 書き込み先を決める | 確定データをどのシステムのどこに入れるか |
いきなり全帳票を対象にすると、まず止まります。枚数が多く、様式が決まっている1種類から始めるのが失敗しない入り方です。
まとめ
- 手書き帳票は、生成AIのOCRで85〜90%程度まで読み取れた（実案件・匿名）
- 精度を上げたのはモデル選定より、元号や表記ゆれのルールをプロンプトに書き込むこと
- 100%を目指さず、AIは下書き・人が確認して確定するプレフィル設計にした
- 確認画面はAppSheetでは分かりにくく、GAS WebApp単独で構築。iframe内のviewportやstickyの制約も踏んだ
- 成否を決めるのは「AIが読む＋人が確認する」の分担設計と、毎日使えるUIの作り込み
RENOYでは、手書き帳票やアナログな紙の業務について「どこまでAIで読めて、どこから人が見るべきか」の切り分けから、確認画面の設計・開発までご相談を承っています。「紙が多くて自動化できないと思っていた」という段階のご相談も歓迎です。まずはお気軽に無料個別相談（オンライン・60分）をご利用ください。サービス内容をまとめた資料は資料請求からご覧いただけます。