BtoB EC 多言語対応の設計｜要件と進め方

◆監修・編集責任者　小園 将隆　2026年8月24日

B2B EC-COLUMN

BtoB ECの多言語対応の設計とは

BtoB ECの多言語対応の設計とは、翻訳文を用意することではなく、画面の文言・データの書式・利用者の識別・運用の分担という4つの決めごとを、言語・ロケール・取引先のどの単位で切り替えるかまで決めきることです^*3*4。

国内向けのBtoB ECを前提に作られたシステムには、この4つの決めごとに対応する余白がないことがあります。表1は、国内向けECと多言語対応ECで何が追加になるかを整理したものです。

本記事が扱う範囲は、この4つの決めごとと、その土台になるデータ設計です。国内取引先の外国籍担当者への対応や、対応言語を広げる段階設計にも触れます。

一方で、海外取引にともなう法令・輸出管理・通関の実務は扱いません。この領域は、海外取引の全体像を扱う別記事に譲ります。取引先別の価格の実装手順やカートシステムの製品選定基準も、本記事では扱いません。

なぜBtoBで多言語対応が必要になるのか

日本貿易振興機構（ジェトロ、独立行政法人）の『2025年度 第24回 日本企業の海外事業展開に関するアンケート調査』（2026年3月公表）によれば、ECを利用したことがある企業（現在は利用していない企業を除く）または利用を検討していると回答した企業（n=1,881）のうち、68.4％が海外向け販売でECを活用または検討していると回答しました^*9。具体的な販売方法では、越境ECと回答した企業が45.5％で最も高い比率になっています^*9。

企業規模別に見ると、中小企業（n=1,694）では越境ECの割合が47.0％を占めました^*9。この数値は全回答企業3,369社に対する割合ではなく、あくまでECを利用または検討している企業を母数にした値です^*9。

国内の市場規模も並行して拡大しています。経済産業省の『令和6年度電子商取引に関する市場調査』（2025年8月26日公表）によれば、2024年の国内BtoB-EC市場規模は514.4兆円で前年比10.6％増、BtoB-ECのEC化率は43.1％で前年比3.1ポイント増でした^*8。この514.4兆円は国内の商取引を対象にした数値であり、越境ECや海外向けの数値ではありません^*8。同調査が扱う越境ECの数値は消費者向け市場を対象にしたものであるため、BtoBの文脈でそのまま引用することはできません^*8。

多言語対応が必要になる場面は、海外向け販売だけではありません。国内で操業する取引先に日本語以外の言語を使う利用者が増え、受発注画面への問い合わせが増えるケースもあります。海外の代理店や現地法人から英語での発注画面を求められる場合も同様です。いずれも、翻訳の有無より前に、どの単位で何を切り替えるかという設計が問われます。

「多言語対応」を4つの決めごとに分解する

多言語対応は「サイトを翻訳すれば完了する」作業ではありません。実務では、次の4つを個別に決める必要があります。

決めごと1 表示――画面文言・帳票・メール・添付物のどこまでを対象にするか

対象範囲は画面だけにとどまりません。見積書・注文請書といった帳票、受注確認メール、仕様書などの添付物まで含めるかどうかで、作業量が大きく変わります。範囲を決めずに着手すると、途中で対象が膨らみ続けます。

決めごと2 データ――何を言語別に持ち、何を共通で持つか

品名や仕様のように言語ごとに異なる情報と、品目コードのように言語に関係なく共通で持つべき情報を分けて設計します。この切り分けが次の決めごとにつながります。

決めごと3 識別――言語・ロケール・取引先のどの単位で切り替えるか

言語・ロケール・取引先は、それぞれ独立した切り替え軸として設計します。文言は言語で、日付や通貨の書式はロケールで、価格や在庫は取引先で切り替えるという分け方が基本です。この記事で最も混乱しやすい論点であるため、次章で詳しく扱います。

決めごと4 運用――誰が訳し、誰が承認し、いつ反映するか

翻訳を用意する仕組みだけでなく、承認と反映のタイミングまで決めておく必要があります。新商品登録時に未翻訳の項目をどう扱うかは、次章のデータ設計で扱うフォールバック規則と直接つながります。

