--- title: "Azure Content Understandingとは？Document Intelligenceとの違い・料金・REST APIの使い方【2026年10月】" url: "https://www.issoh.co.jp/tech/details/18399/" published: 2026-10-16 updated: 2026-10-16 categories: ["開発"] publisher: "株式会社一創" --- # Azure Content Understandingとは？Document Intelligenceとの違い・料金・REST APIの使い方【2026年10月】 Azure Content Understandingは、文書・画像・音声・動画を生成AIで読み取り、利用者が定義したスキーマどおりのJSONに変えるMicrosoft Foundry Toolsのサービスです。2025年11月にAPI版`2025-11-01`で一般提供（GA）となり、2026年10月時点では`2026-06-01-preview`でエージェント型の解析などが試せる状態です。この記事では、アナライザーとスキーマの仕組み、3層に分かれる料金の見積もり方、Japan Eastでの既定モデルの設定、curlとPython SDKでの解析とカスタムアナライザー作成の手順をコード付きで示します。最後に、Document Intelligenceとの選び分けと、採用する条件・見送る場面を言い切ります。 ## まとめ｜Content Understandingは生成AIで文書・音声・動画を構造化する Content Understandingの中心は「アナライザー」です。抽出したい項目をスキーマで定義すると、OCRやレイアウト解析の結果を生成モデルに渡し、値の抽出・要約の生成・分類までを1回の呼び出しで返します。GA以降は生成モデルを自前で用意する方式に変わったため、Foundryに`gpt-5.2`などのモデルをデプロイし、既定モデルとして登録してから使い始めます。 料金はContent Understanding側の「コンテンツ抽出」「コンテキスト化」と、Foundry側の「生成モデルのトークン」の3層です。見積もりは、代表的なファイルを数件解析し、応答の`usage`に出る実測値に単価を掛けて求めます。 新しくOCRやレイアウト抽出を組むなら、Microsoftの公式ガイドどおりContent Understandingから評価を始めます。書式がばらばらな帳票や、音声・動画を含む前処理に向くサービスです。一方、オンプレミスや閉域で動かす必要がある案件、ラベル付きの定型帳票を大量に処理していて現行の精度に不満がない案件は、Document Intelligenceのまま使い続けます。 ## Content Understandingの仕組み：アナライザーとスキーマと生成モデル ### アナライザーが入力を構造化データへ変える処理の流れと3つのメソッド [Microsoft Learnの概要](https://learn.microsoft.com/ja-jp/azure/ai-services/content-understanding/overview)によると、Content Understandingは非構造化データを、後段のアプリやRAGがそのまま使える構造化出力に変える生成AIサービスです。処理は2段階に分かれます。まず文書ならOCRとレイアウト解析、音声・動画なら文字起こしでコンテンツを取り出し、次にその結果とスキーマを生成モデルに渡して項目の値を決めます。 スキーマの各項目には`method`を指定します。文書に書かれた値をそのまま取る`extract`、文面から要約や推論で値を作る`generate`、決められた候補から選ぶ`classify`の3種類です。GA版では`method`は省略でき、省略するとサービスが項目ごとに方式を選びます。`extract`はスキーマ制限の表で文書だけが対象とされており、画像・音声・動画では`generate`と`classify`を使います。 出力の各項目には、値に加えて信頼度（confidence）と、元の文書のどこから取ったかを示す位置情報が付きます。人の確認に回すかどうかを、この信頼度でしきい値判定できる点が実務で効きます。 ### GA版2025-11-01と2026-06-01-previewで使える機能の違い [新機能のページ](https://learn.microsoft.com/ja-jp/azure/ai-services/content-understanding/whats-new)では、GA版とプレビュー版で使える機能がはっきり分かれています。2026年10月16日時点の主な違いは次のとおりです。 | 機能 | 2025-11-01 | 2026-06-01-preview | | ---------------- | ---------- | ------------------ | | SLA | あり | なし | | 項目の抽出・生成・分類 | 対応 | 対応 | | 全項目の信頼度と根拠 | 対応 | 対応 | | エージェント型の解析 | 非対応 | 対応 | | read・layoutの同期処理 | 非対応 | 対応 | | 署名の検出 | 非対応 | 対応 | エージェント型の解析は`config.workflow`に`agentic`を指定すると有効になり、複数段の計算や条件への適合チェックのように、1つの値を抜き出すだけでは答えが出ない項目を扱えます。ただし初期プレビューは1回の解析で1ファイルまでです。本番の処理はGA版で組み、プレビューは評価用の環境に分けて試すのが安全です。 ### プリビルトアナライザーの5系統：抽出・基本・RAG・業種別・ユーティリティ 自分でスキーマを書かなくても使えるのがプリビルトアナライザーです。[プリビルトアナライザーの一覧](https://learn.microsoft.com/ja-jp/azure/ai-services/content-understanding/concepts/prebuilt-analyzers)では、用途別に次の系統に分かれています。 ``` # コンテンツ抽出（生成モデル不要） prebuilt-read / prebuilt-layout / prebuilt-digitalParse # 基本（カスタムアナライザーの土台） prebuilt-document / prebuilt-image / prebuilt-audio / prebuilt-video # RAG向け（文書・画像・音声・動画をMarkdownと要約に） prebuilt-documentSearch / prebuilt-imageSearch / prebuilt-audioSearch / prebuilt-videoSearch # 業種別（請求書・領収書・本人確認書類・契約書など） prebuilt-invoice / prebuilt-receipt / prebuilt-idDocument / prebuilt-contract ほか ``` readとlayoutは2025年12月の更新で生成モデルの設定が不要になり、Document IntelligenceのOCR・レイアウト解析に相当する処理を単独で担います。業種別には米国の税務書類や住宅ローン書類向けが多く、日本の帳票向けの専用アナライザーはこの一覧に見当たりません。日本の請求書なら`prebuilt-invoice`を試すか、`prebuilt-document`を土台にカスタムアナライザーを作ることになります。 ## 料金の見積もり：コンテンツ抽出・コンテキスト化・モデル課金の3層 ### 文書のメーター3種、minimal・basic・standardが決まる条件 [料金の解説ページ](https://learn.microsoft.com/ja-jp/azure/ai-services/content-understanding/pricing-explainer)によると、文書のコンテンツ抽出は1,000ページ単位の従量課金で、メーターは選んだアナライザーではなく実際に行った処理で決まります。 | ファイルの種類 | read相当 | layout相当 | | --------------- | ------- | -------- | | スキャンPDF・画像 | basic | standard | | DOCX・XLSX・HTML等 | minimal | minimal | デジタルのOfficeファイルは、layoutのアナライザーで解析してもOCRが走らないためminimalで課金されます。テキストやメールは3,000文字で1ページ、XLSXは1シートで1ページと数える規則も[サービスの上限ページ](https://learn.microsoft.com/ja-jp/azure/ai-services/content-understanding/service-limits)に書かれています。 生成機能を使うと、コンテキスト化の料金が加わります。1ページを1,000トークンと数え、解説ページの試算前提では標準が1,000ページあたり1ドル、ラベル付きサンプルで学習させたカスタムアナライザーやエージェント型に適用される上位の料金が3ドルです。円建ての実額は[価格ページ](https://azure.microsoft.com/ja-jp/pricing/details/content-understanding/)でリージョンを選んで確認します。 ### usageオブジェクトの実測値から月間コストを見積もる手順と増える要因 生成モデルのトークン料金は、Content Understandingではなく接続したFoundryのデプロイ側に計上されます。請求書が2か所に分かれるので、見積もりは解析の応答に含まれる`usage`を見て両方を足し合わせます。 ``` "usage": { "documentPagesStandard": 2, "contextualizationTokens": 2000, "tokens": { "gpt-5.2-input": 10400, "gpt-5.2-output": 360 } } ``` この例なら、layout相当の抽出2ページ分、コンテキスト化2,000トークン分、`gpt-5.2`の入力10,400・出力360トークン分の料金がかかります。代表的なファイルを10件ほど解析し、1件あたりの平均に月間件数を掛けると概算が出ます。 トークンを増やす要因は、信頼度と根拠の出力、学習用サンプルの参照、分割と分類の追加呼び出しです。信頼度が要らない項目では`estimateFieldSourceAndConfidence`を切ると下がります。400エラーで失敗したリクエストには、抽出とコンテキスト化の料金はかかりません。 ## 検証環境の準備：Japan EastのFoundryリソースと既定モデルの設定 ### Japan Eastを含む対応12リージョンと日本語OCR・手書きの対応状況 [リージョンと言語のページ](https://learn.microsoft.com/ja-jp/azure/ai-services/content-understanding/language-region-support)には、2026年10月時点で12のリージョンが載っており、日本からは`japaneast`を選べます。保存データは選んだリージョンに置かれる仕様です。ただし生成モデルをGlobalデプロイで動かすと推論は別リージョンで行われる場合があるため、データの所在に制約がある案件はデプロイ種別まで確認します。 言語は、印刷文字のOCRに日本語（`ja`）が含まれ、手書き文字の対応言語12種にも日本語が入っています。日付や数値の正規化も`ja-JP`に対応しており、和暦や全角数字の扱いは、代表的な帳票で結果を見て確かめるのが確実です。 リソースはAzureポータルでMicrosoft Foundryリソースとして作成します。Foundryの全体像やAzure OpenAIとの関係は[Azure AI Foundryとは](https://www.issoh.co.jp/tech/details/7168/)、リソース種別の違いは[Azure AI ServicesとAzure OpenAI Serviceの違い](https://www.issoh.co.jp/tech/details/16635/)で整理しています。 ### PATCH defaultsで既定のcompletionとembeddingを登録する GAの時点で、プレビュー期間にあったMicrosoft管理の生成モデルは廃止されました。[REST APIのクイックスタート](https://learn.microsoft.com/ja-jp/azure/ai-services/content-understanding/quickstart/use-rest-api)どおり、Foundryにデプロイしたモデルを既定として登録します。キーの左側がモデル名、右側が自分で付けたデプロイ名です。 ``` export CU_ENDPOINT="https://.services.ai.azure.com" export CU_KEY="" curl -i -X PATCH "$CU_ENDPOINT/contentunderstanding/defaults?api-version=2025-11-01" \ -H "Ocp-Apim-Subscription-Key: $CU_KEY" \ -H "Content-Type: application/json" \ -d '{ "modelDeployments": { "gpt-5.2": "gpt-5.2", "text-embedding-3-large": "text-embedding-3-large" } }' ``` 上限ページには`gpt-5.5`から`gpt-4o-mini`までのチャット補完モデルと、埋め込みモデル3種が並び、2026年4月の更新で`gpt-5.2`が推奨になりました。費用を抑えたいときは、解説ページの勧めどおりminiモデルから品質を確かめます。readとlayoutだけを使うなら、この設定は不要です。 ## REST APIとPython SDKで請求書を解析し、カスタムアナライザーを作る ### prebuilt-invoiceをcurlで呼び出し、非同期の結果を取得する 解析は非同期です。POSTは`202 Accepted`と`Operation-Location`ヘッダーを返し、そのURLを`Succeeded`になるまでポーリングします。次のスクリプトは、公式サンプルの請求書PDFを解析し、取れた項目名を一覧にします（`jq`を使います）。 ``` #!/usr/bin/env bash set -euo pipefail API="api-version=2025-11-01" SAMPLE="https://github.com/Azure-Samples/azure-ai-content-understanding-python/raw/refs/heads/main/data/invoice.pdf" OP=$(curl -s -i -X POST "$CU_ENDPOINT/contentunderstanding/analyzers/prebuilt-invoice:analyze?$API" \ -H "Ocp-Apim-Subscription-Key: $CU_KEY" \ -H "Content-Type: application/json" \ -d "{\"inputs\":[{\"url\":\"$SAMPLE\"}]}" \ | grep -i '^operation-location:' | cut -d' ' -f2 | tr -d '\r') while true; do BODY=$(curl -s "$OP" -H "Ocp-Apim-Subscription-Key: $CU_KEY") STATUS=$(echo "$BODY" | jq -r .status) echo "status: $STATUS" [ "$STATUS" = "Succeeded" ] && break [ "$STATUS" = "Failed" ] && { echo "$BODY"; exit 1; } sleep 2 done echo "$BODY" | jq '.result.contents[0].fields | keys' echo "$BODY" | jq '.result.contents[0].fields.TotalAmount' echo "$BODY" | jq '.usage' ``` クイックスタートは、`Running`や`NotStarted`の間は1〜2秒間隔で再取得するよう案内しています。応答の`contents[0].markdown`には文書全体のMarkdownが入るので、項目抽出と同時にRAG用のテキストも得られます。 ### fieldSchemaを書いたカスタムアナライザーをPUTで作成する手順 自社の帳票に合わせるなら、[カスタムアナライザーのチュートリアル](https://learn.microsoft.com/ja-jp/azure/ai-services/content-understanding/tutorial/create-custom-analyzer)の形でスキーマを書きます。次の例は、請求書から取引先・日付・金額を抜き出し、支払条件を1文に要約させる設定です。 ``` cat > invoice_jp.json <<'EOF' { "description": "国内請求書の項目抽出", "baseAnalyzerId": "prebuilt-document", "models": { "completion": "gpt-5.2", "embedding": "text-embedding-3-large" }, "config": { "returnDetails": true, "estimateFieldSourceAndConfidence": true, "tableFormat": "html" }, "fieldSchema": { "fields": { "VendorName": { "type": "string", "method": "extract", "description": "請求書の発行元の会社名" }, "InvoiceDate": { "type": "date", "method": "extract", "description": "請求日" }, "TotalAmount": { "type": "number", "method": "extract", "description": "税込の請求金額" }, "PaymentTerms": { "type": "string", "method": "generate", "description": "支払期限と支払方法を1文で要約" } } } } EOF curl -i -X PUT "$CU_ENDPOINT/contentunderstanding/analyzers/invoice_jp_v1?api-version=2025-11-01" \ -H "Ocp-Apim-Subscription-Key: $CU_KEY" \ -H "Content-Type: application/json" \ -d @invoice_jp.json ``` 作成も非同期で、`201 Created`の`Operation-Location`を`succeeded`になるまで確認します。つまずきやすいのはアナライザーIDの規則で、上限ページでは英数字・ピリオド・アンダースコアの1〜64文字とされ、ハイフンは使えません。項目は1アナライザーあたり1,000個まで定義できます。 プレビュー期間に作ったアナライザーは、そのままではGA版で動きません。分類の専用APIが廃止され`contentCategories`に統合されたなどの変更があるため、[プレビューからGAへの移行ガイド](https://learn.microsoft.com/ja-jp/azure/ai-services/content-understanding/how-to/migration-preview-to-ga)に沿って作り直します。 ### Python SDK 1.1系でbegin\_analyzeを呼び、値と信頼度を読む 2026年3月に各言語のSDKがGA版APIを対象として一般提供となり、Microsoftは本番ではREST直呼びよりSDKを勧めています。PyPIの`azure-ai-contentunderstanding`は2026年10月16日時点で安定版が1.1系、プレビュー版が1.2.0b3です。 ``` # 事前に: pip install "azure-ai-contentunderstanding>=1.1,<1.2" import os from typing import cast from azure.ai.contentunderstanding import ContentUnderstandingClient from azure.ai.contentunderstanding.models import AnalysisInput, DocumentContent from azure.core.credentials import AzureKeyCredential client = ContentUnderstandingClient( endpoint=os.environ["CONTENTUNDERSTANDING_ENDPOINT"], credential=AzureKeyCredential(os.environ["CONTENTUNDERSTANDING_KEY"]), ) poller = client.begin_analyze( analyzer_id="invoice_jp_v1", inputs=[AnalysisInput(url=os.environ["INVOICE_URL"])], ) result = poller.result() doc = cast(DocumentContent, result.contents[0]) for name in ("VendorName", "InvoiceDate", "TotalAmount", "PaymentTerms"): field = doc.fields.get(name) if field is None: print(f"{name}: 未検出") continue flag = "要確認" if (field.confidence or 0) < 0.8 else "OK" print(f"{name}: {field.value} (confidence={field.confidence}) {flag}") ``` ポーリングは`poller.result()`がまとめて行います。信頼度0.8未満を「要確認」とした基準は例示なので、実際の帳票で人の確認結果と突き合わせて決めてください。API呼び出しの雛形を手早く作るなら、[公式のPythonサンプル集](https://github.com/Azure-Samples/azure-ai-content-understanding-python)や、2026年9月に公開された[Content Understanding ToolkitのCU CLI](https://github.com/Azure/content-understanding-toolkit)（プレビュー）も使えます。 ## Document Intelligenceとの違いと、新規案件・既存案件での選び分け ### 2サービスの処理方式・課金単位・オンプレミス対応を比較表で整理 同じFoundry Toolsに並ぶ[Azure AI Document Intelligence](https://www.issoh.co.jp/tech/details/3119/)は、学習済みモデルとラベル付きで学習させるカスタムモデルで帳票を読むサービスです。2つの違いを整理すると次のようになります。 | 観点 | Content Understanding | Document Intelligence | | ------- | --------------------- | --------------------- | | 抽出の方式 | 生成モデルとスキーマ | 専用の学習済みモデル | | 対象 | 文書・画像・音声・動画 | 文書と画像 | | ラベル付け | なしでも開始可 | カスタムは必要 | | 課金 | 抽出＋文脈化＋トークン | ページ単位 | | 閉域・オンプレ | コンテナ記載なし | コンテナあり | 課金の違いは見積もりに直結します。Document Intelligenceはページ数だけで金額が決まりますが、Content Understandingは項目数やスキーマの複雑さでトークンが増減します。同じ1,000ページでも、項目を絞るかどうかで総額が変わる点を前提に比べてください。 ### 2026年10月7日の公式ガイドが示す、新規OCR案件の評価順と既存案件の扱い Microsoft Foundryのブログは2026年10月7日に[2サービスの使い分けガイド](https://devblogs.microsoft.com/foundry/choosing-azure-document-intelligence-and-content-understanding/)を公開しました。要点は3つに分かれます。新しくクラウドでOCRやレイアウト抽出を組むなら、まずContent Understandingの`prebuilt-read`と`prebuilt-layout`を評価する。本番要件を満たしているDocument Intelligenceのワークロードは移行せずに使い続ける。オンプレミスやエアギャップ環境ではDocument Intelligenceのコンテナを使う、という整理です。 同じガイドは、構造が安定していてラベル付きサンプルがある独自フォームにはDocument Intelligenceのカスタムモデルが向き、同程度の精度なら専用の学習済みモデルに費用面の利点が残るとも書いています。既存のAPI・エンドポイント・SDK・課金は別々のままなので、帳票の種類ごとに片方ずつ切り替える段階的な導入ができます。 ## Content Understandingを採用する条件と、見送るべき場面の判断基準 ### 採用する場面：書式がばらばらな帳票と、音声・動画を含むRAG前処理 採用を勧める場面は2つです。1つは、取引先ごとに書式が異なる請求書や注文書のように、レイアウトでは位置を決められない帳票です。Document Intelligenceのカスタムモデルでは書式ごとにラベル付けが必要ですが、Content Understandingはスキーマの説明文だけで抽出を始められます。支払条件の要約のように、文面を読んで値を作る項目があるときも同様です。非定型帳票の項目設計の考え方は[AI-OCRで非定型帳票を読み取る仕組み](https://www.issoh.co.jp/column/details/16211/)で詳しく扱っています。 もう1つは、社内文書に会議の録音や研修動画が混ざる検索基盤の前処理です。RAG向けのアナライザーは、文書の図表の説明文、音声の話者分離付きの文字起こし、動画の場面ごとの要約を同じAPIで返します。取り込み工程を1本にまとめられる効果は大きく、設計の全体像は[RAGパイプラインとは](https://www.issoh.co.jp/tech/details/16473/)、図表を検索対象にする方式は[マルチモーダルRAGとは](https://www.issoh.co.jp/tech/details/15345/)が参考になります。 ### 見送る場面：オンプレミス必須の案件と、定型帳票を大量に安く処理する場合 文書を社外のクラウドに出せず、閉域やオンプレミスで処理する必要がある案件では、Content Understandingを採用しません。公式ガイドはこの条件でDocument Intelligenceのコンテナを勧めており、2026年10月時点のContent Understandingのドキュメントにはコンテナでの提供が見当たりません。 同じ書式の帳票を毎月数万ページ処理していて、Document Intelligenceの精度に不満がない場合も切り替えません。生成モデルのトークン料金が上乗せされるうえ、移行の検証工数に見合う改善が見込みにくいからです。逆に、移行を検討すべきなのは、人の確認に回る件数が多く、その原因が書式の揺れにある場合です。代表的な帳票100件ほどで両サービスの要確認率を比べれば判断できます。 帳票の選定からスキーマ設計、信頼度に応じた確認フロー、業務システムへの組み込みまでをまとめて進めたい場合は、一創の[AI-OCR導入支援](https://www.issoh.co.jp/service/ai/ocr/)で相談を受けています。AI-OCR全般の比較軸から検討を始めるなら[AI-OCRとは](https://www.issoh.co.jp/tech/details/1333/)が入口になります。 ## Azure Content Understandingでよくある質問 Content Understandingの検討時によく出る疑問を、2026年10月時点の公式ドキュメントをもとにまとめました。 ### Azure Content Understandingは本番環境で使えますか？ 使えます。2025年11月にAPI版`2025-11-01`で一般提供となり、Microsoft Entra ID、マネージドID、顧客管理キー、仮想ネットワーク、プライベートエンドポイントといった企業向けの制御もGAに含まれています。一方、`2026-06-01-preview`はSLAが無く、本番ワークロードには推奨されていません。エージェント型の解析や署名の検出のようにプレビュー版だけにある機能は、評価環境で試す扱いにします。 ### 日本語の請求書や手書きの書類も読み取れますか？ OCRの対応言語に日本語が含まれ、手書き文字の対応言語にも日本語が入っています。日付や数値の正規化も`ja-JP`に対応しています。ただしプリビルトアナライザーは米国の書類向けが多く、日本の請求書に対する`prebuilt-invoice`の精度は公式に数値が示されていません。自社の代表的な帳票を数十件解析し、項目ごとの正解率と信頼度の分布を見てから採用を決めてください。 ### Content Understandingの料金はいくらかかりますか？ Content Understanding側のコンテンツ抽出（文書は1,000ページ単位、音声・動画は分単位）とコンテキスト化、Foundry側の生成モデルのトークンの合計です。料金の解説ページの試算例では、請求書10ページの項目抽出が約0.08ドルと計算されていますが、例示用の単価による数字です。リージョンと選ぶモデルで単価が変わるため、価格ページの実額と、試しに解析した`usage`の値で見積もります。 ### Document Intelligenceから移行する必要はありますか？ 必要はありません。2026年10月7日の公式ガイドは、本番要件を満たしているDocument Intelligenceのワークロードはそのまま維持するよう書いています。既存のAPIやSDK、課金も別々に残ります。検討すべきなのは、新しくOCRを組む場合と、書式の揺れで人の確認が減らない帳票がある場合です。帳票の種類ごとに両方を試し、要確認率と総コストで比べて切り替えるのが現実的です。 ### 画像や動画はどこまで扱えますか？ 上限ページによると、画像は200MBまでで50×50〜10,000×10,000ピクセル、動画はURL参照なら4GB・2時間までです。動画は約1秒に1フレームを解析し、フレームは512×512ピクセルに縮小されるため、短い動きや小さな文字は取りこぼすことがあります。音声は最大1GB・4時間まで受け付けますが、300MB以下か2時間以下のほうが文字起こしは速く終わります。 ## 関連記事 - [Azure AI Document Intelligenceの料金・使い方・精度｜文書解析AIを実務目線で解説](https://www.issoh.co.jp/tech/details/3119/)：比較対象となるDocument Intelligenceの料金とSDKでの使い方です。 - [AI-OCRとは？従来OCRとの違い・精度の実測と教育・自治体の導入事例](https://www.issoh.co.jp/tech/details/1333/)：AI-OCR全般の仕組みと導入判断の前提を扱っています。 - [AI-OCRで非定型帳票を読み取る仕組みと精度確保・項目マッピングの判断基準](https://www.issoh.co.jp/column/details/16211/)：書式が揃わない帳票の項目設計と精度の確保策です。 - [RAGパイプラインとは？取り込み系と推論系に分ける工程設計と再索引の実装判断](https://www.issoh.co.jp/tech/details/16473/)：Content Understandingを取り込み工程に置くときの全体設計です。 - [マルチモーダルRAGとは？図表・画像を検索する仕組みと実装方式の選び方](https://www.issoh.co.jp/tech/details/15345/)：図表や画像の説明文を検索対象にする方式の比較です。 --- 出典: [Azure Content Understandingとは？Document Intelligenceとの違い・料金・REST APIの使い方【2026年10月】]()（株式会社一創）