Document AIとは？機能や料金を解説

Document AIは、Google Cloudで請求書、領収書、申請書、契約書などの非構造文書を読み取り、業務で使える構造化データに変換するための文書処理AIです。
単なるOCRではなく、文書タイプの分類、項目抽出、テーブル・キー値ペアの読み取り、カスタムプロセッサの学習まで扱えます。


この記事では、Document AIの基本、主要プロセッサ、Cloud Vision AIやAzure AI Document Intelligenceとの違い、使い方、料金、活用事例、導入判断で詰まりやすい論点を解説します。

Document AIとは

Document AIは、Google Cloudが提供する文書処理・文書理解のためのAIプラットフォームです。公式ドキュメントでは、文書に含まれる非構造データを、データベースに格納しやすい構造化データへ変換するサービスとして説明されています。

たとえば、請求書のPDFから請求書番号、取引先名、請求額、税額、支払期限、明細行を取り出し、経理システムやワークフローに渡すような用途で使います。単に画像の中の文字を読むだけでなく、文書のレイアウトや意味を踏まえて「どの項目が何を表すか」まで扱える点が、一般的なOCRとの違いです。

OCRだけでなく文書理解まで扱う

文書処理では、文字を読むだけでは業務に使えない場面が多くあります。請求書を例にすると、文字列として「2026/04/30」や「120,000円」を読み取れても、それが請求日なのか支払期限なのか、明細金額なのか合計金額なのかを判定できなければ、後続の処理に渡しにくくなります。

Document AIは、このような文書固有の構造を扱うために、プロセッサという単位でOCR、抽出、分類、分割を実行します。Google Cloudのプロセッサ一覧では、Enterprise Document OCR、Form Parser、Invoice Parser、Expense Parser、Custom Extractor、Custom Classifierなどが用途別に整理されています。

主な対象文書

Document AIで扱いやすいのは、紙やPDFで流通しているものの、業務ではデータ化したい文書です。代表的な対象は次の通りです。

• 請求書・領収書
  取引先名、請求額、税額、支払期限、明細行などを抽出し、会計・経費精算・ERPへ渡す用途です。
  
  
• 申請書・フォーム
  氏名、住所、申請内容、チェックボックス、テーブルなど、定型フォームのキー値ペアを抽出する用途です。
  
  
• 契約書・ローン書類
  文書タイプを分類し、審査やレビューに必要な項目を取り出す用途です。
  
  
• ID・証明書・給与明細
  本人確認やバックオフィス処理に必要な項目を抽出する用途です。
  
  

つまり、Document AIは「文書を読むAI」ではなく、文書から業務データを作るAIとして見ると理解しやすくなります。

Document AIが必要になる理由

Document AIが必要になるのは、紙・PDF・画像で届く情報を、人手で確認しながらシステムへ入力している業務が残っているためです。OCRで文字を起こすだけでは、承認、照合、入力、例外処理まで自動化できません。

請求書処理を例にすると、取引先からPDFが届き、担当者が金額や支払期限を確認し、発注情報と照合し、会計システムに入力し、承認フローへ回すという流れがあります。この中でDocument AIが担うのは、文書から必要な項目を抽出して、後続システムに渡しやすい形にする部分です。

AI-OCRとの違い

AI-OCRは、従来のOCRよりもレイアウトや文字認識に強いOCR技術を指す広い言葉です。一方、Document AIはGoogle Cloud上の具体的な文書処理サービスであり、OCRだけでなく抽出、分類、分割、カスタムプロセッサの学習まで含みます。

一般的なAI-OCRサービスを比較する場合は、画面での修正機能、帳票テンプレート、国内法対応、会計ソフト連携なども見ます。Document AIを選ぶ場合は、Google Cloud上のシステムと組み合わせて、Cloud Storage、BigQuery、Vertex AI Search、ワークフロー基盤へどう接続するかまで設計するのが前提になります。

手作業が残りやすいポイント

文書処理で自動化が止まりやすいのは、読み取り精度そのものより、読み取った後の扱いです。たとえば次のような場面では、単純なOCRだけでは対応しきれません。

