Google Document AI で文書画像からフォーム要素（キー名とその値）を抽出する

本記事では、Document AI の汎用的な Form Parser を利用した簡単な実験を通して、文書画像から抽出できる情報を見ていきます。

【目次】

• ［１］はじめに
• ［２］実験準備
• （１）環境準備
• （２）フォーム解析結果のデータ構造
• （３）本記事で利用するユーティリティ関数
• ［３］Google のサンプル画像解析例
• （１）画像データの準備
• （２）解析の実行と結果確認
• ［４］Google フォームの画像解析例
• （１）画像データの準備
• （２）解析の実行と結果確認
• （３）修正した画像で解析の実行と結果確認
• ［５］表形式の画像解析例
• （１）画像データの準備
• （２）フォーム解析の結果確認
• （３）Google Knowledge Graphとの関係
• ［６］罫線のない表形式画像の解析例
• （１）画像データの準備
• （２）解析の実行と結果確認
• ［７］最後に

［１］はじめに

OCR（Google ならVision APIなど）を利用すると、画像から文字を抽出することができます。小説のような文章中心の文書をスキャンする場合は、OCRの機能で十分な場合が多いと思います。

一方、例えば、請求書をスキャンする場合は、そこに書かれている全ての文字を列挙したいわけではなく、請求元や請求日、各金額などの必要な項目をコンピュータで再利用しやすい形式で抽出したい、ということではないかと思います。

つまり、請求書などのようなテンプレート（様式？、フォーム？）にそった文書をスキャンする目的は、そこに書かれている「文字」を抽出することよりも、そこに書かれている「情報」を抽出することだと思います。

（多くの場合、様式といわれるような文書は、アンケートのように、質問と回答のペア（キー／バリューで表現）で効率よく情報を取得できるように作られていると思います。）

Google の Document AI は、このような、文書画像から、OCRより一歩踏み込んだ情報を抽出することを目的としているようです。

• Document AI（https://cloud.google.com/document-ai）

また、Document AI の動機や技術的な仕組みは以下のブログで触れられています。

• Extracting Structured Data from Templatic Documents
• https://ai.googleblog.com/2020/06/extracting-structured-data-from.html
  

技術的な詳細はともかく、フォームなどの文書画像から構造データ（ここではキー／バリューのペア）を抽出しようとしています。興味津々です。

そこで、本記事では、Document AI の汎用的な Form Parser を利用した簡単な実験を通して、抽出できる情報を見ていきます。

なお、現時点（2021年7月）段階では、Document AIはまだ日本語に対応していません。このため、本記事では日本語文書ではなく自作のショボいサンプル画像で実験しています。

また、英語版では様式に特化したプロセッサも用意されていますが、今回は汎用のプロセッサを用いた実験としています。

最後に、本記事の実験内容のうち、抽出された情報の質？にはあまり深入りせず、Document AIが抽出する情報はどのようなものか（の雰囲気を知る）？という観点で見て頂ければと思います。

［２］実験準備

Document AI の解析結果をざっと知るだけであれば、以降にある本記事の画像や表を見て頂ければ雰囲気はつかめるかも知れません。

もし、実際に試してみる、という場合は、少々予備知識や準備が必要ですので、以下に簡単に書いておきます。

（１）環境準備

Document AI を利用するには、GCP（Google Cloud Platform）、クライアントライブラリなどの準備が必要です。

これらの詳細については、以下の記事を参照して下さい。

• Google Document AI の Python クライアントライブラリを利用して画像から表形式データを抽出する

この記事では、Google Document AIを利用するための準備作業、Pythonクライアントライブラリを利用したAPIの呼び出し方、そして文書画像に対するテーブル解析の結果を概観しています。

実は、フォーム解析もテーブル解析で利用したプロセッサ（Form Parser）を利用しますので、今回の記事と上記の記事の違いは、利用する解析結果フィールドの違いだけです。

このため、本記事にある実験用コードも、上記の記事で利用したコードを使います。

（２）フォーム解析結果のデータ構造

Document AI のデータ構造の概要については、同様に前の記事『Google Document AI の Python クライアントライブラリを利用して画像から表形式データを抽出する』の「［４］APIの仕様」を参照して下さい。

