AI-OCRの仕組み｜読み取りは2段階。確信度スコアで、直す枚数が先に分かる

この記事は、従業員10〜20名で専任の情報システム担当を置いていない会社の、経営者と経理・総務の担当者に向けて書いています。既製のSaaS型AI-OCRで請求書や納品書の手入力を減らしたいが、技術の中身までは追いきれない。そういう状況を想定しました。

扱う課題は一つです。「学習させれば精度が上がります」という説明の主語が、はっきりしないこと。ベンダーがモデルを改良する話なのか、利用者が自社の帳票を覚えさせられる話なのかで、契約後にできることは変わります。確信度スコアの読み方とあわせて、契約前に確認できる形へ落とします。

扱わないものも先に書きます。製品名の比較、価格、ランキングは対象外です。解説記事によく出てくる正読率の水準も書いていません。出典が示されておらず、こちらでは確かめられなかったためです。数値として挙げるのは、MicrosoftとGoogleの公式文書で実際に読めた内容だけに絞りました（確認日 2026-09-04）。

先に結論

結論は3つです。1つ目は、読み取りが1つの処理ではないこと。画像から文字を起こす処理と、その文字が請求書のどの項目かを決める処理は、別々に動いています。誤りが出たとき、どちらで転んだのかを見ないと対処を間違えます。

2つ目は、多くのAI-OCRが項目ごとに確信度スコアを返すこと。0から1の数値で、機械が自分の読み取りにどれだけ自信を持っているかを表します。しきい値を決めれば、目視する枚数を運用の前に見積もれる。3つ目は、「学習」の主語に2種類あることでした。

読み取りは1つの処理ではない

AI-OCRの内部は、前処理、レイアウト解析、文字認識、項目抽出のおおよそ4工程に分かれています。文字そのものを読むのは3番目まで。最後の項目抽出が、読んだ文字列を「発行日」「金額」といった欄へ割り当てています。

解説記事の多くは、文字認識までの説明で終わります。困るのは、その先です。たとえば「1」を「7」と読み違えるのと、支払期日を発行日の欄へ入れてしまうのとでは、故障している場所がまったく違う。前者は画像の質の問題で、後者は書式の想定違いです。

工程	やっていること	ここで失敗すると	気付き方
前処理	傾き・明るさ・ノイズを整える	以降の工程がまとめて崩れる	同じ帳票でも日により結果が違う
レイアウト解析	表・行・空欄の位置を見つける	行がずれ、明細の数が合わない	明細の合計が原本と一致しない
文字認識	形を文字へ起こす	数字や似た字を取り違える	1文字だけ変な値が混じる
項目抽出	文字列を項目名へ割り当てる	正しい文字が違う欄へ入る	値は原本にあるのに欄が違う

誤りは「値」と「欄」に分けて数える

社内で確かめるときは、誤りを「値そのものが違う」と「値は合っているが欄が違う」の2列で数えてください。前者が多ければ、スキャン設定や原本の受け取り方を見直す番。後者なら書式の設定や学習の問題で、スキャナを良くしても減りません。

確信度スコア｜機械が「自信の度合い」を数値で返す

確信度スコアは、読み取った項目ごとに付く0から1の数値です。Microsoftの公式文書はこれを「予測が正しいことの推定確率」と説明し、0.95という値は20回中19回は予測が正しい可能性が高いことを示す、と書いています。カスタムモデルの正確性スコアについては80%以上を目標にすることが最も良いとされ、財務や医療の記録のように機密性の高い用途では100%に近いスコアが勧められていました。同じ文書には、現時点ですべてのドキュメントフィールドが信頼度スコアを返すわけではない、とも書かれています。項目によっては数値が付かない前提で運用を組む必要があります。出典はMicrosoft Learn「カスタムモデルの正確性スコアと信頼度スコアの解釈と改善」、確認日は2026-09-04です。

この数値が効くのは、人が見る枚数を先に決められるからです。しきい値を0.9と置けば、下回った項目だけが目視の対象になる。精度を自社の枚数へ換算する考え方はAI-OCRで請求書や納品書を読み取るで扱いました。

記入例｜しきい値と目視の量

下の表は、月200枚・1枚あたり6項目という前提で、しきい値ごとに目視の量がどう動くかを書いた記入例です。数値は考え方を示すための仮の値で、特定の製品の実測ではありません。

しきい値（仮）	目視の対象（1,200項目中・仮）	1項目3秒として（仮）	この置き方が向く帳票
0.99	約240項目	約12分	誤りを絶対に通せないもの
0.95	約96項目	約5分	金額欄だけ厳しく見たいもの
0.90	約36項目	約2分	後工程で照合が入るもの
設定なし（全件目視）	1,200項目	約60分	導入から最初の1か月

