ホームページを英語・多言語に対応させるには｜翻訳・公開・更新の進め方

「海外の取引先にも会社のことを伝えたい」「日本語が得意でないお客様から問い合わせが来るようになった」。こうしたとき、ホームページを英語に翻訳する案が出てきます。しかし、文章を置き換えても、問い合わせフォームが日本語のまま、英語で届いた相談の担当が決まっていない、料金の更新が英語版に反映されない、といった状態では、相手が安心して次の行動を選べません。

多言語対応で決めたいのは、誰に、どの情報を、どの窓口で届け、その内容を誰が維持するかです。この記事は、Web専任者がいない中小企業の担当者に向けて、翻訳範囲の整理、原稿の準備、言語切り替え、問い合わせ対応、公開前の試験、更新管理を説明します。英語版を小さく始める場合にも使える確認表を用意しました。

Google・W3Cの一次資料と、英国DCMSが公表している言語対応方針を参照しています。DCMSの例は公開された方針の紹介であり、売上改善の実績ではありません。本文の会社設定、日程、管理表の記入内容は説明用の架空例です。自社の条件に置き換え、言語に詳しい確認者と業務担当者の両方で判断してください。

1． 誰に何を伝えるサイトかを決める

「英語を使う人」を一つの顧客像にまとめない

同じ英語ページでも、日本に住む人が店舗への行き方を調べる場面と、海外企業が部品の調達先を探す場面では、必要な内容が違います。前者には予約方法や来店時の案内、後者には仕様、対応範囲、取引の流れが必要かもしれません。「英語版が必要」という要望を受けたら、まず実際の問い合わせや商談で相手が何を確認しているかを集めます。

説明用の例として、福岡で設備の保守を行う会社を考えます。対象が県内の外国人事業者なら、主な情報は訪問できる地域、対応する設備、相談の窓口です。英語で書くことから「海外にも技術者を派遣する会社」という意味にはなりません。読者の居場所、依頼内容、提供地域を別々に書くと、不要な翻訳と期待の食い違いを減らす設計ができます。

読後にできる行動を一つずつ具体化する

目的を「国際化する」「海外にアピールする」で止めず、相手が何を理解し、どう動けばよいかまで決めます。会社の概要を確認する、対応製品を調べる、資料を読む、条件を添えてメールで相談する、といった行動に分けましょう。最初の英語ページですべての取引を完結させる必要はありませんが、次の窓口とそこで対応できることは示しておきます。

例えば、英語でのメール相談は受けられても、電話や現場の作業説明は日本語になる会社があります。その場合は「お問い合わせは英語で受け付けます」と「作業時の対応言語」を分けて案内します。営業担当にも同じ条件を共有してください。Webの文面だけが先に広がると、受付後に説明をやり直すことになり、相手も予定を立てにくくなります。

翻訳以外に調整する情報を洗い出す

W3Cは、ローカライズを特定の言語・地域の要件に合わせる作業として説明し、文字の翻訳に加えて日付、数値、通貨などの違いも扱っています。日本語の文章を英語にした後も、相手が条件を読み取れるかを確認する必要があります。詳しくはW3Cのローカライズと国際化の解説を参照してください。

社内では、営業時間の基準となる時間帯、価格の通貨、寸法の単位、住所の書き方、電話番号、納品地域を確認項目にします。例えば「午前10時」はどこの時間か、「送料込み」はどこまでの配送かを原稿段階で明らかにします。日本語版に書かれていない条件が見つかったら、翻訳者の推測で補わず、サービス担当者が回答してから両方の原稿へ反映します。

2． 翻訳するページと公開範囲を整理する

最初は読者の判断に必要な一続きのページを選ぶ

ページ数だけで範囲を決めると、会社紹介は読めるのに相談方法が分からない、という途切れが生まれます。トップからサービス内容、会社情報、問い合わせへ進む道筋を紙に書き、その途中で必要になる内容を選びます。過去の全ブログやすべてのお知らせを最初から翻訳するより、今回の読者が依頼できるか判断する材料を揃えることを優先します。

