2026 年 8 月 31 日時点の情報です。この記事で扱う
2026-06-01-previewは Public Preview であり、SLA は提供されず、本番ワークロードには推奨されていません。最新状況は Microsoft Learn の「Content Understanding の新機能」を確認してください。
Azure Content Understanding に新たな API バージョン 2026-06-01-preview が追加されました。ということで、単にアプリケーション側のバージョン文字列を差し替えるだけでよいでしょうか？いや、これでは更新の価値はほとんど見えてこないでしょう。
- 同じ PDF を解析したとき、何が増えたのか
- 既存の Markdown や JSON は変わるのか
- 変わったフィールドは、後段の RAG に影響するのか
- 差異は API 更新によるものか、モデルや解析オプションによるものか
リリースノートから「追加された機能」は分かります。しかし、自分の文書に対する「実際の出力差」は、解析して比較しなければ分かりませんよね。
そこで RAGOps Studio for Document Intelligence / Content Understanding v0.1.0 では、2026-06-01-preview 対応と UI 全体の更新に加えて、蓄積した解析結果を構造単位で比較する セマンティック Diff をアップデートしました。
この記事では、公式資料、RAGOps Studio v0.1.0 の実装、同一文書を GA と Preview で解析した実測結果の 3 つを突き合わせながら、更新内容を紹介します。
1. 公式の更新内容を確認
Microsoft Learn では、2025-11-01 を本番向け GA、2026-06-01-preview を Build 2026 wave の新機能を評価する API と位置付けています。API バージョン別機能比較と新機能一覧を整理すると、今回の主な差は次のようになります。
| 領域 |
2025-11-01 GA |
2026-06-01-preview |
|---|---|---|
| 本番対応 | 本番利用を推奨 | Public Preview、SLA なし |
| 文書推論 | 標準ワークフロー | Agentic モードを追加 |
| Read / Layout | 非同期操作 | 同期操作を追加 |
| 文書要素 | 既存の抽出・レイアウト要素 | 署名検出、埋め込みメタデータ抽出を追加 |
| 分類・分割 | 文書分類、セグメンテーション | レイアウトを使った分類とページ内分割を追加 |
| プリビルト | GA の税務アナライザー | Schedule K-1、Minnesota Form M1 などを追加 |
| 学習 | ラベル付き文書による学習 | 学習内容を構築済みアナライザーへ蒸留する方式を追加 |
私の注目ポイントは次の 5 点です。
1.1 Agentic モード
config.workflow に "agentic" を指定すると、単一箇所の値を抜き出すだけではなく、文書内の複数の証拠を使った計算、条件検証、表や図の視覚的な確認を伴う推論を実行できます。初期 Preview は 1 回の解析要求につき 1 入力ファイル、文書アナライザーのみをサポートし、method=extract のフィールドは利用できません。
1.2 Read / Layout の同期解析
prebuilt-read と prebuilt-layout では、URL 入力用の analyzeInline と、バイナリ入力用の analyzeBinaryInline が追加されました。同期操作は入力をメモリ内で処理して結果を直接返すため、Operation-Location を取得してポーリングする必要がありません。
1.3 署名検出と文書メタデータ
Preview の解析結果には、署名の位置と認識テキストを持つ signatures 配列、文書の作成者、作成日時、タイトル、言語などを持つ metadata オブジェクトが追加されます。利用できるメタデータはファイル形式によって異なります。
1.4 ページ内分割
従来のページ境界だけではなく、1 ページ内に複数の文書種別が混在する場合に、そのページを複数セグメントへ分割できます。結果には分割位置とカテゴリ割り当ての信頼度が含まれます。
1.5 Preview SDK
2026 年 8 月には、Python、.NET、Java、JavaScript / TypeScript 向けの 2026-06-01-preview 対応 SDK も公開されました。
2. 同一文書を GA と Preview で実際に比較
署名抽出機能が加わったことで、layout_pageobject_signature.pdf も署名入りにアップデートされましたね。
セマンティック Diff UI
エンジニアであれば、このレベルまで比較し、理解して初めて活用しようと思うのではないでしょうか？
これは 1 文書に対する実測であり、一般的な精度ベンチマークではありません。ただし「API バージョンを変えた結果、どのような構造差が現れるか」だけは確認できます。
2.1 まず、レスポンスの外形が違う
GA は analyzerId、apiVersion、contents が最上位にある直接結果でした。Preview の非同期結果は、最上位に id、status、result、usage があり、解析結果は result の内側にありました。
これは抽出品質の差ではなく、実行プロトコルと応答エンベロープの差です。比較前に正規化しなければ、ほぼ全パスが見かけ上の追加・削除になります。
2.2 署名が文字列から構造化要素になった
GA の Markdown では、署名領域の認識結果が次のような通常テキストでした。
Signature:
D
Preview では、次のような署名参照へ変わりました。
Signature:
同時に contents[0].signatures が追加され、今回の文書では 1 件の署名について source、span、elements、id が返りました。
2.3 文書メタデータが追加された
Preview 側には contents[0].metadata が現れ、今回の PDF では contentType、pageCount、author、createdAt を確認できました。GA 側の同じ位置には metadata オブジェクトがありませんでした。
2.4 実行条件も結果と一緒に記録した
Preview 側では、サービスが解決したワークフロー standard.2026-06-01-preview、API プロファイル、実行方式、要求アナライザー、実効アナライザー、構成ハッシュ、解析日時を _studio に記録しました。また、今回の応答には usage.documentPagesStandard = 1 が含まれていました。
analyzerConfigHash は API バージョンを入力に含むため、同じ UI オプションでも GA と Preview では異なります。これは品質差を表す値ではなく、実行条件の同一性を追跡するための識別情報です。
3. RAGOps Studio をはじめるメリット
この記事でいう RAGOps は、RAG パイプラインを構成する文書解析、分割、埋め込み、索引、検索、生成の各段階について、条件と結果を保存し、比較し、変更の影響を継続的に評価する運用プラクティスです。単に RAG アプリケーションを動かすのではなく、「どの入力を、どの API、モデル、設定で処理し、何が出力されたか」を追跡可能な状態にします。
この考え方は、Microsoft が GenAIOps について説明している再現性、データのバージョン管理、評価、監視、フィードバックループを、RAG の取り込み処理へ適用したものです。RAG における再現性とデータのバージョン管理によって、異なるチャンク分割や埋め込み戦略を比較し、以前の版へ戻せます。
3.1 キャッシュを「高速化」だけでなく「比較可能な履歴」にする
一般にキャッシュは、同じ処理を省略して応答時間と API コストを減らすために使われます。RAGOps Studio のキャッシュには、それに加えて 解析条件ごとの結果を残す役割があります。
保存単位には、次の情報が反映されます。
- 入力ファイルの SHA-256
- DI / CU の区別
- API プロファイルと API バージョン
- 同期 / 非同期の実行方式
- モデルまたはアナライザー ID
- 解析オプションとアナライザー上書きの署名
- 保存日時と実際に指定したオプション
- CU の要求アナライザー、実効アナライザー、解決済みワークフロー
同じ文書でも条件が違えば別バリアントとして並ぶため、「現在の結果」だけでなく「以前の条件ではどうだったか」を API の再実行なしで開けます。ライブラリから複数のバリアントを選べば、その場でセマンティック Diff を実行できます。
ここでいう履歴は、すべての実行イベントを追記する監査ログではありません。同一キャッシュキーは同じ成果物を参照し、キャッシュヒット時には API を再実行しません。RAGOps Studio v0.1.0 が保持するのは、文書と解析条件の組み合わせごとの結果スナップショットです。
3.2 変更を「導入作業」から「差分レビュー」へ変える
API、モデル、オプションを更新するとき、キャッシュがなければ旧条件と新条件をその都度そろえて再実行する必要があります。結果スナップショットが残っていれば、更新作業は次のような差分レビューになります。
この運用には、次のメリットがあります。
| Ops の課題 | キャッシュと比較による効果 |
|---|---|
| API 更新の影響範囲が分からない | 追加・削除・変更された JSON パスから調査対象を絞り込める |
| モデル変更の前後を再現できない | 入力ハッシュと解析条件を固定したバリアントをベースラインとして参照できる |
| オプションを試すたびに結果を失う | 条件ごとの結果がライブラリへ残り、横並びで比較できる |
| 再検証に時間と API コストがかかる | キャッシュ済み結果は API を呼び直さずに表示・比較できる |
| 障害時に「いつから変わったか」を説明しにくい | API バージョン、実効アナライザー、構成ハッシュ、保存日時を手掛かりに変更点を切り分けられる |
| チーム間で品質議論が抽象的になる | 「この文書のこの JSON パス、この座標、この Markdown」という共通の観測対象を持てる |
3.3 回帰を RAG の入口で見つける
RAG の回答品質が低下したとき、原因が生成モデルにあるとは限りません。文書解析時の読み順、表の構造、署名や図の扱い、Markdown、Span が変われば、その後のチャンク境界、埋め込み、検索結果も変わります。
たとえば今回の実測では、Preview で署名が構造化された結果、Markdown の長さと署名付近の Span も変わりました。後段が固定文字数や Span を前提にチャンクを作っていれば、検索インデックスへ登録される単位まで変化する可能性があります。
セマンティック Diff を文書解析層に置くと、この種の変化を検索・生成まで流す前に発見できます。つまり、障害発生後に生成回答だけを調べるのではなく、RAG パイプラインの入口で回帰候補を捕捉できます。
3.4 再現性と説明可能性を高める
MLOps では、再現可能なパイプライン、成果物に関連するメタデータ、ライフサイクルのリネージュ（系列）が品質保証とガバナンスに重要だとされています。RAGOps でも考え方は同じです。モデル名だけではなく、API バージョン、処理方式、オプション、入力文書まで対応付けなければ、結果を再現できません。
RAGOps Studio では、結果そのものと実行条件を近い場所に保存します。そのため、「Preview の方が良かった」という曖昧な記録ではなく、次の粒度で説明できます。
同一 SHA-256 の PDF を
prebuilt-layout、非同期、Markdown 出力で比較したところ、2026-06-01-previewではcontents[0].signaturesとcontents[0].metadataが追加され、署名部分の Markdown と Span が変化した。
この説明は、採用判断、問題調査、レビュー、後続パイプラインの修正方針をつなぐ運用記録になります。
3.5 小さく始めて、継続評価へ発展させられる
RAGOps Studio の比較は人が確認する対話型ワークベンチです。それでも、ベースラインを保存し、変更候補との差を確認するだけで、都度の手作業より再現性は高まります。
次の段階では、この結果スナップショットを評価データセットとして扱い、次の自動化へ発展させられます。
- 重要な JSON パスの存在とデータ型を検証するスキーマテスト
- Markdown や表構造の回帰テスト
- 数値許容差と除外パスを持つ自動 Diff
- 検索再現率、順位、回答品質の評価との関連付け
- CI / CD での品質ゲート
- 問題が見つかった場合の旧 API、モデル、構成へのロールバック判断
Microsoft の GenAIOps ガイダンスでも、内側のループに実験と評価、外側のループにデプロイ、推論監視、フィードバックを置いています。RAGOps Studio のキャッシュとセマンティック Diff は、その最初の足場として、試した結果を消さず、比較できる状態にすることを担います。
GitHub
参考
ちなみに RAGOps Studio for Azure AI Search のほうも Update して Serverless に対応しています