• 文書タイプの判定
  同じメールボックスに請求書、発注書、納品書、領収書が混ざって届く場合、まず文書タイプを分ける必要があります。
  
  
• 項目名の揺れ
  請求額、合計金額、ご請求金額など、同じ意味の項目が取引先ごとに異なる名前で書かれることがあります。
  
  
• テーブルや明細行の抽出
  明細が複数行ある文書では、単純な全文テキスト化だけでは、どの金額がどの品目に紐づくかを扱いにくくなります。
  
  
• 確認と差戻し
  抽出結果が低信頼度の場合、人間の確認、修正、再処理、承認へ回す運用が必要です。
  
  

Document AIはこのうち、読み取り・抽出・分類の部分を担います。ただし、承認やERP入力まで自動化するには、ワークフローや業務システム連携を別途設計する必要があります。

Document AIの主要機能

Document AIの主要機能は、プロセッサの種類ごとに整理すると理解しやすくなります。用途に合わないプロセッサを選ぶと、PoCの段階で精度やコストの見積もりがずれやすくなるため、最初に使い分けを押さえておきましょう。

Enterprise Document OCR

Enterprise Document OCRは、文書から文字やレイアウト、品質情報を抽出する基礎的なプロセッサです。スキャン画像やPDFからテキストを取り出し、後続の抽出や検索に渡す用途で使います。

Google CloudのVision AI製品ページでは、Document AIはコンピュータビジョンや自然言語処理を組み合わせ、スキャン文書からテキストとデータを抽出する文書理解プラットフォームとして紹介されています。画像1枚のOCRで足りるならCloud Vision APIでも検討できますが、文書処理ワークフローや項目抽出が必要ならDocument AIのほうが適しています。

Form ParserとLayout Parser

Form Parserは、定型フォームのキー値ペアやテーブルを抽出するためのプロセッサです。申込書やアンケート、申請書のように、項目名と値が並ぶ文書で使いやすい選択肢です。

Layout Parserは、テキスト、表、リストなどの要素を文脈を保ったチャンクとして返す用途に向きます。検索やRAG、文書要約、ナレッジ化の前処理として、文書の構造を保ちながら分割したい場合に候補になります。

Pretrained Parser

Pretrained Parserは、請求書、領収書、給与明細、銀行明細、身分証など、特定の文書タイプ向けに事前学習されたプロセッサです。たとえばInvoice Parserは、請求書番号、サプライヤー名、請求額、税額、請求日、支払期限、明細行などを抽出する用途として案内されています。

請求書や経費精算のような定番文書では、まずPretrained Parserで試し、足りない項目や自社固有の帳票差分が出てきたらカスタムプロセッサを検討する流れが現実的です。

Custom ExtractorとDocument AI Workbench

Custom Extractorは、自社固有の文書から必要な項目を抽出したい場合に使います。生成AIを使うCustom Extractorのドキュメントでは、学習方法としてzero-shot、few-shot、fine-tuningが整理されており、few-shotは5〜10件、fine-tuningは10〜50件以上の文書が推奨数として示されています。

ただし、少数サンプルで始められることと、本番精度がすぐに安定することは別です。レイアウトの揺れ、取引先ごとの表記差、手書きや低品質スキャン、例外文書の比率が大きい場合は、データセット設計とレビュー運用まで含めて検証する必要があります。

Custom ClassifierとCustom Splitter

Custom Classifierは、文書の種類を分類するためのプロセッサです。複数の書類が混ざって届く業務では、抽出処理に入る前に「これは請求書」「これは納品書」「これは契約書」と振り分ける工程が必要になります。

Custom Splitterは、1つのPDFに複数の文書が含まれる場合に、文書単位へ分割するためのプロセッサです。金融や保険、バックオフィスの一括スキャンでは、分類と分割を先に設計しておくことで、後続の抽出精度と運用負荷を安定させやすくなります。

Document AIの使い方

Document AIは、いきなりモデルを作るのではなく、対象文書と業務フローから逆算してプロセッサを選ぶのが基本です。公式ドキュメントでも、用途に合うプロセッサを選び、プロセッサを作成し、文書を送信して処理結果を受け取る流れが示されています。

基本ステップ

