Azure AI Foundryで文書解析やRAGを組んでいる場合、今回のポイントは「Content UnderstandingのextractionModeで、文書をどの深さで解析するか選べるようになった」という点です。結論から言うと、表・セクション・読み順が重要な契約書や帳票はレイアウト重視、RAG向けにきれいなMarkdownテキストだけを速く作りたい文書はテキスト中心のモードを選ぶのが基本です。
2026年6月3日頃に確認された公式更新では、Microsoft FoundryのContent Understandingがドキュメント向けにextractionMode設定をサポートし、解析方法を選択できるようになったことが案内されています。Azure Updates上ではGA、つまり本番利用を前提に扱える更新として掲載されています。(Microsoft Azure)
Azure AI FoundryのContent Understanding extractionModeで何が変わるのか
今回の更新で変わるのは、Content Understandingに文書を渡した後の「解析の深さ」を、用途に合わせて選びやすくなった点です。
Content Understandingは、文書・画像・音声・動画などの非構造データから、生成AIや業務アプリで使える構造化情報を取り出すためのFoundry Toolsの機能です。Microsoftの説明では、Document Intelligenceの従来型AIによる抽出と、LLMベースのコンテンツ理解を組み合わせ、構造化・非構造化コンテンツの両方を扱えるサービスとされています。(Microsoft Azure)
従来の文書処理では、「とにかく全文テキストを抽出したい」ケースと、「表、段落、見出し、ページ上の位置関係まで見たい」ケースが同じ処理に寄りがちでした。extractionModeにより、たとえば以下のような判断がしやすくなります。
| 選択肢 | 向いている文書 | 期待できる効果 | 注意点 |
|---|---|---|---|
| レイアウト重視の解析 | 契約書、請求書、見積書、申請書、業務マニュアル、表が多いPDF | 表、セクション、読み順、文書構造を保った解析がしやすい | 処理時間やコストが増える可能性があるため、全ファイルに無条件適用しない |
| テキスト中心の解析 | 社内FAQ、規程文書、ナレッジ記事、RAG用のプレーンな文書 | 下流のRAGインデックス作成向けに、より速くMarkdown化しやすい | 表の行列関係、複数カラム、注釈、図表の意味が重要な文書では情報落ちに注意 |
つまり、今回の更新は「精度が上がる新機能」というより、精度・速度・コスト・出力形式のバランスを設計できるようにする更新と捉えると分かりやすいです。
extractionModeを使うべき場面と避けたい場面
extractionModeの選択は、文書の見た目ではなく「後続処理で何を使うか」で決めるのが実務的です。
レイアウト重視を選ぶべき文書
レイアウト重視のモードは、文書内の位置関係が意味を持つ場合に向いています。
たとえば、請求書では「品目名」「数量」「単価」「金額」が同じ行に並んでいることが重要です。契約書では、条項番号、見出し、別紙、注釈の関係が崩れると、RAGの回答や自動判定が誤る可能性があります。
Content Understandingのアナライザー設定では、ドキュメント向けにOCR、レイアウト、表、図、フィールド抽出などの処理オプションを持てます。Microsoft Learnでは、enableLayoutが段落、行、単語、読み順、構造要素などのレイアウト情報を抽出する設定として説明されています。(Microsoft Learn)
レイアウト重視を選びたい代表例は次のとおりです。
- 表の行・列が回答品質に直結する請求書、見積書、財務資料
- 条番号、節、別紙、脚注の関係が重要な契約書
- 2段組み、注釈、ヘッダー、フッターが多いPDF
- 抽出結果を人間がレビューし、元ページ上でハイライト表示したい業務画面
- 信頼度スコアや根拠位置を使って、承認・差し戻しを分岐するワークフロー
テキスト中心を選びやすい文書
テキスト中心のモードは、レイアウト情報よりも「検索しやすい本文」を速く得たいケースに向いています。
たとえば、社内規程、FAQ、ヘルプ記事、仕様説明のように、文章の流れが主で、表や複雑な図が少ない文書では、細かなレイアウト解析よりも、クリーンなMarkdownを作ってチャンク化・ベクトル化するほうが実用的です。
RAG用途では、必ずしもレイアウト情報が多いほど良いわけではありません。不要なヘッダー、フッター、ページ番号、装飾要素まで取り込むと、検索ノイズが増え、回答の根拠がぼやけることがあります。速度を重視するナレッジ取り込みでは、まずテキスト中心のモードを試し、検索品質が足りない文書だけレイアウト重視に切り替える運用が現実的です。
影響範囲は「文書を取り込む処理」全般に及ぶ
今回のAzure AI Foundry更新で確認すべき対象は、Content Understandingを直接呼び出しているアプリだけではありません。文書をAI検索、Copilot、エージェント、業務自動化に流している場合も影響します。
特に確認したいのは次の領域です。
| 対象 | 確認すべきこと |
|---|---|
| Analyze APIを直接呼ぶアプリ | extractionModeを指定するか、既定値に任せるか。レスポンス構造に依存した処理がないか |
| カスタムアナライザー | アナライザースキーマ、抽出フィールド、信頼度、根拠位置の扱い |
| Foundryポータル / Content Understanding Studio | どの画面でプリビルトアナライザーを使い、どこからカスタムアナライザーを管理するか |
| Azure AI Search / Foundry IQ | インデックス再作成の要否、チャンク品質、既存検索結果との互換性 |
| 業務ワークフロー | 自動承認、差し戻し、手動レビューのしきい値が変わらないか |
| 監査・コンプライアンス | 元文書の根拠表示、ログ、アクセス制御、データ保持の設計 |
Azure AI Search側でも、ナレッジソースの取り込み設定としてContent Understanding skillを使うcontentExtractionModeが説明されています。Blob、Indexed OneLake、Indexed SharePointなどのナレッジソースでContent Understanding skillを任意に使う設定が登場しているため、Search側のcontentExtractionModeとContent Understanding側のextractionModeを混同しないようにしてください。(Microsoft Learn)
実装時は、「どのサービスの、どのAPIバージョンの、どのプロパティを設定しているのか」を明確にすることが重要です。
管理者がまず確認すべき設定
管理者は、いきなり本番設定を変えるのではなく、現在の文書処理パイプラインを棚卸しするところから始めるべきです。
APIバージョンとSDKを確認する
Content UnderstandingのGA APIとして2025-11-01が使われています。Microsoft Learnのアナライザー作成例でも、REST APIのエンドポイント例にapi-version=2025-11-01が示されています。(Microsoft Learn)
SDKを使っている場合は、使用中の言語ごとに対応状況を確認してください。Microsoft Learnでは、Content Understanding向けのPython、.NET、Java、JavaScript/TypeScript SDKが2025-11-01 GA APIバージョンを対象にしていると説明されています。(Microsoft Learn)
確認項目は次のとおりです。
| 確認項目 | 見る場所 | 判断基準 |
|---|---|---|
| REST APIバージョン | API呼び出しURL、SDK設定、IaCテンプレート | 2025-11-01など、GA対象のバージョンを使っているか |
| SDKバージョン | requirements.txt、package.json、csproj、pom.xml | extractionModeに対応するバージョンか |
| アナライザーID | アプリ設定、Key Vault、環境変数 | 本番・検証・旧版が混在していないか |
| 出力依存 | 後続のETL、検索インデックス、DBスキーマ | Markdown、JSON fields、confidence、groundingの変更に弱くないか |
文書種別ごとのモード方針を決める
全ファイルを同じextractionModeで処理するのは避けたほうが安全です。管理者は、文書種別ごとに標準方針を決めておくと運用が安定します。
| 文書種別 | 推奨方針 |
|---|---|
| 請求書、領収書、見積書 | レイアウト重視。表の行列関係と金額項目の根拠を重視 |
| 契約書、規程、申請書 | まずレイアウト重視。条項・セクション・別紙の扱いを評価 |
| 社内FAQ、手順書、ナレッジ記事 | テキスト中心から開始。検索品質が不足する場合のみレイアウト重視 |
| スキャンPDF、画像化された文書 | OCRやレイアウトの有無を重点確認。テキスト中心だけで足りるか検証 |
| 図表が多い技術資料 | レイアウト重視。図の説明や表の保持が必要か確認 |
ポイントは、最初から完璧な分類を作ることではありません。まず「誤ると業務影響が大きい文書」をレイアウト重視に寄せ、それ以外をテキスト中心で試すのが現実的です。
セキュリティとアクセス制御も同時に確認する
extractionMode自体はセキュリティ機能ではありません。しかし、より多くの構造情報や根拠情報を扱う場合、出力データに含まれる情報量が増える可能性があります。
Content Understandingの一般提供では、Microsoft Entra ID、マネージドID、カスタマーマネージドキー、仮想ネットワーク、プライベートエンドポイントなどのエンタープライズ向け管理機能が含まれると説明されています。(Microsoft Learn)
管理者は次の点を確認してください。
- APIキーではなく、可能な範囲でマネージドIDやEntra IDベースの認証を使う
- 解析結果の保存先に、元文書と同等以上のアクセス制御をかける
- 信頼度や根拠位置を含むレスポンスをログに出しすぎない
- 検証用にアップロードした文書の削除・保持ルールを決める
- RAG用インデックスに機密情報が不要に混入しないよう、取り込み前後でフィルタリングする
開発者が移行・展開前に見るべきポイント
開発者は、extractionModeを単なるオプション追加として扱わず、出力仕様の変更として検証する必要があります。
既存アナライザーを直接書き換えない
最初の失敗例は、本番で使っているアナライザー設定を直接変更することです。文書解析の結果は、後続の検索、DB登録、承認フロー、UI表示に影響します。
安全な進め方は次の通りです。
| 手順 | 作業内容 |
|---|---|
| 複製 | 既存アナライザーをコピーし、検証用IDで作成する |
| 小規模評価 | 代表文書を使い、旧設定と新設定を横並びで比較する |
| 指標化 | 抽出精度、表の崩れ、Markdown品質、処理時間、失敗率を記録する |
| 後続確認 | RAG検索、UI表示、DB保存、承認フローの動作を確認する |
| 段階展開 | 文書種別またはユーザーグループ単位でカナリアリリースする |
アナライザーは、処理対象、抽出要素、出力形式、利用モデルを定義する再利用可能な構成単位です。Microsoft Learnでも、アナライザーがContent Understandingの中核であり、プリビルトまたはカスタムで使えると説明されています。(Microsoft Learn)
評価用データセットを必ず用意する
extractionModeの効果は、サンプル1件では判断できません。最低限、次のような文書を含めた評価セットを用意してください。
- 通常品質のPDF
- スキャンPDF
- 表がページをまたぐ文書
- 2段組みや脚注がある文書
- 日本語と英語が混在する文書
- レイアウトが崩れた古い帳票
- 余白、印影、手書きメモ、注釈がある文書
- 本番でエラーになりやすかった過去文書
評価では、単純な「全文が取れたか」だけでなく、次の観点を見ます。
| 評価観点 | 確認内容 |
|---|---|
| フィールド精度 | 金額、日付、会社名、契約番号などが正しく取れるか |
| 表構造 | 行の対応、列見出し、合計欄が崩れていないか |
| Markdown品質 | チャンク化しやすい見出し・段落構造になっているか |
| RAG回答 | 検索結果の根拠が正しい文書箇所を指すか |
| レイテンシ | 処理時間が業務要件内に収まるか |
| コスト | 全件に適用しても月次コストが許容範囲か |
| レビュー性 | 人間が確認しやすい根拠情報が残るか |
RAGインデックスは作り直しを前提に考える
extractionModeを変えると、Markdownの構造、チャンクの区切り、埋め込み対象のテキストが変わる可能性があります。つまり、既存のベクトルインデックスに新しい解析結果を混在させると、検索品質の比較が難しくなります。
RAG用途では、以下のようにインデックスを分けるのがおすすめです。
| インデックス | 用途 |
|---|---|
docs-rag-current | 現行本番 |
docs-rag-layout-test | レイアウト重視モードの評価 |
docs-rag-text-test | テキスト中心モードの評価 |
docs-rag-next | 本番切り替え候補 |
切り替え時は、古いインデックスをすぐ削除せず、一定期間ロールバックできる状態を残してください。検索品質の問題は、リリース直後よりも実ユーザーの質問が集まってから見つかることが多いためです。
失敗しやすいポイント
速いモードを全ドキュメントに適用してしまう
テキスト中心のモードは魅力的ですが、表や段組みが多い文書に使うと、RAGの回答が「それらしく間違う」原因になります。
たとえば、料金表で「プラン名」「月額」「上限」「対象ユーザー」が同じ行にある場合、行の対応が崩れると、AIは別プランの金額を回答する可能性があります。速度だけでなく、文書構造が回答品質に与える影響を見て判断してください。
confidenceのしきい値をそのまま使う
Content Understandingでは、設定によりフィールド値の信頼度スコアやソース位置を返せます。Microsoft Learnでは、estimateSourceAndConfidenceがページ番号、バウンディングボックス、信頼度スコアを返す設定として説明されています。(Microsoft Learn)
ただし、解析モードやアナライザーを変えると、信頼度の分布が変わる可能性があります。旧設定で「0.8以上なら自動承認」としていた場合でも、新設定で同じしきい値が妥当とは限りません。
移行時は、次のように業務判断のルールを見直します。
| 判定 | 例 |
|---|---|
| 自動処理 | 信頼度が高く、金額・日付など必須項目がすべて揃っている |
| 人手レビュー | 信頼度が中程度、または根拠位置が不自然 |
| 差し戻し | 必須項目が欠落、表構造が崩れている、複数候補がある |
ポータル操作とREST API設定がずれる
Foundryポータルで試した結果と、REST APIやSDKで実行した結果が一致しない場合、APIバージョン、アナライザーID、モデル設定、出力セクションがずれていることがあります。
Microsoft FoundryのBuild 2026発表では、Content UnderstandingのプリビルトアナライザーをFoundry内で扱える一方、独自ユースケース向けのカスタムアナライザーではContent Understanding Studioへの導線も説明されています。(Microsoft for Developers)
検証結果を本番に反映するときは、ポータルでの手順だけで終わらせず、IaC、環境変数、CI/CD、SDKコードまで同じ設定になっているか確認してください。
実務でのおすすめ展開手順
extractionModeの導入は、次の順序で進めると失敗しにくくなります。
| フェーズ | 実施内容 | 完了条件 |
|---|---|---|
| 棚卸し | Content Understandingを使っているアプリ、アナライザー、Search連携を一覧化 | 影響範囲が分かっている |
| 分類 | 文書を「レイアウト重要」「テキスト中心でよい」「要検証」に分ける | 文書種別ごとの暫定方針がある |
| 検証 | 旧設定と新設定を同じ評価セットで比較 | 精度、速度、コスト、RAG回答の差分が説明できる |
| 設計 | mode選択ルール、しきい値、ロールバック手順を決める | 運用担当者が判断できる |
| 展開 | 一部文書または一部ユーザーから段階適用 | 監視ログと問い合わせ対応が整っている |
| 定着 | 文書種別ごとに標準モードを更新 | 新規文書追加時の判断基準が明文化されている |
最初に取り組むなら、全社文書を一括で切り替えるのではなく、効果が見えやすい1つの業務から始めるのがよいでしょう。たとえば、請求書処理、契約書検索、社内ナレッジRAGなどです。
まとめ：extractionModeは「速さ」ではなく「文書構造の必要度」で選ぶ
Azure AI FoundryのContent Understandingに追加されたextractionModeは、文書解析を業務要件に合わせて調整するための重要な設定です。
判断基準はシンプルです。表、セクション、読み順、根拠位置が業務判断に関わるならレイアウト重視。文章中心で、RAG向けにきれいなMarkdownを速く作ることが目的ならテキスト中心から試します。
管理者はAPIバージョン、SDK、アナライザー、セキュリティ、Search連携を確認し、開発者は既存設定を直接書き換えず、評価セットで旧設定と新設定を比較してください。特にRAGでは、解析モードの変更がチャンクと埋め込みに影響するため、インデックスの作り直しと段階展開を前提に進めるのが安全です。
次に取るべき行動は、現在使っている文書処理パイプラインを一覧化し、文書種別ごとに「レイアウト重視」「テキスト中心」「要検証」の3つに分類することです。そこから小さく検証すれば、精度・速度・コストのバランスを崩さずに、Content UnderstandingのGA更新を本番運用へ取り込めます。
コメント