手書きの帳票をデータにする：人の入力、帳票OCR、生成AIを比べる

手書きの帳票は、帳票OCRか生成AIのどちらか一方に任せず、機械が読み、読み取りの怪しい項目だけを人が見る形にするのが現実的です。どちらの道具も、公式の文書で「間違えることがある」と明記しています。違いは、間違いに気づく手がかりを出力に持っているかどうかです。

この記事では、検査記録や作業日報のような手書きの紙を、集計できるデータにする三つの方法を、公式の文書に書かれた条件で比べます。比べるのは、人が打ち込む方法、帳票OCR（Microsoft の Azure Document Intelligence の Read モデルを例にします）、生成AIの画像・PDF入力（Anthropic の Claude API を例にします）です。2026年10月19日時点の文書にもとづいています。

今回は、実際の帳票で読み取りの正解率を測っていません。精度の数字は書かず、各社が文書に書いている条件と限界だけを扱います。

三つの方法の比べ方

以下、それぞれの条件を確かめていきます。

人が打ち込む：基準になるが、基準も間違える

人が読んで打ち込む方法は、読み取りの正しさを測る基準になります。機械の出力が合っているかどうかは、最終的には人が紙を見て決めるからです。

ただし、人の入力が常に正しいわけではありません。打ち間違いも、読み間違いも起きます。この記事ではその割合の数字を持っていないので、書きません。確かなことは二つあります。一つは、人が打つ方法は量に比例して時間がかかること。もう一つは、紙の束が溜まるほど、手が回らず入力されないまま残る帳票が増えることです。データにならなかった紙は、集計にも使えません。

人の入力は、最初に正解の見本を作る場面で使うのが向いています。機械の出力と比べる基準として、数十枚だけ人が入力しておく。この基準が無いと、後で述べる二つの道具のどちらが自社の帳票に合うのかを、比べようがありません。

帳票OCR：位置と信頼度が出るので、確認の対象を絞れる

Azure Document Intelligence の Read モデル（モデルID は prebuilt-read、2024年11月30日版が一般提供）は、PDF やスキャン画像から印刷文字と手書き文字を取り出します。文書には、手書き文字を取り出せる言語として日本語が挙がっています。

出力の特徴は、読み取った結果に付く情報の多さです。単語ごとに位置（座標）と信頼度が返り、行ごとに手書きの文字かどうかの判定と、その判定の信頼度が付きます。信頼度が低い単語だけを人が見る、という運用が組み立てられるのは、この仕組みがあるからです。

入力の条件も具体的に書かれています。

• PDF や TIFF は2,000ページまで。ファイルサイズは有料の階層で500MB、無料の階層では4MB
• 画像の大きさは50×50〜10,000×10,000ピクセル
• 文字の高さは、1024×768ピクセルの画像で12ピクセル以上。150dpi の8ポイント程度に当たる
• 写真やスキャンは、1文書につき、鮮明な1枚か高品質のスキャンが望ましい

注意したいのは言語コードの扱いです。文書は、言語が確実に分かっていて、その言語のモデルだけを使わせたい場合を除き、言語コードを指定しないよう書いています。指定すると、不完全または不正確な文字が返ることがあるためです。日本語の帳票に英数字の品番が混じるのは普通なので、この注意は現場の帳票にそのまま当てはまります。

手書きの日本語をどこまで正確に読めるかは、文書からは分かりません。対応言語に日本語が入っていることと、実際の帳票で読めることは別です。自社の帳票で、人が入力した基準と照らして測る必要があります。

生成AIの画像・PDF入力：自由記述に強いが、信頼度は付かない

Claude API は、画像と PDF を入力として受け取り、指示した形で中身を返します。「品番、不具合の内容、数量を JSON にして」と頼めば、その形に整えて返す。書式が決まっていない自由記述の日報では、この柔軟さが効きます。

条件も文書に書かれています。

• PDF は1リクエストにつき32MBまで。ページ数は600ページまで（文脈の大きさが100万トークン未満の場合は100ページまで）
• 各ページは画像として処理される。小さい文字や複雑な表が多いPDFは、ページ数の上限より先に文脈の枠を使い切ることがある
• 画像は1枚10MBまで（API を直接使う場合）。縦横は8000×8000ピクセルまで
• 画像は28×28ピクセルの区画ごとに読まれ、1000×1000ピクセルの画像でおよそ1,296トークン。大きすぎる画像は縮小され、文字が読みにくくなることがある

限界についても、文書は率直です。画質が低い、回転している、200ピクセル未満と非常に小さい画像では、誤りや、実際には無い内容を出力することがあると書かれています。JPEG を何度も圧縮すると、文字が読めなくなることがあるとも注意しています。そのうえで、完全な正確さが求められる用途では、人の監督なしに使わないよう書いています。

帳票OCRとの決定的な違いは、出力に信頼度が付かないことです。読めなかった文字を、それらしい別の文字で埋めて返すことがあり得ます。そして、その埋めた箇所と正しく読めた箇所が、出力を見ただけでは区別できません。この点は文書の記述にもとづく私の推測ですが、手書きの数値（寸法、数量、ロット番号）を生成AIだけで読ませると、間違いが静かに紛れ込む危険があります。

組み合わせる

三つは競争する関係ではなく、役割が違います。製造業の帳票で、この組み合わせが筋が良いと考える理由を順に書きます。

1. 人が数十枚を入力して、基準を作る。帳票の種類ごとに、読みにくい字や癖のある書き方も含めて選ぶ
2. 同じ数十枚を、帳票OCRと生成AIの両方に読ませ、基準と比べる。項目ごとに（品番、日付、数量、所見）どちらが合うかを見る。測るのは自社の帳票であり、他社の数字は参考になりません
3. 本番では、項目ごとに合う道具を割り当てる。書式が決まっていて数値の多い欄は帳票OCRの信頼度を見て、低いものを人に回す。自由記述の所見は生成AIに構造化させる
4. 数量、日付、ロット番号のように、後の工程で使うものは、マスタや範囲との照合を必ず通す。品番がマスタに無い、日付が未来、数量が桁違い、といった異常は機械で弾ける

生成AIで読んだ結果をデータにする部分は、構造化出力で不具合報告を JSON にする に実装の手順を書いています。構造化出力で保証されるのは形式までで、中身の正しさは別に確かめる、という考え方は 不具合報告と作業日報をデータに変える にまとめました。

紙の帳票を外部のサービスに送る場合は、帳票に何が書かれているかを先に点検してください。顧客名や図面の番号が書かれていれば、生成AIに現場の文書を入れる前に点検する五つのこと の問いが、そのまま当てはまります。