以下の図は、前の記事に書いたAPIのレスポンスデータの概要です。

本記事で注目する、Form Parser を利用したフォーム解析の解析結果は、Pageにある form_fields フィールドに格納されます。

そこで、FormFieldの構造を簡単に見ておきます。

• Pageの form_fields フィールドに 、抽出されたFormField 型のオブジェクトがリストで格納されます。
• 現状は、FormField以下にあるconfidenceの降順でソートされているようです。
• FormField
• キー（field_name）とバリュー（field_value）のフィールドがあり、それらはLayout型のオブジェクトです。
• field_nameとfield_valueの値（テキスト）は、text_anchor/text_segmentsのstart_indexとend_indexフィールドで与えられます。これは document.text の範囲（開始位置と終了位置）ですので、document.text から指定範囲の文字列を取り出して利用します。
• field_nameとfield_value それぞれにconfidence値があります。
• bounding_poly により、認識した矩形情報が得られます。
• value_type フィールドは、（現状では）以下の値が格納されるようです。
• ブランク
• 値は通常のテキスト
• unfilled_checkbox
• 値はチェックされていないチェックボックス
• filled_checkbox
• 値はチェックされているチェックボックス

（３）本記事で利用するユーティリティ関数

本記事では、記事『Google Document AI の Python クライアントライブラリを利用して画像から表形式データを抽出する』の「［６］Python クライアントライブラリを利用した解析サンプル」に書いた、以下の関数を再利用します。

• call_process_document
• load_image
• tables_to_htmlstr

加えて、本記事では主にFormFieldの内容を確認しやすくするため、FormFieldの内容をHTMLのTABLE形式に変換するユーティリティ関数を用意します。

この関数では、簡単のため、 PrettyTable を利用しますので、pipでインストールしておきます。

• PrettyTable
• https://pypi.org/project/prettytable/

pip install prettytable

＜FormFieldの内容をHTMLのTABLE形式に変換するユーティリティ関数＞

from prettytable import PrettyTable

def fields_to_htmltable(fields, doctext, strip=True, textout=False):
    t = PrettyTable(['id', 'Name', 'Value', 'Value Type', 'Confidence(Name)', 'Confidence(Value)'])
    for i, field in enumerate(fields):
        name = get_anchor_text(doctext, field.field_name.text_anchor)
        name_conf = round(field.field_name.confidence,4)
        value = get_anchor_text(doctext, field.field_value.text_anchor)
        value_conf = round(field.field_value.confidence,4)
        if strip:
            name = name.strip()
            value = value.strip()
        t.add_row([i,name, value, field.value_type, name_conf, value_conf])
    if textout:
        # コンソールにテキスト表示（主にデバッグ用）
        t.align["Name"] = "l"
        t.align["Value"] = "l"
        print(t)
    return t.get_html_string()

def get_anchor_text(doctext, anchor):
    txt = ""
    for seg in anchor.text_segments:
        txt += doctext[int(seg.start_index) : int(seg.end_index)]
    return txt

簡単で少々恥ずかしいコードですが、引数の strip と textout について少し補足します。

抽出される FormField のNameとValueのテキストは、空白文字や改行文字を含む場合があります。

実務での利用は、ケースバイケースでデータを成型する必要があると思いますが、今回の実験では、単純に文字列の前後の空白文字や改行文字を削除します。（strip=Trueがデフォルト。）

一方で、元のデータを確認したい場合もありますので、この場合は strip=Falseとして空白文字などの削除を行わない指定ができるようにしています。

さらに、本ブログ用にHTMLのテーブルタグ出力としていますが、実際のデータ確認には、コンソールへテキストで表示したほうが把握しやすい場合もあります。この場合、textout=True とすると、コンソールにテキストの表が出力されます。

［３］Google のサンプル画像解析例

まずは、Googleのチュートリアルにあるサンプル画像を題材に、解析結果をみていきます。

（１）画像データの準備

今回は、以下のサイトで利用している画像を利用します。

• Use Document AI to Intelligently Process your Handwritten Forms (Python)
• https://codelabs.developers.google.com/codelabs/docai-form-parser-v3-python#0
  

