Azure AI Document Intelligence インボイスモデルのレスポンスタイムを短縮する実践ガイド｜S0 プランでも高速化する方法

Azure AI Document Intelligence の事前構築インボイスモデルは、請求書の自動読み取りを劇的に効率化する一方で、「数ページなのに 1 件あたり 10 秒以上かかる」「GPU を有効化すれば速くなるのでは？」といった疑問もよく聞かれます。この記事では、S0 プランで 4～5 ページの PDF が 12 秒以上かかる理由と、GPU をユーザー側で設定できない前提でレスポンスタイムを実務レベルまで短縮する具体的なチューニング方法を、アーキテクチャと実装の両面から詳しく解説します。

Azure AI Document Intelligence 事前構築インボイスモデルの位置づけ

まずは対象となるサービスを整理しておきます。Azure AI Document Intelligence（旧 Form Recognizer）は、OCR と機械学習モデルを用いて文書からテキストや構造化データを抽出するクラウドサービスです。請求書に特化したのが prebuilt-invoice（事前構築インボイスモデル） で、ベンダー名・請求日・支払期限・合計金額・明細行など、一般的な請求書項目を事前学習済みモデルで抽出します。

インボイスモデルの処理パイプラインは、おおまかに次のような流れです。

ファイル受付（PDF / 画像 / Office 形式など）のバイナリ読込
OCR エンジン（Read モデル）によるテキスト・レイアウト解析
テーブル・段組・ブロックなどの構造解析
請求書に特化したフィールド抽出・正規化（通貨や日付形式など）
JSON 形式のレスポンスとして整形・返却

このように、単なる OCR ではなく「構造解析＋フィールド抽出」まで行うため、どうしても一定の計算コストがかかります。特に、ページ数が多い PDF や、明細行が多くテーブル構造が複雑な請求書では、処理時間が伸びやすくなります。

観点	事前構築インボイスモデルの特徴
対象ドキュメント	請求書・納品書・公共料金請求書などインボイス系ドキュメント全般
主な抽出項目	ベンダー情報、請求先、請求日、支払期限、税額、合計金額、明細行（品目・数量・単価等）
対応フォーマット	PDF、JPEG/JPG、PNG、TIFF、HEIF などの画像、Office ファイル（DOCX/XLSX/PPTX）など
裏側の仕組み	Read モデルによる OCR＋レイアウト解析＋インボイス特化モデルによるフィールド抽出
利用方法	REST API / 各種 SDK（.NET, Java, JavaScript, Python）から呼び出し

GPU は手動では「有効化できない」：仕様の整理

「GPU アクセラレーションを有効化すれば速くなるのでは？」という質問は非常に多いのですが、現時点の Azure AI Document Intelligence では、ユーザーが GPU をオン・オフしたり、GPU 付きプランを明示的に選択することはできません。

Microsoft Q&A でも、同様の質問に対して次のように公式回答されています。

GPU アクセラレーションはサービス内部で管理されており、ユーザーが直接設定することはできない。
事前構築モデル（Invoice, Receipt, ID など）は、必要に応じて GPU を含む Microsoft 最適化インフラ上で動作する。
S0 プランは共有環境であり、レスポンスタイムはドキュメントのサイズ・ページ数・サービス負荷などによって変動する。
現時点では、事前構築モデル向けの「Premium GPU 専用 SKU」は提供されていない。

つまり、「GPU を有効化する設定画面がどこかにあるはず」と探しても見つかりません。GPU の有無はサービス側で自動制御されており、利用者ができるのは API バージョン・呼び出しパターン・ドキュメント構造などを工夫して、待ち時間を最小化することです。

よくある誤解	実際の仕様
Azure Portal で GPU をオンにすれば速くなる	Document Intelligence リソースには GPU オン/オフ設定は存在しない。GPU 利用はサービス内部の最適化に任される。
「S0 = CPU」「GPU プランを別途契約すれば速くなる」	どのプランでもサービス側で必要に応じて GPU バックエンドを利用。ユーザーがハードウェアを指定することは不可。
GPU を使っていないから 12 秒もかかる	レスポンスタイムの主因はページ数・レイアウトの複雑さ・同時利用状況など。GPU を使う/使わないだけの問題ではない。

S0 プランで 4～5 ページの PDF に 12 秒以上かかる理由

S0 プランは「共有環境」：同時利用状況に影響される

