年50万件の資格証明書・経歴証明書を手入力 — AIで自動化できるか。オンプレミスAI-OCRの技術検証

概要

韓国のある公共機関から、年間およそ50万件の資格証明書・経歴証明書を 6名の担当者が手作業で処理している業務を自動化できないか、というご相談を いただきました。AIが各文書から必要な項目を抽出し、抽出項目ごとに信頼度を 算出して、確信度の低いものから優先的に検証できるようにする、そして確認後は 自動承認する — という流れを構築しました。文書に個人情報が含まれるため、 構築とテストはすべて**機関の内部ネットワーク内（オンプレミス）**で実施しています。

課題 — 50万件を6名がすべて手入力

• 資格証明書、経歴証明書などの添付書類が年間およそ50万件
• 6名の担当者が1件ずつ内容を確認し、必要項目（資格名、発行機関、取得日、勤務期間）を システムへ手入力
• 1人あたり年間8万件以上。処理の遅れが積み上がるうえ、繰り返しの手入力には 入力ミスや記入漏れがついて回る

検証したい点は明快でした。手入力なしで回せるか、です。

一般的なOCRでは足りなかった理由

一般的なOCRは画像を文字に変換します。ただし、どの文字が資格名で、どの文字が 取得日なのかまでは判別できません。証明書は発行機関ごとに書式が異なり、項目が 表の中に埋め込まれていることも多いため、文字を抽出しただけでは結局、人が分類して 入力し直すことになります。

ROI（座標指定）方式でも自動化できなかった

文書自動化でよく使われるのがROI（Region of Interest／関心領域）方式です。 「この書式では資格名はこの座標にある」と定義して、その領域を読み取ります。 書式が固定されている場合には有効な手法です。

しかし今回の文書は、そうではありませんでした。

• 同じ書式の文書でも、ページによって項目の位置がずれる。 上部の記載が長くなると、それ以下の項目がすべて下へ押し下げられます
• 改行の入り方が文書ごとに異なる。 ある文書では1行に収まる経歴が、 別の文書では2行に折り返されます

座標で読み取ると、正しく取れる文書と、まったく違う値を返す文書が混在します。 書式ごとにテンプレートを保守しても、このばらつきは吸収できませんでした。 実質的には非定型文書であり、ROI方式や単純なOCRの自動化が及ぶ範囲を 超えていたというのが結論です。

位置ではなく、意味で読む

SUVsoft AI-OCRは、座標ではなく文書内のキーバリュー（項目名と値）の関係を 読み取ります。「資格名 → ◯◯技師」「取得日 → 20XX.XX.XX」というかたちです。 項目を意味で特定するため、記載位置が下へずれても、2行に折り返されても、 抽出結果は変わりません。しかも業務システムがそのまま取り込める形式で出力されます。

検証したワークフロー — 抽出、確認、自動承認

1. 自動抽出 — 審査に必要な項目（資格名、発行機関、取得日、勤務期間）をAIが抽出
2. 信頼度に基づく検証 — 検証画面には原本の画像と抽出値が並べて表示されます。 担当者は入力するのではなく、確認するだけです
3. 自動承認 — 確認済みの項目は自動で承認され、後続の処理へ流れます

担当者の役割が「読んで入力する」から「確認して承認する」に変わります。 手入力が業務フローから消えるため、入力ミスや記入漏れは構造的になくなります。

全件を人が見るなら意味がない — だから信頼度で順番を決める

自動抽出をしても、担当者が50万件すべてを目で追わなければならないなら、 削減効果はありません。作業の名前が「入力」から「検証」に変わっただけです。 文書自動化のプロジェクトが導入後に期待ほどの効果を出せない場面は、 たいていここでつまずいています。

そこでエンジン側で抽出項目ごとにダブルチェックを行い、信頼度を算出します。 検証画面では信頼度の低い項目から先に提示され、担当者は本当に確認が必要な ところに時間を使えます。

もちろん、すべての項目を開いて確認することもできます。AIの判断で結果を 隠すのではなく、見る順番を提案する仕組みです。審査業務の最終判断は人が行うべきものです。 確認された項目は、そのまま自動承認へ進みます。

個人情報 — オンプレミス構築と自動マスキング

対象の文書には、氏名、生年月日、住民登録番号（日本のマイナンバーに相当）が 含まれます。外部のクラウドAPIへ送信するという選択肢は、はじめからありませんでした。

• オンプレミスでの検証 — 構築とテストはすべて機関の内部ネットワーク内で実施しました。 文書も抽出データも、外部へ出ることはありません
• 個人情報の自動検知・マスキング — SUVsoftの個人情報検知技術により、 文書内の住民登録番号などの識別情報を検出してマスキングします。処理の過程で 個人情報が不必要に露出しないようにするためです

検証で確認できたこと

• 発行機関ごとに書式が異なり、同じ書式内でも位置がずれる実際の文書に対して、 座標（ROI）に依存しないキーバリュー抽出が機能すること
• 項目ごとの信頼度算出と、信頼度の低い順に検証キューを並べる仕組みが 設計どおりに動作すること
• 抽出 → 原本との並列確認 → 自動承認という一連の流れが、 完全にオンプレミスで実装可能であること
• 住民登録番号などの個人情報の自動検知・マスキングが、実際の文書上で機能すること

本事例は技術検証（PoC）段階の内容です。実導入に進んだ場合は、 運用結果を本ページに追記します。

よくあるご質問

Q. 一般的なOCR製品と何が違いますか？ 一般的なOCRは画像を文字に変換します。どの文字が資格名でどの文字が取得日かは 判別できないため、結局は人が分類することになります。AI-OCRはキーバリューの組で 抽出するため、システムがそのまま取り込めるデータになります。

Q. 書式が頻繁に変わりますが、そのたびに設定し直す必要がありますか？ 座標（ROI）方式であれば必要です。キーバリュー抽出は位置ではなく文書の意味構造を 読み取るため、書式変更の影響を受けにくい方式です。

Q. 結局すべて人が確認するのではありませんか？ 検証は業務の一部として残ります。ただし項目ごとに信頼度が付与され、 確信度の低いものから順に提示されます。全件を同じ注意力で見ていくのとは、 かかる時間がまったく異なります。

Q. 文書に個人情報が含まれます。外部に出ることはありませんか？ オンプレミス構成であれば、文書も抽出結果も内部ネットワークから出ません。 住民登録番号などの識別情報については、自動検知とマスキングを 処理の一部として適用できます。

環境

関連製品: AI-OCR — インテリジェント文書処理

同様の業務をお持ちですか？ 担当者が文書を読み取ってシステムへ入力する業務が 一定量あるのであれば、文書の種類を問わず同じアプローチが適用できます。 状況をお知らせください。適用可能性の検討からご一緒します。