紙やPDFの書類を、確認しながら正確にデータ化する

書類からのデータ入力が負担として残りやすい理由

書類の「電子化」と「データ化」は別の工程

請求書をPDFで受け取ったり、紙の書類をスキャンして保存したりすることで、書類の保管や共有は効率化できます。しかし、PDFや画像のままでは、支払期日での並べ替えや取引先ごとの集計、ほかのデータとの突き合わせはできません。書類に書かれた内容を業務で活用するには、項目ごとの値としてデータベースや業務システムへ登録する「データ化」の工程が必要です。

また、2023年10月に始まったインボイス制度（適格請求書等保存方式）では、適格請求書の記載事項として、発行事業者の登録番号、取引年月日、税率ごとに区分した対価の額や消費税額などが定められています（国税庁「インボイス制度について」）。請求書を受け取る側では、こうした記載事項を確認しながら内容を記録する場面があり、件数が増えるほど担当者の負担になりやすい工程といえます。

手入力による転記が抱える課題

書類の内容を人が読み取り、システムへ手入力する運用では、次のような課題が生じやすくなります。

• 件数に比例して作業時間が増え、月末・月初など特定の時期に作業が集中しやすい
• 桁の誤りや転記漏れを防ぐためのダブルチェックに、追加の工数がかかる
• 取引先名や品名の表記が書類ごとに異なり、登録済みのマスタとの照合に手間がかかる
• 入力できる担当者が限られ、繁忙期や担当者の不在時に業務が滞りやすい

文字を読み取った後の工程が残りやすい

文字を読み取る技術としてのOCRは以前から利用されてきました。帳票向けのOCRでは、様式ごとに読み取り位置をあらかじめ定義しておく方式が多く見られ、同じ様式の帳票を大量に処理する業務に適しています。一方で、取引先ごとに様式が異なる書類では、定義の作成・保守に手間がかかることがあります。

さらに、読み取った文字列を日付や金額などの形式に整える、取引先名をマスタの登録名に合わせる、といった後工程は、OCRとは別の作業として残ることがあります。データ化の負担を減らすには、文字の読み取りだけでなく、その前後の工程も含めて見直すことが大切です。

AI OCRを業務に組み込む際の3つの考え方

AI OCRの導入効果は、文字の認識精度だけでなく、読み取った後の工程をどう設計するかによっても左右されます。利用するツールにかかわらず、次の3点を整理しておくと、導入後の運用が安定しやすくなります。

「文字の読み取り」と「項目への対応づけ」を分けて考える

書類のデータ化は、①書類に書かれた文字を読み取る工程と、②読み取った文字を「請求日」「合計金額」などの項目に対応づけ、日付や数値といった項目の形式に整える工程に分けて考えることができます。近年は、大規模言語モデル（LLM）などの生成AIを②の工程に活用することで、様式が統一されていない書類でも、項目名や記載位置の手がかりから値を対応づける方法が利用できるようになっています。

工程を分けて捉えておくと、読み取り結果に誤りがあった場合に、文字の認識の問題なのか、項目の対応づけの問題なのかを切り分けやすくなり、改善の打ち手も検討しやすくなります。

人による確認を前提に業務フローを設計する

AI OCRの読み取り精度は、書類の解像度や手書き文字の状態などによって変わるため、誤りを完全になくすことは困難です。また、生成AIには、書類に書かれていない値を文脈から推測し、もっともらしく出力してしまう可能性もあります。

総務省・経済産業省の「AI事業者ガイドライン」の第1.2版（2026年3月）では、AIによる判断を人が最終判断する際に、AIの判断を過度に信頼して自らの判断や確認を怠ってしまう「自動化バイアス」への懸念が追記されています。業務に組み込む際は、AIの出力をそのまま登録するのではなく、原本と見比べて確認・修正してから登録する流れを前提とし、確認しやすい画面や入力規則による検証を組み合わせることが現実的です。

登録先のデータ構造と入力ルールを先に決める

