多言語情報ポータルのウェブサイトを作る方法

目的、対象、言語の優先度から始める

翻訳ツールや言語切替を考える前に、ポータルの目的と誰にサービスを提供するかを明確にします。このステップは後で無駄な「全部翻訳する」判断を防ぎ、コストを節約します。

ポータルの目的を定義する

多言語情報ポータルにはいくつか典型的なパターンがあります：

• ニュースと更新（時宜性が重要で、古いコンテンツは完全翻訳が不要なこともある）
• ガイドとリソース（恒久的なページでローカライズの恩恵が大きい）
• FAQとサポート（問い合わせ削減が測定可能な成果）
• ディレクトリ（サービスや連絡先の一覧。正確さと地域差が重要）

「居住者が公的サービスを見つけ、適格要件を理解できるようにする」といった一文の目的を書いてください。この目的が、どのコンテンツを優先して翻訳するかの判断基準になります。

対象と地域（必要なもの）を列挙する

言語は単なるチェックボックスではありません。次を特定してください：

• 主要ユーザーグループ（居住者、訪問者、専門家、学生、パートナー）
• 対象地域（ある言語は特定の都市や国のみで必要かもしれません）
• 訪問の意図（クイックな回答、深い調査、フォーム、連絡先）

分析データやサポートログがあれば、どの言語とトピックに需要があるかを確認しましょう。

何を翻訳すべきか、何を単一言語にするか決める

すべてのコンテンツが同じ価値を持つわけではありません。実用的には各コンテンツ種別を次のようにラベル付けします：

• Must translate：重要なジャーニー（申請方法、適格要件、緊急情報、主要ポリシー）
• Should translate：トラフィックの多いガイド、上位FAQ、オンボーディングページ
• Can stay single-language：内部アナウンス、ニッチな更新、技術文書

また、完全ローカリゼーション（分かりやすく書き直す）にするのか、基本的な翻訳にするのかの区別も決めてください。

成功指標を早めに設定する

小さめの測定可能な成果を選びます。例：

• ローカライズページへの検索トラフィック
• 言語別のサインアップやリソースダウンロード
• 主要ガイドでの滞在時間／スクロール深度
• 誤解によるサポート問い合わせの減少

これらの指標が言語や優先度の決定に役立ち、ローンチ後にポータルが機能していることを証明します。

複数言語のための情報アーキテクチャを計画する

多言語情報ポータルは構造で成功するか失敗するかが決まります。翻訳を始める前に、サイトの「形」が明確で一貫しており、言語を超えて再利用しやすいことを確認してください。

インベントリから始める（実際に公開するもの）

コンテンツタイプと相互関係を一覧化します。多くのポータルでは記事、カテゴリ、タグ、ヘルプ文書／FAQ、フォーム（連絡、フィードバック、ニュースレター、提出）が含まれます。法的ページ、告知、ダウンロード資源、地域ベースのページなどもメモしておきます。

すべてを一箇所で見れば、どの種類が全言語で必須（例：コアヘルプ）か、どれが任意か（例：地域ニュース）を決められます。

どこでも通用するサイトマップを作る

翻訳後でも意味が通るサイトマップを目指しましょう。単純な構造は管理が容易で、言語切替時のナビゲーションが使いやすくなります。

トップレベルのセクション数を少なく保ち、「雑多」なバケットを作らないでください。成長の余地が必要なら、新しいトップレベルを増やすのではなく既存セクションの下に第二階層を計画しましょう。

タクソノミーを標準化する：カテゴリとタグ

カテゴリの意味は言語ごとに一貫させます（ラベルは変わって良いが、基底概念は安定させる）。これはナビゲーション、検索フィルタ、分析、共通テンプレートで重要です。

タグは増えやすく、一貫して翻訳するのが難しいため注意してください（例：「how-to」と「guide」の重複）。タグを使う場合はルールを定めてください：誰が作成できるか、いつ統合するか、どのように翻訳するか。

コンテンツのパリティ vs 言語固有セクションを決める

早い段階で以下のモデルのいずれかを選んでください：

• 同一構造＋同一コンテンツを各言語に（サポートやドキュメント向け）
• 同一構造＋部分的翻訳（ブログやリソースセンターで一般的）
• 言語別セクション（法律やサービスが異なる場合に有用）

言語別セクションを許可する場合、ポータルが時間とともに三つの異なるサイトに分岐しないように明確に文書化してください。

スケールする言語URL構造を選ぶ

URLパターンは後で変更するのが難しい決定です。言語、セクション、編集者を増やしても明確さを保てる構造を選んでください。

