FAX OCRとAIで送信元判別・全文検索――アドレス帳照合でAPI費用を抑える設計

今回のFAXシステムで、特に重要だった機能が送信元判別と全文検索です。

受信FAXをPDFとして保存するだけなら、過去の原稿は日付やファイル名で探すしかありません。

OCRで本文をテキスト化すれば検索できますが、すべての原稿を無条件にAIへ送り、全文OCRする方法には、費用とデータ取り扱いの問題があります。

また、FAX番号を一つ読み取れたからといって、それが送信元とは限りません。

FAXの送信元情報は一つではない

受信FAXから得られる可能性がある情報には、次のものがあります。

実際の受信では、HylaFAX側の送信元番号がNULLで、REMOTE TSIも空というケースがありました。

そのため、Caller IDやTSIだけで送信元を決める設計にはできませんでした。

原稿全体を最初からOCRしない

FAX原稿では、会社名、電話番号、FAX番号、日付などが上部や下部、四隅付近に配置されることが多くあります。

そこで、最初の段階では原稿全体ではなく、四隅・上部・下部などの周辺領域を対象にOCRします。

受信FAX
  ↓
四隅・上部・下部など周辺領域だけOCR
  ↓
番号候補を抽出・正規化
  ↓
自社アドレス帳と照合
  ├─ 一致候補が1件以上
  │      ↓
  │  設定ページ数まで全文OCR
  │      ↓
  │  分類・要約・全文検索・検索可能PDF
  │
  └─ 一致候補なし
         ↓
     原本は保存、全文OCRは自動実行しない

この段階の目的は、文書内容を完全に読むことではありません。ページ全体を送る前に、処理対象として業務価値が高い可能性があるかを判定します。

アドレス帳に登録された取引先と結び付く番号候補があるかを確認することです。

番号を正規化して比較する

FAX番号は、同じ番号でもさまざまな形式で書かれます。

• 0957-xx-xxxx
• 0957 xx xxxx
• 0957(xx)xxxx
• +81-957-xx-xxxx
• 81957xxxxxx

文字列のまま比較すると一致しません。

照合前に、次の処理を行います。

1. 全角数字を半角へ変換する
2. ハイフン、空白、括弧などを除去する
3. 国番号81と国内先頭0を統一する
4. 桁数が不自然な候補を除外する
5. 自社のFAX番号を候補から除外する
6. アドレス帳側も同じ形式へ正規化する

OCRでは、数字の0と英字O、1とIなどの誤認識もあります。候補を抽出する段階で、文脈と桁数を考慮する必要があります。

全文OCRを実行する条件

設計を進める中で、全文OCRの実行条件は何度か見直しました。

最終的な考え方は次のとおりです。

四隅・周辺OCRで抽出した番号候補のうち、アドレス帳に一致する候補が1件以上あれば、設定ページ数まで全文OCRを実行する。

ここで重要なのは、送信元が一社に完全確定している必要はないという点です。

• 送信元が未確定でも、アドレス帳一致候補があれば全文OCRする
• 一致候補が複数あっても、1件以上あれば全文OCRする
• Caller IDやTSIが空でも、原稿内番号が一致すれば全文OCRする
• 番号候補があっても、アドレス帳に一致しなければ全文OCRしない
• 送信元らしい番号があっても、アドレス帳未登録なら自動で詳細処理しない

つまり、全文OCRを実行する判断と、取引先を自動確定する判断を分けています。

一致候補が複数ある場合に全文OCRは実行しても、取引先を一社へ断定しないことがあります。

なぜアドレス帳一致を条件にしたのか

すべての受信FAXを全文OCRすれば、実装は単純です。

しかし、次の問題があります。

• AI APIの利用量が増える
• 広告や不要FAXまで処理する
• ページ数の多いFAXで費用が膨らむ
• 外部APIへ送る文書量が増える
• OCR失敗データが検索インデックスへ大量に入る

自社アドレス帳と結び付く可能性が高い文書を優先することで、業務上の価値が高いFAXへ処理を集中できます。

OpenAI APIの利用料だけでなく、外部APIへ送る画像量と、後から誤った検索データを修正する運用コストも減らせます。

全文OCR後に行う処理

全文OCRを実行したFAXでは、次の情報を保存します。

• OCR本文
• 抽出した会社名・担当者名
• 電話番号・FAX番号候補
• 文書日付
• 分類候補
• 短い要約
• 検索用キーワード
• OCR処理状態とエラー

Web画面では、取引先名、FAX番号、受信日、分類、OCR本文から検索できます。

「いつ届いたか分からないが、商品名や文章の一部は覚えている」という場合でも、本文検索から原本PDFを開けます。

検索可能PDFとデータベース検索を分ける

検索可能PDFを生成すれば、PDFビューア側でも文字検索できます。

一方、一覧画面で複数のFAXを横断検索するには、OCR本文をデータベースへ保存する必要があります。

• 検索可能PDF：一つの原稿内を確認する
• データベース全文検索：すべての受信FAXから探す

両方を用意することで、一覧から候補を絞り、原本内で該当箇所を探す流れにできます。

アドレス帳はOCR精度を補う業務マスタ

アドレス帳は単なる送信先一覧ではありません。

送信元判別の基準として、次の情報を持たせます。

• 会社名
• 部署名
• 担当者名
• 代表FAX番号
• 支店・部署のFAX番号
• 電話番号
• 番号の旧表記や別番号

新しい取引先から届いたFAXは、アドレス帳に番号がないため、全文OCR条件を満たさない場合があります。

そのため、アドレス帳へ番号を追加した後に、過去FAXを再判定できる仕組みが必要です。

一度失敗した結果を永久に固定せず、マスタの更新に合わせて再処理できるようにすることが重要でした。

AIに最終判断を任せすぎない

AIやOCRは、候補を出すためには有用です。

しかし、FAXには誤送信のリスクがあります。

原稿内に書かれた番号が、返信先ではなく問い合わせ先や別部署の番号である可能性もあります。

そのため、次の処理は人間の確認を残します。

• 取引先候補が複数ある場合の確定
• 返信先FAX番号の選択
• OCR結果の修正
• 送信直前の宛先確認
• 重要文書の分類確定

自動化の目的は、人間を判断から外すことではなく、探す・転記する・開くという作業を減らすことです。

外部APIを使うときの考え方

FAX原本と検索データは自社サーバーへ保存していますが、AI OCRに外部APIを利用する場合は、文書画像やテキストが外部へ送信されます。

そのため、次を整理しておく必要があります。

• どの文書を送るか
• 何ページまで送るか
• 送信前に除外すべき情報があるか
• API事業者のデータ取り扱い条件
• 処理履歴と失敗時の再送
• APIキーの保管方法

「オンプレだから外部へ一切出ない」ではありません。

業務データの保管主体を自社へ置きながら、必要な処理だけ外部サービスを利用するハイブリッド構成です。

まとめ

FAXを検索可能にするには、OCRを実行するだけでは足りません。

Caller ID、TSI、原稿内番号、アドレス帳を別々の情報として扱い、候補と確定を分ける必要があります。

今回のシステムでは、四隅・周辺OCRで得た番号候補の中にアドレス帳一致が1件以上あれば、設定ページ数まで全文OCRを実行します。

この条件により、送信元が完全には確定していないFAXも検索可能にしつつ、無関係な文書へのAPI利用を抑えています。

次回は、受信FAXをタブレットで開き、手書き、テキスト、スタンプを追加して、そのまま返信できるようにした編集・送信機能を紹介します。