Claude APIを使ったアプリケーションの多言語対応

こんにちは、kickflowでCTOをしている小林です。

kickflowでは先日中国語（簡体字・繁体字）と韓国語への対応をベータ版としてリリースしました。今回は、kickflowのプロダクトを多言語対応するにあたり、AIを活用した自動翻訳アプローチについてご紹介します。具体的には、Anthropic社のClaude APIとGitHub Actionsを駆使して、RailsとNuxt.jsで構築されたアプリケーションの翻訳ファイルを継続的に自動生成する仕組みを構築した話をします。

背景：多言語対応の必要性とROIの壁
採用した手法：AIによる翻訳の自動化
品質の安定性を高めるための5つの工夫
今後の展望
まとめ

背景：多言語対応の必要性とROIの壁

kickflowはこれまで日本語と英語の2言語でサービスを提供してきました。しかし、グローバルに事業を展開されているお客様が増えるにつれて、海外子会社の従業員などが利用するために、中国語や韓国語といった他の言語への対応ニーズが高まっていました。

通常、多言語対応といえば専門の翻訳サービスやSDKを導入するのが一般的です。私たちも過去にいくつかのソリューションを検討しましたが、いずれも獲得を見込める売上に対して導入・運用コストが非常に高く、ROI（投資対効果）の面で導入が難しいという結論に至っていました。

かといって、お客様のニーズがある以上、何もしないという選択肢はありません。そこで私たちは、コストを抑えつつ多言語対応を実現する新たな方法として、生成AIを活用した翻訳の自動化に着目しました。

採用した手法：AIによる翻訳の自動化

私たちが構築したのは、開発者がメンテナンスする日本語と英語の翻訳ファイルを正とし、それらを元にAIが他言語の翻訳ファイルを自動で生成し続ける仕組みです。

具体的には、以下の流れで自動化を実現しています。

翻訳元ファイルの準備: 開発者はこれまで通り、新機能の実装や文言修正の際に、Railsのi18nファイル（config/locales/**/*.yml）とNuxt.jsのi18nファイル（i18n/locales/**/*.json）の日本語（ja）と英語（en）を更新します。
日次での自動翻訳: 毎日定時にGitHub Actionsのワークフローが実行されます。
差分検出と翻訳実行: ワークフローは、jaとenのファイルと、その他の言語（zh-CNやkoなど）のファイルに差分があるかをチェックします。差分があれば、Claude API （モデルはSonnet 4）を呼び出して、差分のある箇所を翻訳します。
Pull Requestの作成と自動マージ: 翻訳が完了すると、生成された翻訳ファイルを含むPull Requestが自動で作成されます。CIが通ればエンジニアがマージし、翌日のリリースで本番環境に反映されます。

この仕組みにより、開発者は日本語と英語のメンテナンスに集中するだけで、他の言語へも継続的に対応が追従していく状態を作り出すことができました。

品質の安定性を高めるための5つの工夫

AIによる翻訳は非常に強力ですが、そのまま使うだけでは品質が安定しません。特にアプリケーションのUIテキストのように、正確さや一貫性が求められる場面では工夫が必要です。私たちが実践した5つの工夫をご紹介します。

1. JSON/YAMLを直接翻訳せず、テキストのみを抽出・再構築する

JSONやYAMLファイルをそのままプロンプトに渡して「このファイルを翻訳してください」と指示すると、フォーマットが崩れたり、文字列中のクォーテーションのエスケープに失敗したりと、出力が安定しませんでした。

そこで私たちは、AIに翻訳させる前にファイルからテキスト部分だけを抽出し、翻訳後に元の構造に復元するスクリプトを用意しました。

例えば、以下のようなJSONファイルがあったとします。

{
  "承認": "Approve",
  "差し戻し": "Send back",
  ...
}

これを一度フラットなKey-Valueの形式に変換し、Value（テキスト）だけをAIに渡します。

承認
差し戻し
...

AIが翻訳した結果を受け取ったら、元のキーと組み合わせて再びYAMLファイルを構築します。これにより、AIは純粋なテキストの翻訳に集中でき、構文を壊すリスクを大幅に低減できました。

2. 翻訳辞書でドメイン用語を統一する

AIは同じ単語でも、翻訳のたびに微妙に表現が揺れることがあります。例えば「申請」という単語が、ある画面では「Application」、別の画面では「Request」と訳されてしまうと、ユーザー体験を損ねてしまいます。

