UUUO Tech Blog

水産流通のDXや業務効率化を実現するアプリケーション「UUUO」「atohama」を開発・展開している株式会社ウーオのテックブログです。プロダクトにまつわる様々な情報発信を行います。

OCR/AI を用いた FAX の読み取りによる商品掲載自動化の仕組みづくり

こんにちは! ウーオのソフトウェアエンジニアの髙橋(@yt_hizi)です 👋 今回は OCR/AI のプロダクトへの適用事例について紹介します。

tl; dr

  • 入荷案内の PDF は毎日複数社から届き、これを入力するのに大変な時間がかかる
  • Azure の Document Intelligence を用いて入荷案内情報を OCR で解析し効率化した
  • OCR をプロダクトに組み込む際は、業務に沿った形でデータを変換することがプロダクトの価値になる

ウーオは日々の入荷案内を全国に届ける

市場では日々、さまざまな魚が取引されています。日によって市場にある魚の種類が違えば量も違います。 そういった情報を、市場の事業者は「入荷案内」という形で1つのドキュメントにまとめて、取引先に入荷情報を伝えます。 取引先は、入荷情報を見てどの魚をどれだけ買おうか、というのを日々判断して購入し、これが最終的に私たちの食卓に届くわけです。

そんな入荷案内は、市場の事業者の取引先であるウーオにも日々届きます。 ウーオは各社から届く入荷案内に載っている情報を、市場の事業者の代わりに水産マーケットプレイスである「UUUO」に掲載し、全国のお客様が買えるようにしています。

これだけでも全国のお客様にとっては大きな価値となりうるのですが、日々入荷案内は複数社から届き、各社の入荷案内には約50商品ほどが掲載されています。

これら全てをアプリに掲載するために人力で入力すると、毎日数時間をこのために使うことになってしまいます。これでは効率が良くないので、なんとかしようというのが今回のプロジェクトです。

OCR サービスの選定

こちらは実際に FAX で届いた入荷案内情報です。

水産事業者から届いた実際の入荷案内 (黒塗り部分は筆者によりマスク済みです)

今回は、 PDF に記載の表を表形式のまま扱う必要があります。

単純な文字認識の OCR であれば、Google が提供する Cloud Vision API や、 Microsoft が提供する AI Vision (Read API) などが提供されています。これらはドキュメント内の座標と文字列のセットが解析結果として取得できるので、表形式データに変換したい場合は PyMuPDF などのライブラリを用いる必要があります。

一方で、表形式のまま読みとれるサービスも複数存在し、GoogleDocument AI や、MicrosoftAzure AI Document Intelligence、LINE の LINE WORKS OCR などが提供されています。

今回は開発期間が限られていることや筆者自身の知見がまだ少ないことから、表形式の読み取りまで1サービスで完結できる後者のサービス群から選定することにしました。

Google: Document AI

今回は、あらかじめ用意されたプロセッサである Form Parserを検証しました。 文字認識の精度は決して悪くないものの、表部分の抽出がうまくいかないことが時々あるなど、先述の他サービスに比べると今回のユースケースには合わないことがありそうと判断しました。

LINE: LINE WORKS OCR

こちらは「定型書類OCR」「特化型OCR」「全文認識/表抽出OCR」の3種類の OCR 機能が提供されていますが、今回は「全文認識/表抽出OCR」を用いました。 文字認識精度は高く、表部分の抽出もほとんど間違いなく抽出できていました。一方、価格面では他社サービスよりも高く利用には至りませんでした。

Microsoft: Azure AI Document Intelligence

表形式のまま読み取る場合は、あらかじめ用意されたモデルである「prebuilt-layout」を使用するか Custom extraction model を使用することになります。 prebuilt-layout モデルの性能はおおむね LINE WORKS OCR と同程度の印象でした。 一方、 Custom extraction model を使うことで教師データを利用して学習させることで、表形式に対してより高い精度での認識が見込めました。

今回解析対象の表は必ずしも同じ列の組み合わせではなく、以下のような4~5パターン程度の列の組み合わせを読み取れる必要がありました。

列の組み合わせのパターン

