ECサイトを多言語化して海外販売するときの落とし穴。12言語ECを作って分かったこと

こんにちは。TIFFIN開発チームです。私たちはアーチェリー用品ブランドアーチェリー用品メーカーB社様の公式ECサイトを、12言語対応で構築・運用しています。アーチェリーは世界中に競技人口がいるスポーツなので、日本の工房の製品を海外の選手が直接買いに来ます。この案件を通じて痛感したのは、多言語ECの本当の難所は「翻訳」ではないということです。翻訳は入口にすぎません。この記事では、これから海外販売を考えているEC事業者の方向けに、私たちが実際に踏んだ(あるいは事前に回避した)落とし穴を5つ紹介します。

落とし穴1:機械翻訳の垂れ流しで固有名詞が壊れる

今は機械翻訳の品質が高いので、「全ページ自動翻訳でいいのでは」と思いがちです。実際、説明文の翻訳はかなりの精度で通用します。壊れるのは固有名詞です。

製品名・ブランド名・技術用語。たとえばアーチェリーの世界には「リム」「プランジャー」「スタビライザー」のように、競技者なら原語のまま通じる用語が大量にあります。これを機械翻訳が律儀に一般語へ訳してしまうと、現地の競技者が検索で使う言葉と一致しなくなり、SEO的にも存在しないのと同じになります。最悪なのは製品名自体が翻訳されてしまうケースで、ブランドの信頼に直結します。

対策はシンプルで、「翻訳してはいけない語のリスト(用語集)」を最初に作り、翻訳フローに組み込むことです。機械翻訳を使うにしても、用語集で保護した上で、主要言語だけでも競技経験者・ネイティブのチェックを一周入れる。全言語を人手で、は費用的に非現実的なので、売上見込みの大きい言語から傾斜をつけるのが現実解です。

落とし穴2:翻訳は「作業」ではなく「運用」

公開時の翻訳は頑張れば終わります。本当の問題はその後です。新商品を1つ追加するたび、キャンペーンの文言を1行変えるたび、その変更を12言語ぶん追いかける仕組みがないと、更新のたびに翻訳漏れの言語が生まれます。「英語ページは新商品が載っているのにスペイン語ページは古いまま」という状態は、気づかないうちに進行します。

アーチェリー用品メーカーB社様のECでは、文言を「翻訳キー」で一元管理し、新しいキーが増えたら未翻訳の言語を機械的に検出して埋める同期の仕組みを作りました。どの言語に翻訳漏れがあるかが人の記憶ではなくツールで分かる。多言語サイトを1年以上運用するつもりなら、この仕組みには最初に投資する価値があります。逆にここを人力レビューだけで回す前提の見積もりは、運用開始半年後に破綻します。

落とし穴3:配送料と関税を後回しにする

サイトが完成に近づいてから「ところで海外への送料はどうします?」となる案件、実は少なくありません。ここは商売の根幹なのに後回しにされがちです。

• 送料は国別で大きく違う——同じ荷物でも送り先で送料が数倍変わります。国(地域)ごとの料金表をシステムが持てる設計にしておかないと、「一律送料」で損をするか、高すぎて売れないかのどちらかになります
• 重量・サイズで跳ねる——アーチェリーの弓は長尺物です。長さ制限で使える配送手段自体が変わる商品があるなら、商品データに寸法・重量を最初から持たせておく必要があります
• 関税は買い手負担が基本だが、説明しないとトラブルになる——受取時に関税を請求されて「聞いていない」と怒られる、越境ECの定番トラブルです。購入フローに明記するだけでかなり防げます

私たちはアーチェリー用品メーカーB社様のサイトで、配送国ごとの料金枠をCMSから編集できる作りにしました。送料のルールは開発後に固まるものなので、コードを直さず運用側で変えられることが重要です。

落とし穴4:決済と通貨表示

海外のお客様は日本のコンビニ払いも銀行振込も使えません。国際ブランドのクレジットカードが基本線ですが、ここにも段差があります。

• 海外カードの不正利用対策(3Dセキュア等)を有効にしておくこと。越境ECは不正利用の標的になりやすい領域です
• 通貨表示。決済は円建てでも、参考価格として現地通貨の目安が見えるだけで購入率が変わります
• 返金・キャンセルの手順。海外発送後のキャンセルは送料が往復で消えるので、規約を先に作っておく

決済代行はStripeのような国際対応のサービスを使えば技術的なハードルは下がりました。それでも「どの国からの注文を受けるか(受けないか)」は事業判断として最初に決めておくべきです。全世界OKにすると、配送・関税・不正対策の全部が最大難易度になります。

落とし穴5:日本語データ特有の文字の罠

これは地味ですが実害の大きい話です。日本語の商品データには、多言語システムに載せた瞬間に事故る文字が潜んでいます。

代表格が波ダッシュ問題です。「10〜20」の「〜」には見た目がほぼ同じ2種類の文字(波ダッシュとチルダ)があり、システムやOSによって別の文字として扱われます。既存システムから商品データを移行したり、複数システム間で在庫を同期したりするとき、人間の目には同じに見える2つの文字列が、プログラム上は一致しない——これで照合処理が静かに失敗します。ほかにも機種依存文字(丸数字、ローマ数字)、HTMLエンティティ化された記号などが同種の事故を起こします。

私たちも既存ECからの商品データ移行で、この「見た目は同じなのに一致しない」文字と格闘した経験があります。対策は、移行・同期の入口で文字を正規化(表記ゆれを機械的に統一)する処理を必ず一枚挟むこと。多言語ECに限らず、システム間でデータを付き合わせる案件すべてに効く教訓です。

12言語ECの構成で工夫したこと

最後に、構成面の工夫をまとめます。アーチェリー用品メーカーB社様のサイトでは、商品・在庫・決済まわりと、ブランドコンテンツ(読み物、特集、規約など)の管理を分離しました。商品まわりは変更が激しく整合性が命、コンテンツは言語ごとの表現の自由度が欲しい——性質が違うものを1つの仕組みに押し込めないことで、それぞれの更新が互いを壊さなくなります。

まとめると、多言語ECで最初に決めるべきは次の5つです。

• 対象国と対象言語(全世界OKにしない)
• 翻訳してはいけない用語集
• 翻訳漏れを検出できる更新フロー
• 国別の配送料表と関税の説明
• データ移行時の文字正規化

「まず英語だけ」から段階的に広げる設計もできます。海外から問い合わせが来始めている、展示会で海外の反応が良かった——そんな段階でのご相談が、実はいちばん設計しやすいタイミングです。