切り替えの単位を決める――言語・ロケール・取引先は別の軸である

多言語対応で最も混同されやすいのが、「何の単位で切り替えるか」という論点です。言語・ロケール・取引先は、それぞれ別の軸として設計する必要があります。

言語タグとは――BCP 47で構造が定義される識別子

言語タグ（language tag。ある情報が使用する言語を示す識別子）の構造は、IETF（Internet Engineering Task Force、インターネット技術の標準化団体）が発行するBCP 47（RFC 5646）で定義されています^*1。RFC 5646は2009年9月に発行された文書で、それまでのRFC 4646を置き換える現行の規範文書です^*1。サブタグ（言語タグを構成する各部分）はIANA Language Subtag Registryで一元管理されており、言語部分はISO 639、スクリプト部分はISO 15924、地域部分はISO 3166の各コードに由来します^*2。

言語タグは短く保つ――地域サブタグは必要なときだけ付ける

W3C(World Wide Web Consortium、Web技術の標準化団体)の解説記事は、言語タグ作成の原則として「タグはできる限り短く保ち、有用な区別を加える場合を除いてregion・script等のサブタグは避ける」という考え方を明記しています^*2。これは「en-USは誤りである」という断定ではありません。区別が必要かどうかを先に判断したうえで、必要がなければ地域サブタグを付けない、という条件付きの原則です^*2。イタリア語の例では、イタリアで話されているイタリア語であることを特に強調する必要がない限り、it-ITではなくitを使うべきだとされています^*2。

ロケールとは――「国際的な設定の集合」の識別子

W3Cの作業草案『Language Tags and Locale Identifiers for the World Wide Web』は、ロケール（locale）を「国際的な設定の集合を表す識別子（言語タグなど）」と定義しています^*3。この文書は2020年10月7日付のW3C Working Draftであり、勧告（Recommendation）ではない点に注意が必要です^*3。Unicode Consortium（Unicodeの標準化団体）が策定するLDML(Unicode Locale Data Markup Language、ロケールデータを記述する形式)は、ロケールデータが日付・時刻・数値・通貨の書式、単位、並び順（照合、collation）、タイムゾーン名・言語名・国名の翻訳などを含むと定めています^*4。つまり、言語で切り替わるのは文言そのものであり、ロケールで切り替わるのは書式や並び順です。この2つは別の軸として設計する必要があります^*3*4。

取引先軸は別――価格・在庫・支払条件は言語に紐づけない

価格・在庫・支払条件は、言語やロケールではなく取引先ごとに切り替えるべき情報です。英語表示にした画面がそのまま海外価格を意味するわけではなく、同じ言語を使う取引先でも契約条件によって価格が異なる場合があります。取引先別の価格設定をどのように実装するかは、別記事で扱う実装論であり、本記事では設計上の切り分けにとどめます。

データ設計――BtoBでは品目マスタが本体になる

BtoBの多言語対応で最も作業量が大きくなるのは、画面の翻訳ではなく品目マスタの多言語化です。取り扱う商品数が多いほど、この作業の比重は増します。

何を言語別に持つか

品名・仕様・単位表記・注意書き・カテゴリ名は、言語ごとに異なる値を持つ必要があります。これらは商品登録の都度、翻訳と承認の対象になります。

何を共通で持つか

品目コードや数量は言語に関係なく共通で持てます。財務省税関のカスタムスアンサーによれば、輸入申告で用いられる統計品目番号は9桁で、このうち4桁および6桁の番号はHS条約(商品の名称及び分類についての統一システムに関する国際条約)に基づき国際的に統一されたものです^*10。HS条約は1988年1月に発効し、2025年7月時点で163カ国・地域が加盟しています^*10。品目コードのように国際的に共通の体系を持つ項目は、言語別に持つ必要がありません。

未翻訳のときどう見せるか――フォールバック規則を決める

