概要
https://workos.com/blog/llms-are-tres-bien-at-localization
詳細内容
## LLMはローカライゼーションに非常に優れている
https://workos.com/blog/llms-are-tres-bien-at-localization
**Original Title**: LLMs are très bien at localization
WorkOSは、最先端のLLMと現代的な開発ツールを活用し、AuthKitをわずか5週間で90言語にローカライズした手法を解説し、Webアプリケーション開発者向けの実践的な手順を提供する。
**Content Type**: 📖 Tutorial & Guide
**Language**: en
**Scores**: Signal:4/5 | Depth:4/5 | Unique:3/5 | Practical:5/5 | Anti-Hype:4/5
**Main Journal**: 85/100 | **Annex Potential**: 79/100 | **Overall**: 80/100
**Topics**: [[ローカライゼーション, LLM活用, React開発, 国際化, 開発ワークフロー改善]]
WorkOSは、AuthKitを5週間で90言語にローカライズした経験に基づき、Webアプリケーションにおける多言語対応の実装戦略を提示しています。このプロセスでは、現代の開発ツールとLLMの活用が鍵となりました。
まず、同社はローカライゼーションの設計思想として、「最初からグローバルに対応すること」と「誤訳はバグであり、手動修正で対応すること」を掲げ、迅速な実装を重視しました。サポートする言語の決定には、`accept-language` HTTPヘッダーの実際のユーザーデータと`negotiator`ライブラリを利用し、90の言語タグを選定しています。
実装の基盤技術としては、FormatJS（`react-intl`）を推奨しています。これは、翻訳文字列のコードと隣接配置、コンポーネント削除時の関連翻訳の自動削除、`description`プロパティによるLLMへのコンテキスト提供、自動翻訳ID生成、文字列補間機能など、開発者体験（DX）を大幅に向上させます。ESLintの`eslint-plugin-formatjs`プラグインを活用し、ハードコードされた文字列を`Translation`コンポーネントまたは`useTranslation`フックに置き換えることで、コードベース全体の翻訳対応を徹底しました。特に、大規模リポジトリではAIエージェント（Claude Code）にリントエラー修正を指示するプロンプトが紹介されており、文字列抽出の自動化にLLMが貢献します。
文字列抽出後は、LLM（Claude Sonnet 4）を用いた自動翻訳パイプラインを構築。構造化されたJSON出力、プロンプトキャッシュ、決定論的結果、高レートリミットといった要件を満たすモデルを選定しました。効果的なシステムプロンプトの生成には、AI自身にプロンプトを作成させるアプローチも採用し、WorkOSやAuthKitの目的といった固有のコンテキストを与えることで翻訳精度を高めています。ユーザーがカスタマイズ可能なテキストなど、ビルド時に不明な文字列に対しては、サーバーアクションとデータベースの`jsonb`カラムを利用したランタイム翻訳機能で対応しました。
テストにはChrome DevToolsのSensorsタブで`accept-language`ヘッダーを変更する方法が効率的です。また、ローカライゼーションにおける「落とし穴」として、デフォルトパラメータの文字列、``タグのタイトル、右から左に記述する言語（RTL）におけるシェブロンアイコンの方向、非ラテン語フォントの選定、そして翻訳によってボタンの文字が溢れる問題などが挙げられ、それぞれ具体的な解決策が示されています。特に文字溢れについては、LLMに翻訳の再調整を依頼するアプローチが紹介されています。
この記事は、ローカライゼーションが製品の成長に不可欠であり、LLMと適切なツールを組み合わせることで、その導入がかつてなく容易になっていることを強調しています。これは、グローバル展開を目指すWebアプリケーションエンジニアにとって、実践的かつ価値の高い情報源となるでしょう。