多言語対応とは？翻訳・ローカライズ・国際化を要件に落とす考え方

英語のページを作ったのに、問い合わせフォームの案内は日本語のまま。タイ語の料金表は読めるのに、金額がどの通貨なのか分からない。「多言語対応済み」という一言だけでは、読者が必要な仕事を終えられるか判断できません。

多言語対応とは、対象とする言語や地域の読者が、情報を理解し、必要な行動へ進めるようにする取り組みです。 翻訳は文章の意味を別の言語へ伝える作業、ローカライズは対象の言語・地域に合わせる調整、国際化はそうした調整を行いやすくする設計として分けると、依頼する範囲が具体的になります。

この記事は、多言語サイトの新設・改修を検討する企業の営業・広報・管理担当者向けです。特定の翻訳会社や制作方式の比較ではなく、社内で何を決め、どこを確かめれば「対応した」と説明できるかを扱います。以下の業務例と確認票は編集上の提案で、実在の顧客事例や、当サイトが提供する製品機能の実測結果ではありません。

この記事で分かることは、翻訳・ローカライズ・国際化の違い、対象と正本の決め方、日付・通貨・言語情報の扱い、表示・入力の確認、言語別の案内と受付、更新を続けるための条件です。

翻訳・ローカライズ・国際化は、何が違う？

文章を訳す作業と、使える状態にする作業を分ける

翻訳でまず確かめるのは、原文の意味や条件が別の言語でも正しく伝わるかです。商品の対応範囲、相談できる内容、申込条件などが変わってしまえば、自然な文章でも業務上の問題が残ります。何を元の情報として訳し、誰が内容を確かめるかを決めます。

ただし、文章の確認だけでは、ページ全体を利用できるとは限りません。訳したボタンが枠からはみ出す、日付の読み方が曖昧、電話番号に国番号がない、といった問題は、文章以外の設計や表示とも関係します。文章の正しさと、読者がその情報を使えるかを別々に確認する必要があります。

W3Cの説明では、ローカライズを、特定の対象市場の言語・文化などの要件に合うよう製品や文書内容を適応させることとして扱っています。本記事ではこの考え方に沿い、単なる訳文への置換と、対象地域での使い方に合わせる調整を区別します。

国際化は、言語を増やす前の設計でもある

国際化は、文化・地域・言語が異なる利用者に向けてローカライズしやすくするための設計・開発です。i18nという略称が使われます。翻訳の対象を分けて管理することや、日付などの表示方法を言語・地域に応じて選べるようにすることは、その検討事項の例です。

このため、国際化をしたことと、すべての文章を翻訳したことは同じではありません。後から言語を追加しやすい構造があっても、原稿、画像内の案内、フォームのエラー文、受付体制がまだ整っていなければ、その言語の公開準備は別に残ります。

反対に、一枚の案内を別の言語へ訳すことに、常に大きなシステム改修が必要なわけでもありません。必要な対応は対象物と使い方によって変わります。翻訳、地域向けの調整、設計変更のどこに作業があるかを分けると、必要以上に広い依頼や、見落とした作業を減らせます。

表は横にスクロールして比較できます。

「何言語あるか」だけを完了条件にしない

言語数は、公開するページの範囲を表す情報にはなります。しかし、見積依頼まで進めるか、更新内容がそろっているか、返信できるかまでは示しません。対応を説明するときは、対象の読者、対象の情報、行えること、残る制約を添えます。

例えば「英語・タイ語で会社案内を閲覧でき、相談の受付は英語で行う」と書けば、閲覧と言語別の受付が同じではないことが伝わります。読める言語と、個別のやり取りを行える言語を混同させない説明が、読者の次の判断にも役立ちます。

社内では、対象・正本・担当をどう決める？

国名ではなく、読者の仕事から対象を絞る

「タイ向け」「ベトナム向け」という地域名だけでは、誰が何を探すページなのかが決まりません。現地企業の購買担当者、現地拠点の採用応募者、日本語を使う駐在員では、必要な説明と次の行動が異なります。どの読者が何を判断できればよいかを、先に一文で書きます。

対象言語も、国と一対一に決めつけません。地域、読む人、業務で使う言語を分け、どの組合せを支援するか決めます。読者が使う言語について根拠がない場合は、国名から推測して確定せず、既存の取引や受付記録など、利用できる情報を適切な範囲で確認します。

