💡

Google Cloud Document AIで契約書のOCRを試してみた

に公開

契約データから請求書を生成する処理の効率化を目的にGoogle Cloud Document AIのOCR機能を使っていけないかと思い、社内で定期的に設けられているハッカソンの時間を使って検証してみました。

この記事では、

  • なぜDocument AIを選んだのか
  • コスト試算と実運用での見通し
  • セキュリティ面での検証結果
  • 実装してみた結果と課題

について書いていきます。

契約書や請求書などの帳票処理の自動化を検討している方の参考になれば幸いです。

プロジェクトの概要

目的

  • 契約データから請求書を自動生成する処理の効率化
  • Salesforceのデータ構造に依存しない柔軟な実装

検証内容

  • Document AIのOCR精度の確認
  • コストの試算
  • セキュリティ要件の確認

なぜDocument AIを選んだのか

現状の課題

契約データから請求書を書き起こす際に、以下のような課題がありました:

  • Salesforceのスキーマに合わせてデータ変換する処理が複雑
  • データ構造の変更に弱い

そこで、契約書から直接データを読み取るアプローチを検討しました。

Document AIを選ぶ理由

契約「書」から読み取ることで:

  • Salesforceのデータ構造を気にする必要がない
  • 原本に忠実なデータ抽出が可能
  • 将来的な拡張性が高い

コスト試算

Document AIの料金体系は以下の通りです:

機能 料金
文字起こし(OCR) $1.50 / 1,000ページ
構造解析 $30.00 / 1,000ページ

実運用での見通し

一般的な申込書は数ページ程度で構成されることが多く、月間の処理量を考慮しても、OCR機能のみであれば非常に低コストで運用可能であることがわかりました。

構造解析機能を使用する場合は料金が上がりますが、それでも人手での処理コストと比較すると十分にペイする計算です。

セキュリティ面の検証

帳票データは機密性が高いため、セキュリティ面の検証は特に重要でした。

※以下の情報は変更される可能性があるため、必ず最新の公式情報を参照してください。

データ保護

Google Cloud全体のセキュリティプロセスに準拠:

  • 暗号化:通信中・保管中ともに実行
  • アクセス管理:VPC Service Controls、CMEKなど
  • データ所有権:全てユーザーに帰属

コンプライアンス

以下の認証を取得済み:

  • ISO 27001/17/18
  • SOC 2/3
  • PCI DSS
  • FedRAMP High
  • HIPAA対応

データ利用方針

最も重要な点

「モデル改善や再訓練に顧客文書を利用しない」

これにより、機密データがGoogleのAIモデル改善に使われる心配はありません。

データ保存期間

  • バッチ処理:解析終了後速やかに削除(異常終了時は最大1日保持)
  • 同期処理:インメモリ処理でディスク保存なし

セキュリティ要件まとめ

項目 保護水準
モデル再訓練への利用 一切なし
第三者共有 最小限・管理された形のみ
暗号化 通信中・保管中ともに実行
データ所有権 全てユーザーに帰属
保存期間 処理後即削除、最大でも24時間内

実装してみた

お試し実装

  • 契約書をそのまま文字起こし
  • OCRプロセッサ(一番シンプルな機能)を使用

より実践的な実装

  • 契約書から再利用可能な(ラベルづけされた)契約データを抽出
  • カスタムドキュメントエクストラクタを使用

参考資料:

結果と課題

良かった点

文字起こしの精度が高い

日本語の契約書でも高精度で文字認識ができ、実用レベルでした。特に以下の点で優れていました:

  • 手書き文字と印刷文字の混在にも対応
  • 表形式のデータも正確に認識
  • 縦書き・横書きの混在にも対応

課題(というより、やりきれなかったところ)

一部フィールドが別フィールドのものとして解釈されていた

  • 今回の検証はハッカソン形式で限られた時間の中で検証を行ったためパーサーの設定に不備があったようです
  • フォーマットが同じ文書を読み込むのであれば、一度パーサーさえ作ってしまえば問題ないため課題という課題ではないですね

まとめと今後の展望

Document AIは、機密性の高い文書処理にも適した設計となっており、以下の点で本番運用に耐えうると判断しました:

  1. コスト面:処理量に応じた従量課金で、スモールスタートが可能
  2. セキュリティ面:エンタープライズレベルの要件を満たす
  3. 精度面:日本語契約書でも実用的な精度

次のステップ

  1. 実際に読み取ったデータを再利用できる形にしたい → BigQueryへの連携部分の実装改善
  2. 一部フィールドが別フィールドに解釈される → カスタムエクストラクタの学習による精度向上
  3. 実際の業務フローへの組み込み

関連リンク

Unipos Tech Blog

Discussion