学校・大学のための多言語ウェブサイトの作り方

目標、対象、対応言語を定める

多言語の教育サイトは、まず「誰に向けて何を支援するか」「どの言語が実質的な障壁を取り除くか」が明確なときにうまく機能します。ツールや翻訳手順を選ぶ前に、経営陣、入学課、広報が共通の計画に合意していることが重要です。

主要な対象を特定する

ほとんどの学校・大学サイトは複数のグループにサービスを提供しています。後でコンテンツの優先順位をつけやすくするために、明示的に列挙してください：

• 在校生
• 保護者/後見人
• 教職員
• 卒業生・寄付者
• 国際出願者・交換留学生
• 地域の協力機関

キャンパスやプログラム、年齢層が別れている場合（例：K–12の保護者と大学院出願者）、ニーズの違いをメモしておきます。

訪問者が達成すべき主要タスクを定義する

多言語コンテンツは単に「翻訳されたページ」を増やすためのものではありません。各対象ごとの主要タスクを書き出してください。例：

• 出願要件、締切、授業料を確認する
• 適切な窓口に素早く連絡する
• 各種フォーム（入学、記録請求、住居）を完了する
• ニュースや緊急更新を読む
• カレンダーを見る（学事日程、イベント、休校）

これらが、どの情報を各言語で正確かつ最新に保つべきかを判断する指標になります。

サポートする言語を決める—理由を明確に

言語はエビデンスに基づいて選びます：入学目標、市場、地域人口統計、サポートリクエストなど。出願や支払い、安全情報といった高い影響のあるジャーニーで摩擦を減らす言語から着手してください。リソースが限られる場合は、ローンチ用の「最低限の言語セット」と拡張ロードマップを定めます。

測定可能な成功指標を設定する

成果に結びつく指標を選びます。例：

• 繰り返し寄せられるサポート要求の減少（トピックと対応言語別に追跡）
• 質の高い問い合わせや出願の増加
• 主要ページでのエンゲージメント向上（平均滞在時間、フォーム完了率）
• 入学や連絡ページの直帰率低下

これらの決定を1ページの短いブリーフにまとめ、以降のすべての選択（コンテンツ、デザイン、ワークフロー）が同じ目標を支援するようにします。

コンテンツ監査と翻訳対象の選定

翻訳は「正しい」コンテンツを翻訳したときに最も効果的です。まずはインベントリを作って、何があるのか、何が欠けているのか、翻訳前に廃止すべきものがあるかを把握してください。

完全なコンテンツインベントリを作る

公開されているページやファイルをすべてリスト化します。PDFや家族がよく参照する“隠れた”文書（方針、ハンドブック、入学ガイド、料金表、交通ルール、保護に関する声明、アクセシビリティ情報）も含めてください。フライヤー画像やスキャンしたフォームのようにテキストを含むメディアも含めましょう—これらは単に翻訳するのではなく再作成が必要な場合があります。

シンプルなスプレッドシートで十分です。URL、ページタイトル、担当者、最終更新日、所在場所（CMSページ、PDF、Googleドキュメント）を記録します。

コンテンツを種類と緊急度でラベル付けする

アイテムを次のように分類します：

• エバーグリーン：入学概要、カリキュラム、キャンパス案内、授業料、学生支援、法的/方針系ページ
• 時期限定：お知らせ、カレンダー、イベント投稿、緊急更新、締切リマインダー

これにより、1週間で期限切れになるようなコンテンツを翻訳して無駄にすることを避け、どのコンテンツに迅速な対応が必要か明確になります。

何を必ず翻訳するか決める

各対象（保護者、出願者、在校生、卒業生）について、次のようにマークします：

• 必須（誤解されると大きな影響がある）：出願手順、資格、締切、方針、連絡先
• 推奨：プログラムのハイライト、学生生活、FAQ
• 単言語で可：高度に専門的な研究ニュースやアーカイブ投稿—ただし明確にラベル付けすること

翻訳前に重複を削除する

翻訳は維持作業を増やします。重複ページを統合し、古いコンテンツを削除し、用語（プログラム名、学年表記、事務名）を標準化しておけば、翻訳後の更新管理がずっと楽になります。