最初の対象は、会社のすべての情報でなくても構いません。事業概要、対応する業務、相談前に必要な条件、問い合わせの入口など、読者の判断を支える単位に絞れます。ただし、一部だけを訳す場合は、どの先が別言語になるかを案内し、同じ言語で全行程が終わるように見せないことが大切です。

翻訳する前に、何が正しい情報かを確定する

日本語原稿が複数あり、価格表と営業資料で条件が違うままでは、翻訳者はどちらを採用すべきか判断できません。正本にする原稿、確認した版、対象となるページ、変更を決める担当者をそろえます。翻訳の上手下手を調べる前に、元の情報の不一致を解消します。

正本は必ず日本語でなければならない、という意味ではありません。現地で先に確定する営業時間や所在地などは、その情報を管理する部署を正本の担当にできます。項目ごとに情報の出所と更新責任を決め、各言語の担当者が独自の判断で条件を補わないようにします。

画像に入っている文章、配布資料、よくある質問、フォームの確認画面も対象一覧へ加えます。本文だけが新しい版で、添付資料に古い受付条件が残ると、読者はどちらを信じてよいか迷います。ページ単位だけでなく、同じ案内を載せる場所を結び付けて管理します。

短い状態名にも、業務上の意味を添えます。例えば、架空の相談管理で「受付済み」と「対応完了」を使うなら、受付しただけで回答や解決が終わったわけではありません。この区別を用語表へ書き、各言語の表現を確認します。単語だけを並べた翻訳依頼ではなく、その表示がどの処理段階を指すかを伝えると、案内と実際の仕事のずれを確認できます。

架空の企業で、対応範囲を一枚にする

ここでは、架空の機器メーカーが、海外の購買担当者から仕様の相談を受けたい場面を考えます。実在企業の導入例ではなく、要件の整理方法を示す編集上の例です。目標は「外国語の文章を増やす」ではなく、「対応できる機器の条件を理解し、必要事項を添えて相談できる」に置きます。

表は横にスクロールして比較できます。

この表は、特定の製品機能や契約上の役割分担を保証するものではありません。自社で決める部分、制作側へ確認する部分、現地の担当者が判断する部分を分けるための出発点です。制作方法そのものの比較は、多言語サイトの制作方法を参照し、ここでは方式を選ぶ前の要件をそろえます。

言語・日付・数値・通貨を、どう持ち分ける？

言語の選択と、表示の慣習を同じものにしない

「英語で表示する」という設定だけでは、日付の順序、数値の区切り、時刻の基準まで一意には決まりません。地域による慣習も関係します。言語と地域などに関わる設定の組合せは、一般にロケールと呼ばれます。対象の読者が誤解しない表記を選び、必要な情報を補います。

UnicodeのCLDRは、日付、数値、通貨など、言語や地域に応じた表示に使われるデータや仕組みの基盤を提供しています。ただし、こうしたデータを使うことと、会社の文章を適切に翻訳すること、提供条件を現地向けに決めることは別です。データの仕組みが自社の案内内容まで決めてくれるわけではありません。

言語情報は、人に見える切替ボタンだけでなく、ページを処理する仕組みにも関わります。W3CのHTML言語指定の説明を踏まえ、ページの言語を適切に示す設定も確認対象にします。国旗を置いたことだけで、文書の言語が正しく指定されたとは判断しません。

同じ数値でも、見せ方は変わる

本記事の制作では、AIがローカルのJavaScript実行環境で、固定の架空値を使って書式の違いを確認しました。実行日は2026年10月28日です。数値の元値は12345.67で、表示用の言語・地域設定だけを変えました。実在の取引金額や顧客の画面を調査したものではありません。

表は横にスクロールして比較できます。

この確認で変えたのは数値の書式です。同じ元値でも、区切り記号の使い方が異なります。表示された文字列を別の地域の読み方で取り込むと、元の意味を保てない可能性があるため、元データと表示用の文章を分ける設計を検討します。表の結果は、記録した実行環境と指定条件に対するもので、すべての端末での表示を保証しません。

