冒頭の課題：翻訳が終わっても、顧客は使ってくれない
ある産業機器メーカーの企業サイトは、2025年にお金をかけて中国語サイトを英語、スペイン語、ロシア語に翻訳しましたが、公開から3ヶ月経っても海外からの問い合わせはほとんど増えませんでした。
後から調べたところ：英語版ページのタイトルはまだ中国語のまま、URLは `?lang=en` というパラメータ形式でGoogleにほとんどインデックスされず、スペイン語ページの日付は「2025年10月15日」と書かれていて現地の顧客には理解できず、ロシア語版はエンコーディングが正しく設定されていなかったため一部のページが文字化けしていました。
問題は翻訳ではなく、多言語サイト開発の最初から「言語」をシステム工学として扱っていなかったことにあります。
多言語サイトは翻訳の付属物ではなく、技術アーキテクチャ、SEO、コンテンツ管理、そして後期のメンテナンスに関わります。以下、5つのポイントに分けて、どこで最も問題が起きやすいか、そしてどう回避するかを明確に説明します。
一、言語コードと地域コードを混同しない
多言語開発の第一歩は、まず明確に考えることです：あなたが作りたいのは「多言語」なのか「多地域」なのか？
- 多言語：同じ製品で言語が異なる。例えば中国語、英語、日本語。
- 多地域：同じ言語で地域が異なる。例えば英語をアメリカ、イギリス、オーストラリアに分ける場合、価格、通貨、法規制がすべて異なるためです。
技術的な標準的な方法は `hreflang` タグを使用することで、形式は「言語-地域」、例えば `zh-CN`、`en-US`、`en-GB`、`es-MX` です。
よくある落とし穴：`en` だけを書き、地域を書かない。Googleは誰に向けたものか分からず、他の英語サイトと競合しやすくなります。
推奨される方法：
1. まず表を作り、対象言語と対象地域を分けて書く；
2. すべてのページに `hreflang` を追加し、相互に参照させる；
3. `x-default` を忘れずに追加し、デフォルト版（通常は英語または中国語）を指す。
この表は面倒に見えますが、後のURL、SEO、管理画面構造の基礎となります。多くのサイト開発プロジェクトがやり直しになるのは、このステップをやっていないからです。
二、URL構造を間違えると、後からの変更が非常に痛い
多言語サイトには3つの一般的なURL方式があります：
- サブディレクトリ：`c-mic.cn/en/`
- サブドメイン：`en.c-mic.cn`
- 独立ドメイン：`c-mic-en.com`
三者に絶対的な優劣はありませんが、サブディレクトリを優先することを推奨します。理由は実に明確です：
- メインドメインの権威を各言語版に直接配分でき、新サイトがインデックスされやすい；
- 1つのSSL証明書、1つのCDN設定でカバーできる；
- 後から言語を追加する場合、ディレクトリを追加するだけで、メインサイトの構造を変えなくて済む。
サブドメインと独立ドメインは、ブランドの差異が大きい場合や、現地で個別に届出が必要な場合により適しています。
落とし穴回避の注意：絶対に `?lang=en` のようなパラメータ形式を使わないでください。検索エンジンはパラメータURLの処理が常に苦手で、インデックスが遅く、権威が分散し、後から変更するには大量の301リダイレクトが必要になります。
もし現在企業サイトのリニューアルを行っているなら、このステップはプロトタイプ段階で決めておくのが最善で、ページをすべて書き終えてから変更しないようにしましょう。
三、文字エンコーディングと組版、細部が専門性を決める
文字化けは多言語サイトで最も品位を落とす問題であり、これに勝るものはありません。
技術的な最低ライン：
- サイト全体でUTF-8エンコーディングに統一；
- HTMLに `` を明記；
- データベース、API、エクスポートファイルもUTF-8に統一し、中国語を保存してロシア語を読み出すと疑問符になるのを避ける。
組版の細部：
- アラビア語、ヘブライ語は右から左（RTL）で、CSSに `dir="rtl"` を使い、レイアウト全体をミラーリングする必要がある；
- ドイツ語、ロシア語の単語は長く、ボタンやナビゲーションがはみ出しやすいので、設計時に30%以上の余裕を確保する；
- 日付、通貨、数字の形式は地域に合わせ、サイト全体で1つの形式に固定しない；
- フォントが対象言語をサポートしているか確認する。中国語の思源、日本語のNoto Sans JP、アラビア語のAmiriは一般的な選択肢です。
これらは「美化」の問題ではなく、顧客があなたの専門性を判断する第一印象です。
四、SEOは翻訳ではなく、一からやり直すこと
多言語サイトで最も犯しやすい間違い：中国語のタイトルをそのまま機械翻訳すること。
検索エンジンが見ているのは「このページが現地ユーザーの問題を解決できるか」であり、「この単語が正確に翻訳されているか」ではありません。
やるべきこと：
1. キーワードを再調査する。中国語で「网站安全测试」と検索しても、英語の顧客は「penetration testing service」と検索するかもしれず、語根が全く異なります。
2. タイトルと説明をローカライズする。中国語と英語を混在させたり、中国語の句読点を使ったりしない。
3. コンテンツは直訳だけにしない。例えば：中国語の公式サイトは「公司简介」と書くのが好きですが、英語サイトでは About Us + Our Team + Case Studies という構造がより一般的で、分けて書いた方がインデックスされやすいです。
4. サイトマップを分けて送信する。各言語版で独立したsitemapを生成し、Google Search Consoleでそれぞれ送信する。
5. 内部リンクは言語を一致させる。英語ページから中国語ページにリンクしない。ユーザー体験とクローラーのロジックが乱れます。
もし同時にミニアプリ開発やApp開発も行っているなら、多言語のコンテンツ体系は公式サイトと1つの文案ライブラリを共有するのが最善で、3箇所でそれぞれ翻訳して用語が一致しないのを避けましょう。
五、管理画面：運営が毎回文言を変更するたびに開発を呼ばないように
多言語サイトの公開は始まりに過ぎず、本当に大変なのは後期のメンテナンスです。
具体的なシナリオ：越境予約サービスを行う会社で、公式サイトに中国語、英語、日本語の3バージョンがあり、同時に予約ミニアプリ開発もあります。運営がキャンペーン文案を1つ変更するたびに、3つの管理画面にそれぞれログインし、3回変更し、3回公開し、しかもよくある言語を漏らしてしまいます。
合理的な方法：
- 管理画面は「1つのコンテンツ項目 + 複数の言語フィールド」の構造を使い、3つの独立したコンテンツを作らない；
- 言語間でコピー、対照、翻訳待ちのマークができる；
- ExcelやCSVへのエクスポートをサポートし、翻訳後にインポートできる；
- フロントで言語を切り替える際、できるだけ現在のページに留まり、ホームページに戻らないようにする。
この構造は前期に2〜3日多く設計に費やすことで、後期に大量のコミュニケーションコストを節約できます。
どのような場合にMIC Studioに依頼するのが適切か
あなたのプロジェクトが以下のいずれかに該当する場合、自力で対応すると遠回りになりがちです：
- 公式サイトを単一言語から3言語以上に拡張し、SEOインデックスも考慮する必要がある；
- 企業サイトのリニューアルで、同時に管理システムと多言語コンテンツライブラリを接続する必要がある；
- ミニアプリ開発またはApp開発で、公式サイトと1つの多言語文案を共有する必要がある；
- 海外サイト公開前にセキュリティテストを行う必要がある。特にフォーム、決済、ログインに関わる部分；
- 既存サイトで文字化け、インデックス異常、言語リダイレクトの混乱が発生し、調査が必要。
MIC Studioは企業サイト、ミニアプリ、App、スクリプト開発を行い、サイトのセキュリティテストやリバーステストも行っています。多言語プロジェクトでは、通常まず半日かけて言語表、URL方式、管理画面構造を整理してからコードを書き始め、公開後のやり直しを避けます。
結び：3つの実行可能な提案
1. まず表を決めてから動く。対象言語、地域、URL方式、デフォルト言語を1ページの文書に書き、チームが確認してから開発する。
2. エンコーディングとhreflangを一度で正しく行う。UTF-8を全チェーンで統一し、すべてのページにhreflangとx-defaultを追加し、第2期に補完しない。
3. 管理画面は「1コンテンツ多言語フィールド」で設計する。今は2言語しかなくても、拡張可能な構造で作り、言語追加時に再構築しなくて済むようにする。
多言語サイト開発のハードルは翻訳ではなく、アーキテクチャと細部にあります。これらのことを明確に考えれば、海外顧客の信頼度は明らかに変わります。