【多言語サイトを構築する】 ①対象言語・地域とURL方式の選定

1. 対象言語・地域の選定

まず1番最初に行うべきことが、「言語か地域か」の選択です。例えば「まずは自社の情報を広く世界に届けたい」と思えば、コンテンツを英語で提供することになるでしょう（本来この粒度の戦略ではいけませんが…）。これは、言語ベースの選定です。

対して「ベルギーの顧客/ペルソナに対して、自社の情報を届けたい」というように、特定の国や地域をターゲットとして情報展開を行いたいこともあるでしょう。これは地域ベースの選定です。

まずはこの2つについて、詳細を解説します。

1-1. 言語ベースの方針策定

言語ベースで方針策定する場合、当然まずは言語を選定します。しかしながら、日本語のように「1つの言語が、主に1つの国でしか使用されていない」という状況はどちらかというと稀で、たいていは言語を選定した後に、対象とする地域を選定する作業が必要になります。

「コンテンツを英語にしたから、全世界の人々に広く自社の情報を届けられる」と思うのは間違いとは言い切れませんが、戦略としてはとても不十分です。

1-1-1. 対象地域を選定する

例えば英語にしても、英語を第一言語とする国々の間ですら、単語や文法的な差違が少なからず発生しています。よくイギリス英語・アメリカ英語といいますよね。実際はこの2つだけでなく、オセアニアやアイルランドを始めとする英語を第一言語とする国/地域は、その数だけ差違があると思ってよいでしょう。

もう少し分かりやすく考えるならば、英語の差違を「日本語における方言」と捉えてみてください。 例えば、ゴリゴリの関西弁で文章が書かれたwebサイトがあったらどうでしょうか？関西の人にはとても親しみやすく、企業に対する好感度が自然と上がるかもしれません。 しかし他の地域の人にとっては読みづらく、ときに意味を読み取れない表現もあるでしょう。

日本語の方言で考えるととてもおかしなことをしているように思えますが、「とりあえず英語に」というのは、実は同じことをしています。 イギリス英語で書かれたコンテンツをアメリカ人が見たら「これはイギリス向けのコンテンツだな」と思いますし、逆もまた然りでしょう。

この問題はもちろん英語に限らず、例えばスペイン語など、広く話されている言語であればあるほど起こり得るものです。 「言語を選択して終わり」ではなく、その先の「そもそもどの地域の人に届けたいのか」をきちんと考えるようにしましょう。

1-2. 地域ベースの方針策定

最初から対象地域が決まっている場合は、言語の選定が後から付いてきます。例えば冒頭に挙げたように、対象地域をベルギーとしましょう。 ベルギーは公用語が

• オランダ語
• フランス語
• ドイツ語

の3つあるので、ベルギー全域を対象とするならばこの3言語に対応する必要があります。

他にも例えば東南アジア全域を対象とするのであれば、対応言語は

• ベトナム語
• インドネシア語
• マレー語
• 英語
• フィリピン語
• ビルマ語…

と多岐に渡ります。

いずれの場合も全ての言語に対応できればもちろんベストでしょうが、現実的にはコストの問題もあります。 地域を絞ればそれだけ対応言語が少なくなる傾向がありますので、予算と「本当に情報を届けたい層」を照らし合わせて、地域の選定を行うとよいでしょう。

2.公開URL方式を選定する

次に考えるべきは、公開URL方式です。これは主に

• 国別ドメイン方式
• サブドメイン方式
• ディレクトリ方式
• URLパラメーター方式

の4通りの方法があり、それぞれにメリット・デメリットがあります。それぞれの詳細解説をする前に、先に表にまとめましょう。

参考：多地域、多言語のサイトの管理 - Search Console ヘルプ

2-1.国別ドメイン方式

これは例えば「example.us（アメリカドメイン）」「example.uk（イギリスドメイン）」など、国別に定められている2文字からなるトップレベルドメインを取得する方式です。 国別コードトップレベルドメインの英語の正式名称は「country code Top Level Domain」で、略してccTLDと呼ばれます。 取得条件が厳しい国もあれば、お金さえ払えば誰でも取得できる国もあり、取得難易度は様々です。 ちなみに日本のccTLDは「.jp」です。

地域ターゲティングの性質が1番強いため、現地のユーザーにも受け入れられやすく、また日本語のサイトとは完全に分離しやすいのがメリットです。 しかし、ドメインの取得に費用がかかったり、サーバーやシステムの設定が必要であったりと、決してコストは低くありません。

1点注意点として、「.asia」や「.eu」などの地域を表すドメインは、GoogleではccTLDとは見なされず、次のサブドメイン方式で解説するgTLDと見なされます。

参考：Google ウェブマスター向け公式ブログ: 多地域向けウェブサイトの構築

2-2.サブドメイン方式

次の手法として挙げられるのが、サブドメイン方式です。例えば元サイトが「exaple.com」だとすると、「us.exaple.com（アメリカ向け）」「uk.example.com（イギリス向け）」のようにドメイン冒頭に任意の文字列を付加する方式です。

