目次
「紙の帳票を、スマホで撮るだけでデータにしたい」——生成AIの画像読み取りが身近になり、こうしたご相談が増えています。実際、手書きの帳票でもAIはかなり読めます。
ただ、私たちが実案件（匿名）で最初に試した「この帳票を読み取って」という汎用的な指示では、項目の取り違えが起きました。文字は読めているのに、どの欄の値なのかがずれるのです。
そこでプロンプトを、その帳票専用の前提を書き込んだドメイン特化型に変えたところ、精度は85〜90%まで上がりました。この記事では、その書き方と、それでも「人の確認」を残した理由を整理します。
この記事の結論
- 手書き帳票OCRは、汎用指示より帳票専用のプロンプトが効く
- 様式・項目名・単位・値の範囲を前提として書き込む
- 精度を上げても無人確定せず、人の承認を残して設計する
帳票OCRで項目を取り違える原因
汎用的な「読み取って」で起きたのは、読めない文字よりも項目の対応のずれでした。隣り合う欄の数字が入れ替わる、単位の違う値を同じ欄として扱う、といった誤りです。
原因はシンプルで、AIがその帳票の「常識」を知らないことにあります。人間の担当者は、どこに何が書かれる様式なのか、この欄にはどんな単位でどのくらいの値が入るのかを知っているから、多少崩れた字でも正しく読めます。汎用指示のAIには、その前提がありません。
つまり、精度の問題は「文字認識の性能」だけでなく、前提知識の不足でもあったのです。
ドメイン特化プロンプトの書き方
対策は、担当者が頭の中に持っている前提を、プロンプトに言葉で書き込むことです。私たちが書き込んだのは次の4点です。
| 書き込む前提 | 内容 | 防げる誤り |
|---|---|---|
| 帳票の様式 | どこにどの欄があるか | 隣の欄との取り違え |
| 項目名 | 欄の正式な名前と意味 | 似た項目の混同 |
| 単位 | 各欄の数値の単位 | 単位違いの値の混入 |
| 想定される値の範囲 | その欄に入りうる値の幅 | 桁ずれ・ありえない値 |
汎用指示との違いは、「何を読むか」ではなくどう解釈すべきかを渡している点にあります。
骨組みは、たとえば次のような形です（中身は帳票ごとに書き換えます）。
あなたは〇〇帳票の読み取り担当です。
この帳票には次の項目があります。
- 項目A：〜の欄。単位は〜。通常は〜から〜の範囲。
- 項目B：〜の欄。単位は〜。
出力は指定のJSON形式で返してください。
判読できない項目は推測せず、空で返してください。
ポイントは、帳票ごとにプロンプトを作り分けることです。「どんな帳票でも読める万能プロンプト」を目指すより、1つの様式に深く寄せた方が実務の精度に届きます。
出力はJSONで型を指定し、読めない項目は空にする
読み取り結果は、あとでシステムに流し込むためJSONで型を指定して出力させます。項目名と、それぞれが数値なのか文字列なのかを明示しておくと、後工程で扱いやすくなります。
もう1つ大事なのが、読めない項目は空で返させる指示です。AIは、読めない箇所をもっともらしい値で埋めてしまうことがあります。空欄なら人が気づけますが、それらしい誤った値は見落とされます。「分からないときは分からないと返す」ことを、プロンプトで明示しておきます。
JSON出力の揺れの対策：パーサ側にフォールバックを置く
型を指定しても、AIの出力は完全には安定しません。実際に、同じ指示でも単一のオブジェクトで返るときと配列で返るときが揺れることがありました。
ここをプロンプトの工夫だけで抑え込もうとすると、終わりのない調整になります。そこで、受け取る側のプログラム（パーサ）に、どちらの形で返ってきても同じように処理できるフォールバックを用意しました。
「AIの出力は揺れるもの」と割り切り、指示と受け取りの両側で吸収するのが現実的です。なお、生成AIの出力形式に関する仕様は変わるため、最新は各サービスの公式情報で確認してください。
精度を上げても無人確定しない設計
85〜90%は実務に乗せられる精度ですが、裏を返せば一定の割合で誤りが残るということです。そこで、読み取り結果をそのまま基幹システムに書き込むことはせず、必ず人の確認を挟む流れにしました。
確認・編集画面には、読み取った値を項目ごとに並べ、空欄や怪しい値をその場で直せるようにします。担当者の仕事は「一から入力する」から「確認して直す」に変わり、手間は大きく減りつつ、最終的な責任は人が持つ形になります。
プロンプトと人の確認はセットで決める
この案件で得た一番の学びは、プロンプトだけで精度を上げ切ろうとしないことです。
精度を90%から先に上げる調整は、急に難しくなります。その労力をかけるより、「どこまでをAIに任せ、どこからを人の確認に残すか」を最初に決めてしまう方が、早く・安全に運用に乗せられます。
進め方の順序は次のとおりです。
- 帳票を1種類に絞る：様式に寄せたプロンプトを作る
- 前提を書き込む：様式・項目名・単位・値の範囲
- 出力と受け取りを固める：JSONの型指定、空欄ルール、パーサのフォールバック
- 人の確認範囲を決める：確認・編集画面と承認の流れを設計する
よくある質問
Q. 生成AIで手書き帳票を読み取るとき、プロンプトはどう書けばいい？ 「読み取って」だけの汎用指示ではなく、帳票の様式・項目名・単位・想定される値の範囲を前提として書き込みます。出力はJSONで型を指定し、読めない項目は推測させず空で返すよう指示するのが基本です。
Q. 手書き帳票のAI-OCRはどのくらいの精度が出る？ 当社の実案件（匿名）では、ドメイン特化のプロンプトに変えたことで85〜90%の精度に到達しました。ただし100%ではないため、読み取り結果は人が確認・承認してから基幹システムへ書き込む前提で設計しています。
Q. 生成AIのJSON出力が崩れることはある？ あります。同じ指示でも、結果が単一のオブジェクトで返る場合と配列で返る場合が揺れることがあります。プロンプトで型を指定したうえで、パーサ側にもどちらの形でも受け取れるフォールバックを用意すると安定します。
まとめ
- 汎用的な「読み取って」では、文字は読めても項目の取り違えが起きる
- 様式・項目名・単位・値の範囲を書き込んだドメイン特化プロンプトで、精度は85〜90%に到達
- 出力はJSONで型を指定し、読めない項目は空で返させる。出力の揺れはパーサ側で吸収する
- 精度を上げても無人確定はせず、人が承認してから基幹へ書き込む
RENOYでは、紙の帳票をAIで読み取る仕組みについて、「どの帳票から始めるか」「どこまでを人の確認に残すか」の設計から、無料相談で承っています。「うちの手書き帳票でも読めるのか試したい」という段階のご相談も歓迎です。まずはお気軽に無料個別相談（オンライン・60分）をご利用ください。サービス内容をまとめた資料は資料請求からご覧いただけます。