Azure AI Foundryで帳票、PDF、請求書、契約書、本人確認書類などを扱っている場合、今回まず確認すべき点はシンプルです。Azure Document Intelligence in Foundry Toolsは、Foundry Tools配下のドキュメント処理サービスとして整理され、最新の推奨バージョンはv4.0 GAです。v2.1とv3.0は廃止予定のため、APIバージョン、SDK、カスタムモデル、出力JSONの扱いを棚卸しする必要があります。
特に、REST API v2.1は2027年9月15日、REST API 2022-08-31 v3.0は2029年3月30日にサポート終了予定です。運用中のシステムで古いAPIを使っている場合は、単なる名称変更として見過ごさず、Azure Document Intelligence 2024-11-30 v4.0への移行計画を立てるべきです。(Microsoft Learn)
まず結論：Azure AI FoundryのDocument Intelligenceで確認すべきこと
Azure AI Foundryの「Document Intelligence in Foundry Tools」は、OCRだけのサービスではありません。機械学習ベースのOCRとドキュメント理解技術を使い、文書からテキスト、表、構造、キーと値のペアを抽出するためのクラウドサービスです。公式ドキュメントでは、v4.0 GA、v3.1 GA、v3.0廃止予定、v2.1廃止予定というバージョンの位置づけが示されています。(Microsoft Learn)
| 確認項目 | 実務上の判断 |
|---|---|
| サービス名 | Azure Document IntelligenceがFoundry Tools配下のサービスとして整理されている |
| 最新バージョン | v4.0 GA、REST APIは2024-11-30がGA |
| 既存利用への影響 | v3.1はGAだが、v3.0とv2.1は廃止予定 |
| 管理者の優先作業 | 利用中のAPIバージョン、リージョン、認証、ネットワーク、課金対象機能を確認 |
| 開発者の優先作業 | SDK、エンドポイント、モデルID、レスポンスJSON、カスタムモデルを確認 |
| 移行の注意点 | 出力形式や分類モデルの挙動が変わる可能性があるため、実データで回帰テストする |
重要なのは、「Foundry Toolsという名称になったから何かがすぐ壊れる」という話ではなく、古いAPIバージョンや古いモデル運用を続けているシステムほど、移行準備が必要になるという点です。
Azure Document Intelligence in Foundry Toolsとは
Azure Document Intelligence in Foundry Toolsは、文書を「読めるデータ」から「業務で使える構造化データ」に変換するためのサービスです。PDF、画像、フォームなどからテキスト、テーブル、キーと値のペア、文書構造を抽出できます。Azure AI Foundry Toolsの一部として、Language、Vision、Content Understandingなど他のツールと組み合わせやすい位置づけになっています。(Microsoft Azure)
主な用途は次のとおりです。
- 請求書から取引先名、請求額、明細、税額を抽出する
- 契約書から契約当事者、契約日、条件項目を抽出する
- レシートや領収書を経費精算システムに連携する
- 本人確認書類や保険証などから定型項目を取り出す
- 社内文書を検索、RAG、ナレッジベース用に前処理する
- 独自フォーマットの帳票にカスタムモデルを適用する
モデルは大きく分けて、読み取りやレイアウト解析を行うドキュメント分析モデル、請求書・レシート・ID・契約書などに対応する事前構築済みモデル、自社帳票に合わせて学習するカスタムモデルがあります。(Microsoft Learn)
2026年5月8日時点の公式情報で押さえる変更点
日本語版の公式ドキュメントは2026年5月8日に更新されており、v4.0 GAを中心に、v3.1 GA、v3.0廃止予定、v2.1廃止予定の位置づけが整理されています。(Microsoft Learn)
v4.0 GAが最新の移行先になる
Document Intelligence REST API v4.0は、2024-11-30 REST APIとして一般提供されています。v4.0では、Batch API、検索可能なPDF、カスタム分類モデル、カスタムニューラルモデル、各種事前構築済みモデルなどで変更や機能追加があります。(Microsoft Learn)
特に開発者が見落としやすいのは、単にAPIバージョンを差し替えるだけでは済まない場合があることです。SDK、リクエストパラメーター、レスポンスの読み取り処理、カスタムモデルの再学習、分類モデルのページ分割設定まで確認する必要があります。
v2.1とv3.0は廃止予定
公式情報では、REST API v2.1は2027年9月15日、REST API 2022-08-31 v3.0は2029年3月30日にサポート終了予定とされています。運用停止を避けるには、Azure Document Intelligence 2024-11-30 v4.0への移行が推奨されています。(Microsoft Learn)
現時点でv2.1を使っている場合は、残り時間があるように見えても、実際には早めに動くべきです。v2.1からの移行では、APIの呼び出し方、エンドポイント、レスポンス形式、モデルの扱いが大きく変わる可能性があります。
「Foundry Tools化」は名称だけでなく運用整理のタイミング
Azure Document Intelligenceは、以前はAzure AI Servicesの一部として説明されることが多かったサービスですが、現在はAzure AI Foundry ToolsのDocument Intelligenceとして位置づけられています。公式FAQでも、Azure AI Foundryの下での広範なプラットフォーム統合の一環として説明されています。(Microsoft Azure)
そのため、管理者は「既存のAI OCRサービス」としてだけでなく、Azure AI Foundry上のアプリ、エージェント、検索、Content Understanding、Azure OpenAI in Foundry Modelsなどと組み合わせる前提で、権限管理やデータ連携を見直すとよいでしょう。
影響を受けやすい利用者とシステム
今回の確認対象は、Document Intelligenceを直接APIで呼んでいる開発者だけではありません。Azureリソースを管理する担当者、セキュリティ担当、業務システムの運用担当、FinOps担当にも影響があります。
| 対象者 | 確認すべき内容 | 見落とした場合のリスク |
|---|---|---|
| Azure管理者 | リソース、リージョン、認証、ネットワーク、キー管理 | 本番環境からAPIに接続できない、権限不足、監査不備 |
| 開発者 | APIバージョン、SDK、モデルID、レスポンスJSON | パースエラー、抽出項目の欠落、既存ロジックの誤判定 |
| 業務担当者 | 抽出精度、対象帳票、例外処理 | 請求処理や審査業務で誤ったデータを利用する |
| セキュリティ担当 | 個人情報、保存期間、削除API、アクセス制御 | 機密文書や分析結果の取り扱いが社内基準に合わない |
| FinOps担当 | Premium機能、トレーニング、コンテナー、実行回数 | 想定外のコスト増加 |
特に、ocr.highResolution、ocr.formula、ocr.fontなどの追加機能は便利ですが、Premium機能として追加コストが発生する可能性があります。必要な文書だけに限定して有効化し、全リクエストに機械的に付ける運用は避けるべきです。(Microsoft Learn)
管理者が確認すべき設定
APIバージョンを棚卸しする
最初に行うべき作業は、すべてのアプリケーションで使っているDocument IntelligenceのAPIバージョンを洗い出すことです。
確認対象は、アプリケーションコードだけではありません。環境変数、IaCテンプレート、Azure Functions、Logic Apps、Power Automate、コンテナー設定、CI/CDのシークレット、社内ライブラリも対象です。
grep -R "api-version=2022-08-31\|api-version=2023-07-31\|api-version=2024-11-30\|formrecognizer/v2.1\|prebuilt-document" .この検索で、2022-08-31、v2.1、prebuilt-documentなどが見つかった場合は、移行影響を詳細に確認します。一般ドキュメントモデルであるprebuilt-documentは、2023-10-31-previewで非推奨となっており、キーと値のペアを抽出する場合はprebuilt-layoutでfeatures=keyValuePairsを使う方向が示されています。(Microsoft Learn)
リージョンと提供状況を確認する
Document Intelligenceはリージョンによって利用可否や機能の提供状況が変わる場合があります。公式概要でも、リージョンアクセスは製品のリージョン別可用性を確認するよう案内されています。(Microsoft Learn)
特に確認すべきケースは次のとおりです。
- 本番、検証、DR環境でリージョンが異なる
- 新機能を使う予定がある
- コンテナー版とクラウド版を併用している
- 日本語文書、CJK文書、複数言語文書を処理している
- 社内規定でデータ保存地域が制限されている
「開発環境で動いたから本番リージョンでも同じように動く」と判断せず、リージョンごとに確認するのが安全です。
認証とアクセス制御を見直す
Document Intelligence Studioでは、Microsoft Entra認証のサポート追加も公式の更新履歴に記載されています。(Microsoft Learn)
管理者は、次の点を確認してください。
| 確認項目 | 実務上のポイント |
|---|---|
| APIキー | キーの保管場所、ローテーション手順、不要キーの削除を確認 |
| Managed Identity | Azure Functions、App Service、AKSなどからのアクセス権限を確認 |
| Microsoft Entra ID | Studio利用者、開発者、運用担当の権限を分離 |
| ネットワーク制御 | パブリックアクセス、ファイアウォール、Private Endpoint、DNSを確認 |
| 監査 | 誰がモデルを作成・更新・削除できるかを記録できる状態にする |
本番運用では、開発者全員に広い権限を与えるのではなく、モデル作成、テスト、デプロイ、監査を分ける設計が望まれます。
データ保持と削除要件を確認する
v4.0では、分析応答は操作完了後に取得のため一定期間保持され、必要に応じて分析応答を削除するAPIが用意されています。公式情報では、分析応答は操作完了後24時間保存され、より早く削除したい場合はdelete分析応答APIを使うと説明されています。(Microsoft Learn)
個人情報、契約書、医療・金融関連文書を扱う場合は、次のルールを事前に決めておきます。
- 分析対象ファイルをどこに保存するか
- 分析結果JSONをどこに保存するか
- 保存期間を何日にするか
- 削除APIをどのタイミングで呼ぶか
- 監査ログをどこまで残すか
- LLMや検索インデックスへ連携する前にマスキングが必要か
Document Intelligence自体の設定だけでなく、後段のデータベース、ストレージ、検索インデックス、AIエージェント側の保存設計まで含めて確認してください。
開発者が確認すべき移行ポイント
SDKを最新世代に更新する
v4.0 SDKは一般提供されており、最新のクライアントライブラリは2024-11-30 REST APIを既定で使用します。C#、Java、JavaScript、Python向けのクライアントライブラリが案内されています。(Microsoft Learn)
SDKを更新する際は、単にパッケージを上げるだけでなく、次の点を確認します。
- 明示的に古いAPIバージョンを指定していないか
- SDKのメソッド名や戻り値の型が変わっていないか
- 非同期処理のポーリング方法が変わっていないか
- エラーコード、例外クラス、リトライ処理が既存実装と合うか
- 本番で使うモデルIDがv4.0で期待通り動くか
移行ガイドでは、v4.0 SDKに合わせてアプリケーションコードを更新し、新しいAPIメソッドや更新されたレスポンス形式を扱う手順を確認するよう案内されています。(Microsoft Learn)
レスポンスJSONの差分を確認する
古いAPIから移行する場合、最も失敗しやすいのがレスポンスJSONの扱いです。移行ガイドでは、REST API 2023-07-31に分析応答JSONの破壊的変更が含まれ、boundingBoxがpolygonに変更されることが説明されています。(Microsoft Learn)
また、分析結果はpages、tables、keyValuePairs、entities、styles、documentsなどのトップレベル要素として扱われます。古い実装で「1ページ目の特定プロパティ」を直接読んでいる場合、移行後に値が取れなくなる可能性があります。(Microsoft Learn)
移行時は、次のような差分テストを行いましょう。
| テスト観点 | 確認内容 |
|---|---|
| フィールド名 | 旧APIで取得していた項目が新APIでも取れるか |
| 座標情報 | boundingBox前提の処理がpolygonに対応しているか |
| テーブル | 行、列、結合セル、ヘッダーが期待通りか |
| 信頼度 | confidenceの閾値判定をそのまま使えるか |
| 複数ページ | ページをまたぐ表や項目で欠落がないか |
| 日本語 | 全角、半角、縦書き、手書き、印影、住所表記を確認 |
カスタム分類モデルのsplitModeに注意する
v4.0では、カスタム分類モデルの分析時にドキュメントが既定で分割されなくなっています。古い動作を維持したい場合は、splitModeプロパティを明示的にautoに設定する必要があります。(Microsoft Learn)
これは、複数の帳票が1つのPDFにまとまっているケースで特に重要です。
例えば、次のような入力を扱っている場合は必ず確認してください。
- 請求書、納品書、領収書が1つのPDFにまとめられている
- ローン申請書類のように複数種類の書類が束になっている
- スキャンセンターで複数伝票を連続スキャンしている
- 申込書と本人確認書類を同時にアップロードしている
分類モデルがページ分割をしない前提に変わると、後段の抽出モデルに渡す単位が変わり、抽出精度や業務判定に影響する可能性があります。
カスタムモデルの有効期限と再学習を確認する
移行ガイドでは、カスタム抽出モデルや分類モデルに有効期限が導入され、期限が切れた場合は最新のAPIバージョンを使って再トレーニングする必要があると説明されています。(Microsoft Learn)
管理画面上でモデルが存在していても、将来的に使い続けられるとは限りません。次の情報を台帳化しておきましょう。
- モデルID
- 作成日
- APIバージョン
- 有効期限
- 学習データの保存場所
- ラベル付けルール
- 精度評価結果
- 再学習の担当者
- 本番反映手順
カスタムモデルは、一度作って終わりではありません。帳票のレイアウト変更、税率表示の変更、社内フォーム改訂、取引先フォーマットの追加に合わせて、定期的に再評価する運用が必要です。
v4.0で注目すべき機能と業務への影響
Batch APIで大量処理の設計がしやすくなる
v4.0のBatch APIでは、読み取り、レイアウト、事前構築済みモデル、カスタムモデルを含むすべてのモデルがサポートされるようになり、過去7日以内のバッチジョブ一覧や、プライバシー対応のための削除機能もサポートされています。(Microsoft Learn)
大量のPDFを夜間に処理する、月次で請求書をまとめて解析する、バックオフィス処理をバッチ化する、といった業務では検討価値があります。
ただし、Batch APIを使う場合でも、次の設計は必要です。
- 失敗ジョブの再実行ルール
- 処理済みファイルの重複防止
- ジョブIDと業務IDの対応付け
- エラー時の通知先
- 削除APIの実行タイミング
- 処理件数とコストの監視
検索可能なPDFは日本語文書の活用に効く
v4.0では、事前構築済みの読み取りモデルで検索可能なPDF出力がサポートされ、中国語、日本語、韓国語を含むPDF出力の言語拡張が説明されています。(Microsoft Learn)
これは、紙文書やスキャンPDFを社内検索、監査、ナレッジベースに使いたい企業にとって有用です。例えば、紙の契約書を検索可能なPDFに変換し、さらに検索インデックスやRAGシステムに連携する流れを作れます。
ただし、検索可能なPDFを作っただけでは業務利用に十分とは限りません。重要項目を抽出して業務システムに登録する場合は、レイアウトモデル、事前構築済みモデル、カスタムモデルとの使い分けが必要です。
2026年の更新では米国税フォームモデルにも変更がある
公式の新機能ページでは、2026年3月の更新として、米国税フォーム向けの事前構築済みモデルが2025年税フォームをサポートし、複数のW-2や1099などのマルチコピー抽出に関する品質改善が含まれると説明されています。(Microsoft Learn)
日本国内のみの業務では影響が限定的ですが、米国法人、海外給与、グローバル会計、外資系企業のバックオフィスでは確認対象になります。
モデル選定の実務判断
Document Intelligenceでは、最初からカスタムモデルを作る必要はありません。標準的な帳票なら事前構築済みモデル、自由度の高い文書ならレイアウト解析、独自帳票ならカスタムモデルを検討します。
| ユースケース | 推奨しやすいモデル | 判断基準 |
|---|---|---|
| 請求書処理 | prebuilt-invoice | 一般的な請求書項目を抽出したい |
| 領収書・レシート処理 | prebuilt-receipt | 経費精算や店舗データ処理に使う |
| 契約書の基本項目抽出 | prebuilt-contract | 契約当事者や契約情報を取りたい |
| 社内文書の検索前処理 | prebuilt-readまたはprebuilt-layout | テキスト化、表、構造を重視する |
| 独自フォーマット帳票 | カスタムテンプレート | レイアウトが比較的固定されている |
| 非定型・半構造化文書 | カスタムニューラル | レイアウトが揺れるが項目抽出したい |
| 複数種類の書類パック | カスタム分類モデル | 抽出前に文書タイプを判定したい |
実務では、「どのモデルが最も高精度か」だけで選ぶと失敗します。保守性、再学習のしやすさ、コスト、処理速度、例外時の人手確認フローまで含めて判断してください。
移行前に行うべき検証手順
移行は、開発環境でAPIが1回成功しただけでは不十分です。次の手順で進めると、運用トラブルを減らせます。
| 手順 | 作業内容 | 完了条件 |
|---|---|---|
| 棚卸し | APIバージョン、SDK、モデルID、利用機能を一覧化 | 古いAPI利用箇所が特定できている |
| 影響分類 | v2.1、v3.0、v3.1、v4.0利用システムを分ける | 移行優先度が決まっている |
| SDK更新 | 最新SDKまたはv4.0 REST APIに合わせて修正 | ビルドと単体テストが通る |
| 出力差分確認 | 旧APIと新APIで同じ文書を処理 | フィールド値、表、座標、信頼度の差分が把握できている |
| カスタムモデル確認 | 有効期限、再学習、モデルコピーを確認 | 本番で使うモデルの継続利用可否が明確 |
| セキュリティ確認 | 認証、ネットワーク、データ保持、削除APIを確認 | 社内基準に合っている |
| 段階展開 | 一部ユーザー、少量データ、限定業務から切り替え | エラー率と精度が許容範囲 |
| 本番移行 | 監視、ロールバック、問い合わせ窓口を用意 | 業務影響なく切り替えられる |
検証データは、きれいなサンプルだけでは不足です。実際に現場で発生する汚いスキャン、傾いた画像、手書き、押印、複数ページ、表の途中改ページ、縦書き、旧フォーマットを含めてください。
よくある失敗と対策
名称変更だけだと思い込む
Foundry Tools配下に整理されたことだけを見て、「既存システムには関係ない」と判断するのは危険です。実際に確認すべき本質は、APIバージョン、SDK、モデル、レスポンス形式、サポート終了日です。
レスポンスの項目名変更を見落とす
boundingBoxからpolygonへの変更のように、抽出結果の意味は近くてもプロパティ名が変わる場合があります。画面表示、座標ハイライト、表抽出、帳票レビュー画面を作っている場合は、UI側も影響を受けます。(Microsoft Learn)
Premium機能を全リクエストで有効にする
高解像度OCR、数式、フォント抽出などは便利ですが、すべての文書に必要とは限りません。たとえば、請求書の合計金額だけを抽出する処理でフォント情報まで毎回取得するのは、コストと処理時間の面で無駄になる可能性があります。
カスタム分類モデルのページ分割を確認しない
v4.0では、カスタム分類モデルの既定の分割挙動が古いバージョンと異なる可能性があります。複数帳票をまとめて投入している場合、splitModeを明示するかどうかで後続処理が変わります。(Microsoft Learn)
旧モデルの再学習計画がない
カスタムモデルは、期限、基盤モデル、学習データ、ラベル定義に依存します。担当者が異動した後に再学習できない、学習データが削除されている、ラベルルールが文書化されていない、といった問題は本番移行時によく発生します。
Azure AI Foundry連携で考える活用シーン
Document Intelligenceは、単体のOCRとして使うより、Azure AI Foundry上の他機能と組み合わせることで価値が出ます。
例えば、社内規程や契約書を処理する場合は、次のような流れが考えられます。
- Document IntelligenceでPDFからテキスト、表、構造を抽出する
- 抽出結果を検索インデックスやデータベースに保存する
- Azure AI Foundry上のモデルやエージェントで要約、分類、照会を行う
- 重要項目は人間のレビューを通して確定する
- 監査ログとデータ削除ポリシーを適用する
このとき、Document Intelligenceの出力をそのままLLMに渡すだけでは不十分です。機密情報のマスキング、抽出信頼度が低い項目の人手確認、原本PDFとの照合、誤抽出時の修正フローを組み込む必要があります。
今日から行うべき確認リスト
最後に、管理者と開発者がすぐ確認できるチェックリストを整理します。
| 優先度 | 確認内容 |
|---|---|
| 高 | REST API v2.1または2022-08-31 v3.0を使っていないか |
| 高 | SDKがv4.0対応の現行バージョンになっているか |
| 高 | prebuilt-documentや古いエンドポイントを使っていないか |
| 高 | カスタムモデルの有効期限と再学習手順を把握しているか |
| 高 | 本番帳票でv4.0の抽出結果を比較検証したか |
| 中 | Premium機能を必要な文書だけに限定しているか |
| 中 | 分析結果の保存期間と削除APIの運用を決めているか |
| 中 | リージョン、ネットワーク、Private Endpoint、認証方式を確認したか |
| 中 | Batch APIや検索可能PDFを業務改善に使えるか検討したか |
| 低 | Foundry Toolsとして他のAI機能と連携する設計を検討したか |
Azure AI FoundryのDocument Intelligenceは、文書処理を自動化する強力なサービスですが、古いAPIや古いカスタムモデルを放置すると、将来のサポート終了や移行時の不具合につながります。まずは利用中のAPIバージョンとモデルを棚卸しし、v4.0への移行影響を実データで確認してください。そのうえで、管理者は認証・ネットワーク・データ保持を、開発者はSDK・レスポンス形式・モデル挙動を重点的に見直すのが現実的な進め方です。
コメント