数字に見える値が、すべて計算用の数値とも限りません。架空の部品番号「00123」は、識別に使う文字列として扱う必要があるかもしれません。価格と同じように整形して先頭のゼロを落とせば、元の識別方法を変えてしまいます。項目が金額、数量、識別番号、文章のどれなのかを整理し、見た目の共通性だけで保存や変換の方法を決めないことが大切です。

さらに通貨をTHBと明示して書式を設定しましたが、これも金額を別通貨へ換算した処理ではありません。MDNのIntl.NumberFormatの説明は、言語・地域に応じた数値表示や通貨書式を扱っています。通貨の見せ方、為替による換算、請求する通貨は別の判断として管理します。

同じ瞬間でも、日付が変わる境界を確認する

日時も、元の瞬間、表示する地域の時刻、読む人へ示す文章を分けます。架空の時点として、UTCの2026年10月30日18時30分を使い、グレゴリオ暦、同じ表示用ロケールを指定して、時刻の地域だけを変える確認を行いました。

表は横にスクロールして比較できます。

この表の日付は日・月・年の順です。同じなのは元の瞬間で、表示される日付と時刻は同じではありません。MDNのIntl.DateTimeFormatの説明をもとに、表示に使う地域や暦を明示して確認しました。ブラウザ画面、フォーム、予定通知、処理性能を検証した結果ではありません。

締切の案内なら「何月何日まで」だけでなく、基準とする地域や時刻を明確にすることが重要です。一方、誕生日や記念日のように、元から日付そのものを扱う項目は、締切の瞬間と同じ設計でよいとは限りません。項目が何を意味するデータなのかを決めてから、保存と表示の方法を相談します。

文字を訳した後、表示と入力の何を確かめる？

短い日本語に合わせた枠を、そのまま使わない

見出しやボタンの翻訳後は、文字数や改行位置が変わり得ます。日本語で一行に収まることを前提に枠を固定すると、別言語で文字が切れたり、隣の操作と重なったりする可能性があります。長い文字列、複数行、スマートフォンの狭い幅を含めて確認します。

文字を小さくして詰め込む前に、説明と操作名を分ける、余白や折返しを調整する、見出しの役割を確かめるといった方法を検討します。確定した条件を勝手に削って短くすることは避け、意味を保って読める形を探します。最終的な文章と実際の画面を組み合わせることが必要です。

文章を細かい単語へ分け、値や別の単語と機械的につなぐ設計にも注意します。語順や単位の置き方が変わる場合には、日本語の部品の順番を保ったままでは自然な案内を作れません。例えば、数量を含む完了メッセージは、文全体の意味を確認できる形で管理する方法を相談します。短い部品を訳せたことと、組合せた文章が正しいことは別の確認です。

フォントが表示できるか、文字同士が不自然に重ならないか、入力後の文字が欠けないかも対象です。特定の端末では正常だったという理由だけで、全言語・全端末の表示に合格したとは扱いません。どの言語、画面幅、操作、状態を確かめたかを記録し、未確認の範囲を分けます。

フォームは、項目名以外の文章も確認する

問い合わせの入力欄だけを訳しても、未入力時の案内、確認画面、完了画面、受付メールが別言語のままだと、読者は手続きが進んだか判断しにくくなります。入力を始めてから受付結果を確認するまで、読む文章と必要な操作を一覧にします。

氏名や住所、電話番号の項目も、日本の入力例だけを前提にしないことが大切です。例えば、海外の連絡先を受ける必要があるのに、日本国内の郵便番号や電話番号の形式だけに限定していないかを確認します。対象外の地域を受け付けない方針なら、入力エラーで初めて知らせるのではなく、案内の段階で条件を示します。

この確認で、本番の顧客情報を試しに送信する必要はありません。許可されたテスト方法と架空データを使い、外部への通知が発生する操作では送信先と影響を管理します。入力欄の見た目、保存された内容、実際の通知が届いた結果を別々に検証し、未実施を成功扱いしないようにします。

正常時と、迷ったときの状態を組にする

表は横にスクロールして比較できます。

言語を増やすたびにすべてを勘で確認するのではなく、代表的な画面と状態を決めて確認票へ残します。テスト用の文章で枠を確かめた段階と、確認済みの訳文を載せて検査した段階も区別します。仮の文章が表示できたことは、最終原稿の内容や読みやすさの合格を意味しません。

言語別のページと受付を、どうつなげる？

