【2021年版】Azure/GCP/AWS OCRサービス比較

## はじめに
### 概要
AzureのOCR機能のレビュー記事を書いた際に、他のクラウドベンダーのOCRサービスとの比較についてお問合せ頂きました。
以下のレビュー記事です。
- [AzureのOCR機能(Cognitive Service Read API v3.2)が日本語対応したので使ってみた](https://qiita.com/c-makitahiroki/items/e3e4a52eb2b92a15fd22)

今回は、主要なパブリッククラウドであるAzure/GCP/AWSのOCRサービスについて比較してみましたので紹介したいと思います。

### この記事の想定読者
クラウドが提供するOCR機能に興味のある方
どのクラウドサービスを導入しようか迷われている方

## 各社サービスの機能比較
Azure/GCP/AWSが提供するOCRサービスの比較を一覧表にまとめました。
※2021/5/17時点で最新のバージョンを使用して検証しています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/268929/01afd43d-4a4b-7f87-754b-2d698e58ec07.png)
対応言語数、価格ではAzureが一歩リードしているように思います。
対応ファイル数はGCPが多く対応していますが、マイクロソフトも実用上問題ないレベルでカバー出来ているかなと思います。
AWSは他と比べて全体的に機能が弱いなという印象です。

ここからは、実際のデータを使って、OCRの認識精度や機能について詳細に比較していきたいと思います。
AWSのOCR機能は日本語未対応とのことで、**AWSのOCR機能は比較対象外**とします。

## 認識精度
### 精度検証データ
精度検証用のデータとして以下のデータ使用しました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/268929/afa8921f-28b4-c608-c9d3-083e959c178d.png)
IPAで公開されている情報システム・モデル取引・契約書のテンプレートを基に作成した自作データです。
総文字数は1149文字で、言語は日本語、英語が含まれています。また、文章だけでなく表形式の記述が含まれている点が特徴です。

### 精度検証結果
今回は「文字認識率」と「ノイズ数」の2つの視点から精度評価を実施しました。
検証の結果、今回の検証データでは精度はAzureの方が良い結果となりました。

||Azure|GCP|
|---|---|---|
|文字認識率|**99.74%**|99.48%|
|ノイズ数|**3文字**|22文字|

- 文字認識率(%)…正しく認識された文字数 / 検証画像の総文字数 * 100
- ノイズ数…検証データに含まれない文字を文字として認識した数

文字認識率はAzureもGCPともに精度は非常に高く僅差でAzureの方が良い結果でした。
ノイズ数はAzureの方が良い結果となりました。GCPの方がノイズが少し多めで、バグの様な出力も見られました。
以下で、具体的な事例をいくつか紹介したいと思います。

### 文字誤認識の例
まずはAzureのOCR機能(Read API)の誤認識の例です。
`ベンダ`とOCRしてほしいところを`"ペ"ンダ`とOCRしています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/268929/80607299-9c13-5892-3801-d407241b44fe.png)
次にGCPのOCR機能(Vision API)の誤認識の例です。
`住所`とOCRしてほしいところを`主  PF`とOCRしています。
`所`が`PF`とOCRされているのは少し笑ってしまいました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/268929/51e77a51-ec4a-d5b1-2639-83017d62484a.png)
Azure、GCP共に、別の箇所では正しく「ベンダ」「所」と認識できていたりするので、常にこの様な認識になるわけではありません。
### ノイズの例
まずはAzureのOCR機能(Read API)のノイズの例です。
文字以外に、〇の記号があるのでそれが影響しているような気がします。
AzureのOCRで見られたノイズは大体このパターンでした。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/268929/06cffeab-ee6f-f0bc-ac28-371d0073ae25.png)

次にGCPのOCR機能(Vision API)のノイズの例を2つ紹介します。
1つ目ですが、準委任の準の前に`「`が認識されています。
表形式になっているところでこのパターンが多くみられました。表を構成する格子を誤認識しているようです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/268929/aadf8071-e3c0-80da-ff66-f34a02530127.png)
続いて2つ目です。
何もないところに`0 0 0 0 0 0`が認識されています。これは何かしらのバグの様な気がします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/268929/a3af0959-16ab-be96-1520-124df430a483.png)
### (参考)AWS Textractの認識精度
ちなみに、AWSのOCR機能(AWS Textract)についてもOCRを実施してみました。
日本語に関しては全然OCR出来ないことを改めて確認しました…。（日本語対応していないので当たり前ですが…。）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/268929/5fea2be9-128f-bd0a-4ad4-faf485a26b74.png)
濃い灰色の部分が認識できている個所です。この例では、`な`が認識されているように見えますが、OCR結果は意味不明な記号でした。
AWSの名誉のために。英語のドキュメントに対してはAzue、GCPと同等レベルに精度良く検出出来ています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/268929/6f72b278-345b-30e7-4f87-6c463759575a.png)

## 頑健性
スキャンに失敗して傾いたようなデータに対しては、Azure、GCPどちらも問題なく検出できています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/268929/e51002cb-be0a-a172-66e0-f62658003e9f.png)
## 自然な読み取り順序
段組みデータに対して、Azureは自然な読み取り順序でOCR出来ていますが、GCPは対応出来ていません。
青色の番号がOCRの出力順です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/268929/ff38fff8-87f9-a35e-824e-9005ac858e54.png)
AzureのOCR機能(Read API)は、段組みデータの左半分をOCRした後に右半分をOCRしています。
GCPのOCR機能(Vision API)は、段組みデータに対応できておらず、左上から右下方向にZ型でOCRを実施しています。
## まとめ
今回は、主要なパブリッククラウドであるAzure/GCP/AWSのOCRサービスについて比較してみました。

Azure、GCP共に高い精度で文字認識が出来ていることが分かりましたが、ノイズが少ない点、自然な読み取り順序でOCR出来る点で、機能的にはAzureの方が優れていると感じました。
また、コスト面や対応言語数の多さではAzureがリードしており、総合的に見てもAzureのOCR機能(Read API)が優れていると思います。
OCRサービスをご検討の方はまずAzureのOCR機能(Read API)を試して頂くのが良いのではないでしょうか。