Azure Document Intelligence（旧Form Recognizer）で prebuilt layout モデルを使ったところ、メトリクス上は 950 ページしか処理していないのに、1 日で 160 米ドルも請求されて驚いた──そんなケースは珍しくありません。本記事では、このような「請求が想定より高い」状況でどこを確認し、どう切り分ければよいかを、実務目線で詳しく整理します。
Azure Document Intelligence の請求が高く見えるケースの整理
まず、今回の事象を数字で整理しておきます。
| 項目 | 値 |
|---|---|
| 処理ページ数（メトリクス） | 950 ページ |
| 当日の請求額 | 160 米ドル前後 |
| 1 ページあたり実績単価 | 約 0.168 米ドル |
| 1,000 ページ換算 | 約 168 米ドル |
| 事前の想定 | prebuilt layout で 1,000 ページあたり 約 10 米ドル程度 |
Azure 公式ドキュメントや Q&A などでは、従量課金（S0）の代表的な単価として、
- Read モデル：1,000 ページあたり 約 1.5 米ドル
- prebuilt モデル（Document / Layout / Invoice / Receipt など全般）：1,000 ページあたり 約 10 米ドル
- Custom extraction / Generative extraction：1,000 ページあたり 30〜50 米ドル程度
- Add-on（高解像度 OCR / フォント / 数式認識など）：1,000 ページあたり 約 6 米ドル
といった水準が案内されています（リージョンやプランにより差異あり）。
今回の実績単価「約 168 米ドル / 1,000 ページ」は、prebuilt layout 単体の想定価格（約 10 米ドル / 1,000 ページ）と比べて 16 倍以上 高い水準です。したがって、単純な「prebuilt layout を 950 ページだけ回したコスト」では説明できず、
- 別のモデルや Add-on を同時に使っている
- 同じページを複数回処理している（再試行や複数モデルへのパイプライン）
- 別リージョン / 通貨 / 税 / 為替やコミットプランなど、料金テーブルの前提が異なる
- メトリクスに出ていない課金メーターがある
といった要因が複数重なっている可能性が高いと考えられます。
Azure Document Intelligence の料金体系をざっくり整理
モデル種別と課金単価の関係
Azure AI Document Intelligence（旧 Form Recognizer、現 Foundry Tools 内 Document Intelligence）は、モデル種別ごとに単価が大きく異なります。
| モデル種別 | 代表的な機能 | 代表的な単価イメージ （S0 / 1,000 ページあたり、米ドル） | 補足 |
|---|---|---|---|
| Read | 単純な OCR（テキスト抽出中心） | 約 1.5 米ドル | 最も安価。構造解析は薄い。 |
| Prebuilt（Document / Layout など） | レイアウト / 構造 / 一般ドキュメント抽出 | 約 10 米ドル | layout モデルはここに含まれる。 |
| Prebuilt（Invoice / Receipt / ID 等） | 請求書・レシート・身分証などの専用モデル | 約 10 米ドル | 項目抽出に特化したスキーマ。 |
| Custom classification | ドキュメント分類 | 約 3 米ドル | 分類だけを行う用途。 |
| Custom extraction / Generative extraction | カスタム抽出 / 生成抽出 | 約 30〜50 米ドル | 高度な抽出。料金も高め。 |
| Add-on（高解像度 / フォント / 数式など） | 高解像度 OCR、スタイル解析、数式認識 | 約 6 米ドル | 他モデルに追加課金として上乗せ。 |
| Free tier（F0） | 月 500 ページまでの無料枠 | 0 米ドル（上限まで） | 検証向け。超過分は有料。 |
ここで重要なのは、prebuilt layout モデルは「prebuilt モデル」扱いであり、安価な Read モデル（約 1.5 米ドル / 1,000 ページ）とは別の単価テーブルで計算される、という点です。
「1 ページあたり」の意味と、複数モデル実行の罠
Azure Document Intelligence の課金は「モデル × ページ数」で行われます。同じ 1,000 ページを次のように処理した場合を考えてみます。
- Read モデルで 1 回処理
- prebuilt layout で 1 回処理
- prebuilt invoice で 1 回処理
このときの課金対象ページ数は、
- Read：1,000 ページ
- Layout：1,000 ページ
- Invoice：1,000 ページ
の合計 3,000 課金ページになります。さらに、ネットワーク障害などで同じバッチが 2 回リトライされると、単純に課金ページが 2 倍〜3 倍にふくらみます。
今回のケースで「メトリクス上は 950 ページなのに、請求ベースでは 16 倍近い単価になっている」という状況は、
- 実際には別メーターで数千ページ相当の課金が発生している
- それがメトリクス画面では一部しか見えていない
ことを示唆しています。
Foundry Tools 化による名称の違い
近年、Azure の AI サービスは「Foundry Tools」として再編され、Document Intelligence もその一部として提供されています。
そのため、コスト分析や使用量 CSV では、
Azure AI Document IntelligenceDocument Intelligence in Foundry ToolsCognitive Services内の個別メーター
のように、やや異なる名称で記録されているケースがあります。「自分が見ている料金表のサービス名」と「実際に請求されているメーター名」が完全には一致しないことがある点には注意が必要です。
950 ページで 160 ドルになり得る代表的なパターン
あくまで概算ですが、「prebuilt layout を 950 ページだけ回した」場合と、「他のモデルやオプションが混ざった」場合のコスト感を比較してみます。
| パターン | 実行内容のイメージ | 単価イメージ（1,000 ページ） | 950 ページ実行時の概算 |
|---|---|---|---|
| A：layout だけ | prebuilt layout 1 回のみ | 約 10 米ドル | 約 9.5 米ドル |
| B：layout + Add-on + 再実行 | layout + 高解像度 Add-on、バッチ再実行 2 回 | （10 + 6） × 3 回 = 48 米ドル | 約 45.6 米ドル |
| C：layout + custom extraction | layout で構造抽出後、custom extraction で項目抽出 | 10 + 30〜50 = 40〜60 米ドル | 約 38〜57 米ドル |
| D：B + C が複合 | layout + Add-on + custom extraction + 再試行複数回 | 40〜60 + 追加実行分 | 合計 160 米ドル超も十分あり得る |
実際の請求額は、リージョン・通貨・コミットプラン・税などの条件で変動しますが、概ねこのように、
- 高単価モデル（custom 系）を組み合わせる
- Add-on を併用する
- 同じページに対して複数回実行または再試行が走る
と、1,000 ページあたりの実効単価が簡単に 100 米ドルを超えてしまいます。
まずやるべき確認：コスト分析と Usage CSV
請求が想定より高いと感じたら、真っ先にやるべきは 「どのメーターで、いくら課金されたのか」を数字で特定することです。
Azure Cost Management でメーター内訳を確認
- Azure ポータルで「Cost Management + Billing」を開く。
- 「コスト分析」を選択し、対象サブスクリプションを選ぶ。
- 期間を問題の日（例：2025-09-11）に絞る。
- フィルターで「サービス」「リソース」を絞り込む。
- サービス：
Azure AI Document Intelligenceもしくは Foundry Tools / Cognitive Services 内の Document Intelligence 相当 - リソース：対象の Document Intelligence リソース
- サービス：
- 「グループ化」を「メーター名」「リソース名」「リージョン」などに設定し、どのメーターでいくら発生しているかを確認する。
ここで、例えば次のようなメーターが見つかります。
- Prebuilt / Layout / Document に該当するメーター
- Invoice / Receipt / ID など、別の prebuilt モデルのメーター
- Custom extraction / Generative extraction のメーター
- Add-on（高解像度 / フォント / 数式など）のメーター
「layout しか使っていないはず」と思っていても、ここに別メーターが載っていれば、その分だけ余計に課金されています。
Usage CSV をダウンロードして「Quantity × UnitPrice」を突合
Cost Management から「使用状況の詳細（Usage details）」を CSV でエクスポートし、Excel などで開きます。CSV には、次のような列が含まれます。
| 列名 | 役割 |
|---|---|
MeterName | どのメーター（prebuilt / custom / Add-on 等）か |
Product / Service | サービス名（Document Intelligence in Foundry Tools 等） |
ResourceLocation | リージョン（Japan East / East US 等） |
Quantity | 課金対象の数量（ページ数など） |
UnitPrice | 1 単位あたりの単価 |
Cost | その行の合計コスト = Quantity × UnitPrice |
これを使って、
- 日付を 2025-09-11 にフィルター
- MeterName ごとに
QuantityとCostを集計 - 「prebuilt layout 以外のメーター」がどれだけの割合を占めているかを確認
すると、「実は custom extraction が 3,000 ページ分走っていた」「Add-on が 950 ページ分すべてに付いていた」といった実態が見えてきます。
アプリ側ログで確認すべきポイント
Cost Management / CSV で「どのメーターで高額請求になっているか」が分かったら、次はアプリ側の実行内容と突き合わせます。
モデル ID とオプションをコード／ログで確認
SDK や REST API の呼び出しログから、次の点を重点的に確認します。
- 実際に呼び出しているモデル ID
prebuilt-layoutのみか？prebuilt-documentなど別の prebuilt を併用していないか？- 請求書（invoice）やレシート（receipt）などの専用モデルを使っていないか？
- オプションの有無
- 高解像度 OCR オプション
- スタイル / フォント解析
- 数式認識
- Query Fields（問い合わせ項目指定）
- リトライ回数
- HTTP 429 / 5xx などのエラーで自動再試行が何回走っているか
- アプリ側のリトライロジックと SDK 標準のリトライが二重になっていないか
- バッチ処理の構成
- 1 バッチで同じファイルに対して複数モデルを適用していないか
- テスト用の同じデータを本番でも繰り返し流していないか
「コード上は layout しか呼んでいないつもりでも、実際には別の関数呼び出しで invoice モデルも叩いていた」といったケースは現場でもよくあります。
Document Intelligence リソースのメトリクスと照合
Document Intelligence リソースの「メトリック」や「診断ログ」を有効化している場合、
- 総ページ数
- リクエスト数
- 失敗・再試行の件数
- モデル別の呼び出し回数
といった値を時系列で確認できます。公式の「コスト推定」ドキュメントでも、メトリクスを元に Azure Pricing Calculator でコストを見積もる方法が紹介されています。
メトリクス側の「ページ数」と CSV の Quantity を突き合わせ、「どこから差が出ているか」を見るのが、原因特定の近道です。
請求が高くなる代表的な原因の深掘り
想定と異なるモデル・機能を使っている
最も多いのが、「自分では layout だけのつもりなのに、他の prebuilt / custom / Add-on も同時に使っていた」パターンです。
- Power Apps / Logic Apps / Power Automate などから呼び出していて、裏側で複数モデルを叩いている
- アプリ側で「レイアウト解析 → custom 抽出 → Add-on」というパイプラインを組んでいて、すべて課金対象になっている
- レシート / 請求書専用モデルをお試しで入れたまま、本番データにも適用してしまっている
対策として、layout 専用のエンドポイントや関数を分離し、他のモデル・機能に触れないコードパスを明確に用意しておくと安全です。
リージョン・通貨・税込 / 為替の差
Azure の料金表はリージョンごとに微妙に異なります。また、課金通貨（USD / JPY 等）や税（消費税）、為替レートの影響も受けます。料金表ページでは、リージョンを選択して単価を確認できますが、見ていたページが別リージョンだったり、古いスナップショットだったりすることもあります。
必ず、
- 実際にリソースをデプロイしたリージョン
- サブスクリプションの請求通貨
- 税（内税 / 外税）の扱い
を確認し、「自分が見ている料金表が本当にその条件に対応しているか」をチェックしましょう。
「ページ」のカウント方式の違い
Document Intelligence の「ページ」は、次のような要因で想定より多くカウントされることがあります。
- PowerPoint：1 スライド = 1 ページ換算
- Excel：ワークシートごとにページ換算されるケース
- マルチページ TIFF / PDF：サムネイルや埋め込み画像も含めてカウントされる場合
- 添付ファイル付き PDF：本体と添付を別々に処理している場合、合計ページ数が増える
また、失敗したリクエストやタイムアウトしたリクエストが、再試行によって再度ページ課金される可能性もあります。メトリクス画面が「成功したページ数だけ」をカウントしている場合、請求上のページ数の方が多くなることがあります。
コミット（前払い）やバッチ / 高解像度実行による単価差
Document Intelligence には、一定量を前払いするコミットプランや、バッチ処理専用の料金メニューが用意されています。コミット枠を超過した部分は「オーバーユニット」として別単価になるなど、料金体系が変わることがあります。
また、
- 高解像度 OCR
- フォント / スタイル解析
- 数式認識などの Add-on
を有効にすると、ベースのモデル料金に加えて Add-on 分の料金（例：6 米ドル / 1,000 ページ）が上乗せされます。prebuilt layout に Add-on を付けると、それだけで実質単価が 1.5〜2 倍程度になることがあります。
メトリクスと請求の不整合（遅延・可視範囲の差）
Azure 全般に言えることですが、ポータルのメトリクスと請求データの間には、集計タイミングや粒度の違いがあります。Document Intelligence の場合も、
- メトリクス：特定の API / 成功分のみをカウント
- 請求：失敗 / 再試行 / 別 API も含めて課金メーターに計上
という差異が生じることがあります。そのため、「メトリクス上の 950 ページ ＝ 課金ページ数 950」ではない点に注意が必要です。
価格表の読み違い / 古い情報
Microsoft Q&A やブログなどでは、
- Read：1,000 ページで 1.5 米ドル
- prebuilt：1,000 ページで 10 米ドル
といった例が紹介されていますが、ここでしばしば起きるのが、layout を Read と同じ 1.5 米ドル / 1,000 ページだと誤解するパターンです。実際には layout は prebuilt グループであり、10 米ドル / 1,000 ページ側に属します。
さらに、料金表は頻繁に更新されるため、検索でヒットした古いブログやキャプチャをそのまま信じるのは危険です。最終的な判断は必ず公式の料金ページで行いましょう。
最低料金・端数処理
Azure の請求では、
- ページ単価の小数点以下の丸め
- 通貨換算（為替レート）の丸め
- 税計算の端数
などによって、数セント〜数十セント単位の誤差は日常的に発生します。ただし、今回のように「期待値 10 米ドル vs 実績 160 米ドル」というオーダーの差を、これだけで説明することはできません。大きな差が出ている場合は、ほぼ確実に 別メーターの追加課金が原因です。
コンテナー版 / エッジ実行の別料金
Document Intelligence には、クラウド API だけでなく、コンテナー版やエッジ実行のオプションもあります。コンテナーを「接続モード（Connected Container）」で利用する場合、クラウドと同じ従量課金体系が適用される一方で、オフライン運用（Air-gapped）では別契約・別料金になることがあります。
もしエッジ環境でコンテナーを利用している場合は、契約内容や利用モード（接続 / 非接続）も併せて確認しておくとよいでしょう。
日々の運用でコスト事故を防ぐための設計・運用のコツ
layout 専用パスを分離し、高単価モデルを明示的に切り替える
アプリ設計として、
- layout 専用の API 呼び出しパス
- custom / Add-on を含む高単価パス
をコードレベルで明確に分離しておくと、意図せぬ高額モデルの利用を防ぎやすくなります。具体的には、
- layout 用のクライアントインスタンスやサービスクラスを別ファイルに定義
- 高単価モデルを使う関数には「要レビュー」「高コスト」などのコメントや命名ルールを付ける
- Pull Request テンプレートに「新たに高額モデルを追加していないか？」のチェック項目を入れる
といった工夫が有効です。
日次のコスト予算アラート・異常検知を設定する
Azure Cost Management の「予算（Budget）」機能を使うと、
- 特定のサブスクリプション / リソースグループ / タグ単位で月次予算を設定
- 80% / 100% などの閾値に達した際にメールやアラートを飛ばす
といった運用ができます。Document Intelligence 用のリソースに tag: service=document-intelligence のようなタグを付けておき、そのタグ単位で予算アラートを設定しておくと、想定外の急増を早期に検知できます。
最近はコストの異常検知（anomaly detection）機能も強化されているため、「前日比で 200% 以上増加したら通知」といった設定も組み合わせると安心です。
入力制御で「ページ爆発」を防ぐ
想定外にページ数が増える典型パターンとして、
- 数百シートある巨大な Excel ファイルをそのまま投げてしまう
- 何百ページものスキャン PDF を一括で処理してしまう
- Zip 内のドキュメントをすべて展開して一括処理してしまう
といったケースがあります。対策として、
- 1 ドキュメントあたりの最大ページ数や最大ファイルサイズをアプリ側で制限する
- スライド / シートの数が多い場合は、ユーザーに分割アップロードを促す
- テスト環境では意図的に 1〜2 ページのサンプルだけを使う
などのガードレールを設けておくと、「気づいたら数万ページ分を一晩で回していた」という事故を減らせます。
SDK のリトライ上限・タイムアウトを適切に調整する
Azure の SDK（例：azure-ai-formrecognizer）には、標準でリトライ機能が組み込まれています。さらに、アプリ側で独自にリトライロジックを実装していると、
- ネットワークの一時的な失敗で 3 回リトライ → 合計 4 回課金
- 429（スロットリング）に対して過剰にリトライ → コストだけ増える
といった事態になりかねません。
リトライ回数・タイムアウト・バックオフ戦略を見直し、
- maxRetries を 2〜3 回程度に抑える
- アプリ側のリトライと SDK のリトライが二重にならないように整理
- スロットリングが頻発する場合は、そもそものスループット設計（並列度）を見直す
といった対応を行うと、無駄な再試行コストを抑えられます。
具体的な調査シナリオのイメージ
ここまでの話を踏まえ、「950 ページで 160 米ドル」というケースをどのように切り分けていくか、具体例の形で整理します。
ステップ 1：メーター内訳の仮想例
Usage CSV を 2025-09-11 でフィルターした結果、次のような集計になっていたとします。
| MeterName（例） | Quantity | UnitPrice | Cost | コメント |
|---|---|---|---|---|
| S0 Prebuilt Layout Pages | 950 | 0.01 | 9.5 | 想定どおりの layout 分 |
| S0 Custom Extraction Pages | 3,000 | 0.04 | 120 | 高単価 custom が多く走っている |
| S0 Add-on High Resolution Pages | 950 | 0.006 | 5.7 | 全ページに高解像度 Add-on が付与 |
| その他（Read 等） | 数百 | 0.0015 | 数十セント | 影響は小さい |
この仮想例では、
- layout 分：9.5 米ドル
- custom extraction 分：120 米ドル
- Add-on 分：5.7 米ドル
- その他：数十セント
といった構成で、合計が 160 米ドル前後になります。このように、「layout 以外のメーター」が大半を占めていることが確認できれば、原因は custom や Add-on 側にあると判断できます。
ステップ 2：アプリの処理フローと照合する
次に、アプリ側のコードやログを見て、
- layout で構造抽出後、custom extraction で項目抽出していないか
- それを 950 ページ分すべてに対して実行していないか
- エラーが出たときに、同じドキュメントを何度も再送していないか
を確認します。もし、
- 「レイアウト解析 → custom 抽出 → 高解像度 Add-on 付き」
という処理を 3 回リトライしていた場合、実質的には、
- layout：950 ページ × 3 回
- custom：950 ページ × 3 回
- Add-on：950 ページ × 3 回
が課金対象となり、単価テーブル次第では 160 米ドルを軽く超えてしまいます。
ステップ 3：それでも不明ならサポートにエスカレーション
Cost Management / Usage CSV / アプリログを突き合わせてもなお原因が絞り切れない場合は、Microsoft サポートに問い合わせるのが最短ルートです。その際は、次の情報をまとめて添付すると解析がスムーズです。
- 問題となった日付（例：2025-09-11）
- Usage CSV の抜粋（MeterName / Quantity / UnitPrice / Cost）
- Cost Management のスクリーンショット（メーター別コスト）
- アプリログの抜粋（モデル ID・リクエスト件数・再試行回数が分かる部分）
- 参照していた料金表の URL とリージョン設定
ここまで整理してからサポートに投げると、「950 ページ vs 160 米ドルの差分がどのメーターで発生しているか」をかなり高い精度で特定してもらえます。
つまずきやすいポイントの整理
最後に、Azure Document Intelligence の請求周りで、特につまずきやすいポイントをコンパクトにまとめます。
| ポイント | ありがちな勘違い | 正しい理解 |
|---|---|---|
| モデル種別 | layout は Read と同じくらい安い | layout は prebuilt グループで、Read より高い単価 |
| ページ定義 | メトリクスのページ数 ＝ 請求ページ数 | 失敗・再試行・別モデル分は別メーターで課金されることがある |
| 複数モデル | 1 ドキュメントを 3 モデルで処理しても 1 回分の課金 | 「モデル × ページ」で課金されるので実質 3 倍 |
| Add-on | オプションだから無料か、誤差レベル | 1,000 ページあたり数ドル単位で上乗せされる |
| 料金表 | ブログや Q&A の古い情報をそのまま信じる | 最終的な単価は必ず公式料金ページと自テナント条件で確認 |
まとめ：原因メーターを特定できれば、対策は立てやすい
今回のように、「prebuilt layout を 950 ページ処理したつもりなのに 160 米ドルも請求された」というケースでは、
- layout 以外の prebuilt / custom / Add-on が混在している
- リージョン / 通貨 / 税・為替、コミットプランなどの条件が想定と違う
- 同じページを複数モデルや再試行で繰り返し処理してしまっている
- メトリクス画面では見えていない課金メーターが存在する
といった要因が複合的に絡んでいる可能性が高いです。
最短ルートで原因にたどり着くための手順は、次の 3 ステップです。
- Azure Cost Management と Usage CSV で「どのメーターで何ドル発生しているか」を数値で特定する。
- アプリのログから「どのモデルを・どのオプション付きで・何回呼び出したか」を洗い出し、メーターと突き合わせる。
- 不明点は整理した証跡を添えて Microsoft サポートへエスカレーションする。
原因メーターさえ分かってしまえば、
- 不要なモデル / オプションの無効化
- layout 専用パスの分離やリトライ制御の見直し
- 入力ファイル制御や日次コストアラートの導入
- リージョン・料金表の再確認と、必要であればデプロイ先の見直し
といった具体的な対策につなげることができます。Azure Document Intelligence は非常に強力なサービスですが、「モデル × ページ」の課金構造を正しく理解し、コストガードレールを設計しておくことが、安心して本番運用するための鍵になります。
コメント