一つの訳文を、すべての地域へ当てはめない

同じ言語でも、提供するサービスや連絡先が地域によって違う場合があります。言葉を変える部分と、業務の条件が変わる部分を整理します。会社全体の方針として共通にする情報と、現地拠点の担当者が管理する情報を分けると、条件の違いを訳文の誤りとして扱いにくくなります。

逆に、地域を増やすたびに別々の内容を一から作ると、共通の仕様まで食い違う可能性があります。共通項目と地域別項目を識別し、何を変えてよいかを決めます。「現地らしくする」という曖昧な指示ではなく、対象読者、提供範囲、窓口など、違いの理由を説明できる単位へ分けます。

画像や記号も、見た目だけで選ばず、伝えたい意味と読者の理解を確認します。ある国や言語の読者全員に同じ好みがあると決めつけることは避けます。確認できていない文化的な評価や顧客反応を、理由らしく付け足して調整の正当性に使う必要もありません。

切替の先でも、読者の目的を保つ

あるサービスの説明から別の言語へ切り替えたとき、いつもトップページへ戻されると、同じ説明を探し直すことになります。対応する情報があるなら、その関係を設計します。対応ページがまだない場合は、利用できる別言語の案内や相談先を、読者が分かる形で示します。

リンク先の資料、予約ページ、問い合わせ窓口まで、どこで言語が変わるかを確認します。外部サービスの画面が自社の制御外なら、その範囲と利用可能な案内を分けて説明します。すべての画面が同じ言語になると保証できないまま、途中の境界を見せずに誘導しないようにします。

ページの言語指定、言語切替、検索に関わる設定は、それぞれ確認する対象が異なります。読者向けの切替ボタンが動いたことだけで、技術的な言語情報や検索上の設定まで完了したと説明しません。また、多言語ページを作ったことから検索登録や順位、問い合わせ数の増加を断定することもできません。

返信できる条件を、相談前に示す

ページを読む言語と、窓口が返信する言語を合わせて考えます。受付後に別言語での連絡が必要なら、相談前にその条件を伝えます。担当する部署、受付後の流れ、追加で必要な情報を示すと、読者も社内の担当者も、何をもって次の工程へ進めるか判断しやすくなります。

例えば、架空の企業がタイ語で事業案内を公開し、技術的な質問は英語で受ける場合を考えます。本文、問い合わせボタンの近く、受付案内で、その違いが矛盾していないかを確認します。「タイ語対応」という一言だけで、すべての商談をタイ語で進められるように見せないことが必要です。

返信時間や対応範囲を約束する場合も、実際の体制に基づいて決めます。多言語のページを作る作業者が、確認していない受付条件を補うものではありません。案内の翻訳と、約束できるサービス水準の判断を分け、どの言語でも同じ条件を伝えられるようにします。

原文が変わった後、各言語へどう届ける？

翻訳済みの印ではなく、元の版との対応を持つ

最初の公開時にそろっていた文章も、元の仕様や受付条件が変われば見直しが必要です。「翻訳済み」という状態だけでは、どの原稿を訳したのか分かりません。元の項目、元の版、言語別の原稿、確認状態、掲載先を結び付けます。

すべての文章を同時に更新できない場合は、変更の影響を判断する担当と、暫定的にどう案内するかを決めます。古い条件が残っていても日付だけを新しくする、未確認の訳文を確認済みとして公開する、といった扱いは避けます。元の変更内容と、読者が判断を誤る可能性を具体的に確認します。

更新の対象は、同じページの本文だけとは限りません。料金表、配布資料、画像の説明、フォーム、受付メールにも同じ条件があるなら、対応を追います。情報が重複している箇所を把握しておくことが、言語を増やした後の管理にも役立ちます。

例えば、架空の受付条件が変わったときは、変更項目と掲載先の対応表から対象を取り出します。英語の本文は改訂済みでも、タイ語の添付資料は確認中なら、その差を残します。管理上の言語コードやファイル名だけでは公開中の版が分からない場合、実際の掲載先と結び付く参照も必要です。自動連携を導入するかどうかとは別に、この対応関係を説明できることが更新管理の土台になります。

原稿・確認・掲載を別の工程として残す

表は横にスクロールして比較できます。

