はじめに
Azure でドキュメント処理のシステムを設計していて、こんな壁にぶつかりませんでしたか？
「Document Intelligence の Read モデルで OCR してたんだけど、最近 Content Understanding にも Read があるって聞いて……どっち使えばいいの？」
自分もまったく同じところで詰まりました。名前が似すぎていて、ドキュメントを読んでも最初は違いがよく分からなかったです。
この記事では、2つの Read モデルを実際に調べて比較した結果をまとめます。
まず結論から（忙しい人向け）
テキスト抽出が必要
│
├─ テキストの「位置（座標）」が必要？
│ ├─ Yes → DI Read（bounding polygon付き）
│ └─ No ↓
│
├─ Searchable PDF（検索可能PDF）が必要？
│ ├─ Yes → DI Read
│ └─ No ↓
│
├─ DI の Invoice・Receipt・ID モデルと連携？
│ ├─ Yes → DI Read（基盤エンジンとして）
│ └─ No ↓
│
├─ RAG / 全文検索インデックスへ投入？
│ ├─ Yes → CU Read（低コスト・高速）
│ └─ No ↓
│
├─ 数式・バーコードが含まれる？
│ ├─ Yes → CU Read
│ └─ No ↓
│
└─ 後続で CU フィールド抽出・推論を使う予定？
├─ Yes → CU Read（エコシステムで完結）
└─ No → どちらでも可（コスト優先なら CU Read）
サービスの名前、ちゃんと整理しておきます
まず自分が混乱したポイントから。Azure AI Foundry の中の構造はこうなっています。
Azure AI Foundry
├── Azure Document Intelligence（旧 Form Recognizer）
│ └── prebuilt-read ← 今回の比較①
│
└── Azure Content Understanding
├── Azure-Content-Understanding-Read ← 今回の比較②
├── Azure-Content-Understanding-Layout
├── prebuilt-contract, prebuilt-invoice...
└── Custom analyzers
Document Intelligence（DI）は昔からある「専門訓練モデル」で、Content Understanding（CU）は生成 AI ベースの新しいやつです。どちらも今は Azure AI Foundry に統合されていますが、中身の作りは全然違います。
Document Intelligence Read（prebuilt-read）
どんなモデルか
prebuilt-read は PDF・スキャン画像・Office ファイルからテキストを抽出する OCR エンジンです。
ちょっと知っておくと便利なのが、DI の Invoice や Receipt などのプリビルトモデルは、内部でぜんぶこの Read を使っているという点です。つまり DI エコシステムの土台になっているモデルです。
出力してくれるもの
pages：ページの幅・高さ・傾き角度paragraphs：段落テキスト + 座標（bounding polygon）lines：行テキスト + 座標words：単語 + 座標 + 信頼スコア（confidence）styles：手書きかどうかの判定 + 信頼スコア
座標情報と信頼スコアが取れるのが DI Read の強みです。「このテキストは PDF の何ページ目のどの位置にある」まで分かります。
地味に便利な機能
Searchable PDF 出力という機能があって、スキャンした PDF（画像として埋め込まれているもの）を Ctrl+F で検索できる PDF に変換してくれます。しかも追加費用なし。例えば月次の紙帳票スキャンを SharePoint に上げて全文検索できるようにする、みたいな運用に直接使えます。
対応フォーマット
| 形式 | 対応 | メモ |
|---|---|---|
| ✅ | 最大 2,000 ページ / 500 MB | |
| JPEG / PNG / BMP / TIFF / HEIF | ✅ | |
| Word (DOCX) | ✅ | 3,000 文字 = 1 ページ換算 |
| Excel (XLSX) | ✅ | シート = 1 ページ換算 |
| PowerPoint (PPTX) | ✅ | スライド = 1 ページ換算 |
| HTML | ✅ |
Office 形式まで対応しているのは意外と便利です。
価格
- ~$10 / 1,000 ページ（有料プラン）
- 毎月 500 ページ無料
Azure Content Understanding Read
どんなモデルか
Azure-Content-Understanding-Read（長い……）は、Microsoft Foundry のモデルカタログに掲載されている新しい Read モデルです。
公式の説明がこれです：
「レイアウト解釈なしで、ドキュメントからテキストと基本コンテンツ要素を高速・確実に抽出する。シンプルなインジェストワークフローに最適。」
つまり 「位置情報とかレイアウト解析はしない。テキストだけ速くキレイに出す」 というコンセプトです。
出力してくれるもの
words、lines、paragraphsformulas：数式（DI Read にはない！）barcodes：バーコード（DI Read にはない！）
DI Read にない数式・バーコード抽出があるのは地味に嬉しいポイントです。理工系や製造業のドキュメントを扱うなら刺さるかもしれません。
ただし bounding polygon（座標）は返してくれません。テキストがどこにあるかは分からない設計です。
料金の構造（ここがちょっと複雑）
CU の料金は 2 段構えになっています。
① コンテンツ抽出（OCR）の料金：
| メーター | 対象 | 目安 |
|---|---|---|
| Minimal | デジタルドキュメント（DOCX/XLSX/HTML 等） | 最安 |
| Basic | 画像系ドキュメントの OCR（= CU Read） | ↑より高い |
| Standard | 画像系のレイアウト解析（= CU Layout） | 参考: ~$5/1,000p ※1 |
② 生成系機能（LLM）の料金：
prebuilt-read を純粋な OCR として使うだけなら LLM の課金はありません。フィールド抽出とか推論機能を使ったときだけ課金されます。
なので、単純にテキストを抽出するだけの用途なら CU Read は DI Read より安い、というのが結論です。
※1 価格は 2026 年 6 月時点の参考値です。Azure Pricing Calculator で最新価格を必ず確認してください。
機能を並べて比べる
まとめ比較表
| 観点 | DI Read | CU Read |
|---|---|---|
| 印刷テキストの OCR 精度 | ★★★★★（業界最高水準） | ★★★★ |
| 手書き検出 | ★★★ | ★★★★ |
| テーブル・表 | ★★★★（Layout 別途必要） | ★★★ |
| 多言語対応 | ★★★★ | ★★★★ |
| 処理速度 | Fast | Fast（レイアウトなし分 ちょっと軽い） |
| 座標（bounding polygon） | ✅ | ❌ |
| 単語単位の信頼スコア | ✅ | ❌ |
| Searchable PDF 出力 | ✅（無料） | ❌ |
| 数式・バーコード | ❌ | ✅ |
| Office 形式（DOCX 等） | ✅ | 未確認 ※2 |
| 推論・演算フィールド | ❌ | ✅（CU の機能として） |
| 価格目安 | ~$10/1,000p | Basic meter（< $5/1,000p）※1 |
| API バージョン | 2024-11-30 (GA) | 2025-11-01 (GA) |
※2 CU Read の Office 形式対応は公式ドキュメントに明示されていないため未確認です。
OCR 精度について
印刷テキストは DI Read が依然として業界最高水準です。ただ手書きは CU Read の方が精度が良い傾向があります（LLM の文脈理解が効いているっぽい）。
日本語について
DI Read は日本語を含む 73 言語以上に公式対応していて、Language Support ページ で確認できます。
CU Read の言語別精度は今のところ公式の定量データが出ていません。日本語の重要なドキュメントに使う場合は、事前に自分のドキュメントで検証することをお勧めします。
「OCR だけなら CU を使え」と Microsoft が言い始めた
ここが一番驚いたポイントです。
Microsoft の公式ドキュメント「Choose the right Azure AI tool」にこう書いてあります：
「OCR またはレイアウト抽出のみ」→ CU prebuilt-read または prebuilt-layout を推奨
理由：「より低コストでリッチなレイアウト抽出」
長年 DI の主力だった Read モデルを、Microsoft 自身が「OCR 用途なら CU に切り替えを」と言っている状況です。
なぜこうなったのかを考えると、3 つの理由が見えてきます。
コストが安い：DI Read は ~$10/1,000p の固定。CU Read は Basic メーター（それより安い）。シンプルな OCR 用途なら乗り換えるとコストが下がります。
後続パイプラインとの相性が良い：CU エコシステムで RAG・検索・フィールド抽出まで一気通貫で作れます。DI Read で始めると、後で CU に移行するときに若干つなぎが面倒です。
アーキテクチャが進化している：CU は複数の AI モデルを並列で走らせてクロスバリデーションする設計になっています。単純な OCR 以上のことが同じ API でできます。
とはいえ DI Read が要らなくなったわけでは全然なくて、座標情報が必要・Searchable PDF を使いたい・Office ファイルを処理したい・オンプレに展開したい、といったケースでは引き続き DI Read が唯一の選択肢だったりします。
どっちを使うか、シナリオ別に整理
CU Read を選ぶケース
- RAG の前処理：LLM に渡すだけなら座標は要らないので CU Read で十分です
- Azure AI Search へのインジェスト：テキストだけ欲しいケース
- テキスト分類・タグ付けのバッチ処理：大量・低コストが正義
- 数式・バーコードが含まれる文書：理工系、製造業、物流系のドキュメント
- 後続で CU のフィールド抽出も使う予定：エコシステムで揃えるのが楽
DI Read を選ぶケース
- テキストの座標が必要：「この文字列は PDF の何ページ目のここにある」が必要な処理
- 単語単位の信頼スコアで品質管理したい：金融・医療・法務など精度要件が厳しい業務
- スキャン PDF を Searchable PDF に変換したい：追加費用なしで使えるので便利
- DI の Invoice・Receipt・ID モデルと組み合わせている：既存パイプラインをそのまま使える
- Word や Excel ファイルをそのまま OCR したい
- オンプレ・ネットワーク分離環境に展開したい：DI コンテナが現状唯一の選択肢
コスト感を掴む：月 10 万ページ処理した場合
⚠️ 以下は参考試算です。正確な価格は Azure Pricing Calculator で確認してください。
| サービス | 月額概算 | 備考 |
|---|---|---|
| DI Read | ~$1,000 | $10 × 100 |
| CU Read (Basic) | 推定 $300〜$500 | Standard ($5/1,000p) より安い Basic meter の試算 |
OCR のみの用途なら CU Read の方がかなり安く済む可能性があります。
ちなみに CU でフィールド抽出（LLM 使用）まで回すと、GPT-4.1 使用・1,000 ページで概算 $6.54（公式 pricing-explainer の計算例より）。GPT-4.1-mini に切り替えるとさらに削減できます。
API バージョンの廃止、要注意
2026 年 7 月 15 日に以下のプレビュー API が廃止されます：
2024-12-01-preview2025-05-01-preview
使っている場合は早めに移行を。
現在の推奨 GA バージョン：
– DI：2024-11-30（v4.0 GA）
– CU：2025-11-01（GA）
GA 版 DI をすでに使っている人は API・エンドポイント・SDK とも変更なしなので、特に何もしなくて大丈夫です。
まとめ
| DI Read | CU Read | |
|---|---|---|
| 一言で | 高精度・座標付き OCR エンジン | 速い・安い・CU エコシステムに乗れる |
| 強み | 印刷 OCR 精度、座標情報、PDF 変換 | コスト、速度、後続パイプラインとの相性 |
| 弱み | コストが高め、GenAI 機能なし | 座標なし、Office 対応不明 |
| 向いてる用途 | フォーム解析、QC、PDF 変換 | RAG 前処理、検索、分類バッチ |
個人的な感想としては、新しく RAG システムや検索基盤を作るなら CU Read から入るのがスムーズだと思います。既存の DI Read パイプラインが動いているなら無理に移行する必要はないですが、新規設計なら CU ベースで考えておくと後々フィールド抽出などに展開しやすいです。
ただし日本語ドキュメントへの CU Read 適用は、精度の公式データがまだ少ないので、必ず自分のドキュメントで検証してから本番投入することをお勧めします。
(←参考になった場合はハートマークを押して評価お願いします)
読み込み中...