Azure AI FoundryでOffice文書を多言語化している組織にとって、今回のポイントは明確です。Azure AI Translatorのバッチ ドキュメント翻訳で、Word .docx などのOffice文書内に埋め込まれた画像中の文字も、OCRで認識して翻訳し、文書内へ戻せるようになりました。これまでスクリーンショット、図表、操作マニュアル内の画像テキストだけが原文のまま残りやすかったワークフローでは、翻訳後の手戻りを大きく減らせます。Azure Updatesではこの機能が「Launched / Generally Available」として扱われており、Azureの「Launched」は本番利用可能な状態を指します。(マイクロソフト Azure)
ただし、既存の翻訳ジョブが何もしなくても自動で画像内テキストまで翻訳される、と考えるのは危険です。公式ドキュメントでは、Office文書内画像の翻訳はバッチ翻訳向けの機能として説明されており、リクエストごとに画像内テキスト翻訳を有効化する設定が必要です。管理者と開発者は、対象ファイル、APIバージョン、Blob Storage権限、料金、翻訳品質の確認手順をセットで見直す必要があります。(Microsoft Learn)
Azure AI FoundryのAI/Copilot更新で何が変わるのか
今回の更新は、Azure AI Foundry、正確にはAzure Translator in Foundry ToolsのDocument Translationに関する機能強化です。Document Translationは、文書構造や書式を保ったまま複数ファイルを翻訳できるクラウドベースの機械翻訳機能で、非同期バッチ翻訳と同期単一ファイル翻訳の2種類の処理方式があります。(Microsoft Learn)
特に影響が大きいのは、Word文書やPowerPoint資料にスクリーンショット、図解、製品ラベル、UI画像、フローチャートを多く含めているケースです。従来は本文テキストだけ翻訳され、画像中の「Submit」「Error」「管理画面」「承認済み」などの文字が原文のまま残ることがありました。今回のGAにより、画像領域の検出、OCR、翻訳、再描画までをバッチ翻訳フローに組み込めます。Microsoft Foundry Blogでも、Word文書やPowerPointデッキ内のチャート、図、スクリーンショット、埋め込み画像に含まれる文字を、文書本文とあわせて翻訳できると説明されています。(Microsoft for Developers)
| 観点 | これまで起きやすかったこと | 今回の更新後に期待できること |
|---|---|---|
| 操作マニュアル | 画面キャプチャ内のボタン名やエラー文が原文のまま残る | 画像内の文字も翻訳対象にできる |
| 営業資料・提案書 | 図解やチャート中のラベルだけ手作業で修正する | 翻訳後のDTP・差し替え作業を減らせる |
| 社内ナレッジ | Copilotや検索向けに多言語化しても画像情報が抜ける | 画像中のテキスト情報も翻訳済み文書に反映しやすい |
| 品質確認 | 画像部分を人が目視で探して修正する | OCR失敗数などを確認し、レビュー対象を絞り込める |
対象になるファイルと処理方式
公式アップデートの主題は、バッチ ドキュメント翻訳でOffice文書内画像のテキストを翻訳できるようになった点です。Document Translation 2026-03-01の概要では、Office文書内画像翻訳は「batch only」とされ、Word .docx とPowerPoint .pptx 内の画像テキストを対象にできると説明されています。(Microsoft Learn)
ここで重要なのは、単体の画像ファイル翻訳と、Office文書内に埋め込まれた画像の翻訳を分けて考えることです。.jpeg、.png、.bmp、.webp のような画像ファイルを直接翻訳する機能もDocument Translation 2026-03-01で説明されていますが、Office文書内画像翻訳は「文書の中にある画像」を対象にする別の確認ポイントがあります。(Microsoft Learn)
| 方式 | 主な用途 | Blob Storage | 今回のOffice文書内画像翻訳との関係 |
|---|---|---|---|
| 非同期バッチ翻訳 | 大量文書、大きなファイル、定期処理 | 必要 | 対象。Office文書内画像翻訳はバッチ向け |
| 同期単一ファイル翻訳 | 1ファイルを即時に翻訳して返す | 不要 | Office文書内画像翻訳の主対象ではない |
| 単体画像ファイル翻訳 | 画像ファイルそのものを翻訳 | 方式により異なる | Office文書内画像翻訳とは別に検討 |
バッチ翻訳では、入力ファイル用と出力ファイル用のAzure Blob Storageコンテナーを用意し、SASトークンまたはマネージドIDでアクセス権を構成します。大量ファイルや大きなファイルを扱う場合は、リクエスト後にジョブIDをポーリングして完了を確認し、翻訳済み文書をターゲットコンテナーから取得する流れになります。(Microsoft Learn)
管理者が確認すべき設定
最初に確認すべきなのは、利用しているTranslatorまたはMicrosoft Foundryリソース、価格プラン、エンドポイント、ストレージ権限です。Microsoft Learnでは、Document Translationは無料レベルではなく、S1 Standard Service Planや一部のVolume Discount Planでサポートされると説明されています。既存環境が検証用の低コスト構成になっている場合、本番展開前にプランと課金条件を確認してください。(Microsoft Learn)
次に、バッチ翻訳用のBlob Storage設計を見直します。入力コンテナーには読み取りと一覧、出力コンテナーには書き込みと一覧の権限が必要です。SASを使う場合は有効期限を短くし、対象コンテナーや対象Blobを絞るのが基本です。本番運用では、キーやSAS URLをソースコードやログに残さず、可能であればマネージドIDを使う方が管理しやすくなります。Microsoft Learnでも、SASトークンの代替としてシステム割り当てマネージドIDを利用できると案内されています。(Microsoft Learn)
| 確認項目 | 管理者が見るポイント | 放置した場合のリスク |
|---|---|---|
| リソースと価格プラン | Document Translation対応プランか | ジョブが実行できない、想定外の課金 |
| APIバージョン | 2026-03-01 を使う実装か | 新機能が呼び出せない |
| ストレージ権限 | sourceは読み取り・一覧、targetは書き込み・一覧 | 読み込み失敗、出力失敗 |
| 出力先設計 | 既存ファイルと衝突しないか | 同名ファイルがあるとジョブ失敗の原因になる |
| 監査とセキュリティ | 画像内に個人情報・機密情報が含まれないか | スクリーンショット経由の情報漏えいリスク |
特に見落としやすいのが出力先のファイル衝突です。Microsoft Learnでは、宛先に同じ名前のファイルが既にある場合、ジョブが失敗すると説明されています。毎回同じターゲットコンテナーへ出力する運用では、日付別フォルダー、ジョブID別フォルダー、言語別コンテナーなどに分ける設計にしておくと安全です。(Microsoft Learn)
開発者が確認すべきAPIとオプション
Office文書内画像の翻訳は、バッチ翻訳リクエストで画像内テキスト翻訳のオプションを有効にして使います。Microsoft Foundry Blogのサンプルでは、options 内で translateTextWithinImage を true に設定する例が示されています。(Microsoft for Developers)
{
"inputs": [
{
"source": {
"sourceUrl": "OFFICE_SOURCE_CONTAINER_SAS_URL_OR_MANAGED_IDENTITY",
"storageSource": "AzureBlob",
"language": "en"
},
"targets": [
{
"targetUrl": "OFFICE_TARGET_CONTAINER_SAS_URL_OR_MANAGED_IDENTITY",
"storageSource": "AzureBlob",
"language": "ja"
}
]
}
],
"options": {
"translateTextWithinImage": true
}
}一方で、Document Translation 2026-03-01のクイックスタートやREST API説明では、translateWithinImage という名称で説明されている箇所もあります。実装時は、利用しているAPIバージョン、SDK、RESTリファレンス、実際のテナントで受け付けられるパラメーター名をステージング環境で確認してください。ここを曖昧にしたまま本番展開すると、ジョブ自体は成功しても画像内テキストだけ翻訳されない、という分かりにくい不具合につながります。(Microsoft Learn)
また、バッチ翻訳は即座に翻訳済みファイルを返すのではなく、成功時に 202 Accepted が返り、operation-location ヘッダーのURLを使ってジョブ状態を確認します。既存の同期翻訳処理に組み込むのではなく、非同期ジョブ管理、リトライ、タイムアウト、通知、失敗ファイルの再処理まで含めて設計する必要があります。(Microsoft Learn)
既存ワークフローへの影響範囲
今回のGAで最も恩恵を受けるのは、翻訳後に人手で画像を修正していたローカライズ工程です。たとえば、次のような文書では作業時間の削減が期待できます。
- 製品マニュアル内の画面キャプチャ
- クラウド管理画面の操作手順書
- 研修資料やオンボーディング資料
- 営業提案書の図解・チャート
- 海外拠点向けの社内規程や手順書
- Copilotや検索基盤に投入する多言語ナレッジ文書
ただし、画像内テキストの翻訳は「完全なDTP自動化」ではありません。OCRは画像品質に影響を受けます。小さすぎる文字、低解像度のスクリーンショット、斜めに配置された文字、装飾フォント、複雑な背景の上にある文字は、認識精度が落ちる可能性があります。Azure AI Document Translationでは画像処理の成功数と失敗数として totalImageScansSucceeded と totalImageScansFailed がレスポンスに含まれるため、運用ではこの値を監視し、失敗があるジョブをレビュー対象にしてください。(Microsoft Learn)
移行・展開時のおすすめ手順
いきなり全社の翻訳パイプラインに組み込むのではなく、代表的な文書で検証してから段階展開するのが安全です。特に、画像を多く含む文書ほど、翻訳品質、レイアウト崩れ、処理時間、料金への影響が出やすくなります。Microsoft Foundry Blogでも、Office文書内画像翻訳では画像翻訳に追加料金が発生すると説明されています。(Microsoft for Developers)
| フェーズ | やること | 合格基準の例 |
|---|---|---|
| 棚卸し | 画像を多く含む .docx / .pptx を抽出 | 重要文書、定期翻訳文書、外部公開文書を優先 |
| 小規模検証 | 5〜10件程度でバッチ翻訳を実行 | 画像内テキストが翻訳され、本文レイアウトが大きく崩れない |
| 品質確認 | 原文画像、翻訳後画像、OCR失敗数を確認 | 重要語句、UI名、数値、単位に致命的な誤訳がない |
| コスト確認 | 画像数が多い文書の処理量を測定 | 予算内で定期実行できる |
| 本番展開 | 対象フォルダー、言語、出力先を固定 | 失敗時の再実行手順と通知先が決まっている |
移行時に注意したいのは、すでに別のOCR前処理を組んでいる環境です。たとえば、Word文書から画像を抽出し、Azure AI VisionやDocument IntelligenceでOCRし、Translatorへ渡して、最後に人手で画像を差し替えている場合、今回の機能で工程を簡略化できる可能性があります。一方で、既存のOCR結果を検索インデックスや監査ログに保存している場合は、その副産物が不要になるとは限りません。翻訳文書の生成と、検索・監査・分析のためのテキスト抽出は目的が違うため、置き換え範囲を分けて判断してください。
失敗しやすいポイント
最も多い失敗は、画像内テキスト翻訳のオプションを有効にし忘れることです。通常のバッチ翻訳としては成功しても、画像部分が原文のまま残るため、利用者から見ると「翻訳漏れ」に見えます。リクエスト生成処理にテストを追加し、対象拡張子が .docx または .pptx のときにオプションが期待通り入っているか確認しましょう。
次に、翻訳後のレイアウト確認を省略する失敗です。画像内の英語を日本語に翻訳すると、文字数が増えて画像内に収まりにくくなることがあります。ボタン名や短いラベルなら問題が少なくても、説明文が入った図解では文字の折り返しや重なりが発生する可能性があります。外部公開資料や顧客向けマニュアルでは、翻訳後ファイルをそのまま公開せず、最低限の目視確認工程を残すべきです。
また、スクリーンショットに個人情報、アクセストークン、メールアドレス、顧客名、社内URLが含まれているケースにも注意が必要です。画像内テキストが翻訳対象になるということは、これまで見落としていた画像内の情報も処理対象になるという意味です。翻訳前の文書チェックでは、本文だけでなく画像内の機密情報も確認しましょう。
Foundryポータルだけで使えるのか
非同期バッチ翻訳を使う場合、Foundryポータルの画面操作だけで完結すると考えない方が安全です。Microsoft Learnでは、Foundryポータルは現在、同期の単一ファイル翻訳のみをサポートしており、非同期バッチ翻訳にはREST APIまたはクライアントライブラリを使うと説明されています。(Microsoft Learn)
そのため、管理者は「誰がポータルから実行するか」だけでなく、「どのアプリケーションやジョブがAPIを呼び出すか」「認証情報をどこで管理するか」「出力ファイルを誰が確認するか」まで決める必要があります。Logic Apps、Azure Functions、GitHub Actions、社内CMSなどから実行している場合は、APIバージョンとリクエストボディの更新が必要になる可能性があります。
実務での判断基準
今回の機能をすぐ有効化すべきかどうかは、文書の種類で判断すると分かりやすくなります。
| 文書タイプ | 有効化の優先度 | 判断理由 |
|---|---|---|
| 操作マニュアル、手順書 | 高 | スクリーンショット内のUI文字が重要 |
| 製品カタログ、仕様書 | 高 | 図表やラベルの翻訳漏れが品質に直結 |
| 社内向け議事録、簡易メモ | 低〜中 | 画像が少なければ効果は限定的 |
| 法務・契約関連文書 | 中 | 便利だが、翻訳後の人手レビューは必須 |
| 外部公開マーケ資料 | 高 | 効率化できるが、レイアウト確認が重要 |
| 機密スクリーンショットを含む資料 | 慎重 | 処理対象データと権限設計の確認が先 |
特に、海外展開しているSaaS企業、製造業の技術文書チーム、グローバルサポート部門、社内Copilot向けナレッジ整備チームでは、検証する価値が高い更新です。画像内のテキストは、検索や翻訳の抜け漏れになりやすい一方で、読者にとっては重要情報であることが多いためです。
まず何をすべきか
最初に、現在の翻訳対象文書から「画像内に重要な文字がある文書」を10件ほど選び、ステージング環境でバッチ翻訳を試してください。その際、通常翻訳と画像内テキスト翻訳を有効にした翻訳を比較し、画像内の翻訳品質、レイアウト、処理時間、失敗数、料金見込みを確認します。
次に、APIリクエストのオプション名、APIバージョン、Blob Storageの権限、出力先ルールを運用手順に落とし込みます。最後に、翻訳後のレビュー基準を決めます。特に外部公開文書では「画像内テキストが翻訳されているか」だけでなく、「日本語として自然か」「図中に収まっているか」「製品名やUI名が意図通りか」まで確認してください。
Azure AI Foundryの今回の更新は、単なる翻訳精度の改善ではなく、文書ローカライズ工程そのものを短くする変更です。本文だけでなく画像内の情報まで翻訳対象にできるようになったことで、マニュアル、提案書、研修資料、Copilot向けナレッジの多言語展開が進めやすくなります。まずは画像の多いWord文書やPowerPoint資料から小さく検証し、品質とコストを確認したうえで本番ワークフローに組み込むのが現実的です。
コメント