そこで、 Custom extraction model を用いて複数パターンのドキュメントを教師データに用いることで、全てのパターンにおいて統一的な列の組み合わせで解析することができました。 元々、列の組み合わせの違いは Web アプリケーション上で吸収することを想定していたので、この工程が自動化されるのは工数削減につながると判断しました。

以上の検証から、 Azure AI Document Intelligence の Custom extraction model を用いて開発を進めることにしました。

なお、これらの検証結果は解析対象のドキュメントの状態に強く依存するため、必ずしもこのような比較結果にならないことはご留意ください。

FAX受信から「UUUO」に掲載するまで

取引先からの入荷案内は、インターネット FAX サービスを経由して受信し、それを Azure AI Document Intelligence を用いて解析を実施し、商品情報として扱えるようにデータを変換して、最後は人力で確認して商品情報の掲載を行います。

インターネットFAXサービスからの受信

利用するインターネット FAX サービスによっては Web API を公開しており、Web アプリケーションへの組み込みが容易に実現できるようになっています。詳細な実装は割愛しますが、Web アプリケーション側で定期的に新着の FAX を確認し、未解析のFAXがあった場合のみ解析を行うような仕組みをとっています。

Azure AI Document Intelligence による解析

入荷案内の FAX の解析は、Azure AI Document Intelligence の Custom extraction model を用いて実施します。

事前に Document Intelligence Studio というサービスを用いて、Custom model の構築を行います。これにより、GUI 上で教師データとなる PDF のアップロード、レイアウト解析、ラベリングなどを行うことができます。

教師データの登録が終わったら、画面右上の「Train」から Custom model を作成することができます。 Custom model の作成時には Neural または Template の2種類から選択できますが、検証の結果 Template の方がより表形式の読み取り精度が高かったことから、Template を採用しました。

Template を用いた Custom model の作成は一般的に10分以内には完了しますが、教師データの数などに依存する可能性があります。 Custom model の作成が完了すると、画面左側のメニューにある「Test」から、実際に作成したモデルの動作確認が実施できるため、Custom model の作成と検証を行き来しやすい設計になっています。

Azure AI Document Intelligence Studio の画面

こうして作成したモデルを、Rails アプリケーションから API を用いて利用することができます。 Azure portal 上で作成したリソースごとに割り振られる URL に対して、以下のようなAPIエンドポイントを呼び出すことによってカスタムモデルを簡単に利用することができます。 APIのリクエストボディには、ドキュメントの URL またはバイナリデータを Base64エンコードした文字列を渡すことで解析対象のドキュメントを渡します。

https://example-resource.cognitiveservices.azure.com/documentintelligence/documentModels/example-custom-model:analyze?api-version=2023-10-31-preview

解析を実行するAPIを呼び出すと、解析が開始されます。この時点で API レスポンスとして解析結果が返ってくるわけではなく、別の API から解析結果を取得することになります。 この解析結果の取得用の URL は以下のようなエンドポイントで、上記の API のレスポンスヘッダに operation-location として含まれます。

https://example-resource.cognitiveservices.azure.com/documentintelligence/documentModels/example-custom-model/analyzeResults/example-analyze-result-uuid?api-version=2023-10-31-preview

解析結果が取得できるまでには数秒程度かかるため、解析結果が取得できるまで1秒ごとにポーリングするようにしています。 (ドキュメントによると、最小1秒間隔でのポーリングが推奨されているため、今回は最小間隔である1秒としました。)

解析結果は JSON で取得することができ、Custom model による解析結果はdocuments の中に含まれます。

{
  "status": "succeeded",
  "createdDateTime": "2024-02-03T03:00:00Z",
  "lastUpdatedDateTime": "2024-02-03T13:00:00Z",
  "analyzeResult": {
      "apiVersion": "2023-10-31-preview",
      "modelId": "example-custom-model,
      "stringIndexType": "textElements",
      "content": "...",
      "pages": [...],
      "tables": [...],
      "styles": [...],
      "documents": [...],
      "contentFormat": "text"
  }
}

詳しい API の利用方法については公式のドキュメントをご覧ください。

learn.microsoft.com

データの変換

先述の通り、解析結果の JSON には Custom model によって抽出された表データが含まれます。その他、あらかじめ用意された prebuilt-layout の解析結果や、よりプリミティブな座標情報とテキストデータのセットのデータも返却されますが、今回は Custom model によって抽出された表データのみを用います。

