Google Document AIとは｜プロセッサの選び方・料金・Pythonでの使い方【2026年9月】

Google Document AIは、PDFや画像の帳票から文字・表・項目を取り出して構造化データとして返す、Google Cloudの文書処理サービスです。「ドキュメントAI」という言葉は文書を読むAI全般を指す一般名詞としても使われますが、この記事ではGoogle Cloudの製品としてのDocument AIを扱います。

結論から書くと、OCRだけなら月1,000ページまで無料で、項目抽出（Form Parser・Custom Extractor）は1,000ページあたり30米ドルです。ただし日本語の帳票では、請求書専用のInvoice Parserが日本語に対応していない、生成AIによる抽出は英語だけが公式サポート、東京リージョンがない、という3点で設計が変わります。料金・上限・対応言語は2026年9月26日に公式ドキュメントで確認した値です。

まとめ：Document AIの要点

• Document AIは「プロセッサ」を作ってAPIに文書を送る仕組みで、用途ごとにOCR・Form Parser・Layout Parser・Custom Extractor・分類・分割・特化型を選ぶ
• 料金はEnterprise Document OCRが月1,000ページまで無料、以降1,000ページあたり1.50米ドル。Form ParserとCustom Extractorは30米ドル、Layout Parserは10米ドル
• オンライン処理は多くのプロセッサで1回15ページ（imageless_modeで30ページ）・40MBまで。Expense Parserは10ページ、Layout Parserは20MBなどの例外がある。上限を超える文書は、プロセッサごとのバッチ上限内でCloud Storage経由のバッチ処理に回す
• 日本の請求書はInvoice Parserの対応言語外。Custom Extractorで自前モデルを学習するのが公式にサポートされた経路になる
• 処理ロケーションはusかeuが基本で、日本のリージョンはない。国内でのデータ処理が必須の案件には向かない
• Pythonは google-cloud-documentai 3.15.0の documentai_v1.DocumentProcessorServiceClient を使う。v1beta3の DocumentUnderstandingServiceClient を使う古いサンプルは動かない

以下、プロセッサの選び方から料金、Pythonでの実装、日本語帳票の制約の順に説明します。

Document AIの仕組み：プロセッサへの文書送信と構造化データの受信

Document AIでは、最初にコンソールかAPIで「プロセッサ」を作成します。プロセッサは「請求書を読む」「フォームのキーと値を取る」といった処理の単位で、作成時にロケーション（usまたはeuなど）を決め、IDが発行されます。アプリケーションはそのIDを指定して文書を送り、結果を Document オブジェクトで受け取ります。

Document には全文テキスト（text）、ページごとのブロック・段落・表（pages）、抽出した項目（entities）、Layout Parserのチャンク（chunked_document）が入ります。項目には type_（項目名）、mention_text（読み取った値）、confidence（信頼度）が付くため、信頼度の低い項目だけを人の確認に回す、といった後処理が組めます。

文字を読むだけなら画像向けのCloud Vision APIでも足ります。Document AIを選ぶ理由は、表やキーと値の対応、帳票の項目名まで構造として返ってくる点です。OCRの方式や精度の考え方はOCRの仕組みと実装での組み込み方で整理しています。

プロセッサの種類と選び方

公式のプロセッサ一覧に載っている型は、用途で5つに分かれます。どれも一般提供（GA）ですが、各型の中で新しいモデル版はPreviewとして並行提供されています。

選ぶ順番は「決まった項目を取りたいか」で分かれます。文字を全部取り出して検索や翻訳に回すならEnterprise Document OCR、RAGの前処理として見出し付きのまとまりに切りたいならLayout Parserです。項目を取りたい場合、帳票の書式がばらばらでラベルと値が隣り合っているならForm Parser、取りたい項目が決まっているならCustom Extractorになります。

Enterprise Document OCRとForm Parser：汎用の読み取りとキー・値抽出

Enterprise Document OCRは200以上の言語の文字を、手書きを含めて読み取り、読みやすさの品質判定も返します。Form Parserは同じく200以上の言語でキーと値、チェックボックス、表を取り出し、さまざまな文書に共通する汎用項目を11種類抽出します。どちらも学習なしですぐ使えるため、最初の検証はこの2つから始めるのが近道です。

