Azure AI Foundryの画像ファイル翻訳がGAに:同期APIの変更点と確認事項

Azure AI Foundryで画像ファイル翻訳を使う場合、今回のポイントは「単体の画像を同期APIで送信し、翻訳後の画像をその場で受け取れるようになった」ことです。従来のように、少数の画像翻訳のためだけにBlob Storageを前提としたバッチ処理を組む必要はありません。JPEG、PNG、BMP、WebPなどの画像内テキストを翻訳し、翻訳結果を画像として返せるため、サポート窓口、現場作業、社内ナレッジ翻訳、アプリ内の単発画像翻訳で使いやすくなります。MicrosoftのAzure Updatesでは、この機能は「Launched」、つまり本番利用可能な一般提供機能として扱われています。(マイクロソフトアジュール)

ただし、すべてのドキュメント翻訳を同期APIへ置き換えるべきではありません。大量ファイル、複数ターゲット言語、長時間処理、ストレージ連携が必要な業務では、引き続き非同期バッチ翻訳を使うのが現実的です。管理者と開発者は、APIバージョン、ファイル形式、サイズ上限、課金単位、認証キーの管理、エラー時の再試行設計を確認してから展開しましょう。

目次

Azure AI Foundryの画像ファイル翻訳で何が変わるのか

今回の更新は、Azure AI TranslatorのDocument Translationにおける「画像ファイルの同期・単一ドキュメント翻訳」の一般提供です。公式ドキュメントでは、Document Translation API version 2026-03-01 の新機能として、.jpeg、.png、.bmp、.webp のような単体画像ファイル内のテキストを翻訳し、翻訳済みコンテンツを画像へレンダリングして返す機能が説明されています。(Microsoft Learn)

実務上の変化は、次の3点に集約できます。

観点これまで課題になりやすかったこと今回の更新でできること
実装方式画像1枚の翻訳でも、OCR、テキスト翻訳、画像再生成を個別に組み合わせる必要があった画像ファイルをDocument Translation APIへ送信し、翻訳後の画像をレスポンスで受け取れる
処理フローバッチ翻訳ではBlob Storage、ジョブ投入、ステータス確認、出力取得が必要だった同期APIでは1回のPOSTで単一ファイルを翻訳でき、Blob Storageは不要
ユースケース大量処理には向いていても、ユーザー操作に応じた即時翻訳には重くなりやすかったチケット添付画像、製品ラベル、画面キャプチャなどの単発翻訳に組み込みやすい

同期翻訳は、POST /translator/document:translate に対して multipart/form-data でファイルを送信し、翻訳済みファイルをHTTPレスポンスのバイナリとして受け取る仕組みです。REST APIの最新ガイドでは、API version 2026-03-01、targetLanguage、Ocp-Apim-Subscription-Key、ファイルのMIMEタイプ指定などが示されています。(Microsoft Learn)

同期画像翻訳が向いているケース、向かないケース

同期APIは「すぐ返す」ことに価値がある場面で強みを発揮します。一方で、処理対象が大量になると、バッチのほうが運用しやすくなります。

判断軸同期APIが向いている非同期バッチが向いている
ファイル数1回の操作で画像1枚を翻訳する複数ファイルをまとめて処理する
体験ユーザーが画面上で翻訳結果をすぐ確認する処理完了後にまとめてダウンロードする
保存先アプリ側でレスポンスを受け取り、そのまま表示または保存するBlob Storage上の入力・出力コンテナーで管理する
例サポートチケットの添付画像、スマホで撮ったラベル、海外拠点から届いた1枚の案内画像マニュアル一式、契約書フォルダー、研修資料の一括翻訳
注意点タイムアウト、MIMEタイプ、サイズ上限、即時応答の失敗処理が重要ストレージ権限、ジョブ監視、出力先管理、再実行設計が重要

公式ドキュメントでも、同期単一ファイル翻訳は「1つのドキュメントをPOSTし、翻訳結果をレスポンスで直接受け取る」方式で、Azure Blob Storageを必要としないと説明されています。一方、非同期バッチ翻訳は複数または大きなファイルをBlob Storage経由で処理します。(Microsoft Learn)

API利用時に押さえるべき基本仕様