このサイト（Codelab）は、Document AI の Form Parser とPythonクライアントライブラリを利用して、HEALTH INTAKE FORM（問診表？）の文書画像から、質問事項とその回答を抽出する例が書かれています。

HEALTH INTAKE FORM の画像は以下のページで見ることができます。

• 4. Create and Test a Processor
• https://codelabs.developers.google.com/codelabs/docai-form-parser-v3-python#3
  

この画像ファイルのダウンロード方法は、以下のページにあります。

• 6. Download the Sample Form
• https://codelabs.developers.google.com/codelabs/docai-form-parser-v3-python#5
  

なお、gsutil ツールを使って、Google Cloud Storageからファイルをダウンロードする手順などについては、以下の記事も参考にしてください。

• Colaboratory環境でGoogle Cloud Storage(GCS)と連携する(gsutil,gcsfuse)

（２）解析の実行と結果確認

記事『Google Document AI の Python クライアントライブラリを利用して画像から表形式データを抽出する』の手順と同様に、解析を実行していきます。

（ダウンロードしたファイルの名前は「form.pdf」とします。）

# endpoint_url にはコンソールの予測エンドポイントに表示される値を設定する。
endpoint_url = "https://(Region)-documentai.googleapis.com/v1/projects/(省略):process"
# 画像を読み込む
image_content = load_image("form.pdf")
# 解析を実行
response =  call_process_document(endpoint_url,image_content,"application/pdf")

まず、抽出された文字列全体を確認します。（以下は、print(response.document.text)　の出力結果です。）

FakeDoc M.D.
HEALTH INTAKE FORM
Please fill out the questionnaire carefully. The information you provide will be used to complete
your health profile and will be kept confidential.
Date:
Sally
Walker
Name:
9/14/19
DOB: 09/04/1986
Address: 24 Barney Lane City: Towaco State: NJ Zip: 07082
Email: Sally, waller@cmail.com Phone #: (906) 917-3486
Gender: F
Single Occupation: Software Engineer
Referred By: None
Emergency Contact: Eva Walker Emergency Contact Phone: (906) 334-8976
Marital Status:
Describe your medical concerns (symptoms, diagnoses, etc):
Runny nose, mucas in thwat, weakness,
aches, chills, tired
Are you currently taking any medication? (If yes, please describe):
Vyvanse (25mg) daily for attention

語順や手書き文字の微妙な認識を除いて、かなり精度良く文字が抽出されていると思います。

しかしながら、この文字列から、質問と回答を抽出するのはなかなか大変です。

特に、Single と Marital Statusが分離しているところなど、語順が入れ替わってしまっているところは厳しいです。これは文字の画像上の位置関係も考慮しないと解釈できません。

ここまではOCRの範疇ですが、Form Parser が解釈する FormFieldの内容を見てみます。

（実行）

htmlstr = fields_to_htmltable(response.document.pages[0].form_fields, response.document.text)

この出力を貼り付けたものが以下の表です（border=1に設定しています）。

id	Name	Value	Value Type	Confidence(Name)	Confidence(Value)
0	Phone #:	(906) 917-3486		1.0	1.0
1	Emergency Contact:	Eva Walker		1.0	1.0
2	Marital Status:	Single		1.0	1.0
3	Gender:	F		0.9999	0.9999
4	Occupation:	Software Engineer		0.9999	0.9999
5	Referred By:	None		0.9999	0.9999
6	Date:	9/14/19		0.9999	0.9999
7	DOB:	09/04/1986		0.9997	0.9997
8	Address:	24 Barney Lane		0.9991	0.9991
9	City:	Towaco		0.9977	0.9977
10	Name:	Sally Walker		0.9973	0.9973
11	State:	NJ		0.9969	0.9969
12	Email:	Sally, waller@cmail.com		0.9963	0.9963
13	Zip:	07082		0.995	0.995
14	Emergency Contact Phone:	(906) 334-8976		0.9905	0.9905
15	Are you currently taking any medication? (If yes, please describe):	Vyvanse (25mg) daily for attention		0.922	0.922
16	Describe your medical concerns (symptoms, diagnoses, etc):	Runny nose, mucas in thwat, weakness, aches, chills, tired		0.8795	0.8795

これは驚きです！。