S0 は、いわゆるマルチテナントの共有コンピューティング環境です。専用のコンピュート（専有 GPU / 専有 VM）が割り当てられるわけではなく、同じリージョン・同じ SKU を利用する他テナントとインフラを共有します。

このため、同じ 5 ページの PDF を解析しても、時間帯によって 4 秒で終わることもあれば 12 秒以上かかることもある、という揺らぎが発生します。これは次のような要因が重なった結果です。

同じリージョンで他テナントからのリクエストが集中している
利用中のバックエンドにすでに多数のジョブがキューイングされている
自身のシステムからのリクエストが瞬間的にスパイクしている

Document Intelligence はクラウドネイティブなマネージドサービスであり、基盤側でスケールアウトは行われるものの、「常に一定以下のレスポンスタイムを保証する」サービスではない点を理解しておく必要があります。

ページ数が増えると「逐次処理」が積み上がる

もう 1 つのポイントが、ページごとに解析処理が行われるという点です。内部実装の細部は非公開ですが、概ね以下のようなイメージで処理が流れます。

ページ単位で画像レンダリング・ノイズ除去などの前処理
OCR（Read モデル）によるテキスト・行・単語検出
レイアウト解析（テーブル・セル・段組などの検出）
インボイス特化モデルによるフィールド抽出・スコア計算

これらのステップは内部的にはある程度並列化されているものの、最終的には「1 ドキュメントのすべてのページが処理完了するまでレスポンスは返らない」ため、ページ数が増えるほどレスポンスまでの時間が伸びます。4～5 ページで 12 秒というのは、サービスの設計上、十分起こり得る数値です。

レイアウトが複雑なインボイスは特に重くなりがち

同じ 5 ページでも、次のような特徴を持つドキュメントは処理時間が長くなりがちです。

明細行が数十行以上あり、テーブルが複数ページにまたがっている
セル結合や縦書き・回転テキスト・複数通貨など、レイアウトのバリエーションが多い
背景にロゴ・透かし・イラストが多く、前処理やテーブル検出に時間がかかる
スキャン品質が低く、OCR 自体に時間がかかる（高解像度ノイズ画像など）

こうした要因が重なると、GPU の有無にかかわらず、ロジック側の処理時間自体が長くなってしまう点に注意が必要です。

レスポンスタイム短縮のための具体的な改善策

ここからは、実際に運用で効く具体的なチューニング策を、優先度の高いものから順に整理していきます。

対処	内容
最新 API & モデルを使用	v4.x 系の最新 GA API を利用し、古い 2.x / 3.x 系は新規実装では極力避ける。
並列処理	5 ページを 1 件として送るのではなく、ページごとに分割して複数リクエストを並列実行し、全体の待ち時間（ウォールタイム）を短縮。
ドキュメントの簡素化	不要なロゴ・背景・画像・複雑な表を削ることでレイアウト解析の負荷を軽減。
リージョン最適化	利用者やアプリケーションが存在するリージョンにリソースを配置し、ネットワーク往復時間を削減。
サービス状態の監視	Azure Service Health / Azure Monitor で、対象リージョンの障害や高負荷状況を確認し、運用でカバー。
要望提出	より高速な専用 SKU や GPU プランが必要な場合は、サポートチケットから要望としてフィードバック。

「ページ分割＋並列実行」で体感時間を短縮する

単一の 5 ページ PDF を 1 回の API 呼び出しで処理すると、1 件あたり 12 秒かかるケースがあります。しかし、ページを分割して複数のインボイスとして並列に解析すると、全ページ完了までの「ウォールタイム」を大きく短縮できます。

例えば、次の 2 パターンを比較してみます。

パターン	構成	想定レスポンスタイム（例）	特徴
A: 単一リクエスト	5 ページ PDF を 1 回の `prebuilt-invoice` 呼び出しで解析	約 12 秒	実装は単純だが、レスポンスが返るまで待つしかない
B: ページ分割＋並列	各ページに分割（または 2 ページずつ）し、5 件のリクエストを並列実行	約 4〜6 秒（インフラ負荷に依存）	並列度を上げることで、ユーザーの体感時間を短縮できる

もちろん、並列度をむやみに上げると スロットリング（429 エラー） を招くため、アプリケーション側で 最大同時呼び出し数（例：5〜10） を決めて制御するのが実践的です。

