OCR APIとは何か：文書認識をシステムへ連携する方法の完全整理

OCR APIとは、開発者が文書画像やファイルを定められた規格で送ると、認識されたテキストと各値の位置、信頼度を構造化された応答として受け取り、自社システムへそのまま接続できるようにしたインターフェースです。

OCR APIが必要な理由

画面に結果を表示するだけでは業務は減りません。

文書認識のツールを導入したのに担当者の仕事がそのままという場合があります。認識の結果が別の画面に表示され、担当者はその画面と業務システムを行き来しながら値を再び転記します。窓を二つ開いて片方から読み取りもう片方へ入力していた元の作業がそのまま残ったわけです。自動化ではなく確認の段階が一つ増えた状態に近くなります。

認識の結果が既存システムへ流れ込むには、人ではなくプログラムが受け取れる形でなければなりません。OCR APIはその通路です。文書を送れば値と位置と信頼度が構造化されたデータとして返り、そのデータが審査システムや文書管理システムへ直接渡ります。

OCR APIの正確な定義：構築型と何が違うのか

API連携と構築型導入、三つの軸の違い

第一に、対象が異なります。API連携は認識の機能のみを対象とします。要求と応答の規格を合わせれば足り、モデルがどこでどう動いているかには関与しません。構築型はモデルと推論環境、ストレージ、運用ツールまでを対象とします。顧客の社内に一つのシステムを立ち上げる作業に近くなります。

第二に、目標が異なります。API連携の目標は素早くつないで性能と適合性を確認することです。初期検証の段階で文書を数種類投げて結果を受け取るのに数日あれば足ります。構築型の目標は文書の原本を外部へ出さずに運用規模の処理量を支えることです。

第三に、成果指標が異なります。API連携では応答の精度と遅延時間、処理量の上限を見ます。構築型ではこれに加えて必要な演算装置の仕様、閉域網での設置可否、モデル更新の手続、監査ログの要件を併せて見ます。実際の運用で確認された数値を挙げると、API方式の認識精度が99.3%水準と確認された事例があり、処理性能は100枚で3.5分、500枚で17分、毎時およそ1,800枚規模が測定されました。

二つの方式は置き換えの関係にはありません。初期検証はAPIで素早く進め、運用の段階で構築型へ移す経路が一般的です。したがって検討の段階で確認すべきは、APIの性能だけでなく同じエンジンを構築型でも提供しているかどうかです。

業務に投入できるOCR APIの6つの条件

実際の連携に入る6つの条件

第一に、応答スキーマが業務基準で定義されていることです。文字列を一かたまりで返す応答ではシステム入力を自動化できません。文書種別ごとにどのキーにどの値が入るかが事前に定義されていて初めて、受信側の開発が可能になります。

第二に、値の位置と信頼度が併せて返ることです。各値に対して原文の座標と確信の度合いが付いてくれば、信頼度の低い項目だけを検収画面へ表示する構成が可能になります。この二つのフィールドがなければ結局は全件検収へ戻ります。

第三に、対応形式が実際の受付ファイルを覆うことです。業務の現場にはPDFと画像だけが届くわけではありません。韓国製ワープロ文書やオフィス文書、表計算、スキャン画像が併せて受け付けられます。対応の一覧にこれらの形式が含まれているかの確認が必要です。

第四に、大量処理の経路があることです。件別の同期呼び出しのみが提供されれば、月末や特定の時間帯に集中する物量を支えられません。バッチ処理と作業状態の照会、完了通知のためのコールバックが併せて提供されるかをご確認ください。

第五に、認証と権限の管理が備わっていることです。文書には個人情報が含まれるため、キーの発給と回収、呼び出し履歴の記録、役割別のアクセス制御が必要です。金融と公共では監査対応のためにこのログが求められます。

第六に、構築型の併行提供の可否を確認することです。今はAPIで足りても、保安要件が強化されるか処理量が増えれば社内設置が必要になります。そのときにエンジンをまるごと変えずに済むかが導入判断の重要な基準になります。

OCR APIの実際の適用方法

連携の地点をまず定めます

設計の最初の決定は、認識の結果をどこへ差し込むかです。文書管理システムへ原本と併せて格納するのか、審査システムの入力項目へ直接入れるのか、自動化ツールを経て基幹系へ送るのかによって必要な応答の形が変わります。

実際の運用構成を見ると、認識の結果が文書管理システムへ格納され、その後に自動化ツールを経て基幹システムへ登録される流れがよくあります。この接続が設計されていなければ担当者が結果を再入力することになるため、連携地点の定義を認識性能の検証より前に置くほうが適切です。

要求と応答の規格を合わせます

典型的な構成はファイルのアップロード方式の要求と、構造化された応答の組み合わせです。文書を送ると形式変換とレイアウト解析、文字認識、後処理を経て結果が生成され、テキストと位置情報、信頼度が併せて返されます。結果の形式は用途に応じて分けて受け取るほうが適切です。システム入力が目的であれば項目経路をキーとする構造化データで、検索と生成に用いる文書であれば構造の保たれたマークアップ形式で受け取ります。

大量処理では作業の単位で要求を登録し状態を照会する方式が安定します。完了の時点を知らせるコールバックを併せて用いれば、受信側でのポーリングの負担を減らせます。

エラー応答と再試行の規則を定めます

連携で成功の経路より手のかかるのは失敗の経路です。ファイルが開かない場合、形式が対応外の場合、ページが空の場合、処理中に時間が超過した場合が、それぞれ異なる対応を求めるためです。

設計で定めるべきは三つです。まずどのエラーが再試行で解決するかを区別します。一時的な資源の不足は再送すれば済みますが、対応していない形式は何度送っても同じ結果になります。次に再試行の間隔と回数を定めます。最後に再試行でも解決しなかった案件をどこへ積むかを定めます。この待ち行列がなければ失敗した文書が静かに消えます。

国内環境におけるOCR API

韓国の金融と公共の組織の相当数はネットワーク分離規定の適用を受けます。業務網から外部APIを呼び出せないため、公開されたクラウドAPIのみを提供するソリューションは検討の初期に除外される場合が多くあります。社内網にAPIサーバーを立てる構成が可能かをまずご確認ください。

文書形式にも国内の条件があります。韓国製ワープロ文書が実際の処理対象に含まれるか、ファクスで受け付けた低画質のスキャンでも応答の品質が保たれるかを実際のファイルで確認するほうが適切です。公開された例示文書で測定した値と自社の受付箱の文書で測定した値は異なる結果になります。

よくあるご質問