Webシステムを開発するとき、
「最初は日本向けだけだが、将来的には英語にも対応したい」
「海外拠点でも同じ業務システムを使いたい」
「日本語・英語・中国語でサービスを提供したい」
というケースがあります。
多言語対応というと、画面上の日本語を英語へ翻訳すればよいと思われがちです。
しかし実際には、
- 画面上の文言
- URL
- データベース
- 日付
- 時刻
- 通貨
- 数値
- メール
- エラーメッセージ
- 検索
- SEO
など、システム全体へ影響します。
結論からいうと、将来的に多言語対応する可能性があるWebシステムでは、最初から「言語によって変わるもの」と「言語に依存しないもの」を分離して設計することが重要です。
日本語の文字列をプログラムへ直接書き込んだり、商品名を日本語だけ保存したりしていると、後から多言語化するときに大幅な改修が必要になる可能性があります。
この記事では、多言語対応Webシステムを設計するときに考えたい、i18n、翻訳管理、データベース、URL、日時・通貨、メール、SEOなどのポイントを具体例とともに解説します。
Webシステムの多言語対応とは
Webシステムの多言語対応とは、単に表示言語を切り替えることではありません。
例えば日本語ユーザーには、
「顧客を登録する」
と表示し、英語ユーザーには、
「Add customer」
のように表示する必要があります。
しかし、多言語化する対象は画面文言だけではありません。
例えば、
日本語：
2026年7月31日
10,000円
英語圏向け：
July 31, 2026
¥10,000
のように、日時や数値の表示方法も地域によって変わります。
そのため、多言語対応では「翻訳」と「地域ごとの表示ルール」の両方を考える必要があります。
i18nとL10nの違い
多言語対応について調べると、i18nやL10nという言葉が出てきます。
i18nとは
Internationalization（国際化）の略です。
「Internationalization」の最初のiと最後のnの間に18文字あるため、i18nと表記されます。
意味としては、
複数言語・地域へ対応できるようにシステムの構造を設計すること
です。
例えば、
- 表示文言をコードから分離する
- 日時フォーマットを固定しない
- Unicodeに対応する
- 言語情報を管理する
といった設計です。
L10nとは
Localization（ローカライズ）の略です。
特定の国や地域向けに、
- 翻訳する
- 日付表記を変更する
- 通貨を変更する
- 表現を地域に合わせる
といった対応を行います。
つまり、
i18n
→ 多言語化できる構造を作る
L10n
→ 実際に各言語・地域へ対応する
という違いです。
Webシステム開発では、まずi18nを意識した設計にしておくことが重要です。
多言語対応で最初に決めたいこと
いきなり翻訳機能を実装するのではなく、まず対象範囲を整理します。
例えば、
- 日本語
- 英語
の2言語だけなのか、
将来的に、
- 中国語
- 韓国語
- フランス語
- ドイツ語
なども追加する可能性があるのかで設計が変わります。
さらに、
管理画面だけ多言語化する
海外拠点の社員が利用する。
一般ユーザー向け画面を多言語化する
海外顧客がサービスを利用する。
登録データ自体も多言語化する
商品名や説明文を言語別に登録する。
という違いがあります。
この3つは必要な実装が異なります。
多言語対応の対象を整理する
まず、システム内で言語によって変わる情報を洗い出します。
代表的には次のようなものがあります。
システム固定文言
- 保存
- キャンセル
- 検索
- 登録
- 編集
- 削除
- ログイン
メッセージ
- 保存しました
- 入力内容に誤りがあります
- データが見つかりません
- 権限がありません
業務データ
- 商品名
- 商品説明
- カテゴリ名
- お知らせ
- FAQ
通知
- メール
- プッシュ通知
- システム内通知
その他
- 日付
- 時刻
- 数値
- 通貨
- 単位
これらを「どこまで多言語化するのか」整理することが第一歩です。
設計ポイント1．画面文言をプログラムへ直接書かない
多言語対応で基本になるのが、表示文言をコードから分離することです。
例えば画面に、
保存
という日本語を直接記述するのではなく、
save_button
のようなキーを使います。
翻訳ファイルでは、
日本語：
save_button → 保存
英語：
save_button → Save
というように管理します。
画面側では、
save_button
を参照するだけにします。
これにより、言語を切り替えても同じプログラムを利用できます。
翻訳キーの命名も重要
翻訳キーを、
text1
text2
のようにすると、後から意味が分からなくなります。
例えば、
customer.create.title
customer.create.submit
customer.delete.confirm
のように、画面・機能・用途が分かる形にすると管理しやすくなります。
多言語化では翻訳文そのものだけでなく、翻訳資産を長期間管理できる構造が重要です。
設計ポイント2．文章を細かく分割しすぎない
翻訳ファイルを作るとき、
「こんにちは」
「さん」
を別々の翻訳キーにして、
こんにちは + 山田 + さん
のように組み立てると、他言語では自然な文章にならない場合があります。
言語によって語順が異なるからです。
そのため、
こんにちは、{name}さん
のように、一つの文章として管理する方法が適しています。
英語なら、
Hello, {name}.
のように翻訳できます。
日本語の語順を前提にプログラムを組むのではなく、各言語で自然な文章を作れる構造にします。
設計ポイント3．言語と地域を分けて考える
「英語」という情報だけでは足りない場合があります。
例えば同じ英語でも、
- アメリカ
- イギリス
- オーストラリア
などで、日付や通貨などが異なります。
そこで、
ja-JP
en-US
en-GB
のようなlocale（ロケール）を利用します。
localeとは、言語や地域を表す情報です。
例えば、
ja-JP
→ 日本語・日本
en-US
→ 英語・アメリカ
という意味です。
Webシステムでは単純なlanguageだけでなく、必要に応じてlocaleを管理すると拡張しやすくなります。
設計ポイント4．ユーザーごとの言語設定を持たせる
ログイン型Webシステムでは、ユーザーごとに表示言語を設定できるようにする方法があります。
例えばusersテーブルに、
locale
を持たせ、
山田さん
→ ja-JP
Johnさん
→ en-US
とします。
ログイン時にlocaleを取得し、それに応じて表示言語を決定します。
これにより、同じ会社のシステムを日本拠点と海外拠点で利用する場合にも対応できます。
言語をどう決定するか
言語の決定方法には複数あります。
例えば、
- ユーザーが設定した言語
- URLの言語
- ブラウザの言語設定
- システムのデフォルト言語
という優先順位にする方法があります。
例えば、
ユーザー設定
→ 英語
なら、ブラウザが日本語でも英語を表示します。
言語決定ルールを明確にしておくことが重要です。
設計ポイント5．URL設計を早い段階で決める
一般公開するWebサービスでは、URLの言語設計も重要です。
代表的には次の方式があります。
パスで分ける
example.com/ja/
example.com/en/
サブドメインで分ける
ja.example.com
en.example.com
ドメインで分ける
example.jp
example.com
Webサービスや企業サイトでは、
/ja/
/en/
のようにパスで分ける構成もよく検討されます。
URLへ言語情報を含めると、
- URLを共有しやすい
- 言語ごとのページを識別しやすい
- SEO対応を行いやすい
というメリットがあります。
ログイン後の業務システムではURLに言語を持たせない方法もある
例えば社内システムなら、
app.example.com/customers
へアクセスし、ユーザー設定から表示言語だけ変える方法もあります。
必ずしもすべてのWebシステムでURLを言語別にする必要はありません。
一般公開ページなのか、ログイン後の業務アプリなのかによって判断します。
設計ポイント6．DBの業務データをどう多言語化するか
多言語対応で難しくなりやすいのがデータベースです。
例えば商品管理システムに、
商品名：スタンダードプラン
というデータがあるとします。
英語ユーザーには、
Standard Plan
と表示したい場合があります。
この場合、データベース側で言語別データを管理する必要があります。
代表的な方法はいくつかあります。
方法1．言語ごとのカラムを持つ
例えば、
name_ja
name_en
というカラムを作ります。
メリット
- 構造が分かりやすい
- 小規模なら実装しやすい
デメリット
言語が増えるたびに、
name_zh
name_ko
name_fr
とカラムが増えます。
2〜3言語だけで固定されるシステムなら使える場合がありますが、多数の言語へ対応するサービスでは管理しにくくなります。
方法2．翻訳テーブルを分ける
例えば、
products
と、
product_translations
を分けます。
product_translationsには、
- product_id
- locale
- name
- description
などを保存します。
例えば、
商品ID：1
locale：ja-JP
name：スタンダードプラン
商品ID：1
locale：en-US
name：Standard Plan
という構造です。
この方式なら言語が増えてもテーブル構造を変更せずに追加できます。
多数の言語へ対応する可能性がある場合は検討しやすい方法です。
言語に依存しないデータは分けない
すべてを翻訳テーブルへ入れる必要はありません。
例えば商品なら、
- 商品ID
- 商品コード
- 価格
- 在庫数
などは言語によって変わりません。
一方、
- 商品名
- 商品説明
は変わります。
そのため、
products
→ 言語に依存しない情報
product_translations
→ 言語依存情報
という分離ができます。
これが多言語DB設計の基本的な考え方です。
設計ポイント7．UTF-8を前提にする
多言語対応では文字コードも重要です。
日本語だけでなく、
- 中国語
- 韓国語
- アラビア語
- 絵文字
などを扱う可能性があります。
現在のWebシステムではUTF-8を利用することが一般的です。
データベース・API・CSV出力などで文字コードがバラバラになると、
- 文字化け
- データ欠損
- CSVが正しく開けない
といった問題につながります。
システム全体で文字コードを統一しておくことが重要です。
設計ポイント8．日付・時刻は表示と保存を分ける
多言語・多地域システムでは、時刻設計も重要です。
例えば、
2026年7月31日 15:00
が、日本時間なのかアメリカ時間なのか分からなければ問題になります。
一般的には、システム内部ではUTCなど統一した基準で保存し、画面表示時にユーザーのタイムゾーンへ変換する設計があります。
例えば、
DB
→ UTC
日本ユーザー
→ Asia/Tokyo
アメリカユーザー
→ America/New_York
として表示します。
日付フォーマットを固定しない
日本では、
2026/07/31
という表示が自然です。
アメリカでは、
07/31/2026
などの表記があります。
地域によって形式が異なるため、
年 + “/” + 月 + “/” + 日
のように文字列を直接組み立てるのではなく、localeに応じたフォーマットを利用することが重要です。
設計ポイント9．通貨と数値の表示を分ける
例えば、
1000
という数値でも、
日本：
¥1,000
アメリカ：
$1,000.00
ヨーロッパの一部：
1.000,00 €
のように表示ルールが異なります。
そのため、
「金額という数値」
と、
「どう表示するか」
を分けて考えます。
DBへ、
“1,000円”
という文字列として保存してしまうと、多言語化しにくくなります。
例えば、
amount：1000
currency：JPY
として管理し、表示時にフォーマットする方法があります。
設計ポイント10．単位も固定文字列にしない
例えば、
10kg
5km
などの単位も、サービスの対象地域によって変わる可能性があります。
アメリカ市場では、
kg
→ lb
km
→ mile
などへの変換が必要になるサービスもあります。
単なる翻訳だけでなく、地域ごとの単位まで変更する可能性があるなら、データと表示単位を分離します。
設計ポイント11．入力フォームも多言語化を考える
表示だけではなく入力フォームにも注意が必要です。
例えば住所入力は、日本と海外で構造が異なります。
日本では、
- 郵便番号
- 都道府県
- 市区町村
- 番地
という構成があります。
海外では、
- Country
- State
- City
- ZIP Code
などが必要になります。
「日本向け住所フォームを英語へ翻訳するだけ」では適切でない場合があります。
多言語対応では、翻訳だけでなく業務・データ構造自体が地域によって異なる可能性を考えます。
設計ポイント12．バリデーションメッセージも翻訳する
入力エラーも多言語化対象です。
例えば、
メールアドレスを入力してください。
パスワードは8文字以上で入力してください。
というメッセージです。
フロントエンドだけでなく、バックエンドから返されるエラーも含めて翻訳を考える必要があります。
おすすめなのは、APIが日本語の文章そのものを返すのではなく、
EMAIL_REQUIRED
INVALID_PASSWORD
などのエラーコードを返し、画面側で適切な言語へ変換する方法です。
APIを複数のフロントエンドから利用する場合にも扱いやすくなります。
設計ポイント13．メール・通知も多言語対応する
見落とされやすいのがメールです。
例えばユーザー登録時に、
「登録が完了しました」
というメールを送信している場合、英語ユーザーには英語メールを送る必要があります。
対象には、
- アカウント登録
- パスワードリセット
- 契約完了
- 支払い完了
- 支払い失敗
- 通知メール
などがあります。
メールテンプレートも言語ごとに管理します。
メール生成時はユーザーの言語設定を確認する
画面表示中であれば現在のlocaleがあります。
しかし、バッチ処理で翌日にメールを送る場合、ブラウザの言語情報はありません。
そのため、
user.locale
などをDBへ保持しておくと便利です。
バックグラウンド処理でもユーザーに適した言語を判断できます。
設計ポイント14．管理画面の翻訳運用を考える
多言語コンテンツが多いサービスでは、開発者が翻訳ファイルを直接変更する運用だけでは大変になる場合があります。
例えばECサイトで、
- 商品名
- 商品説明
- FAQ
- お知らせ
を複数言語で管理する場合です。
管理画面で、
日本語
英語
中国語
の入力欄を用意する方法があります。
さらに、
- 未翻訳
- 翻訳済み
- レビュー待ち
- 公開済み
などのステータスを管理すると、翻訳業務そのものをワークフロー化できます。
設計ポイント15．機械翻訳をどう利用するか決める
現在はAIや機械翻訳を利用して、多言語コンテンツを生成することもできます。
例えば、
日本語の商品説明を登録
↓
AIで英語へ仮翻訳
↓
担当者が確認
↓
公開
という流れです。
ただし、
- 契約条件
- 法律関連
- 金融情報
- 医療情報
- 重要なUI
など、誤訳の影響が大きい内容では人による確認が必要になる場合があります。
AI翻訳を利用する場合も、
自動翻訳
↓
レビュー
↓
公開
という業務設計まで考えることが重要です。
設計ポイント16．検索機能も言語によって変わる
多言語化すると検索も難しくなる場合があります。
例えば商品名が、
日本語：
在庫管理システム
英語：
Inventory Management System
の場合です。
英語画面では英語の商品名を検索できる必要があります。
さらに、
- 大文字・小文字
- 全角・半角
- Unicode
- 言語ごとの単語区切り
なども検索結果へ影響します。
全文検索を導入する場合は、対象言語に対応できる検索方式か確認する必要があります。
設計ポイント17．RTL言語も将来的な対象なら考慮する
アラビア語やヘブライ語などでは、文章を右から左へ表示するRTL（Right-To-Left）が利用されます。
日本語や英語だけを想定したUIでは、
左側にアイコン
右側にテキスト
などを固定してしまうことがあります。
将来的にRTL言語へ対応するなら、レイアウト自体を反転できる設計が必要になる場合があります。
対象国が決まっている場合は、初期段階で確認しておきましょう。
多言語WebシステムではSEOも考える
一般公開するWebサイト・Webサービスの場合、多言語SEOも重要です。
例えば、
日本語：
example.com/ja/service
英語：
example.com/en/service
というページを作る場合です。
検索エンジンへ、
「これは同じ内容の日本語版・英語版です」
と適切に伝える必要があります。
多言語サイトでは、
- 言語ごとのURL
- canonical
- hreflang
- title
- meta description
- sitemap
などを言語別に整理します。
特に集客を目的とするサービスでは、翻訳だけでなく検索キーワード自体も国によって変わるため、単純な直訳だけではSEOが弱くなることがあります。
URLを自動的に強制転送しすぎない
例えばブラウザが英語だからといって、
/ja/
へアクセスしたユーザーを強制的に、
/en/
へリダイレクトすると、ユーザーが意図した言語を閲覧できなくなる場合があります。
言語を推測する仕組みと、ユーザーが明示的に選択した言語を分けることが重要です。
多言語対応をあとから追加すると大変になりやすい理由
最初から日本語専用で開発すると、システム内に日本語依存の実装が増えます。
例えば、
プログラム内：
“保存しました”
DB：
status = “対応中”
金額：
“10,000円”
日付：
“2026年7月31日”
のような状態です。
後から英語対応すると、
- コード
- DB
- API
- 画面
- メール
- CSV
をまとめて修正する必要が出てきます。
特に注意したいのが、DBの値そのものに日本語を利用することです。
ステータス値は言語に依存させない
例えば案件ステータスを、
対応中
完了
失注
としてDBへ直接保存するとします。
英語では、
In Progress
Completed
Lost
と表示したくなります。
そこでDBには、
IN_PROGRESS
COMPLETED
LOST
のような言語非依存の値を保存し、表示時に翻訳します。
日本語：
IN_PROGRESS
→ 対応中
英語：
IN_PROGRESS
→ In Progress
という構造です。
この考え方は、
- ステータス
- 種別
- 権限
- カテゴリ
- エラーコード
などでも重要です。
CSV・Excel出力の多言語対応も忘れない
業務システムでは、CSVやExcel出力が必要になることがあります。
例えば日本語ユーザーなら、
顧客名,契約日,ステータス
英語ユーザーなら、
Customer Name,Contract Date,Status
としたいケースがあります。
また、CSVを他システムへ連携する場合は、人間向けの翻訳済み値ではなく、固定コードを出力したほうがよいこともあります。
「画面表示用」と「システム連携用」を分けて設計することが重要です。
多言語対応Webシステムの具体例
法人向け案件管理SaaSを考えてみましょう。
日本企業
locale：
ja-JP
表示：
顧客
案件
商談中
保存
日時：
2026年7月31日 10:00
海外企業
locale：
en-US
表示：
Customers
Projects
In Progress
Save
日時：
July 31, 2026 10:00 AM
この場合、
ユーザー
↓
所属企業
↓
locale
↓
翻訳
↓
日時・数値フォーマット
という流れで表示を決定できます。
商品名やサービス名など業務データ自体も多言語化する場合は、別途翻訳テーブルを利用します。
【チェックリスト】多言語対応Webシステムの要件整理
多言語化を検討するときは、次の項目を整理してみてください。
対応言語
- 初期対応言語：
- 将来追加する可能性がある言語：
- 地域：
- RTL言語の有無：
対象画面
- 一般公開ページ：
- ログイン画面：
- 業務画面：
- 管理画面：
翻訳対象
- ボタン：
- メニュー：
- エラー：
- メール：
- 通知：
- 商品名：
- 商品説明：
- FAQ：
ユーザー設定
- ユーザーごとのlocale：
- ブラウザ言語：
- 言語切替：
- デフォルト言語：
データベース
- 言語依存データ：
- 翻訳テーブル：
- ステータスコード：
- UTF-8：
地域対応
- タイムゾーン：
- 日付：
- 時刻：
- 通貨：
- 数値：
- 単位：
外部出力
- メール：
- CSV：
- Excel：
- PDF：
- API：
公開サイト
- 言語別URL：
- hreflang：
- title：
- meta description：
- sitemap：
すべてを最初から実装する必要はありません。
しかし、将来的にどこまで多言語化する可能性があるのかを整理しておくだけでも、後からの改修コストを減らしやすくなります。
多言語対応Webシステムでよくある設計ミス
1．日本語をコードへ直接書く
画面文言が大量にコードへ埋め込まれていると、後からすべて探して翻訳する必要があります。
初期段階から翻訳キーへ分離しておくと拡張しやすくなります。
2．DBへ日本語のステータスを保存する
「対応中」など表示用文字列をそのまま内部値にすると、多言語化しにくくなります。
内部コードと表示文言を分離しましょう。
3．英語だけ追加して多言語対応完了と考える
日付、時刻、通貨、住所、メールなどにも地域差があります。
翻訳とローカライズを分けて考える必要があります。
4．商品名などの業務データを考えていない
画面の「保存」「キャンセル」だけ翻訳しても、商品名やFAQが日本語のままではサービス全体を多言語化できません。
固定UIとユーザー・管理者が登録するコンテンツは別に整理します。
5．翻訳文の長さを考えていない
英語にすると日本語よりボタンやメニューが長くなることがあります。
日本語で幅を固定してUIを作ると、
テキストがはみ出す
改行される
レイアウトが崩れる
といった問題が起こります。
一定の文字数変化を想定してUIを設計することが重要です。
6．バックエンドのエラーだけ日本語になる
フロントエンドは英語でも、
「登録に失敗しました」
という日本語エラーがAPIから返されるケースです。
APIのエラーコードと表示メッセージを分離しておくと対応しやすくなります。
7．翻訳がない場合の挙動を決めていない
例えば英語版の商品説明がまだ登録されていない場合、
- 日本語を表示する
- 空欄にする
- 非公開にする
などの選択肢があります。
fallback（代替表示）のルールを事前に決めておきましょう。
多言語対応Webシステムに関するよくある質問
Webシステムは後から多言語化できますか？
可能です。
ただし、画面文言やDBデータが日本語へ強く依存していると、大きな改修になることがあります。
将来的な多言語化が想定されるなら、初期設計からi18nを意識しておくほうが効率的です。
日本語と英語だけならDBにname_jaとname_enを作ってもよいですか？
対応言語が固定され、小規模なシステムなら選択肢になります。
一方、将来的に言語が増える可能性がある場合は、翻訳テーブルとして分離する方法が拡張しやすいでしょう。
Google翻訳やAIを使えば多言語化できますか？
翻訳作業の効率化には利用できます。
ただし、多言語Webシステムでは翻訳以外にも、DB設計、URL、日時、通貨、検索、メールなどを設計する必要があります。
多言語対応するならURLも分ける必要がありますか？
必須ではありません。
一般公開サイトで検索流入を獲得したい場合は、言語別URLを設計するメリットがあります。
ログイン後の社内システムでは、ユーザー設定だけで言語を切り替える構成もあります。
多言語化すると開発費は高くなりますか？
日本語だけのシステムより設計・テスト対象は増えます。
特に、言語数、翻訳対象、業務データの多言語化、地域固有処理によって開発規模が変わります。
どこまで対応するのかを要求整理の段階で決めることが重要です。
タイムゾーンも多言語対応と一緒に考えるべきですか？
海外ユーザーが利用する場合は重要です。
DB内部では統一した時刻基準で管理し、利用者のタイムゾーンに応じて表示を変える設計を検討します。
管理画面も多言語化する必要がありますか？
海外の運営担当者が利用するなら必要になる場合があります。
一方、日本国内の管理者しか使わないのであれば、ユーザー向け画面だけ多言語化する方法もあります。
hiro-dev-labでは多言語対応を見据えたWebシステム設計から相談できます
多言語対応Webシステムを開発するときは、
「日本語を英語へ翻訳する」
だけでは十分ではありません。
実際には、
画面文言
↓
ユーザーのlocale
↓
業務データ
↓
日時・通貨
↓
メール・通知
↓
URL・SEO
までシステム全体を整理する必要があります。
hiro-dev-labでは、Webシステム・業務システム開発の観点から、
- 業務ヒアリング
- 要求整理
- 要件定義
- 多言語対応範囲の整理
- i18n設計
- データベース設計
- 翻訳データ設計
- ユーザー・locale設計
- URL設計
- 認証・権限設計
- API設計
- Webシステム開発
など、必要な段階から相談できます。
例えば、
「今は日本語だけだが、将来海外展開したい」
「海外拠点でも同じ業務システムを利用したい」
「日本語・英語の両方でSaaSを提供したい」
「すでにある日本語システムを多言語化できるか知りたい」
といった段階でも、現在のシステム構造と将来の対象地域を整理することで、必要な対応範囲が見えやすくなります。
多言語対応で重要なのは、最初から何十言語も実装することではありません。
あとから言語を追加しても、画面・データ・日時・権限・通知などを大きく作り直さずに済む構造を設計しておくことが重要です。