すべての商品を全言語で即座に翻訳できるとは限りません。LDMLは、ロケールデータの継承を「parent locales」による親ロケールへの継承と、最終的な「root」ロケールへのフォールバックとして規定しています^*4。W3CのLTLI(Language Tags and Locale Identifiers)も、言語ネゴシエーション(利用者の希望と利用可能なロケール・資源を突き合わせる処理)の手段として、より具体的な資源からより一般的な資源へ段階的に探索するロケールフォールバックに言及しています^*3。「未翻訳は空欄にする」のではなく、「どの順番でフォールバックするか」を規則として決めることが設計です。

文字を壊さないための2点――文字集合と正規化

多言語のテキストを保持するには、基本多言語面の外の文字も扱える文字集合を選ぶ必要があります。あわせて重要なのが正規化です。Unicode Consortiumが定めるUAX #15(Unicode正規化形式に関する技術文書)は、正規化形式を保っていれば「等価な文字列が一意の二進表現を持つことが保証される」としています^*5。正規化形式を決めていないと、見た目が同じ文字列でも内部表現が異なり、検索でヒットしない、同一商品が重複登録される、ログイン照合が一致しないといった不具合につながります。

氏名・住所は「姓・名」で単純に切らない

W3Cの解説記事『Personal names around the world』は、日本・韓国・ハンガリーなどの文化圏では姓が名の前に来ると説明したうえで、「可能な場合は、利用者が入力した氏名全体をそのまま使うほうが単純である」と述べています^*11。姓名を分割して並び替えたい場合は、読み仮名を入力する専用の欄を別に用意する必要があるとも指摘しています^*11。品目マスタだけでなく、取引先担当者の氏名欄を設計する際にも踏まえるべき論点です。

画面とURLの設計――見つけられ、機械に伝わる状態にする

lang属性はアクセシビリティの達成基準である

HTMLのlang属性は、SEOの補助的な設定ではなく、アクセシビリティの達成基準として位置づけられています。W3CのWCAG 2.2(Web Content Accessibility Guidelines、Webコンテンツのアクセシビリティ指針。2024年12月12日付のW3C勧告)は、ページ全体の既定言語を扱う達成基準3.1.1 Language of PageをLevel A、ページ内の一部分の言語を扱う達成基準3.1.2 Language of PartsをLevel AAとしています^*6。3.1.2は、固有名詞や専門用語、周辺の文章に溶け込んだ語句を除き、各文や語句の使用言語がプログラムで判定できることを求めています^*6。

言語別URLの持ち方

言語ごとにURLを分ける場合、サブディレクトリ・サブドメイン・別ドメインのいずれを使うかという選択があります。Googleの公式ドキュメントは「代替 URL は同じドメイン内である必要はありません」としており、別ドメインでの運用も想定されています^*7。一方で、言語ごとのサブドメインについては「そのページのターゲット ユーザーを Google が判断する際には使用されませんので、ターゲット ユーザーを明示的にマッピングする必要があります」とも明記しています^*7。つまりURLの形そのものが対象読者を伝えるわけではなく、後述するhreflangでの明示が必要です。言語ごとにURLを分ける構成は、言語別の流入や離脱を分析しやすくなる点でも扱いやすくなります。

hreflangの指定――HTML・HTTPヘッダー・サイトマップの3方式

Google(検索セントラル、公式ドキュメント)は、ページの言語・地域ごとの別バージョンを伝える方法として、HTMLタグ・HTTPヘッダー・サイトマップの3方式を挙げています^*7。

相互に参照していないタグは無視される

Googleの公式ドキュメントは「2つのページが互いに参照し合っていない場合、参照するタグは無視されます」と明記しています^*7。片方のページにだけhreflangを設定し、もう一方からの参照が無い状態では、設定そのものが機能しません。これが「hreflangを入れたのに効かない」という現象の主な原因です。

x-defaultの役割

予約値であるx-defaultは、「ユーザーのブラウザの設定が、他に指定されているどの言語や地域とも一致しない場合に使用される」値です^*7。言語コードはISO 639-1形式、地域コードはISO 3166-1 Alpha 2形式で指定します^*7。

Googleはhreflangやlang属性でページ言語を判定しない

