AI-OCRを選ぶ基準になる3つの軸
AI-OCRを比べる作業は、認識率や対応する形式の一覧を並べるところから始まりがちです。ただ、同じサービスでも通る帳票と通らない帳票があるため、一覧だけでは自社で使えるかが決まりません。先に決めるのは、どの帳票にどの読み取り方式を当てるかです。決め手になるのは、取りたい項目がどれくらい固定されているか、発行元によって書式がどれだけ変わるか、月にどれだけの件数が届くかの3つで、製品を並べるより先にこの3つを自社の帳票で測ります。
方式は大きく2つに分かれます。様式ごとに読み取る位置を登録しておく定型のAI-OCRと、項目の意味から値を取る生成AIを使う方式です。仕組みの違いは AI-OCRと生成AIの違い で扱っているため、ここでは自分の帳票をどちらへ振り分けるかに絞ります。
3つの軸は帳票の種類とだいたい対応するため、種類ごとの傾向は当たりを付ける材料になります。ただし同じ請求書でも会社によって値が違うので、種類の名前だけで決めずに自社の実物で測ります。
3つの軸で自社の帳票を測る
軸ごとに、何を数えて、どちらの方式へ寄るかを整理します。数える対象は直近3か月に届いた実物です。
| 測る軸 | 何を数えるか | どちらへ寄るか |
|---|---|---|
| 項目の固定度 | 取りたい項目のうち、どの帳票にも必ず記載がある項目の割合 | 高いほど定型のAI-OCRで足りる。欄の有無が発行元ごとに違うなら意味で読む方式へ |
| 書式のばらつき | 発行元の数と、上位5社が全体に占める割合 | 上位に集中しているほどAI-OCR。裾野が広いほど意味で読む方式へ |
| 月あたりの件数 | 1か月の枚数と、発行元が入れ替わる頻度 | 件数が多く発行元が固定なら登録の手間が割に合う。少なく入れ替わるなら合わない |
項目の固定度は、欄の有無で数えます。 金額や日付のように必ず記載される項目は、位置さえ決まれば取れます。一方、備考欄に書かれる支払条件や、発行元によって付いたり付かなかったりする管理番号は、位置で取ろうとすると空欄と誤読の区別が付きません。取りたい項目のうち、どれが全社共通で、どれが一部の発行元にしか無いかを先に数えます。
書式のばらつきは、発行元の分布で見ます。 発行元が30社あっても、上位5社で8割を占めるなら、その5社分の様式を登録するだけで大半が自動化されます。逆に30社が均等に近い分布なら、登録の作業が終わらないうちに新しい発行元が増えます。
件数は、登録の作業が割に合うかを決めます。 月に数十枚しか届かない帳票のために様式を登録し続けるより、意味で読む方式に任せるか、手入力のまま残すほうが運用は軽くなります。件数の少なさは、自動化しない判断の根拠にもなります。
帳票の種類ごとに出やすい傾向
3つの軸は種類ごとに傾向が出ます。自社の実物を測る前の当たりを付ける材料として使えます。
| 帳票の種類 | 3つの軸に出やすい傾向 | 当てやすい方式 |
|---|---|---|
| 請求書 | 項目は共通だが書式は発行元次第。件数は多い | 上位の発行元は定型のAI-OCR、残りを意味で読む方式で補う |
| 見積書 | 項目の並びも書式もばらつく。件数は少なめ | 意味で読む方式。相見積もりの比較まで含めるなら特に |
| 納品書 | 明細の行数が毎回変わる。件数は請求書より多いことがある | 明細を行の並びとして取れる方式。ヘッダだけならAI-OCRでも足りる |
| 領収書 | 大きさも様式もばらばら。写真で届く | 意味で読む方式。券面の種類が限られるなら定型でも通る |
| 自社が様式を指定する帳票 | 項目も位置も固定。件数は運用次第 | 定型のAI-OCR。登録した定義が長く使える |
請求書は、方式を1つに決めきらない帳票です。 記載される項目は取引先が違っても大きくは変わりませんが、その置き場所は発行元ごとに違います。上位の発行元が件数の大半を占めるなら、その分は様式を登録して安定して読み、裾野の部分だけを意味で読む方式へ回す形が取れます。書式の違いを吸収して会計へ渡すまでの流れは 請求書処理の自動化 で扱っています。
見積書は、登録が間に合わない帳票です。 相見積もりを比べるには複数社から同じ項目を揃えて取る必要がありますが、取引が始まる前なので様式は登録されていません。件数も請求書ほど多くないため、1社ごとに定義を作る作業が割に合いにくくなります。明細をデータ化して比較へつなぐ設計は 見積書の取り込み を参照してください。
納品書で効くのは明細の行数です。 発注1件に対する納品が分かれると、行数も並びも毎回変わります。ヘッダの日付や番号だけを取るなら位置で読めますが、明細を検収や請求と突き合わせるところまで自動化するなら、行の並びとして取れる方式が要ります。
領収書は、券面そのものがばらつきます。 交通機関の券面のように種類が限られていれば定型で通りますが、飲食や物販が混ざると様式は数え切れません。写真で届くため、傾きや影の影響も受けます。経費精算の中での扱いは 経費精算のチェック で扱っています。
種類が同じでも判定が変わる場合
種類だけで決めきれない要因が4つあります。判定を始める前に、これらを帳票の束から分けておきます。
| 分けておく条件 | 判定への影響 | 先に決めておくこと |
|---|---|---|
| 届き方が紙とPDFとメール本文で混在する | メール本文には様式が無く、位置で読めない | 経路ごとに束を分け、本文のものは別扱いにする |
| 同じ発行元が様式を変える | 登録済みの位置がずれ、抽出値が静かに外れる | 様式変更に気づく仕組みを検証側に置く |
| 手書きの追記がある | 印字部分は読めても、追記は定義の外に出る | 追記を自動化の対象に含めるかを決める |
| 外貨や税率の異なる明細が混じる | 金額の検算が通らず、確認に回る件数が増える | 対象から外すか、確認へ回す条件として書く |
このうち2つ目は、方式を選んだあとも残ります。位置で読む方式は、様式が変わっても処理そのものは動き続け、値だけが別の場所から取られます。読み取りに失敗したわけではないため、検算やマスタとの突合で気づく形にしておかないと、誤った値がそのまま登録されます。
精度が出ないときに疑う順番
方式を選んだあとに「思ったほど読めない」となったとき、先にサービスの乗り換えを考えると原因が残ったまま移るだけになります。抽出が合わない場面は、崩れ方によって手当てが違います。数字を測る手順は AI-OCRの読み取り精度をどう検証するか で扱っているため、ここでは何を疑う順に見るかを整理します。
| 出ている症状 | 先に疑うところ | 確かめ方 |
|---|---|---|
| 特定の発行元だけ値が入らない | 様式の登録漏れ、または発行元側の様式変更 | その発行元の直近の帳票と、登録した時期の帳票を並べて位置を見る |
| 全体的に文字が欠ける・化ける | 元画像の解像度と傾き、複合機の設定 | 同じ帳票をPDFで受け取った分と読み比べる |
| 金額は合うのに明細だけ崩れる | 行の区切りの取り方。表の罫線が無い様式で起きやすい | 明細の行数が多い帳票と少ない帳票で誤りの出方を比べる |
| 日付や番号が別の欄の値になる | 位置で読む方式で、近接する欄を拾っている | 抽出値の座標と、帳票上の欄の位置を突き合わせる |
| 値は取れるが検算が合わない | 読み取りではなく税率や端数の扱い | 手入力した値で同じ検算を通し、条件側の誤りかを切り分ける |
発行元ごとに出方が違うなら、方式ではなく登録の問題です。 全体の一致率だけを見ていると、1社の様式変更で数十件が落ちている状態と、全社で少しずつ落ちている状態が同じ数字に見えます。誤りは発行元ごとに数え分けます。
画像の質は、方式を変えても改善しません。 傾きや影、解像度の不足は位置で読む方式でも意味で読む方式でも同じように効きます。読み取りの前段で直せる部分を先に潰してから、方式の比較に戻ります。
検算が合わない件は、読み取りの誤りと混ぜて数えません。 抽出は正しく、突合の条件のほうが自社の運用に合っていない場合があります。両者を同じ「エラー」として扱うと、精度の数字が実態より低く出て、サービスの入れ替えという誤った結論に向かいます。
既製サービスのまま使ってよい範囲
方式が決まったら、次はどこまでを契約したサービスに任せるかです。工程ごとに、既製のもので足りるか、内製へ切り替える合図は何かを分けます。
| 工程 | 既製サービスで足りるか | 内製へ切り替える合図 |
|---|---|---|
| 帳票の受け取り | 足りる。メールや専用の受付窓口が用意されている | 部署ごとに受け取り経路が分かれ、集約できていない |
| 文字認識 | 足りる。自前で用意する理由は乏しい | （切り替える理由はほとんど無い） |
| 項目の抽出 | 足りる。定義や指示の中身は自社で書く | 定義の登録を提供元へ依頼する形になっている |
| 突合と検算 | 自社の会計処理に依存するため合わないことが多い | 検算の条件を自分で足せない |
| 人の確認画面 | 単独で使うなら足りる | 読み取り方式を2つ以上使い、画面が分かれている |
| 会計システムへの連携 | 対応済みの組み合わせなら足りる | 出力形式が固定で、自社の仕訳の付け方に合わない |
| 保存と証跡 | 保存要件に対応した製品なら足りる | 修正履歴を外部から取り出せない |
上の3行は、そのまま既製のサービスに任せて問題が起きにくい部分です。文字を読む処理は自社の帳票の中身に左右されないため、ここを自前で持っても判断材料は増えません。
分かれ目は4行目からです。突合の条件と会計への渡し方は、自社の勘定科目の付け方や取引先の管理の仕方でしか決まりません。ここが既製のまま固定されると、業務側の運用をサービスの仕様へ合わせることになります。買うか作るかの一般的な判断基準は AIエージェントは自作か既製ツールか で整理しています。
突合と会計連携を自社に置く
内製で持つ範囲を広く取りすぎると規模が膨らみます。優先して自社に置くのは次の3つです。
突合の条件。 明細の合計と請求額が合うか、税率ごとの対象額から計算した税額が記載と一致するか、発注時の金額と差がないか、振込先が登録済みの口座かを確かめます。どの不一致で処理を止め、どれを通すかは自社の運用でしか決められません。条件を1つ足すたびに提供元へ依頼が要る作りだと、締めに間に合わなくなります。
会計システムへ渡す形式。 取り込むファイルの項目の並び、勘定科目や税区分の付け方、支払データの作り方です。ここを自社で決めておくと、読み取りの方式やサービスを入れ替えても、会計側は作り直さずに済みます。仕訳と支払データの作り方は 請求書の仕訳を自動化する で扱っています。
確認と差し戻しの経路。 突合が合わなかったものが誰の画面へ行き、社内で直すのか発行元へ再発行を依頼するのかを分けます。読み取りの方式を2つ使う場合も、この画面は1つに寄せます。方式ごとに画面が分かれると、経理の担当者が両方を見て回ることになります。
内製へ切り替える時期の決め方
最初から内製で組む必要はありません。既製のサービスで始めて、数えた結果が次のようになったときに切り替えを検討します。
- 様式の登録や修正を提供元へ依頼した件数が、月ごとに増えている
- 未登録を理由に手入力へ回った帳票の割合が、数か月にわたって下がらない
- 突合の条件を足したいという要望が、サービスの機能で吸収できずに溜まっている
- 会計へ渡す前に、出力を人が加工し直す手順が定着している
- 抽出値の誤りを、登録後に気づいた回数が減らない
これらは1回の締めでは判断できないため、記録を残しながら数えます。切り替えを決めたあとも、文字認識と実行の基盤は既製のものを使ったままで構いません。自社に移すのは突合と会計連携、そして確認の画面です。開発の進め方と見積の考え方は AIエージェント開発の進め方 を参照してください。
まとめ：帳票ごとに方式を決め、突合から先を自社に置く
- 製品の一覧から比べ始めず、自社の帳票を項目の固定度と書式のばらつき、件数の3点で測ってから方式を決める
- 項目の固定度は欄の有無で、書式のばらつきは上位の発行元が占める割合で、件数は登録の作業が割に合うかで数える
- 請求書は上位の発行元を定型のAI-OCRで読み、裾野を意味で読む方式で補う形が取りやすい
- 見積書は取引開始前で様式が登録できないため、意味で読む方式に寄る。納品書は明細の行数、領収書は券面のばらつきが判定を分ける
- 届き方の混在、発行元の様式変更、手書きの追記、税率の違う明細は、束を分けてから判定する
- 読めない件が出たら、発行元ごとの出方と画像の質、検算の条件を分けて数えてから方式を疑う
- 受け取りと文字認識、項目の抽出は既製のサービスで足りる。突合の条件と会計へ渡す形式、確認の画面を自社に置く
- 切り替えの判断は、依頼した登録の件数や手入力へ回った割合を記録してから決める
Augueでは、帳票の種類ごとの読み取り方式の切り分けから、突合の条件と会計システムへの連携までを含めた設計と開発、および運用を社内で持ち続けるための引き継ぎに対応しています。自社の帳票にどの方式が合うか、どこから内製へ切り替えるかを整理したい方は、是非ご相談ください。
関連する記事
位置で読む方式と意味で読む方式の仕組みの違いは AI-OCRと生成AIの違い、書式の違う請求書を会計へ渡すまでの設計は 請求書処理の自動化、選んだあとに読み取りの精度を測る手順は AI-OCRの読み取り精度をどう検証するか、複数社の見積を比較できる形に揃える流れは 見積書の取り込み を参照してください。
よくある質問
AI-OCRのサービスを比べるとき、資料のどこを見ればよいですか？
認識率の数字より先に、料金の数え方と定義の作り方を見ます。1枚あたりで数えるのか項目数で数えるのか、明細の行が増えたときに何枚分として請求されるのかで、同じ件数でも金額が変わります。定義については、様式の登録を自社の担当者が画面から作れるのか、提供元への依頼が要るのかを確かめます。依頼が要る作りだと、発行元が増えるたびに待ち時間が入ります。
帳票の種類ごとに違うサービスを使い分けても構いませんか？
読み取りの部分だけなら分けても構いませんが、そのあとの確認画面と会計への渡し方は1つに寄せます。種類ごとに画面が分かれると、経理の担当者が複数の画面を見て回ることになり、締めのたびに確認の手間が増えます。使い分ける場合は、抽出した結果を同じ形式で受け取れるか、外部から取り出す口が用意されているかを契約前に確かめておきます。
導入してから運用に乗るまで、どれくらいの期間を見ればよいですか？
帳票の種類数と発行元の数で変わるため、一律の期間は出せません。目安を作るなら、締め1回分の帳票を実際に通し、様式の登録に何日かかったか、直しが何件出たかを記録します。その1回分から、残りの発行元に必要な作業量を見積もれます。期間を先に決めてから帳票を流すと、登録が終わっていない発行元の分だけ手入力が残った状態で運用が始まります。
手書きの帳票が混じる場合は、どう扱えばよいですか？
手書きは方式の選択より前に、対象から外すかどうかを決めます。印字と手書きが同じ帳票に混在する場合、印字部分だけを自動で取り、手書きの追記は人が入力する形にすると運用が止まりにくくなります。全体が手書きの帳票は、件数が少なければ手入力のまま残す判断もあります。自動化の対象を広げるほど、確認に回る件数が増える点を先に見ます。
電子帳簿保存法への対応は、読み取りの方式によって変わりますか？
保存の要件は読み取りの方式では変わりません。求められるのは、検索できる状態で原本を保存することと、いつ誰が修正したかを残すことです。AI-OCRでも生成AIでも、抽出した値を保存要件の項目へ割り当てられるかを見ます。読み取りのサービスが保存まで含むのか、保存は別のシステムで持つのかは契約の範囲で変わるため、選定の段階で確認します。