kintone OCR連携の設計方法｜紙帳票を入力業務に戻さない構成

kintoneとOCRを連携したい相談では、最初に読み取り精度の話になりやすいです。

請求書を読み取りたい。

領収書を読み取りたい。

申請書やアンケートを自動入力したい。

FAXやメール添付のPDFをkintoneへ取り込みたい。

手書き文字まで読めるのか知りたい。

たしかに、OCRの読み取り精度は重要です。

ただし、実務で崩れるのは「文字を読めないこと」だけではありません。

本当に困るのは、次のような状態です。

• 読み取り結果をそのまま本登録し、誤字や金額違いが残る
• 請求書、領収書、申請書、アンケートを同じ流れで処理している
• 取引先名や品目名がマスタと一致せず、後続処理で使えない
• OCR結果の確認担当が決まっていない
• 読み取りに失敗した帳票が放置される
• 同じPDFを二重登録してしまう
• 原本画像やPDFの保存先が分からない
• 承認前のデータが会計や請求処理へ流れる
• 電子取引保存やスキャナ保存の扱いをkintoneだけで判断している
• OCRサービスを入れたのに、結局、別のExcelへ転記している

OCR連携は、紙を読み取るだけの仕組みではありません。

紙、PDF、画像、FAX、メール添付を受け付け、OCR結果を確認し、必要な項目だけをkintoneの業務データへ渡す仕組みです。

kintone OCR連携で最初に決めるべきなのは、どのOCRサービスを使うかではなく、「OCR結果をどこで人が確認し、どの状態から本登録するか」です。

この記事では、OCRサービス比較ではなく、kintoneとOCRを業務で使える形に設計する方法を整理します。

kintone請求書管理の設計方法はこちら
kintone帳票出力の設計方法はこちら
kintone名刺管理の設計方法はこちら

先に結論：OCRは入力候補を作る工程として設計する

OCRを入れると、紙帳票の入力がなくなるように見えます。

しかし、実務では「入力作業」がそのまま「確認作業」に移ります。

ここを設計しないと、OCR結果の誤りが本登録されます。

まず、次の情報を分けます。

分けるもの	1レコードの意味	役割
受付レコード	1つの紙、PDF、画像、メール添付	原本、取込元、受付状態を持つ
OCR結果	1回の読み取り結果	読み取り項目、信頼度、候補値を持つ
確認キュー	1件の確認待ち	担当者、期限、優先度、確認状態を持つ
マスタ照合	取引先、品目、税区分などとの照合	読み取った文字を業務データに変換する
例外処理	不明、重複、読取失敗、差し戻し	人が判断すべきものを分岐する
業務レコード	請求、経費、申請、アンケート回答など	確定したデータを本登録する
承認・確認	金額、内容、添付、支払可否の確認	後続処理へ進めてよいか判断する
原本保管	画像、PDF、スキャンファイル	後から照合できるようにする
連携ログ	会計、保管、通知などの結果	外部連携の成否を追う

OCR結果は、業務データの候補です。

まだ正式データではありません。

請求書の取引先名を読み取れても、自社の取引先マスタと一致するとは限りません。

領収書の合計金額を読み取れても、税区分や勘定科目まで正しいとは限りません。

アンケートの自由記述を読み取れても、営業フォロー対象かどうかは別の判断です。

OCR連携で重要なのは、文字を読めることではなく、読み取った候補値を確認済みの業務データへ変換できることです。

OCR導入で失敗する理由

kintoneとOCRの連携で失敗しやすい理由は、OCRを「入力の代替」とだけ考えることです。

実際には、次の設計が必要です。

失敗	原因	設計で見ること
誤読が本登録される	OCR結果をそのまま確定している	確認キューと承認を挟む
取引先が増殖する	読み取った会社名を新規登録している	取引先マスタ照合を入れる
金額が会計に合わない	税区分や明細を確認していない	明細、税率、合計のチェック
読取失敗が放置される	例外状態がない	不明、差し戻し、再読取を分ける
二重登録する	原本や請求番号で重複確認していない	ハッシュ、番号、取引先、日付で確認
保管先が分からない	原本画像と登録データが分かれている	原本添付と保存URLを戻す
現場が使わない	確認画面が業務に合っていない	帳票別に確認項目を変える