主なURLオプション（と意味）

1) サブディレクトリ: /en/、/es/、/fr/

1ドメイン内にすべてを置けるため、多くの情報ポータルで最も一般的な選択です。管理が簡単で、1つの解析プロパティで追跡しやすく、運用コストも比較的低いです。

2) サブドメイン: en.example.com、es.example.com

ローカルチームやインフラ、リリースサイクルが分かれている場合に有用です。欠点は各サブドメインが別サイトのように扱われ、SEO、解析、クッキー、ガバナンスで負担が増すことです。

3) 別ドメイン: example.es、example.fr（または全く別のドメイン）

強い国別ブランディング、現地法や現地ホスティングが必要な場合に最適ですが、ドメインごとに権威構築が必要で作業量が最も増えます。

デフォルトの推奨

ほとんどのポータルではサブディレクトリ（例：/en/、/es/）を使い、各言語で同じコンテンツ構造を保つことを勧めます。

チームやプロパティが半分独立して運営される場合はサブドメインを選び、明確なビジネスや法的理由がある場合のみ別ドメインを検討してください。

URLは読みやすく一貫させる

人間に読みやすいスラッグを使い、安定させ、階層を反映させます：

• /en/help/getting-started/
• /es/ayuda/primeros-pasos/

スラッグを翻訳するかはユーザーにとって分かりやすい方を選び、編集者がバラつかせないようルールを文書化してください。

リダイレクトとcanonicalのルール

1つのデフォルト動作を設定（例：/を/en/にリダイレクトする、または言語セレクタを表示する）し、一貫して適用します。

トラッキングパラメータや代替パスだけで違う複製ページを避け、廃止URLは301、重複が避けられない場合はcanonicalタグで推奨版を示してください（印刷ビューやフィルタ付き一覧など）。

言語切替とユーザー体験を設計する

言語切替が違和感なく機能することが重要です。言語切替は装飾ではなく、すべてのページで一貫したコアナビゲーション要素にするべきです。

スイッチャーの配置とラベル

ヘッダーに明確な言語切替を置き、検索からのランディングページでも見えるようにします。スクロールするユーザー向けにフッターにも二次的に置くと良いでしょう。

国旗ではなく言語名（「日本語」「English」「Español」など）を優先してください。国旗は国を表すもので、言語を正確に表さないため混乱を招きます。

自動検出：助けにはなるが支配しない

ブラウザ設定や位置情報に基づいて言語を提案できますが、ユーザーを強制転送して閉じ込めないでください。一般的なパターンは控えめなバナー表示：「¿Prefiere Español? スペイン語に切り替えますか？」のように案内し、ユーザーが閉じたらしばらく表示しないようにします。

ユーザーの選択を記憶する

ユーザーが言語を選んだら、クッキーで保存し、アカウントがある場合はプロファイルにも保存してください。目標はシンプル：一度選べば、その言語でサイトが表示され続けることです。

翻訳がない場合のフォールバック

未翻訳ページに対しては計画を立てておきます：

• 選択言語を保ちながら、そのページがまだ翻訳されていない旨をやさしく表示
• デフォルト言語版へのリンクを明確に表示
• 代替として該当カテゴリページ、検索結果、ホームを案内する

これにより行き止まりを避け、翻訳進行中でも信頼を維持できます。

多言語ポータルに適したCMSとツールを選ぶ

CMSの選択は、多言語公開を日常業務にするか、更新ごとに大作業にするかを決めます。プラットフォームを比較する前に、何を公開するか（ニュース、ガイド、PDF、アラート）、更新頻度、言語ごとの責任者を書き出してください。

多言語の基本機能を確認する

「多言語サイト」はページ本文の翻訳だけではありません。プラットフォームが次を言語ごとに管理できるか確認します：

• ページと再利用ブロック（ヘッダ、フッタ、バナー）
• メニューとナビゲーションラベル
• SEOメタデータ（タイトル、説明、ソーシャル共有用テキスト）
• メディアフィールド（キャプション、altテキスト）

また、CMSが「翻訳欠け」をどう扱うかも重要です。英語の更新を公開してもスペイン語版のナビゲーションが壊れないか確認してください。

CMSの検討ポイント

WordPressやDrupalのような従来型CMS、ホスト型ビルダー、ヘッドレスCMSのいずれでも、次の機能を評価してください：

• 明確なコンテンツモデリング: 翻訳を元ページにリンクでき、ステータスが一目で分かること
• 柔軟なワークフロー: 下書き→レビュー→承認→公開が言語ごとに運用できること
• 拡張可能なURLサポート: 選んだ言語URL構造をハックなしでサポートできること