この問題に対応するため、私たちは主要なドメイン用語や頻出するUI文言をまとめた翻訳辞書をCSVで作成しました。

日本語,英語,中国語（簡体字）,中国語（繁体字）,韓国語
ダッシュボード,Dashboard,仪表板,儀表板,대시보드
マイチケット,My tickets,我的工单,我的工單,내 티켓
承認リクエスト,Approval requests,审批请求,審批請求,승인 요청
...

翻訳を実行する際、この辞書をプロンプトに含めることで、特定の単語が常に意図した通りに翻訳されるように制御しています。翻訳辞書に単語を登録することで、時制（現在・過去・未来など）や主語の人称・数による動詞の活用など、辞書に登録した単語と完全に一致していないケースにおいても、Claudeは翻訳辞書を元によしなに翻訳を実行してくれます。

3. 英語を併記して翻訳のコンテキストを補う

日本語は文脈依存度が高く、単語だけでは意味が確定しにくい場合があります。例えば「承認」という言葉は、名詞の「Approval」なのか、動詞の「Approve」なのか、日本語だけでは判断がつきません。

この曖昧さを解消するため、私たちはAIに翻訳を依頼する際に、日本語と英語の両方を提示するようにしました。

// プロンプトのイメージ
以下の日本語を中国語・韓国語に翻訳してください。
翻訳の際には、英語も参考に翻訳してください。

日本語のテキスト
${jaStrings}

英語のテキスト
${enStrings}

このように英語の情報を加えることで、AIが文脈をより正確に理解し、翻訳の精度が向上しました。

4. 翻訳単位を最適化し、用語の揺らぎを抑制する

翻訳の品質は、一度にAIに渡すテキストの量にも影響されます。

ファイルが巨大すぎる場合: 一度に大量のテキストを処理させようとすると、翻訳精度が低下したり、プロンプトで定義したルールが守られない傾向がありました。また、巨大なファイルは普段エンジニアが開発するときに扱いが難しいという問題もあります。
ファイルが細かすぎる場合: 画面をまたいで使われる単語の訳語が統一されにくくなります。

試行錯誤の結果、現在は1ファイルあたり100~200行程度にファイルを分割するのが最もバランスが良いと判断しています。同じ機能や画面で使われる文言は同じファイルにまとめることで、画面内での用語統一を図りつつ、AIが扱いやすい適切な粒度を保っています。

5. コスト削減と安定化のためMessage Batches APIを利用する

多数の翻訳ファイルを処理する際、APIをファイルごとに逐次呼び出すと、コストがかさむだけでなく、Anthropic Claude APIのレートリミットに引っかかりやすくなるという課題がありました。

この対策として、Anthropicが提供しているMessage Batches APIを活用しています。これは、複数のClaudeへのリクエストをまとめて送信することで、コストが50%安くなるというものです。代わりに、即時で結果を取得することができなくなるというデメリットがありますが、今回のような日次で翻訳を実行するようなタスクでは即時性が求められないため、これを活用してコストを削減しました。また、タスクが非同期で処理されることで、レートリミットによるエラーも回避できています。

6. AIによる翻訳レビュー

生成された翻訳ファイルが正しいかどうかを、中国語も韓国語もネイティブではないエンジニアがレビューするのは現実的ではありません。そこで、翻訳に使用したClaudeとは別のAIによるコードレビューを翻訳ファイルに対して行い、文法や単語の使い方に問題がないかを検知させることにしました。具体的には、以前から導入していた CodeRabbit というAIコードレビュワーを使い、翻訳結果が記載されたPull Requestを自動でレビューさせています。これにより、翻訳品質の最終防衛ラインを設けています。

coderabbit.ai

今後の展望

この仕組みは現在ベータテストとしてお客様に提供しており、いただいたフィードバックを元にさらなる品質改善を進めています。

翻訳辞書の拡充: お客様からのフィードバックや、実際の利用状況を分析し、より多くのドメイン用語を辞書に追加していきます。
プロンプトの改善: より自然で正確な翻訳を引き出せるよう、継続的にプロンプトのチューニングを行っていきます。
画像内のテキスト翻訳: 幸いなことに、現在のkickflowにはテキストが埋め込まれた画像は全くありません。しかし、今後そのような画像アセットが登場した際には、画像認識と翻訳を組み合わせたアプローチも検討していく必要があります。