Web多言語化対応の最適な「考え方」

なぜ必要？ 誰に向けて用意する？

「Webサイトの多言語化」をするにあたり、出発点は「なぜ」やるのか、です。Webサイトの規模、サイトを運営する組織や企業の規模の大小にかかわらず必要なのは、「なぜ」という目的の整理です。ここをはっきりさせましょう。

多言語化を突き詰めると、英語だけではない、中国語も？ 他の言語は？となります。目的に即してターゲットを明確化できると、対応言語の見通しが立っていきます。

私が所属するWovn Technologies（以下Wovn）は、これらを「Webの外国人戦略」と称しています。まず着目してほしいのが、“外国人”と言っても、一括りにできないこと。インバウンド向けを念頭に置いた、旅行などで日本に遊びに来る訪日外国人のほかに、もともと日本に滞在する（けれど日本語が苦手な）在日外国人、現地に滞在する在外外国人と、大別して3種類あり、それぞれ対策に違いも出ます（01）。

在外外国人向けだと、メーカーの海外展開や越境EC対策。一般の暮らしに根づく在日外国人向けだと、国内のサービスインフラにかかわるサイトがその対象になります。インバウンドと呼ばれる旅行者には、単に訳すのではなく観光客向けの情報へとアレンジしていないと、機会損失を招きます。

違和感のない状態は、翻訳だけではつくれない

「なぜ」については、個人ブログの翻訳という規模から企業の海外戦略という規模まで、幅広いでしょう。となると、「翻訳」や「多言語化対応」という言葉だと、取り組むべき範囲を誤解しかねません。それらの問題を含んだWebサイトのローカライズ（外国人向けの最適化）と考えるべきです。

すると、上図02の「なぜ（Why）」「何を（What）」「どのように（How）」という順番での対応が見えてきます。

「なぜ」で前述のターゲットと目的を洗い出したら、01の背景（言語／文化／システム）を踏まえる必要性が見えてきます。そこで次の「何を」へ。ここで5つの課題が待ち受けています（P058、03）。

1つ目が「翻訳」。多くの人が真っ先に気になるところでしょう。

主に機械翻訳か人力翻訳か。予算や翻訳のボリュームなどで適宜判断していきます。最近の潮流では、MTPE（マシントランスレーションポストエディット）という方法が定着しつつあります。機械翻訳でベースの「下書き」をつくる考え方で、下書き段階以降に人力で細かく調整すれば、ゼロから人力翻訳するより時間と手間が軽減できます。

機械翻訳の精度が高まっている背景があるので、ボリュームが多いほど人力だけで進めるのはコストも時間も現実的ではなくなります。ゼロから人力で進めるより、タイピングミス、スペルのミスが軽減できるメリットもあります。

あとは下書きに、翻訳のための「用語集」を加えられると、さらに精度が高まります。企業、メーカーの商品名など固有名詞の対訳を、あらかじめサイト運営者側が定義してリスト化しておきます。下書きにリストを照合できれば、固有名詞が出てきても訳が一定します。ほかにもよく出てくる表現に対して、決まった表記をリスト化するのも手です。

それらを翻訳用語集として一元管理できれば、Webサイトのほかにアプリやメール、オフラインなど別の発信源の多言語化対応にも随時利用できます。

外国人最適化のUXへ翻訳以外も気をつけよう

多言語化対応を考える場合、もっとも「翻訳」が気になるでしょうが、翻訳以外にも重要な課題があります。残るは4つ。中でも見落とされがちなのが「Webデザイン」です。既存サイトを翻訳するだけで満足していませんか？ 綺麗に翻訳できても、日本語だと収まっていたレイアウトが他の言語では収まらず、レイアウトが崩れる可能性があります。翻訳にあわせてレイアウトを調整してください。フォントは言語にあった最適なフォントに変えて、サイズの調整も忘れずに。また、ロゴを含めた画像も同様です。対象の国や地域、ユーザーにあわせて変える準備もします。さらにブラウザ別、デバイス別で通常どおりの表示かどうかの確認も必須です。

「通信」は、サーバを置いている場所次第です。国内サーバを使う人が大半でしょうが、訪問ユーザーは日本から遠く離れた国からのアクセスの可能性があります。容量の大きいWebサイトだと余計につながりづらいユーザーが出てきます。備えとしては、CDN（コンテンツ・デリバリー・ネットワーク）を利用して場所のリスクを回避する。もしくは、翻訳量を限定的にする手があります。

「データ解析」や「SEO」は、翻訳言語で検索エンジンを使い、その結果を確認しましょう。言語別でのアクセス解析も必要です。例えば、来期の予算を絞らないといけない場合、ある外国語について、解析結果で想定通りの来訪者数があれば引き続き予算を確保していいでしょうし、来訪者数が少ないなら、来期からその外国語対応を控えて予算を浮かせる判断もできるでしょう。

「運用」で気をつけたいことの1つは、自社サイトで出てくる用語が一定しているかどうか。用語データは資産化するようにしたいです。もう1つが適時性です。特に動的サイトやECサイトなど日々数多くのボリュームを抱えていても、継続的に情報提供できるかどうかです（03）。

仕組みやボリュームの違いで解決策を変えていく

最終アプローチがHow（どのように対応するか）です。厳密には、業種業態別、規模の大小、サイトの種類（コーポレートサイトなのかECサイトなのかなど）によって対応方法は細分化されます。1万以上Wovnで手がけた、あらゆる業種業態のメディアサイトやECサイト、コーポレートサイトなどの中で、導いた分類が図04です。

自社がどのサイトに該当するかを確認しましょう。サイトが静的か動的か、ボリュームが多いか少ないかで分けることができます。動的（日常的に更新）で大量ページを持つという組み合わせは、ECサイトや各種メディアサイトが挙げられます。人力翻訳だけでは更新が間に合わず、量に対応できず、何よりコストがかさむばかり。この場合は精度の高い機械翻訳をベースに、オペレーションの自動化が解決の第一歩です。

動的で量が少ないケースはクラウド、SaaSサービスです。例えば、勤怠管理や経費精算などの社内システムが該当します。日本語固有の項目（静的エリア）をいかに正確に翻訳できるか。翻訳ボリュームがない分、予算をかけて対応し、翻訳した項目名はデータベース化します。動的な箇所があれば、中身にあわせて機械翻訳か人力翻訳かを判断します。

コーポレートサイトやIRページは変更の生じないエリアです。重点的に考える国や地域を中心に多言語化対応を丁寧に進めましょう。対外的に出すので固有名詞の対応のほか、URLも言語ごとで見映えする並びを検討します。

もろもろを進めた仕上がりの段階で、どう中身を判断すべきか？ ダブルチェック体制を推奨します。中国語を知らない人が中国語翻訳の中身や精度は確認できずとも、体制内の調整ならできそうです。実際に翻訳した人とは別に、中国語が確認できる人をアサインします。サイト運営者は常にこうした局面の判断が求められるわけです（05）。