ヘッドレスCMSを検討する場合、フロントエンド保守が可能なチームがいるか確認してください。いなければマネージドCMSの方が適しています。

独自構築する場合、Koder.aiのようなvibe-codingプラットフォームはプロトタイプやフルスタックの迅速出荷に実用的です：チャットで多言語IAやURL構造（例：/en/、/es/）、コアテンプレートを説明し、計画モードやスナップショット、ロールバックで反復できます。ReactベースのフロントエンドとGo/PostgreSQLのバックエンドを素早く作り、後でソースコードをエクスポートできる点が便利です。

権限、役割、編集統制

多言語ポータルは厳格なガバナンスが有効です。次を検討してください：

• 翻訳者アカウントの限定アクセス
• 言語ごとのレビュアー／編集者ロール
• 誰がいつ何を変更したかの監査履歴

これにより誤って別言語を編集する事故や承認プロセスのばらつきを防げます。

時短に役立つ統合

CMSが既存のツールと連携できるか確認します：

• 翻訳管理（エクスポート／インポート、翻訳メモリ、用語集）
• フォーム（ローカライズされた確認メッセージと通知）
• 解析（言語別レポート）
• 検索（言語認識インデックスとシノニム）

数ページやメタデータ、メニューを翻訳してエンドツーエンドで試す短いパイロットが、機能チェックリストより多くを明らかにします。

翻訳ワークフローとコンテンツガバナンスを構築する

各言語を一貫して更新し続けるには「翻訳に回す」以上のルール、権限、予測可能なパイプラインが必要です。

共有スタイルガイドを作る

軽めのスタイルガイドを翻訳者と編集者で共有します。実用的に：

• トーンとボイス: 形式的かフレンドリーか、呼称（あなた／我々）、読みやすさのレベル
• 用語集: 主要用語（プログラム名、機能、法的語句）の承認済み訳語と翻訳しない語
• 名前と用語のルール: 製品名、組織名、地名、頭字語、大文字化、日付や数字の扱い

これにより「同じ概念なのに訳語が3つある」問題を減らし、検索やサポートを楽にします。

翻訳アプローチを選ぶ

多くのポータルは混合アプローチを使います：

• プロ翻訳者：公開向け、法的／機密コンテンツ
• 社内翻訳：バイリンガルの主題専門家がいる場合
• 機械支援ワークフロー（MT＋人によるレビュー）：量が多くリスクが低い更新向け

コンテンツ種別ごとにどの方法を使うか定義してください。不安があるなら初めは厳しめ（人のレビュー多め）にし、品質が確認できたら緩めていくと良いです。

役割を明確にしたレビュー経路を作る

ハンドオフは明確に：翻訳者 → 编辑者 → パブリッシャー。

編集者は意味、トーン、用語、基本的な使いやすさ（リンク、見出し、CTA）をチェックします。パブリッシャーはページのレンダリングやソース版の意図との整合性を確認します。

受け入れ基準を単純に定義してください：「文字列の抜けなし、全ボタン翻訳済み、スクリーンショットは避けるかローカライズ、メタデータ含む」など。

翻訳が遅れないようにする

ある言語が数ヶ月遅れるとユーザー信頼を失います。ルーチンを作りましょう：

• 更新を**大（翻訳必須）と小（待っても良い）**にタグ付け
• SLAを設定（例：上位ページは48時間以内、長文は1週間以内）
• バックログとペースを維持（週次の翻訳バッチ＋月次監査）

一貫性が重要です。定期的なチェックと明確な責任が、各言語版の乖離を防ぎます。

デザインのローカライズ（フォント、フォーマット、RTL）

完璧な翻訳があっても、デザインが単一言語前提だと違和感を与えます。幸い、多くのデザイン対応は早期に計画すれば対処しやすいです。

言語差に合わせた余白を確保する

言語によって文字数が増減します（ドイツ語は長くなることが多い、ロシア語は行長が増える、アジア言語は読みやすさのために大きめのフォントが必要になることがあります）。ボタンラベルの語順も変わりうるためデザインは柔軟に：

• 固定高さのカードより自動高さのコンポーネントを優先する
• 画像にテキストを埋め込まない（ラベルがリサイズできるようにする）
• 主要テンプレート（ホーム、記事、ナビゲーション、カード）を長めの文言でテストする

使用フォントは必要な言語を実際にサポートするものを選ぶ

英語で良く見えるフォントでもキリル文字やギリシャ文字、ベトナム語のダイアクリティカルマークが欠けていることがあります。フォントファミリー（またはペア）で必要な文字集合をカバーしているか確認してください。