翻訳対象の表には、ページ名だけでなく、想定読者、役割、内容の決定者、更新頻度を付けます。採用、通販、会員機能などを含めると確認事項が増えるため、会社紹介の英語版と同じ作業範囲に無意識に含めないようにします。次の表は、国内向けサービスを英語で案内する会社の架空の整理例です。

翻訳しないページへの行き方も決める

日本語だけのお知らせや資料を残す場合は、リンク先が日本語であることを分かる位置に示します。英語ページから日本語PDFを開く構成自体が直ちに不適切なのではなく、何が読めて、何は別途相談が必要かが伝わることが大切です。英語版がない資料の表紙だけを英訳すると、中身まで英語で読めると誤解される可能性があります。

対象外ページを隠すだけで業務上必要な条件まで抜けないかも確認します。例えば、サービスの制限事項が日本語FAQにしかないなら、その制限は英語のサービス案内にも必要です。「全FAQは翻訳しない」と「重要な条件を伝えない」は別の判断です。閲覧経路に沿って、依頼前に知らなければ困る情報が残っていないか点検してください。

公開方針の実例から、範囲と担当を決める考え方を学ぶ

英国の文化・メディア・スポーツ省DCMSは、Welsh language schemeで、ウェールズ語の情報を掲載する判断、関連するフォーム、職員への案内、実施の確認をまとめています。付録の行動計画には、組織紹介の翻訳と言語切り替え、翻訳時間を広報計画に確保する取り組みも示されています。

これは英国行政の言語対応方針で、日本企業に同じ義務を課すものではありません。また、計画に記載された項目をすべて現在の実装実績とみなすこともできません。参考にしたいのは、翻訳する範囲だけでなく、担当や運用まで公開方針として整理している点です。中小企業でも「誰が原稿を決め、誰が公開し、いつ見直すか」を範囲表へ加えると、依頼内容が具体的になります。

3． 翻訳に渡す原文・用語・資料を揃える

日本語の意味が曖昧なまま翻訳へ進めない

「柔軟に対応します」「高品質なサービスです」という表現だけでは、翻訳後も相手の判断材料になりません。どの工程まで依頼できるのか、何を事前に用意するのか、例外はあるのかを日本語で確認します。社内では通じる製品の略称や部署名にも、初めて読む人向けの説明を添えます。翻訳者が業務条件を解釈して決める状態を避けるためです。

例えば「短納期対応」を英語にする前に、対象商品、在庫、数量、相談が必要な条件を営業に確認します。対応日数を約束できないなら、無理に具体的な日数を作らず、相談時に確認する項目を示します。原文を修正した場合は翻訳用ファイルだけに書き足さず、日本語サイトの内容との整合も取ります。両言語が別のサービスを説明する状態にしないことが大切です。

用語表と数値の照合表を分けて用意する

会社名、ブランド名、製品名、部署名、役職は表記を決めて一覧にします。正式な英語名称があるものは、その根拠となる会社資料や製品資料も渡します。正式表記が未確定なら「確認待ち」とし、翻訳者ごとに異なる名称を作らせないようにします。同じ日本語でも文脈によって訳し分ける用語は、意味や使用場所を備考に残します。

別の表で、価格、寸法、容量、営業時間、年月日、連絡先を確認します。文章が自然かどうかの確認と、数値が正しいかどうかの確認は分けた方が進めやすくなります。例えば製品担当者は仕様と単位、総務は住所と電話番号、営業は提供条件を見る、と役割を分担します。写真の説明や図中の文字、ダウンロード資料の表題も忘れずに対象へ含めてください。

翻訳・業務内容の確認・公開承認を分ける

AIや機械翻訳で下訳を作る場合でも、文章を生成した時点を完成としません。原文の意味を保っているか、用語が揃っているか、サービスの条件を強く言い換えていないかを確認します。未公開の顧客情報や契約資料を入力する場合は、使うサービスと社内の取り扱い条件を先に確認し、翻訳に不要な情報は渡さない設計にします。