OCRは万能ではありません。

読み取りやすい帳票もあれば、読み取りにくい帳票もあります。

定型帳票、活字、きれいなPDFは処理しやすいです。

手書き、写真の傾き、薄い印字、複数ページ、自由記述、印影や罫線が多い帳票は確認が必要です。

そのため、OCR連携の最初の設計では、対象帳票を分けます。

帳票	OCR後に人が確認すべき項目
請求書	取引先、請求日、支払期限、金額、税区分、請求番号
領収書	利用日、店名、合計金額、税区分、用途、添付
申請書	申請者、申請内容、添付、承認者、金額
アンケート	回答者、設問、選択肢、自由記述、フォロー要否
問診票	氏名、生年月日、症状、同意、確認者
棚卸表	品目、数量、棚番、差異、確認者

ジョイゾーのLINE WORKS OCR連携プラグインでは、レシートや請求書画像をkintoneにアップロードし、店名、住所、明細金額、合計金額などを読み取ってkintoneフィールドへ登録する用途が紹介されています。

ジョイゾー：LINE WORKS OCR連携プラグイン

このような連携は、経費精算や請求書管理で有効です。

ただし、読み取った金額や取引先をそのまま確定にせず、確認済みへ進めるルールが必要です。

取り込み対象を紙・PDF・画像・メール添付に分ける

OCR連携では、入口を分けます。

同じ「OCR」と言っても、紙をスキャンするのか、PDFをアップロードするのか、スマホ写真を撮るのか、メール添付を受けるのかで運用が変わります。

入口	例	設計の注意点
紙スキャン	請求書、申請書、棚卸表	スキャン担当、解像度、原本扱い
PDFアップロード	メールで届いた請求書、申込書	ファイル名、二重登録、保存先
スマホ写真	領収書、現場報告、名刺	画像の傾き、影、撮影者
FAX	注文書、申込書、依頼書	受信フォルダ、読取失敗、再送確認
メール添付	請求書PDF、注文書PDF	メール本文、添付抽出、送信元確認
外部サービス連携	OCRサービス、名刺管理、会計	連携ログ、エラー、再実行

入口を1つにまとめると、確認担当が混乱します。

請求書PDFとアンケート画像では、確認項目も担当者も違います。

経費精算の領収書と、顧客から届く注文書も違います。

受付レコードには、最低限次の項目を持たせます。

フィールド	型	設計意図
受付番号	文字列、採番	原本とOCR結果を追う
取込元	ドロップダウン	紙、PDF、写真、FAX、メール、外部連携
帳票種別	ドロップダウン	請求書、領収書、申請書、アンケートなど
原本ファイル	添付ファイル	後から照合する
受付者	ユーザー選択	誰が受けたか
受付日時	日時	処理期限や保存確認に使う
OCR状態	ステータス	未読取、読取中、確認待ち、確定、例外
重複候補	関連レコード	同じ原本や請求番号を確認する
保存先URL	リンク	外部保管先と紐づける

トヨクモの記事では、kintoneと連携できるOCRサービス・プラグインを複数紹介し、請求書、FAX、アンケート、問診票、チェックシートなどの用途が整理されています。

トヨクモ：kintoneとOCRを連携するなら？

用途が広いほど、入口と確認キューを分けることが重要になります。

OCR結果をそのまま本登録しない設計

OCR結果は候補値です。

本登録する前に、確認と補正を挟みます。

OCR結果	確認すること
取引先名	既存マスタに一致するか
請求番号	重複していないか
請求日・領収日	日付として正しいか
金額	税込、税抜、税額、合計が一致するか
明細	品目、数量、単価、税区分が正しいか
氏名・住所	表記ゆれや読み違いがないか
自由記述	人が読むべき内容か、分類だけでよいか