Googleの公式ドキュメントは「Googleがhreflangまたはlang属性を使用してページの言語を検出することはありません。代わりに、アルゴリズムを使用して言語を決定します」とも説明しています^*7。これは言語判定の仕組みについての説明であり、hreflangの設定そのものが不要という意味ではありません。hreflangは、同一内容の代替版がどこにあるかをGoogleに申告するための仕組みとして、引き続き必要です^*7。

現状のやり方のまま言語別URLを増やしても、hreflangの相互参照が漏れていれば意図した効果は得られません。無料相談で要件を整理することで、自社のURL構成に合わせた抜け漏れの点検がしやすくなります。

会員制・クローズド運用の場合の扱い

ログイン後のみ表示される受発注画面のように検索エンジンの対象にならない画面には、hreflangの設定は不要です。検索対象になる画面とクローズドな画面を区別して設計します。

翻訳の運用設計――訳語を揺らさない仕組みをつくる

訳語の統一は「章として立てる」対象である

国土交通省観光庁の『観光立国実現に向けた多言語対応の改善・強化のためのガイドライン』(平成26年3月)は、観光分野を対象にした文書ですが、訳語統一の考え方には参考になる点があります。同ガイドラインは「多言語表記の統一性・連続性の確保」を独立した章として置き、表記方法を6パターンに分類したうえで、英語・中国語・韓国語について400以上の対訳語を掲載しています^*12。BtoB ECの品名ルールに個別の対訳語をそのまま転用することはできませんが、訳語の統一を仕組みとして持つという考え方は参考になります^*12。

固有名詞と普通名詞で扱いを分ける

自社の製品名・型番は翻訳せず、仕様を説明する語句のみ翻訳するという切り分けが基本です。この区別を先に決めておかないと、翻訳者ごとに扱いが揺れます。

用語集を先に作り、翻訳の入力にする

対訳語のリストを先に用意し、翻訳作業の入力として使う仕組みにすると、訳語の揺れを防ぎやすくなります。

機械翻訳をどこまで使うか

機械翻訳は特定の翻訳サービスの精度によって一律に評価できるものではなく、用途によって適否が変わります。一次判断の材料として使える箇所と、契約に関わる帳票のように人の確認を経るべき箇所を、あらかじめ切り分けておく必要があります。

反映のタイミング

新商品を登録した時点で全言語の翻訳が揃っているとは限りません。ここで、データ設計で決めたフォールバック規則が生きます。未翻訳のまま公開するか、翻訳完了まで非表示にするかを、登録フローの中であらかじめ決めておきます。

どこから始めるか――多言語対応に固有の段階設計

「全部揃うまで始めない」という判断は、着手を先延ばしにするだけになりがちです。対象範囲を絞った段階0から着手し、段階を追って広げるほうが、投資判断もしやすくなります。段階を分けて進める考え方の詳細は、導入の進め方全体を扱う記事で扱っています。

よくある失敗と回避策

言語と通貨・価格を同じ切り替えに載せてしまう

言語設定を切り替えると価格や在庫まで自動的に変わる作りにすると、同じ言語を使う複数の取引先に異なる価格を提示できなくなります。回避策は前述のとおり、取引先を独立した軸として設計することです。

未翻訳時の挙動を決めずに公開し、画面が空欄になる

フォールバック規則を決めないまま新商品を登録すると、未翻訳の言語で画面が空欄になります。回避策は、フォールバック規則をあらかじめ決めておくことです。

en-US・ja-JPを無条件に採用し、不要な地域差を抱える

区別の必要性を検討せずに地域サブタグを付けると、管理する言語タグの種類が不必要に増えます。W3Cの原則に従い、区別が必要かどうかを先に判断します^*2。

hreflangを片側にだけ入れて効かない

相互参照が漏れていると、設定した側のタグも無視されます^*7。両方向の参照を点検します。

品目マスタを後回しにし、画面だけ多言語化して問い合わせが減らない

画面の文言だけ翻訳しても、品名や仕様が日本語のままでは、取引先からの問い合わせは減りません。品目マスタの多言語化は後回しにできない作業です。

まとめ――多言語対応の設計を3つの判断軸に集約する