Custom Extractor：自社帳票の項目定義と抽出方式

Custom Extractorは「請求番号」「支払期日」のように取りたい項目を自分で定義して抽出するプロセッサです。方式は2系統あり、Geminiを基盤にした生成AI方式と、ラベル付き文書で学習するカスタムモデル方式（モデルベース・テンプレートベース）から選べます。生成AI方式の詳細は後の章で扱います。

分類・分割と特化型プロセッサ

Custom Classifierは文書を種別に振り分け、Custom Splitterは複数の書類を1ファイルにまとめたPDFを書類ごとの境界で分けます。特化型は請求書（Invoice）、経費・領収書（Expense）、給与明細（Pay Slip）、米国のW-2や運転免許証など、帳票の項目があらかじめ定義されたプロセッサです。米国の書式向けのものが多く、日本の帳票に使えるかは次の章の対応言語表で判断してください。

日本語帳票で詰まる制約：対応言語・生成AI抽出・リージョン

日本語の請求書や申込書をDocument AIで処理する場合、次の3つを最初に確認しないと設計をやり直すことになります。対応言語と処理ロケーションは、公式のプロセッサ一覧とリージョン別対応表で確認できます。

Invoice Parserの日本語非対応とExpense Parserの対応状況

プロセッサ一覧の対応言語表で、Invoice Parserに載っているのはドイツ語・英語・スペイン語・フランス語など欧州の12言語だけで、日本語はありません。一方、Expense Parser（領収書などの経費書類）はGAの pretrained-expense-v1.4.2-2024-09-12 で日本語を追加対応しています。

対応言語は公式のプロセッサ一覧の各プロセッサの「Supported languages」で確認できます。つまり日本の請求書を処理するなら、Invoice Parserではなく、Form Parserでキーと値を取るか、Custom Extractorで自社の項目を定義するのが公式に対応言語の範囲内に収まる経路です。

Custom Extractorの生成AI抽出：英語限定の公式サポート

Custom Extractorのプロセッサ一覧には「生成AIで抽出する場合、公式にサポートされる言語は英語のみ」と注記があります。日本語の文書でもゼロショットで項目が返ってくることはありますが、日本語は公式の対応言語に含まれません。本番の日本語帳票は、ラベル付き文書で学習するカスタムモデル方式を前提に見積もるほうが安全です。

Document AIの日本リージョン不在と一部Gemini版の処理地域制約

Document AIのロケーションは、マルチリージョンのusとeuのほかに、限定対応の単一リージョンとしてムンバイ、シンガポール、シドニー、ロンドン、フランクフルト、アムステルダム、モントリオールなどがあります。日本のリージョンはありません。プロセッサ作成時の既定はusです。

さらに、Custom ExtractorとLayout Parserのv1.6系（Gemini 3系を使うPreview版）は、Vertex AIのGeminiグローバルエンドポイントを使うため、公式に「usやeuのエンドポイントに送ったリクエストでも世界中のどこへでもルーティングされうる」と書かれています。個人情報を含む帳票を扱い、処理地域を契約で固定する必要があるなら、Custom ExtractorではStableのv1.5系、Layout ParserではStableのv1.0など、処理地域の要件を満たす版を個別に選んで固定してください。

Document AIの料金：プロセッサ別の単価と月額の試算

料金はプロセッサごとの従量課金で、エラー（4xx・5xx）になったリクエストには課金されません。以下は2026年9月26日時点のオンデマンド単価です（米ドル）。

単価の出典はDocument AIの公式料金ページです。月1万ページで試算すると、Enterprise Document OCRは無料枠を引いた9,000ページ分で13.50米ドル、Layout Parserは100米ドル、Form ParserとCustom Extractorは300米ドルです。特化型はページ単価ではなく文書単位で、1〜10ページの請求書1通が0.10米ドル、11〜20ページなら0.20米ドルになります。

見落としやすいのがカスタムプロセッサのホスティング料金です。Custom Extractorなどカスタムプロセッサは処理料金に加えて、デプロイ中のプロセッサバージョン1つにつき1時間0.05米ドルがかかります。公式の試算では1年で438米ドルです。検証で作ったバージョンをデプロイしたまま放置しないでください。