「.com」や「.net」など特定の国に関連付かないドメインを「generic Top Level Domain」、略してgTLDと呼びます。 サブドメイン方式を採用するのであれば、ccTLDではなく、gTLDドメインを使用するのが一般的です。

• △ us.example.jp
• ○ us.example.com

またサブドメイン方式で用いるドメイン冒頭の文字は任意であるため、ccTLDと同様の国別コードである必要はありません。 かといってあまりに自由な文字列は、ユーザーがURLから法則を推測できず、ターゲティングとしても効果が下がるので推奨しません。

ではどうするべきかと言うと、「対象とする国/地域が決まっている」という場合は、先ほど出てきた国/地域別コードを使用する方法が挙げられます。「地域をターゲティングせず、あくまで言語ベースでの多言語サイトとしたい」という場合は、言語コードを使用します。 また言語ベースでありつつも地域ターゲティングも同時に行いたい場合は、国/地域別コードも付け加えることが可能です。 まとめると、以下のような選択肢が考えられます。

• us.example.com（国別コードのみ）
• en-us.example.com（言語別コード + 国別コード）
• en-uk.example.com（言語別コード + 国別コード）
• en.example.com（言語別コードのみ）

上から順に、地域ターゲティングの性質が強くなります（中2つはもちろん同列です）。 ただし国別コードを含む方式は、対象とする国が増えれば増えるほど、管理すべき設定項目や、コンテンツが増えることに注意してください。

また1点注意点として、一般的なccTLDと国別コードが一致していない国もあります。例えば今までイギリスは「uk」と紹介しておりますが、正式な国別コードは「gb」です。ccTLDとしてはどちらもありますが、「uk」の方が一般的に使用されています。サブドメイン方式は任意の文字列を付けられますので、より一般的な方を採用するとよいでしょう。
正式な国別コードはISO 3166-1にて定義されていますので、ぜひそちらも参考にしてください。

以上のようにそれなりに自由度が高く、かつそれなりに地域ターゲティングの性質も持っているため、メリット・デメリット含め国別ドメイン方式とディレクトリ方式のちょうど中間といった形になります。

2-3.ディレクトリ方式

次にご紹介するのがディレクトリ方式です。これは今までとは違ってドメインに変更を加えず、「example.com/en」など言語毎にディレクトリ（ページ）を作成する方式です。

今まで紹介した方式に比べ地域ターゲティングの性質が弱くなりますが、ドメインに変更を加えないため1番導入しやすく、かつコンテンツの管理もしやすいのが特徴です。 「コンテンツを管理しやすい」ということは、一方で「サーバー・システムを分離しづらい」ということでもあるため、ディレクトリ方式は元のサイトからデザインが変わらない多言語サイトに向いています。

ディレクトリ名にはもちろん任意の文字列が使えますので、サブドメイン方式と同じように以下のような選択肢が一般的です。

• example.com/us（国別コードのみ）
• example.com/en-us（言語別コード + 国別コード）
• example.com/en-uk（言語別コード + 国別コード）
• example.com/en（言語別コードのみ）

サブドメイン方式と同じく、国別コードを含む方式は対象とする国が増えれば増えるほど、管理すべき設定項目や、コンテンツが増えることに注意してください。

また下層ページも多言語化した際のディレクトリ構成としては、主に下記2パターンが挙げられます。元の日本語のページを「example.com/compnay/about」とします。

• example.com/en/compnay/about（第一階層にディレクトリを置く）
• example.com/compnay/about/en（各ページの中に都度ディレクトリを置く）

どちらの方式がよいかを断言できるデータは、残念ながら今のところありません。 筆者の考えとしては、第一階層にディレクトリを置く方式の方がURLが統一的であり、URLを直接編集して遷移する場合もユーザビリティは良いと思います。
また事実として、HubSpotは第一階層にディレクトリを置く方式を採用しています。この辺りはCMSによっては自動的に選定されることもあるので、使用するCMSの目処が付いているのであれば、変に悩まず、先にCMSの仕様を確認することをオススメします。

2-4.URLパラメーター方式

最後にURLパラメーター方式ですが、これはGoogleが非推奨としていますので、基本的に採用しない方がよいでしょう。 一応、今までと同じく各パターンの実装例を挙げると、下記のようになることが考えられます。

• example.com/?loc=us（国別コードのみ）
• example.com/?lang=en&loc=us（言語別コード + 国別コード）
• example.com/?lang=en&loc=uk（言語別コード + 国別コード）
• example.com/?lang=en（言語別コードのみ）

まとめ

以上のように、対象地域や言語、URL方式だけでもいろいろと考えるべきことがあります。 細かいことを考え始めると悩みがつきませんので、まずは

• 「誰に届けたいのか？」
• 「なぜ届けたいのか？」

など、戦略の本質を忘れずに検討してみるとよいでしょう。

ここまででURL方式までは決まりましたので、次回はCMSについて解説します！（3月中旬公開予定。鋭意執筆中……）

以降の記事も基本的に筆者作成の構築フロー図に従って解説していきますので、多言語サイト構築を考えられている方はぜひ下記バナーより構築フロー図の導入をご検討ください。