本稿では、BtoB ECの多言語対応を「表示・データ・識別・運用」の4つの決めごとに分解し、設計の考え方を整理しました。要点を3つに集約すると次の通りです。第一に、言語・ロケール・取引先は別の軸であり、混ぜて設計すると価格や書式の表示が崩れます^*3*4。第二に、BtoBで最も作業量が大きいのは画面の翻訳ではなく品目マスタの多言語化であり、未翻訳時のフォールバック規則を決めることが設計の核になります^*4。第三に、hreflangやlang属性は「入れれば終わり」ではなく、相互参照とアクセシビリティ要件を満たして初めて機能します^*6*7。

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

よくある質問

サイトを翻訳ツールで多言語化すれば、多言語対応と言えますか。

画面文言の翻訳だけでは不十分です。品目マスタのデータ設計、識別の単位、未翻訳時のフォールバック規則まで決めて初めて、対応が完了したと言えます^*3*4。

言語コードはenとen-USのどちらで持つべきですか。

W3Cの原則は、有用な区別を加える場合を除いてサブタグを避け、タグを短く保つことです^*2。地域を区別する必要が実際にあるかを先に判断したうえで選びます。

翻訳が用意できていない商品は、画面にどう表示すればよいですか。

空欄のまま公開するのではなく、親ロケールや既定言語へ段階的にフォールバックする規則をあらかじめ決めておきます^*3*4。

英語ページと日本語ページが検索で重複扱いになりませんか。

hreflangで代替版を相互に参照させれば、重複ではなく同一内容の別バージョンとして扱われます。ただし相互参照が漏れていると設定自体が無視されます^*7。

対応言語を後から増やすことはできますか。

できます。段階0で対象範囲を絞って着手し、段階を追って品目マスタや検索対応まで広げる進め方が現実的です。

1. *1　出典：Internet Engineering Task Force「RFC 5646 / BCP 47 Tags for Identifying Languages」（2009年9月）https://www.rfc-editor.org/rfc/rfc5646.txt
2. *2　出典：World Wide Web Consortium（W3C）Internationalization「Language tags in HTML and XML」https://www.w3.org/International/articles/language-tags/
3. *3　出典：World Wide Web Consortium（W3C）「Language Tags and Locale Identifiers for the World Wide Web」（W3C Working Draft・2020年10月7日）https://www.w3.org/TR/ltli/
4. *4　出典：Unicode Consortium「Unicode Technical Standard #35: Unicode Locale Data Markup Language（LDML）」バージョン48.2（2026年3月3日）https://www.unicode.org/reports/tr35/
5. *5　出典：Unicode Consortium「Unicode Standard Annex #15: Unicode Normalization Forms」Unicode 17.0.0（2025年7月30日）https://www.unicode.org/reports/tr15/
6. *6　出典：World Wide Web Consortium（W3C）「Web Content Accessibility Guidelines (WCAG) 2.2」（W3C Recommendation・2024年12月12日）https://www.w3.org/TR/WCAG22/
7. *7　出典：Google 検索セントラル「ローカライズ版ページ（hreflang）について Google に伝える」https://developers.google.com/search/docs/specialty/international/localized-versions?hl=ja
8. *8　出典：経済産業省 商務情報政策局「令和6年度電子商取引に関する市場調査」（2025年8月26日公表）https://www.meti.go.jp/press/2025/08/20250826005/20250826005.html
9. *9　出典：日本貿易振興機構（ジェトロ）調査部「2025年度 第24回 日本企業の海外事業展開に関するアンケート調査」（2026年3月公表）https://www.jetro.go.jp/ext_images/_Reports/01/23f5d9f6472b5c0d/20250042.pdf
10. *10　出典：財務省 税関「1201 品目分類の概要（カスタムスアンサー）」https://www.customs.go.jp/tetsuzuki/c-answer/imtsukan/1201_jr.htm
11. *11　出典：World Wide Web Consortium（W3C）Internationalization「Personal names around the world」https://www.w3.org/International/questions/qa-personal-names
12. *12　出典：国土交通省 観光庁「観光立国実現に向けた多言語対応の改善・強化のためのガイドライン」（平成26年3月）https://www.mlit.go.jp/kankocho/content/810003138.pdf