Azure AI FoundryでAzure AI Translatorのバッチ ドキュメント翻訳を使っている場合、今回のポイントはシンプルです。画像ファイルをPDF化せず、そのまま翻訳対象として投入できる範囲が広がりました。 2026年6月3日に公開・更新されたAzure Updatesでは、Azure AI Translatorのbatch document translationが画像ファイル入力をGenerally Availableとして受け付けるようになったことが案内されています。対象形式は.jpeg、.png、.bmp、.webpです。(マイクロソフト Azure)
これは「新しいCopilot画面が追加された」というより、既存の翻訳ワークフローに効く実務向けの更新です。スキャン画像、画面キャプチャ、製品ラベル、マニュアル内の画像素材などを大量に翻訳しているチームでは、前処理・OCR連携・PDF変換の手間を減らせる可能性があります。一方で、OCR精度、画像サイズ、課金、Blob Storage権限、失敗時の再実行設計は事前に確認しておく必要があります。
Azure AI FoundryのAI更新で何が変わるのか
今回の更新では、Azure AI Translatorのバッチ ドキュメント翻訳で、画像ファイルそのものを入力として扱えるようになりました。Azure TranslatorはFoundry Toolsに含まれる翻訳サービスで、テキストやドキュメントをリアルタイムまたはバッチで翻訳できるサービスとして提供されています。(マイクロソフト Azure)
従来、画像内の文字を翻訳したい場合は、次のような前処理を組むケースがありました。
| 従来の対応 | 課題 |
|---|---|
| 画像をPDFに変換してから翻訳する | ファイル変換処理が増え、画質やレイアウト崩れの確認が必要 |
| OCRで文字を抽出し、Text Translationに渡す | 翻訳後の文字を画像に戻す処理を別途作る必要がある |
| 人手で画像を編集する | 数が多いとコストと納期が膨らむ |
| 翻訳対象から画像を除外する | マニュアル、UI資料、ラベルの翻訳漏れが起きやすい |
今回のGAにより、対応形式の画像であれば、バッチ ドキュメント翻訳の入力として扱えるようになります。公式ドキュメントでも、画像内のテキストを元のデザインやレイアウトを維持しながら翻訳する機能として、.jpeg、.png、.bmp、.webpが示されています。(Microsoft Learn)
実務上の変化は、次の3つです。
| 観点 | 変更前に起きやすかったこと | 今回の更新後に期待できること |
|---|---|---|
| 前処理 | 画像をPDF化、またはOCR処理を別サービスで実装 | 対応画像をバッチ翻訳の入力として扱いやすくなる |
| 運用 | 画像だけ別フローになり、監視や再実行が複雑化 | 既存のバッチ翻訳ジョブ管理に寄せやすい |
| 品質確認 | OCR結果、翻訳結果、画像再配置を個別に確認 | 画像単位で翻訳結果を確認する流れに整理しやすい |
ただし、画像ファイル翻訳は「画像を入れれば常に完全な翻訳画像になる」機能ではありません。OCRで認識できない文字、低解像度、傾き、手書き文字、装飾フォント、複雑な背景、縦書きや多言語混在などは、翻訳品質に影響します。本番展開前に、自社で実際に扱う画像を使って検証することが重要です。
対象となるファイル形式と向いている用途
今回の更新で重要なのは、サポート形式が明確に示された点です。公式情報では、画像ファイル形式として.jpeg、.png、.bmp、.webpが挙げられています。(Microsoft Learn)
| 形式 | 向いている用途 | 確認したいポイント |
|---|---|---|
.jpeg | スキャン画像、写真ベースのラベル、紙資料の撮影画像 | 圧縮ノイズで文字がつぶれていないか |
.png | UIスクリーンショット、図解、Web画面キャプチャ | 小さい文字や薄い文字が認識されるか |
.bmp | レガシーシステムから出力された画像 | ファイルサイズが大きくなりすぎないか |
.webp | Web向け画像、軽量化された画像素材 | 圧縮率によってOCR精度が落ちていないか |
特に.pngは、製品マニュアルや社内手順書で使われるスクリーンショット翻訳に向いています。UI上のボタン名、エラーメッセージ、メニュー名が画像化されている場合、従来は翻訳漏れになりやすい部分でした。
一方、.bmpは非圧縮に近い形式でサイズが大きくなりやすいため、大量処理ではストレージ容量やバッチ制限の確認が欠かせません。Translatorのサービス制限ページでは、非同期バッチ操作に関するドキュメントサイズやバッチ内ファイル数などの制限が示されており、画像ファイルサイズについても上限が記載されています。なお、該当表にプレビュー表記が残る場合があるため、GA後の最新制限は本番前に必ず確認してください。(Microsoft Learn)
影響を受ける利用者とシステム
今回の更新で直接影響を受けるのは、Azure AI Translatorのドキュメント翻訳を次のように使っているチームです。
| 対象 | 影響 |
|---|---|
| 多言語マニュアルを作成している開発・ローカライズチーム | 画像化された説明図やUIスクリーンショットの翻訳フローを見直せる |
| 製品ラベル、注意書き、掲示物を翻訳している業務部門 | 画像ファイルをそのまま処理できる可能性がある |
| バッチ翻訳基盤を運用するIT管理者 | Blob Storage権限、課金、監視、再実行設計の確認が必要 |
| アプリに翻訳機能を組み込む開発者 | 画像ファイルを許可する入力バリデーションやエラー処理の追加が必要 |
| OCRと翻訳を別々に実装しているチーム | 既存構成を簡素化できるか比較検討できる |
反対に、通常のテキスト翻訳APIだけを使っているシステムには、基本的に直接の変更はありません。また、WordやPowerPoint内に埋め込まれた画像テキストの翻訳は別の設定項目として扱われます。Microsoft Learnでは、.docxや.pptx内の画像テキスト翻訳にはtranslateTextWithinImageオプションを使う説明があります。画像ファイルそのものを翻訳する今回の話と混同しないようにしてください。(Microsoft Learn)
管理者が確認すべき設定
画像ファイル翻訳を本番で使う前に、管理者は「使えるか」だけでなく「安全に継続運用できるか」を確認する必要があります。
Translatorリソースと価格レベル
ドキュメント翻訳は、Freeレベルではなく、対応する有料プランで利用する前提です。Microsoft Learnでは、ドキュメント翻訳がS1 Standardサービスプランや一部のボリューム割引プランでサポートされること、Freeレベルではドキュメント翻訳がサポートされないことが説明されています。(Microsoft Learn)
確認すべき項目は次の通りです。
| 確認項目 | 見るべきポイント |
|---|---|
| Translatorリソース | ドキュメント翻訳に使うリソースが存在するか |
| 価格レベル | ドキュメント翻訳を利用できるプランか |
| エンドポイント | カスタムドメインエンドポイントを利用しているか |
| キー管理 | キーをコードやログに残していないか |
| 利用リージョン | マネージドID利用時のリージョン要件を満たすか |
特に既存の検証環境を本番転用する場合、Freeレベルや古いサンプル構成のままになっていることがあります。画像ファイル翻訳を有効活用する前に、リソース構成を棚卸ししてください。
Blob Storageの入力・出力コンテナー
バッチ ドキュメント翻訳では、ソースコンテナーに翻訳対象ファイルを置き、ターゲットコンテナーに翻訳後ファイルを出力する構成が基本です。公式ドキュメントでは、非同期バッチ翻訳の前提として、Translatorリソース、ソースコンテナー、ターゲットコンテナーを含むAzure Blob Storageアカウント、SASトークンまたはマネージドIDによるアクセス許可が示されています。(Microsoft Learn)
SASトークンを使う場合は、少なくとも次を確認します。
| コンテナー | 必要な権限の考え方 |
|---|---|
| ソースコンテナー | 読み取り、一覧表示 |
| ターゲットコンテナー | 書き込み、一覧表示 |
| 用語集を使う場合 | 用語集BLOBへの読み取り、一覧表示 |
Microsoft Learnでは、ソースには読み取りと一覧表示、ターゲットには書き込みと一覧表示のアクセス権が必要であることが説明されています。また、同じ名前のファイルが宛先に既に存在する場合、ジョブが失敗する点にも注意が必要です。(Microsoft Learn)
本番運用では、ターゲット側のファイル名を固定にせず、ジョブID、日付、言語コードなどを含めて衝突しにくい設計にすると安全です。
SASではなくマネージドIDを使う場合
セキュリティを重視する環境では、SAS URLをアプリケーションに埋め込むより、マネージドIDとAzure RBACを使う構成を検討すべきです。公式ドキュメントでは、マネージドIDがSASトークンをURLに含める要件を置き換える、より安全な方法として説明されています。(Microsoft Learn)
ただし、マネージドIDには注意点があります。
| 項目 | 注意点 |
|---|---|
| Translatorリソース | グローバルではなく、特定の地理的リージョンに作成する必要がある |
| IDの種類 | ドキュメント翻訳ではシステム割り当てマネージドIDを前提に確認する |
| RBAC | Storage Blob Data Contributorなど、必要なロールを正しく割り当てる |
| 反映時間 | ロール割り当ての反映に時間がかかる場合がある |
| ネットワーク | Storage firewallや信頼されたサービス設定を確認する |
「SASを消したのにジョブが失敗する」という場合、Translatorリソースのリージョン、マネージドIDの有効化、ストレージへのRBAC、ネットワーク制限のいずれかが原因になりやすいです。
開発者が見直すべき実装ポイント
入力バリデーションに画像形式を追加する
既存のバッチ翻訳システムでは、アップロード時に.docx、.pptx、.pdfなどだけを許可していることがあります。今回の更新を使うなら、対応形式に.jpeg、.png、.bmp、.webpを追加する必要があります。
ただし、拡張子だけで判断するのは危険です。実装では次の観点も確認してください。
| チェック項目 | 理由 |
|---|---|
| 拡張子 | サポート対象外ファイルの混入を防ぐ |
| MIMEタイプ | 拡張子偽装を検出しやすくする |
| ファイルサイズ | バッチ制限や処理失敗を避ける |
| 画像解像度 | OCR精度に直結する |
| 対象言語 | OCR・翻訳品質の事前評価に必要 |
| ファイル名 | 出力先の重複や文字化けを避ける |
特にユーザーがアップロードする画像をそのまま処理するアプリでは、サイズ制限とファイル種別チェックをサーバー側で必ず行いましょう。
画像翻訳とOCR抽出を使い分ける
画像ファイル翻訳は便利ですが、すべてのOCR用途を置き換えるものではありません。判断基準は「翻訳後の画像が欲しいのか」「抽出された文字データが欲しいのか」です。
| やりたいこと | 向いている方式 |
|---|---|
| 画像内の文字を翻訳し、見た目もなるべく維持したい | Azure AI Translatorの画像ファイル翻訳 |
| 画像から文字や表、項目を抽出してDBに保存したい | Azure AI Document IntelligenceなどのOCR/抽出系サービス |
| 抽出テキストを検索、分類、RAGに使いたい | OCR抽出後に翻訳・インデックス化 |
| デザイン品質を厳密に整えたい | 自動翻訳後に人手でDTP・画像編集 |
たとえば、海外拠点向けの手順書に含まれる画面キャプチャを翻訳したいなら、画像ファイル翻訳が有力です。一方、請求書画像から項目を抽出し、金額や日付を業務システムに取り込みたいなら、翻訳よりも構造化抽出を優先すべきです。
Office文書内の画像翻訳と混同しない
開発者がつまずきやすいのが、.docxや.pptx内の画像翻訳と、画像ファイルそのものの翻訳を同じものとして扱ってしまうケースです。
Office文書内の画像を翻訳する場合、translateTextWithinImageオプションをtrueに設定する説明があります。これはWordやPowerPointファイルの中に埋め込まれた画像テキストを翻訳するための設定です。画像ファイルそのものをソースとして扱う場合は、対応形式の画像をBlob Storageに置き、バッチ翻訳の入力として処理する流れを確認してください。(Microsoft Learn)
失敗時に再実行できる設計にする
バッチ翻訳は非同期処理です。成功・失敗をアプリ側で追跡し、失敗したファイルだけを再実行できる設計にしておくと運用が安定します。公式ドキュメントでも、非同期バッチの流れとして、ソースドキュメントのアップロード、バッチ要求の送信、ジョブとドキュメント状態の監視、ターゲットコンテナーからのダウンロードが示されています。(Microsoft Learn)
実装では、少なくとも次の情報を保存しておきます。
| 保存する情報 | 用途 |
|---|---|
| ジョブID | ステータス確認、問い合わせ対応 |
| ソースファイルパス | 再実行対象の特定 |
| ターゲット言語 | 多言語出力の確認 |
| ターゲット出力先 | 出力ファイルの取得 |
| 開始時刻・終了時刻 | SLAや処理時間の分析 |
| 成功・失敗件数 | 運用レポート |
| エラー内容 | 自動リトライや手動対応 |
ターゲットコンテナーに同名ファイルがあると失敗する可能性があるため、再実行時には出力先を変えるか、既存ファイルの扱いを運用ルールとして決めておきましょう。
課金で注意すべきポイント
画像ファイル翻訳では、通常のテキスト翻訳とは課金の見方が異なります。Azure Translatorの価格ページでは、Document TranslationのImageが画像単位で課金されること、1画像あたり500文字までを含み、それを超える場合は500文字単位で課金されることが説明されています。(マイクロソフト Azure)
つまり、画像の枚数だけでなく、画像内の文字量もコストに影響します。
| 画像の種類 | コスト面の注意 |
|---|---|
| ボタン名だけのUI画像 | 文字数が少なく、比較的見積もりやすい |
| 注意書きが密集したラベル画像 | 500文字を超える可能性がある |
| マニュアル1ページを丸ごと画像化したもの | 文字数が多く、複数画像相当で課金される可能性がある |
| 高解像度スキャン画像 | ファイルサイズと文字量の両方を確認する |
導入前には、実際の画像100枚程度をサンプルにして、平均文字量、失敗率、処理時間、出力品質を確認するのがおすすめです。特にラベル、規約、注意喚起文のように文字が密集する画像では、想定より課金対象単位が増えることがあります。
本番展開前の検証手順
画像ファイル翻訳をすぐ全社展開するのではなく、小さな検証から始めるのが安全です。
| 手順 | 確認内容 |
|---|---|
| 対象画像を棚卸しする | 形式、サイズ、文字量、言語、用途を分類する |
| サンプル画像を選ぶ | きれいな画像だけでなく、低品質・斜め・小さい文字も含める |
| 開発用Blob Storageに配置する | 本番データと分離し、アクセス権を限定する |
| バッチ翻訳を実行する | 成功率、処理時間、出力形式を確認する |
| 翻訳品質をレビューする | OCR漏れ、誤訳、文字のはみ出し、レイアウト崩れを見る |
| 課金を見積もる | 画像数だけでなく、500文字単位の扱いを確認する |
| 監視と再実行を確認する | 失敗ファイルだけを再処理できるか確認する |
| セキュリティレビューを行う | SAS、マネージドID、RBAC、ログ出力を確認する |
検証では、成功した画像だけで判断しないことが大切です。実際の運用では、解像度が低い画像、古いスキャン、余白が少ないラベル、多言語が混在した画面などが混ざります。失敗しやすい画像を先に把握しておくと、運用開始後の問い合わせを減らせます。
よくある失敗と対策
| 失敗例 | 主な原因 | 対策 |
|---|---|---|
| 画像が処理対象にならない | 拡張子フィルター、未対応形式、アップロード先の誤り | 対応形式とBlobパスを確認する |
| ジョブは開始するが出力されない | ターゲット権限不足、SAS期限切れ、同名ファイルの存在 | 権限、期限、出力ファイル名を確認する |
| OCR結果が悪い | 低解像度、手ぶれ、装飾フォント、背景ノイズ | スキャン品質基準を設ける |
| 翻訳後の文字がはみ出す | 翻訳文が長くなる、画像内の余白が少ない | 重要画像は人手レビューを入れる |
| コストが想定より高い | 文字量の多い画像が多い | サンプルで平均課金単位を見積もる |
| セキュリティレビューで止まる | SAS URLをコードやログに残している | Key VaultやマネージドID利用を検討する |
特にSAS URLの取り扱いは要注意です。Microsoft Learnでも、サンプルで使ったSAS URLはコードから削除し、公開しないよう注意されています。本番では、資格情報を安全に保存してアクセスできる方法を使うべきです。(Microsoft Learn)
既存システムを移行する判断基準
すでにOCRと翻訳を組み合わせた独自パイプラインを持っている場合、すぐ置き換えるべきとは限りません。次の基準で判断すると失敗しにくくなります。
| 判断項目 | 画像ファイル翻訳に寄せやすいケース | 既存構成を残すべきケース |
|---|---|---|
| 成果物 | 翻訳済み画像がほしい | 抽出テキストや構造化データがほしい |
| 画像の種類 | UIキャプチャ、ラベル、簡単な図解 | 帳票、表、複雑なレイアウト |
| 品質要件 | 概要理解や社内利用が中心 | 法務、医療、安全表示など厳密な確認が必要 |
| 運用規模 | 大量の画像をまとめて処理したい | 少量で人手編集が前提 |
| 既存投資 | OCR後の再配置処理が重い | 既存OCR精度や後処理が十分に最適化済み |
おすすめは、既存パイプラインをすぐ廃止するのではなく、まず「画像をPDF化している部分」や「翻訳漏れになっているスクリーンショット部分」から置き換え候補にすることです。効果が出やすく、影響範囲も限定できます。
管理者・開発者向けチェックリスト
本番反映前に、次の項目を確認してください。
| 区分 | チェック項目 |
|---|---|
| サービス | Azure Translatorの対象プランでドキュメント翻訳が使える |
| 入力 | .jpeg、.png、.bmp、.webpの受け入れルールを定義した |
| ストレージ | ソース・ターゲットコンテナーを分離した |
| 権限 | SASまたはマネージドIDのどちらを使うか決めた |
| セキュリティ | SAS URLやキーをログ、Git、設定ファイルに残さない |
| 監視 | ジョブID、成功数、失敗数、エラー内容を記録する |
| 再実行 | 失敗ファイルだけを再処理できる |
| 課金 | 画像数と文字量をもとに見積もった |
| 品質 | OCR漏れ、誤訳、レイアウト崩れのレビュー基準を作った |
| 利用者対応 | 自動翻訳の限界と人手確認が必要な画像を明示した |
まず何から始めるべきか
今回のAzure AI Foundry関連更新は、画像内テキストの翻訳を多く扱うチームにとって、前処理を減らせる実用的な変更です。特に、マニュアル、画面キャプチャ、ラベル、掲示物、ナレッジ資料の多言語化では、既存のバッチ翻訳基盤に画像を組み込みやすくなります。
最初にやるべきことは、全社展開ではありません。まず、現在翻訳対象になっている画像を棚卸しし、代表的な.jpeg、.png、.bmp、.webpを少量選んで検証します。そのうえで、OCR精度、翻訳品質、課金、Blob Storage権限、ジョブ監視、再実行手順を確認してください。
品質と運用コストの見通しが立ったら、PDF変換や独自OCR処理に頼っている部分から段階的に置き換えるのが現実的です。画像ファイル翻訳は、翻訳業務を完全自動化する魔法ではありませんが、画像を含む多言語ドキュメント運用を整理する強力な選択肢になります。
コメント