原稿を受け取ったこと、内容を確認したこと、サイトへ保存したこと、一般の読者が閲覧できたことは別の出来事です。外部への連絡や公開で結果が不明になった場合も、同じ処理を繰り返す前に実際の状態を読み取ります。次の担当者に、どの段階から再開すればよいかを渡せる記録にします。

最初から、すべての地域へ広げなくてもよい

小規模な運営なら、優先する読者と行動を絞り、必要な言語とページから始める選択があります。その場合も、将来の追加を考えずに文章や条件を画面へ埋め込むのか、別の言語へ展開しやすく管理するのかは検討できます。国際化は、初日から多くの言語を公開することと同じではありません。

まず、一つの相談導線について、原稿の正本、地域別の条件、言語別の表現、入力から受付までの確認、更新担当をそろえます。その範囲が運用できるかを確認し、不足を直してから広げると、次の言語で引き継ぐべき条件が明確になります。売上や作業時間の改善を保証する手順ではなく、未完の仕事を見える形で扱うための考え方です。

作業範囲を制作担当へ渡す際は、多言語サイト導入の進め方も参照できます。定義を理解した後に必要なのは、何をどこまで対応するかを決め、実際の読者の行動と更新の流れで確かめることです。

多言語対応についてよくある質問

翻訳したページがあれば、多言語対応済みといえますか？

何に対応したかを添えて説明するのが適切です。別言語で本文を読めることと、入力・受付・返信まで同じ言語で進められることは違います。対象の情報、行えること、残る制約を示し、確認していない範囲まで対応済みとしないようにします。

ローカライズは、文章を自然に直すことですか？

文章の調整も含みますが、それだけには限りません。対象地域に合わせた日付や連絡先、提供条件、表示や入力の扱いも検討事項です。どこを調整するかは、自社の読者と業務に合わせて決め、根拠のない文化的な決めつけは避けます。

国際化をすれば、自動的にすべての言語へ対応できますか？

できるとは限りません。国際化は、言語や地域に応じた調整をしやすくする設計です。実際の訳文、地域ごとの条件、表示の確認、受付体制の準備は別に必要になります。どの機能を使えるかも、採用する仕組みで個別に確認します。

通貨の表示を変えれば、海外向け価格も決まりますか？

決まりません。数値の書式や通貨記号の表示、為替換算、販売・請求する価格は別の作業です。記事内の固定値による確認も表示の書式を確かめただけで、実際の価格設定や換算、決済を実行したものではありません。

最初に何を制作担当へ渡せばよいですか？

対象読者、読者に進んでほしい行動、正本の原稿、地域ごとに異なる条件、言語別の確認・更新担当をまとめます。まだ決まっていない部分も分けて示すと、翻訳だけで済む作業と、設計・表示・運用の検討が必要な部分を相談しやすくなります。

自社に必要な「対応した状態」を一文にする

多言語対応は、言語の名前を増やすことだけが目的ではありません。誰が、どの情報を理解し、何を行えればよいかを決めるところから始まります。そのために翻訳、地域向けの調整、調整しやすい設計、受付と更新の担当を分けて考えます。

自社でどこまで対応すべきか整理したい場合は、多言語サイトの要件整理をご相談ください。対象読者と必要な行動、現在の原稿や更新方法をもとに、制作前に決める項目を具体化します。相談したい言語や地域と、現在使っている案内をそろえると、整理する範囲を話し合いやすくなります。

関連記事・出典・確認日

• 多言語サイトの制作方法比較：依頼先や制作方式の判断へ進む記事です。
• 多言語サイト導入の進め方：作業範囲と進行の整理を扱います。
• W3C：Localization vs. Internationalization：ローカライズと国際化の考え方を参照しました。
• W3C：Declaring language in HTML：文書の言語指定の説明を参照しました。
• Unicode CLDR：言語・地域の表示に使うデータの役割を参照しました。
• MDN：Intl.NumberFormat：数値と通貨書式を確認しました。
• MDN：Intl.DateTimeFormat：日時の書式と時刻の地域を確認しました。

運営・編集：タゲンゴ。公式資料の確認日：2026年10月28日。固定の架空値による確認はローカル実行環境の書式処理に限り、実際の顧客、取引、製品画面、翻訳品質、ブラウザ表示、処理性能、集客成果を検証したものではありません。