設計のポイントは次の通りです。

1 ドキュメント = 1 API 呼び出しにこだわらず、「ページ単位」「最大ページ数ごとのチャンク」で扱う
非同期 API（ジョブベースの Analyze API）を利用し、バックエンドでジョブが完了するのをポーリング / Webhook で待つ
アプリケーションからはキュー（例：Azure Storage Queue / Service Bus）を挟んで、Function / コンテナが並列処理する構成にする

ドキュメントの事前処理で構造を「シンプルにする」

Document Intelligence の負荷を下げるためには、入力ドキュメントをできるだけシンプルにすることが最も効きます。具体的には次のような前処理が有効です。

背景・透かし・大量のロゴを除去した PDF を生成する
スキャン時の解像度を 150〜300 DPI 程度に抑え、無意味に高解像度なノイズ画像にしない
色は グレースケールで十分なケースが多い（ただし文字の視認性は要確認）
他の書類が含まれている PDF の場合は、事前にページ分割・クロップしてインボイス部分だけを渡す
明らかに不要な装飾枠やイラストが多いテンプレートは、今後の発行分から順次簡素化する

レイアウトが複雑なほど、テーブル検出やセル認識に時間がかかります。少しでも構造を単純にしてあげることで、処理時間と認識精度の両方を改善できます。

リージョン選択とネットワーク経路の最適化

Document Intelligence 自体の処理時間だけでなく、ネットワーク往復時間（RTT）もレスポンスタイムに含まれます。特にオンプレミス環境や他クラウドから呼び出す場合、RTT が数百ミリ秒〜 1 秒近くになることもあります。

次のようなポイントを押さえておきましょう。

アプリケーション（App Service / Functions / コンテナなど）と Document Intelligence リソースは、可能な限り同一リージョンに配置する
大量バッチ処理を行うバッチサーバーも、同一リージョン内の IaaS / PaaS に寄せる
VNet 統合・プライベートエンドポイントを用いる場合も、無駄な経路を通らないようネットワーク設計を見直す
HTTP Keep-Alive や接続プールを活用し、毎回 TCP ハンドシェイクや TLS ネゴシエーションを行わないようにする

サービス状態の監視と運用でのカバー

S0 のような共有環境では、サービス側の負荷や障害状況によってレスポンスが一時的に悪化することがあります。そのため、アプリケーションから見たメトリクス監視が重要です。

Application Insights や独自ロギングで 「API 呼び出し時間」「エラー率」「429（スロットル）発生数」を継続的に可視化する
Azure Monitor アラートで異常な遅延やエラー率の上昇を検知し、運用チームに通知する
Azure Service Health で対象リージョンのインシデント情報を確認し、問題が発生している時間帯はバッチ処理の実行をずらす等の対応を検討する

運用で「遅い時間帯」「エラーが出やすい時間帯」の傾向を掴めば、バッチ処理を夜間に寄せる、ピーク時間帯にはキューに溜めて後から処理するなど、アプリ側で負荷を平準化する戦略が立てやすくなります。

「ページ分割＋並列呼び出し」の設計イメージ

実務でよくあるシナリオとして、「1 つの PDF に複数の請求書が連結されている」「1 請求書が 4〜5 ページにわたっている」といったケースがあります。ここでは、それを前提にしたアーキテクチャ例を簡単に紹介します。

例：Azure Functions + キューを用いた並列処理

ユーザーまたはバッチサーバーが PDF を Azure Storage にアップロードする
アップロードトリガーで Azure Functions が起動し、PDF をページ単位に分割する
各ページ（または 2 ページ単位）ごとに キューメッセージ を生成し、「documentUrl」「pageRange」「関連する請求書 ID」などを含める
別の Functions（キュートリガー）がキューからメッセージを取り出し、prebuilt-invoice を呼び出す
結果を共通のストレージ（Cosmos DB / Blob / SQL など）に書き込み、最後に 請求書 ID 単位でマージする

この構成のメリットは次の通りです。

Functions のスケールアウトにより、自然と並列度が上がる
キューがバッファとして機能するため、Document Intelligence の一時的な遅延やスロットリングにも耐性がある
1 ページあたりの処理時間が 2〜3 秒程度であれば、5 ページでもウォールタイムは 4〜6 秒程度に収まる可能性が高い

Power Automate / Logic Apps での簡易並列化