実務チェック：

• デザイン承認前にグリフのカバレッジを検証する
• 適切なフォールバックを定義する（□の豆腐表示を避ける）
• スクリプトによって見た目の太さが変わる点に注意する

右から左（RTL）対応は後回しにしない

アラビア語やヘブライ語を将来扱うなら、今のうちからRTLを想定してください。RTLは単なる左右反転ではなく、ナビゲーション順、アイコン、アライメントに影響します。

考慮点：

• レイアウトが方向反転できる（パディング、マージン、アイコン）
• 矢印や「次へ／前へ」などのアイコンがRTLでも意味を保つ
• 混在コンテンツ（アラビア語と英語の製品コードなど）が読みやすいこと

ローカルフォーマット：日付、数字、単位

表示フォーマットは信頼感に直結します。ユーザーが期待する形式で表示してください：

• 日時（12/24時間、月/日順序、週の始まり）
• 数字（小数点のカンマかドット、千位区切り）
• 単位と通貨（メートル法かヤード・ポンド、ローカライズされた通貨表示）

これらはデザイン要素として扱い、十分なスペースを確保し、あいまいなフォーマットを避け、一貫性を保ちます。

多言語SEOの基本（迷わないために）

多言語SEOは主に“明確さ”の問題です：どのページがどの言語／地域に対応しているかを検索エンジンに示し、各バージョンが本当に有益であることを確かめます。

各言語でページ上の基本を整える

本文だけでなく各言語版に以下が必要です：

• ページタイトル（titleタグ）とメタディスクリプション
• 主要見出し（H1/H2）— 意味やキーワードが変わる場所は翻訳する
• 画像のaltテキスト（機能的な画像は特に重要）

自然な表現を目指してください。逐語訳のタイトルはCTRを下げることがあります。

hreflangで対応ページを紐づける

Googleにどのページがどの言語版かを示すためにhreflangを使います。重要なルール：

• 対応するページ同士をリンクする（ホームだけでなく個別ページで）
• hreflangは相互に設定する（ENがESを指すならESもENを指す）
• 言語コードは正確に（en、es、fr-CAなど）。グローバルなデフォルトがある場合はx-defaultも検討する

言語のみか地域指定まで使うか迷う場合は、理由がない限り最初は言語のみで進めてください。

自動翻訳だけの薄いページを避ける

大量の機械翻訳を最低限の編集で公開すると品質低下として評価される可能性があります。代わりに：

• 重要なページを優先（上位ランディング、意図の強いガイド、FAQ、重要ポリシー）
• トラフィックとビジネス目標に基づき段階的に言語カバレッジを拡大する

言語別サイトマップを提出する

プラットフォームが対応するなら、言語ごとのサイトマップ（またはサイトマップ・インデックス）を作成すると発見が早く、言語別のインデックス状況のデバッグが容易になります。

最後に、Google Search Consoleでディレクトリやサブドメイン別にパフォーマンスを確認し、問題をスケールする前に修正してください。

ナビゲーションと検索を各言語で機能させる

多言語情報ポータルの成否は“見つけやすさ”で決まります。同じトピックが各言語で同じメンタルモデルで見つかることが不可欠です。

検索の挙動を決める

サイト内検索を言語ごとにするか横断にするかを早めに決めてください：

• 言語ごと検索はシンプルで混乱が少ない：インターフェース言語に一致した結果を返す
• 横断検索はリソースが薄い言語や上級ユーザー向けに有用だが、結果に言語ラベルが必要

迷う場合はまず言語ごと検索で始め、必要なら後で「他言語も含める」トグルを追加します。

「この言語で検索」をデフォルトにする

フランス語版を閲覧しているなら検索はまずフランス語結果を返すようにします。UI上で現在の言語を検索ボックス近くに表示し、他言語の結果がある場合は別見出しでグルーピングしてください。

ナビゲーション、フィルタ、タグを一貫して翻訳する

ナビゲーションはメニューだけではなく、カテゴリ名、フィルタ、トピックタグ、パンくず、関連コンテンツも含みます。これらは管理語彙として扱い、単なるフリーテキストにしないでください。

共有タクソノミー（簡単なスプレッドシートで可）に次を含めます：

• 正準概念（例：「公衆衛生」）
• 各言語の承認訳
• 曖昧用語の注記（2つの語が当てはまる場合の扱い）

これにより「Help Center」が「Support」「Assistance」「Customer Help」に翻訳されて別物に見えるリスクを避けられます。

多言語対応の404を用意する

