UIローカリゼーションプロセスを劇的に改善するRigiと機械翻訳の連携

2024-01-10 05:00（更新：2024-01-05 09:08）KIマーケティングチームRigi

言語(Language)のデジタル変革(DX)には、デジタルデータの変換や入出力を支援する柔軟なソリューションが不可欠です。本連載（計四回）では、多言語化を必要とするさまざまなシーンにおいて、LDX hubを活用して効率をアップさせるポイントを解説します。今回のテーマは、UIの翻訳です。

過去の記事
・（第一回）：数千ページを超えるPDFファイルを効率よく機械翻訳するコツ
・（第二回）：OpenAIとの連携によるLDX hubの可能性

目次[非表示]

1.画面を確認しながらUIローカライズができることの利点
2.ソフトウェアのローカライズに機械翻訳を活用できるのか
3.RigiとLDX hubを活用してUI翻訳の処理時間を20％短縮する方法

3.1.UI画面の設計変更を要するテスト作業を翻訳工程の前に実施する
3.2.機械翻訳後のテキストを人が修正することで翻訳作業の時間を短縮する
3.3.クエリの時間と品質保証にかかる時間を削減する
3.4.スクリーンショット一括取得で修正作業の手間を削減する
3.5.IDベースのローカリゼーションなのでアジャイルにも対応

4.LDX hub を使用したRigiへの機械翻訳の適用フロー
5.まとめ

画面を確認しながらUIローカライズができることの利点

まず、本稿の主役の一つ、Rigiについて紹介します。 Rigiとは、WebアプリケーションのUIを可視化することに特化したクラウドベースのプラットフォームです。

一般的に、Webアプリケーションまたはソフトウェアをローカライズするというと、画面項目（ユーザーインターフェイス、UI）の翻訳を思い浮かべるのではないでしょうか。しかし、ローカライズの対象には多くの場合、オンラインヘルプ、トレーニング教材、マーケティング資料、仕様説明書など多様な要素が含まれており、UI テキストは通常、翻訳対象テキスト全体のわずか5%前後しか発生しません。

その一方で、翻訳量がごくわずかであるからといって、その特徴を理解せずにUIの翻訳を開始してしまうと、見えないコスト（ソフトウェアローカリゼーションの隠れたコスト）や翻訳者が感じる課題（UI翻訳の不満と悩み～依頼者/翻訳者それぞれの視点から）を軽視してしまうだけでなく、安易に機械翻訳を利用してしまい、ユーザーからの大きなクレームへとつながってしまうことがあります。

たとえば、UIテキストをExcelファイルにエクスポートして翻訳を行う場合、翻訳者の目線では、以下のような課題が頻発しています。

画面内や前後の画面のUIテキストとの整合性を確保することが難しい
レイアウトや入力長などの制約に合わせて翻訳することができない
テキストがどこでどのように使われるのか確証がない（ボタン、メッセージなど）
上記のような情報不足により問い合わせや申し送りが増える

簡潔に言えば、コンテクスト（背景や場面）がわからないため正しく訳せないことが課題となっています。結果として、翻訳されたテキストを実際のUI画面で表示したときに、以下のような想定外の問題が発生します。

表示領域に対して訳文が長すぎるため、すべてのメッセージが表示されていない
同じ単語に対して複数の訳語が用いられており、UIテキストが統一されていない
翻訳そのものは正しいが、画面に適していない（メッセージテキストが対話調に訳されていない等）

翻訳する側にとっては限られた情報の中で最大限努力した結果だとしても、翻訳を依頼している側から見ればこれらは誤った訳文であり、修正する手間が発生します。

一般的に、翻訳に起因する問題が判明するのは翻訳後の画面テスト（言語テスト）時になってしまうため、修正のやり取りの多くは後工程になって発生します。また、UIテキストをExcelファイルにエクスポートして翻訳会社に発注している場合などは、修正対象のテキストがどの画面にあるのかわからないこともあり、照合作業にさらに手間がかかります。