ページの数え方はファイル形式で変わり、PDFは1ページ＝1ページ、画像は1枚＝1ページ、DOCXとHTMLは3,000文字ごとに1ページ、XLSXは1シート＝1ページ、PPTXは1スライド＝1ページです。料金表には1年・3年の「Gemini Enterprise Flexible Savings Plan」の割引列もあり、OCRなら1.35米ドル（1年）と1.20米ドル（3年）です。

処理の上限：オンライン15ページとバッチ処理の使い分け

Document AIの処理方式は、1文書を同期で送るオンライン処理と、Cloud Storageの文書をまとめて非同期で処理するバッチ処理の2つです。全プロセッサ共通の上限は、オンラインが1ファイル40MB、バッチが1ファイル1GBで、バッチ1回あたり5,000ファイルまでです。ページ数の上限はプロセッサごとに違います。

imageless_mode は処理結果から画像を省く指定で、オンラインの上限を30ページまで広げられます。ただし1ページ目から連続して処理する場合に限られます（公式の制限一覧）。チェックボックスを含む文書は、Custom Extractorではオンライン・バッチとも10ページが上限です。Layout Parserはオンライン処理のファイルサイズが20MBまでで、全体の40MBより小さい点にも注意してください。

100ページのPDFをForm Parserで処理するなら、オンラインでは送れないのでバッチ処理を使います。逆に数ページの帳票を1件ずつ即時に返したい業務はオンライン処理が向いています。

Pythonでの使い方：API有効化からprocess_documentまで

事前準備：API有効化・プロセッサ作成・権限

Google Cloudのプロジェクトで課金を有効にし、Document AI APIを有効化します。次にコンソールのDocument AIでプロセッサを作成し、ロケーション（usかeu）と16進数のプロセッサIDを控えます。処理だけを行うサービスアカウントには、processOnline と processBatch の権限を持つ roles/documentai.apiUser（Document AI API User）を付ければ足ります。

gcloud services enable documentai.googleapis.com
gcloud auth application-default login
pip install google-cloud-documentai==3.15.0

クライアントライブラリの最新版は2026年6月3日公開の3.15.0で、Python 3.10以上が必要です。GitHub ActionsなどのCIから呼ぶ場合は、サービスアカウントの鍵JSONを置くよりgoogle-github-actions/authによるWorkload Identity連携で認証するほうが鍵の漏えい経路を持ちません。

オンライン処理の最小コード

公式のクイックスタートと同じ構成で、リージョンごとのエンドポイントを指定してクライアントを作り、RawDocument を ProcessRequest に入れて送ります。以下はgoogle-cloud-documentai 3.15.0でリクエストの組み立てまで確認したコードです。実APIへの送信と抽出結果の検証は含みません。

from google.api_core.client_options import ClientOptions
from google.cloud import documentai_v1 as documentai

PROJECT_ID = "my-project"
LOCATION = "us"                     # プロセッサを作ったロケーション（us / eu）
PROCESSOR_ID = "0123456789abcdef"   # 表示名ではなく16進数のID

client = documentai.DocumentProcessorServiceClient(
    client_options=ClientOptions(api_endpoint=f"{LOCATION}-documentai.googleapis.com")
)
name = client.processor_path(PROJECT_ID, LOCATION, PROCESSOR_ID)

with open("invoice.pdf", "rb") as f:
    raw = documentai.RawDocument(content=f.read(), mime_type="application/pdf")

request = documentai.ProcessRequest(
    name=name,
    raw_document=raw,
    imageless_mode=True,            # オンライン上限を15ページから30ページへ
)
document = client.process_document(request=request).document

print(document.text[:200])
for entity in document.entities:
    print(entity.type_, entity.mention_text, round(entity.confidence, 2))

公式サンプルのコメントどおり、us以外のロケーションに作ったプロセッサを呼ぶときは api_endpoint を必ず指定します。項目名の属性は type ではなく type_ です（Pythonクライアントで定義されている属性名）。

オンライン上限を超える文書のバッチ処理