OCR を使う以上、その読み取り結果を完全に信頼することはできません。その上で、読み取られたデータを実際のデータモデルに合致するように変換していく必要があります。

たとえば、OCRで読み取られた魚種名「ぶり」は、DB で管理されている魚種「ブリ」にマッピングする必要があります。この場合は、単純にカタカナに変換することで実際の魚種データと合致させることができます。

他にも、魚種の規格は「1入3kg」「4kg3入」「3入4/5kg」などと表現されます。例えば、「4kg3入」は「1つの発泡スチロールの箱の中に魚が3尾入っており、それらの合計の重さが4kgである」という意味になります。このうち、発泡スチロールの箱(単に「箱」「ケース」といいます)に何尾入っているか(「入数」といいます)と、箱全体の重さがどれだけあるのか(「箱目方」といいます)といった情報に分解する必要があります。入数は購入者に対して1尾あたりの重さ(目方)を伝えたり、箱目方はお客様が実際に支払う金額の計算に使ったりします。

このように、OCR によって出力されたテキストデータと、実際の業務で扱えるレベルのデータにはギャップがあります。上記の例はほんの一部で、このようなギャップを埋めていくことで、プロダクトに組み込まれたOCR機能が真に価値を発揮するのだと考えています。

出品者用サイトでの入力

出品者用サイトでは、解析が完了した FAX の一覧から入力対象を選択し、入力フォームに反映します。 以下は、解析結果を入力フォームに反映した状態です。商品数は60程度、各商品ごとに10項目程度存在するため、およそ600箇所の入力を確認していくことになります。 すべての項目をチェックしていくのは限界があるため、事前にバリデーション処理をかけることで入力内容の修正や確認が必要な項目をハイライトし、チェックすべき項目が一目でわかるようになっています。 データの修正/確認が完了したら出品を行います。これで、FAX に掲載された入荷情報が UUUO アプリ上に出品され、全国のお客様が購入できるようになります。

Sellers Web でのデータ修正

今後の展望

ルールベースのデータ変換のカバー率を改善する

データ変換の実例は先述のとおりですが、まだまだ対応できていないケースも存在します。プロダクトにOCRを組み込むときに最も価値が出るのはこの部分なので、特に注力していくべきだと考えています。

OCR エンジンによる認識精度を継続的に向上させていくための仕組み作り

ウーオにとって、OCR 技術を用いた機能はこれまでに開発経験がありませんでした。つまり、OCR 技術や今回利用した Azure AI Document Intelligence に対する知見はまだ浅い状態です。いかに精度を上げるか、という部分や精度を継続的に計測できる仕組みなどの構築を目指します。

他社の入荷案内への対応

今回はある1社への対応をベースに紹介させていただきましたが、他にも複数社からそれぞれ異なるフォーマットで入荷案内が届いているのが現状です。これらも同じ仕組みで入荷情報を配信できるように対応を進めていく予定です。

最後に

今回は、 Azure AI Document Intelligence を用いたドキュメントの OCR と、そのプロダクトへの適用事例について紹介させていただきました。 OCR というとすでにコモディティ化し、誰でも扱える技術になっていますが、そこから AI を用いたドキュメントのレイアウト情報の解析などもこうしてサービスとして提供されていると、プロダクトへの提供価値の幅が広がるのが良いなと感じました。

ウーオには、今回のような Azure AI Document Intelligence のプロダクト導入や、Next.js の導入、Algolia の導入など社内にとって新しい技術を積極的に取り入れていく文化があります。単に技術を導入することが目的ではなく、それがプロダクトの価値になりうるという判断が前提にあるというのも、過去の記事をご覧頂ければお分かりいただけると思います。

このように、ウーオでは水産流通を革新するために、あらゆるアプローチをしています。ウーオの事業やプロダクト開発にご興味のある方はぜひ以下から詳細をご覧ください! カジュアル面談もお待ちしております 🙏

uuuo.co.jp

<業務委託スタート可>ソフトウェアエンジニア(Backend/Ruby on Rails) / 株式会社ウーオ

◆カジュアル面談はこちらから◆ / 株式会社ウーオ