開発者が最初に確認すべきなのは、エンドポイント、APIバージョン、ヘッダー、クエリパラメーター、リクエストボディです。特に画像ファイルでは、拡張子だけでなくMIMEタイプの指定をアプリ側で正しく扱う必要があります。

項目確認内容
エンドポイント{endpoint}/translator/document:translate
APIバージョン2026-03-01
HTTPメソッドPOST
入力形式multipart/form-data
必須クエリtargetLanguage、api-version
任意クエリsourceLanguage、category、allowFallback
必須ヘッダーOcp-Apim-Subscription-Key
条件付きヘッダーregional resourceを使う場合は Ocp-Apim-Subscription-Region
レスポンス成功時は翻訳済みファイルをバイナリで返す

画像PNGを日本語へ翻訳する最小構成の例は次のようになります。

curl -X POST "{endpoint}/translator/document:translate?targetLanguage=ja&api-version=2026-03-01" \
  -H "Ocp-Apim-Subscription-Key: {key}" \
  -F "[email protected];type=image/png" \
  -o translated.png

REST APIでは、document パートに翻訳対象ファイルとMIMEタイプを含めます。用語集を使う場合は、glossary を追加できます。レスポンスコードは、成功時の 200 のほか、パラメーター不備の 400、認証失敗の 401、MIMEタイプ不備などの 415、レート制限の 429 が想定されます。(Microsoft Learn)

管理者が確認すべき設定と運用ポイント

Translatorリソースとカスタムドメインエンドポイントを確認する

同期翻訳を使うには、Azure AI TranslatorリソースまたはMicrosoft Foundryリソースを用意します。Document TranslationのREST APIでは、カスタムドメインエンドポイントが必要です。エンドポイントはリソース名を含む https://{your-resource-name}.cognitiveservices.azure.com/ の形式で扱われます。(Microsoft Learn)

管理者は、検証環境と本番環境で以下を分けて管理してください。

確認項目実務での見方
リソース名エンドポイントURLに含まれるため、環境や用途が分かる命名にする
キー管理ソースコードや設定ファイルへ直書きせず、Key Vaultやシークレット管理を使う
権限開発者全員にキー閲覧権限を与えず、CI/CDや実行環境に限定する
ネットワーク社内アプリから直接呼ぶか、API Managementなどを経由するか決める
監査リクエストID、エラーコード、処理対象のファイル種別を記録する。ただし画像内容そのもののログ保存は避ける

同期処理の上限を前提に設計する

公式のサービス制限では、同期Document Translationは1リクエストあたり1ファイル、1ターゲット言語、ドキュメントサイズ10MBまで、用語集1MBまでといった制限が示されています。上限はサービス更新で変わる可能性があるため、本番展開前に最新のService limitsを確認してください。(Microsoft Learn)

特に注意したいのは、フロントエンドから画像を直接アップロードさせる構成です。スマートフォン写真は見た目以上にファイルサイズが大きくなることがあります。アップロード前に圧縮、リサイズ、拡張子とMIMEタイプの検証を入れておくと、API側の 400 や 415 を減らせます。

課金は「画像単位」と「画像内文字量」を確認する

Azure Translatorの価格ページでは、Document Translationの画像は「画像1,000枚あたり」の課金項目として示され、1画像は最大500文字を含み、500文字を超える場合は500文字単位で複数画像として扱われると説明されています。たとえば画像内の文字が多い商品カタログや掲示物では、見かけ上の画像枚数より課金単位が増える可能性があります。(マイクロソフトアジュール)

コスト管理では、単にAPI呼び出し回数を見るだけでは不十分です。少なくとも次の指標を記録しましょう。

  • 翻訳リクエスト数
  • 入力ファイル形式
  • 入力ファイルサイズ
  • 成功、失敗、再試行の回数
  • 翻訳先言語
  • 画像翻訳を実行したアプリ機能名

データ所在地とコンプライアンスを確認する

Document Translationのデータ所在地は、Translatorリソースを作成したAzureリージョンに依存します。公式ドキュメントでは、Asia Pacificの処理先としてJapan EastとSoutheast Asiaが示されています。個人情報、機密資料、顧客から受け取った画像を扱う場合は、リソースリージョン、ログ保存、出力ファイルの保存期間を管理ルールに落とし込んでください。(Microsoft Learn)