多言語サイト構造（URLとナビゲーション）を選ぶ

URL構造は多言語教育サイトの背骨です。SEO、解析、編集ワークフロー、適切な言語版の共有のしやすさに影響します。

よく使われる3つのURL方式

• サブフォルダ: example.edu/es/ や example.edu/fr/
  1つのサイトで管理し、ブランディングが一貫しやすく、解析も簡単です。
• サブドメイン: es.example.edu
  チームが半独立している場合に有用ですが、複数サイトを維持する感覚になります。
• 別ドメイン: example.edu と example.edu.mx（あるいは異なるTLD）
  地域対応の柔軟性は高い一方で、ガバナンス、SEO、コンテンツパリティの負荷が最も大きくなります。

多くの学校・カレッジでは、実務的な既定はサブフォルダです：1つのCMS、1つのデザインシステム、技術設定の一元化、言語間のナビゲーションが簡単になります。

一貫したURLパターンを計画する

予測可能で安定したパターンを決めて維持します：

• 最上位に言語コードを使う：/es/、/ar/、/zh/
• 可能な限りスラッグを揃える：/es/admissions/ は /en/admissions/ に対応させる
• 翻訳しない項目を決める（PDFファイル名や特定の略語、内部システムのパスなど）

一貫性があれば、メニュー、パンくず、翻訳ワークフローの維持が楽になります—特に複数の部署が公開する場合に有効です。

各言語のナビゲーションとパンくず

ナビゲーションは翻訳され、文化的に分かりやすいものであるべきです。示すべきもの：

• 言語ごとのメインメニュー（項目は言語ごとに異なる場合あり）
• 言語別のパンくず（ユーザーが常に現在地を把握できる）
• ページが存在する場合には対応する言語ページへのクロスリンク

すべての言語にページがない場合の扱い

プログラムやフォームなどが一部の言語でしか提供されないことはよくあります。事前に方針を決めてください：

• その言語のナビゲーションから該当ページを非表示にするか
• 「この言語では利用できません」という短い案内ページを表示し次の手順を示すか
• 最寄りの代替ページ（例：英語のプログラム概要）へ案内するか

こうすることで行き止まりを避け、利用者に未完成のサイトという印象を与えません。

CMSを選び公開ワークフローを定義する

多言語教育サイトは日々の運用で成否が決まります。適切なCMSは言語版を作成し、正しい担当者にルーティングし、一人の“ウェブ担当”に依存しない公開を可能にするべきです。

CMSに求める要件

多言語ページやコンテンツタイプをネイティブに（またはサポートモジュールで）扱えるCMSを選びます。契約前に確認すべき主要機能：

• 言語対応のページ管理：各ページが翻訳リンクされ、未翻訳ステータスが分かる
• 役割と権限：学部や部局、中央広報の権限分離
• ワークフロー状態：draft → in translation → in review → approved → scheduled/published など
• リビジョン履歴とコメント：翻訳者とレビュアーが意味確認できる
• 言語ごとのメタデータ：タイトル、説明、ソーシャルプレビューが各ロケールで編集可能

既にCMSを使っているなら、まずは少数ページ（例：入学/連絡）で多言語公開を試して、ギャップを見つけてください。

もし新規でマイクロサイトや多言語イベントハブを作るなら、CMSの外でプロトタイプすることも検討してください。例えば、Koder.ai はチャットベースの仕様から動作するウェブアプリを素早く生成できるため、ページテンプレートや言語切替の挙動、ワークフローを検証するのに便利です。Koder.aiはソースコードの書き出しやデプロイ/ホスティング、スナップショットとロールバックをサポートするため、初期プロトタイピングから本番の引き渡しまで役立ちます。

役割を定義する（誰が何を所有するか）

早期に期待値を設定するために、次のような役割を定義します：

• 編集者（Editor）：原文を作成・管理
• 翻訳者（Translator）：翻訳版を作成（内部スタッフまたはベンダー）
• レビュアー（Reviewer）：用語、トーン、正確性を検証（国際担当やバイリンガルの教職員）
• 公開担当（Publisher）：フォーマット、リンク、準拠性を最終チェックして公開

