帳票の読み取りで、何を手がかりにするか
請求書や見積書の読み取りを自動化するとき、方式は大きく2つに分かれます。AI-OCRで組む場合と、生成AIを含むエージェントで組む場合です。どちらも文字を読む点では同じに見えますが、項目を取る手がかりが違います。
比べる軸は3つに絞れます。読み取り精度、発行側が書式を変えたときに持ちこたえるか、そして費用です。このうち読み取り精度は方式だけでは決まらず、対象の帳票によって向きが入れ替わります。先に手がかりの違いを押さえたうえで、帳票の種類ごとの目安を見ていきます。
AI-OCRは、帳票のどこに何が書かれているかを事前に定義し、その位置から値を取ります。「請求金額はこの矩形の中」という定義を、発行元ごと、様式ごとに登録します。文字認識の性能が読み取りの質を決め、同じ様式が続く限り出力は安定します。
生成AIは、位置ではなく項目の意味で取ります。「ご請求金額」「合計金額」「お支払金額」が同じものを指すと扱えるため、登録していない様式からも抽出できます。代わりに、同じ入力に対して同じ出力が返るとは限りません。
| 比べる観点 | AI-OCR（位置で読む） | 生成AIを含むエージェント（意味で読む） |
|---|---|---|
| 事前に必要な作業 | 発行元・様式ごとの読み取り定義 | 抽出したい項目の定義を1度だけ |
| 登録していない様式 | 定義が無いため取れない | 定義なしで抽出できる |
| 出力の再現性 | 同じ様式なら安定する | 同じ入力でも揺れることがある |
| 明細のような可変長の表 | 行数が変わると崩れやすい | 行の並びとして取れる |
| 手書きの追記や欄外の注記 | 定義した範囲の外は拾えない | 前後の文脈として扱える |
| 誤りの出方 | 位置ずれで、同じ項目がまとめて外れる | 書かれていない値をもっともらしく埋める |
| 1件あたりの費用 | 概ね一定で見積もりやすい | 入力量に応じて変動する |
最後の2行が、後段の設計を分けます。AI-OCRの誤りは位置ずれとして現れるため、同じ発行元の同じ項目がまとめて外れます。1件気づけば原因を特定でき、同じ様式の他の帳票も疑えます。生成AIの誤りは1件ずつ独立して出るため、まとめて見つけることができません。どちらも検証は必要ですが、確かめ方が変わります。
帳票の種類ごとに、どちらで組むか
手元の帳票がどちらに寄るかは、書式を誰が決めるかと、その書式がどれくらい動くかでおおよそ決まります。次の表が初期の当たりを付ける目安になります。
| 帳票 | 書式の決まり方 | どちらで組むか |
|---|---|---|
| 自社が指定する申込書・検収書 | 自社が様式を決めるため動かない | AI-OCR。作った定義が長く使える |
| 毎月同じ発行元から届く利用明細 | 発行側が固定していて変わりにくい | AI-OCR。件数が多いほど定義を作る作業が回収できる |
| 請求書 | 発行元ごとに違い、取引先が増えるほど広がる | 件数の多い発行元はOCR、裾野は生成AI |
| 見積書 | 発行元ごとに違い、初回は必ず未登録になる | 生成AI。相見積で同じ項目を揃えて取る必要がある |
| 納品書・受領書 | 発行元ごとに違い、明細の行数も毎回変わる | 生成AI。可変長の表として取る |
| 領収書・経費精算の証憑 | 様式が定まらず、手書きや折れが混ざる | 生成AI。ただし検証と人の確認を厚くする |
右の列は初期の当たりであって、最終的な判断は自社の帳票で測って決めます。分け目になるのは、様式の数と1様式あたりの件数の比です。同じ様式が月に何十枚も届くなら読み取り定義を作る作業が回収できますが、1様式あたり数枚なら登録の手間が読み取りの手間を上回ります。帳票の種類ごとに、項目の固定度と書式のばらつき、件数の3点で測り分ける手順は AI-OCRの比較と選び方 で扱っています。
定型の帳票でAI-OCRが安定して強い条件
AI-OCRが向くのは、次の条件が揃う帳票です。
様式を自社側が決められる。 提出させる申込書や検収書のように、こちらが指定した用紙に記入してもらう帳票は、読み取り定義が長く使えます。定義を1度作れば、あとは記入内容だけが変わります。
同じ発行元から同じ様式で継続して届く。 毎月同じサービスから届く利用明細のように、発行側の様式が固定されている帳票です。件数が多いほど、定義を作る作業が割に合います。
項目の位置と数が変わらない。 明細の行数が固定されている、または上限が決まっている帳票です。
印字されていて、判読できる。 手書きの追記や押印の重なりが少ない帳票です。
この条件が揃う帳票では、生成AIを使う理由が薄くなります。出力が毎回同じであること自体が価値になり、1件あたりの費用も読めます。件数が多く様式が動かない帳票を、わざわざ意味で読む方式に載せ替える必要はありません。
テンプレート運用が破綻する境目
問題になるのは、様式を発行元が決める帳票です。読み取り定義を登録する運用がいつ回らなくなるかは、次を見ると判断できます。
| 見るところ | 何を数えるか | 回らなくなっている状態 |
|---|---|---|
| 登録済みの様式 | 定義の総数と、月あたりの新規登録件数 | 新規登録が毎月途切れず、担当が特定の人に固定している |
| 手入力に回る帳票 | 全体に占める割合と、その理由の内訳 | 未登録を理由とする手入力が減らないまま続いている |
| 定義の修正 | 様式変更で直した回数と、気づいた経緯 | 抽出値がおかしくなってから発覚している |
| 新規取引の1枚目 | 初回の帳票がどの経路を通るか | 例外なく手入力になっている |
このうち最後の行が、方式の限界をいちばん端的に示します。読み取り定義は過去に見た様式にしか作れないため、初回の帳票は必ず未登録です。取引の開始時は金額や条件の確認が最も必要な場面ですが、そこだけが自動化の対象外になります。
見積書の取込では、この性質がより強く出ます。相見積もりを比べるには複数社の書式から同じ項目を揃えて取る必要があり、しかも取引が始まる前なので、その会社の様式は登録されていません。請求書より件数が少ない分、定義を作る作業が割に合いにくいという事情も重なります。書式が発行元ごとに変わる帳票の取込設計は 請求書処理の自動化をAIで進める でも扱っています。見積書に絞って、明細の対応付けから相見積の比較までを組む場合は 見積書の取り込みをAIで自動化する を参照してください。
抽出値の確からしさを、どう確かめるか
方式を決める前に置くべき工程があります。抽出した値が正しいかを機械で確かめる検証です。ここが無いまま人の目視確認へ回す構成にすると、読み取りを自動化しても確認の負担が残ります。
| 確かめること | 突き合わせる相手 | 合わなかったときの扱い |
|---|---|---|
| 明細の合計と請求合計の一致 | 同じ帳票内の値 | 抽出の誤りを疑い、該当項目を人の確認へ |
| 税率ごとの対象額から再計算した税額 | 帳票に記載の税額 | 税区分の判断が要るため人の確認へ |
| 帳票番号と発行元の組み合わせ | 過去に登録済みのデータ | 重複として止める |
| 発行元の名称 | 取引先マスタ | 候補を示して人が選ぶ |
| 振込先の口座 | マスタに登録された口座 | 金額にかかわらず人の承認へ |
| 必須項目が空でないか | 抽出項目の定義 | 未取得として差し戻しの経路へ |
この検証は、AI-OCRで読んでも生成AIで読んでも同じものを使えます。方式ごとに別の検証を組むと、後から方式を足したときに二重に持つことになります。
生成AIを使う場合に注意するのは、確からしさの測り方です。モデルに自己申告させた確信度をそのまま閾値に使うと、根拠のない値に高い数字が付くことがあります。代わりに機械で確かめられる条件へ置き換えます。抽出値が帳票のどこから取られたかを座標や切り出し画像として返せるか、同じ帳票を2度通したときに同じ値になるか、といった条件です。出どころを保持しておくと、人の確認が読み直しではなく照合で済みます。
人が持つ判断は、金額と振込先と税区分に絞ります。検算が合わない場合、発注時の金額と差がある場合、上限額を超える場合は人が承認します。マスタに登録がない口座や登録と違う口座は、金額の大小にかかわらず人へ回します。この線引きは読み取り方式が変わっても動きません。
読み取り精度だけで比べたときに抜ける費用
方式の比較が読み取り精度の話に寄ると、判断を誤ります。帳票処理でかかる作業は読み取りだけではないためです。少なくとも次の4つを同じ範囲に入れて並べます。
読み取り定義の維持。 OCRで組む場合、発行元が増えるたび、様式が変わるたびに作業が発生します。これは初期構築の費用ではなく、運用が続く限り続く費用です。生成AIで組む場合は様式ごとの登録が不要になる代わり、入力量に応じた処理費用が毎件かかります。
会計や基幹への連携。 抽出した値をどの形式で渡すかは、読み取り方式とは独立して決まります。インポートするファイルの仕様か、接続の口か。ここは方式を変えても作り直す必要がない部分なので、先に固めておくと方式の変更が局所で済みます。
差し戻しと再処理。 読み取れなかったもの、項目が欠けているもの、金額が合わないものの行き先です。社内で直せるものと、発行元へ再発行を依頼しないと進まないものを分け、それぞれ状態と期限を持たせます。ここを設計に含めないと、締めの直前に止まったままの帳票が出てきます。
監査に残す証跡。 原本、抽出値、検証の結果、誰がいつどの値を直したか、承認者を残します。生成AIを使う場合は、どの版のモデルにどの指示で渡したかも記録します。モデルや指示を更新したあとで過去の処理を説明できなくなるためです。開発全体の進め方と見積の考え方は AIエージェント開発の進め方 を参照してください。
既存のAI-OCRを残したまま、生成AIを足す
すでにAI-OCRを導入している場合、方式を入れ替える必要はありません。足し方は3通りあります。
振り分ける。 登録済みの様式はOCRで処理し、未登録のものだけ生成AIへ回します。件数の多い発行元がOCR側に残るため、処理費用の増え方を抑えられます。
取り切れなかった項目を補う。 OCRの出力のうち空だった項目や検証で外れた項目だけを、生成AIに渡して埋めます。読み取り全体を置き換えないため、既存の定義がそのまま生きます。
点検に使う。 OCRの出力を生成AIに見せ、帳票の内容と食い違う箇所に印を付けさせます。値を決めるのは検証工程のままで、人が見る順番を並べ替える用途です。
どの足し方でも、検証工程と人の確認画面は1つに合流させます。方式ごとに確認画面が分かれると、確認する人が2つの画面を行き来することになり、自動化したはずの運用が重くなります。
どちらで組むかを決める順番
先に方式を選ぶのではなく、自社の帳票を分けるところから始めます。
様式を誰が決めるかで帳票を分ける。 自社が指定する様式と、発行元が決める様式に分けます。前者はOCRの適用対象として残せます。
発行元が決める帳票の偏りを数える。 上位の発行元が全体のどれくらいを占めるかを数えます。少数の発行元に集中しているなら、その分はOCRで定義を作る形が続きます。裾野が広いなら、意味で読む方式を足す判断につながります。
既存の定義の維持にかかっている作業を数える。 月あたりの新規登録と修正の件数です。ここが積み上がっているかどうかが、方式を足すかの主な材料になります。
締め1回分を通して記録を取る。 抽出と検証だけを自動化し、承認は人に残したまま流します。直しがどの項目に集中するかを記録し、自動で通してよい条件をその記録から決めます。着手前に達成すべき自動化の割合を決め打ちしないほうが、判断を間違えにくくなります。
読み取り単価だけでなく、確認に残っている作業や差し戻しの発生量まで含めて比べる考え方は AI導入の効果測定と投資判断 を参照してください。方式の選定と検証の作り込みを社内で回せるようにする進め方は AI内製化の進め方 で扱っています。
内製で組む場合、どこまでを自分で作るか
読み取りを内製すると言うとき、作る対象は1つではありません。帳票を受け取ってから会計へ渡すまでを層に分け、層ごとに買うか作るかを決めます。全部を作る前提で見積もると規模が大きくなりすぎ、全部を買う前提だと自社の処理に合わない条件のまま運用が固定されます。
| 層 | 外部の製品で足りるか | 自分で作るかの目安 |
|---|---|---|
| 帳票の受け取り | 足りることが多い | 受け取り経路が部署ごとに分かれている場合だけ作る |
| 文字認識 | 足りる | 帳票処理では自前で用意する理由が乏しい |
| 項目の抽出 | OCRの定義機能、またはモデルへの指示文で足りる | 定義と指示文の中身は自社で持つ |
| 検証（検算・マスタ突合） | 自社の会計処理に依存するため既製では合わない | 作る |
| 人の確認画面 | 製品付属のもので足りる場合がある | 方式を2つ以上使うなら1つに寄せて作る |
| 会計・基幹への連携 | 連携の口があれば既製の部品でつなげる | 受け渡しの形式は自社で決める |
文字認識そのものは外に置く。 帳票の文字を読む部分は自社の帳票の中身に依存しないため、自前で用意しても判断材料は増えません。内製の話がこの層から始まると、規模の割に業務の側が変わらない構成になります。
検証と確認画面を自社側に置く。 検算の式、突き合わせるマスタ、人へ回す線引きは、自社の会計処理と取引先の管理の仕方でしか決まりません。加えてこの2つは読み取り方式によらず共通で使うため、ここを自社に置いておくと、OCRに生成AIを足す入れ替えをしても確認の運用を作り直さずに済みます。
作る範囲を決める前に、締め1回分を通す。 直しがどの項目に集中するかを記録してから範囲を決めます。記録が無いまま構成を決めると、実際には手入力が残っている工程ではなく、作りやすい工程に作り込みが寄ります。
内製で持ち続けるとき、社内に残る作業
作る範囲を決めたあとは、動かし続けるあいだ社内に残る作業と、外部へ任せたままでよい部分を分けておきます。ここが曖昧なままだと、動き始めてから直せる人がいない状態になります。
| 社内に残るもの | 持ち続ける内容 | 外へ出したときに起きること |
|---|---|---|
| 読み取り定義 | 発行元・様式ごとの登録と、様式が変わったときの修正 | 発行元が増えるたびに依頼と待ち時間が発生する |
| 検証条件 | 検算の式、突き合わせるマスタ、人の確認へ回す線引き | 自社の処理と合わない条件のまま運用が固定される |
| 差し戻しの扱い | 社内で直すものと、発行元へ再発行を依頼するものの分け方 | 締めの直前に止まった帳票の行き先が決まらない |
| 文字認識・実行基盤 | 選定と契約の判断まで | 任せたままでよい |
読み取り定義の登録と修正を、誰が持ち続けるか。 OCRで組むなら様式ごとの定義、生成AIで組むなら抽出したい項目の定義と指示文が、これに当たります。どちらも一度作って終わりではなく、発行元が増えたとき、発行側が様式を変えたときに直します。持つ人を決めるときに見るのは、様式が変わったことに気づく場所と、定義を直す場所が同じかどうかです。帳票を日々受け取っている側が定義を持てば、抽出値がおかしくなる前に直せます。外部へ出すと、気づいてから直るまでに依頼が挟まります。
検証条件の設計を社内に残す理由。 検算やマスタ突合の条件は、自社の会計処理や取引先の管理の仕方に依存します。どの不一致で止めてどれを通すか、どの帳票を金額にかかわらず人の確認へ回すかは、業務側でしか決められません。加えて、検証は読み取り方式によらず共通で使う部分です。ここを社内に持っておくと、OCRに生成AIを足す、逆に一部をOCRへ戻すといった入れ替えをしても、確認の運用を作り直さずに済みます。外部へ出すと、条件を1つ変えるたびに依頼と反映待ちが発生します。
外部へ任せたままでよい部分の線引き。 文字認識そのもの、使うモデル、実行の基盤とその更新への追随は、外に置いたままで構いません。自社の帳票の中身に依存しない部分なので、社内に担当を置いても判断材料が増えないためです。線を引くときに確かめるのは、その部分を入れ替えたときに読み取り定義と検証条件をそのまま使えるかどうかです。使えない作りになっていると、基盤を替える判断が読み取りの作り直しと一体になり、動かせなくなります。
担当が変わったときに引き継ぐもの。 引き継ぐのは3つです。読み取り定義そのもの、検証条件、そして直しの履歴です。履歴には、どの発行元のどの様式で何が外れ、どう直したかを残します。定義と検証条件だけを渡すと、なぜその条件にしたのかが分からないまま引き継ぐことになり、後任が触れなくなります。逆に履歴が残っていれば、同じ様式で同じ誤りを繰り返す状態を避けられます。引き継ぎのために別の資料を作るのではなく、日々の修正がそのまま履歴として残る形にしておくと、更新が止まりません。
まとめ：帳票の読み取りをどちらで組むか
- AI-OCRは位置で、生成AIは意味で項目を取る。精度の高低ではなく、安定して動く条件が違う
- 帳票の種類で当たりを付けられる。自社が様式を決める申込書や毎月同じ形で届く利用明細はOCR、見積書や納品書、経費精算の証憑は意味で取る方式が向く
- 様式が自社で決まる帳票や、同じ発行元から同じ形で届く帳票では、出力が毎回同じであることが利点になりOCRが向く
- 読み取り定義は過去に見た様式にしか作れないため、新規取引の1枚目は必ず未登録になる。ここが自動化の対象外として固定していないかを見る
- 抽出値の検証は方式によらず共通で組む。モデルの自己申告する確信度ではなく、検算やマスタとの突合で確かめる
- 読み取り精度だけで比べず、定義の維持、会計連携、差し戻しの再処理、監査に残す証跡まで同じ範囲に入れて並べる
- 既存のOCRは残したまま、未登録の様式だけを生成AIへ回す形が取れる。検証工程と人の確認画面は1つに合流させる
- 内製する範囲は層ごとに決める。文字認識と実行の基盤は外部の製品に任せ、読み取り定義と検証条件を自社側に置く
Augueでは、請求書の取込や見積書のOCR取込のように、既存の読み取り資産を残したまま生成AIを組み合わせる構成の設計と開発、および社内で運用を持ち続けるための引き継ぎに対応しています。自社の帳票をどちらの方式で組むか、どこまでを内製で持つかを整理したい方は、是非ご相談ください。
関連する記事
帳票の種類ごとの向き不向きと既製サービスを使う範囲は AI-OCRの比較と選び方、書式の違う請求書を取り込んで会計へ渡すまでの設計は 請求書処理の自動化をAIで進める、見積書の明細をデータ化して比較につなげる設計は 見積書の取り込みをAIで自動化する、検証から本番運用までの進め方と見積の考え方は AIエージェント開発の進め方、社内で改善を回す体制づくりは AI内製化の進め方 を参照してください。
よくある質問
AI-OCRと生成AIによる読み取りは、何が違いますか？
項目を取る手がかりが違います。AI-OCRは帳票のどこに何が書かれているかを様式ごとに登録し、その位置から値を取ります。生成AIは位置ではなく項目の意味で取るため、登録していない様式からも抽出できます。前者は同じ様式が続く限り出力が安定し、後者は同じ入力でも出力が揺れることがあります。精度の高低ではなく、安定して動く条件が違うと捉えるのが実務的です。
AI-OCRの限界はどこにありますか？
読み取り定義を人が登録し続ける前提にあります。発行元が増えれば登録作業が増え、発行側が様式を変えれば登録済みの位置がずれます。新規取引先の1枚目は必ず未登録のため自動化できません。明細のように行数が毎回変わる表とも相性がよくありません。文字認識そのものの性能ではなく、定義の維持が続くかどうかが限界を決めます。
既に導入したAI-OCRは、生成AIを使うなら捨てることになりますか？
捨てずに残す構成が取れます。登録済みの様式はOCRで処理し、未登録のものだけ生成AIへ回す振り分け方、OCRが取り切れなかった項目だけを生成AIに渡す補完の仕方、OCRの出力を生成AIで点検させる使い方があります。いずれの場合も、検算やマスタ突合といった検証工程と人の確認画面は1つに合流させます。方式ごとに確認画面が分かれると運用が二重になります。
読み取りの精度はどちらが高いですか？
一律の比較はできません。様式が固定された印字の帳票ではOCRが安定し、発行元ごとに書式が変わる帳票では意味で取るほうが通ります。判断材料になるのは、自社の帳票を締め1回分そのまま通し、項目ごとに直しの発生率を測った結果です。加えて、誤りが機械で検出できる範囲がどこまで広いかを併せて見ます。
生成AIで抽出した値が正しいかは、どう確かめますか？
モデルが自己申告する確信度を閾値に使わず、機械で確かめられる条件に置き換えます。明細合計と請求合計の一致、税率ごとの対象額から再計算した税額との突合、取引先マスタや過去データとの照合が中心です。加えて、抽出値が帳票のどこから取られたかを保持しておくと、人の確認が読み直しではなく照合で済みます。
費用はどちらが安く済みますか？
読み取り単価だけでは決まりません。OCRは1件あたりの費用が読みやすい一方、読み取り定義を登録し直す作業が継続して発生します。生成AIは入力量に応じて費用が変動する代わり、様式ごとの登録が要りません。比較するなら、読み取りに加えて定義の維持、会計への連携、差し戻しの再処理、監査に残す証跡までを同じ範囲に入れて並べます。
帳票の読み取りを内製で組むなら、どこから着手しますか？
文字認識をどう作るかではなく、締め1回分の帳票を流して直しがどこに出るかを記録するところからです。その記録が無いまま製品や基盤を選ぶと、選定の基準が読み取り単価だけになります。記録を取ったうえで、自社の会計処理に合わせて決めるほかない部分から先に手を付けます。文字認識と実行の基盤は外部の製品を使う前提で構いません。
内製で持つには、社内にどんな担当が要りますか？
モデルや文字認識の中身を扱える人より先に、帳票を日々受け取っている担当が定義と条件を自分で直せる状態にすることが要ります。加えて、会計システム側の受け渡し仕様を判断できる人が要ります。必要な人数を一律には出せないため、月あたりの新規様式の登録件数と修正件数を数えて、その作業量から見積もります。