7月24日、Salesforce Engineeringが「How AI Rebuilt Salesforce's Decades-Old Localization Pipeline」と題した記事を公開した。この記事では、数十年来のローカライゼーションパイプラインをLLMベースのAIワークフローで刷新し、コストを最大90%削減した取り組みについて詳しく紹介されている。

「翻訳が35%増、予算は据え置き」という詰み局面

Salesforceのローカライゼーション部門が直面した問題は単純だ。リリースごとに翻訳量が35%以上増加したにもかかわらず、予算もリリースウィンドウも一切変わらなかった。

34言語で同時リリースするというSalesforceの要件は変わらない。ドキュメント類は既に数年前に一般的な機械翻訳へ移行済みで、「簡単に取れる効率化の果実」は使い切っていた。翻訳者を増員するのはコスト面で持続不可能であり、リリース日を延ばすという選択肢もない。

ローカライゼーション担当VPのTeresa Marshallが問い直した課題はこうだ。「どうすれば速く翻訳できるか？」ではなく、「品質とリリーススケジュールを損なわずに、数十年来のエンタープライズローカライゼーションをAIで再発明できるか？」

「LLMに投げれば解決」が機能しなかった理由

最初の発想は「モダンなLLMで人間の翻訳者を置き換える」というものだった。しかし、エンタープライズのローカライゼーションはテキスト変換では済まない。

たとえばSalesforceでは、ユーザーがプラットフォーム上のオブジェクト名を自由にリネームできる。医療機関が「Account」を「Patient」に変更した場合、その語を含む周辺文章すべてが34言語で文法的に正しく成立しなければならない。加えて、Financial Services Cloud、Health Cloud、Sales Cloud、Slackはそれぞれ異なる語彙・ユーザー期待・言語慣習を持つ。

プロンプトを改善するアプローチは限界をすぐに露呈した。ブランド表記を正確に扱えるようにすると文法規則が崩れ、文法を修正するとプロダクトコンテキストが失われる。Sales Cloud向けに最適化すると別プロダクトで用語が揺れる。問題はプロンプトの質ではなく、単一のプロンプトで複数の相互干渉する要件を同時に満たそうとするアーキテクチャそのものにあった。

「1プロンプト」から「85ステージのAIパイプライン」へ

チームが到達した結論は、「プロンプトの改善ではなくアーキテクチャの再設計」だった。

構築されたのは、プロンプトエンジニアリングとコンテキストエンジニアリングを組み合わせたAIオーケストレーションパイプラインだ。UIの文字列を単一の翻訳リクエストに投げるのではなく、懸念事項ごとに分割された専門化AIステージを順番に実行する。記事で説明されているステージ構成の概要は以下のとおりだ。

• 初期ステージ：文法規則・Salesforce用語・ブランド表記・言語固有の慣習を確立する
• コンテキスト注入ステージ：プロダクトコンテキストを付与する（Sales Cloudか、Health Cloudか、Slackかを判別してから翻訳を開始する）
• 編集ステージ：出力を専用のエディタープロンプトに通し、文体・トーンを整える
• 検証ステージ：別の検証プロンプトが用語・品質・一貫性を独立して評価する

言語によっては、1つの翻訳文字列が本番到達前に最大85の専門プロンプトステージを通過する。 ステージ数が多いのは複雑さの現れではなく、「1つのプロンプトに詰め込まない」という設計判断の結果だ。各ステージが単一の責務を持つことで、干渉を避けながら品質を積み上げていく。

コンテキストは「プロンプトの補足情報」ではなく、アーキテクチャそのものになった。チーム内では「context, context, context」という言葉がプロジェクト中のキーワードになったと記事は述べている。

スタイルガイドが「AIインフラ」に変わった

本番投入への信頼性確保でも、重要な発見があった。人間の翻訳者向けに長年整備してきたスタイルガイド、用語集、ブランドガイダンス、言語規約といった資産が、そのままLLMへの構造化コンテキストとして再利用できるとわかったのだ。これらの資産をLLMが消費・適用・自己評価できる形式に再設計し、Salesforceのボイスを維持するための基盤とした。

検証自体もAIパイプラインとして構築されている。AI生成 → AI編集 → AI検証 → 人間レビューという多段階ワークフローで、各ステージが用語・文法・一貫性・品質を評価してから次へ渡す。人間のレビュアーは承認・却下だけでなく、プロンプトやコンテキストデータ、検証ルールを継続的に改善する役割を担い、次のリリースへのフィードバックループを形成する。

この結果、ローカライゼーションコストはワークフローによって50〜90%削減された。

次の課題：AIパイプラインを「普通の大規模本番システム」として運用する

パイプラインの次の進化における課題として記事が挙げるのは、基盤モデルの更新への追従だ。Foundation Modelが改良されるたびに、長年積み上げたプロンプトエンジニアリングとコンテキストエンジニアリングを作り直す事態は避けなければならない。

また、AIによるエンジニアリング生産性の向上がSalesforce全体で進むにつれ、ローカライゼーション需要はさらに増加する。焦点は今後、スループット、バッチ処理、データベース容量、品質ゲートといった「普通の大規模本番システムの運用課題」に移行しつつあると記事は指摘する。

記事が最後に強調するのは、AIが数十年の専門知識を置き換えたのではなく、その専門知識をプロンプト・コンテキスト・バリデーション・ワークフローへと変換したという点だ。AIシステムが本番で信頼できるものになるのは、基盤モデルが改善されるからではなく、エンジニアがモデルを信頼可能にするワークフローと検証を構築するからである。

詳細はHow AI Rebuilt Salesforce's Decades-Old Localization Pipelineを参照していただきたい。