（このポストは 5/6 に投稿したオリジナルのポスト を AI 翻訳したものに加筆・修正をしています）
先日 Drupal Dev Days Athens 2026 に登壇し、年末から開発を進めていた RAG ベースの .po ファイル翻訳ツールについて発表しました。元々は日本の Drupal コミュニティ向けに開発を始めたのですが、開発を進めるうちに、日本のコミュニティだけに限定する必要はないと思い、多言語対応にしました。さらに、Drupal エコシステム以外でも役立つとも思い、より汎用的なツールへと拡張しました。
その結果完成したのが、 RAG-LLM Translator と呼ばれる、ややオーバーエンジニアリング気味な PoC です。
以下は セッション の要約です。セッションの様子は YouTube でも視聴でき、スライドは こちら からダウンロードできます。
アップデート: 2026-06-07 このイベント後、さまざまなリファクタリングや機能拡張を行ったため、Drupal Dev Days Athens にて発表した際の仕様は古いものです。最新バージョンは Github リポジトリから入手可能で、 6/29~30 の DrupalCamp Kortrijk (Belgium) にて登壇し、使用方法や新機能について発表予定です。
課題
2025 年の Drupalcon Nara のコントリビューションスプリントで、約 10 名が集まり、LLM を活用して Drupal の翻訳に掛かる負担を軽減する方法について議論しました。
翻訳は難しいものです。少なくとも英語から日本語、またはその逆の翻訳において、私はそう感じます。少し話が逸れますが、英文をオランダ語に翻訳するときは、翻訳というよりも変換に近い感覚を覚えます。この 2 つの言語は同じインド・ヨーロッパ語族に属するだけでなく、ゲルマン語派という同じグループにも属しています。その結果、これら 2 つの言語は同じ単語やフレーズを共有し、文法にも共通点があります。
一方、日本語と英語には根本的に共通点がありません。もし類似点を挙げるとすれば、約 150 年前から日本語に入り始めた英語の借用語くらいでしょう（しかも、その一部はすでに本来とは異なる意味やニュアンスで使われています）。
LLM 翻訳の一貫性
LLM はある言語から別の言語へと驚くほどうまく翻訳します。しかし、LLM 翻訳における主な課題は、一貫性です。
用語の使用
例えば、“publish” という単語はいくつかの異なる日本語に翻訳できます。そして Drupal の UI の文脈においては、“publish” は常に「掲載」と翻訳されるべきです。しかし、LLM はほぼ常にこれを「公開」と翻訳します（参考までに、私は 10 以上の異なるモデルを試したので、自信を持ってそう言えます）。プロンプトに用語集を含めることは可能ですが、無関係な情報が増えれば増えるほど、翻訳の質が低下する可能性が高くなります。また、利用するトークン数という観点からも、無駄に長いプロンプトは避けるべきです。
また、文脈によって単語の訳が変わることもあります。一見すると問題なく、文章も自然に読めますが、他の UI テキストと一貫性が保たれていないことが多く、その矛盾がユーザーを混乱させます。
解決策としての RAG-LLM Translator
RAG-LLM Translator は元々、日本の翻訳コミュニティで共有し、RAG を使用することで LLM による用語の統一性が向上するかどうかを評価するための PoC として開発されました。しかし、作っているうちにすっかり夢中になってしまい、最終的に多くの機能を追加することになりました。
品質
プレゼンテーションで示したように、この翻訳ツールには LLM-as-a-Judge 機能が備わっており、ランダム化されたブラインドテストを実行して、RAG を使った翻訳と使っていない翻訳を比較し、信頼水準 95%、誤差の範囲 +/-5% で評価します。
LLM-as-a-Judge によるレポートによると、RAG-LLM Translator によって生成された翻訳は、LLM のみを使用した翻訳と比較して一貫して高いスコアを記録しています。結果は プロジェクトの issue キュー のスレッドで公開されているので、興味があれば詳細な結果を確認できます。
その他の機能
前述の通り、様々な機能が付随しています。
カスタマイズ
言語ごとのプロンプト上書き機能
この翻訳ツールには、ja.md と generic.md という 2 つのデフォルトプロンプトが用意されており、対象言語が日本語以外の場合には後者が適用されます。ファイル命名規則 {lang code}.md に従って、対象言語用のカスタムプロンプトを追加できます。
用語集ジェネレーター
用語集がなくても問題ありません。既存の翻訳をベクター DB に取り込みコマンドを実行するだけで、用語集の候補リストを生成できます。おまけとして、特定の単語の翻訳方法に不一致がある場合もリストで見つけられるため、既存の翻訳をの改善にも役立ちます。
demo_prep.sh
このスクリプトは、システムのテスト実行に必要なすべてのファイルを簡単にダウンロードします。
RAG ファインチューニングヘルパー
この翻訳ツールの RAG は事前に調整されていますが、用途によっては適さない場合があります。また、用語集が大きくなるにつれて精度が下がる可能性があり、ファインチューニングが必要になります。この翻訳ツールにはファインチューニングヘルパーとしっかりとしたドキュメントが付属しているため、デフォルトのしきい値に縛られることはありません。
ポストプロセスフレームワーク
LLM は文字列のフォーマット規則を一貫して適用できないことがよくあります。例えば日本語では、可読性を高めるために、マルチバイト文字と「半角」ラテン文字の間に半角スペース を入れることが推奨されています。例を挙げましょう：「正しい URL を入力してください」（‘Please enter a correct URL’）という文では、URL という単語の前後にスペースが入っています。LLM にこのようなルールに従わせようと試みましたが、うまくいくこともいかないこともあるため、翻訳後の処理としてこのようなフォーマット処理を担当するポストプロセスフレームワークを追加しました。
このフレームワークはカスタムプラグインに対応しているため、言語に特定のフォーマットが必要な場合は、独自のルールを追加し、選択した対象言語で実行されるようにプラグインを設定できます。
終わりに
幸いセッションは好評で、翌日には BoF といくつかの個別セッションを開催し、6 名の参加者がローカル環境に翻訳ツールをセットアップして試せるようサポートしました。
その過程でいくつかのバグが見つかり、パッチの作成やドキュメントの更新へと繋がりました。素晴らしい機能リクエストもいくつかいただき、その一部はすでに実装されています。
翻訳ツールの開発はとても楽しく、それをコミュニティと共有できたことは光栄です。今後もツールをさらに改善していくことを楽しみにていると同時に、OSS 翻訳メインテイナーの負担軽減に役立つことを願っています。
最後に、Drupal Dev Days Athens のボランティアの方々には、イベントの前から最中、そして終了後も献身的にサポートしていただいたことに感謝したいと思います。間違いなく、私が参加した中で最高のイベントの一つでした！