2026年6月3日に公開・更新された Azure AI Foundry 関連の公式情報では、Azure AI Translator の Unified Text Translation API が一般提供（GA）になったことが示されています。結論から言うと、今回の更新は「翻訳品質を上げる新機能が増えた」だけでなく、Text Translation API の使い方、移行設計、認証、ネットワーク、コスト管理を見直す必要がある変更です。特に v3.0 を使っている既存システムでは、api-version を変えるだけでは移行できません。リクエスト構造、レスポンス解析、未対応になったメソッド、LLM 利用時の Foundry リソース要件まで確認してから展開する必要があります。(Microsoft Azure)
Azure AI FoundryのUnified Text Translation APIで何が変わったのか
Azure AI Translator の Unified Text Translation API は、標準的なニューラル機械翻訳（NMT）だけでなく、LLM ベースの翻訳、Adaptive custom translation、トーンや性別に応じた出力制御などを、より統一された API 体験で扱えるようにする更新です。公式ブログでは、NMT の速度、LLM の流ちょうさ、適応型カスタマイズを単一エンドポイントに統合する方向性が説明されています。(Microsoft for Developers)
今回の中心は、Text Translation API の最新 GA 版である 2026-06-06 です。Microsoft Learn では、このバージョンが一般提供であり、v3.0 と比べてリクエスト・レスポンスのスキーマ変更、NMT と LLM のモデル選択、Adaptive output、tone、gender-specific variations などの翻訳制御を追加すると説明されています。(Microsoft Learn)
実務上は、次のように捉えると分かりやすいです。
| 観点 | これまでの考え方 | 2026-06-06 GAでの考え方 |
|---|---|---|
| 翻訳モデル | 主に標準翻訳APIを呼び出す | NMT、LLM、カスタムNMTなどを用途に応じて選択 |
| リクエスト構造 | to パラメーター中心 | inputs と targets 配列中心 |
| 品質調整 | カスタムモデルや外部処理で補う | referenceTextPairs や adaptiveDatasetId で出力を誘導 |
| 表現制御 | 翻訳後に別処理で調整しがち | LLM利用時に tone / gender を指定可能 |
| 移行難度 | APIバージョン変更で済む場合がある | v3.0とは下位互換ではないためコード修正が必要 |
一般提供になったことで本番利用しやすくなるが、移行は慎重に行う
GA は、本番利用を検討しやすい状態になったことを意味します。ただし、既存の Translator v3.0 利用者にとっては「そのまま置き換えられるアップデート」ではありません。Microsoft Learn では、2026-06-06 は v3.0 と下位互換ではなく、API バージョン、ペイロード構造、v3.0 固有メソッドに依存するコードを更新する必要があると明記されています。(Microsoft Learn)
特に注意すべきなのは、プレビュー版 2025-10-01-preview を検証していたチームです。公式の移行ガイドでは、このプレビュー API は GA から90日後に非推奨となり、GA へ移るには api-version=2026-06-06 を設定する必要があるとされています。(Microsoft Learn)
本番環境では、次のような進め方が現実的です。
| 利用状況 | 取るべき対応 |
|---|---|
| v3.0を本番利用中 | すぐに置換せず、非本番環境でAPI互換性と品質を検証 |
| 2025-10-01-previewを検証中 | GA版の 2026-06-06 に切り替え、差分を再テスト |
| 新規開発 | 原則として 2026-06-06 を前提に設計 |
| LLM翻訳を使いたい | Microsoft Foundryリソース、モデルデプロイ、コスト、ネットワーク条件を確認 |
| 用語や文体を揃えたい | Adaptive custom translation の参照ペアまたはデータセットを検討 |
開発者が最初に確認すべきAPI変更点
to パラメーター中心の実装から targets 配列へ変わる
v3.0 からの移行で最も影響が大きいのは、ターゲット言語の指定方法です。移行ガイドでは、v3.0 の to パラメーターを targets 配列へ置き換えることが重要な構造変更として示されています。(Microsoft Learn)
v3.0 のイメージは次のような形です。
POST https://api.cognitive.microsofttranslator.com/translate?api-version=3.0&to=ja
Content-Type: application/json
[
{
"Text": "Please confirm your order."
}
]2026-06-06 では、入力テキストと翻訳先を JSON の中で明示します。
POST https://api.cognitive.microsofttranslator.com/translate?api-version=2026-06-06
Content-Type: application/json
{
"inputs": [
{
"text": "Please confirm your order.",
"language": "en",
"targets": [
{
"language": "ja"
}
]
}
]
}この変更により、1つの入力に対して複数の翻訳ターゲットを柔軟に定義しやすくなります。一方で、既存コードが to=ja のようなクエリパラメーターや、v3.0 のレスポンス配列を前提にしている場合は、リクエスト生成とレスポンス解析を修正しなければなりません。
レスポンス解析も見直す
2026-06-06 の Translate API では、リクエスト本文に inputs 配列を使い、成功レスポンスでは入力ごとの結果を value 配列として扱う形が示されています。また、各翻訳結果には翻訳テキスト、ターゲット言語、検出言語などの情報が含まれます。(Microsoft Learn)
移行時に失敗しやすいのは、既存の JSON パーサーが v3.0 の構造を固定的に見ているケースです。たとえば、次のような実装は確認が必要です。
- レスポンスの先頭要素を直接配列として読む
translations[0].textの位置を固定している- 検出言語が必ず返る前提で処理している
- 複数ターゲット言語の順序だけで後続処理を分岐している
API の戻り値を画面表示だけに使っている場合は修正範囲が小さく済むこともあります。しかし、翻訳結果をデータベースへ保存したり、ワークフローの次工程に渡したりしている場合は、スキーマ変更の影響が連鎖します。
NMT、LLM、Adaptive custom translationの使い分け
Unified Text Translation API の価値は、すべてを LLM に置き換えることではありません。むしろ、翻訳対象ごとに「速さ」「コスト」「品質」「文体制御」のどれを優先するかを選びやすくなる点にあります。
| 用途 | 推奨しやすい選択 | 判断基準 |
|---|---|---|
| UI文言、通知文、短い定型文 | NMT | 低レイテンシ、大量処理、コスト重視 |
| FAQ、サポート回答、チャットボット | NMTまたはLLM | 自然さや文脈理解が必要ならLLMを検討 |
| 医療、法務、製造、金融などの専門文書 | LLM + Adaptive custom translation | 用語、文体、言い回しの一貫性が重要 |
| ブランドトーンを守りたいマーケティング文 | LLM + tone指定 + 人手確認 | 直訳より自然さや表現調整を重視 |
| 厳密な定型処理 | NMTまたはカスタムNMT | 出力の安定性と検証容易性を重視 |
Microsoft Learn では、LLM ベースの翻訳を使う場合、Microsoft Foundry リソースが必要であること、また NMT はソース文字数課金、LLM は処理された入力・出力トークン課金として考える必要があることが説明されています。大量トラフィックをすべて LLM に流す設計は、コストとレイテンシの両面で慎重に評価すべきです。(Microsoft Learn)
管理者が確認すべき設定と影響範囲
Microsoft FoundryリソースとTranslatorリソースの関係を整理する
標準のテキスト翻訳だけなら既存の Translator リソースで対応できるケースがあります。一方、LLM ベースの翻訳やモデル選択を本格的に使う場合は、Microsoft Foundry 側のリソース、プロジェクト、モデルデプロイ、アクセス権限を含めた確認が必要です。
管理者は、最低限次の項目を棚卸ししてください。
| 確認項目 | 見るべきポイント |
|---|---|
| Translatorリソース | リージョン、キー、エンドポイント、SKU、利用量 |
| Foundryリソース | LLM翻訳で必要なリソースが用意されているか |
| モデルデプロイ | deploymentName に指定する名前が環境ごとに一致しているか |
| 認証 | APIキー運用のままか、Microsoft Entra IDやマネージドIDへ移すか |
| ネットワーク | private endpoint利用時にLLM翻訳要件と矛盾しないか |
| 監査・ログ | リクエストID、APIバージョン、リージョン、使用量を追えるか |
| コスト管理 | NMT文字数課金とLLMトークン課金を分けて見積もれるか |
特に private endpoint を使っている環境では注意が必要です。Translate API のリファレンスでは、Translator リソースが private endpoint で構成されている場合、LLM based translation は利用できないと記載されています。閉域構成を優先する業務では、LLM 翻訳を使う範囲、データ処理場所、代替手段を事前に設計してください。(Microsoft Learn)
リージョンとデータ処理場所を確認する
翻訳APIは、グローバルエンドポイントを使うか、リージョン別エンドポイントを使うかで、レイテンシやデータ処理場所の考え方が変わります。Microsoft Learn では、グローバルエンドポイントでは通常もっとも近い利用可能なデータセンターで処理され、地理的な制約が必要な場合はリージョンエンドポイントを使う考え方が示されています。(Microsoft Learn)
日本国内のサービスであっても、すべてのシステムが同じ要件とは限りません。社内文書、顧客問い合わせ、医療・金融・公共系データなどを扱う場合は、技術担当だけでなく、セキュリティ、法務、データガバナンス担当者を含めて確認するのが安全です。
v3.0からの移行で削除・変更される機能に注意
2026-06-06 では、v3.0 の一部メソッドが利用できなくなります。移行ガイドでは、BreakSentence、Detect、Dictionary Lookup、Dictionary Examples がサポートされなくなることが示されています。Detect は Azure AI Language の言語検出 API への置き換え、辞書系は Adaptive custom translation の利用検討が案内されています。(Microsoft Learn)
| v3.0で使っていた機能 | 2026-06-06での扱い | 移行時の考え方 |
|---|---|---|
| Translate | 継続 | スキーマ変更に対応 |
| Transliterate | 継続 | 新APIの仕様で再検証 |
| Languages | 継続 | 対応言語・モデル確認に利用 |
| BreakSentence | 非サポート | NLPライブラリや文区切り処理へ置換 |
| Detect | 非サポート | Azure AI Languageの言語検出APIを検討 |
| Dictionary Lookup | 非サポート | 専門用語はAdaptive custom translationを検討 |
| Dictionary Examples | 非サポート | 用語例の管理方法を再設計 |
移行で見落としやすいのは、アプリ本体ではなく周辺処理です。たとえば、翻訳前に言語判定を行うバッチ、辞書検索を使う社内ツール、QA用の翻訳比較スクリプトなどが残っていることがあります。API 利用箇所は、ソースコード検索だけでなく、CI/CD、PowerShell、Logic Apps、Azure Functions、社内管理画面まで含めて洗い出してください。
SDK利用者はバージョン対応を確認する
REST API を直接呼び出していない場合でも、SDK のバージョン確認は必須です。たとえば .NET 向けの Azure Text Translation client library では、Azure.AI.Translation.Text 2.0.0 がサービス API version 2026-06-06 に対応し、1.0.0 は v3.0 に対応する関係が示されています。(Microsoft Learn)
SDK を更新すると、単に依存パッケージが新しくなるだけでなく、型、メソッド引数、レスポンスモデル、例外処理が変わる可能性があります。次の順序で確認すると安全です。
| 作業 | 確認内容 |
|---|---|
| 依存パッケージの棚卸し | SDK名、バージョン、利用言語を確認 |
| APIバージョンの固定 | 暗黙の既定値に頼らず、環境ごとに意図したAPIを使う |
| ビルド確認 | 非推奨・削除された型やメソッドを検出 |
| 単体テスト更新 | 新しいレスポンス型に合わせて期待値を変更 |
| 結合テスト | 実際のTranslatorリソースで認証、翻訳、エラー処理を確認 |
展開前に行うべき移行チェックリスト
既存利用箇所を棚卸しする
まず、どこで Translator API を呼び出しているかを洗い出します。アプリケーションコードだけでなく、バッチ、管理ツール、RPA、問い合わせ対応システム、CMS連携、チャットボット、社内翻訳ツールも対象です。
確認すべきキーワードは次の通りです。
api-version=3.0
api-version=2025-10-01-preview
cognitive.microsofttranslator.com
/translator/text/v3.0/
to=
Dictionary
Detect
BreakSentence
Ocp-Apim-Subscription-Key非本番環境でリクエストとレスポンスを比較する
移行時は、同じ入力文を v3.0 と 2026-06-06 の両方で翻訳し、次の観点で比較します。
| 比較項目 | 確認ポイント |
|---|---|
| 意味の保持 | 原文の意味が落ちていないか |
| 用語 | 製品名、機能名、業界用語が揺れていないか |
| 敬体・常体 | 「です・ます」と「である」が混在していないか |
| 性別・敬称 | 不要な性別表現や不自然な敬称が出ていないか |
| HTML | タグ構造が壊れていないか |
| レイテンシ | 既存SLAに収まるか |
| コスト | NMTとLLMのルーティングが妥当か |
| エラー | 400、401、403、429時の処理が正しく動くか |
LLM や Adaptive custom translation を使う場合は、翻訳結果が入力例やモデル構成に左右されます。Microsoft のブログでも、AI ベースの翻訳は言語ペア、ドメイン文脈、入力品質、モデル構成によって結果が変わるため、重要なコンテンツでは人による確認が推奨されています。(Microsoft for Developers)
allowFallback の扱いを決める
Translate API では、指定したモデルが特定の言語ペアをサポートしない場合に代替アプローチへフォールバックできる allowFallback が用意されています。既定では True とされ、False にするとサポートされない言語ペアでエラーを返す仕様です。(Microsoft Learn)
これは便利ですが、品質検証時には注意が必要です。たとえば「LLM で翻訳しているつもりだったが、実際には一般的な NMT にフォールバックしていた」という状態に気づきにくくなります。
本番運用では、次のように使い分けるとよいでしょう。
| シナリオ | allowFallback の考え方 |
|---|---|
| 翻訳を止めたくない顧客向けチャット | True を検討 |
| モデル別の品質検証 | False にして意図しないフォールバックを検出 |
| 法務・医療など厳密な翻訳 | False または人手確認フローを組み合わせる |
| 大量バッチ翻訳 | フォールバック時の品質差と課金差をログで追跡 |
運用で失敗しやすいポイント
すべてをLLMに流してしまう
LLM 翻訳は自然な表現や文脈対応に強みがありますが、すべての翻訳に必要とは限りません。Microsoft Learn では、NMT 翻訳はソーステキストの文字数、LLM 翻訳は入力・出力トークンに基づいて課金されると説明されています。コストを抑えるには、高頻度・定型的な翻訳は NMT、専門性や文体調整が必要な翻訳は LLM といったルーティング設計が重要です。(Microsoft Learn)
Adaptive custom translationに低品質な参照文を入れる
Adaptive custom translation は、少数の参照訳やデータセットで用語・文体を誘導できる一方、参照データの品質に強く影響されます。公式ブログでは、重複、古い訳、信頼度の低い訳を取り除き、用語の一貫性を保ち、言語ペアやドメインごとにデータセットを分けることが推奨されています。(Microsoft for Developers)
たとえば、サポート部門の過去回答をそのまま投入すると、古い製品名や誤った敬語が再利用される可能性があります。投入前に「最新版の用語集と矛盾していないか」「人が読んで自然か」「1文ごとに意味が対応しているか」を確認してください。
ログにAPIバージョンやモデル名を残していない
翻訳結果の品質やコストを改善するには、どのリクエストがどのAPIバージョン、どのモデル、どのリージョンで処理されたかを追える必要があります。Microsoft Learn でも、失敗時の切り分けにはリクエストID、エンドポイント、リージョン、APIバージョン、主要ヘッダーを記録することが有効と説明されています。(Microsoft Learn)
最低限、次の情報はアプリケーションログや監視基盤で確認できるようにしましょう。
api-version
endpoint
region
deploymentName
target language
allowFallback
adaptiveDatasetId
HTTP status
service error code
request ID
metered usage
latencyすぐに取るべき次のアクション
Azure AI Foundry で Unified Text Translation API を使う、または既存の Azure AI Translator 実装を移行する場合は、まず「使えるか」ではなく「どこに影響するか」を確認することが重要です。
最初の一歩として、次の順に進めてください。
- 既存システム内の Translator API 利用箇所を洗い出す
- v3.0、2025-10-01-preview、SDK利用の有無を分類する
2026-06-06の新スキーマで非本番環境の疎通テストを行う- Translate、Languages、Transliterate以外の旧メソッド利用を置き換える
- NMT、LLM、Adaptive custom translation の使い分けルールを決める
- private endpoint、リージョン、認証、コスト監視を管理者と確認する
- 本番展開前に、品質・レイテンシ・課金・フォールバックをログで検証する
今回の GA は、翻訳APIを単なる「文字列変換」から、AIアプリやCopilot、エージェントに組み込む多言語処理基盤へ広げる更新です。ただし、v3.0 からの移行は破壊的変更を含みます。新機能を急いで使うよりも、まず API 仕様、モデル選択、認証、ネットワーク、運用ログを揃え、影響範囲を小さく区切って展開するのが安全です。
コメント