所有権を明確にします：各部署はプログラム詳細を更新し、中央チームはグローバルナビゲーション、方針ページ、ブランドボイスを管理します。

主要ページのテンプレートを用意する

テンプレートを標準化して翻訳を予測可能にします：

• 入学（要件、締切、授業料、ビザ案内）
• プログラム/学部（概要、学習成果、連絡先）
• 連絡先/キャンパス情報（住所、地図、窓口時間）

テンプレートは再作業を減らし、レビュアーが意味に集中できるようにします。

メディアと代替テキストを言語ごとに忘れない

メディアライブラリは言語ごとのAltテキスト（できればキャプションやトランスクリプトも）をサポートするべきです。Altテキストは意味を伝えるため翻訳が必要で、特にフォームやインフォグラフィック、指示画像では重要です。

言語切替とナビゲーションのUX設計

訪問者が素早く言語を切り替え、元の文脈を保てることが成功の鍵です。国際学生や保護者、教職員は深いリンク（プログラムページ、締切告知）でサイトに来ることが多いため、ホーム以外の場所でも言語体験が機能する必要があります。

スイッチャーは期待される位置に置く

一般にヘッダー（右上）に置き、モバイルでもヘッダーかメニューの最初に入れてください。フッターにだけ置くのは避けます。

ラベルは言語名で表示（国旗だけは使わない）

言語はネイティブ表記で示します： “English”、“Español”、“العربية”。国旗は誤解を招くことがあり、言語は国で一意に示せないためです。

各言語でメニューが読みやすいようにする

メニューの略語は避けます（“Acad.”、“Intl.” など）。「入学」「プログラム」「学生生活」のような短く明確な表現を使い、翻訳後に項目が長くなってもレイアウトが自然に折り返すよう余裕を持たせます。

右から左（RTL）言語への配慮

アラビア語やヘブライ語をサポートする場合は、初めからRTLを設計に組み込みます：レイアウトの鏡像化、適切なタイポグラフィ、アイコンや矢印の配置、フォームの自然な挙動を確認してください。入学や申請などの重要ページは早期にRTLでテストします。

翻訳のない場合のフォールバック挙動を定義する

翻訳がまだないページの扱いを決めます。一般的な対応：

• デフォルト言語を表示し短い注記を付ける（翻訳が進行中であることを知らせる）
• あるいは最も近い翻訳済みの親ページへ誘導する

どちらを選ぶにせよ、ユーザーに通知しない静的な挙動は避けます。

翻訳とレビューのプロセスを作る

多言語サイトは信頼が基盤です。教育機関では入学や安全、方針といった情報が信頼できるものである必要があります。

人による翻訳が必要なものを決める

リスクと影響度に応じて分類します。人翻訳を必須にすべき重要ページ：

• 出願・申請手順
• 授業料、手数料、返金ポリシー
• 法的通知、プライバシー、同意文書
• 健康、安全、緊急情報
• アクセシビリティ表明

ニュース投稿などの低リスクなコンテンツは迅速に進められますが、それでもレビューと責任者を設定してください。

用語集と翻訳メモリで一貫性を保つ

教育サイトでは専門用語が繰り返されます：プログラム名、キャンパス名、学年表記、奨学金名、公式表現など。以下を用意します：

• 優先翻訳をまとめた用語集（ブランド名などは「翻訳しない」指示を含む）
• 翻訳メモリ（承認済みの文を再利用）

こうすることで、同じプログラムがページごとに違う訳語になるのを防げます。

役割とレビューゲートを明確にする

更新が滞らないように軽量なワークフローを定義します：

1. コンテンツオーナー（部署）が原稿を作成/更新
2. 翻訳者が用語集と翻訳メモリに従って翻訳
3. バイリンガルレビュアーが意味・トーン・正確さを確認
4. 最終承認者が法的/方針系ページを最終確認して公開

SLA（例：「入学ページは3営業日以内に更新」）を設けると、言語版の遅れを減らせます。

機械翻訳を使うなら明示する

機械翻訳は非クリティカルなコンテンツの助けになりますが、重要ページに無断で使うことは避けてください。利用する場合は明記し、問題報告の手段（ページ下部の短い注記＋フィードバックリンク）を用意します。