しきい値を上げるほど安全側に寄り、目視の時間は増えます。決め方の順序は逆です。まず「この帳票に毎月何分使えるか」を出し、その時間に収まる値を選ぶ。超えた項目に誤りがないかは、月に一度だけ抜き取って確かめます。

「学習させれば精度が上がる」の主語は誰か

「使うほど賢くなります」と書かれていても、賢くなるのが自分の会社の帳票に対してとは限りません。ベンダーが全利用者の傾向をもとに汎用モデルを改良している場合、恩恵は受けられても、自社独自の様式が覚えられるわけではない。

学習の種類	作業するのは誰か	自社の帳票が反映されるか	既製SaaSでそのまま使えるか
ベンダー側の汎用モデル改良	ベンダー	直接は反映されない	使える。時期も内容も選べない
利用者が作るカスタムモデル	利用者または委託先	反映される	製品による。開発環境が要る場合あり
書式ごとの読み取り枠の設定	利用者	位置の指定として反映される	多くの製品に用意されている

必要な枚数の目安は、公式文書に書かれています。Microsoftの文書には、同じ書式の書類5例からカスタム抽出モデルの作成を開始できる、とあります。Googleの文書では、カスタムベース抽出モデルを最低3文書から学習できると記載されていました。出典はMicrosoft Learn「カスタムモデルをトレーニングする」と、Google Cloud の Document AI カスタムベース抽出です（確認日 2026-09-04）。

ただし、この5例や3文書を、そのまま自社に当てはめないでください。どちらもクラウドの開発者向けサービスの話で、ストレージや開発ツールの操作が前提です。既製のSaaSを契約してすぐ同じことができる、という意味ではありません。5例で始められるのは作成の開始であって、5枚で実運用の精度に届く保証でもない。

では中小企業には関係のない話なのか。多くのSaaS型AI-OCRは、この仕組みを「帳票の書式登録」や「読み取り枠の設定」として製品側で包んでいます。確認するときは技術用語ではなく「自社が受け取る請求書の書式を、こちらで登録できますか」と聞くのが早い。

読み取れない原因を、直せるものと直せないものに分ける

読み間違える原因は、いくつかの型に整理できます。ここで見るのは、その原因がどの工程に効いてくるかと、自社の側で直せるかどうかの2点です。誤りがどの箇所に集中するか、出た誤りを検算でどう捕まえるかはAI-OCRで請求書や納品書を読み取るで扱っているため、ここでは繰り返しません。直せないものにスキャナの設定を試し続けても、時間だけが減っていきます。

原因	効いてくる工程	自社で直せるか	直し方・避け方
手書き文字	文字認識	直せない	選択式にする、電子で受け取る形へ変える
罫線と文字の接触	レイアウト解析	直せない（先方の様式）	文字の一部が欠けて読まれるため、解像度を上げても戻らない
解像度の不足	前処理・文字認識	直せる	解像度を上げ、圧縮の強い設定をやめる
原本の傾き	前処理	直せる	自動補正の有無を確認し、給紙をそろえる
複写伝票の薄い印字	文字認識	ほぼ直せない	控えではなく原本側を読む。無理なら手入力
押印と文字の重なり	文字認識・項目抽出	直せない	押印位置の変更を依頼し、金額欄と重なるものは除外

右の2列を見ると、自社の努力で減らせるのは解像度と傾きの2つだけだと分かります。残りは相手先の様式や運用に関わるため、こちらの設定では動かせない。対象を選ぶ段階で「手書きが入るもの」と「複写の控え」を外しておくと、後の苦労がかなり減ります。読み取らせない、という選択も設計のうちでした。

業務のどこに置くか

流れは、読み取り、確信度による振り分け、人の目視、基幹システムへの取り込み、の4段です。つまずくのは2段目で、スコアが出ていても、それで一覧を分ける運用まで作れていない。振り分けがなければ、入力の時間は減っても確認の時間が丸ごと残ります。確認する人の決め方はAIと人の役割分担で扱いました。

段	ここで決めること	決めていないと起きること
読み取り	対象の帳票を1種類に絞る	様式ごとの差が、製品の優劣に見える
確信度で振り分け	しきい値と、下回った項目の集め方	全件を人が見る運用が固定化する
人が目視	見る人と、その人が休んだ週の扱い	月末に確認が滞留し、締めが遅れる
基幹システムへ	取り込み形式と、失敗データの戻し先	手作業の再入力が発生し、二重管理になる