コーディングを極力避けたい場合は、Power Automate や Azure Logic Apps で簡易的な並列化を行うこともできます。

「ファイルのページ数を取得 → 配列に展開 → 並列分岐 で各ページを呼び出し」というフローを組む
Document Intelligence コネクタ（または HTTP アクション）を利用して、ページごとに prebuilt-invoice を呼び出す
最後に「すべての分岐が完了したら結果を統合する」ステップを追加する

高度な制御（キューイングやリトライポリシー）までは難しいですが、既存フローを少し拡張するだけでレスポンスタイムを体感的に半分程度にできるケースもあります。

SKU 選択：F0 と S0 の違いと使い分け

インボイスを本番で大量に処理する場合、F0（無料枠）は避け、S0 以上を使うのが前提です。F0 はあくまで検証・学習用途であり、スループット・同時リクエスト数・ページ数に厳しめの制限があります。

項目	F0（無料）	S0（従量課金）
想定用途	検証・学習・小規模 PoC	本番・準本番環境
ページ数制限	月あたり無料ページ数に上限あり	従量課金。上限はサブスクリプションクォータに依存
スループット	制限が厳しく、遅延・スロットリングが発生しやすい	F0 より高スループット。SLA 対象
利用シナリオ	少量のテスト・デモ	業務システムでの継続利用・大量バッチ処理

本番運用で F0 を使うと、レスポンスが遅い・スロットルされる・月初にすぐ上限に達するなどのトラブルが発生しやすいため、必ず S0 以上を利用するようにしましょう。

どうしても足りない場合：Premium / 専用 SKU への要望

ここまで紹介したチューニングを行ってもなお、「1 件あたり数秒以内のレスポンスを絶対に保証したい」「数十万ページ規模を短時間で処理したい」といった要件がある場合は、現行の S0 だけでは限界があるかもしれません。

その場合の現実的なアクションは次の 2 つです。

Document Intelligence のサポートプランを契約した上で、専用 SKU・Premium プラン・プロビジョンドスループットの提供予定について問い合わせる
要件に応じて、オンプレミス / コンテナ版の利用を検討し、自前で GPU リソースを用意してスループットをコントロールする

特にコンテナ版は、自社クラウド環境やオンプレミスの Kubernetes クラスターなどで Document Intelligence の機能を実行できるため、利用可能な CPU/GPU リソースを自分たちでコントロールしたいケースに向いています。

まとめ：インボイスモデル高速化のチェックリスト

最後に、Azure AI Document Intelligence の事前構築インボイスモデルでレスポンスタイムを短縮する際のチェックリストをまとめます。

カテゴリ	チェック項目	実施状況
サービス設定	最新の v4.x GA API / SDK を利用しているか
SKU	本番では F0 ではなく S0 以上を利用しているか
アーキテクチャ	ページ分割＋並列呼び出しを設計に取り入れているか
ドキュメント	余計な装飾や複雑な表を削り、解析しやすいテンプレートに見直しているか
ネットワーク	アプリと Document Intelligence を同一リージョンに配置し、RTT を最小化しているか
運用監視	レスポンスタイム・エラー率・スロットリングを継続的にモニタリングしているか
今後の拡張	より高いスループットや専用 SKU が必要な場合、サポートチケットで要望を上げているか

繰り返しになりますが、Azure AI Document Intelligence の事前構築インボイスモデルでは、GPU をユーザー側で明示的にオンにして高速化することはできません。代わりに、

最新バージョンの API / SDK を利用する
ページ分割＋並列実行でウォールタイムを短縮する
ドキュメント構造を簡素にし、OCR・レイアウト解析の負荷を下げる
リージョンやネットワーク経路を最適化し、無駄な往復を削る
サービス状態を監視し、運用で遅延を吸収する

といったアプローチを組み合わせることで、S0 プランであっても実務に耐えうるレスポンスタイムを実現できます。現状の 1 件 12 秒という状況から、「ユーザーがストレスを感じない数秒レベル」まで近づけるために、ぜひこの記事の内容を自社システムの設計・実装・運用に反映してみてください。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Azure AI Document Intelligence インボイスモデルのレスポンスタイムを短縮する実践ガイド｜S0 プランでも高速化する方法

Azure AI Document Intelligence 事前構築インボイスモデルの位置づけ

GPU は手動では「有効化できない」：仕様の整理