2026年6月5日に公開・更新された Azure AI Foundry 関連の公式情報では、Azure AI Search のインデックス作成時に使う Azure Content Understanding skill が強化され、セマンティックなチャンク化と画像の言語化をパブリックプレビューとして利用できるようになりました。結論から言うと、PDF、Word、PowerPoint、Excel などのリッチドキュメントを RAG や社内 Copilot に取り込む際、固定長で機械的に分割するだけでなく、段落・見出し・表・図の文脈を保った検索インデックスを作りやすくなります。(マイクロソフト Azure)
特に影響が大きいのは、Azure AI Foundry、Azure AI Search、Azure OpenAI、Blob Storage などを組み合わせて、社内文書検索、ナレッジベース、AI エージェント、Copilot 連携を構築している管理者・開発者です。既存環境が自動的に壊れる更新ではありませんが、プレビュー API、課金、リージョン、インデクサー、スキルセット、ベクトル化設計を確認せずに本番相当のデータへ適用すると、コスト増や検索品質の揺れにつながる可能性があります。
Azure AI Foundryの更新で何が変わったのか
今回の更新は、Azure AI Search のインデクサー処理における「ドキュメントの読み取り方」を強化するものです。Azure Content Understanding skill は、Foundry Tools の Azure Content Understanding を使って非構造化ドキュメントを解析し、検索や自動化に使える形へ変換する組み込みスキルです。公式ドキュメントでは、このスキルがテキストと画像を抽出し、画像の文書内位置を保持する location metadata も扱えると説明されています。(Microsoft Learn)
今回のポイントは大きく3つです。
| 変更点 | できるようになること | 実務上の意味 |
|---|---|---|
| セマンティックチャンク化 | 段落や見出しの境界を考慮して文書を分割 | RAG の回答根拠が途中で切れにくくなる |
| 画像の言語化 | 図、グラフ、チャート、埋め込み画像を自然文で説明 | 図だけに含まれる情報も検索・ベクトル化しやすくなる |
| リッチドキュメント解析の強化 | Markdown、位置情報、画像参照を含むチャンクを生成 | 検索結果から元ページや関連画像をたどりやすくなる |
従来の固定長チャンク化では、「500文字ごと」「一定トークンごと」のように文書を機械的に分割するため、表の途中、手順の途中、見出しと本文の間で切れてしまうことがありました。今回のセマンティックチャンク化では、chunkingProperties.method に semantic を指定することで、段落や見出しの境界を尊重したチャンクを作成できます。(Microsoft Learn)
画像の言語化は、埋め込み画像、チャート、図表を Azure OpenAI のチャット完了モデルで説明文に変換し、その説明をチャンク本文へ統合する仕組みです。modelName と modelDeployment を設定すると、画像説明が生成され、ベクトル化前のチャンクコンテンツにマージされます。(Microsoft Learn)
対象になるサービスと機能範囲
今回の更新は「Azure AI Foundry の単独機能」というより、Azure AI Foundry と Azure AI Search を組み合わせたデータ取り込み・検索・RAG パイプラインに関わる更新です。
主な関係サービスは次のとおりです。
| 領域 | 関係するサービス・機能 | 確認ポイント |
|---|---|---|
| AI基盤 | Azure AI Foundry / Microsoft Foundry resource | Content Understanding skill の課金・リージョン・モデル配置 |
| 検索 | Azure AI Search | インデックス、スキルセット、インデクサー、ベクトル検索設定 |
| 生成AI | Azure OpenAI | 画像説明用のチャット完了モデル、チャンク埋め込み用の embedding モデル |
| データソース | Azure Blob Storage など | ファイル形式、権限、allowSkillsetToReadFileData |
| アプリ連携 | RAG、Copilot、AIエージェント、社内検索 | 検索結果の粒度、根拠表示、画像参照の扱い |
公式ドキュメントでは、Azure AI Search サービス自体はこのシナリオでリージョン制約を受けない一方、Content Understanding skill で処理する Microsoft Foundry リソースは対応リージョンに配置する必要があるとされています。また、画像説明とチャンク化は Foundry リソースのリージョンで処理されます。(Microsoft Learn)
つまり、管理者は「検索サービスが動いているから問題ない」と判断せず、Foundry リソース、Azure OpenAI モデル、データ所在地、ネットワーク経路まで含めて確認する必要があります。
既存のRAG・社内Copilotに与える影響
今回の更新で最も分かりやすいメリットは、RAG や社内 Copilot の回答品質を改善しやすくなることです。
例えば、社内マニュアルに次のような情報があるとします。
- 手順の説明文
- 画面キャプチャ
- 承認フロー図
- 例外処理の表
- 複数ページにまたがる料金表や仕様表
固定長チャンク化では、フロー図が画像のまま扱われたり、表が途中で分割されたりして、検索結果に必要な文脈が入らない場合があります。Azure Content Understanding skill では、表や図を Markdown 形式で扱いやすくし、複数ページにまたがる表を1つの単位として認識できる点が示されています。(Microsoft Learn)
そのため、次のようなユースケースでは効果を検証する価値があります。
| ユースケース | 期待できる改善 | 検証すべき観点 |
|---|---|---|
| 社内規程検索 | 条文や補足図の文脈をまとめて取得しやすい | 古い規程と新しい規程の混在を防げるか |
| 製品マニュアル検索 | 手順文と画面図の関係を検索に反映しやすい | 画像説明が実際の画面内容とずれていないか |
| 営業資料検索 | スライド内の図表や比較表を拾いやすい | 図表の説明が営業上の意味を正しく表すか |
| 契約・申請書類検索 | ページ位置や表情報を保持しやすい | 権限管理や機密ラベルと矛盾しないか |
| AIエージェントの根拠検索 | テキストと画像説明を同じ検索対象にしやすい | 回答根拠としてユーザーに見せる粒度が適切か |
一方で、画像を言語化すれば必ず正確になるわけではありません。グラフの読み取り、細かい数値、複雑な画面キャプチャ、法務・医療・金融のような厳密性が必要な文書では、生成された説明が過不足なく利用できるかをサンプルデータで確認する必要があります。
管理者が確認すべき設定
管理者が最初に確認すべきなのは、プレビュー API を使う前提条件と運用ルールです。今回の機能は 2026-05-01-preview REST API の一部として扱われており、Microsoft のプレビュー条件に従うことが明記されています。(Microsoft Learn)
プレビュー利用の可否
パブリックプレビューは、すべての Azure 顧客が非運用環境で利用・テストできるステータスです。Azure Updates のステータス説明でも、In preview は本番運用ではなく非運用環境での使用とテスト向けと説明されています。(マイクロソフト Azure)
本番環境に近いデータで検証する場合でも、まずは次を確認してください。
| 確認項目 | 判断基準 |
|---|---|
| プレビュー機能の利用承認 | 社内のクラウド利用ルールで preview API の利用が許可されているか |
| データ分類 | 機密情報、個人情報、規制対象データを含むか |
| リージョン | Foundry リソースの処理リージョンが要件に合うか |
| 監査 | どの文書を処理し、どのインデックスへ反映したか追跡できるか |
| ロールバック | 既存インデックスや旧スキルセットへ戻せる構成か |
特に注意したいのは、プレビュー API では他の Microsoft サービスやサードパーティサービスへの接続がサポートされ、利用条件によってはデータ処理・保存場所に関する考慮が必要になる点です。公式ドキュメントでは、組織のコンプライアンス境界や地理的境界を管理する責任は利用者側にあると説明されています。(Microsoft Learn)
課金とコスト管理
Azure Content Understanding skill は、課金対象の Microsoft Foundry リソースに紐づきます。公式ドキュメントでは、Document Layout skill などと異なり「1日20ドキュメント無料」のような扱いはなく、Content Understanding の価格で課金されると説明されています。(Microsoft Learn)
コスト面で見落としやすいのは、次の3点です。
- ドキュメント解析そのものの課金
- 画像説明を生成する Azure OpenAI チャット完了モデルの利用
- チャンク数増加に伴う embedding とインデックス容量の増加
大量の PDF やスライドを一括投入する前に、代表的なファイルを数十件選び、1ファイルあたりのチャンク数、画像数、処理時間、トークン量を測定してから展開範囲を決めるのが安全です。
権限とマネージドID
公式の手順ではサンプルを簡潔にするため API キーが使われていますが、本番ではマネージド ID の利用が推奨されています。スキルセットから Foundry リソース、Azure OpenAI、Blob Storage へ接続する箇所は、キー管理ではなくロールベースアクセスへ寄せる方が運用しやすくなります。(Microsoft Learn)
管理者は、少なくとも次の接続を棚卸ししてください。
| 接続元 | 接続先 | 確認する権限 |
|---|---|---|
| Azure AI Search indexer | Blob Storage | 読み取り権限、必要に応じて Storage Blob Data Reader |
| Skillset | Foundry resource | Content Understanding skill の実行・課金に必要な接続 |
| Skillset | Azure OpenAI | embedding や画像説明用モデルへのアクセス |
| アプリ | Azure AI Search index | クエリ実行、検索結果取得、必要に応じた文書レベル権限 |
開発者が確認すべき実装ポイント
開発者は、スキルセットを少し変更するだけで済むと考えがちですが、実際にはインデックス設計まで含めて見直す必要があります。今回の更新では、1つのソース文書から複数の検索ドキュメントを作る「one-to-many」構成が基本になります。公式ドキュメントでも、各チャンクを1つの検索ドキュメントとして扱い、chunk_id、parent_id、チャンク本文、ページメタデータ、画像参照、ベクトルフィールドを持つ設計例が示されています。(Microsoft Learn)
セマンティックチャンク化の設定
セマンティックチャンク化を使う場合は、chunkingProperties を明示します。
"chunkingProperties": {
"method": "semantic",
"unit": "tokens",
"maximumLength": 500
}method は fixedSize または semantic を指定できます。semantic では、レイアウトを意識し、段落境界や大きな表の扱いを考慮したチャンク化が行われます。unit は、semantic の場合 tokens を使い、maximumLength はトークン単位で指定します。(Microsoft Learn)
実務では、最初から最大長を大きくしすぎないことが重要です。チャンクが大きすぎると、1件の検索結果に余計な情報が入り、RAG の回答がぼやける場合があります。逆に小さすぎると、表や手順の文脈が分断されます。まずは 500〜1,000 トークン程度の検証用設定で、検索結果と回答品質を比較するのが現実的です。
画像の言語化の設定
画像説明を有効にするには、Content Understanding skill に modelName と modelDeployment を設定します。公式ドキュメントでは、modelName は埋め込み画像、チャート、図の説明生成に使う Azure OpenAI チャット完了モデル名であり、modelDeployment とセットで指定する必要があるとされています。(Microsoft Learn)
"modelName": "gpt-4.1",
"modelDeployment": "myGpt41Deployment"画像説明は便利ですが、すべての画像に必要とは限りません。例えば、装飾画像やロゴ、意味の薄いアイコンまで説明対象にすると、チャンク本文にノイズが増えます。検索品質を優先するなら、「図解、手順画面、グラフ、表、アーキテクチャ図を含む文書」から優先的に適用するのがよいでしょう。
インデックス投影とフィールド設計
Content Understanding skill は text_sections と normalized_images を出力できます。text_sections にはチャンクの Markdown コンテンツ、位置情報、関連する画像パスなどが含まれます。画像を抽出する場合、normalized_images には抽出画像と位置情報が含まれます。(Microsoft Learn)
開発者は、最低限次のフィールドを検討してください。
| フィールド例 | 目的 |
|---|---|
chunk_id | チャンク単位の一意キー |
parent_id | 元文書とのひも付け |
title | 検索結果や引用表示に使う文書名 |
chunk | Markdown を含むチャンク本文 |
page_number_from / page_number_to | 根拠ページの表示 |
image_path | 関連画像の参照 |
text_vector | ベクトル検索用 |
RAG アプリで引用を表示する場合、parent_id とページ番号は特に重要です。検索結果が正しくても、ユーザーが元文書へ戻れないと業務利用では信頼されにくくなります。
移行・展開時の注意点
既存の Document Layout skill や Text Split skill を使っている場合、すぐに置き換えるのではなく、並行インデックスで比較するのが安全です。Azure Content Understanding skill は、Content Extraction と Chunking を1つのスキルで扱えるため Text Split skill が不要になるケースがありますが、チャンクの粒度や出力構造は変わります。(Microsoft Learn)
既存インデックスを直接上書きしない
既存の検索アプリや Copilot が参照しているインデックスを直接変更すると、検索結果の件数、ランキング、引用表示、フィルター条件が変わる可能性があります。まずは次のように段階的に進めるのがおすすめです。
| フェーズ | 作業内容 | 合格基準 |
|---|---|---|
| 検証 | 代表文書だけで別インデックスを作成 | 処理エラー、コスト、チャンク数を確認 |
| 比較 | 旧インデックスと新インデックスで同じ質問を実行 | 回答精度、引用、検索漏れを比較 |
| 限定展開 | 特定部門・特定文書だけ適用 | ユーザーの検索ログとフィードバックを確認 |
| 本格展開 | 対象データを拡大 | ロールバック手順と監視を準備 |
大きすぎる文書に注意する
Azure Content Understanding skill には、Content Understanding document analyzer で5分を超える処理が必要な大きな文書には適さないという制限があります。タイムアウトしても、紐づく Foundry リソースには課金が発生する可能性があるため、巨大な PDF、画像が多いスライド、スキャン文書は事前に分割・最適化を検討してください。(Microsoft Learn)
また、PDF がパスワード保護されている場合は、インデクサー実行前に解除が必要です。画像サイズにも制限があり、公式ドキュメントでは 50×50 ピクセル以上、10,000×10,000 ピクセル以下とされています。(Microsoft Learn)
DOCXとPDFで結果が揃わない可能性
同じ内容でも、Word ファイルと PDF では画像やレイアウトの扱いが異なるため、出力結果が変わる可能性があります。公式ドキュメントでも、DOCX と PDF では画像処理の違いなどにより結果が異なる場合があると説明されています。(Microsoft Learn)
業務マニュアルや規程集のように検索品質を揃えたい文書では、入力形式を PDF に統一する、または形式ごとに評価セットを分けて品質確認するのが実務的です。
導入前に確認したいチェックリスト
Azure AI Foundry と Azure AI Search の管理者・開発者は、検証前に次の項目を確認してください。
| チェック項目 | 確認内容 |
|---|---|
| APIバージョン | 2026-05-01-preview を使う前提で問題ないか |
| プレビュー利用 | 社内ルール上、非運用・検証用途で利用できるか |
| Foundryリソース | Content Understanding skill 対応リージョンにあるか |
| モデル配置 | 画像説明用の Azure OpenAI チャット完了モデルを同じ Foundry リソース側で利用できるか |
| embedding | チャンク本文をベクトル化する embedding モデルを用意しているか |
| データ形式 | PDF、DOCX、XLSX、PPTX、画像など対象形式がサポート範囲か |
| 権限 | Blob、Foundry、Azure OpenAI、Search へのアクセス権限が適切か |
| コスト | 解析、画像説明、embedding、インデックス容量の見積もりを取ったか |
| 品質評価 | 旧インデックスとの検索結果比較を行うか |
| ロールバック | 旧スキルセット・旧インデックスへ戻せるか |
どのような環境で優先的に試すべきか
今回の更新は、すべての検索システムに即適用すべきものではありません。優先度が高いのは、次のような環境です。
- PDF、PowerPoint、Word などのリッチドキュメントを大量に検索対象にしている
- 図、表、グラフ、画面キャプチャに重要情報が含まれている
- RAG の回答で「該当箇所が見つからない」「図の内容を答えられない」という課題がある
- 社内 Copilot や AI エージェントに、文書の根拠付き回答をさせたい
- チャンク分割の調整に時間がかかっている
反対に、プレーンテキスト中心の FAQ、短いナレッジ記事、構造が単純な Markdown だけを扱う環境では、まず既存の Text Split skill や通常のベクトル化設定を見直す方が効果的な場合もあります。画像や複雑な表を多く含む文書ほど、今回の機能を試す価値が高くなります。
まず取るべき次の行動
今回の Azure AI Foundry 関連更新では、Azure AI Search の Content Understanding skill によって、リッチドキュメントをより文脈に沿ってチャンク化し、画像・図表を検索可能な説明文として扱いやすくなりました。RAG、社内 Copilot、AI エージェントの検索品質を高めるうえで有力な選択肢ですが、プレビュー機能であること、課金が発生すること、リージョンや権限、入力形式によって結果が変わることを前提に検証する必要があります。
最初に行うべきことは、本番インデックスの変更ではありません。代表的な文書を10〜50件ほど選び、既存のチャンク方式と Content Understanding skill のセマンティックチャンク化・画像言語化を並行比較してください。検索漏れ、回答根拠、画像説明の正確性、処理時間、コストを確認したうえで、対象文書と展開範囲を決めるのが安全です。
コメント