Googleが提供するサンプルなので精度が良いことは予想できますが、ここまで解釈ができるとは思いませんでした。

私として、特に興味深い点を書いてみます。

• FakeDoc M.D、HEALTH INTAKE FORM、Please...の説明文は無視されています。
• これらはキー／バリューの有意な対応が認識できないということかも。
• Name、Value にそれぞれConfidence値があり、昇順にリストされています。
• とはいいつつ、私が試した範囲では、NameとValueのConfidence値は同じ値ばかりでしたけど。。。
• Value Type は全てブランクなので、値はテキストという扱いです。
• Name, City, Zip など、一般的な単語をキー（Name）として値を対応付ける解釈は理解しやすいですが、Are you currently …?やDescribe your medical ...のような疑問文や命令文もNameとValueに切り出されているのは凄いです。
• NameやValueの値には、空白文字や改行文字も含まれています。
• 実務で利用する場合は、項目に応じてトリミングなどの処理が必要と思います。この例では、値の両端以外に、NameのSallyとWalkerの間に改行文字が入っています。
• フィールドの内容によっては、利用できない文字を含む場合もあります。
• この例では、Email値に、メールアドレスには利用できない文字が含まれています。実務で利用する場合は、誤認識の可能性のある項目として表示して確認を促すような対策が必要かもしれません。（但し、これはDocument AIの範疇を超えている気がします。）
• また、Confidence値が一定の値より低い場合なども同様の対応が必要かもしれません。

入力画像が、今回の「HEALTH INTAKE FORM」様式であることが分かっていれば、専用アルゴリズムを作って、OCRの情報から上記のフォーム要素を抽出することは可能なような気がしますが、これは汎用的なForm Parserによる解析結果だということを考えると、これは凄いと思いました。

また、ここまでくると、様式特化したOCRの解析アルゴリズムを必死で考えるより、Form Parser の結果を様式に応じて補正などを行うほうが良いのではないか？と考えてしまいますね。。。

［４］Google フォームの画像解析例

（１）画像データの準備

フォームといえば「Google フォーム」ということで、Google フォームで作ったフォームの画像を解析してみることにしました。

• Google フォーム
• https://www.google.com/intl/ja_jp/forms/about/
  

とはいいつつ、Google フォームのアンケート画面を画像化して解釈することは、まずありえないと思います。（オンラインで簡単に回答結果を集計するために利用するようなものですから、画面を印刷する必要がそもそもない（笑））

このため、解析サンプルとしては不適切というか、現実的ではないと思いますが、Document AI の解析への興味から試してみることにしたものです。

下図は、Googleフォームで作成した画像です。

この画像をダウンロードして、ファイル名を「gform.jpg」とします。

（２）解析の実行と結果確認

解析を実行します。

# endpoint_url にはコンソールの予測エンドポイントに表示される値を設定する。
endpoint_url = "https://(Region)-documentai.googleapis.com/v1/projects/(省略):process"
# 画像を読み込む
image_content = load_image("gform.jpg")
# 解析を実行
response = call_process_document(endpoint_url,image_content,"image/jpeg")

まず、抽出された文字列全体を確認します。（以下は、print(response.document.text)　の出力結果です。）

Name
Techno Daifuku
Are you ready?*
Yes
No
Which of the following devices do you use? (Check all that apply)
Desktop computer
Laptop computer
Smart phone
Other

期待通り、文字は完璧に抽出できています！

続いて、抽出されたFormFieldを見てみます。

htmlstr = fields_to_htmltable(response.document.pages[0].form_fields, response.document.text)

この出力を貼り付けたものが以下の表です（border=1に設定しています）。

id	Name	Value	Value Type	Confidence(Name)	Confidence(Value)
0	Laptop computer		unfilled_checkbox	1.0	1.0
1	Other		unfilled_checkbox	0.9999	0.9999

さらに、認識されたFormFieldのNameとValueの矩形領域を元画像に描画してみました。

（赤色がName、緑色がValueの値です。青色の数字はFormFieldのインデックス番号で、Nameは左寄せ、Valueは右寄せで表示しています。）

あれれ。。。

先ほどの問診表の例とは違って、FormFieldから質問に対する回答を殆ど得ることができません。

