Azure AI FoundryのNextGen playgroundで、Azure Translator向けのAdaptive Custom Translation（AdaptCT）が一般提供されました。結論から言うと、企業固有の用語・表記・文体を翻訳結果に反映したい場合に、従来のような大規模なモデル再トレーニングを前提にせず、小さな対訳データセットから翻訳を調整しやすくなった更新です。特に、製品マニュアル、サポートFAQ、社内規程、SaaS画面文言、業界特化コンテンツを多言語化しているチームに影響があります。Microsoft Learnの関連ページは2026年6月3日に更新され、Adaptive Custom Translation playgroundがFoundry NextGenでGAとなり、コードなしでデータセットのライフサイクル管理ができると説明されています。(Microsoft Learn)
今回のポイントは「翻訳エンジンを丸ごと作り直す」のではなく、「翻訳時に参照すべき用語・表現・文脈を与えて、LLMの出力を業務ドメインに寄せる」ことです。管理者はFoundryリソース、Translatorリソース、RBAC、認証、ネットワーク、課金影響を確認し、開発者はadaptiveDatasetId、APIバージョン、フォールバック動作、既存Translator APIからの移行テストを進める必要があります。
Azure AI FoundryのAdaptive Custom Translationで何が変わったのか
今回の更新では、Azure AI Foundry NextGen playground内でAzure TranslatorのAdaptive Custom Translationを実運用向けに使いやすくなった点が重要です。Azure Updatesでは対象アップデートが「Launched」として扱われており、Azure Updates上のLaunchedは「完全にリリース済みで、本番利用可能な製品がAzure顧客に提供される」状態として説明されています。(マイクロソフトアジュール)
Adaptive Custom Translationは、Microsoft Foundryで利用できるランタイム翻訳適応機能です。コンパクトな参照文ペアを使い、GPT-5.1などのLLM出力を改善する仕組みとして説明されています。(Microsoft Learn)
| 観点 | 変更点 | 実務上の意味 |
|---|---|---|
| 提供状態 | Azure AI Foundry NextGen playgroundでAdaptive Custom TranslationがGA | PoCだけでなく、本番導入に向けた検証対象にしやすくなった |
| データ管理 | プレイグラウンドでコードなしのデータセットライフサイクル管理が可能 | 翻訳担当者やローカライズ担当者も、開発者に依存しすぎず検証しやすい |
| データ要件 | 5〜10,000個の事前アライン済みソース・ターゲット文ペアを使用 | 大規模な並列コーパスがなくても、小さく始められる |
| 翻訳適応 | 推論時に類似セグメントを取得し、用語・文脈・スタイルを誘導 | 新製品名や社内用語の反映を短いサイクルで改善できる |
| API連携 | Azure Translator 2026-06-06 APIで適用可能 | 既存アプリへの組み込みにはAPI差分と移行テストが必要 |
| 注意点 | APIによるデータセットライフサイクル管理はv1.0プレビュー | 画面操作のGAとAPI運用の成熟度を分けて評価する必要がある |
特に見落としやすいのは、「Adaptive Custom Translationそのものが便利になった」だけでなく、「翻訳ワークフローの更新速度」が変わることです。たとえば、毎月新機能が増えるSaaS製品で、workspaceを「作業場」と訳されると困る場合、用語を含む対訳例を登録しておけば、次回以降の翻訳で「ワークスペース」という表記に寄せやすくなります。
AdaptCTは再トレーニングではなく、翻訳時に参照データを使って調整する仕組み
Adaptive Custom Translationの本質は、従来型のカスタム翻訳モデルのように専用モデルを大規模にトレーニングすることではありません。Microsoft Learnでは、AdaptCTは大規模なトレーニングや個別デプロイを必要とせず、推論時にアダプティブデータセットから類似セグメントを取得して、用語、コンテキスト、スタイルをガイドすると説明されています。(Microsoft Learn)
小さなデータセットで始められるのが最大の利点
AdaptCTでは、5〜10,000個の事前アライン済みソース・ターゲットのセグメントペアをアップロードします。各セグメントは250文字以下である必要があり、サービス側で数分程度でアダプティブデータセットが作成されると説明されています。(Microsoft Learn)
実務では、いきなり社内の全翻訳資産を投入するよりも、以下のような「価値の高い少量データ」から始める方が成功しやすくなります。
- 製品名、機能名、UIラベルを含む短い文
- 誤訳されると問い合わせにつながるサポートFAQ
- 法務・医療・製造・金融など、一般訳では意味がずれる用語
- ブランドトーンが重要なマーケティング文
- 既存の人手翻訳で品質が高い短文ペア
たとえば、英語のtenantを一般的な「借主」ではなく、クラウドサービス文脈では「テナント」と訳したい場合があります。このような用語は単語帳だけでなく、実際の文脈を含む対訳例として登録した方が、翻訳の方向性を伝えやすくなります。
影響範囲：誰が何を確認すべきか
今回のAzure AI Foundry更新は、単に翻訳担当者だけの話ではありません。Azureリソース、認証、ネットワーク、API、コスト、品質評価にまたがるため、管理者と開発者の両方で確認が必要です。
| 対象者 | 影響 | まず確認すること |
|---|---|---|
| Azure管理者 | Foundryリソース、Translatorリソース、RBAC、課金設定に影響 | 利用リソース、リージョン、権限、予算アラート |
| 開発者 | Translator APIのリクエスト形式やadaptiveDatasetId指定に影響 | APIバージョン、JSON形式、フォールバック設定、SDK対応 |
| セキュリティ担当 | 対訳データに機密情報が含まれる可能性 | 投入データの分類、アクセス権、監査、保存ルール |
| 翻訳・ローカライズ担当 | 用語・文体の反映プロセスが変わる | 対訳データの品質、用語集、レビュー基準 |
| 業務部門 | 多言語コンテンツ更新のリードタイム短縮が期待できる | どの文書・画面・FAQから適用するか |
| 運用担当 | レイテンシ、エラー、翻訳品質の監視が必要 | ログ、再試行、ロールバック、A/B比較 |
重要なのは、AdaptCTを「翻訳品質を自動で完全に解決する機能」と見なさないことです。品質の上限は、投入する対訳データの品質、ドメインの一貫性、評価設計に大きく左右されます。
Custom Translatorとの使い分け
Adaptive Custom TranslationがGAになっても、従来のCustom Translatorが不要になるわけではありません。Microsoft Learnでは、AdaptCTは新しいモデル成果物を作成せず、用語・フレージング・スタイルを迅速かつ反復的に制御したい場合に適している一方、Custom Translatorは大規模な並列コーパスでトレーニングされた専用ニューラル翻訳モデルが必要な場合に適していると整理されています。(Microsoft Learn)
| 判断基準 | Adaptive Custom Translation | Custom Translator |
|---|---|---|
| 向いている用途 | 用語や表現を短いサイクルで調整したい | 大量文書を一貫した専用モデルで翻訳したい |
| 必要データ | 少量の事前アライン済み文ペアから開始可能 | 通常は大規模な並列文ペアが必要 |
| 更新速度 | データセット更新を数分単位で反映しやすい | 再トレーニングと再デプロイが必要 |
| 運用負荷 | データセット管理中心 | モデル管理、再学習、デプロイ管理が必要 |
| 典型例 | サポートチケット、FAQ、製品UI、頻繁に変わる用語 | 法的契約、専門文書、大量で厳密な翻訳資産 |
| 失敗しやすいケース | 品質の低い対訳例を混在させる | データ量や更新頻度に対して運用が重くなる |
目安として、まずはAdaptCTで「少量・高価値・頻繁に変わる」領域を改善し、安定した大量翻訳が必要な領域ではCustom Translatorを検討する流れが現実的です。
管理者が確認すべき設定と運用ポイント
FoundryリソースとTranslatorリソースの関係を確認する
Azure Translatorは既定でニューラル機械翻訳を使用しますが、LLMモデルを使う場合はFoundryリソースが必要とされています。既存のAzure Translatorリソースやマルチサービスリソースを使っている組織でも、LLM翻訳やFoundry連携を前提にする場合は、Foundryリソースの有無を確認してください。(Microsoft Learn)
確認すべき項目は以下です。
| 確認項目 | 見る場所 | 判断ポイント |
|---|---|---|
| Foundryリソース | Azure portal / Microsoft Foundry | LLM翻訳を使う構成になっているか |
| Translatorリソース | Azure portal | 既存のキー、エンドポイント、リージョンを利用するか |
| サブスクリプション | Azure portal | 本番・検証環境が分離されているか |
| リソースグループ | Azure portal | 翻訳関連リソースのライフサイクルが整理されているか |
| 価格レベル | Azure portal / 価格表 | 検証用と本番用で想定コストが分かれているか |
RBACと認証方式を整理する
Foundry連携では、単にAPIキーを持っているだけでなく、適切なロールとアクセス許可が必要です。Microsoft Learnでは、環境設定の前提として、サブスクリプションレベルでFoundry Account Owner、または共同作成者、Cognitive Services共同作成者ロールを持つことが要件を満たすと説明されています。さらに、Cognitive ServicesユーザーロールをマネージドIDに割り当てる手順も示されています。(Microsoft Learn)
本番導入前には、少なくとも次の方針を決めておきます。
| 項目 | 推奨される確認 |
|---|---|
| 管理者権限 | 誰がFoundryリソース、Translatorリソース、データセットを作成できるか |
| 実行権限 | アプリケーションからの翻訳実行にマネージドIDを使うか、キー認証を使うか |
| キー管理 | APIキーをアプリに直書きしていないか |
| 監査 | データセット作成、削除、権限変更を追跡できるか |
| 職務分離 | 翻訳データを編集する人と本番反映する人を分けるか |
小規模な検証ではキー認証で始めがちですが、本番ではマネージドIDやMicrosoft Entra ID認証を優先して検討する方が、キー漏えいリスクを抑えやすくなります。
ネットワーク制約を必ず確認する
見落としやすい注意点として、Microsoft LearnのTranslate APIページでは、Translatorリソースがプライベートエンドポイントで構成されている場合、LLMベースの翻訳は使用できないと記載されています。閉域網、Private Link、厳格なデータ境界を前提にしている企業では、AdaptCTを含むLLM翻訳の採用可否を早い段階で検証する必要があります。(Microsoft Learn)
特に以下の環境では、机上設計だけで進めない方が安全です。
- 翻訳APIを社内ネットワークからのみ呼び出している
- Private Endpoint必須のセキュリティ基準がある
- 特定リージョン外への処理を禁止している
- 医療、金融、公共などデータ所在要件が厳しい
- 既存のTranslator構成をそのままLLM翻訳にも使えると想定している
課金とレイテンシの見積もりを分けて行う
Azure Translatorの2026-06-06概要では、NMT翻訳は通常ソーステキストの文字数に応じて課金され、生成AI LLMを使った翻訳は処理された入力トークンと出力トークン数に応じて課金されると説明されています。一方、adaptiveDatasetIdを使う例では、Adaptive Custom TranslationはTranslatorインフラストラクチャにデプロイされ、料金はソース文字に基づくと説明されています。実際の請求は利用モデル、API、リージョン、SKU、価格表の更新に影響されるため、本番前に必ず実測してください。(Microsoft Learn) (Microsoft Learn)
コスト確認では、単価だけでなく次の観点が重要です。
| 観点 | 確認内容 |
|---|---|
| 文字数・トークン数 | 短文中心か、長文中心か |
| 翻訳回数 | 1回限りのドキュメント翻訳か、アプリ内で頻繁に呼ぶか |
| 対象言語数 | 1入力を複数言語へ翻訳するか |
| LLM利用 | NMTで十分か、LLM翻訳が必要か |
| レイテンシ | UI上で同期的に待てるか、バッチ処理に逃がすか |
| フォールバック | 意図せず一般翻訳に戻った場合の品質とコストを許容できるか |
開発者が確認すべきAPI・移行ポイント
Translator API 2026-06-06のリクエスト形式を確認する
Azure Translator REST API 2026-06-06では、要求配列にinputs、応答配列にvalueというキー名が使われるようになったと説明されています。既存のTranslator v3.0から移行する場合は、コードと内部ワークフローを見直し、運用コードを十分にテストしたバージョンに限定することが推奨されています。(Microsoft Learn)
単純な翻訳呼び出しだけでなく、AdaptCTを使う場合はtargets内にdeploymentNameやadaptiveDatasetIdを指定する設計になります。adaptiveDatasetIdは、ドメインデータと用語を使って作成されたデータセットインデックスを指定し、LLM出力をドメインの用語、文脈、スタイルに合わせて調整するために使われます。(Microsoft Learn)
{
"inputs": [
{
"text": "Sign in to your workspace and review the tenant policy.",
"language": "en",
"targets": [
{
"language": "ja",
"deploymentName": "your-llm-deployment-name",
"tone": "formal",
"adaptiveDatasetId": "<your-workspace-id>-adaptive-general",
"allowFallback": false
}
]
}
]
}この例では、workspace、tenant、policyのように、一般訳では文脈がずれやすい語を、登録済みの対訳データに基づいて調整する想定です。allowFallbackをfalseにすると、目的のモデルや言語ペアが使えない場合に一般システムへ自動的に戻るのではなく、エラーとして扱いやすくなります。Microsoft LearnではallowFallbackの既定値はTrueであり、Falseの場合はサポートされていない言語ペアでエラーが返ると説明されています。(Microsoft Learn)
adaptiveDatasetIdとreferenceTextPairsを混同しない
Translate APIでは、adaptiveDatasetIdのほかにreferenceTextPairsも指定できます。referenceTextPairsを指定した場合、adaptiveDatasetIdは無視されると説明されています。(Microsoft Learn)
| 使い方 | 向いている場面 | 注意点 |
|---|---|---|
adaptiveDatasetId | 継続的に使う業務用語・文体をデータセット化する | データセットの作成・更新・ID管理が必要 |
referenceTextPairs | その場の翻訳だけに少量の参照例を与える | 参照ペアをリクエストごとに管理する必要がある |
| 併用 | 原則として避ける | referenceTextPairs指定時にadaptiveDatasetIdが無視される点に注意 |
実務では、製品全体や部門共通の用語はadaptiveDatasetId、一時的なキャンペーン文言や単発文書はreferenceTextPairsという使い分けが分かりやすいです。
サービス制限を前提にバッチ設計を見直す
Azure Translator 2026-06-06概要では、翻訳操作の配列要素数とサイズについて、通常の翻訳と生成AI LLMで異なる制限が示されています。生成AI LLMでは配列要素の最大数が50、最大サイズが5,000とされているため、既存の大量一括翻訳処理をそのままLLM翻訳に流す設計は避けるべきです。(Microsoft Learn)
| 処理設計 | 確認ポイント |
|---|---|
| UIのリアルタイム翻訳 | レイテンシがユーザー体験に耐えるか |
| バッチ翻訳 | 1リクエストあたりの件数とサイズを分割できるか |
| 複数言語翻訳 | 言語数に応じてコストと処理時間が増えないか |
| 再試行処理 | 429、500系、タイムアウト時の再送設計があるか |
| ログ設計 | 入力文をそのままログに残して問題ないか |
| 品質評価 | NMT、LLM、AdaptCTの結果を比較できるか |
データセット作成で失敗しやすいポイント
AdaptCTの品質は、データセットの量よりも「文脈の近さ」と「対訳の一貫性」に左右されます。Microsoft Learnでは、250文字を超えるソースまたはターゲットのセグメントは拒否され、すべてのセグメントが無効な場合はドキュメントアップロードが失敗すると説明されています。問題のあるセグメントはImport Job Status APIで確認する流れです。(Microsoft Learn)
| 失敗例 | 起きる問題 | 対策 |
|---|---|---|
| 長すぎる文をそのまま投入 | セグメント制限に抵触し、取り込みに失敗する | 250文字以下の自然な単位に分割する |
| 用語だけを羅列する | 文脈が不足し、訳し分けが安定しない | 用語を含む短文ペアを用意する |
| 複数ドメインを混ぜる | 法務、サポート、マーケ文体が混在する | 用途別にデータセットを分ける |
| 古い訳語を混ぜる | 廃止済み名称が翻訳に反映される | 投入前に用語棚卸しを行う |
| レビューなしで投入 | 誤訳を正解例として学習文脈に使う | 人手レビュー済みデータだけを採用する |
| 本番データを無造作に使う | 機密情報や個人情報の取り扱いリスクが出る | マスキング、承認、保存期間を決める |
最初のデータセットは、50〜300文ペア程度でも構いません。重要なのは「よく誤訳される」「ビジネス上の影響が大きい」「短く明確な文脈がある」文を選ぶことです。
展開手順：PoCから本番導入までの進め方
Microsoft Learnでは、Foundryリソースの利用、ワークスペース作成、TMX/TSV形式のアダプティブドキュメントインポート、アダプティブデータセット作成、テキスト翻訳APIでの利用という流れが示されています。(Microsoft Learn)
| フェーズ | 作業 | 完了基準 |
|---|---|---|
| 現状把握 | 既存翻訳の誤訳、用語揺れ、レビュー工数を洗い出す | 改善対象の文書・画面・FAQが決まっている |
| データ準備 | TMXまたはTSVで対訳ペアを作る | 250文字以下、言語ペア、表記ルールが確認済み |
| リソース確認 | Foundry、Translator、RBAC、認証、リージョンを確認 | 検証環境で安全に実行できる |
| データセット作成 | NextGen playgroundまたはAPIでインポート・インデックス化 | アダプティブデータセットIDを取得できる |
| 品質評価 | NMT、LLM、AdaptCTを同じ入力で比較 | 用語、文体、意味保持、コスト、速度を評価済み |
| アプリ連携 | adaptiveDatasetIdを指定してAPI実装 | エラー処理、フォールバック、ログが実装済み |
| 段階展開 | 部門、文書種別、言語ペアを限定して本番化 | 問い合わせやレビュー差し戻しが増えていない |
| 継続改善 | 新語、廃止語、失敗例をデータセットに反映 | 更新ルールと責任者が決まっている |
Foundry上でワークスペースを作成する流れとして、Microsoft Learnではプロジェクトを選択し、Build > Models > AI Services > Azure Translator - Text Translation > Adaptive LLMを選ぶとワークスペースが自動作成されると説明されています。(Microsoft Learn)
本番展開前のチェックリスト
管理者向けチェックリスト
- Foundryリソースが必要な構成か確認した
- Translatorリソース、リージョン、価格レベルを確認した
- 検証環境と本番環境を分離した
- RBACとマネージドIDの方針を決めた
- APIキーの保管場所とローテーション手順を決めた
- プライベートエンドポイント利用時の制約を確認した
- コスト監視と予算アラートを設定した
- 対訳データに機密情報・個人情報が含まれないか確認した
- データセットを誰が作成・削除・更新できるか決めた
- 障害時に一般翻訳へ戻すか、エラーで止めるか決めた
開発者向けチェックリスト
api-version=2026-06-06のリクエスト形式を確認した- 既存Translator v3.0利用箇所との差分を洗い出した
inputs、targets、value形式に対応したdeploymentNameの指定方法を確認したadaptiveDatasetIdとreferenceTextPairsの使い分けを決めたallowFallbackの既定動作を理解した- LLM利用時のリクエストサイズ制限を考慮した
- 429、401、403、404、500系の処理を実装した
- レスポンス品質を自動評価または人手評価できるようにした
- 翻訳結果をキャッシュするかどうか決めた
どのような企業が優先して検証すべきか
Azure AI FoundryのAdaptive Custom Translationは、すべての翻訳用途で最初から必要になるわけではありません。優先度が高いのは、一般的な機械翻訳では業務上の意味がずれるケースです。
| 優先度 | 該当する状況 | 理由 |
|---|---|---|
| 高 | 製品名、機能名、UI用語の誤訳が多い | 少量の対訳例で改善効果を確認しやすい |
| 高 | サポートFAQを頻繁に更新している | 再トレーニングなしで表現更新しやすい |
| 高 | 法務・医療・製造など専門用語が多い | 一般訳では意味が変わるリスクがある |
| 中 | マーケティング文のトーンを統一したい | LLM翻訳と組み合わせて文体調整しやすい |
| 中 | 社内文書を多言語化している | 用語統一の効果はあるが、権限管理が重要 |
| 低 | 汎用的な短文翻訳だけで足りている | 通常のNMT翻訳で十分な可能性がある |
最初のPoCでは、全社展開を狙うよりも「誤訳が多く、改善効果を測りやすい1言語ペア・1文書種別」に絞るのが現実的です。たとえば、英日翻訳のサポートFAQだけを対象にし、既存NMT、LLM翻訳、AdaptCT適用後の3パターンを比較します。
運用で見るべき品質指標
AdaptCT導入後は、単に「自然に見えるか」だけで判断しない方が安全です。業務翻訳では、自然さよりも用語の正確性や意味の保持が重要な場面があります。
| 指標 | 見る内容 | 評価例 |
|---|---|---|
| 用語一致率 | 指定用語が正しく訳されているか | tenantが常に「テナント」になっている |
| 意味保持 | 原文の意味が変わっていないか | 否定、条件、期限、数量が保持されている |
| 文体一致 | 敬体、常体、ブランドトーンが合っているか | サポート文では丁寧語に統一されている |
| レビュー工数 | 人手修正が減ったか | 1記事あたりの修正時間が短縮された |
| エラー率 | API失敗やフォールバックが増えていないか | 401、403、429、500系を監視している |
| コスト | 文字数・トークン・呼び出し回数が想定内か | 月次予算を超えていない |
| レイテンシ | UIやワークフローに支障がないか | 同期処理で待ち時間が許容範囲内 |
特にallowFallbackを有効にしている場合、見た目上は翻訳に成功していても、期待したLLMやアダプティブデータセットが使われていない可能性があります。本番では、どの翻訳経路が使われたかをログやレスポンスヘッダーで追えるようにしておくと、品質トラブルの切り分けがしやすくなります。
まとめ：まずは「高価値な対訳データ」を小さく作って検証する
Azure AI Foundry NextGen playgroundでAdaptive Custom TranslationがGAになったことで、Azure Translatorの翻訳結果を業務固有の用語や文体に寄せる選択肢が実用段階に入りました。大規模なCustom Translatorモデルを作る前に、少量の対訳データで改善効果を試せる点が大きなメリットです。
一方で、管理者はFoundryリソース、RBAC、ネットワーク、課金、データガバナンスを確認する必要があります。開発者はTranslator API 2026-06-06のリクエスト形式、adaptiveDatasetId、referenceTextPairs、allowFallback、既存APIからの移行差分を押さえる必要があります。
次に取るべき行動はシンプルです。まず、誤訳の影響が大きい文書や画面を1つ選び、50〜300件程度の高品質な対訳ペアを作成します。そのうえで、通常のNMT翻訳、LLM翻訳、AdaptCT適用後の結果を比較し、用語一致率、レビュー工数、コスト、レイテンシを確認してください。小さく検証し、効果が見えた領域から段階的に展開するのが、Azure AI FoundryのAdaptive Custom Translationを安全に活用する近道です。
コメント