確認表には「言語表現を確認した人」「業務の事実を確認した人」「公開を承認した人」を記録します。一人が複数の役割を担う場合も、何を確認したかは分けて残します。修正依頼は原文、訳文、理由を組にして返すと、別の箇所へ同じ問題が残っていないか確認できます。素材そのものの整理は、ホームページ制作の原稿・写真を準備するガイドも参考にしてください。

4． 言語切り替えとページのURLを設計する

言語ごとのページを直接開けるようにする

Googleは、多言語サイトでは言語ごとに異なるURLを用意する方法を推奨しています。また、利用者が別の言語版を選べるリンクを設け、推測した言語による自動転送を避けるよう案内しています。検索からだけでなく、取引先へ英語のサービスページを直接送る場面でも、目的の言語と内容を開けることが役立ちます。出典はGoogleの多地域・多言語サイトの管理ガイドです。

依頼時には、日本語のサービス詳細から英語へ切り替えたとき、対応する詳細へ移動できるかを確認します。毎回トップへ戻る構成では、読者が同じ情報を探し直します。対応する訳ページがない場合は、その状態と案内先を決めておきます。URLの方式は既存サイトや管理方法と合わせて選び、見た目の言語ボタンだけを先に追加しないようにします。

langとhreflangの役割を混同しない

HTMLのlang属性は文書などの言語を示すための情報です。一方、hreflangはGoogleへ言語・地域別の対応ページを伝えるために使います。Googleはhreflangやlangそのものをページの言語検出には使わないと説明しています。設定を足すことと、本文やナビゲーションを対象言語で分かりやすく書くことは、それぞれ確認が必要です。

Googleの言語・地域別バージョンの説明では、対応ページの参照に自分自身を含めること、完全なURLを使うこと、相互に対応を示すことなどが案内されています。担当者はコードを暗記するより、日本語と各言語の対応URL表を渡し、公開後の設定がその表と一致するか報告してもらうと確認しやすくなります。設定だけで順位が上がると考えないことも大切です。

本文以外の共通表示と移動先も同じ範囲で点検する

メニュー、パンくず、フッター、ボタン、関連記事、検索欄などは、多くのページで共通に使われます。本文だけ英語でも、次に押すボタンが日本語なら迷うかもしれません。WordPressでは、記事編集欄の翻訳とテーマ・機能側の表示が別に管理される場合があるため、どこを誰が変更するかを制作会社に確認します。

試験用の経路を一つ作り、英語トップ、サービス詳細、実績、問い合わせの順に進んでみてください。途中で日本語へ戻る箇所、英語ページが存在しないリンク、別サービスへ移って言語が変わる箇所を記録します。すべてを同じシステムで翻訳できなくても、言語が変わる前に説明を置くなど、利用者が行き先を理解できる案内は検討できます。

5． 問い合わせから回答までの対応を揃える

入力する人を想定して項目と制限を見直す

英語フォームでふりがなや日本の郵便番号を必須にしていないか確認します。氏名も、日本語の姓・名の分け方をそのまま当てはめてよいとは限りません。W3Cの世界の人名と入力設計の解説は、名前の構成や文字、記号などの多様性を説明しています。業務で何のために名前を使うかを決め、不要な入力制限を設けないことが確認の出発点です。

問い合わせ段階で住所が不要なら、納品時に必要になる情報を最初からすべて求めない方法もあります。海外の電話番号を受け付ける場合は、入力例だけでなく実際の検証条件も確認してください。画面上は入力できても、保存時にエラーになる、管理者の通知では文字が欠ける、という問題は入力欄を見るだけでは分かりません。

受付メールと担当者の回答を別に準備する

送信後には、受け付けたこと、次に何が起きるか、回答の窓口を伝えます。英語版から送ったのに日本語だけの受付メールが届く構成では、読者は手続きが完了したか判断しにくくなります。フォームの表示言語や選択された希望言語を、通知と回答担当へ引き継げるか確認します。入力内容をどこまで受付メールに載せるかも、情報の取り扱いと合わせて決めます。

