こんにちは。くりなみです。
弊社では今年、AIと機械翻訳を用いたプロダクトの英訳に新たにチャレンジしました。
今回はその方法や成果、途中の学びを共有します。
きっかけ
これまで、回答画面などのエンドユーザーにご利用いただく機能は信頼できる翻訳パートナーさんのご協力を得て、多言語への対応を行っておりましたが、最近、お客様からより広い範囲でプロダクトを多言語で利用したいというご期待をいただくことが増え、管理画面を英語に対応させる方針で動き始めた時に、AIや機械翻訳を使った翻訳を検討し始めました。
まずは結果から
クオリティ
実際にお客様にご利用いただいてフィードバックをいただいたところ、
ほぼ自然であるとの評価をいただきました🙌
ただ今回はフィードバックをいただいたお客様が必ずしも英語ネイティブの方ではないので、その方の第一言語や英語への精通度等によって感じ方は変わるかと思いますが、基本的にはプロダクトの操作に困るようなことはなさそうです。
今回は対象が管理画面で、何度もユーザーテストを行い、このクオリティが必要十分であると実証できたのでこの方法で行いましたが、他の機能は引き続き翻訳パートナーさんにお力添えいただくところもたくさんあります。
ネイティブスピーカーのプロの翻訳者さんしかできないこと
UI/UXを踏まえた翻訳
翻訳パートナーさんに翻訳をお願いする際は、プロダクトのUI/UX両方をご理解いただいた上で翻訳をしていただいているのですが、AIでは、どうしてもそこに書いている日本語に対する翻訳になりがちです。AIでも文脈をインプットしておけば十分翻訳できるとは思いますが、それなら翻訳パートナーさんにお願いした方が早いと思います。
もっとAIが発展して、プロダクトのソースコードをまるまるインプットしておけば、文脈まで勝手に理解してくれるようになれば、AIでも実現可能かもしれませんね。
その言語圏で文化的に理解しやすい・受け取りやすい翻訳
ちょっと何言ってるかわからないと思うので、GPTに考えてもらった例を挙げます。
「無効化する」の翻訳
背景: 「無効化する」を「Disable」と翻訳するのは一般的ですが、一部のユーザーにとっては「Disable」が否定的に感じられることがあります。特に「障害」や「不自由」を連想する場合があるため、感覚的に不快とされることがあります。
改善例: 「Turn Off」や「Deactivate」の方が柔らかく感じられる場合があります。
感覚の違い: 英語圏では否定的な言葉を避け、できるだけニュートラルで優しい表現を選ぶ傾向があります。
言われてみれば、"Turn Off"って英語のプロダクトでよく見るかもって思いませんか？こういったことに配慮した結果の表現だったのかもしれません。
言葉として間違ってはないし全然意味もわかるんだけど、「なんかしっくりこない」とか「私ならそう言わない」みたいな世界になってくると、AIでも限界があります。
コスト
コストは驚異的でした！
翻訳パートナーさんにお願いした場合の90％以上の削減を実現しました🎉
1/10以下のコストで翻訳できてしまうわけです。弊社では、私たちが知る限り最高基準の翻訳をしていただける翻訳パートナーさんにお願いしているため、翻訳費用が相対的に特に大きく削減できたのかもしれません。また、社内で実施することで、詳細な意味や解釈のすり合わせにかかるコミュニケーションコストが大幅に削減されたのも大きかったように思います。
その上で、何度も翻訳手順に試行錯誤を重ねた結果なので、後述の翻訳手順をぜひ参考にしてみてください🙌
ここで浮いた工数や期間を他に回すことで、さらにお客様に提供する価値を高められたり、提供スピードを早くできるので、全体として提供できる価値は高まるのではないかと考えています。
デリバリー
ここは厳密に測れていた訳ではありませんが、半分以下の期間で翻訳を完了することができました🎊これは非常に嬉しい🙌
今回は翻訳専属の人がいたのではなく、私が他と並行しながら翻訳しましたが、それでも50％以下でした。
このデリバリーの短縮は、新機能のリリースのような状況でももちろん最高ですが、エラーメッセージのちょっとした改善のような、翻訳の分量が少ない時にも非常にプラスです。
翻訳パートナーさんに依頼すると、納品までの期間も最低でも数日はかかりますし、そこに翻訳コスト、コミュニケーションコスト、経費管理コストなどが加わってきますが、社内の場合は
「これよろしく！」→2,3分後→「ほい！できた！」
みたいなことがよく起こります。
私がうっかりして遅くなることもありますが。笑
副産物
日本語のUI文言の改善が増えた
これはすごく面白い発見だったのですが、英訳していて、「なんかこの英訳変だぞ」っていう時は、日本語自体がまわりくどい表現や曖昧な表現をしていることが多く、「これはそもそも日本語から変えよう！」という動きがすごく増えたように思います。人間にとってわかりにくい表現はAIにとってもわかりにくいようです。
翻訳ツールと手順
選んだツールと検討した翻訳方法
最終的に今はChat GPTのGPTsとDeepL Pro APIの併用に落ち着いています。
必要なクオリティを満たす中で、一番コストやデリバリーの負担が少ない方法でした。
柔軟に考えるために、お客様にお手元でGoogle翻訳で画面翻訳していただくという一番ライトな方法から、翻訳パートナーさんにお願いするという方法まで、できる限り多くアイデアを出し、複数の国のお客様や英語ネイティブの社員にテストにご協力いただき、検証しました。
DeepL Pro APIの特徴
- クオリティ
- 用語集が登録できる
- 文章の翻訳の精度が高い（プロダクトのボタンの文言より、ヘルプサイトの文章の翻訳の方がうまい）
- 言語数は限られている
- 意訳や短い表現の翻訳はあまり強くない（でも面白い）
- 曜日を表現する（土）を(Turkish)と返してくれたときは非常に笑わせていただきました、こういうの好きですw
- コスト
- 大量の文言でもスプシで一気に翻訳できる
- 比較的安価に利用可能
Chat GPTのGPTsの特徴
- クオリティ
- 利用シーンに合わせた翻訳をしてくれる（DeepLが苦手とするボタンの短い文言なんかもできる）
- 意訳もお手のもの
- 意訳する能力を使って、たまに2文を1文にまとめて要約されたりするので、コントロールが必要（特に仕様について厳密に説明したいときは本当に困る）
- もちろん用語集もプロンプトに入れておけば登録できるが、プロンプトの文字数制限があり、量によっては全部は登録できない
- コスト
- （普段からGPTを契約していれば）追加のコストがかからない
- 用途に合わせて使える分、より詳細なカスタマイズが必要でプロンプトを作成するまでは労力がかかる
- 一度プロンプトが完成すれば、実際に翻訳をするときは日本語の文言を投げるだけで全部勝手に処理してくれるので非常に楽
2つのサービスを併用する理由
上記を読んで、「GPTだけで良いじゃん」と思ったかもしれません。
GPTだけでもクオリティとしては良いのですが、GPTだけ、もしくはDeepLだけだと「GPTはAと言ってるけど、どの程度信じていいかわからないから調べよう」と思ってしまい、すごく時間がかかったため、英訳の精度に加え、人間に根拠が伝わる答え方が必要でした。
イメージ
- GPTのみ
- GPT 「Aがいいよ！理由はね〜」
- GPTとDeepLの併用
- GPT 「Aがいいよ！」
- DeepL「Bがいいよ！」
- GPT 「AとB比較して、Aが適切だと思うんだ。理由はね〜」
あえてDeepLの追加コストを許容し、より大きな人件費を削減しています。
翻訳手順
ここではプロダクトの翻訳手順を記載しますが、ヘルプサイトも同じような手順です。
- DeepLが翻訳
- GPTが翻訳（1と2は順不同）
- GPTに2つの英訳を比較させ、より良い方を選ばせるor別のより良い英訳を提案させる
- 人間が全てレビューする
- プロダクトに反映
- 画面上でチェック
特に重要な手順
3 英訳比較
初期はなかったこの工程を足したことで、圧倒的に効率が良くなりました。具体的にGPTにしてもらっていることは適切な英訳の選択or提案と、その判断理由の記載です。
英訳はGPTやDeepLがするとはいえ、最終は4で人間が大量に英訳をレビューすることになるので、どのレベルでチェックするのか（さらっとか血眼か）をGPTが提示してくれるだけでもかかる時間と使う頭を非常に軽減できました。
- 両方の英訳が完全一致→高確率で正しい英訳なので軽くチェック
- どちらかの英訳が適切→英訳のチェックとその根拠の確認
- より良い英訳を提案→どちらの英訳も適切ではなかったということなので血眼チェック＆場合によっては人間が英訳
6 画面上でチェック
英訳のレビューは4ですでに行っているので、英訳としては合っているのですが、実際に画面上で確認すると意外とニュアンスが違ったり、名詞と動詞の使い分けがミスっているということがあるので、弊社では画面上でのチェックも重ねて行っています。
英訳する人に求められる要件は？
- 中学レベルの英語がある程度わかる
- 特に否定形がわかる（"It's nice"と"It's not nice"の違いがわかる）
- 最後まで責任を持って実行できる
- 大量に翻訳することになるので英語に苦手意識がない人の方が辛い思いをしない
- 英語ができればできるほど判断は早い
今まで何万文字も英訳してきて、中学英語レベルより難しいものに出会った記憶はありません。一番難しい文法で、"どうのこうの, which is 〜" ぐらい。もしこれより難しい文法を活用していたら、きっと日本語が非常に難解なので、日本語を見直してください。
「否定形がわかる」というところだけ具体的に書いているのは、ここがわからないと文章の意味が180度変わってしまう、かつ、ちょこちょここの翻訳ミスが起こるからです。
例えば「〜を指定しない設定はしないでください」という二重否定の文章は、文章のわかりにくさによっては「〜を指定しないでください」という意味に翻訳されてしまうことがあります。こういうのはそもそも日本語からわかりやすくするべきですが、英訳のレビューで気づけないと大変です。
それ以外は、語彙力がなくてもGPTに質問すればニュアンスまで細かく丁寧に教えてくれるので、「わかんないからこれでいっか」と無責任になってしまわなければ、あまり英語力は関係ないんじゃないかと思っています。忍耐力の方が大事。
ちなみに、この業務を始めて最初の方は英語力の伸びを感じていたのですが、英訳方法が洗練されるほど、人間が考えることが減るので、英語力は上がらなくなりました。笑
関係者の合意を得る
AIや機械翻訳を利用するか否かは、事業の状況や会社の文化などさまざまなものに依存するかと思います。
弊社の場合は、トップが新しい挑戦に明るいので苦労はありませんでしたが、それでも関係者で「じゃあどこまでこの方法でやるの？」「今度リリースするこの機能はどうする？」という話は度々上がりました。
それを解決した方法は2つです。
- 開発チーム内
- 翻訳対象ごとに、求めるクオリティとそれを満たす方法を一覧化し、関係者で認識を合わせ、合意を得る
- 開発チーム外（関連部署）
- 開発組織内の基準の一覧化をベースに説明した上で、実際にデモを見せたり、ユーザーテストで使えることを実証することで信頼してもらう
ユーザーテストの重要性はご存知だと思うので、ここでは求めるクオリティ等の一覧化を説明します。
対象ごとに翻訳に求める基準とそれを満たす方法を定める
それぞれの機能や画面に求める翻訳クオリティは違いますし、基準によって方法も変わります。そのため、表のように、翻訳クオリティに対して、以下のような変数を盛り込んで、一覧化し、関係者と認識合わせを行っています。
- プロダクトや機能の性質
- ユーザーロール
- 実現方法
- 言語
例えばこんな感じ
※内容は実際に弊社内で運用しているものではありません。
| 翻訳クオリティ | 具体例 | 対象機能 | 実現方法 |
|---|---|---|---|
| ニュアンスまで完全に一致している | ー | 解釈が一致する必要がある重要な文言、契約書 | 翻訳パートナーさんにお願いした上で、社内でチェックし細かくすり合わせ |
| 自然でその言語圏の考え方に沿った表現 | Disableを使わない | エンドユーザー向けの比較的シンプルなヘルプ記事 | 翻訳パートナーさんにお願いして軽くチェック |
| … | … | … | … |
| 間違ってはないけどわかりにくい | 「次へ」が"next"や"OK"ではなく"to the next"になっている | β版で操作ミスが起きても問題ないミニゲーム | DeepLのみ |
| 間違っている | （土）が(Turkish)になっている | なし | DeepLのみ |
具体例は変数ではないのですが、翻訳クオリティで書いている抽象的な粒度だと認識がズレることが多いので、具体例まで書くのがおすすめです。
また、上記の表には言語の変数を含んでいませんが、同じ翻訳クオリティでも、英語ではDeepLで実現できて、タイ語では翻訳パートナーさんが必要、など、言語によって実現方法も変わってきます。
おわりに
プロセスを構築するまではちょっと大変ですが、困ったポイントは全てこの記事に詰め込んだので、興味があればぜひチャレンジしてみてくださいね🥳
もし疑問点やより詳しい情報が必要な場合はコメント等でお知らせください👋