この結果をざっと見ると、

• 名前（Name）のフィールドが認識されません。
• Are you ready?のフィールドが認識されません。
• 「Which of the ...」のフィールドが認識されません。
• 一部のチェックボックスをNameとして認識しています。
• 「Laptop computer」と「Other」がNameとして認識され、Value Typeが「unfilled_checkbox」となっています。つまり、この２つはチェックされていないチェックボックス項目として認識されています。
• 一方で、「Desktop computer」と「Smart phone」は、Value Typeが「filled_checkbox」として認識されているわけではありません。

つまり、この例の場合、フォーム解析結果だけから理解できることは、「Laptop computer」と「Other」を利用していない、ということだけ。。。

「unfilled_checkbox」を認識しているところは凄いと思いましたが、意外な結果に。。。

例が悪いと言えばそれまでですが、この例を見ると、現状の Document AI の汎用 Form Parserがうまく解析できるものと、そうでないものがありそうです。

（３）修正した画像で解析の実行と結果確認

しかし、Googleサンプルと大きな落差を感じたので、もう少し深堀してみる気になりました。

Googleサンプルとの違いとして、キーとバリューの間隔が広い感じがしたので、下図のように間隔を少し詰めたレイアウトに変更して試してみました。

しかし、残念ながら、結果は同じでした。

そこで、次のような、つまらない仮説を立ててみました。

• Nameが認識できないのは、値となる「Techno Daifuku」が、名前として不適切なのかも。。。
• 有名人に変えてみる（例：Abraham Lincoln）
• Are you ready?が認識されないのは、ラジオボタンを認識できないという事なのかも。。。
• チェックボックスに変更してみる
• 「unfilled_checkbox」が認識できるのに、「filled_checkbox」が認識できないのは、「filled_checkbox」の画像（形？）が悪いのかも。。。
• チェック付きのチェックボックスの画像をシンプルなものに変えてみる。

これらを反映した以下の画像を作成して試してみました。

すると結果は、以下のように大きく変わりました！

＜FormFieldの認識結果＞

id	Name	Value	Value Type	Confidence(Name)	Confidence(Value)
0	Laptop computer		unfilled_checkbox	1.0	1.0
1	Other		unfilled_checkbox	0.9999	0.9999
2	Yes		filled_checkbox	0.9999	0.9999
3	No		unfilled_checkbox	0.9992	0.9992
4	Desktop computer		filled_checkbox	0.9955	0.9955
5	Name	Abraham Lincoln		0.7137	0.7137
6	Smart phone		filled_checkbox	0.6393	0.6393

＜FormFieldの認識領域＞

なんと、ほぼ全ての項目を認識しています！

• チェックボックスが認識できなかったのは、チェックの背景色の問題だったのかも。。。
• ラジオボタンは現状では認識できないのかもしれない。。。
• リンカーンは名前として妥当だが、Techno Daifukuは妥当ではないということなんでしょうか（号泣）。。。

考えてみると、ラジオボタンはソフトウェアの入力フォームではよく利用されますが、紙の様式に利用されることは無いように思います。

その意味では、Document AI の主な用途を考えると、チェックボックスが認識できれば十分なのかもしれません。

ところで、チェックボックスの状態が認識できるのは凄いのですが、情報取得という観点から気になる点として、質問（キー）項目は認識対象にならず、回答の文言がキーとなって、そのチェック状態が値となっています。

このため上記例だと、Yesにチェックが入っていることは分かりますが、それがどの質問に対するYesなのかを特定する方法がありません。今回の例の場合は、YesかNoを聞く設問が一つなので特定できますが、複数ある場合は迷います。

これに対しては、フィールドの位置関係から特定するとか、回答の文言に「Yes, XXX」など、何に対するYesかを特定する文言にするとか、何らか工夫が必要かもしれません。

［５］表形式の画像解析例

Form Parser は、FormFieldの解釈だけでなく、テーブル構造の解釈も行えます。

テーブル構造の解釈例については、以下の記事を参考にしてください。

• Google Document AI の Python クライアントライブラリを利用して画像から表形式データを抽出する

この記事はテーブル解析の結果に絞って書きましたが、実はテーブル解析結果と同時に、フォーム要素の解析結果（FormFieldの値）も設定されています。