404ページは翻訳やリストラ中のリンク切れ時に重要なナビゲーションツールです。良い多言語404は：

• 訪問者の現在の言語で表示される
• 行き先近くに留めるよう言語切替を提供する
• トップリンク（ホーム、主要カテゴリ、問い合わせ）と検索ボックスを提示する

人気のある恒久的リソースがあれば「よく見られているリソース」も提示してセッション回復を助けます。

フォーム、アクセシビリティ、主要ジャーニーのローカライズ

最後の一歩（申請送信、更新購読、資料ダウンロード、問題報告）がうまくいかないと、部分的な翻訳は破綻します。UI文言、バリデーション、メールテンプレ、法的通知が混ざるため、部分翻訳はすぐに不自然になります。

フォームはラベル翻訳以上の作業

フル体験をローカライズしてください：

• フィールドラベル、プレースホルダ、ヘルパーテキスト（機械的でない、行動を促す表現）
• バリデーションとエラーメッセージ（地域のフォーマット期待に合わせる）
• 成功状態（確認画面、バナー、「次に何が起こるか」の案内）

またフォームがトリガーするトランザクションメッセージ（確認メール、パスワードリセット、チケット受付）は、ユーザーの言語設定に基づいて送るべきです。

各言語でのアクセシビリティ

アクセシビリティは原文よりそれぞれの翻訳で影響を受けます。各言語で検証してください：

• コントラストと読みやすさ（特定スクリプトでフォントが薄く表示されることがある）
• キーボード操作（タブ順、フォーカス表示、ダイアログの罠がないこと）
• ラベルの明確さ（プレースホルダだけに頼らない）

アイコンのツールチップなどはスクリーンリーダー向けの説明を翻訳して提供してください。

地域ごとの法的／同意要件

Cookieや同意バナー、法的ページは地域ごとに異なることがあります。文言を翻訳するだけでなく、同意を得るまで何をブロックするかの挙動も地域要件に合わせてください。必要に応じてプライバシーポリシーや利用規約など地域別ページを用意します。

実際のレビューで主要ジャーニーをテストする

ローンチ前にネイティブレビュアー（または専門のレビュアー）でタスクベースのチェックを行ってください：フォームを送信し、すべてのエラーを発生させ、確認フローとメール内容を検証します。実際の利用テストは自動チェックでは見つからない不自然さや抜けを明らかにします。

ローンチ、パフォーマンス測定、長期運用

多言語ポータルはローンチで終わりではありません。言語ごとの成果をどう測り、更新をどう管理するかが信頼性を保つ鍵です。

多言語リリースチェックリストでローンチする

新しいページや大規模リデザインの前にチェックリストを使い、すべての言語が同じ品質で公開されるようにします：

• UI文字列の翻訳（ナビ、ボタン、システムメッセージ）
• ページコンテンツの翻訳とレビュー（必要なaltテキスト含む）
• メタデータのローカライズ（titleタグ、meta description、Open Graph）
• 正しいcanonical URLと言語注釈（hreflang）
• 言語切替が実際の同等ページを指していること（デフォルトでホームに飛ばさない）

このチェックをゲートにしてください：重要要素が欠けている場合は、言語ページを隠すか、完成するまで公開を待ちます。

サイト全体ではなく言語別にパフォーマンスを測る

「スペイン語はどうか？」と答えられるように、言語別のレポートを用意します。追跡項目例：

• トラフィック推移と流入元
• 上位ページ（発見されていないページはどれか）
• コンバージョンと離脱点（サインアップ、問い合わせ、ダウンロード）
• 検索クエリとインプレッション（ローカル語のキーワード）

これにより翻訳の質の問題（直帰が高い）と発見性の問題（インプレッションがない）を区別できます。

更新後の翻訳抜けやリンク切れを監視する

多言語サイトでよく起きる静かな破損：英語ページが公開されてもフランス語版が404になる、スラッグが変更され一方だけが更新される、など。次のアラートを用意しましょう：

• 翻訳プレースホルダの残存
• 言語別の内部リンク切れ
• URL変更によるリダイレクトチェーン

保守はルーチンで計画する

四半期ごとの監査をスケジュールしてコンテンツとSEOを同期させます：

• 言語ごとの上位トラフィックページの正確性と鮮度をチェック
• 言語バージョン間のギャップを比較（欠落セクション、古いスクリーンショット、古いポリシー）
• 大規模なコンテンツ投入後にhreflangとインデックス状況を検証

一貫した小さなチェックが、突発的な大掃除より強力です。小まめな管理で多言語ポータルの信頼性を維持してください。