ECサイトの多言語化は、本文を翻訳APIに送るだけでは終わりません。配送できる市場を決め、商品情報と購入条件を訳し、利用者が選べる言語ページを公開する必要があります。自動翻訳は下書きとして使い、注文前に誤解が起きやすい部分から確認します。
対象は言語と配送市場を別々に決める
英語を話す人が同じ通貨や返品条件を使うとは限りません。中国本土・台湾・香港も一つの販売条件でまとめず、簡体字・繁体字、表現、決済、配送先を検討します。実際に届けられる市場と、問い合わせを受けられる言語から開始してください。
先に翻訳するページを購入順に並べる
商品一覧、詳細、カート、チェックアウト、配送・返品、問い合わせ、注文メールを一続きで確認します。商品ページだけ訳して決済時に日本語へ戻ると、条件を理解できないまま購入されるおそれがあります。公開できない言語は選択肢から外すなど、未完成部分を管理します。
用語集と翻訳しない項目を用意する
素材、サイズ、使用上の注意は商品台帳を基準に用語を統一します。ブランド名、SKU、単位、型番、URLは翻訳対象から外す設計を検討します。法律上の表示や返品条件は、対象市場の条件を確認できる担当者が意味を確認し、自然な文章になったことだけで承認しません。
翻訳APIと公開管理を分ける
DeepLなどのAPIは翻訳処理の部品です。認証キーはサーバーで管理し、対象言語、文字量、上限、エラー時の再処理を設計します。HTMLを扱う場合、DeepLのtag_handlingなど仕様に合う方法を使い、リンクやSKUを含む文書で確認します。API契約だけで言語切替や検索向けURLが自動で完成するわけではありません。
Shopifyは翻訳アプリと市場設定を一緒に確認する
Translate & Adaptでは商品やページなどの翻訳を管理できます。手動と自動の翻訳は運用が異なるため、対応する対象と条件を確認します。テーマや別アプリが出す文言、メール、購入画面も実際に点検し、商品更新時にどの訳が古くなったかを追えるようにします。
WordPressは翻訳データと更新方法を決める
多言語プラグインや外部翻訳サービスを選ぶ際は、商品・在庫連携、言語別URL、SEOタグ、編集権限、翻訳の保存先、停止後の表示を確認します。無料プラグインに翻訳APIやEC対応がすべて含まれるとは限りません。既存ページをバックアップし、テスト環境で購入導線を確認します。
Googleに言語版の関係が伝わるURLを作る
言語ごとのURLと利用者が操作できる切替リンクを用意します。サブドメインとサブディレクトリには運用上の違いがあり、後者が必ず高評価になるわけではありません。hreflangで言語・地域の対応を示し、canonicalと矛盾させないようにします。IPや推測した言語だけで強制転送せず、各版を閲覧できる状態にします。
公開前は翻訳文と実注文を別々に確認する
訳文の意味、金額・単位、文字切れ、検索表示、画像内の文字を確認します。続いて配送先を切り替えて、送料、税の案内、決済、完了メールをテストします。更新担当と確認日を記録し、売上や問い合わせの変化は市場ごとに測定します。翻訳しただけで購入率が一定割合上がるとは言えません。
導入前の確認事項
- 販売市場と対応言語、配送条件を決める
- 用語集と翻訳除外項目を揃える
- APIキー・使用量・失敗時の再処理を管理する
- 言語別URL・タグ・購入メールを全言語で点検する
公式資料・関連記事
関連記事：EC運営ツール10選｜業務別の役割と導入手順、ECにAI APIを導入する手順｜用途・権限・検証。
運用設計や確認項目の整理は、現在の業務と対象URLを添えて株式会社AOへご相談ください。
公式資料の確認日：2026年11月2日。記入例や手順は編集上の提案で、導入成果を保証するものではありません。
コメント