ATTAZoo AI OCRパックの掲載ページでは、PDFの取り込み、OCR化、帳票確認までをkintone上で実現し、読み取り結果を1画面で確認・修正できることが紹介されています。

サイボウズ連携サービス：ATTAZoo AI OCRパック

この「確認できる」工程を、業務フローとして設計することが重要です。

確認キューには、次の項目を持たせます。

フィールド	型	設計意図
確認担当	ユーザー選択	誰が確認するか
確認期限	日時	支払や承認に間に合わせる
優先度	ドロップダウン	支払期限、顧客影響、金額で判断する
確認状態	ステータス	未確認、確認中、修正済み、確定、差し戻し
信頼度	数値、選択肢	OCR結果の確からしさを判断する
補正理由	テキスト	なぜ人が直したかを残す
確定値	各フィールド	業務レコードへ渡す値

OCR結果をそのまま本登録するのではなく、「OCR値」「人が補正した値」「確定値」を分けると、後から精度と運用のどちらが問題だったか見えます。

確認キュー・例外処理・差戻しの流れ

OCR連携では、正常系より例外系の設計が重要です。

正常に読めた帳票は、確認して本登録できます。

しかし、実務では必ず例外が出ます。

例外	対応
画像が不鮮明	再スキャン、再撮影を依頼
帳票種別が不明	仕分け担当へ回す
取引先が見つからない	新規登録申請または既存マスタ候補確認
請求番号が重複	二重登録確認
金額が合わない	明細と合計を確認
税区分が不明	経理確認へ回す
添付が不足	申請者へ差し戻す
保存要件が不明	経理・管理者へ確認

例外を自由コメントだけで処理すると、放置されます。

例外種別を選択肢にして、担当者と期限を持たせます。

例外状態	次の行動
再読取待ち	原本を再アップロードする
申請者差戻し	添付や内容を修正してもらう
マスタ確認待ち	取引先・品目候補を確認する
経理確認待ち	税区分、支払可否、保存方法を確認する
管理者確認待ち	連携エラーや設定不備を確認する
破棄	対象外、重複、取消として残す

通知も設計します。

OCR失敗のたびに全員へ通知すると、見られなくなります。

通知すべきなのは、確認期限、支払期限、差し戻し、連携エラーなどです。

通知条件	通知先
確認期限が近い	確認担当
支払期限に影響する	経理担当、承認者
取引先マスタが見つからない	マスタ管理者
OCR連携エラー	システム管理者
差し戻し	受付者、申請者
再読取が必要	受付担当

OCR連携を定着させるには、読めた帳票よりも、読めなかった帳票を誰がいつ処理するかを設計します。

取引先マスタ・品目マスタとの照合

OCRで読み取った文字は、業務で使えるコードとは限りません。

取引先名、品目名、部署名、勘定科目、税区分は、マスタと照合します。

読み取り項目	照合先	確認すること
取引先名	取引先マスタ	正式名称、支払条件、インボイス番号
請求先住所	請求先マスタ	住所表記、部署、担当者
品目名	品目マスタ	商品コード、税区分、勘定科目
金額	明細・合計	税抜、税額、税込が合うか
請求番号	請求書管理	重複していないか
領収日	経費申請	対象期間内か
申請者名	ユーザーマスタ	社内ユーザーと一致するか

ここで避けたいのは、OCRが読んだ取引先名をそのまま取引先マスタへ追加することです。

たとえば、同じ会社でも次のように揺れます。

OCR結果	本来のマスタ
株式会社ビットライト	株式会社ビットライト
（株）ビットライト	株式会社ビットライト
ビットライト	株式会社ビットライト
株式会社 ビットライト	株式会社ビットライト
BITLIGHT Inc.	株式会社ビットライト

マスタ照合では、完全一致だけでなく候補表示も必要です。

ただし、自動で統合しすぎると誤統合が起きます。

現実的には、次の段階に分けます。

照合結果	処理
完全一致	自動で紐づける
高い候補一致	確認キューで人が選ぶ
候補複数	マスタ管理者へ回す
候補なし	新規マスタ登録申請
重複疑い	二重登録確認