ここでは、同じサンプル画像を用いて、抽出されたFormFieldについても見ておきます。

（１）画像データの準備

上記記事で利用した画像とテーブル解析結果を再掲します。

＜文字の抽出結果＞

Shopping List
Price
Date Description
2021/2/1 Sweets
2021/2/1 Bento
2021/2/2 TechnoDaifukucho
Total
$300.00
$1,000.00
$0.00
$1,300.00

＜テーブルの解析結果＞

Date	Description	Price
2021/2/1	Sweets	$300.00
2021/2/1	Bento	$1,000.00
2021/2/2	TechnoDaifukucho	$0.00
	Total	$1,300.00

＜テーブル認識領域＞

（赤色はヘッダ、緑色はボディ）

（２）フォーム解析の結果確認

tablesと同時に抽出されたFormFieldを見てみます。

htmlstr = fields_to_htmltable(response.document.pages[0].form_fields, response.document.text)

この出力を貼り付けたものが以下の表です（border=1に設定しています）。

id	Name	Value	Value Type	Confidence(Name)	Confidence(Value)
0	Total	$1,300.00		0.9669	0.9669
1	Bento	$1,000.00		0.8364	0.8364
2	Sweets	$300.00		0.6971	0.6971
3	Price			0.2176	0.2176
4	Description			0.1546	0.1546

表の情報からは、様々なキー／バリューペアの組み合わせを考えることができますが、フィールドとして何を優先して解釈したかというところに興味があります。

• Totalという単語に対して数値（金額）が対応するのは自然な気がします。。。
• その流れからか、同様にSweetsとBentoが数値（金額）が対応している？
• しかし、TechnoDaifukuchoは認識されていません。
• PriceとDescriptionがキーとして抽出されていますが、値は設定されておらず、また、Confidenceが低い値になっています。
• 実は値の文字列は設定されていませんが、値に矩形領域が設定されていました。これによると、Priceの値はDescriptionの矩形領域、Descriptionの値はSweetsの矩形領域を指しています（分かり難いですが、上図の矩形の番号の関係から見て取れます）。
• どのような判断で値をブランクにしたのかはわかりませんが、どのようにスコア（Confidenceの値など）を利用しているのかには興味が湧きます。。。

（３）Google Knowledge Graphとの関係

フォーム解析結果の Confidence値が最も高かったのが Total というのは分かりやすいのですが、その次が Bento、そして少し Confidence 値が下がって Sweetsと続いています。

さらに、同じような関係なのに、「TechnoDaifukucho」に至っては、抽出すらされていません（号泣）。

ところで、以下の資料を見ると、フィールドタイプの認識には、Google Knowledge Graph も利用されているようです。

• Extracting Structured Data from Templatic Documents
• https://ai.googleblog.com/2020/06/extracting-structured-data-from.html
  

そこで、Bento、Sweets、TechnoDaifukucho をGoogle Knowledge Graph Search APIを利用して検索してみることにしました。

結果としては、Bentoは立派な英語として通じる定義済みの単語であり、Sweetsは微妙で、TechnoDaifukucho に至っては、検索結果無しでした（笑）。

今回の抽出結果だけを見ると、ナレッジグラフのスコアがそのまま反映されたような Confidence 値になっていますが、次の項の実験結果を見ると、必ずしもそういうわけではないということが分かります。（難しい。。。）

（参考）Google Knowledge Graphの検索方法については以下の記事を参考にしてください。

• Googleナレッジグラフの検索APIを使ってみる（Google Knowledge Graph Search API）

（追記：2021/8/11）

抽出されたテキストに対して、Document AIのビルディングブロックの１つである Natural Language AI のエンティティ分析を行ってみたところ、Bento、Sweets、TechnoDaifukucho はエンティティとして認識されませんでした。よろしければ以下の記事も参考にしてください。

• Google Natural Language API を利用して固有表現とその付加情報（ナレッジグラフなど）を抽出する

［６］罫線のない表形式画像の解析例

表形式画像でも FormFieldが抽出されていることを見ましたので、逆に、罫線が無い表形式文書でもテーブル解析が行われるのか、また、フォーム解析の結果がどうなるのか、について見てみます。