開発者が実装前に確認すべきポイント

sourceLanguageは分かるなら明示する

sourceLanguage は任意ですが、入力画像の言語が分かっているなら明示したほうが安全です。FAQでは、ソース文書の言語が分かっている場合は、翻訳品質向上のためにソース言語を指定することが推奨されています。複数言語が混在する場合や言語が不明な場合は、自動検出に任せる判断になります。(Microsoft Learn)

たとえば英語の製品ラベルを日本語にするなら、次のように指定します。

curl -X POST "{endpoint}/translator/document:translate?sourceLanguage=en&targetLanguage=ja&api-version=2026-03-01" \
  -H "Ocp-Apim-Subscription-Key: {key}" \
  -F "[email protected];type=image/jpeg" \
  -o label-ja.jpg

レスポンスは「翻訳テキスト」ではなく「翻訳済みファイル」として扱う

同期画像翻訳では、成功時に翻訳後のファイルがレスポンスボディとして返ります。アプリ側ではJSONを期待するのではなく、バイナリを保存または表示する処理が必要です。Webアプリなら、レスポンスをBlobとして扱い、プレビュー表示またはダウンロードへ回す設計になります。(Microsoft Learn)

失敗時はJSON形式のエラーが返る場合があるため、成功時と失敗時でレスポンス処理を分けましょう。よくある失敗は次の通りです。

エラー起きやすい原因対応
400targetLanguage 不足、クエリ不備、フォームデータ不備必須パラメーターを送信前に検証する
401キー誤り、期限切れ、環境変数の設定ミスKey VaultやCI/CD変数を確認する
415MIMEタイプ不一致、未対応形式拡張子とMIMEタイプの両方を検証する
429短時間にリクエストが集中指数バックオフ、キューイング、ユーザー単位の制限を入れる
500一時的なサービス側エラーリクエストIDを記録し、再試行後も失敗する場合は調査する

UIで即時翻訳する場合はタイムアウト設計が重要

同期APIはユーザー操作に組み込みやすい反面、ブラウザやバックエンドのタイムアウト設定に影響されます。高解像度画像、文字量が多い画像、混雑時のリトライが重なると、ユーザーには「ボタンを押しても反応しない」ように見えます。

実装時は、翻訳中のローディング表示、キャンセル導線、失敗時の再試行ボタンを用意してください。バックエンドでは、同じ画像を短時間に何度も投げないように、ハッシュ値による重複抑止や、ユーザー単位のレート制限を入れると安定します。

移行・展開時の進め方

既存システムがOCRと翻訳APIを組み合わせている場合でも、いきなり全体を置き換える必要はありません。まずは「単体画像をすぐ翻訳したい」導線だけを同期Document Translationへ切り出すのが安全です。

ステップ作業内容判断基準
現状把握画像翻訳が発生している画面、ファイル形式、件数、失敗パターンを洗い出す単発処理が多いか、一括処理が多いか
小規模検証JPEG、PNG、スクリーンショット、スマホ写真で翻訳結果を比較するレイアウト、文字認識、翻訳品質が業務に耐えるか
API実装api-version=2026-03-01、MIMEタイプ、エラー処理を実装する失敗時にユーザーが次の操作を選べるか
セキュリティ確認キー管理、ログ、保存期間、アクセス権を確認する画像内容が不要に保存されていないか
コスト確認画像枚数、文字量、再試行回数を記録する月次コストの見積もりに使えるか
段階展開一部ユーザー、特定画面、特定言語から有効化する問い合わせ増加や翻訳失敗率が許容範囲か

たとえば社内ヘルプデスクで、海外拠点から届く画面キャプチャを翻訳して一次回答に使っている場合、同期APIは相性が良い構成です。オペレーターが画像をアップロードし、数秒から十数秒程度で翻訳済み画像を確認できれば、OCR結果のコピー、翻訳、画像への手作業転記を減らせます。一方、月末に数千枚の画像付き資料をまとめて翻訳する用途では、ジョブ管理しやすい非同期バッチのほうが適しています。

失敗しやすいポイントと回避策