読み取った値の登録先となる項目や入力ルールが曖昧なままだと、AIが値を対応づける基準も曖昧になります。項目ごとの型（日付・数値・選択肢など）、必須項目、取引先などマスタとの関連をあらかじめ定義しておくことで、読み取り結果を同じ基準で検証でき、登録後の集計やシステム連携にもそのまま活用しやすくなります。

RapidTableの「RaIM AI OCR」でできること

ここからは、上記の考え方をRapidTableでどのように実現できるかをご紹介します。

RapidTableは、エクセルやスプレッドシートを扱う感覚でデータベースを設計できる、SaaS型のノーコード・ローコードデータベースです。RapidTableのAI機能「RaIM」は、AIチャットとAI OCRを提供しています。RaIM AI OCRは、画像やPDFの書類を読み取り、プロジェクト（データベース）のフィールド定義に沿って値を対応づけたうえで、利用者の確認・修正を経てレコードとして登録する機能です。

スプレッドシートから画像・PDFを取り込む

RaIM AI OCRは、プロジェクトのスプレッドシート画面で、ツールバーの［挿入］メニューにある［画像から取り込み］から利用します。主な仕様は次のとおりです。

読み取り・対応づけ・参照の解決の3段階で処理

RaIM AI OCRは、前章で触れた「文字の読み取り」と「項目への対応づけ」を分け、次の3段階で処理します。

1. 読み取り：文字の読み取りに特化したOCRエンジンが、書類に書かれた文字や表の構造をテキストとして読み取ります。
2. 対応づけ：生成AIが、読み取ったテキストを基準に、元の画像とも突き合わせながら、プロジェクトのフィールドへ値を対応づけます。手書きと見られる箇所や不自然な文字列、項目の形式に合わない値などは、画像の該当箇所を読み直して訂正します。画像にもテキストにもない値は出力しないよう指示しています。
3. 参照の解決：取引先マスタなど、別のプロジェクトを参照するフィールドについては、読み取った名称で参照先のレコードを検索し、該当するレコードに対応づけます。1〜2文字程度の誤読や表記ゆれは許容しつつ、大きく異なる候補は採用しません。

帳票の様式ごとに読み取り位置を定義する必要はなく、プロジェクトのフィールド定義が対応づけの基準になります。各フィールドの「備考」に、書類上の記載位置や略称の扱いなどを書いておくと、読み取りの手がかりとして活用されます。

フィールドの型に合わせて値を整える

読み取った値は、登録先のフィールドの型に合わせて次のように整えられます。

入力フォームで読み取りの対象と入力ルールをそろえる

読み取りの対象は、プロジェクトに登録済みの入力フォームから選択できます。選択したフォームに配置された項目だけが読み取り・保存の対象となり、非表示や読み取り専用に設定された項目は読み取りの対象から外れます。プロジェクトの表示設定で利用できる入力フォームが制限されている場合は、許可されたフォームの中から選択します。同じ画面で続けて取り込む際は、前回選択したフォームが初期選択されるため、同じ種類の書類を続けて登録する場合も選び直す必要がありません。

入力フォームのルックアップ設定も、読み取った値を起点に動作します。たとえば、読み取った取引先名から取引先マスタのレコードが特定されると、ルックアップによって住所や支払条件などの関連情報をフォームへ補完できます。

原本と見比べて確認・修正してから保存

読み取りが終わると、全画面の確認画面に切り替わり、左側に原本のプレビュー、右側に入力フォームが並んで表示されます。画像はマウスを乗せた部分を拡大表示でき、PDFはビューアのツールバーで拡大して細部を確認できます。スマートフォンなど画面幅の狭い端末では、入力フォームとプレビューをタブで切り替えて表示します。

1つのファイルから複数件のデータが読み取られた場合は、1件ずつ確認します。［保存］でスプレッドシートに新しい行として登録し、［キャンセル］でその1件を登録せずに次へ進みます。必須項目の未入力など入力規則に反する項目は、読み取った直後から強調表示され、修正するまで保存できません。画面上部には処理中のファイル名と、何ファイル目を処理しているかが表示されます。途中で画面を閉じた場合も、それまでに保存したデータは登録されたまま残ります。