準備ができたら、このプロセスを /blog/translation-workflow のような簡単な内部ページにまとめ、新しいスタッフが手順に従えるようにします。

多言語SEOの扱い（hreflang、メタデータ、インデックス）

多言語SEOは、家族や出願者が検索で正しい言語版のページにたどり着けるようにするための仕組みです。目的は明快さ：各トピックに対して複数の言語バージョンがあり、それぞれ検索エンジンに明確に示すことです。

固有のURLと一貫したパターンを使う

各言語に安定したURLを与えます。一般的には：

• サブフォルダ：/en/admissions/ と /es/admisiones/（管理が楽）
• サブドメイン：en.example と es.example

どちらを採用しても、言語ごとの内部リンクは一貫させ、検索エンジンやユーザーが言語をまたいで行ったり来たりしないようにします。

言語ごとにタイトルとメタディスクリプションを書く

すべての言語版で固有のタイトルとメタディスクリプションを用意します。翻訳ページに英語のメタを残しておかないでください。検索ニーズは言語ごとに異なるため、自然な表現を心がけます（特に入学、授業料、プログラム、連絡先など高インテントのページ）。

主要な見出し（H1/H2）も各言語で自然に翻訳してください。キーワードの詰め込みは避け、信頼性を損なわないようにします。

hreflang と正しい canonical を実装する

hreflang により検索エンジンに各ページの対象言語／地域を伝え、翻訳を重複とみなされないようにします。canonical と組み合わせて、翻訳が重複コンテンツとして扱われるのを防いでください。

英語ページ上の簡易例は次のとおりです（コードブロックはそのまま）：

<link rel="alternate" hreflang="en" href="/en/admissions/" />
<link rel="alternate" hreflang="es" href="/es/admisiones/" />
<link rel="alternate" hreflang="x-default" href="/admissions/" />

各言語ページは自ページと対応ページを参照するようにします。

インデックスとサイトマップ：検索エンジンが見つけやすくする

必要であれば多言語サイトマップを作り（1つのサイトマップに言語URLを入れるか、言語別に分ける）、Search Consoleに送信します。

部分的にしか翻訳されていないセクションは、完成するまでnoindexにすることを検討してください—未完成の翻訳がインデックスされ拡散するのを防げます。ローンチ後はインデックス状況や“言語の不一致”を監視し、主要ページを言語別に検索して結果をスポットチェックします。

多言語のアクセシビリティと準拠

アクセシビリティは教育サイトにとって必須です。多言語化することで、アクセシビリティ上の問題が見えにくくなる箇所も増えます。

まずアクセシブルなテンプレートを作る

コアレイアウトがWCAG 2.2 AA（米国のADA/Section 508やEUのEN 301 549に準拠することが多い）に合うように設計します。すべきこと：

• 明確な見出し構造（H1–H3）でスクリーンリーダーがページを解釈しやすくする
• 十分な色コントラストと読みやすいフォントサイズ
• メニュー、ボタン、モーダル、言語スイッチャーのキーボード操作対応
• 必要な場合にのみARIAを使う（誤用は混乱を招く）

文書とメディアも各言語でアクセシブルにする

学校はしばしば重要情報をPDFで公開します。スキャンPDFは支援技術で読みづらいため避け、適切に構造化された文書（実テキスト、見出し、リスト、表ヘッダ）を提供してください。ファイル名やリンクテキストも説明的にします。

音声/映像にはキャプションと必要に応じて文字起こしを付け、これらも翻訳してください。

アクセシビリティ要素もローカライズする

アクセシビリティ要素は本文と同じ注意で翻訳します：

• 画像のAltテキスト（装飾画像は空のaltでスキップ）
• フォームラベル、ヘルプテキスト、エラーメッセージ
• “コンテンツにスキップ”リンクやARIAラベル（使用する場合）

ページ言語設定を正しく入れることでスクリーンリーダーが適切に発音できるようにします。

実際の環境でテストする

各言語でモバイル・デスクトップをチェックし、キーボードのみの操作テストや少なくとも1つのスクリーンリーダー（例：NVDA/JAWS、VoiceOver）で検証してください。テキスト長の違いでレイアウトが壊れることがあるので、ローンチ前に必ず確認します。