担当者の回答は、受付通知と同じものではありません。休業日や時差がある場合は、相手が回答時期を理解できる書き方にします。ただし、実際には守れない即時返信や時間を約束しないでください。受付メールの構成や未着時の案内は、問い合わせフォームの自動返信メールの作り方で詳しく説明しています。

対応できない相談を受けたときの案内も決める

英語の相談を受け付ける担当が休みの場合、引き継ぐ人と確認する資料を決めておきます。依頼内容が対応範囲外だった場合も、担当者が毎回最初から説明を組み立てなくて済むよう、提供地域、対応業務、回答方法の共通文面を準備します。断る理由や代案は案件ごとに異なるため、定型文を無確認で送る運用にはしません。

架空例として、国内訪問のみを行う会社に海外現地作業の相談が届いた場合を考えます。まず公開ページの地域条件が明確だったかを確認し、回答では今回提供できる範囲を説明します。似た相談が続くなら、受付担当だけの問題とせず、サービス案内の位置や表現を見直す材料にします。相談の内容をサイト改善へ戻す経路を作っておきましょう。

6． 公開前は翻訳と動作を別々に試験する

長い見出しやボタンを実際の画面で読む

翻訳前の短い日本語では収まっていたボタンやメニューが、別の言語では複数行になることがあります。W3Cの翻訳と文字量の解説は、文字量や文字の幅が変わることを踏まえ、狭い固定領域に文章を押し込まない設計を説明しています。一定の倍率で必ず長くなると決めつけず、採用する訳文で確認することが必要です。

PCとスマートフォンで、見出し、メニュー、ボタン、表、注意事項を見ます。文字を小さくして収める前に、余白や折り返し、文面の意味を保った短縮を検討します。画像に日本語の文字が焼き込まれている場合は、本文を翻訳しても画像は変わりません。図やバナーを別途作るのか、文字をHTMLへ移すのかを確認し、画像の説明文も合わせて扱います。

言語情報と読み上げ・キーボード操作を確認する

W3Cは、HTML文書の基本言語をhtml要素のlang属性で示し、途中で言語が変わる部分には必要に応じて個別に指定する方法を説明しています。英語ページに日本語ページの設定がそのまま残っていないか、共通テンプレートも含めて確認します。具体的な指定方法はW3CのHTML言語宣言の解説を参照してください。

言語ボタンは、見た目だけでなく名前が分かり、キーボードで移動・選択できるかを試します。読み上げでも内容が理解できるかは、対象言語を理解する確認者と検証すると問題を発見しやすくなります。サイト全体の点検を進める場合は、企業サイトのアクセシビリティ改善ガイドも利用できます。

テスト用の入力から通知・回答の確認まで進める

公開前の検証環境と、許可された送信先を用意し、テストと分かる内容で確認します。実在のお客様の個人情報を試験に流用しないようにします。送信後の表示、管理者通知、受付メール、保存された内容を照合し、担当者がどの言語で返すべきか判断できるところまで確認します。公開環境で試験する場合も、担当者と日時・送信先を調整してから行います。

7． 日本語版の変更を各言語へ反映する

更新単位をページ名だけで管理しない

多言語サイトは、最初の公開よりも、その後の料金・営業時間・対応範囲の変更で差が生じやすくなります。更新依頼には、日本語版のURLだけでなく、変更前後の内容、対応する他言語のURL、反映日、確認者を付けます。「日本語版を直したので完了」とせず、言語ごとの状態を一つの表で見られるようにします。

例えば、架空の設備会社が訪問地域を変更する場合、サービス本文のほか、問い合わせの選択肢、PDF、受付メールに地域名が残っていないか確認します。更新の単位を「ページ一枚」から「今回変更した事実」に広げると、共通表示や資料の更新漏れを探しやすくなります。対象が増えた場合は、作業範囲と期限も一緒に調整してください。

