はじめに
「自社ECサイトを多言語化したいが、サブドメインかサブディレクトリかで判断がつかない」
「多言語プラグインを入れただけでSEO評価が積み上がるのか不安がある」
「翻訳した瞬間に運用負荷が3倍になりそうで、踏み出せていない」
海外販売やインバウンド需要の取り込みを検討するEC事業者から、こうした相談が増えています。
EC多言語対応は、サイトの文字を翻訳するだけの作業ではなく、URL構成・hreflang・通貨表示・決済手段・配送設定・コンテンツ運用が一体で組み立てられて、はじめて海外ユーザーの購入完了まで到達できる構造です。
途中の設計を一つ誤ると、検索流入が国内サイトとカニバリを起こしたり、決済画面で離脱したり、運用工数が膨らんだりと、後から大きな手戻りが発生します。
本記事では、EC多言語対応の判断軸、URL構成の3パターン比較、多言語プラグインと標準機能の選定、hreflangを含むSEO設計、通貨・決済・配送の連動、翻訳ワークフロー、運用体制、よくある失敗パターンまで解説します。
目次
-
EC多言語対応とは｜越境ECとの違いを整理する
-
EC多言語対応を検討すべきタイミングと判断軸
-
EC多言語対応の3つのURL構成パターン
-
多言語プラグイン・標準機能の選定
-
EC多言語対応のSEO設計（hreflang・重複コンテンツ対策）
-
通貨・決済・配送の多言語連動
-
翻訳ワークフローと品質管理
-
EC多言語対応の運用体制と工数設計
-
EC多言語対応で陥りがちな失敗パターン
-
まとめ
【無料相談】貴社のEC多言語対応をShopifyの専門家がご提案します 多言語化の判断軸からURL構成、SEO設計、運用ワークフローまで、貴社の事業規模・販売国に合わせた最適な進め方を整理します。
[無料で相談する] [資料をダウンロード]
1. EC多言語対応とは｜越境ECとの違いを整理する
1-1. EC多言語対応の定義
EC多言語対応とは、自社のECサイトを複数の言語で表示・運用できるように設計し、外国語話者ユーザーが自然に商品閲覧から購入完了まで進めるようにする取り組みを指します。
「多言語ECサイト」「EC グローバル対応」「ローカライズ対応」とも呼ばれますが、本記事では「EC多言語対応」で統一します。
対応範囲は、商品名・商品説明・カテゴリページ・購入フロー・カスタマーサポート・利用規約・特定商取引法表記の現地法対応版まで、サイト全体に及びます。
1-2. 越境ECとの違いと関係
EC多言語対応と越境ECは、混同されがちですが指す範囲が異なります。
|
項目 |
EC多言語対応 |
越境EC |
|---|---|---|
|
主な意味 |
サイトを多言語で表示・運用できる状態 |
海外消費者に向けて販売する事業形態 |
|
カバー範囲 |
UI翻訳・URL設計・SEO・運用ワークフロー |
事業計画・販売国選定・決済・物流・法規制・現地マーケまで |
|
主な担当 |
EC担当・エンジニア・コンテンツ運用 |
事業責任者・経営・法務・物流 |
|
必須条件 |
言語の追加 |
国境を越えた取引（多言語対応はその一部） |
多言語対応は越境ECの一部を構成する要素ですが、国内向けにも訪日外国人・在留外国人向けに多言語化するケースがあるため、必ずしも越境ECとイコールではありません。
事業の目的と顧客像に合わせて、対応の深さを設計することが出発点です。
1-3. 対応の3レベル
EC多言語対応は、深さに応じて3つのレベルで整理できます。
|
レベル |
対応範囲 |
主な手法 |
適した状況 |
|---|---|---|---|
|
Lv1: 簡易対応 |
UI主要部分のみ機械翻訳で表示 |
ブラウザ翻訳・Google翻訳ウィジェット |
訪日外国人の閲覧対応、初期テスト |
|
Lv2: 標準対応 |
商品ページ・主要導線をネイティブ翻訳 |
多言語プラグイン・標準機能 |
越境EC初期、海外需要の試験 |
|
Lv3: 完全対応 |
サイト全体・運用フロー・サポートまで多言語化 |
専門翻訳＋現地運用体制 |
本格的な海外展開 |
立ち上げ初期はLv2で始め、売上規模と販売国が固まった段階でLv3に進む構造が現実解です。
Lv1のままでは本格的な海外売上を期待しにくく、機械翻訳の品質はCVRと返品率に直結します。
2. EC多言語対応を検討すべきタイミングと判断軸
2-1. 検討すべきタイミングの目安
EC多言語対応を検討するタイミングは、事業の状況に応じて以下のサインから判断できます。
-
自社サイトに海外からのアクセスが一定数（月間1,000セッション以上）発生している
-
海外のSNSフォロワー・問い合わせが増えている
-
インバウンド観光客の購入が店舗で見られる
-
海外のモールや代理販売で一定の売上が立っており、自社EC化を検討したい
-
経営計画で海外売上比率の目標が掲げられている
Google Search ConsoleやGA4で海外からのアクセス・検索クエリを確認し、需要の輪郭を掴むところから始めると、後の投資判断がぶれにくくなります。
2-2. 対応言語の選定
多言語対応を始める際、最初に決めるべきは「どの言語に対応するか」です。判断軸は以下です。
-
現状のアクセス分析（GA4の国別セッション、言語別検索クエリ）
-
商材の親和性が高い国・言語
-
競合他社が対応している言語
-
自社のリソースで運用できる言語数（最大2〜3言語で始めるケースが多い）
英語は「世界の共通語」として一定のカバー率がありますが、購入完了率を上げるには「ユーザーの母語」での体験が望ましいことが多くの調査で示されています。
CSA Researchの調査では、消費者の76%が「自国の言語で書かれた商品情報を持つサイトでの購入を好む」と回答しています（出典：CSA Research “Can’t Read, Won’t Buy” 2020年）。
英語のみで世界を網羅する戦略と、主要販売国の母語に丁寧に対応する戦略は、コストとリターンのバランスが大きく異なります。事業の優先順位に応じて選択します。
2-3. 多言語対応の判断フレーム
多言語対応に踏み出すかどうかは、次の判断フレームで整理できます。
|
判断軸 |
多言語対応に進むサイン |
見送るサイン |
|---|---|---|
|
需要 |
海外アクセス・問い合わせが定常的に発生 |
海外需要が散発的・確認できない |
|
商材 |
海外でも検索される・ブランド認知がある |
国内市場固有の商材 |
|
体制 |
翻訳・運用・サポートを担う人員またはパートナーがある |
国内運用で手一杯 |
|
投資余力 |
初期投資100万〜・継続的な翻訳費用を確保できる |
初期投資を最小化したい |
|
期間目標 |
6〜12カ月で海外売上の輪郭を見たい |
短期で結果が必要 |
「進むサイン」が3つ以上揃った段階が、本格的な多言語対応の検討フェーズです。
3. EC多言語対応の3つのURL構成パターン
多言語対応の初動でつまずきやすいのが、URL構成の選定です。サブドメイン・サブディレクトリ・別ドメインの3パターンがあり、それぞれ性質が異なります。
3-1. 3パターンの基本構造
|
構成 |
URL例（英語版） |
概要 |
|---|---|---|
|
サブディレクトリ |
example.com/en/ |
ドメインの配下に言語別ディレクトリを配置 |
|
サブドメイン |
en.example.com |
メインドメインの下に言語別サブドメインを配置 |
|
別ドメイン |
example.us / example.eu |
国別の独立ドメインを取得 |
主要なグローバルEC・大手ブランドは、用途に応じてこの3パターンを使い分けています。どれが「最適」と一概には言えず、事業フェーズ・SEO戦略・運用体制・国別の独自性の必要度合いで選定します。
3-2. サブディレクトリ型
ドメインの配下に /en/ /zh/ のように言語別ディレクトリを配置する構成です。
-
特徴：メインドメインのSEOオーソリティを引き継げる／構築・運用コストが相対的に低い／言語切替の実装がシンプル／国別の独自施策の自由度はやや限定的
-
向いている事業：立ち上げ初期でドメイン分散によるSEOリスクを避けたい／国別の独立性を必要としない／既存サイトに段階的に多言語を追加したい
3-3. サブドメイン型
en.example.com のように、メインドメインの下に言語別サブドメインを配置する構成です。
-
特徴：言語別・地域別のサイト独立性が高い／インフラ構成・運用体制を国別に分けやすい／メインドメインとの関係はGoogleには独立扱いされ得る（ただし運用次第）／構築の手間はサブディレクトリより増える
-
向いている事業：国別に独立した運用体制を組みたい／国別にインフラ・ホスティングを分けたい／既存の組織体制が国別に分かれている
3-4. 別ドメイン型
国別に .us .eu .cn 等の独立ドメインを取得する構成です。
-
特徴：国別の独立性が高い／各国ごとに最適化されたサイトを構築できる／国別のSEOオーソリティはゼロから積み上げ／構築・運用コストが大きい
-
向いている事業：各国で独自のブランド・商品ラインを展開／法人・販社が国別に存在する／大規模な海外売上を持つグローバル企業
3-5. 構成選定の判断軸
3パターンを判断する主要観点を整理します。
|
観点 |
サブディレクトリ |
サブドメイン |
別ドメイン |
|---|---|---|---|
|
SEOオーソリティの引き継ぎ |
★★★★★ |
★★★☆☆ |
★☆☆☆☆ |
|
構築・運用コスト |
★★★★★（低い） |
★★★☆☆ |
★☆☆☆☆（高い） |
|
国別の独立性 |
★★☆☆☆ |
★★★★☆ |
★★★★★ |
|
立ち上げスピード |
★★★★★ |
★★★☆☆ |
★★☆☆☆ |
|
多国展開時の拡張性 |
★★★☆☆ |
★★★★☆ |
★★★★★ |
立ち上げ初期はサブディレクトリ型で始め、特定の国の売上が成熟してからサブドメイン型や別ドメイン型に切り出す経路が、実務でよく見られます。
3-6. プラットフォーム別の対応傾向
ECプラットフォームによって、デフォルトで採用しやすいURL構成は異なります。ASP・SaaS型（グローバル設計）はサブディレクトリ型を標準サポートするケースが多く、ASP・SaaS型（国内中心＋拡張）はサブドメイン型・別ドメイン型を別契約・別ストアで運用するケースがあります。
パッケージ・オープンソース型は3パターンとも実装可能ですが、開発工数を要します。
選定時には、将来の構成変更（サブディレクトリ→サブドメイン等）に対応できるかも確認しておくと、後の手戻りを抑えられます。
4. 多言語プラグイン・標準機能の選定
URL構成と並行して検討するのが、翻訳の仕組みです。プラットフォーム標準機能を使うか、サードパーティのプラグイン・アプリを使うかで運用負荷が変わります。
4-1. 翻訳の仕組みの3タイプ
|
タイプ |
概要 |
例 |
|---|---|---|
|
プラットフォーム標準機能 |
多言語対応がプラットフォームに組み込まれている |
Shopify Markets、BigCommerce Multi-Storefront |
|
専用プラグイン・アプリ |
サードパーティのアプリ・拡張で翻訳機能を追加 |
Weglot、Langify、ConveyThis |
|
カスタム実装 |
独自で多言語化ロジックを構築 |
EC-CUBE・Magento等で開発実装 |
4-2. それぞれのメリット
プラットフォーム標準機能：翻訳データがプラットフォーム本体と同期されるため商品追加・更新時の二重作業を避けやすい／多通貨・多税率・地域別在庫管理などECの周辺機能と一体で運用しやすい／SEO設定（hreflang等）の自動生成が組み込まれている場合が多い／アプリ追加による表示速度の負荷を抑えられる。
プラグイン・アプリ：翻訳ワークフローや機械翻訳エンジンの選択肢が広い／UIや翻訳管理画面が翻訳業務に特化していて使いやすいことが多い／既存のプラットフォームに後付けで導入できる。
4-4. 主要な多言語アプリ・サービス（並列紹介）
各サービスの最新仕様は公式サイトでご確認ください。
-
Weglot：クラウドベースの多言語化サービス。SaaS型ECへのスムーズな導入、機械翻訳の自動適用と人手による上書き翻訳の両立、SEO設定（hreflang等）の自動生成に対応
-
Langify：Shopify向けに開発された多言語アプリ。多言語切替UI・翻訳エディタを提供
-
ConveyThis：機械翻訳と人手翻訳のハイブリッドに対応するクラウドサービス。複数のECプラットフォームに対応
-
TranslatePress / WPML：WordPress＋WooCommerce構成で広く使われる多言語化プラグイン。記事ベースのコンテンツECで採用
-
Smartling：エンタープライズ向けの翻訳管理プラットフォーム。大規模・多サイト運用や翻訳ワークフローの統制に強み
4-5. 選定の判断軸
多言語アプリ・サービスを選ぶ際の主要観点を整理します。
|
判断軸 |
評価ポイント |
|---|---|
|
対応プラットフォーム |
自社のECプラットフォームに公式対応しているか |
|
URL構成 |
サブディレクトリ・サブドメインのいずれに対応するか |
|
SEO設定 |
hreflang・サイトマップ・canonical URLの自動生成範囲 |
|
翻訳方式 |
機械翻訳・人手翻訳・ハイブリッド |
|
翻訳エディタ |
担当者が直感的に編集できるUIか |
|
表示速度 |
アプリ追加による表示速度への影響 |
|
月額・販売手数料 |
文字数課金・固定料金など料金体系 |
サイトの表示速度はCVRに直結します。
多言語アプリが追加のJavaScriptやリクエストを介して表示する仕様の場合、表示速度が落ちる可能性があります。Googleの調査によると、モバイルページの表示に3秒以上かかると53%のユーザーが離脱すると報告されており、表示のわずかな遅れが直帰率の悪化に直結します（出典：Google『The Need for Mobile Speed』）。
そのため、導入前に本番環境に近い形でパフォーマンスを計測してから本採用する流れが安全です。
5. EC多言語対応のSEO設計（hreflang・重複コンテンツ対策）
多言語ECサイトの設計で最も慎重に扱うべきが、SEO観点です。
設計を誤ると、Googleが各言語版を「重複コンテンツ」と認識し、検索流入が伸び悩む結果につながります。
5-1. hreflangタグの設定
hreflangタグは、同じコンテンツの言語別・地域別バージョンをGoogleに伝えるためのHTMLタグです。
多言語ECサイトの基本設定として、以下の3要素を一貫して設計します。
-
各言語ページに、対応する全言語ページへのhreflangタグを記述する
-
自分自身を指すself-referencing hreflangを含める
-
x-default タグでデフォルトページ（言語非指定時に表示するページ）を指定する
設定例（言語別ページのhead内）：
<link rel="alternate" hreflang="ja" href="https://example.com/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/" />
<link rel="alternate" hreflang="zh-CN" href="https://example.com/zh/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />
地域指定（en-US、en-GB、zh-CN、zh-TW等）まで分ける場合は、言語コードと地域コードをハイフンで連結します（ISO 639-1＋ISO 3166-1の組み合わせ）。
5-2. canonical URLの設計
各言語ページのcanonical URLは、原則として「そのページ自身」を指すように設定します。日本語版の翻訳である英語版ページが「canonical = 日本語版」となっていると、英語版が独立コンテンツとして評価されなくなります。
多言語アプリ・プラグインの設定によってはデフォルトで日本語版をcanonicalに指定するケースがあるため、リリース前に各言語ページのcanonical URLを一通り検査することが推奨されます。
5-3. サイトマップの分割と提出
多言語サイトでは、言語別にサイトマップを分割または統合してGoogle Search Consoleに提出します。
サイトマップ内では、各URLにhreflang情報を含めることも可能です（Sitemap Protocol拡張）。ヘッダ内のhreflangタグと組み合わせてサイトマップにも記述すると、Googleがクロール時に多言語関係を把握しやすくなります。
5-4. URLとパンくずリストの言語化
URL構造とパンくずリストも、可能な範囲で言語化することが推奨されます。
-
URL：日本語スラッグではなく、英語スラッグまたは言語別スラッグを使用
-
例：/products/sneakers（OK）／/products/スニーカー（避ける）
-
パンくずリスト：各言語に対応した表記（例：英語版「Home > Products > Sneakers」、中国語版「首页 > 商品 > 运动鞋」）
5-5. 言語切替UIと自動リダイレクトの注意点
ヘッダ・フッタの言語切替UIは、すべての言語版で同等の位置・操作性で配置します。検索エンジンが言語切替リンクを認識できるよう、JavaScriptに依存しすぎないHTMLリンクで提供することが推奨されます。
IPアドレスやブラウザ言語による自動リダイレクトは、Googleの公式ガイドラインでも慎重な実装が推奨されています。
Googlebotは特定地域のIPからクロールするため、自動リダイレクトでGooglebotが意図しない言語版にしか到達できなくなる事故が起こりえます。
自動リダイレクトを採用する場合は、初回訪問のみのリダイレクト／ユーザー手動切替の優先／Googlebotが全言語版にクロールできる構造の提供、といった設計を組み合わせます。
5-6. 翻訳済みコンテンツのインデックス管理
未翻訳のページが残る場合は、noindexタグを設定するか、サイトマップから除外し、翻訳完了時点で順次公開する運用が安全です。
翻訳途中ページがGoogleにインデックスされ、低品質コンテンツとして評価されるリスクを避けます。
【資料ダウンロード】EC多言語対応のSEOチェックリストをご提供します hreflang・canonical・サイトマップ・URL構造など、リリース前に確認すべき項目を一覧化したチェックリストを無料でダウンロードいただけます。
[資料をダウンロード]
6. 通貨・決済・配送の多言語連動
多言語対応は「文字を翻訳する」だけでは完結しません。
決済画面までの体験を、ユーザーの自国通貨・自国決済・自国向け配送設定で完結させることが、購入完了率の前提条件になります。
6-1. 多通貨表示と決済通貨の設計
多通貨対応には大きく3レベルがあります。
|
レベル |
内容 |
主な体験 |
|---|---|---|
|
Lv1: 通貨表示のみ |
価格を自国通貨で参考表示。決済は事業者通貨 |
「USDで表示されるが、決済は円」 |
|
Lv2: 自動換算決済 |
自動換算で決済通貨を切り替える |
「USDで決済が完了する」 |
|
Lv3: 国別固定価格 |
国別に固有の価格を設定 |
「米国向けは$X、欧州向けは€Y」 |
立ち上げ初期はLv1〜Lv2、ブランド・商材戦略が固まったらLv3に進む構造が一般的です。
Shopify Marketsをはじめとするグローバル設計のプラットフォームでは、130通貨以上に標準対応するケースもあります（出典：Shopify公式）。
6-2. 販売国別の主要決済への対応
販売国ごとに主要決済は異なります。
決済画面に到達したものの、現地で主流の決済手段が用意されていないことで離脱するケースは少なくありません。
|
地域 |
主要決済の例 |
|---|---|
|
米国 |
クレジットカード／PayPal／Shop Pay／Apple Pay |
|
欧州 |
クレジットカード／SEPA／iDEAL／Klarna／PayPal |
|
中国 |
Alipay／WeChat Pay／銀聯 |
|
東南アジア |
クレジットカード／GrabPay／GCash／OVO |
|
韓国 |
クレジットカード／カカオペイ／Naver Pay |
EU・米国向けには3Dセキュア（強い顧客認証）への対応、中国向けには現地決済の取り扱い、欧州・東南アジア向けには分割払い・後払いサービス（Klarna、Atomeなど）との連携といった、地域ごとの決済UXに合わせた追加実装が必要になることがあります。
6-3. 関税・税金の事前計算と表示
Baymard Instituteの調査では、ECサイトでカゴ落ちが発生する主因の48%が「予期せぬ追加コスト（送料・税金・手数料）」とされています（出典：Baymard Institute “Cart Abandonment Rate Statistics” 2024年）。
多言語ECで決済までの離脱を抑えるには、関税・税金・送料を購入フローの早い段階で明示することが要点になります。
|
方式 |
概要 |
UXへの影響 |
|---|---|---|
|
DDP（Delivered Duty Paid） |
販売者が事前に関税・税金を計算して徴収・納付 |
購入者のUXがシームレス |
|
DDU（Delivered Duty Unpaid） |
購入者が商品到着時に関税・税金を負担 |
受取時の追加請求でクレーム・返品のリスク |
購入体験を一貫させるならDDP方式での運用が望ましいケースが多くなります。
プラットフォーム標準機能やAvalara・Zonosなどの税計算サービスを併用するのが一般的です。
6-4. 配送設定の多言語連動
配送設定も、言語と連動して設計します。
-
配送先国・地域を言語別ストアごとに制限／許可する
-
国別の配送業者・配送方法を切り替える（国内便／国際郵便／国際宅配便）
-
国別の送料・配送リードタイムを表示する
-
配送先の住所フォーマット（郵便番号の桁数・州コード等）に対応する
配送リードタイム・送料・関税の表示が「不明瞭」「想定より遅い」「高すぎる」と判断された瞬間にカゴ落ちが発生する構造のため、購入完了率を左右する重要な要素になります。
6-5. 言語・通貨・配送の整合性
ユーザー体験を一貫させるには、サイト訪問から購入完了までの「言語」「通貨」「配送」の組み合わせを整合させます。
米国からのアクセスには英語UI＋USD表示＋米国宛配送、中国からのアクセスには簡体字中国語UI＋CNY表示＋中国向け配送、訪日外国人には英語UI＋JPY表示＋日本国内配送、といった揃え方が基本です。
「言語は英語だが通貨は円」「言語は日本語だが配送先は米国」といった組み合わせが発生するケースもあり、ユーザーが任意に変更できる仕組みも合わせて提供します。
7. 翻訳ワークフローと品質管理
EC多言語対応で運用負荷を分けるのが、翻訳ワークフローの設計です。
新商品・キャンペーン・コンテンツ更新のたびに発生する翻訳工程を計画的に組まないと、運用が回らなくなります。
7-1. 翻訳の3方式
|
方式 |
概要 |
強み |
制約 |
|---|---|---|---|
|
機械翻訳のみ |
DeepL、Google翻訳等で全自動翻訳 |
コスト最小・即時対応 |
品質の保証なし。CVRと返品率に影響 |
|
機械翻訳＋ネイティブチェック |
機械翻訳の結果をネイティブが修正 |
コストと品質のバランス |
チェック工程の管理が必要 |
|
完全人手翻訳 |
翻訳者が全文を一から翻訳 |
品質が高い |
コスト・リードタイムが大きい |
EC事業の現実解は「機械翻訳＋ネイティブチェック」が中心です。
商品名・商品説明・キャッチコピー・FAQなど購入判断とブランド体験に直結する部分はネイティブチェックを通し、利用規約・特定商取引法表記など定型部分は機械翻訳のままで運用するなど、コンテンツの重要度に応じた使い分けが現実的です。
7-2. 翻訳メモリと用語集
中長期で運用負荷を抑える鍵が、翻訳メモリ（Translation Memory）と用語集（Glossary）の整備です。
-
翻訳メモリ：過去に翻訳した文の対訳をデータベース化し、再利用する仕組み。新商品追加時に「過去に翻訳した類似フレーズ」を自動提案できる
-
用語集：商品名・ブランド名・カテゴリ名など、翻訳しない／一定のルールで翻訳する用語を登録した一覧
これらが整っていない状態で運用を始めると、担当者・翻訳者ごとに表記揺れが発生し、サイト全体のブランド体験が崩れます。
立ち上げ時に最低限の用語集を整備し、運用しながら翻訳メモリを蓄積する流れが堅実です。
7-3. 商品情報の翻訳の落とし穴
商品情報の翻訳では、以下の点でつまずきがちです。
-
単位の現地化（cm/inch、kg/lb、JPY/USD/EUR、サイズ表記の現地版）
-
色名の現地化（「ベージュ」「グレージュ」等のニュアンスを伝える表現）
-
文化的に避けるべき表現（中国向けの数字「4」「14」の扱いなど）
-
商品名のローマ字表記とローカル名の使い分け
-
法規制対応の表示（製造国・原材料・成分等の現地表記）
機械翻訳の精度が上がっても、こうしたニュアンス・規制要件は人手によるチェックがないと拾いきれません。
7-4. 翻訳の品質チェック項目
リリース前と運用中の品質チェックでは、以下の観点を確認します。
|
項目 |
確認内容 |
|---|---|
|
翻訳の正確性 |
元の文の意味を正しく伝えられているか |
|
自然な表現 |
ネイティブが読んで違和感のない言い回しか |
|
用語の一貫性 |
サイト全体で用語集に沿った表記か |
|
単位・数値 |
通貨・サイズ・重量の単位が現地基準か |
|
法的表記 |
各国の法規制に沿った表記か |
|
UIテキスト |
ボタン・エラーメッセージ・送信完了画面まで翻訳されているか |
|
文字数 |
UIに収まる文字数か（言語によって文字数が増減する） |
7-5. 翻訳発注の体制
翻訳業務の発注パターンには、社内ネイティブ・フリーランス翻訳者・翻訳会社・翻訳プラットフォーム（Gengo等）の活用があり、商品点数・更新頻度・予算に応じて組み合わせます。
立ち上げ初期は翻訳プラットフォームで対応し、売上規模が拡大した段階で専属翻訳者やローカルパートナーに切り替える事業者が多く見られます。
8. EC多言語対応の運用体制と工数設計
技術的な実装が終わっても、運用体制が整わなければ多言語サイトは陳腐化します。
新商品・キャンペーン・コンテンツ更新のたびに、翻訳・反映・公開の工程が発生する構造を、最初に設計しておく必要があります。
8-1. 運用フローに発生する主な工数
EC多言語対応のサイト運用では、以下のような追加工数が発生します。
|
業務 |
追加工数の発生ポイント |
|---|---|
|
商品登録 |
商品名・商品説明・属性タグの言語数分の入力 |
|
キャンペーン |
バナー・LPコピー・メルマガ本文の翻訳・配信 |
|
カスタマーサポート |
多言語問い合わせの対応・FAQ翻訳 |
|
サイト改修 |
UIテキスト変更時の全言語反映 |
|
SEO運用 |
言語別のキーワード調査・タイトル・メタタグ調整 |
|
コンテンツマーケ |
ブログ・記事の多言語化（必要に応じて） |
「言語が増えると工数がN倍になる」が大きな前提です。立ち上げ初期から、運用フローと工数を試算した上で対応言語を決める方が、運用が破綻しにくくなります。
8-2. 体制パターン
EC多言語対応の運用体制には、以下のパターンがあります。
|
パターン |
内容 |
向いている事業 |
|---|---|---|
|
自社内製＋外部翻訳 |
商品登録・運用は自社、翻訳のみ外注 |
中小〜中規模EC、複数言語に対応 |
|
自社内製＋ネイティブ社員 |
ネイティブ社員を雇用し、運用も社内化 |
売上規模が安定し、対応言語が固定 |
|
完全外部委託 |
多言語運用全体を外部に委託 |
立ち上げ初期、リソース不足 |
|
国別の支社・販社運用 |
国別の現地法人・販社が運用 |
大規模企業、現地マーケが必要 |
8-3. 翻訳・運用ツールの活用
ツールの活用で運用負荷は大きく変わります。代表的なカテゴリは以下です。
-
翻訳管理プラットフォーム（TMS）：翻訳ワークフローを一元管理（Smartling、Crowdin、Lokaliseなど）
-
機械翻訳API：DeepL API、Google Cloud Translation等
-
翻訳メモリ・用語集管理ツール：TMSに統合された機能を活用
-
カスタマーサポートツール：多言語対応のヘルプデスク（Zendesk、Intercom等）
ツールの選定は、対応言語数・更新頻度・連携可能なECプラットフォームの観点で行います。
8-4. 言語数を増やすタイミング
対応言語を一気に増やすと、運用が間に合わなくなります。実務的には、以下のサインを判断軸に段階的に増やします。
-
既存言語の運用が安定し、KPIが見える状態になっている
-
追加言語の市場で需要が確認できている（GA4、検索クエリ、問い合わせ）
-
追加翻訳・運用に充てられる予算・人員が確保できている
-
主要決済・配送・法規制の準備が並行で進められる
「3言語までは何とかなるが、4言語以上は運用設計を作り直さないと回らなくなる」という現場感覚は、多くの事業者で共通しています。
【無料相談】貴社のEC多言語対応の運用体制をShopifyの専門家がご提案 翻訳ワークフロー、対応言語の優先順位、ツール選定まで、貴社の事業規模と運用リソースに合わせた構成を整理します。
[無料で相談する]
9. EC多言語対応で陥りがちな失敗パターン
最後に、EC多言語対応で陥りがちな失敗パターンを6つ解説します。事前に把握して回避しましょう。
9-1. 失敗1：機械翻訳のみでサイトを公開する
無料の機械翻訳ウィジェットを設置して「これで多言語対応完了」とするケースです。商品名・商品説明・購入フローが機械翻訳のままだと、ニュアンスの誤訳・不自然な言い回しが多発し、購入意欲とブランド信頼を損ねます。
少なくとも商品ページの主要部分・購入フロー・FAQはネイティブチェックを通すことが、立ち上げ時の最低ラインです。
9-2. 失敗2：hreflangの設定漏れ・誤り
hreflangが正しく設定されていないと、Googleが言語別ページの関係を理解できず、検索流入が伸び悩みます。特に多い誤りは以下です。
-
self-referencing hreflangが入っていない
-
双方向で記述すべきところ、片方向のみ記述している
-
言語コードが誤っている（en-USではなくen-USAなど）
-
翻訳完了後のページにhreflangが追加されていない
リリース前のSEO監査では、Google Search Consoleの「インターナショナルターゲティングレポート」やhreflang検証ツールでチェックすることが推奨されます。
9-3. 失敗3：URL構成の途中変更
「立ち上げ初期はサブディレクトリにしたが、後からサブドメインに変更した」というケースで、URL構造の変更によって既存のSEOオーソリティが分散・喪失するリスクがあります。
301リダイレクトの徹底とサイトマップ再提出で被害は抑えられますが、立ち上げ前の構成選定が最重要です。
9-4. 失敗4：自動リダイレクトの暴走
IPアドレスやブラウザ言語による自動リダイレクトを過剰に組み込むと、Googlebotが日本国内からアクセスしても日本語版にしか到達できず、海外向け言語版がインデックスされない事故が起こります。
自動リダイレクトを採用する場合は、初回訪問のみのリダイレクト／ユーザー操作の優先／Googlebotが全言語版にクロールできるリンク構造の提供、といった設計を組み合わせます。
9-5. 失敗5：通貨表示と決済通貨の不一致
商品ページではUSDで表示しているが、決済画面で円換算されて表示されるといったUXの不一致が発生するケースです。
ユーザーは「思っていた値段と違う」と感じて離脱します。
通貨表示・カート・決済の3画面で通貨が一貫することが基本設計で、多通貨機能の挙動はリリース前に複数の国から実機テストで確認します。
9-6. 失敗6：運用フローを設計しないままリリース
サイトはリリースされたが、商品追加のたびに翻訳発注が手作業で発生する。
キャンペーンが日本語版だけで先行し、英語版・中国語版に反映されない。
問い合わせ対応が英語社員に集中する。
こうした運用負荷がリリース後3カ月で顕在化します。
リリース前に、翻訳ワークフロー・運用体制・KPI・チェック体制を明文化し、関係者で合意しておくことが、その後の運用品質を分けます。
まとめ
EC多言語対応は、サイトの文字を翻訳するだけの作業ではなく、URL構成・SEO・通貨・決済・配送・翻訳ワークフロー・運用体制が一体で組み立てられて、はじめて海外ユーザーの購入完了に到達できる構造です。
立ち上げで重要なのは、「対応言語を絞り込み、対応の深さを段階的に上げる」設計を最初に決めることです。
多くの言語を中途半端に対応するより、メイン1〜2言語で完成度の高い体験をつくり、勝ち筋が見えてから段階的に拡大する流れが、運用が回りやすい構成です。
EC多言語対応成功の7つのポイント
-
対応言語を絞り込み、段階的に拡大する：メイン1〜2言語で運用が安定してから、追加言語に進みます。
-
URL構成は事業フェーズと将来像から逆算して選ぶ：サブディレクトリ／サブドメイン／別ドメインの選定は、立ち上げ前の最重要意思決定です。
-
hreflang・canonical・サイトマップを整合させる：SEOの基本設定が乱れると検索流入が伸び悩みます。リリース前監査を組み込みます。
-
機械翻訳＋ネイティブチェックの体制を組む：商品ページ・購入フロー・FAQはネイティブチェックを通します。
-
通貨・決済・配送をユーザーの国に合わせて整合させる：表示価格・決済通貨・配送設定の一貫性が、購入完了率の前提条件です。
-
翻訳メモリと用語集を立ち上げ時から整備する：表記揺れを防ぎ、運用負荷を中長期で抑えます。
-
運用体制と工数をリリース前に設計する：翻訳ワークフロー・KPI・チェック体制を明文化してからリリースします。
最初の一歩を踏み出そう
EC多言語対応の判断は、「海外需要の実データを掴むこと」から始めます。GA4の国別セッション、Google Search Consoleの言語別検索クエリ、SNS・問い合わせの海外ユーザーの存在感を確認し、需要の輪郭が見えた段階で、対応言語と対応の深さを決めていきます。
技術的な実装の前に、運用体制の設計と対応範囲の合意が、その後の成否を分ける起点になります。URL構成・SEO・翻訳ワークフローのどこかで判断に迷いが出てきた段階で、早めに外部の専門家を巻き込むことが、後の手戻りを抑えます。
【無料相談】EC多言語対応の立ち上げをShopifyの専門家が伴走支援します 対応言語の選定、URL構成、SEO設計、翻訳ワークフロー、運用体制まで、貴社のEC多言語化を立ち上げから運用まで伴走支援します。事業計画段階からのご相談を承ります。
[無料で相談する] [資料をダウンロード]
参考文献
-
経済産業省『令和5年度 電子商取引に関する市場調査』2024年（URL: https://www.meti.go.jp/policy/it_policy/statistics/outlook/ie_outlook.html）
-
Baymard Institute “Cart Abandonment Rate Statistics” 2024年（URL: https://baymard.com/lists/cart-abandonment-rate）
-
Google『The Need for Mobile Speed』2018年
-
CSA Research “Can’t Read, Won’t Buy: Consumers in 29 Countries” 2020年
-
Google Search Central『多言語・多地域ページの管理』（URL: https://developers.google.com/search/docs/specialty/international）
-
Shopify公式サイト（URL: https://www.shopify.com/jp）
※本記事中の数値は2026年5月時点の業界統計・公開情報に基づいています。各プラットフォームの料金・機能、各国の規制・税制・主要決済手段は変更される場合があるため、実装前に最新情報をご確認ください。
