Azure AI FoundryのContent Understanding NextGenは、結論からいうと、Content UnderstandingをMicrosoft Foundryポータル内で扱いやすくするパブリックプレビューです。これまで日常的な確認でContent Understanding Studioへ移動していた作業の一部がFoundry内に入り、開発者はReadとLayoutのプレイグラウンドでOCRテキスト抽出やレイアウト解析を試しやすくなります。管理者と開発者がまず見るべきポイントは、プレビュー利用の範囲、対応リージョン、RBAC、モデルデプロイ、既存APIの移行要否です。
今回の変更は「新しいAI機能が1つ増えた」というより、非構造化データ処理をAzure AI Foundry上の開発・運用フローに寄せる変更と捉えると理解しやすくなります。PDF、画像、表を含む文書、RAG用の取り込み、社内ワークフロー自動化を扱っているチームほど、早めに検証しておく価値があります。
Azure AI FoundryのContent Understanding NextGenで何が変わるのか
2026年6月3日に公開または更新された公式情報として取り上げられている「Public Preview: Content Understanding NextGen in Microsoft Foundry」は、Microsoft Foundryポータル内にContent Understandingの利用体験を取り込むアップデートです。Azure Updatesでは、Content UnderstandingをMicrosoft Foundryポータルに持ち込み、日常的な作業でスタンドアロンのContent Understanding Studioへ切り替える必要を減らす内容として案内されています。(マイクロソフトアジュール)
特に重要なのは、Foundry内でRead playgroundとLayout playgroundを使える点です。Microsoft Learnの機能比較でも、Foundryの新しいポータルでは組み込みプレイグラウンドでReadとLayoutアナライザーをインタラクティブに試せると説明されています。(Microsoft Learn)
ただし、これは「Content Understanding Studioが不要になる」という意味ではありません。Microsoftの比較ページでは、Content Understanding Studioはデータラベル付け、カスタムアナライザーの改善、分類ベースのカスタムアナライザー構築に向いた補完的なUXとして整理されています。(Microsoft Learn)
変更点をひと目で整理
| 観点 | これまでの運用で起きやすかったこと | NextGenで期待できる変化 |
|---|---|---|
| 作業場所 | FoundryとContent Understanding Studioを行き来する | Foundryポータル内でRead/Layoutを試しやすくなる |
| OCR検証 | APIや別画面で文書を試す必要があった | Read playgroundでテキスト抽出を確認しやすい |
| レイアウト解析 | 表、段落、構造の確認が手間になりやすい | Layout playgroundで構造抽出を試しやすい |
| 開発者体験 | プロトタイプから実装までの流れが分断されやすい | Foundry上で検証、モデル、リソース管理をつなげやすい |
| 管理者の確認点 | Studio、API、Foundryリソースの管理範囲が分かれやすい | RBAC、ネットワーク、モデルデプロイ、リージョンの棚卸しが重要になる |
Azure Updatesにおける「In preview」は、すべてのAzure顧客が非本番用途のテストに利用できる状態として説明されています。つまり、いきなり本番処理を置き換えるのではなく、まず検証環境で既存の文書、画像、PDFを使って出力差分を確認するのが現実的です。(マイクロソフトアジュール)
Content Understandingとは何をするサービスか
Content Understandingは、ドキュメント、画像、オーディオ、ビデオなどの非構造化コンテンツを、検索や業務処理で使いやすい構造化データに変換するFoundry Toolsの機能です。請求書、契約書、サポート記録、動画、音声などを対象に、抽出、分類、要約、RAG向け取り込みなどへ活用できます。(Microsoft Learn)
Microsoft Learnでは、Content Understandingの処理要素として、入力、アナライザー、コンテンツ抽出、セグメンテーション、フィールド抽出、信頼度スコア、根拠、構造化出力などが説明されています。最終的な出力は、検索・取得向けのMarkdown、または自動化・分析向けの構造化JSONとして利用できます。(Microsoft Learn)
実務で分かりやすい例を挙げると、次のような使い方です。
- 紙帳票をスキャンしたPDFから文字を抽出する
- 表や見出しを含む契約書の構造を保持してRAGに取り込む
- 請求書から取引先名、日付、金額、明細を抽出する
- 社内ナレッジ文書をMarkdown化してエージェントに渡す
- 音声や動画からトランスクリプトや要約を生成する
今回のNextGenでは、このうち特にOCRとレイアウト解析の初期検証がFoundryポータル内で進めやすくなる点が実務上のメリットです。
ReadとLayoutはどう使い分けるべきか
Content Understandingの事前構築済みアナライザーには、OCRやレイアウト分析に使うものがあります。prebuilt-readは基本的なOCR向けで、ドキュメントから単語、段落、数式、バーコードなどを抽出し、レイアウト分析なしの基本的なテキスト抽出を提供します。(Microsoft Learn)
一方、prebuilt-layoutは、単語、図、段落、表などのコンテンツ要素とレイアウト要素を抽出し、セクションや書式、ハイパーリンク、注釈、図形の種類や位置情報など、より詳しい文書構造を扱います。(Microsoft Learn)
| 使いたいこと | 選びやすい機能 | 判断基準 |
|---|---|---|
| 画像PDFから文字だけ取り出したい | Read | 後段で全文検索や単純なテキスト処理をする |
| 表、段落、見出しを保ちたい | Layout | RAG、文書比較、契約書レビューに使う |
| Markdown化してLLMに渡したい | LayoutまたはRAG系アナライザー | 文書構造が回答品質に影響する |
| 請求書や領収書などの項目抽出をしたい | ドメイン固有アナライザーまたはカスタムアナライザー | フィールド名やJSONスキーマが必要 |
| まず精度感だけ知りたい | Foundry内のプレイグラウンド | コードを書く前に代表サンプルで確認する |
見落としやすいのは、OCRで文字が取れることと、業務で使える構造になることは別だという点です。たとえば表形式の見積書では、文字列だけを抽出できても「どの単価がどの品目に対応するか」が崩れると後続処理に使えません。RAGや自動処理に使う文書ほど、ReadだけでなくLayoutの結果を確認すべきです。
影響を受ける対象者
Azure AI Foundry管理者
管理者は、Content UnderstandingがどのFoundryリソース、リージョン、ネットワーク設定、RBACで使われるかを確認する必要があります。Content Understandingを使うには、サポートされているリージョンでFoundryリソースを作成する必要があり、Microsoft Learnでは東日本を含む対応リージョンが示されています。静止データは選択したリージョンに保存されると説明されています。(Microsoft Learn)
特に日本企業では、東日本リージョンを利用できるか、データ所在地要件に合うか、既存のAzure AI Foundryプロジェクトやネットワーク設計と矛盾しないかを先に確認しておくと安全です。
アプリ開発者・AIエンジニア
開発者は、プレイグラウンドで出力を確認したうえで、既存アプリやワークフローに組み込むAPI、SDK、アナライザーID、出力スキーマを確認します。特に、既存のプレビューAPIを使っている場合は移行対応が必要です。
Microsoft Learnでは、2024-12-01-previewと2025-05-01-previewのプレビューAPIが2026年7月15日までに廃止されるため、最新の2025-11-01 (GA) APIをターゲットにコードを更新するよう案内されています。(Microsoft Learn)
Content Understanding Studio利用者
Studioを使ってカスタムアナライザーを調整しているチームは、Foundry内で完結できる作業と、Studioに残すべき作業を分けて考える必要があります。
Foundryの新しいポータルはRead/Layoutの探索に向いています。一方で、データラベル付けやカスタムアナライザーの性能改善、分類ベースのカスタムアナライザー構築は、Content Understanding Studioが引き続き有力です。(Microsoft Learn)
管理者が確認すべき設定
リージョンとリソースの整合性
まず、Content Understandingを使うFoundryリソースがサポートリージョンにあるか確認します。日本向けシステムでは東日本を選べるかが重要ですが、既存のFoundryリソース、Azure OpenAIモデル、ネットワーク、データ保管要件との整合も見てください。
確認すべき項目は次の通りです。
| 確認項目 | 見るべきポイント |
|---|---|
| Foundryリソース | Content Understandingを利用する対象リソースが明確か |
| リージョン | 東日本など要件に合う対応リージョンか |
| データ所在地 | 静止データの保存先が社内ポリシーに合うか |
| ネットワーク | Private Endpoint、VNet、社内接続経路と矛盾しないか |
| 検証環境 | 本番とは分けたプロジェクトで試せるか |
RBACは最小権限で割り当てる
Content Understandingには、Reader、Contributor、Ownerに相当する組み込みRBACロールが用意されています。Readerは読み取り、一覧、分析操作などが可能で、Contributorは作成・更新・分析・テスト操作、Ownerは削除を含む全操作が可能です。(Microsoft Learn)
検証段階では、全員にOwnerを付与するのではなく、次のように役割を分けると管理しやすくなります。
| 利用者 | 推奨ロールの考え方 |
|---|---|
| 出力確認だけをする担当者 | Reader |
| アナライザーを作成・調整する開発者 | Contributor |
| 本番設計、削除、権限管理を行う管理者 | Owner |
| CI/CDや自動処理 | Managed IDに必要最小限の権限 |
ネットワークと認証を確認する
Content UnderstandingはMicrosoft Foundryの一部として、VNetやPrivate Endpointによるネットワーク分離、Microsoft Entra IDやマネージドID、APIキーによる認可を利用できます。ネットワークルールを有効にした場合、許可したIP、IP範囲、VNet、サブネットからの通信に制限できます。(Microsoft Learn)
本番に近い検証をするなら、ブラウザでプレイグラウンドが開けるかだけでなく、実際にアプリケーションが動く接続経路でAPIを呼び出せるかまで確認してください。社内ネットワーク、Azure Functions、Logic Apps、AKS、仮想マシンなど、実行元によって詰まるポイントが変わります。
開発者が確認すべき移行ポイント
プレビューAPIを使っていないか棚卸しする
既存コードで2024-12-01-previewまたは2025-05-01-previewを指定している場合、移行計画が必要です。Microsoft Learnでは、プレビューAPIからGA APIへ移行する際、アナライザー定義の更新、baseAnalyzerIdの指定、modelsオブジェクトの追加などが案内されています。(Microsoft Learn)
特に注意したいのは、画面上のプレイグラウンド検証とAPIの本番実装は別物だという点です。ポータルで期待通りに見えても、アプリ側が古いAPIバージョンを呼んでいれば、将来的に動作しなくなる可能性があります。
Proモード利用中のチームは要注意
GA APIにはProモードが含まれておらず、AnalysisModeは非推奨、GA APIでサポートされるモードはStandardのみと説明されています。また、PersonディレクトリやFace APIを使った一部のビデオアナライザー機能もGA APIの一部ではないとされています。(Microsoft Learn)
そのため、複数ファイル横断の推論、参照データを使った検証、顔関連の処理を利用している場合は、単純なAPIバージョン置き換えでは済まない可能性があります。移行前に、現在のアナライザー定義と出力仕様を保存し、代表データで差分を比較してください。
モデルデプロイの既定値を確認する
Content Understandingでは、利用する機能によってFoundryモデルへの接続が必要です。Microsoft Learnでは、Content Understandingリソースの既定のモデルデプロイを設定し、リソース内のContent UnderstandingモデルとFoundryモデルの接続を構成する手順が説明されています。(Microsoft Learn)
また、GPT-4.1モデルファミリは2026年10月に廃止されるため、強化された機能を提供するgpt-5.2への移行が推奨されています。既存環境でGPT-4.1系を使っている場合、Content Understandingだけでなく、周辺のプロンプト、出力品質、コスト、レイテンシも含めて確認しましょう。(Microsoft Learn)
なお、prebuilt-readとprebuilt-layoutについては、Microsoft Learn上で言語モデルや埋め込みモデルは不要と説明されています。OCRやレイアウト解析だけを試す場合と、RAG向け要約やカスタム抽出まで使う場合では、必要な準備が異なる点に注意してください。(Microsoft Learn)
展開時に失敗しやすいポイント
プレイグラウンドの結果をそのまま本番品質とみなす
プレイグラウンドは、代表ファイルで素早く出力を確認するには便利です。しかし、本番ではファイル形式、画質、スキャン品質、ページ数、言語、手書き、表の複雑さが大きく変わります。
検証では、きれいなサンプルだけでなく、次のような「現場で実際に来るファイル」を混ぜてください。
- 斜めにスキャンされたPDF
- 表の罫線が薄い見積書
- 余白に手書きメモがある申請書
- 日本語と英数字が混在する帳票
- 画像化された古い契約書
- 複数ページでレイアウトが変わる資料
ReadとLayoutの使い分けを誤る
ReadはOCR中心、Layoutは文書構造の把握に向いています。文字列だけで後続処理が成立するならReadで十分な場合がありますが、表、段落、見出し、図、注釈の意味が重要ならLayoutを検討すべきです。
RAGでは、この差が回答品質に直結します。たとえば、表の列見出しと金額の対応関係が崩れたままベクトル化すると、検索結果に含まれていてもLLMが誤った回答を返す原因になります。
Content Understanding Studioの役割を誤解する
NextGenによってFoundry内での日常的な確認はしやすくなりますが、Studioの役割が消えるわけではありません。データラベル付けやカスタムアナライザーの改善が必要なチームは、Studioを「高度な調整場所」として残し、Foundryを「検証と統合の入口」として使い分けるのが現実的です。
コンテンツフィルターとGuardrailsを後回しにする
Content Understandingは、利用するFoundryモデルデプロイに関連付けられたGuardrailsの結果を反映します。Guardrailsでコンテンツにフラグが立つと、分析応答にcontent_filters配列として結果が含まれると説明されています。(Microsoft Learn)
また、ブロックや注釈の挙動は、モデルデプロイに紐づくGuardrails構成で調整します。業務文書にセンシティブな情報や規制対象データが含まれる場合は、抽出精度だけでなく、ブロック時のエラー処理、監査ログ、再処理フローまで決めておくべきです。(Microsoft Learn)
実務でのおすすめ検証手順
| 手順 | やること | 成果物 |
|---|---|---|
| 現状把握 | Studio、Foundry、API、SDKの利用箇所を洗い出す | 利用一覧、APIバージョン一覧 |
| 検証環境作成 | サポートリージョンにFoundryリソースを用意する | 検証用プロジェクト |
| 権限設計 | Reader、Contributor、Ownerを分ける | RBAC設計表 |
| サンプル投入 | 代表的なPDF、画像、帳票をRead/Layoutで試す | 出力差分メモ |
| 出力評価 | OCR精度、表構造、段落、Markdown品質を確認する | 採用判断 |
| API確認 | 既存コードのAPIバージョンを確認し、必要ならGAへ移行する | 移行タスク |
| 運用設計 | エラー処理、再試行、監査、コスト監視を決める | 本番展開チェックリスト |
この順番で進めると、画面の新機能に飛びついて後から権限やAPI移行で止まるリスクを減らせます。
どのようなチームが早めに試すべきか
早めに検証すべきなのは、次のようなチームです。
- Azure AI FoundryでRAGやエージェントを構築している
- PDFや画像帳票のOCR処理を既に持っている
- Azure AI Document IntelligenceやContent Understanding Studioから移行を検討している
- 請求書、契約書、申請書、本人確認書類などを自動処理している
- 社内文書をMarkdown化してLLMに渡したい
- 非構造化データ処理をFoundry上の統合管理に寄せたい
反対に、単純な全文検索だけで十分な小規模システムや、既存のOCR基盤で問題が出ていない環境では、すぐに置き換える必要はありません。まずは新規案件や改善対象のワークロードから検証するとよいでしょう。
まず取るべきアクション
Azure AI FoundryのContent Understanding NextGenは、Content UnderstandingをFoundryポータル内で扱いやすくし、Read/Layoutの検証をスムーズにするアップデートです。最大のメリットは、OCRやレイアウト解析をコード実装前にFoundry内で確認し、RAGや業務自動化につなげやすくなることです。
一方で、プレビュー機能であること、Studioの役割が残ること、APIバージョン移行やモデルデプロイ確認が必要になることは見落とせません。特に既存環境でプレビューAPIを使っている場合は、2026年7月15日の廃止予定に向けて早めに棚卸ししてください。
次にやるべきことは明確です。まず、現在使っているContent Understanding、Document Intelligence、Studio、APIの利用箇所を一覧化します。そのうえで、代表的なPDFや画像をFoundryのRead/Layoutプレイグラウンドで試し、出力品質、権限、リージョン、API移行の課題を洗い出しましょう。小さく検証してから展開範囲を広げることが、今回のアップデートを安全に活用する最短ルートです。
コメント