こうしたケースにRigiを使用すると、画面を見ながら翻訳ができる上、UIテキストの翻訳に必要な機能が充実しているため、問題は一気に解決します。

画面のイメージを視覚的に確認しながら翻訳ができるため、翻訳の質が大きく向上する
IDベースで翻訳ができるため、差分や修正反映部分の照合がしやすい
問い合わせ（「クエリ」と呼ばれます）のやり取りをシステム内でできるため、
不明点の解決にかかる時間を短縮できる
全言語のスクリーンショットを1アクションで取得できるため、修正指示の工数が劇的に削減でき

ソフトウェアのローカライズに機械翻訳を活用できるのか

次に、本ブログの主題であるLDX hubとの連携について説明します。LDX hubは、言語サービスの課題を解決するのに役立つ豊富なサービスおよびアプリケーションとのAPI連携機能と、それらを組み合わせたプロセスの自動化機能を提供しています。

翻訳とコトバを変革するAPI群「LDX hub」｜機械翻訳・AIの有効活用言語データのデジタル変革を実現【LDX lab】 LDX hubは、自社システムと連携を検討中の企業や、言語サービスの開発に携わるのエンジニアの皆様に、言語の変換を制御するアプリケーションのハブとなるAPI群を提供するサービスです。 2,000通り以上の処理の組み合わせから、課題解決・活用/連携をサポートいたします。新しいAPI連携も継続して拡張し続けます。 LDX lab

サービスおよびアプリケーションを自由に組み合わせて連携させることができ、現在は2000通り以上の組み合わせで自動化が可能です。1つのドキュメントの入力を起点に、さまざまな変換･加工処理と機械翻訳を連鎖させて、ニーズに応じた多種多様な出力を得ることができます。RigiもLDX hubとAPI連携をしており、LDX hubの機械翻訳機能をUIテキスト翻訳に利用できます。

では、大前提として、UIテキストのローカリゼーションに機械翻訳を活用できるのでしょうか。UIテキストはボタンやプルダウンテキストなどの短い文字列であることが多いため、その翻訳は、適切な単語を当て込むような文字列の置き換えであることがほとんどです。一見、こうした置き換え作業は機械の方が得意なように見えますが、単語の訳には複数の可能性があり、機械では前後関係や背景情報、文脈を理解できないため、適切な訳語を充てられるとは限りません。

また、UIテキストの中でも、ボタン名には名詞句や体言止めのシンプルな翻訳が求められますが（「検索」「エラー」など）が、メッセージは対話調の訳語にしなければなりません（「検索してください」「エラーが発生しました」など）。機械翻訳ではこうした訳し分けもうまく処理してくれるとは限らないため、結局人による確認作業が発生します。

それでも翻訳のプロセスだけではなく、ローカリゼーションの全プロセスを眺めてみると、機械翻訳が役に立つ場面はあります。特に、ソフトウェアテストの工程では、ダミーテキストを入力して検証作業を効率化することができます。

ソフトウェア開発に関連するテストには様々なものがあります。開発工程ごとのテストや機能テスト、負荷や限界値を検証する性能テストもありますが、この中で、UIを確認しながら行うテストは、主に機能テストやユーザビリティテストです。意味を持たない「XXXXXX」などの文字列を入れてテストを実施することも可能ですが、現地の言葉が入っている方が、ユーザビリティの評価には役立ちます。たとえば、文字の大きさや文字列の長さ、記載内容の視認性を確認する目的であれば、機械翻訳で十分です。

また、プロトタイピング手法を何度も繰り返すようなソフトウェア開発では、何度もテストを繰り返すことになるため、低コストかつ時間もかからない機械翻訳を使うことには妥当性があります。
Rigiを使用すると、機械翻訳を適用したテスト画面を瞬時に表示することができるため、翻訳プロセスの前にユーザビリティテストや機能テストを実施することが可能です。これらのテストでは、UI画面の設計変更などを伴うことがあり、上流工程に立ち戻ることがあります。こうしたリスクを考慮すると、翻訳プロセスとは別に実施できると手戻りの時間を短縮できます。