バッチ処理では、入力と出力の両方にCloud Storageのパスを指定し、長時間実行オペレーションとして完了を待ちます。入力バケットがプロセッサと別のプロジェクトにある場合は、プロセッサ側プロジェクトのDocument AIサービスエージェント（service-{プロジェクト番号}@gcp-sa-prod-dai-core.iam.gserviceaccount.com）に、そのバケットの roles/storage.objectViewer を付けます。結果は出力先に Document のJSONとして書き出されます。バケットの設計はCloud Storage（GCS）の仕組みとストレージクラスを参照してください。

request = documentai.BatchProcessRequest(
    name=name,
    input_documents=documentai.BatchDocumentsInputConfig(
        gcs_prefix=documentai.GcsPrefix(gcs_uri_prefix="gs://my-bucket/input/")
    ),
    document_output_config=documentai.DocumentOutputConfig(
        gcs_output_config=documentai.DocumentOutputConfig.GcsOutputConfig(
            gcs_uri="gs://my-bucket/output/"
        )
    ),
)
operation = client.batch_process_documents(request)
operation.result(timeout=1800)   # 完了まで最大30分待つ

旧サンプルからDocumentProcessorServiceClientへの移行

古い解説記事には、from google.cloud import documentai_v1beta3 で DocumentUnderstandingServiceClient を作り、features に DOCUMENT_TEXT_DETECTION を指定するコードが残っています。3.15.0では DocumentUnderstandingServiceClient はv1にもv1beta3にも存在せず、実行すると AttributeError で止まります。DOCUMENT_TEXT_DETECTION はCloud Vision APIの機能名で、Document AIのリクエストには指定しません。

移行先は上の documentai_v1.DocumentProcessorServiceClient と process_document で、公式クイックスタートもv1で書かれています。v1beta3のAPIは現在も提供されており、2026年3月に追加されたファインチューニング済みプロセッサのアップグレード機能のように、新機能がv1beta3にだけ先に入ることがあります。文書の処理だけならv1を使ってください。

Custom Extractorの学習方式：ゼロショットからファインチューニングまで

生成AI方式のCustom Extractorは、学習データの量に応じて3つの方式から選べます。公式の推奨件数は次のとおりです。

ただし推奨件数と実行要件は別で、v1.5でファインチューニングを実行するには学習用50件・テスト用50件以上が必要です。本番で使える安定版（Stable）は、Gemini 2.5 Flashを使う pretrained-foundation-model-v1.5-2025-05-05 と、Gemini 2.5 Proを使う v1.5-pro-2025-06-20 の2つです。2026年7月のv3.5（Gemini 3.5 Flash）や9月のv3.1 Liteはまだpreview版です。v1.4以前の基盤モデルは廃止日（v1.4は2026年3月31日）を過ぎているため、古いバージョンに固定しているプロセッサは切り替えが必要です。

ラベル付き文書で学習するカスタムモデル方式のうち、モデルベースでは学習データが最大25,000文書・100,000ページ、テストデータが最大2,000文書・8,000ページで、各ラベルがテストデータの10文書以上に現れることが条件です。テンプレートベースは学習データが最大300文書・300ページと小さく、各ラベルが学習・テストとも3文書以上あれば学習できるため、書式が固定の帳票ならこちらのほうが少ない件数で始められます。日本語帳票ではこちらが公式サポートの範囲になります。

Layout ParserによるRAG用チャンクの生成

Layout Parserは、PDF・HTML・DOCX・PPTX・XLSX・XLSMから見出し・表・リストを認識し、検索や生成AIで使いやすいチャンクに分けて返します。チャンクに祖先の見出しを含められるため、段落だけを取り出したときに「どの章の話か」が失われにくいのが特徴です。料金は初回のチャンク化込みで1,000ページあたり10米ドルです。

LAYOUT_PROCESSOR_ID = "fedcba9876543210"   # 同じロケーションに作ったLayout ParserのID
layout_parser_name = client.processor_path(PROJECT_ID, LOCATION, LAYOUT_PROCESSOR_ID)