導入初期は、次の順番で進めると検証範囲を切り分けやすくなります。

1. 対象文書を決める
   請求書、領収書、申請書、契約書など、最初に扱う文書タイプを1つに絞ります。
   
   
2. プロセッサを選ぶ
   OCRだけならEnterprise Document OCR、定型フォームならForm Parser、請求書ならInvoice Parser、独自帳票ならCustom Extractorを候補にします。
   
   
3. Google Cloudプロジェクトでプロセッサを作成する
   Document AIはプロジェクトごとにプロセッサインスタンスを作成して使います。
   
   
4. サンプル文書を処理する
   PDFや画像を送信し、抽出されたフィールド、信頼度、ページ構造、テーブルの結果を確認します。
   
   
5. 業務システムへ接続する
   抽出結果をCloud Storage、BigQuery、ワークフロー、ERP、会計システムなどへ渡し、承認や例外処理を設計します。
   
   

この流れで重要なのは、抽出結果のJSONを見て満足しないことです。現場で必要なのは「読めた」ではなく、「次の承認・照合・入力が減った」です。PoCでは、抽出精度だけでなく後続作業の削減時間も一緒に測るべきです。

導入判断で詰まる論点

Document AIの導入で詰まりやすいのは、どこまでをDocument AIに任せ、どこからを業務アプリ側で処理するかです。SIer視点では、以下のように切り分けるのが現実的です。

論点	判断の目安
OCRだけでよいか	画像内の文字列を取り出すだけならCloud Vision AIも候補。項目抽出や文書分類が必要ならDocument AIを優先
事前学習済みで足りるか	請求書や領収書ならPretrained Parserから始める。自社固有帳票が多いならCustom Extractorを検討
全自動化できるか	抽出結果に低信頼度項目や例外帳票があるなら、人間の確認ステップを前提にする
後続処理をどうするか	ERP入力、承認、照合、検索、保管まで必要なら、Document AI単体ではなくワークフロー全体で設計

特に請求書処理では、請求書処理をAIで自動化する方法でも解説しているように、読み取り後の照合・承認・会計連携まで含めて初めて業務負荷が下がります。

Document AIと他サービスの違い

Document AIは、Google Cloudの他のAIサービスや、Azure・AWSの文書処理AIと比較されることが多いサービスです。役割が近いサービスほど混同しやすいため、まずは「何を入力し、何を出力したいか」で整理すると判断しやすくなります。

以下の表では、代表的な比較対象を用途別に整理します。

サービス	向いている用途	Document AIとの違い
Cloud Vision AI	画像のOCR、ラベル検出、顔・ランドマーク検出、セーフサーチ	画像解析が中心。文書タイプ別の項目抽出やカスタム文書処理はDocument AIが適する
Cloud Natural Language AI	テキストの感情分析、エンティティ分析、分類、モデレーション	入力は主にテキスト。PDFやスキャン文書から構造化データを作る用途はDocument AIが適する
Azure AI Document Intelligence	Azure環境でのフォーム・請求書・カスタム文書処理	Microsoft環境やAzure基盤との親和性が高い。GCP上のデータ基盤やVertex AI連携ならDocument AIが候補
Amazon Textract	AWS環境でのテキスト、フォーム、テーブル、署名、クエリ抽出	AWSネイティブ構成に向く。Google CloudのCloud Storage、BigQuery、Vertex AI Searchとの接続を重視するならDocument AIが候補
Vertex AI Search	抽出済み文書や社内文書の検索・検索拡張	文書からデータを取り出すのではなく、検索体験を作るサービス。Document AIで抽出した文書データを検索に活かす関係

すでにGoogle Cloudでデータ基盤を作っている企業なら、Document AIで文書を構造化し、BigQueryやVertex AI Searchへ渡す設計が自然です。一方、既存基盤がAzureやAWSに寄っている場合は、Azure AI Document IntelligenceやAmazon Textractも候補に入れて比較するべきです。

Document AIの活用事例

Document AIの導入事例を見ると、単なるOCR置き換えより、文書処理の流れ全体を再設計しているケースが多いことが分かります。ここでは、Google Cloudが公開している事例から、文書量と業務インパクトが分かりやすいものを紹介します。