画像品質を軽視すると翻訳品質が落ちる

画像翻訳は、画像内の文字を検出して翻訳するため、元画像の品質に左右されます。低解像度、傾き、影、反射、圧縮ノイズ、手書きに近い文字、背景と文字色のコントラスト不足があると、期待通りに翻訳されない可能性があります。

本番導入前には、きれいなサンプル画像だけでなく、実際に現場から届く画像で検証してください。特にスマホ撮影のラベル、掲示物、機械の表示パネルは、斜め撮影や反射が入りやすいため、アップロード前の撮影ガイドを用意すると効果的です。

レイアウト保持を過信しない

Document Translationは元の構造や形式の保持を重視する機能ですが、翻訳後の文字数が増減すると、テキストの折り返しや位置ずれが起きる可能性があります。FAQでも、翻訳による文字長の変化がレイアウトへ影響することや、フォントスタイルの保持には要因があることが説明されています。(Microsoft Learn)

公開物、契約関連資料、顧客向け画像に使う場合は、機械翻訳後に人が確認する工程を残しましょう。特に製品名、法的表現、安全注意、単位、数値は自動翻訳だけで確定させないほうが安全です。

透かし、印影、複雑な図表を含む画像は要注意

Azure Translatorの既知の問題では、透かしや印影がテキストに重なる文書、複雑な表やグラフ、多言語が混在する文書などで、翻訳が不完全または不正確になる可能性が示されています。画像翻訳でも、文字の上に印影や透かしが重なる場合は、OCRと翻訳の両方に影響します。(Microsoft Learn)

回避策として、可能であれば透かしのない原本画像を使う、表やグラフは元データから別途翻訳する、複数言語が混じる画像は翻訳対象を分ける、といった運用を検討してください。

Foundryポータルで試せることと、本番APIを混同しない

公式ドキュメントでは、Foundry portalは同期単一ファイル翻訳をサポートする一方、新しいFoundry portalではサンプル文書と事前定義された言語に限定され、顧客が用意した文書を扱えない旨が説明されています。検証時にポータルで試した内容が、そのまま本番アプリの仕様になるとは限りません。(Microsoft Learn)

本番実装では、REST APIまたはSDKを使い、認証、ファイル検証、エラー処理、監査ログ、コスト監視まで含めて設計しましょう。

管理者・開発者向けチェックリスト

展開前に、次の項目を確認してください。

区分チェック項目
サービスAzure AI TranslatorまたはMicrosoft Foundryリソースを用意している
エンドポイントカスタムドメインエンドポイントを使っている
APIapi-version=2026-03-01 を指定している
入力JPEG、PNG、BMP、WebPなど対象形式を明確にしている
MIME拡張子だけでなくMIMEタイプを検証している
制限ファイルサイズ、1リクエスト1ファイル、1ターゲット言語の前提を確認している
言語入力言語が分かる場合は sourceLanguage を指定している
セキュリティキーをソースコードに埋め込まず、安全に保管している
ログ画像本文や個人情報を不要にログ保存しない
コスト画像枚数、文字量、再試行回数を監視できる
品質実データでレイアウト、認識精度、用語の揺れを確認している
フォールバック失敗時に手動翻訳、再アップロード、バッチ処理へ切り替えられる

まず取るべき行動

今回のAzure AI Foundry関連更新は、画像ファイル翻訳をアプリや業務画面へ組み込みたいチームにとって実用的な改善です。特に、単体画像をその場で翻訳したいケースでは、Blob Storage前提のバッチ処理よりも軽く実装できます。

最初にやるべきことは、既存業務の中から「画像1枚をすぐ翻訳できると効果が大きい場面」を1つ選ぶことです。次に、実際の画像サンプルで同期APIを検証し、ファイルサイズ、MIMEタイプ、翻訳品質、レイアウト、課金見積もりを確認します。問題なければ、特定画面や特定部署に限定して段階展開し、ログとコストを見ながら対象範囲を広げるのが安全です。

大量翻訳は非同期バッチ、ユーザー操作に応じた単発翻訳は同期API。この使い分けを明確にすることで、Azure AI Translatorの画像ファイル翻訳を無理なく業務に取り込めます。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次