マスタ照合がないOCR連携は、入力は減っても後続処理が増えます。

会計、請求、在庫、顧客管理へつなぐなら、文字列ではなくマスタIDへ変換する設計が必要です。

請求書・領収書・申請書で異なる設計

OCR連携は、帳票ごとに設計を変えます。

請求書、領収書、申請書、アンケートを同じアプリで処理すると、確認項目が膨らみます。

帳票	本登録先	確認ポイント
請求書	請求書管理、支払予定、会計連携	取引先、請求番号、支払期限、税区分、二重登録
領収書	経費精算、支払申請	利用日、店名、金額、用途、添付、承認者
申請書	申請管理、承認ワークフロー	申請者、内容、添付、承認ルート
アンケート	回答管理、営業フォロー	回答者、設問、自由記述、フォロー要否
問診票	受付・予約・診療前確認	氏名、生年月日、同意、確認済み状態
棚卸表	在庫管理、差異確認	品目、数量、棚番、差異理由

請求書OCRでは、金額と支払期限が重要です。

領収書OCRでは、経費用途と承認者が重要です。

申請書OCRでは、承認ルートと添付不足が重要です。

アンケートOCRでは、集計とフォロー対象の抽出が重要です。

それぞれで、確認キュー、承認、連携先を変えます。

帳票	確認担当	次の連携
請求書	経理、購買、部門責任者	会計、支払、電子取引保存
領収書	申請者、上長、経理	経費精算、会計
申請書	申請部署、承認者	ワークフロー、契約、マスタ登録
アンケート	営業、マーケティング	顧客管理、フォロータスク
棚卸表	現場、在庫管理者	在庫差異、発注、棚卸承認

同じOCRサービスを使っても、業務アプリ側は分けた方がよいです。

「OCR受付」は共通にし、確定後の本登録先を帳票種別で分ける設計が扱いやすいです。

会計・電子取引保存・ワークフロー連携

OCRで読み取った後は、後続処理へつなぎます。

請求書や領収書なら、会計や支払処理へつながります。

申請書なら、承認ワークフローへつながります。

アンケートなら、顧客管理やフォロータスクへつながります。

後続処理	kintoneで持つこと	外部に任せること
会計連携	確認済み金額、取引先、連携ログ	仕訳、支払、消込、税務処理
電子取引保存	原本ファイル、保存先URL、確認状態	保存要件を満たす文書管理・会計サービス
ワークフロー	申請状態、承認者、差し戻し理由	複雑な決裁規程や電子契約
顧客管理	回答者、関心、フォロー状態	MA、メール配信、CRM連携
在庫管理	棚卸結果、差異、確認者	基幹在庫、原価、発注

電子取引保存やスキャナ保存の扱いは、OCRを入れれば自動で満たせるものではありません。

国税庁の電子帳簿等保存制度特設サイトでは、電子取引データの保存義務や保存方法、スキャナ保存など制度別の情報が案内されています。

国税庁：電子帳簿等保存制度特設サイト

kintoneで設計するなら、少なくとも次の情報を残せるようにします。

残す情報	目的
原本ファイル	後から照合する
受付日時	いつ受けたか
取引先	検索・照合する
金額	検索・照合する
確認者	誰が確定したか
保存先URL	保管場所へたどる
差し替え履歴	旧版と新版の関係を説明する

ただし、保存要件そのものは、会計担当、税理士、利用する保管サービスと確認します。

kintoneは、受付、確認、照合、連携ログを持つ場所として設計し、正式な保存先や会計処理は別サービスと役割を分けることがあります。

OCR連携では、読み取った後にどの業務システムへ渡すかを先に決めます。会計・保管・承認の正本が曖昧なままだと、入力だけ減って確認が増えます。

よくある失敗パターン

kintone OCR連携でよくある失敗を整理します。

1. OCR結果をそのまま確定する

OCRは候補値を作る工程です。

金額、税区分、取引先、請求番号、申請者などは人が確認します。