Workday

Workdayは、経費精算などで扱う多言語の領収書処理にGoogle CloudのDocument AI for Procurementを活用しています。Google CloudのWorkday事例ブログでは、Workday Financial ManagementとWorkday HCMの顧客が3,400以上あると説明されており、グローバルに流通する文書を処理する必要があったことが分かります。

同ブログでは、多言語の領収書処理でF1スコア85以上を達成したことも紹介されています。ここで重要なのは、単にOCR精度を競っているのではなく、多言語・複数フォーマットの経費処理を業務プロセスに組み込んでいる点です。

Mr. Cooper

米国の住宅ローン企業Mr. Cooperは、Google Cloud上でローン関連文書の処理基盤を構築しており、Document AIの文脈でも紹介されています。Google Cloudの公式ブログでは、同社の文書分類モデルが1年以内に9億3,200万ページ以上を処理し、毎分2,200ページ超、90%以上の分類精度で動作していると説明されています。

住宅ローンのように文書量が多く、審査・確認・コンプライアンスが絡む領域では、抽出精度だけでなく、処理速度と運用の安定性が重要になります。Document AIはこうした大量文書処理の基盤として使われています。

Resistant AI

金融犯罪対策のResistant AIは、Document AIと組み合わせた文書不正検知の仕組みをGoogle Cloud上で提供しています。Google Cloudの公式ブログでは、Payoneerが手動の文書不正レビューを全体の18%まで減らし、顧客承認担当者が判定に99.2%同意したこと、Habitoが既存の不正対策と比べて追加で32%の不正を検知し、調査時間を1件あたり52分削減したことが紹介されています。

この事例は、Document AIが「読める文書を増やす」だけでなく、不正検知や審査の前段に組み込まれることを示しています。ただし、Document AI単体の効果ではなく、Resistant AI側の不正検知システムと組み合わせた成果として読むべきです。

Document AIの注意点

Document AIを導入するときは、読み取り精度だけで判断しないことが重要です。文書処理は、データ品質、例外対応、セキュリティ、後続システム連携まで含めて業務影響が出る領域だからです。

プロセッサ選定を間違えない

最初に確認すべきなのは、対象文書がどのプロセッサに合うかです。請求書なのに汎用OCRだけで始めると、項目抽出の部分を後から自作することになります。逆に、テキスト化だけで十分な資料にCustom Extractorを使うと、コストと学習作業が過剰になります。

小さく始める場合でも、対象文書の種類、ページ数、言語、レイアウトの揺れ、抽出したい項目、後続処理を事前に棚卸ししてください。

ページ数やファイルサイズの制限を確認する

Document AIには、処理方式やプロセッサごとにページ数・ファイルサイズの制限があります。公式の制限ページでは、オンライン処理の最大ファイルサイズは40MB、バッチ処理は1GB、バッチ処理1回あたりのファイル数は5,000件と示されています。また、プロセッサごとにオンライン処理とバッチ処理のページ上限が異なります。

このため、数百ページのPDFや大量のスキャンファイルを扱う場合は、オンライン処理で試した結果をそのまま本番設計に使わないほうが安全です。実運用のファイルサイズと件数に近いデータで、バッチ処理、分割、リトライ、監視まで確認してください。

人間の確認フローを残す

文書処理では、全件を完全自動化するより、信頼度やルールに応じて人間が確認する設計のほうが安定するケースがあります。たとえば、請求額が発注額と一致しない、支払期限が抜けている、取引先名がマスタと一致しない、抽出信頼度が低いといった場合は、人間のレビューへ回すべきです。

AI総研の導入支援でも、最初から100%自動化を目標にするより、「高信頼度の定型文書は自動処理、例外文書はレビュー」と分けたほうが、現場に定着しやすいケースが多くあります。PoCでは精度だけでなく、レビューへ回る件数とレビュー時間も測定してください。

Document AIの料金

Document AIの料金は、利用するプロセッサ、処理ページ数、文書単位の課金条件によって変わります。2026年4月時点の公式料金ページでは、主に米ドル建てのページ単位料金として掲載されていますが、一部のPretrained processorは文書単位またはclassified document単位で課金されます。

