AI-OCRの導入で判断を誤る原因の多くは、確認作業がゼロになる前提で計画することです。 読み取りの精度は書類の状態で上下し、どれだけ高くても誤りは残ります。現実的な目標は「全件を目視で入力・照合していた状態をやめ、機械的なチェックで弾かれたものだけを人が確認する状態にすること」です。
この記事では、AI-OCRを導入するかどうか、既製サービスで足りるか開発が要るかを、精度・確認工数・費用・保存要件の4点から整理します。想定する読み手は、会計事務所や経理部門で紙やPDFの帳票を毎月処理していて、稟議や見積り比較の前に判断の軸を持ちたい方です。会計事務所の記帳部門で、顧客から届く領収書・請求書を読み取る例を通して具体化します。
AI-OCRは何を自動化し、何を自動化しないか
AI-OCRは、紙やPDFの画像から文字を読み取り、日付・金額・取引先などの項目に分けてデータ化する仕組みです。従来のOCRは「どの位置に何が書いてあるか」を事前に設定した定型帳票が主な対象でしたが、AI-OCRは学習によって位置のばらつきや手書きにも対応範囲を広げました。
ただし、読み取った結果が正しいかどうかを判断するのは、AI-OCRの仕事ではありません。読み取った値を会計ソフトへ流す前に、誤りに気づく仕組みを別に用意する必要があります。 ここを設計しないまま導入すると、「入力の手間は減ったが、確認の手間は変わらない」という状態になります。導入の可否を判断する前に、この記事で扱う「分類・テスト・検知・保存」の4つを順に確認してください。
まず自社に届く書類を分類する
| 分類 | 例 | 読み取りの難易度 |
|---|---|---|
| 定型・印字 | 自社フォーマットの申込書、自社発行の請求書控え | 低い |
| 非定型・印字 | 取引先ごとに書式が異なる請求書・領収書 | 中程度 |
| 手書き | 手書きの領収書、現場の作業日報 | 高い |
| 複写・かすれ・感熱紙 | 複写式の伝票、退色したレシート | 高い |
上2つが対象の大半なら、導入の効果が出やすい状況です。 下2つが中心の場合は、精度と確認工数を実データで確かめてから判断してください。会計事務所に届く領収書は、飲食店や小売店の感熱紙レシートが多く、印字が薄いものや折れたものが混ざります。分類の段階で「どの種類が何割か」を数えておくと、後のテスト結果を解釈しやすくなります。
導入前にやること:実物の書類でテストする
自社に実際に届いている書類20〜30枚でテストしてください。 カタログに記載された精度は、条件のよい書類で測った数値であることが多く、そのまま自社の数値にはなりません。多くのサービスに試用の仕組みがあります。
テストで確認するのは次の3点です。
- どの項目が読み取れて、どの項目が外れるか(日付は読めるが取引先名が外れる、など)
- 外れ方に傾向があるか(特定の取引先の書式だけ弱い、感熱紙だけ弱い、など)
- 1枚あたりの確認にかかる時間
3番目が投資判断の材料になります。 目視で入力していたときに1枚3分かかっていた作業が、読み取り結果の確認だけで30秒になるなら効果は明確です。逆に、読み取り結果を疑って原本と全項目を突き合わせる運用になれば、時間は元に戻ります。テストの段階で「確認とは何を見ることか」を決めておくことが、測った数値を信頼できるものにします。
間違いに気づく設計
精度を上げるより、間違いを検知できる仕組みを組むほうが実務的です。 検知の方法は帳票の種類によらず、次の4つに整理できます。
| 検知の方法 | 内容 | 領収書・請求書での例 |
|---|---|---|
| 合計の突合 | 明細の合計と記載された合計金額が一致するか | 税抜額+消費税額=税込額になっているか |
| 必須項目のチェック | 空欄・記号のみの項目を弾く | 日付・金額・発行者名のいずれかが空欄 |
| 範囲のチェック | 金額・日付が想定範囲内か | 日付が対象月の範囲外、金額が桁違い |
| 過去との照合 | 同じ取引先の過去データと大きくずれていないか | 毎月ほぼ同額の家賃・リース料が前月と違う |
これらで弾かれたものだけを人が確認する設計にすると、全件確認から解放されます。 弾かれる割合は書類の状態次第ですが、テストの段階で「何枚中何枚が弾かれたか」を数えておけば、導入後の確認工数がそのまま見積もれます。
保存要件との関係:読み取りと保存を一体で設計する
会計事務所や経理部門でAI-OCRを使う場合、読み取った後の紙やデータをどう保存するかが、税務上の要件と結びつきます。国税庁は電子帳簿保存法の一問一答を、電子帳簿・電子書類関係、スキャナ保存関係、電子取引関係の3つに分けて公表しています。紙で受け取った領収書・請求書をスキャンして、そのデータの保存をもって紙の保存に代えるのがスキャナ保存です。
一問一答【スキャナ保存関係】(令和8年7月版)では、読み取りの要件として解像度200dpi以上(25.4ミリメートル当たり200ドット以上)、赤・緑・青それぞれ256階調以上であることが示され、タイムスタンプの付与(入力期間内に訂正削除の履歴が残るシステムへ格納する等の代替要件あり)、取引年月日その他の日付・取引金額・取引先を検索の条件として設定できることが整理されています。入力期間については、「速やかに」入力する場合はおおむね7営業日以内、業務の処理に係る通常の期間を経過した後に入力する場合は、最長2か月の業務サイクルであれば通常の期間として取り扱われる、という考え方が説明されています(出典1)。
| 区分 | 対象 | AI-OCRとの関係 |
|---|---|---|
| 電子帳簿・電子書類 | 自社が一貫して電子的に作成した帳簿・書類 | 直接の対象ではない |
| スキャナ保存 | 紙で受け取った書類をスキャンして保存 | 解像度・階調、タイムスタンプ等、検索項目の要件が読み取り工程に関わる |
| 電子取引 | メール添付PDFなど電子データで授受した取引情報 | 読み取りの対象にはなるが、保存は受け取ったデータが基本。訂正削除防止の規程等が関わる |
ここで重要なのは、AI-OCRの読み取り精度とスキャナ保存の要件は別の話だということです。 AI-OCRが日付や金額を正しく読めても、保存するデータが解像度や検索項目の要件を満たしていなければ、紙を廃棄できません。逆に、要件を満たす形で保存していても、読み取った値が間違っていれば帳簿が誤ります。読み取りの設計と保存の設計は一体で考える必要があります。
また国税庁は、スキャナ保存に関して「スキャナによる電子化保存規程」と「国税関係書類に係る電子計算機処理に関する事務の手続を明らかにした書類」、電子取引に関して「電子取引データの訂正及び削除の防止に関する事務処理規程」のサンプルを公開しています(出典2)。AI-OCRを組み込んだ業務フローは、この規程に書く「誰が・いつ・どの手順で読み取り、確認し、保存するか」と一致している必要があります。 開発や設定を進める前に、事務所として採用する規程の案を作り、その手順にAI-OCRの工程を当てはめる順序が安全です。
さらに請求書・領収書には、消費税のインボイス制度による記載事項があります。国税庁の解説では、インボイスとして必要な記載事項は、交付先の氏名または名称、売手の氏名または名称および登録番号、取引年月日、取引内容(軽減税率の対象品目である旨)、税率ごとに区分した対価の額および適用税率、税率ごとの消費税額等の6項目で、請求書に限らず領収書や納品書など書類の名称を問わず該当します。小売業・飲食店業・タクシー業などが交付する簡易インボイスでは、宛先の省略と、税率または税額のいずれか一方の記載が認められています(出典3)。
この6項目は、AI-OCRで読み取る項目とチェック項目の設計にそのまま使えます。 登録番号(「T」+数字13桁。出典4)が読めているか、税率ごとの区分が取れているかを読み取り時点でチェック項目にしておけば、記帳の段階で「インボイスの要件を満たしているか」を人が一枚ずつ見る工程を減らせます。簡易インボイスは宛先がなくても不備ではないため、宛先の空欄を一律に弾く条件にすると、レシートの大半が確認対象に回ってしまいます。書類の種類ごとに条件を分ける必要があります。
生成AIを組み合わせる場合
従来のOCRは文字を読み取るところまでを行います。生成AIを組み合わせると、読み取った内容の意味を判断する処理を足せます。 2026年7月時点の主要なモデル(Claude Opus 5・Fable 5、GPT-5.6、Gemini 3.6 Flashなど)は画像の入力に対応しており、「この書類の発行者はどこか」「どの行が合計金額か」を、位置の設定なしに内容から判断させることができます。
| 処理 | 従来のOCR | 生成AIの追加 |
|---|---|---|
| 文字を読み取る | できる | 画像から直接読める |
| 項目の位置が書類ごとに違う | 設定が必要 | 内容から判断できる |
| 摘要から勘定科目を推定する | できない | 候補を出せる |
| 記載の矛盾を指摘する | できない | 指摘できる(税抜・税込の不一致など) |
| インボイスの記載事項の有無 | 項目設定次第 | 6項目の有無を判定できる |
取引先ごとに書式が違う請求書のような、位置が定まらない書類で利点が出ます。 一方で、生成AIの出力は毎回同じとは限らないため、金額のような確定値は「生成AIが読んだ値」をそのまま使わず、前述の合計の突合を通してから確定させる設計にします。生成AIの部分にはAPI利用料が発生し、処理する枚数と画像の量に比例します。計算方法はAI開発のAPI利用料|月額の見積り方にまとめています。
既製サービスで足りる条件と、開発に分岐する条件
既製サービスだけで足りるのは、次の4つがそろっている場合です。
- 読み取る書類の種類が5種類以下
- 形式が安定している
- 読み取り結果を手作業で会計ソフトに取り込んでも負担にならない件数
- 保存要件に制約がない、または既製サービスがその要件に対応している
3番が効いてきます。 月1,000件を超えるなら、読み取り結果の会計ソフトへの取り込みと、前述の機械的なチェックも自動化しないと効果が出ません。ここが開発の分岐点になります。既製サービスの読み取り結果をCSVで出し、チェックと取り込みだけを作る構成が、費用と効果の均衡を取りやすい形です。
| 状況 | 向く選択 |
|---|---|
| 書類の種類が少なく形式が安定、月数百件 | 既製サービスのみ |
| 書式がばらばら、月1,000件超、会計ソフトへ自動で取り込みたい | 既製サービス+チェック・取り込み処理の開発 |
| 顧客ごとの勘定科目ルールを反映、複数の会計ソフトに対応 | 生成AIを組み込んだ開発 |
費用の考え方
| 項目 | 内容 |
|---|---|
| サービス利用料 | 読み取り枚数に応じた課金が一般的 |
| 生成AIのAPI利用料 | 組み合わせる場合に発生。処理量に比例 |
| 開発費 | チェック処理・会計ソフト連携が必要な場合 |
| 保存の仕組み | スキャナ保存要件(タイムスタンプ等・検索)を満たすシステムの利用料 |
| 確認作業の人件費 | 導入後も残る。ここを減らすのが目的 |
最後の項目を計算に入れてください。 読み取り自体が自動化されても、確認に時間がかかるなら効果は限定的です。
投資回収の試算例
次の表は、前提を置いた試算です。数字は実績ではなく、自社のテスト結果に置き換えて使ってください。
| 項目 | 導入前 | 導入後 |
|---|---|---|
| 月間処理件数 | 500件 | 500件 |
| 1件あたりの作業 | 3分(目視入力・照合) | 30秒(弾かれた書類の確認を全件で平均化) |
| 月間工数 | 25時間 | 約4.2時間 |
| 人件費換算(時給3,000円で計算) | 75,000円 | 約12,600円 |
この前提なら月あたり約62,400円の差になり、初期費用が300,000円なら5ヶ月で回収する計算です。 ただし「30秒」は仮の数字です。実物の書類でテストして、この部分を自社の数値に置き換えてから判断してください。サービス利用料とAPI利用料は月額として差し引く必要があるため、回収月数はこの表より延びます。
業種別の想定例
例:会計事務所の記帳部門で、顧客から届く領収書・請求書を読み取り確認する
会計事務所の記帳部門には、月初から中旬にかけて、顧客から領収書と請求書がまとめて届きます。届き方は顧客ごとに違い、紙を封筒で送ってくる顧客、スマートフォンで撮影した画像をアップロードする顧客、メール添付のPDFで送る顧客が混在します。担当者は1枚ずつ日付・金額・支払先・摘要を会計ソフトへ入力し、勘定科目を判断し、税率区分とインボイスの登録番号の有無を確認します。顧客数が増えるほどこの入力と確認が月次の山になり、繁忙期には残業で吸収している、というのが典型的な状態です。
この業務にAI-OCRを当てる場合、最初に決めるのは「読み取りをどこまで信頼し、確認を何に絞るか」です。設計の型としては、読み取った値に対して、税抜額と消費税額と税込額の突合、日付が対象月の範囲内か、支払先名が顧客の過去の取引先一覧に存在するか、登録番号が「T」+数字13桁の形式か、の4つを機械的にチェックし、いずれかで弾かれた書類だけを担当者の確認画面に出します。弾かれなかった書類は、勘定科目の候補が付いた状態で会計ソフトへの取り込み待ちに入ります。手書きの領収書と印字の薄い感熱紙レシートは、テストの段階で外れやすいことが分かるはずなので、最初から「人が見る」側に振り分けておくと、確認工数の見積りがぶれません。
保存については、紙で届いた領収書をスキャナ保存に切り替えるなら、読み取りの解像度・階調、タイムスタンプの付与またはその代替要件、日付・金額・取引先での検索という要件を、AI-OCRの前後の工程で満たす必要があります(出典1)。事務所として「スキャナによる電子化保存規程」を整え(出典2)、顧客から紙を受け取った日、スキャンした日、担当者が確認した日が記録として残る流れにしておくと、入力期間の要件を説明できる状態になります。メール添付のPDFで届いたものは電子取引のデータであり、紙の扱いとは区分が違うため、受け取り経路ごとに保存先を分ける設計が要ります。
導入後に見る指標は、1顧客あたりの記帳完了までの日数と、機械的なチェックで弾かれた書類の割合の2つに絞ります。前者は導入前の数か月分を記録しておかないと比較できないので、テストと同時に記録を始めてください。後者が高止まりしている場合、原因は書類の状態か、チェック条件が厳しすぎるかのどちらかです。閾値を緩める前に、弾かれた書類のうち本当に誤りだったものの割合を見ると、条件の調整方向が決まります。
当社が自社で運用して分かったこと
当社は自社サイト500ページ超をAIで開発・運用し、記事の自動公開パイプラインとサイト上のAIチャットも自社で運用しています。このパイプラインでは、AIが下書きした本文を人が全件読むのではなく、価格の表記が料金表と一致しているか、外部リンクが到達できるか、使ってはいけない表現が入っていないかを機械的に検査し、弾かれたものだけを人が見る形にしています。
AI-OCRの設計と同じ構造です。AIの出力をそのまま信じるのでも、全件を人が見直すのでもなく、「機械で弾く条件」を業務に合わせて決めることが、工数を下げつつ品質を保つ鍵でした。 条件が甘いと誤りが通り、厳しいと人の確認が増えます。この閾値は最初から決め切れないので、運用の初期は弾かれた件数と実際の誤り件数を記録しながら調整する期間を設けています。会計事務所の記帳業務でも、この調整期間を計画に含めておくことをおすすめします。
当社の費用
| プラン | 料金 | 初期費用・契約条件 | 含まれるもの |
|---|---|---|---|
| 業務自動化ミニ開発 | ¥300,000〜(税抜・単発) | — | 1業務の自動化ツールを設計・開発/例: 見積書生成・日報集計・レポート自動作成/要件整理から納品まで2〜4週間/納品後1ヶ月の動作フォロー付き |
| AI組込み開発おすすめ | ¥800,000〜(税抜・要件見積) | — | 社内チャットボット・RAG(社内ナレッジAI)/Claude・GPT・Gemini API統合/業務アプリ・ダッシュボード開発/開発期間1〜3ヶ月・保守プランは別途 |
| AI開発顧問 | ¥300,000/ 月(税抜) | 契約期間 最低3ヶ月(以降1ヶ月単位) 最低期間の総額 ¥900,000(¥300,000×3ヶ月) | Claude Code環境構築・開発伴走/社内メンバーの内製化支援/月次の開発ロードマップ設計/チャット相談・コードレビュー |
読み取り結果のチェック処理と会計ソフトへの取り込みは、業務自動化ミニ開発(300,000円〜・税抜・単発)の代表的な依頼内容です。取引先ごとに書式が違う書類に生成AIで対応する、複数の会計ソフトや顧客ごとの勘定科目ルールを組み込む、といった要件が入ると、AI組込み開発(800,000円〜・税抜・要件見積)になります。事務所内で運用と改修を担える体制を作りたい場合は、AI開発顧問(300,000円/月・税抜・最低3ヶ月)で担当者に引き継ぎます。
初回30分の相談は無料・オンライン対応・秘密厳守です。既製サービスだけで足りると判断した場合は、開発をご提案せずその理由をお伝えします。
商談で聞かれる質問
Q1. 作業範囲はどこまでですか
当社が担うのは、対象書類の分類とテスト設計、既製サービスの選定支援、機械的なチェック条件の設計と実装、会計ソフトへの取り込み処理、試用期間中の閾値調整、検収、運用担当への引き渡しです。発注側にお願いするのは、テスト用の実物書類(顧客名等を伏せたもの)の提供、勘定科目の判断ルールの提示、保存規程の採否の決定、検収に立つ担当者の指名です。保存規程を事務所として採用するかどうかの判断は、当社では代われません。 税務上の取扱いは顧問先や所轄の相談窓口で確認いただく前提で、当社は要件を満たす業務フローの実装を担います。
Q2. 導入後の運用は誰がやりますか
日常の運用は発注側の担当者です。具体的には、弾かれた書類の確認、月に一度の「弾かれた件数と実際の誤り件数」の記録、顧客の追加や取引先一覧の更新、チェック条件の閾値の見直しです。納品時に、これらの手順を画面付きで引き渡します。既製サービス側の仕様変更や会計ソフトの更新で処理が止まった場合の改修は、都度見積り、またはAI開発顧問で継続的にご一緒する形のどちらかです。「納品後の窓口はどこか」は契約前に確認してください。
Q3. 依頼前に何を用意すればよいですか
3点です。第一に、月に届く書類の枚数と種類のおおよその内訳(紙・画像・PDFの比率、手書きの割合)。第二に、現在の記帳にかかっている時間の記録(1顧客あたり、または1枚あたり)。第三に、スキャナ保存や電子取引の保存を事務所としてどう扱っているか、または扱う予定かの現状。いずれも完成している必要はなく、初回の相談で一緒に整理できます。特に第二の記録がないと導入後の効果を比較できないので、相談の前から1か月分だけでも数え始めておくことをおすすめします。
まとめ
- 目標は「確認をゼロにする」ではなく「全件目視をやめ、疑わしいものだけ確認する」
- 導入前に自社に届く実物の書類20〜30枚でテストし、1枚あたりの確認時間を測る
- 精度を上げるより「間違いに気づく仕組み」を組む
- 紙をスキャナ保存に切り替えるなら、解像度・タイムスタンプ等・検索項目の要件を読み取り工程と一体で設計する(出典1・2)
- インボイスの記載事項6項目は、読み取り項目とチェック項目の設計にそのまま使える(出典3)
- 書式が取引先ごとに違うなら、生成AIの組み合わせで利点が出る。API利用料は別に見積もる
- 確認作業の人件費を計算に入れて投資回収を出す
あわせて読みたい
- 経理業務のAI自動化開発|請求書処理・仕訳下書き・月次集計の費用と進め方
- 士業事務所のAI開発活用|定型書類・顧客対応・調査業務の自動化と守秘義務
- AI開発のAPI利用料|月額の見積り方
- 業務自動化PoCの進め方|30万円規模で小さく検証する手順と成功基準
- AI開発のセキュリティ|発注前に確認すべきデータの扱い・学習利用・保管場所
- 経理・財務部門の生成AI研修|仕訳確認・月次資料・監査対応を効率化
- AI開発の記事一覧
出典
- 国税庁「電子帳簿保存法一問一答【スキャナ保存関係】」(令和8年7月) — スキャナ保存の読み取り要件(200dpi以上・赤緑青各256階調以上)、タイムスタンプの付与と代替要件、検索要件(取引年月日その他の日付・取引金額・取引先)、入力期間(おおむね7営業日以内・最長2か月の業務サイクル)
- 国税庁「参考資料(各種規程等のサンプル)」 — スキャナによる電子化保存規程、国税関係書類に係る電子計算機処理に関する事務の手続を明らかにした書類、電子取引データの訂正及び削除の防止に関する事務処理規程のサンプル
- 国税庁「インボイス制度について」 — インボイスの記載事項6項目、書類の名称を問わない旨、簡易インボイスで省略できる項目
- 国税庁 適格請求書発行事業者公表サイト「登録番号とは」 — 登録番号の構成(「T」(ローマ字)+数字13桁)