入力フォームに画像型や任意ファイル型のフィールドがある場合は、読み取りに使った原本のファイルが自動的にセットされるため、書類の原本とデータを同じレコードで管理できます。不要な場合は、通常のファイル項目と同じ操作で削除できます。

スマートフォンのカメラで書類をスキャン

カメラを利用できる端末では、［カメラで書類をスキャン］から、アプリ内のスキャナで書類を撮影して取り込むこともできます。撮影した画像から書類の四隅をブラウザ上で自動的に検出し、斜めから撮影した書類を正面から見た形に補正（台形補正）した画像を作成します。四隅を検出できなかった場合は、ドラッグで範囲を調整できます。複数ページの書類は、［次のページをスキャン］で続けて撮影でき、1ページずつ画像として取り込まれます。

RapidTableはPCのブラウザに加え、スマートフォンやタブレットからも利用できます。外出先や現場で受け取った書類を、その場で撮影して登録するといった運用にも対応しやすくなります。

安心して使うための仕組み

利用者の権限の範囲で読み取り・登録

RaIM AI OCRは、操作している利用者の権限で、プロジェクトのフィールド定義や参照先のデータを取得します。ユーザー表示設定で非表示にしているカラムは、参照先のプロジェクトも含めて読み取りの対象外となります。読み取り結果は確認画面の入力フォームを経由し、通常のデータ登録と同じ仕組みで登録されます。

AIの推測で値を埋めないための設計

生成AIによる対応づけでは、書類に書かれていない値が補われてしまうことを防ぐ設計を重視しています。

• 書類から読み取れなかった項目には、AIが推測した値を入れず、確認画面で利用者が入力できる状態にします。
• タグ・ユーザーは登録済みの候補と一致した場合のみ、外部参照は検索で見つかったレコードのみを対応づけます。存在しないタグやユーザーが登録されることを防ぐためです。
• フィールドの「備考」は読み取りの手がかりとしてのみ扱い、指示のような文言が書かれていても、読み取りのルールや出力の形式は変わりません。

利用量の管理と、書類の内容の取り扱い

RaIMの利用量はクレジットで管理され、当月のクレジット使用量などを画面で確認できます。AI OCRの実行前には当月の使用限度額を超えていないかを確認し、超過している場合は読み取りを開始しません。

読み取りに使ったファイルは、確認画面で保存したレコードのファイル項目にセットされている場合を除き、RapidTableのデータとして保存されることはありません。また、読み取った書類の内容は、既定ではアプリケーションのログに出力しない設計としています。

まとめ

書類のデータ化は、文字の読み取りだけでなく、項目への対応づけ、表記の統一、マスタとの照合、内容の確認までを含む工程です。文字の読み取りと項目への対応づけを分けて考える、人による確認を前提に業務フローを設計する、登録先のデータ構造と入力ルールを先に決める、といった考え方は、ツールの選定にかかわらず検討の出発点になります。

RaIM AI OCRは、これらの考え方に沿って、RapidTableのプロジェクトや入力フォームの設定をそのまま読み取りの基準として活用できるように設計しています。帳票の様式ごとに読み取り位置を定義する作業を必要とせず、業務部門や情報システム部門が自ら設定を調整しやすいため、転記作業の負担軽減や、データ入力業務の内製化につながることが期待できます。

また、登録したデータは、承認ワークフローや帳票の出力、REST APIによる外部システムとの連携などにも活用できます。書類の受け取りから後続の業務までを段階的にデジタル化していく、DXの基盤としてもご活用いただけます。

※ 記載の内容は、本記事公開時点の製品仕様に基づいています。RaIM AI OCRは、RaIMをご利用いただける環境で利用できます。機能の詳細は製品マニュアルをご確認ください。