翻訳待ちの扱いと承認の順番を決める

原文が変更されたときに、翻訳、内容確認、公開の時間を予定へ入れます。先に紹介したDCMSの行動計画でも、広報の計画段階に翻訳時間を確保する取り組みが示されています。自社でも、日本語の承認日だけを公開日程の基準にせず、必要な言語の確認がいつ終わるかを確認することが運用の参考になります。

料金や提供条件など、古い情報を残すと誤解を生む変更は、担当者同士で公開の順番を決めます。翻訳が間に合わないときは、確認済みの短い案内へ置き換える、該当の案内を一時的に止めるなど、利用者への影響に応じて判断します。未確認の訳文を急いで掲載することを標準の処理にせず、再開や正式反映の担当と期限まで記録してください。

問い合わせの内容を、次の改善の根拠にする

公開後は閲覧数だけでなく、どのページを読んだ相手から、どのような質問が来たかを確認します。英語ページが見られていても、提供地域を誤解した相談ばかりなら、ページの条件説明を見直す余地があります。反対に、資料の意味を繰り返し質問されるなら、その資料の説明や用語を改善する候補にできます。

集計では、閲覧、フォーム送信、実際の相談、商談を区別します。最初は件数が少なくても、迷った箇所や説明不足を記録することはできます。翻訳の品質だけに原因を決めつけず、アクセス経路、サービス条件、返信体制も見てください。定期的な情報確認の進め方は、ホームページの古い情報を見直すガイドへまとめています。

8． 制作会社への依頼と費用の条件をまとめる

ページ数・言語数に加え、確認と運用の範囲を伝える

見積もりを依頼するときは、ページ数と言語数だけでなく、原文を整える作業、翻訳、専門用語の確認、画像内の文字、フォーム、受付メール、公開後の更新をどこまで含めるかを示します。翻訳された文章を渡して実装だけ依頼する場合と、原稿の整理から任せる場合では、作業が異なります。料金表だけを並べる前に、同じ範囲を比較できる依頼書を作ります。

継続費用も確認してください。言語管理に使う機能の費用、翻訳修正の依頼方法、追加ページの扱い、更新後の検証が見積もりに含まれるかを質問します。作った担当者しか変更できない状態にしないため、原稿・用語表・対応URL表の保管先と、担当交代時の引き渡し範囲まで合意しておくと運用しやすくなります。

依頼メモには未確定のこともそのまま書く

次のメモは説明用の架空例です。最初から全部を決めてから相談する必要はありません。「対象読者は県内の英語利用者」「最初は会社情報、主力サービス、問い合わせを英語化」「メールで回答可能、電話対応は日本語」「正式な会社名は総務が確認」「製品用語は営業が確認」「公開後は月次の更新確認を担当者が行う」と整理するだけでも、相談の出発点になります。

未確定の項目は、候補と判断する人を書きます。例えば「実績紹介の英訳は掲載条件を確認後に判断」「予約サービスが英語対応できるかは制作会社に調査を依頼」と記します。分からない部分を曖昧なまま一括依頼するより、調査が必要な箇所と制作する箇所を分けた方が、費用や日程の説明を受けやすくなります。

最初の公開範囲を決め、更新できる状態まで仕上げる

着手時には、対象読者、必要なページ、対応窓口、原稿の確認者を決めます。その後、言語ごとのURLと切り替え、フォームと通知、実際の表示を確認し、最後に更新表と担当を整えます。翻訳した文章の納品だけで終わらせず、相手が目的の情報を読み、相談でき、会社側が次の変更へ対応できるところを完了の条件にしてください。

範囲の整理から相談したい場合は、ホームページ制作の対応内容をご覧ください。現状のURL、想定する読者、追加したい言語、社内で確認できる人を共有いただくと、ページ構成と運用範囲を検討しやすくなります。多言語化を一度の翻訳作業に閉じず、伝える内容と更新する仕組みを一緒に準備していきましょう。