RigiとLDX hubを活用してUI翻訳の処理時間を20％短縮する方法

約1000行程度のUI テキストを３言語に翻訳するプロジェクトを想定してみましょう。多言語への翻訳の場合、単一の言語のプロジェクトの場合より、管理のコストはその分上昇し、修正にかかる手間も増大します。Rigiを使用すると多言語プロジェクトもシステム内で一元管理できるため、プロジェクト管理や修正にかかる手間は削減できます。

このほかにもRigiと機械翻訳を併用することでリリースまでの期間を短縮できるコツがありますので、以下で説明します。

図1

UI画面の設計変更を要するテスト作業を翻訳工程の前に実施する

一般的には、翻訳後のテキストを画面に表示させてテストを実施するため、テスト工程の前に翻訳工程が発生します。ところが、Rigiを活用すると機械翻訳後のテキストをダミーテキストとしてテスト画面に表示した状態で確認することができるため、先にUIの視認性やユーザビリティのテスト、および機能面でのテストを実施することができます。これにより、UI画面の設計変更が発生した場合に、再度翻訳の依頼をかけるロスが発生しなくなります（図1の”７”の工程を削減できる）。

翻訳工程が終わった後にテストは必要になりますが、機能やユーザビリティの問題ではなく、翻訳やテキストに関する問題になるため、言語テストの工程でカバーすることができます（図2の”７”の工程）。

図2

機械翻訳後のテキストを人が修正することで翻訳作業の時間を短縮する

機械翻訳そのままの出力ではUIテキストの翻訳は完了できません。すでに述べたとおり、機械では前後関係や背景情報、文脈を理解できないため、適切な訳語を充てられるとは限らないからです。判断は、人間の得意分野です。画面を見ながら機械翻訳の出力結果を修正（ポストエディット）することで、最初から人手で翻訳する場合と比較して、コストと時間を低減できる場合があります。

クエリの時間と品質保証にかかる時間を削減する

前述したとおり、Rigiを使用すると、テスト画面を表示しながら翻訳したり機械翻訳を確認したりできるため、最終的な翻訳の質が向上し、後工程での修正の数が劇的に減ります。
また、システム内でクエリのやり取りができるため、不明事項のやり取りを簡略化できるだけでなく、原文の修正を開発元に依頼しなくてはいけない場合もシステム内で一元管理でき、対象箇所がどこにあるかを検索する時間も大幅に削減できます。

スクリーンショット一括取得で修正作業の手間を削減する

Rigiの大きな強みの一つに、スクリーンショットの一括取得があります。修正が必要な箇所を発見した場合に、一言語分のスクリーンショットを取得すると、その他の対象言語のスクリーンショットを一括で取得することができます。
画面がわかれば、Rigi上でその対象箇所を検索して修正することが容易なため、修正の指示はスクリーンショットのやり取りで完結します。

IDベースのローカリゼーションなのでアジャイルにも対応

Rigiは、UIテキストの翻訳に特化しているため、IDベースでUIテキストを管理しています。IDベースで管理することにより、並行して開発が発生しているときにも、修正や追加された行がどこであるかを瞬時に検出することができ、差分の管理も効率よく行うことができます。図示していたローカリゼーションのプロセスは、ウォーターフォール型の開発を想定していますが、アジャイル開発でこそ効果を発揮できるのがRigiの強みです。

このように、Rigiと機械翻訳を活用すると、ローカリゼーションにかかる合計作業時間が約20％（もしくはそれ以上）の短縮が見込めます。翻訳工程でのエラーが削減して、修正やコメントのやり取りも効率化できると、全関係者にメリットがあります。UIテキストのローカリゼーションにかかる時間を短縮したい方は、是非お試しください。

ブログ後半では、LDX hub を使用したRigiへの機械翻訳の適用フローについてガイダンスを記載しています。参考にしてください。