本記事は提供記事です。

海外向けのWebサイトやアプリを日本語にするとき、「翻訳」と「ローカライズ」は同じ意味で使われることがあります。実務では、この2つを分けて考えたほうが抜けを見つけやすくなります。
翻訳は意味を別の言語へ移す作業です。ローカライズは、その訳文を含むページやサービス全体を、日本の利用者が自然に使える状態へ整える作業。日本語では、文体、フォーム、改行、検索語、表示ルールまで確認対象が広がります。

翻訳・ローカライズ・国際化を分ける

「Your order has been shipped.」を「ご注文の商品を発送しました」とするのは翻訳です。日付や通貨、問い合わせ先、ボタンまで日本向けに調整するなら、ローカライズまで含みます。W3Cも、ローカライズを特定市場の言語・文化・その他の要件に合わせる作業と説明しています。
さらに手前にあるのが国際化（internationalization / i18n）。文字列をコードから分ける、Unicodeを扱えるようにする、日付や通貨を地域ごとに切り替えられるようにする、といった翻訳前の設計です。

日本語版は文体から決める
日本語では、同じ内容でも「利用できます」と「ご利用いただけます」で印象が変わります。複数人で作業するなら、個別の訳語より先に文体と敬語のレベルを決めます。
敬体か常体か、利用者を「お客様」「ユーザー」のどちらで呼ぶか、一人称をどうするか、カタカナ語をどこまで残すか。既存サイトがあるなら、その書き方を基準にするのが自然です。
英語の「you」を毎回「あなた」と訳す必要もありません。主語を落としたほうが自然な場面は多く、ここが最初の分岐点。

日付と通貨は更新方法まで考える
「09/10/2026」は、米国式なら2026年9月10日、日/月/年の地域では2026年10月9日と読めます。日本語版なら「2026年9月10日」のように書けば迷いません。
US$50を円に換算して載せる場合は、使った為替レートと取得日も管理します。更新しにくいページなら、古くなる換算額を固定するよりUS$50のまま残す判断もあるでしょう。

フォームは日本の入力方法に合わせる
英語圏向けのフォームは、文章だけ訳しても使いやすくなりません。氏名の順序、フリガナの要否、7桁の郵便番号、住所の並び、電話番号の形式まで見直します。
必須項目の記号やエラーメッセージも本文と同じ文体にそろえます。郵便番号から住所を補完する機能を使うかなど、実装側で決める項目もあります。
翻訳ファイルの外にある作業です。

表示幅は実画面で確認する
翻訳後の文字列は、原文と同じ幅にはなりません。W3CのText size in translationが紹介するIBMの目安では、10文字以下の短い英語文字列が欧州言語への翻訳で200〜300%に伸びる場合があります。
日本語は逆に文字数が減っても横幅が広がることがあります。同ページの「desktop」→「デスクトップ」は1文字少ないのに、表示にはより広い横幅が必要になる例です。
文字数だけ見ていても、ボタンの崩れは分かりません。

改行と疑似ローカライズも先に試す
日本語は単語間にスペースがないため、英語と同じ改行設定では見出しやボタンが不自然に折り返すことがあります。句読点やかぎかっこなどが不自然な位置に来ないよう、禁則処理やCSSの設定も確認します。
翻訳前なら疑似ローカライズも使えます。原文の文字列を機械的に長くしたテスト版を表示し、狭いボタンや固定幅の領域を先に探す方法です。
訳文が届いてから初めて「入らない」と気付くより、修正範囲を小さくできます。

用語集はCATツールでも使う
「Save」「Open」「Free」のような短い文字列は、使われる場所が分からなければ自然な訳を決めにくいものです。翻訳者には原文だけでなく、画面キャプチャや文字列の用途も渡します。
用語集には「ユーザー／利用者」「ログイン／サインイン」、全角・半角、句読点、英字表記などを記録します。TradosやmemoQのようなCATツールでは、用語ベースをプロジェクトで参照しながら作業できます。
口頭ルールではなく、次の更新でも使える資料として残すのが前提。

検索語は検索結果で確かめる
英語キーワードを日本語に訳しただけでは、実際に検索される言葉になるとは限りません。候補が複数あるならGoogle Trendsで主要語の検索関心を比べ、各語をGoogleで検索して上位ページの種類を確認します。
既存サイトならSearch Consoleの検索クエリも材料です。訳語として自然でも、検索結果が別の意図で埋まっていれば狙う語を見直します。
多言語SEOとローカライズを同じ設計で扱う例として、こよみ筒元のプロフィールでは、両方が担当領域として紹介されています。

日本語版のURLとhreflangをそろえる
Google Search Centralは、言語・地域別のページをGoogleに伝える方法としてhreflangを案内しています。各言語版は自分自身と他の言語版を列挙し、対応するページ同士を相互参照させます。
地域指定は必要な場合だけ追加します。日本語話者全体向けならjaだけで構いません。対応していない言語向けのフォールバックページがある場合は、x-defaultの利用も検討できます。
URL、内部リンク、サイトマップの対応まで一貫させて確認します。

AI下訳は人の確認を前提にする
AIは大量の文章を下訳するには便利ですが、そのまま公開できるとは限りません。Microsoftの解説も、AI翻訳には人による十分な評価が必要で、LLMが原文にない内容を生成する可能性があるとしています。
固有名詞、数字、用語を原文と照合したあと、日本語だけを読んで文体と意味が自然かを確認します。モデルを更新した後のスポットチェックも必要になるでしょう。

品質管理と工数は工程で考える
翻訳、レビュー、SEO、実装、公開確認の担当を先に決めます。ISO 17100:2015は、品質の高い翻訳サービスに必要なプロセスや資源について要求事項を定めた国際規格です。一方、機械翻訳の生出力をポストエディットする工程は適用範囲外とされています。
同じ5,000文字でも、記事本文だけを訳す案件と、フォームやSEO、画面QAまで含む案件では作業量が違います。見積もりは翻訳文字数だけでなく、用語整理、レビュー、実装、QA、修正まで分けて考えます。

日本向け表示は法務確認も入れる
日本向けECなどで通信販売広告に該当するページでは、特定商取引法ガイドに沿って、販売条件や事業者情報などの表示を確認します。
「No.1」などの強調表示も、訳せばそのまま使えるわけではありません。消費者庁は、合理的な根拠に基づかず事実と異なるNo.1表示が、景品表示法上問題になり得ると説明しています。
原文の表現を日本語に置き換えるだけでなく、その表示を日本で出せるか。ここもローカライズの確認範囲です。

公開前は原稿ではなくページを見る
本文がきれいでも、画像内の英語、フォームの入力例、エラーメッセージ、自動返信メールだけが未対応ということがあります。最後の確認対象は、原稿ではなく実際のページ。