主要コンポーネント：ページ、フォーム、カレンダー、統合

多言語サイトは「動く部品」が増えるため、はじめから翻訳を前提に設計すると保守が楽になります。部門が再利用できる共通コンポーネントを作り、時期限定のコンテンツが迅速に公開できる仕組みを整えます。

部署向けの再利用テンプレート

カバーするニーズがほとんど収まるよう、少数のテンプレートを用意します：部署トップ、プログラム詳細、スタッフプロフィール、ニュース投稿、FAQ。レイアウト要素（見出し、ラベル、ボタン、コールアウト）は画像に埋め込まず編集可能なフィールドとして保持してください。

共有コンポーネントライブラリの例：

• プログラムカード（期間、キャンパス、要件の一貫したフィールド）
• 連絡ブロック（電話、メール、窓口時間）
• CTAボタン（Apply、Request info）を翻訳可能なラベルにする

これらにより翻訳コストが下がり、一貫性が保てます。

カレンダー、告知、緊急アラート

カレンダーとアラートは頻繁に変わるため最も同期が難しい要素です。構造化データ（タイトル、要約、詳細、場所、対象、公開期限）で管理し、重要情報をPDFや画像に埋め込まないようにします。迅速な更新が必要な場合は「まず原文公開→翻訳進行状況を明示」するワークフローを設定してください。

フォーム：ラベル、確認メッセージ、メール

翻訳する項目を早めに決めます：

• フィールドラベルと補助テキスト
• 成功/エラーメッセージ
• 確認メールとスタッフ向け通知

また、提出データをどう保管するかも考えます：多言語で回答が来る場合、スタッフが扱いやすいように「提出言語」フィールドを付けるなどの工夫が必要です。

統合やサードパーティウィジェット

学生ポータル、決済システム、埋め込みウィジェットはすべての言語をサポートしないことがあります。どこがローカライズ可能か（UI文言、メール、領収書、エラー表示）を棚卸しし、翻訳できないウィジェットがある場合はページ内で代替手段（翻訳された窓口やポータルのランディングページへのリンク）を用意します。

解析、監視、継続的改善

ローンチ後も多言語サイトは継続的に改善する必要があります。言語ごとの利用実態や問題を定期的にチェックする運用を作りましょう。

言語ごとの利用状況を追う

ロケール（言語＋必要なら地域）別にパフォーマンスを分けて見ます：

• ロケール別・デバイス別の訪問数（国ごとにモバイル利用が違うことがある）
• 言語別の上位ページ（入学、プログラム、授業料、住居など）
• サイト内検索やSearch Consoleでの検索語（言語別）

これが翻訳やUX改善の優先順位を決める手がかりになります。

品質監視：欠落コンテンツや壊れた導線の検出

多言語サイトは知らないうちにずれていきます。定期チェックで：

• 言語ごとの壊れたリンク（特にフッターやナビゲーション）を検出
• ある言語にしかないページをフラグ化
• ボタンやフォームラベルなどのUI要素の未翻訳を検出

CMSに対応機能があれば「翻訳完了率」ダッシュボードや定期レポートを作成します。

重要ページを新鮮に保つ

入学、プログラム、授業料/手数料、締切、奨学金ページなどは更新予定表を作り、ソース言語の変更があれば全言語でレビューが走るようにします。

簡単なフィードバックループを作る

翻訳の問題を報告する目立つ方法（例：翻訳ページのフッターに「翻訳の問題を報告」リンク）を設置し、担当チームに自動でページと言語の情報を付けて送ると改善サイクルが早まります。

これらの信号を蓄積して翻訳ワークフローを洗練させれば、問い合わせ削減やSEO改善につながります。関連手順は /blog/multilingual-seo-hreflang-metadata と /blog/translation-review-workflow を参照してください。

ローンチ計画と段階的な展開

多言語のローンチは一度に全部を出すより、小さなリリースを積み上げる方が安全で確実です。まずはユーザーに役立つものを早く公開し、段階的に拡張していきます。

まず影響の大きいページから始める

最初は最も頻繁に尋ねられる質問に答え、問い合わせを促すページを優先します。一般的には：

