2026年6月3日に公開・更新された「[Launched] Generally Available: Improved PDF batch document translation in Azure AI Translator」は、Azure AI FoundryでPDF翻訳を扱う管理者・開発者にとって、実運用の見直し対象になるアップデートです。結論から言うと、Azure AI TranslatorのPDFバッチドキュメント翻訳で、デジタルPDFとスキャンPDFの構造をより適切に復元しながら翻訳できるようになったため、手作業のOCR前処理やPDF変換ワークフローを減らせる可能性があります。公式更新では、Azure AI Document Intelligenceを使ってPDFの構造を回復し、認識したテキストを翻訳すると説明されています。(Microsoft Azure)
ただし、「どんなPDFでも完全に元の見た目で翻訳できる」という意味ではありません。スキャン品質、フォント、表組み、翻訳後の文字量、パスワード保護、デジタル要素とスキャン要素が混在するPDFなどでは、事前検証が必要です。この記事では、Azure AI FoundryのAI/Copilot活用にも関係するPDF翻訳改善について、変更点、影響範囲、管理者・開発者が確認すべき設定、移行・展開時の注意点を実務目線で整理します。
Azure AI FoundryのPDFバッチ翻訳改善で何が変わるのか
今回の更新は、Azure AI TranslatorのDocument Translation、特に非同期のバッチドキュメント翻訳でPDFを扱う処理に関する改善です。Microsoft Learnの「What’s new」では、Document Translation API version 2026-03-01 のGAリリースとして、PDF翻訳改善、画像翻訳、Office文書内画像の翻訳、同期・非同期モードの整理が説明されています。PDF翻訳改善では、Azure Document Intelligenceを使ってPDF文書を翻訳し、レイアウトと構造の保持を支援するとされています。(Microsoft Learn)
実務上のポイントは、PDFを「ただ文字列として抜き出して翻訳する」のではなく、文書の構造を意識して処理する方向に進んだことです。マニュアル、契約書、仕様書、申請書、製品カタログ、調査レポートなど、レイアウトに意味があるPDFでは、翻訳後の読みやすさや後工程の修正工数に影響します。
一方で、Azure AI FoundryのエージェントやCopilot的なアプリが自動的にすべてのPDF翻訳問題を解決する、という話ではありません。正しく捉えるなら、多言語ドキュメントをAIアプリや業務システムに組み込む前段の処理品質が上がる更新です。社内ナレッジを翻訳して検索・RAG・問い合わせ対応に使う場合も、翻訳前のPDF構造が保持されやすくなることで、確認作業や再整形の負担を減らせる可能性があります。
今回の変更点を実務目線で整理
| 観点 | 変更・改善の内容 | 実務で見るべきポイント |
|---|---|---|
| 公開状態 | 「Launched」「Generally Available」として公開 | 本番利用を前提に検討しやすい段階。Azure UpdatesのLaunchedは、一般提供済みで本番利用可能な状態を示します。(Microsoft Azure) |
| 対象機能 | Azure AI Translatorのバッチドキュメント翻訳におけるPDF翻訳 | 単発の手動翻訳ではなく、複数PDF・大容量文書をまとめて処理する運用に関係します。 |
| PDF処理 | Azure AI Document Intelligenceを使い、デジタルネイティブPDFとスキャンPDFの構造を復元して翻訳 | OCR前処理、PDFのWord化、手作業のレイアウト修正をどこまで減らせるか検証する価値があります。(Microsoft Azure) |
| 既存要件 | 非同期バッチ翻訳では、Azure Blob Storageのソース/ターゲットコンテナと認証設定が必要 | 既存のストレージ設計、SAS、マネージドID、RBACの見直しが必要です。(Microsoft Learn) |
| 注意点 | PDFの種類によって翻訳品質やレイアウト保持に差が出る | ネイティブPDF、スキャンPDF、混在PDF、パスワード付きPDFを分けてテストする必要があります。(Microsoft Learn) |
ここで重要なのは、今回の更新を「PDFが翻訳できるようになった」と単純に理解しないことです。PDF形式自体はDocument Translationのサポート対象に含まれており、スキャンPDFについてもOCRを使って翻訳する説明があります。今回の注目点は、PDF処理の改善がGAとして整理され、Azure AI Document Intelligenceによる構造復元を前提にした翻訳品質向上が示されたことです。(Microsoft Learn)
影響が大きい利用シーン
海外拠点向けのマニュアル・手順書翻訳
製造業、医療機器、SaaS、社内IT部門などでは、PDFの操作手順書や業務マニュアルを複数言語に展開することがあります。従来はPDFからテキストを抽出し、翻訳後にWordやDTPツールで整える工程が発生しがちでした。
今回の改善により、特に次のようなPDFで検証する価値があります。
- 見出し、本文、注釈、図表が混在するマニュアル
- 表や箇条書きが多い業務手順書
- スキャンされた古い紙マニュアル
- 多言語展開が必要な製品仕様書
- AI検索やチャットボットに取り込む前の社内文書
ただし、翻訳後は必ず「意味」と「レイアウト」の両方を確認してください。機械翻訳の品質が高くても、警告文、契約条件、単位、数値、製品名、専門用語の扱いは人によるレビューが必要です。
紙資料をスキャンしたPDFの翻訳
スキャンPDFを多く扱う企業では、OCR専用ツールで文字起こしし、その後に翻訳する運用が残っていることがあります。Azure AI Translatorのバッチ翻訳でスキャンPDFを処理できるなら、処理フローを簡素化できる可能性があります。
ただし、スキャンPDFは原稿の状態に強く依存します。傾き、低解像度、薄い文字、手書きメモ、押印、背景ノイズ、複雑な表などがあると、OCR精度やレイアウト保持に影響します。Microsoft Learnでも、スキャンPDFでは元のフォーマット、レイアウト、スタイルが失われる可能性があると説明されています。(Microsoft Learn)
Copilot・RAG・社内ナレッジ基盤への前処理
Azure AI Foundryでエージェントや社内AIアプリを構築している場合、翻訳済みPDFをナレッジベースや検索インデックスに取り込む場面があります。このとき、翻訳前後の構造が崩れていると、章立て、表、注釈、製品名の対応関係が分かりにくくなります。
PDFバッチ翻訳の改善は、こうしたAI活用の前段にある「多言語ドキュメント整備」に効きます。特に、海外拠点向けのFAQ、サポート文書、規程、教育資料をまとめて翻訳し、検索やチャット回答に活用するチームでは、従来のOCR・翻訳・整形工程を棚卸しする価値があります。
管理者が確認すべき設定
Azure AI TranslatorのPDFバッチドキュメント翻訳を本番運用に入れる前に、管理者はリソース、認証、ストレージ、ネットワーク、権限を確認する必要があります。Document Translationの非同期バッチ処理では、Translatorリソース、Azure Blob Storageのソース/ターゲットコンテナ、SASまたはマネージドIDによるアクセス認可が前提になります。(Microsoft Learn)
| 確認項目 | 見るべきポイント | 失敗しやすい例 |
|---|---|---|
| Translatorリソース | Document Translationを利用できるプランか確認 | 無料レベルで検証しようとして動かない |
| カスタムドメインエンドポイント | Document Translationではカスタムドメインエンドポイントが必要 | 一般的なTranslatorエンドポイントと混同する |
| Blob Storage | ソースコンテナとターゲットコンテナを分ける | 出力先に同名ファイルがありジョブが失敗する |
| 認証方式 | SASかマネージドIDを選ぶ | マネージドID利用時にSAS付きURLを渡して失敗する |
| RBAC | マネージドIDには必要なストレージ権限を付与 | Storage Blob Data Contributor相当の権限不足 |
| ネットワーク | Storageのファイアウォール、信頼済みサービス、同一リージョン要件を確認 | ストレージに到達できずバッチ処理が失敗する |
| キー管理 | サブスクリプションキーをKey Vaultなどで安全に管理 | キーやSAS URLをコードやログに残す |
Document Translationは、S1 Standard Service Planおよび一部のボリュームディスカウントプランでサポートされ、無料レベルではサポートされないと説明されています。また、Document Translationではカスタムドメインエンドポイントが必要です。(Microsoft Learn)
マネージドIDを使う場合は、TranslatorリソースをGlobalではなく特定の地理的リージョンに作成する必要がある点に注意してください。Microsoft Learnでは、GlobalリージョンのTranslatorリソースではマネージドIDを使えず、その場合はSASトークンを使うと説明されています。(Microsoft Learn)
開発者が確認すべき実装ポイント
開発者がまず確認すべきなのは、今回の改善が非同期バッチ翻訳のPDF処理に関係する点です。Foundryポータルは、現在の説明では同期の単一ファイル翻訳のみをサポートしており、非同期バッチ翻訳にはREST APIまたはクライアントライブラリを使う必要があります。(Microsoft Learn)
基本的なバッチ処理の流れは次のとおりです。
| 手順 | 実施内容 | 確認ポイント |
|---|---|---|
| ソースPDFを配置 | Azure Blob StorageのソースコンテナにPDFをアップロード | ファイル名、拡張子、サイズ、暗号化有無を確認 |
| 翻訳ジョブを投入 | Translatorのバッチ翻訳APIにリクエスト | sourceUrl、targetUrl、対象言語、認証方式を確認 |
| ジョブ状態を監視 | ステータスをポーリングまたは運用監視に組み込む | 失敗時のファイル単位エラーを記録 |
| 出力を取得 | ターゲットコンテナから翻訳済み文書を取得 | レイアウト、文字化け、未翻訳箇所、用語を確認 |
| 後処理 | レビュー、承認、AI検索への取り込みなどを実行 | 自動公開せず、重要文書は確認工程を挟む |
APIリクエストのイメージは次のようになります。実際の本番環境では、SAS URLやキーをコードに直書きせず、Key VaultやマネージドIDを使って安全に扱ってください。
{
"inputs": [
{
"source": {
"sourceUrl": "https://<storage-account>.blob.core.windows.net/<source-container>"
},
"targets": [
{
"targetUrl": "https://<storage-account>.blob.core.windows.net/<target-container-ja>",
"language": "ja"
}
]
}
]
}複数の対象言語に翻訳する場合、ターゲットURLは対象言語ごとに一意である必要があります。また、prefixやsuffixで処理対象を絞る場合、これらは大文字・小文字を区別する文字列として扱われます。(Microsoft Learn)
ソース言語が分かっている場合は、リクエストでソース言語を指定した方がよいとされています。一方、文書内に複数言語が含まれる場合や言語が不明な場合は、指定せずに自動検出させる選択肢があります。(Microsoft Learn)
PDFごとに検証すべき品質ポイント
PDF翻訳は、ファイルの見た目が似ていても内部構造が大きく異なります。特に「ネイティブPDF」「スキャンPDF」「混在PDF」を同じ基準で評価すると、移行後に想定外の未翻訳やレイアウト崩れが発生します。
| PDFの種類 | 検証すべきポイント | 判断基準 |
|---|---|---|
| ネイティブPDF | 見出し、段落、表、リンク、脚注、ページ番号 | Microsoft Learnでは、デジタル形式から生成されたネイティブPDFが最適な出力を得やすいと説明されています。(Microsoft Learn) |
| スキャンPDF | OCR精度、文字の欠落、傾き、ノイズ、レイアウト保持 | 翻訳は可能でも、元のフォーマットやスタイルが失われる可能性があります。 |
| デジタル要素とスキャン要素の混在PDF | 画像内文字まで翻訳されるか、未翻訳箇所が残らないか | 公式FAQでは、混在文書の全内容翻訳についてはデジタル部分のみが翻訳されると説明されています。(Microsoft Learn) |
| パスワード保護PDF | 暗号化、コピー制限、パスワード保護の有無 | 暗号化またはパスワード保護された文書は翻訳できないと説明されています。(Microsoft Learn) |
| デザイン性の高いPDF | 文字量変化による改ページ、図表との重なり | 翻訳後は文字数が変わるため、ページ内で文字が流れたり位置がずれたりする可能性があります。 |
特に注意したいのは、混在PDFです。たとえば、契約書の本文はデジタルテキストで、押印済みの別紙だけがスキャン画像として埋め込まれているPDFでは、すべてが期待どおり翻訳されるとは限りません。社内標準としては、PDFを次の3種類に分類してからテストするのがおすすめです。
- A：WordやDTPツールから出力されたネイティブPDF
- B：紙をスキャンした完全スキャンPDF
- C：デジタルテキストとスキャン画像が混在したPDF
AとBは比較的評価しやすい一方、Cは見た目だけでは判断しづらいため、翻訳後に未翻訳箇所が残っていないかを重点的に確認してください。
制限値と処理単位を確認してから展開する
PDFバッチ翻訳を本番運用に組み込む場合、機能改善だけでなく、サイズ制限とバッチ単位も重要です。Microsoft Learnのサービス制限では、非同期バッチ翻訳について、文書サイズ、ファイル数、バッチ全体のサイズ、対象言語数、用語集サイズなどの制限が示されています。(Microsoft Learn)
| 項目 | 非同期バッチ翻訳の制限 |
|---|---|
| 1文書のサイズ | 40 MB以下 |
| 合計ファイル数 | 1,000ファイル以下 |
| 1バッチの合計コンテンツサイズ | 250 MB以下 |
| 1バッチの対象言語数 | 10言語以下 |
| 用語集ファイルサイズ | 10 MB以下 |
これらの制限は、単に「アップロードできるか」だけでなく、運用設計にも影響します。たとえば、海外10拠点向けに大量のPDFを翻訳する場合、部署別、言語別、文書種別にバッチを分ける設計が必要です。大きなPDFをそのまま投げるより、章や文書種別で分けた方が、失敗時の再実行やレビューもしやすくなります。
移行・展開時の注意点
既存のOCR前処理をすぐに廃止しない
今回の改善により、既存のOCR前処理を減らせる可能性はあります。しかし、すぐに全廃するのは危険です。これまで独自のOCR、PDF分割、不要ページ除去、文字補正、用語置換を行っていた場合、それらが翻訳品質や後工程に効いていることがあります。
まずは、代表的なPDFを選び、次の3パターンで比較してください。
| 比較パターン | 目的 |
|---|---|
| 既存フロー | 現在の品質と処理時間を基準値にする |
| Azure AI Translatorに直接投入 | 今回の改善でどこまで前処理を減らせるか確認する |
| 最小限の前処理後に投入 | 傾き補正、不要ページ削除、ファイル分割などの効果を確認する |
評価指標は、翻訳の自然さだけでは不十分です。未翻訳箇所、表の崩れ、ページ数変化、重要語の訳語、数値・単位、脚注、図表内テキスト、検索インデックス投入後の検索性まで確認してください。
用語集とレビュー工程を組み合わせる
Azure AI TranslatorのDocument Translationでは、カスタム翻訳や用語集を使った翻訳も説明されています。製品名、機能名、法務用語、医療・製造・金融などの専門用語を扱う場合、用語集なしで本番展開すると、文書間で訳語が揺れやすくなります。(Microsoft Learn)
たとえば、社内で「tenant」を「テナント」と訳すのか、「契約単位」と訳すのかが決まっていないと、マニュアル、FAQ、契約書で表現がばらつきます。PDF翻訳の自動化は、用語統一とセットで設計するのが実務的です。
ターゲットコンテナの上書きルールを決める
バッチ翻訳では、出力先に同名ファイルが存在するとジョブが失敗するケースがあります。Microsoft Learnでも、宛先に同じ名前のファイルが既にある場合はジョブが失敗すると説明されています。(Microsoft Learn)
本番環境では、次のような命名ルールを決めておくと事故を防ぎやすくなります。
source/manuals/2026-06/のように投入日や版で分けるtarget/ja/2026-06/のように言語とバージョンを分ける- 再実行時は既存出力を削除するのではなく、新しい出力先に分ける
- 承認済みファイルと検証中ファイルを別コンテナまたは別フォルダで管理する
マネージドIDとSASを混在させない
セキュリティ面では、可能であればマネージドIDを使う設計が扱いやすくなります。マネージドIDはSASトークンをHTTPリクエストに含める必要を置き換える仕組みとして説明されています。(Microsoft Learn)
ただし、マネージドIDを使う場合にSAS付きURLを渡すとリクエストが失敗します。逆に、SASを使う場合は、ソースには読み取り・一覧、ターゲットには書き込み・一覧など、必要最小限の権限と有効期限を設定し、HTTPSで安全に扱う必要があります。(Microsoft Learn)
管理者・開発者向けチェックリスト
本番展開前に、少なくとも次の項目を確認してください。
| チェック項目 | 確認内容 |
|---|---|
| リソース | Translatorリソースのプラン、リージョン、エンドポイントを確認したか |
| ストレージ | ソース/ターゲットコンテナ、命名規則、ライフサイクル管理を決めたか |
| 認証 | SASまたはマネージドIDのどちらを使うか決めたか |
| 権限 | マネージドIDに必要なRBAC権限を付与したか |
| ネットワーク | Storageファイアウォールや信頼済みサービスの設定を確認したか |
| PDF分類 | ネイティブPDF、スキャンPDF、混在PDFを分けて検証したか |
| 品質評価 | 未翻訳、誤訳、レイアウト崩れ、表、脚注、図表内文字を確認したか |
| 用語管理 | 用語集やレビュー担当者を決めたか |
| 監視 | ジョブ失敗、処理時間、対象ファイル数、再実行手順を記録できるか |
| コスト | バッチ単位、文書量、対象言語数、再処理回数を把握したか |
このチェックリストを満たす前に全社展開すると、「翻訳はできたが、レビュー不能なレイアウトになった」「一部の画像文字が未翻訳だった」「出力先の競合でジョブが失敗した」といったトラブルが起きやすくなります。
よくある疑問
Azure AI Document Intelligenceのリソースを別途作成する必要はある？
今回の公式更新では、サービスがAzure AI Document Intelligenceを使ってPDF構造を回復すると説明されていますが、利用者が別途Document Intelligenceリソースを作成する必要があるとは読み取れません。Document Translationの前提として明示されているのは、Translatorリソース、Blob Storage、SASまたはマネージドIDなどです。(Microsoft Azure)
ただし、既存環境で独自にDocument Intelligenceを使ったOCRやレイアウト抽出を組み込んでいる場合は、今回の改善後もその前処理が必要かどうかを再評価してください。不要な前処理を残すと、コストや処理時間が増えるだけでなく、翻訳対象の構造をかえって崩す場合があります。
既存のバッチ翻訳実装は移行が必要？
必ず全面移行が必要とは限りません。今回の更新はPDF翻訳改善としてGA化されたものですが、既存のAPI呼び出し、認証、ストレージ構成がそのまま使えるかは環境によって異なります。特に、古いAPIバージョン、独自OCR、ファイル分割、出力先命名規則、SASの有効期限設計を使っている場合は、テスト環境で再確認してください。
Microsoft Learnでは、Document Translation API version 2026-03-01 のGAリリースとして、PDF翻訳改善や統合された翻訳モードが説明されています。新機能を使う前提で設計する場合は、参照しているAPIバージョンとSDKの対応状況も確認しましょう。(Microsoft Learn)
スキャンPDFなら何でもきれいに翻訳できる？
いいえ。スキャンPDFは、元画像の品質に強く依存します。公式FAQでも、スキャンPDFの翻訳では元のフォーマット、レイアウト、スタイルが失われる可能性があると説明されています。(Microsoft Learn)
実務では、低品質なスキャンPDFをそのまま投入するより、傾き補正、解像度確認、不要な余白や表紙の除去、ページ分割などを行った方が安定する場合があります。特に法務文書や監査資料では、翻訳結果だけでなく原文との対応関係を確認できるレビュー体制が必要です。
翻訳後のPDFをそのまま公開してよい？
社内の参考資料なら自動翻訳のまま使える場面もありますが、顧客向け資料、契約書、規程、医療・安全・法務に関わる文書では人によるレビューを前提にすべきです。機械翻訳は、専門用語、文脈、否定表現、条件文、単位、数値、責任範囲の解釈を誤る可能性があります。
公開前には、最低でも次の観点で確認してください。
- 重要語の訳語が社内用語集と一致しているか
- 数値、単位、日付、製品名が変わっていないか
- 否定文や条件文の意味が逆転していないか
- 図表、脚注、注記が読める位置に残っているか
- 未翻訳のページや画像内テキストがないか
まず取るべき次のアクション
今回のAzure AI Translator PDFバッチドキュメント翻訳の改善は、PDF翻訳の自動化を進める良いタイミングです。ただし、最初から全社展開するのではなく、代表的なPDFを使って小さく検証するのが安全です。
最初の一歩として、次の順序で進めると失敗しにくくなります。
| 順序 | 実施内容 |
|---|---|
| 1 | 既存のPDF翻訳フローを棚卸しし、OCR、変換、手修正にかかっている工数を把握する |
| 2 | ネイティブPDF、スキャンPDF、混在PDFをそれぞれ5〜10件ずつ選ぶ |
| 3 | Azure AI Translatorのバッチ翻訳でテストし、既存フローと比較する |
| 4 | 認証方式、ストレージ構成、出力先命名、レビュー工程を決める |
| 5 | 重要度の低い文書から段階的に展開し、ログと品質評価を蓄積する |
PDF翻訳の改善は、単なる翻訳機能の強化ではなく、多言語ドキュメント運用、社内ナレッジ整備、AI/Copilot向けコンテンツ準備の土台に関わる更新です。管理者はセキュリティとストレージ設計を、開発者はバッチ処理と品質検証を見直し、まずは実データで「どこまで前処理を減らせるか」を確認しましょう。
コメント