以下は代表的な料金の一部です。Google Cloudの料金は改定される可能性があるため、実際の見積もりでは利用するプロセッサ、リージョン、通貨、無料枠や契約条件を最新ページで確認してください。

プロセッサ・機能	料金の目安
Enterprise Document OCR	1,000ページあたり1.50ドル。月500万ページ超の部分は1,000ページあたり0.60ドル
Enterprise Document OCR add ons	1,000ページあたり6ドル
Form Parser / Custom Extractor	1,000ページあたり30ドル。月100万ページ超の部分は1,000ページあたり20ドル
Layout Parser	1,000ページあたり10ドル
Custom Classifier / Custom Splitter	1,000ページあたり5ドル。月100万ページ超の部分は1,000ページあたり3ドル
Summarizer	1,000ページあたり25ドル
Custom processor hosting	1時間あたり0.05ドル
Invoice Parser / Expense Parser / Utility Parser	10ページあたり0.10ドル

料金ページでは、PDFは1ページごと、画像は1画像ごと、WordやHTMLなどは3,000文字までを1ページとして扱うなど、ページ換算のルールも示されています。つまり、同じ「1ファイル」でも、PDFのページ数やOffice文書の文字数によって課金ページ数が変わります。

コストを読むときは、OCR部分と抽出部分を分けて考えるのが重要です。大量の全文OCRだけならEnterprise Document OCRの単価が効きますが、請求書や独自帳票から項目を抽出する場合は、Pretrained ParserやCustom Extractorの単価が主なコストになります。さらに、カスタムプロセッサではホスティング料金や学習データ準備の工数も見ておく必要があります。

Document AIで読み取った書類を業務フローに接続するなら

Document AIで請求書や申請書の読み取り精度が確認できても、そのまま業務の自動化が完了するわけではありません。実務では、抽出結果を承認フロー、マスタ照合、ERP入力、差戻し、監査ログまで接続して初めて、現場の手作業が減ります。

AI Agent Hubは、文書処理の結果を業務フローへつなぐためのエンタープライズ向けAIエージェント基盤です。Document AIなど既存のGoogle Cloud環境を前提に、要件に応じて接続設計・構築を進められます。

• 請求書・領収書の読み取り後を自動化
  AI-OCR Agent、請求書受領Agent、経費申請Agentなどを組み合わせ、読み取った文書データを承認・仕訳・入力へつなぐ設計が可能です。
  
  
• 例外処理と人の承認を前提にできる
  信頼度が低い項目やマスタ不一致の文書は、Human-in-the-Loopで人間の確認へ回せます。全自動化ではなく、現場で止まらない運用を設計できます。
  
  
• 既存システムへの入力まで見据えられる
  SAP Concur、freee会計、Dynamics 365、Salesforce、Oracle NetSuite、勘定奉行クラウドなど、既存システムを前提に接続設計を進められます。
  
  

AI総合研究所では、Document AIで抽出した文書データを、承認・照合・入力までつなぐ業務フロー設計を支援しています。無料資料で、AI Agent Hubを使った文書処理自動化の全体像をご確認ください。

まとめ｜Document AIは文書処理を業務データ化する入口

Document AIは、Google Cloud上で請求書、領収書、申請書、契約書などの文書を読み取り、構造化データとして業務システムへ渡すための文書処理AIです。Cloud Vision AIのOCRよりも、文書タイプの分類や項目抽出、カスタムプロセッサの学習まで踏み込める点が特徴です。

導入時は、まず対象文書を絞り、Pretrained Parserで足りるのか、Form ParserやCustom Extractorが必要なのかを見極めます。大量文書や独自帳票を扱う場合は、ページ数・ファイルサイズ・学習データ・レビュー運用の制約も先に確認してください。

重要なのは、Document AIだけで業務自動化が完結するわけではないことです。抽出結果をどこに保存し、誰が確認し、どのシステムに入力し、例外をどう処理するかまで設計して初めて、文書処理の工数削減につながります。まずは請求書や申請書など1つの文書タイプからPoCを始め、抽出精度と後続作業の削減時間をセットで測るのがおすすめです。