• ホームページ（プログラム概要と主要CTA）
• 入学（/admissions）
• 授業料と費用
• 連絡先（窓口時間含む）
• FAQ

この初期セットは新しい言語で完全かつ信頼できる状態であるべきです：正しい日付、電話番号、住所、リンクが含まれていることが重要です。

パイロットを実施してから拡張する

追加する1言語でまずパイロットを行います。これによりフルワークフロー（翻訳、レビュー、公開、更新）を実運用で検証できます。

パイロット中に見るべき点：

• 言語スイッチャーは見つけやすいか
• 主要タスク（情報請求、見学予約、出願）が端から端まで理解可能か
• 原文更新時に翻訳ページが同期するか

翻訳バックログとリリーススケジュールを作る

翻訳するページとコンポーネントのバックログを作り、バッチで公開します。週次・隔週などのリズムを決めると審査の負荷を平準化できます。

良いバッチは“セクション完了”ではなく“タスク完了”を目指します。例：「Apply（出願）に必要なすべてのコンテンツ—プログラムページ、要件、締切、確認メッセージ、メールテンプレート—を翻訳して公開する」など。

公開前の受け入れチェックを定義する

各バッチ公開前に簡単な受け入れチェックを行い、どの言語でもプロフェッショナルに見えることを確認します：

• リンク：内部リンクは正しく動作し、該当言語のページを指す
• レイアウト：スペース崩れ、カード崩れ、テキストの重なりがない
• フォント/文字：アクセントや特殊文字が正しく表示される
• コピー確認：トーン、用語、公式名称が一致している

段階的な展開でリスクを抑え、パイロット言語からフルサポートへと進めてください。

長期ガバナンスとコンテンツガイドライン

多言語サイトは一貫性がなくなると使えなくなります。翻訳のズレ（translation drift）を防ぐ最良のタイミングは、次回更新が来る前です。

編集ガイドライン：声、トーン、用語

寄稿者（職員、学生ワーカー、外部翻訳者）が参照できる簡潔なスタイルガイドを用意します。含めるべき項目：

• トーンと敬称（例：公式だが親しみやすく、スラングは避ける、略語は説明する）
• 優先用語（入学手順、学位表記、学生サービスの名前）
• 名称の扱い：翻訳するか公式名称をそのまま残すか（例："Office of the Registrar" は公式名称のままにする場合など）
• フォーマット基準：日付、電話番号、住所、通貨、タイムゾーン、キャピタライゼーション

簡潔にして実際に使われる場所（CMSや共有ドライブ）に置いてください。

プログラム・部署・施設名の共通用語集

共有用語集には次を含めます：

• 正式なプログラム名、学位名、科目コード、部署名
• キャンパス名、建物名、都市名、略称
• 承認済みの翻訳または「翻訳禁止」ラベル

オーナー（多くの場合マーケティング/広報）と簡単な更新プロセスを決めます：リクエスト→レビュー→公開、という流れです。

所有権と変更トリガー（誰が何を更新するか）

「誰でも編集できる」状態はガバナンスの失敗につながります。セクションごとに所有者を決めます：

• 入学：入学課
• 学術部門：各プログラムページ
• 学生サービス：支援ページ
• IT/Webチーム：テンプレート、ナビゲーション、技術的SEO

さらに翻訳トリガーを定義します：

• 原文に変更があったら自動で「翻訳レビュー要」のタスクが作られる
• 締切関連ページは採用シーズン中は定期レビュー（例：月1回）
• 緊急告知は「翻訳作業中」バナーとともに即時公開可

プロセスを回すためのドキュメント

軽量な「公開手順」プレイブックを作り、ページタイプ、承認手順、エスカレーションの連絡先をまとめます。

ツール選定の際はハンドオフを減らし、ロールバックが安全にできるものを優先してください。Koder.aiを使って多言語機能をカスタム開発する際には、計画段階で役割やワークフローを可視化し、スナップショット／ロールバックでナビゲーションや言語ルーティングの変更を安全に展開できる点が有用です。

ツールや価格比較は /pricing を参照し、ワークフローのヒントは /blog をご覧ください。