options = documentai.ProcessOptions(
    layout_config=documentai.ProcessOptions.LayoutConfig(
        chunking_config=documentai.ProcessOptions.LayoutConfig.ChunkingConfig(
            chunk_size=500,
            include_ancestor_headings=True,   # 祖先の見出しをチャンクに含める
        )
    )
)
result = client.process_document(
    request=documentai.ProcessRequest(name=layout_parser_name, raw_document=raw, process_options=options)
)
for chunk in result.document.chunked_document.chunks:
    print(chunk.chunk_id, chunk.page_span.page_start, chunk.content[:80])

既定の版は pretrained-layout-parser-v1.0-2024-06-03（GA）です。Gemini 2.5 Flashを使うv1.5はPDFのレイアウト解析を強化したPreview版で、PDF以外のファイルを渡すとv1.0と同じ動作になります。2026年5月には、画像と表の内容を説明文として注釈する機能がGAになりました。Layout Parserはusとeuのほか単一リージョンではeurope-west4とus-central1でしか使えません。

チャンク化をオープンソースで手元で完結させたい場合はDoclingでPDFをMarkdown化してRAGに載せる手順が比較対象になります。図表まで検索対象にする設計はマルチモーダルRAGの実装方式で扱っています。

Document AIの不採用条件：国内処理・専用パーサー・運用負荷

Document AIの採用候補は、繰り返し届く帳票から決まった項目を抽出し、既存システムへ継続的に取り込む業務です。次の条件に当てはまる場合は、別の手段を先に検討してください。

• 国内でのデータ処理が契約上の義務になっている、または日本語請求書から請求番号や支払期日などを専用の学習済みパーサーで抽出したい：日本のリージョンがなく、Invoice Parserも日本語に非対応
• 単発の少量処理で項目も毎回違い、継続的なAPI連携が不要：プロセッサ作成やIAM設定の工数を含め、手作業や既存ツールと総費用を比較
• AWSやAzureに業務基盤がある：Amazon TextractやAzure AI Document Intelligenceのほうがデータ移動と権限設計が少なく済む

なお、SnowflakeのDocument AIは同名の別製品で、2026年3月16日にUIと推論メソッドが廃止されています。移行先はSnowflake Document AIの廃止とAI_EXTRACTへの移行で解説しています。

よくある質問

Google Document AIは無料で使えますか？

Enterprise Document OCRは月1,000ページまで無料です。Form Parser、Custom Extractor、Layout Parserなどには無料枠がなく、最初のページから課金されます。エラーになったリクエストには課金されません。

Document AIの料金はいくらですか？

1,000ページあたり、OCRが1.50米ドル、Layout Parserが10米ドル、Form ParserとCustom Extractorが30米ドル、分類・分割が5米ドルです。請求書などの特化型は最大10ページの1文書で0.10米ドルです。カスタムプロセッサはデプロイ中に1時間0.05米ドルのホスティング料金もかかります。

Document AIは日本語に対応していますか？

OCR、Form Parser、Layout Parser、Custom Extractorのカスタムモデル、Expense Parserは日本語に対応しています。Invoice Parserは日本語非対応で、Custom Extractorの生成AI抽出は英語だけが公式サポートです。

Google Document AIの使い方は？

Document AI APIを有効化し、コンソールでプロセッサを作成してIDを控え、Pythonなら DocumentProcessorServiceClient.process_document に文書を送ります。プロセッサごとのオンライン上限を超える文書は、バッチ上限内でCloud Storage経由の処理を使います。対応プロセッサではimageless_modeによりオンラインでも条件付きで30ページまで処理できます。

Custom Extractorとは何ですか？

取りたい項目を自分で定義して帳票から抽出するプロセッサです。Geminiを使う生成AI方式ではゼロショットから始められ、ラベル付き文書で学習するカスタムモデル方式では日本語も公式にサポートされます。

関連記事

• OCRとは？光学文字認識の仕組み・種類・精度と実装での組み込み方を解説
• Azure AI Document Intelligenceの料金・使い方・精度｜文書解析AIを実務目線で解説
• Amazon Textractとは？機能・料金・使い方と他OCRとの違いを解説
• Doclingとは？PDFをMarkdown化してRAGに載せる実装手順と採用判断
• Vertex AIとは？Google CloudのAI開発プラットフォームの機能・料金とSageMaker/Azure MLとの違いを実装者目線で解説