確認前の値と確定値を分けます。

2. 帳票種別を分けない

請求書、領収書、申請書、アンケートでは、確認担当も後続処理も違います。

受付は共通化しても、本登録先と確認項目は帳票種別で分けます。

3. 取引先マスタと照合しない

OCRが読んだ会社名をそのまま使うと、表記ゆれが増えます。

取引先マスタ、品目マスタ、税区分マスタと照合します。

4. 読めなかった帳票を管理しない

読めなかった帳票は、入力待ちではなく例外処理として扱います。

再読取、差し戻し、マスタ確認、経理確認の状態を分けます。

5. 原本ファイルを残さない

OCR結果だけ残して原本がないと、後から確認できません。

PDF、画像、スキャンファイルを受付レコードや保存先URLで紐づけます。

6. 二重登録を防がない

同じ請求書や領収書を複数回アップロードすることがあります。

請求番号、取引先、日付、金額、ファイル情報で重複候補を出します。

7. 会計連携を早くしすぎる

OCR結果の確認前に会計へ流すと、修正が面倒になります。

確認済み、承認済み、連携待ち、連携済みを分けます。

8. OCRサービス選定だけで終わる

どのOCRサービスを使うかは重要です。

ただし、運用を決めないと、読取結果の確認、例外処理、マスタ照合、会計連携が人任せになります。

まず決める設計チェックリスト

kintoneとOCRを連携する前に、次の項目を決めます。

確認項目	決めること
対象帳票	請求書、領収書、申請書、アンケート、問診票など
入口	紙スキャン、PDF、画像、FAX、メール添付
受付レコード	原本、取込元、状態、担当者をどう持つか
OCR結果	候補値、信頼度、読み取りログを残すか
確認キュー	誰が、いつまでに、何を確認するか
確定値	OCR値と人が補正した値を分けるか
マスタ照合	取引先、品目、税区分、ユーザーを照合するか
例外処理	読取失敗、重複、不明、差し戻しの状態
本登録先	請求、経費、申請、回答、在庫など
承認	どの状態から会計や後続処理へ渡すか
原本保管	kintone添付、Drive、文書管理、会計ソフト
電子取引保存	保存要件を誰が確認するか
連携ログ	会計、保管、通知、再実行の結果
精度改善	補正理由、読取失敗理由をどう蓄積するか

この表が埋まると、OCRサービス選定も明確になります。

請求書に強いサービスが必要なのか。

手書きに強いサービスが必要なのか。

PDF一括処理が必要なのか。

kintone上で確認画面まで必要なのか。

原本保存や会計連携まで見るべきなのか。

判断軸が「読めるか」ではなく、「確認して業務データにできるか」に変わります。

Bitlightに相談できること

Bitlightでは、kintoneとOCRの連携を、読み取り機能だけではなく入力・確認・連携フローとして設計できます。

たとえば、次のような支援ができます。

• OCR対象帳票の整理
• 紙、PDF、画像、FAX、メール添付の受付設計
• OCR結果、確認キュー、確定値の分離
• 取引先マスタ、品目マスタ、税区分との照合設計
• 読取失敗、重複、不明、差し戻しの例外処理
• 請求書、領収書、申請書、アンケートごとの本登録先設計
• 承認済みデータだけを会計や後続処理へ渡すステータス設計
• 原本ファイル、保存先URL、電子取引保存確認の項目設計
• OCRサービスやkintoneプラグインの選定支援
• 既存の紙帳票・Excel入力業務をkintone向けに分解する支援

OCR連携は、入れるだけなら早く始められます。

しかし、読み取り結果を誰が確認し、どのマスタと照合し、どの状態で本登録し、どこへ連携するかを決めないと、入力作業が別の確認作業に置き換わるだけです。

紙やPDFを減らしたいなら、OCRの入口だけでなく、確認、例外処理、承認、保管、会計連携までまとめて設計します。

kintone OCR連携は、紙を読むためではなく、読み取った候補値を確認済みの業務データへ変換し、後続処理へ安全に渡すために設計します。