（１）画像データの準備

先の罫線付きの表形式文書画像から、罫線を取った画像で試してみます。

この画像をダウンロードして、ファイル名を「shoppinglist_noborder.jpg」とします。

（２）解析の実行と結果確認

解析を実行します。

# endpoint_url にはコンソールの予測エンドポイントに表示される値を設定する。
endpoint_url = "https://(Region)-documentai.googleapis.com/v1/projects/(省略):process"
# 画像を読み込む
image_content = load_image("shoppinglist_noborder.jpg")
# 解析を実行
response = call_process_document(endpoint_url,image_content,"image/jpeg")

まず、抽出された文字列全体を確認します。（以下は、print(response.document.text)　の出力結果です。）

Shopping List
Price
Date Description
2021/2/1 Sweets
2021/2/1 Bento
2021/2/2 TechnoDaifukucho
Total
$300.00
$1,000.00
$0.00
$1,300.00

罫線付きの表形式画像と同じ結果（同じ文字）が得られました。

続いて、テーブルが認識されているかどうか確認してみます。

htmlstr = tables_to_htmlstr(response.document.pages[0].tables, response.document.text)
print(htmlstr)

この出力を貼り付けたものが以下の表です。

	Description
2021/2/1	Sweets
2021/2/1	Bento
2021/2/2	TechnoDaifukucho
	Total

なんと、表が認識されています！凄い！

ただし、Dateのヘッダ文字が認識されていないのと、Priceのカラムが含まれていません。。。

加えて、FormFieldも見てみます。

htmlstr = fields_to_htmltable(response.document.pages[0].form_fields, response.document.text)

この出力を貼り付けます（border=1に設定しています）。

id	Name	Value	Value Type	Confidence(Name)	Confidence(Value)
0	Price	$300.00 $1,000.00 $0.00 $1,300.00		0.7783	0.7783
1	Total	$1,300.00		0.5562	0.5562
2	TechnoDaifukucho	$0.00		0.4377	0.4377
3	Bento	$1,000.00		0.4313	0.4313
4	Date	2021/2/1 2021/2/1 2021/2/2		0.4036	0.4036
5	Sweets	$300.00		0.3977	0.3977
6	Description			0.1268	0.1268

• Priceはテーブルとして認識されませんでしたが、フォーム要素のキーとして認識されて、その値として金額が列挙されています。
• 今回の例では、金額間に改行がありますので、金額の区別はつきやすいです。
• Dateはテーブルのヘッダ文字列として認識されませんでしたが、フォーム要素のキーとして認識されて、その日付が列挙されています。
• 但し、値として認識されている矩形はかなり大きく、その中からDescriptionの項目を除いた値のようになっているようです。。。
• 罫線ありのフォーム要素の解析結果とは異なり、TechnoDaifukuchoが認識されています。（しかもBentoより上位にきている。。。（笑））
• ナレッジグラフとは関係なかったのかな。。。？

結局のところ、罫線がある場合は、とてもスッキリした解釈ができましたが、罫線が無い場合は、テーブルの解析結果とフォームの解析結果から、最終的にどのように情報を解釈（利用）するべきか、かなり悩む気がします。

［７］最後に

長々と Document AI の汎用Form Parserの解析結果を見てきました。

サンプルが適切だったとは言えないかもしれませんが、感想として、ハマれば凄く使えそう！という感じがします。（うまくいかない場合もあるが、うまくいくものは凄くうまくいく、という感じでしょうか。）

そう考えると、今回は試していませんが、特定様式に特化したプロセッサを利用した解析は、かなり凄いのかもしれません。

また、今回の実験を通じて、汎用プロセッサ（Form Parser）でも、「凄い」と思わせるところが多々あり、Document AI のサービスの今後にとても期待が持てます。日本語対応が待ち遠しいです。

もう一つ感じるのは、今回のような解析ができるようになると、（特種用途は別として）一般的なOCR利用については、解析アルゴリズムをいろいろ考えるより、学習が基本になりそう、と強く感じました。

実際に、Document AI のガイドには、人間参加型（HITL：Human in the Loop）の記述があります。

今後も動向を追っていきたいと思います。