全件確認をやめる判断も、この4段の上でしか成り立ちません。導入から1か月は全件を見て、しきい値を超えた項目に誤りが何件あったかを数えておく。2か月続けて0なら、目視を抜き取りへ切り替えられます。1件でも出たなら、しきい値を上げるか、その帳票を対象から外すかの二択でした。この2か月は業界の基準ではなく、運用上の目安として示しています。

よくあるつまずきと対処

つまずき	主な原因	対処
同じ帳票なのに日によって結果が変わる	スキャン条件が人により違う	設定を1つに固定し、手順を機械のそばに貼る
確信度が高いのに値が間違っている	文字認識ではなく項目抽出でずれている	誤りを値と欄に分けて数え、書式登録の設定を見直す
目視の担当者が月末だけ回らない	帳票が締め日に集中している	受領のたびに読み取る運用へ変え、滞留させない
学習させたのに精度が上がらない	学習が反映される範囲を誤解している	ベンダー側の改良か自社モデルかを管理画面で確認する
読み取り結果を基幹システムへ渡せない	書き出し形式が合っていない	列名と文字コードを先に取り寄せ、試験取り込みを行う
やめる判断ができない	中止の条件を決めずに始めた	目視の時間が手入力を上回ったら中止、と決めておく

つまずきの多くは、製品の性能ではなく決め事の不足から出ています。とくに最後の1行は、契約前に書き留めておかないと後から言い出しにくくなる項目でした。決める順序ややめる基準はAI-OCRの導入手順にまとめてあります。

契約前に確認する4つ

最後に、商談で聞く内容を4つに絞ります。どれも技術の知識がなくても聞けて、答えが「できる・できない」で返る形にしました。その場で答えられない場合は、後日でよいので文面で回答をもらってください。

確認すること	確かめたい理由	「できない」と答えられたときの代替
読み取り結果に確信度スコアが付くか	人が見る枚数を先に見積もるため	全件目視を前提に、対象の帳票数を絞って始める
自社の帳票を登録・学習できるか。できる場合は見本が何枚要るか	様式が固定の帳票で精度を安定させるため	汎用モデルで通る帳票だけに用途を限定する
読み取り結果をどの形式で書き出せるか	基幹システムへ渡せるかが決まるため	手作業の転記が残る前提で工数を見る
読み取れなかった項目がどう扱われるか	空欄で通るか止まるかで確認の設計が変わるため	取り込み前に空欄を弾く工程を自社側で1つ入れる

4つ目は見落とされがちです。読み取れなかった項目が空欄のまま次の工程へ流れる製品なら、取り込みの前に空欄を弾く仕組みを自社で足す必要が出てきます。

まとめ｜今週やること

今週できることを1つだけ挙げます。直近1か月に受け取った帳票から10枚を選び、体験版の画面か営業担当への1通のメールで、「読み取り結果に項目ごとの確信度スコアが出ますか。出る場合、CSVの列として書き出せますか」と確認してください。この1問への答えが、全件確認をやめられるかどうかの分かれ目になります。

よくあるご質問

AI-OCRとは、簡単に言うと何ですか

紙やPDFの画像から文字を読み取り、その文字が何の項目かまで判定して、表の形で出力する仕組みです。従来のOCRが文字を起こすところまでだったのに対し、AI-OCRは書式の違いを吸収して項目へ割り当てるところまで担います。

AI-OCRのメリットとデメリットは何ですか

利点は、手入力の時間が減ることと、確信度スコアで確認すべき箇所を絞れることの2つです。欠点として、確認の作業そのものは消えません。減らせるのは入力の時間であって確認の時間ではない、と導入前に共有しておくと期待のずれが起きにくい。

自社の帳票を学習させる方法はありますか

製品によります。クラウド事業者の開発者向けサービスでは、Microsoftが同じ書式5例からカスタムモデルの作成を開始できるとし、Googleは最低3文書から学習できると記載しています。ただしストレージや開発ツールの操作を伴うため、既製のSaaSをそのまま使う会社の話とは別です。SaaS側では「書式登録」などの名前で提供されるので、必要な見本の枚数を含めて契約前に確認してください。

OCRとAI-OCRは何が違うのですか

従来のOCRは、あらかじめ決めた位置にある文字を読む使い方が中心でした。AI-OCRは学習済みのモデルを使うため、書式が多少違っても項目を推定でき、手書き文字にもある程度対応します。とはいえ原本が薄い、罫線と重なるといった条件では結果が落ちる。違いは万能さではなく、書式の揺れをどこまで吸収するかにあります。

自社の帳票でどこまで読み取れるか、確信度スコアをどう運用へ組み込むかを整理したい場合は、お問い合わせから状況をお知らせください。帳票の種類と月間の枚数を添えていただけると、初回のやり取りが早く進みます。