Document AI

解決する課題

• スキャンした PDF や画像の文書を人手で転記しており、時間とミスが多い
• 請求書・領収書・契約書から特定の項目（金額・日付・取引先など）を自動抽出したい
• レイアウトが崩れた帳票や手書きを含む文書から文字と表構造をまとめて取り出したい
• 抽出結果を後続の BigQuery / データベース / 業務システムへ流し込み、処理を自動化したい

主要概念と用語

• プロセッサ (Processor): 文書を処理する実体。用途ごとに種類があり、API はこのプロセッサに対して文書を送る
• OCR（光学文字認識）プロセッサ: 文字・段落・ブロック・表などのレイアウト要素を抽出する基本処理。多言語と手書きに対応する
• 特化型（事前学習）プロセッサ: 請求書・領収書・身分証など特定の文書タイプ向けに学習済みのプロセッサ。決まった項目（エンティティ）を最初から抽出できる
• カスタム抽出プロセッサ (Custom Extractor): 自社固有の帳票に合わせ、ラベル付けした教師データで項目抽出を学習させるプロセッサ
• エンティティ (Entity): 抽出された意味のある項目。たとえば請求書なら「請求金額」「支払期日」「請求元」など
• Document オブジェクト: 処理結果のレスポンス。テキスト本文、ページ、レイアウト要素、抽出エンティティ、各値の信頼度スコアを含む
• Human-in-the-Loop（人間によるレビュー）: 信頼度が低い抽出結果を人がレビュー・修正する仕組み。精度が求められる業務で併用する
• Document AI Workbench: カスタムプロセッサの作成・学習・評価を行う管理画面

仕様・制限・クォータ

• 入力は **PDF・画像（TIFF や PNG など）**が中心。同期処理は少ないページ数、バッチ処理（非同期）は大量・多ページの文書に向く
• 1 リクエストで扱えるページ数やファイルサイズには上限があり、大きい文書はバッチ処理で扱う。具体的な上限値は変動するため公式ドキュメントで確認する
• 入力・出力は Cloud Storage を介して受け渡すのが一般的。バッチ結果は JSON として出力される
• 抽出結果には項目ごとの信頼度スコアが付き、しきい値で自動採用と人手レビューを切り分けられる
• 利用できるプロセッサの種類・対応言語・対応リージョンはサービス更新で増減するため、最新は公式情報を参照する

内部の仕組み

Document AI はまず OCR で文書から文字とレイアウト（ページ・ブロック・行・表のセル）を取り出し、座標付きのテキストレイヤーを生成します。その上に、用途別の機械学習モデルが乗り、文書タイプの分類や、意味のある項目（エンティティ）の抽出を行います。請求書プロセッサなら「この数値は請求金額」「この日付は支払期日」といった項目の意味づけまで含めて返します。

特化型プロセッサは Google が学習済みのモデルを使うため、ユーザーは教師データを用意せずに使えます。一方、カスタム抽出プロセッサでは、自社の帳票にラベルを付けたサンプルで学習・評価し、独自項目の抽出精度を高めます。抽出された各値には信頼度スコアが付与され、低スコアのものを Human-in-the-Loop で人がレビューする運用につなげられます。

設計パターン / ベストプラクティス

• 入力 = Cloud Storage、処理 = Document AI、保存先 = BigQuery / Firestore の三段構成が王道。大量文書はバッチ処理で非同期に流す
• 取り込みをイベント駆動にする。Cloud Storage への文書アップロードを Eventarc / Cloud Functions で受け、Document AI を呼び出す
• 信頼度スコアでルーティングする。しきい値以上は自動確定、未満は Human-in-the-Loop や担当者キューへ回す
• カスタム抽出は少量から学習し評価指標（適合率・再現率）で改善を回す。最初から完璧を狙わない
• 文書タイプが混在する場合は、まず分類してから適切なプロセッサへ振り分ける

運用・監視

• Cloud Monitoring / Cloud Logging で API のリクエスト数・エラー率・レイテンシを監視する
• バッチ処理は失敗ファイルが混ざるため、出力 JSON の有無や処理ステータスを確認し、失敗分のみ再処理する設計にする
• 抽出精度の劣化は信頼度スコアの分布や人手修正率の推移で検知する。帳票フォーマット変更時は再評価する
• カスタムプロセッサはバージョン管理し、新版を本番投入する前に評価データで回帰を確認する

コスト

• 課金は基本的に処理したページ数に応じる。プロセッサの種類（OCR・特化型・カスタム）によって単価が異なる
• 不要な高機能プロセッサを全文書に使わず、用途に合った最小のプロセッサを選ぶとコストを抑えられる
• 大量文書はバッチ処理でまとめ、Human-in-the-Loop の対象を信頼度の低い分だけに絞ると、人手コストも削減できる
• 具体的な単価は変動するため、見積もりは公式の料金ページで確認する

セキュリティ

• サービスアカウント + IAM で最小権限を付与し、認証情報のハードコードを避ける（AWS の IAM ロール相当）
• 入出力の Cloud Storage バケットへのアクセスを限定し、文書に含まれる個人情報・機密情報の取り扱いに注意する
• 保存データは Google 管理鍵で既定暗号化。要件に応じ **CMEK（顧客管理鍵, Cloud KMS）**を適用する
• 外部流出対策に VPC Service Controls を併用し、データ境界を設ける

Well-Architected の観点

• 運用上の優秀性: 手作業の転記を自動化し、イベント駆動とバッチで処理を標準化。信頼度ベースの例外処理で人手を最小化する
• 信頼性: バッチの失敗ファイルを検知して再処理し、フォーマット変更時は再評価する
• コスト最適化: 用途に合うプロセッサを選び、人手レビューを低信頼度分に絞る

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# 1) Document AI API を有効化
gcloud services enable documentai.googleapis.com

# 2) OCR プロセッサを作成（タイプはユースケースに合わせて選択）
gcloud documentai processors create \
  --location=us \
  --display-name=my-ocr \
  --type=OCR_PROCESSOR

# 3) 作成済みプロセッサを一覧で確認
gcloud documentai processors list --location=us

# 4) REST API で単一文書を同期処理（base64 化した文書を送る）
#    PROCESSOR_ID は手順 2 で作成したプロセッサの ID
curl -X POST \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  "https://us-documentai.googleapis.com/v1/projects/MY_PROJECT/locations/us/processors/PROCESSOR_ID:process" \
  -d '{"rawDocument":{"mimeType":"application/pdf","content":"BASE64_PDF"}}'