「原稿は何から用意すればいいのか」「翻訳が終わるまで制作は始められないのか」。多言語サイトの導入では、画面を作る前に止まってしまうことがあります。すべての資料を完成させるより、誰に何を伝え、どの言語で問い合わせを受けるかを先に決めると、準備を絞れます。
多言語サイトの導入は、相談・要件整理、構成と原稿の確定、翻訳と実装、公開前検査、公開と引継ぎの順に進めます。 各工程で「決めること」「渡すもの」「次へ進む条件」をそろえるのが要点です。制作期間や打ち合わせ回数は案件ごとに異なり、ページ数だけで一律に約束できません。
この記事で分かること
- 初回相談で必要な情報と、まだ決めなくてよいこと
- 日本語原稿・翻訳・デザインを手戻り少なく進める順番
- 各工程で受け取る資料と、社内で確認するポイント
- 公開日から逆算する検査、問い合わせ対応、引継ぎの方法
確認日:2026年10月27日。本記事の工程表と架空例は導入準備のための編集上の提案です。特定プランの納期、作業範囲、顧客の実体験を示すものではありません。
導入前に何を準備すればよい?

AI生成の概念イメージ。実製品の画面・顧客実績ではありません。
「外国語対応したい」を一つの目的にする
多言語化する目的が曖昧だと、会社案内、採用、商品説明、予約を一度に盛り込みたくなります。まず、サイトを見た人に取ってほしい行動を一つ選びます。資料請求なのか、相談なのか、所在地を確認して来店することなのか。目的によって必要なページが変わります。
たとえば海外の取引先から相談を受けたいなら、会社の概要だけでなく、提供できる商品、対応地域、取引の相談方法が必要です。外国語ページを増やすだけでは、相手が自分に関係のあるサービスか判断できない場合があります。訪問者が判断するための情報から考えます。
最初に書く目的文は、「どの相手が、何を理解し、何をするか」の形にすると具体的です。「海外向けに信頼感を出す」より、「英語で製品を探す担当者が、対応できる仕様を確認し、相談を送れるようにする」と書けば、後の原稿や検査に使えます。
初回相談に持参するものを整理する
完璧な企画書は不要です。現在のサイト、会社案内、商品の説明、営業でよく聞かれる質問があれば、必要な情報を整理する材料になります。手元にない資料は、無理に作ったふりをせず「未準備」と分けます。
表は横にスクロールして比較できます。
| 用意する情報 | 使う目的 | 未確定の場合の伝え方 |
|---|---|---|
| サイトの目的と読者 | 優先するページを決める | 主な相手と期待する行動を仮置きする |
| 希望する言語 | 翻訳と確認の範囲を決める | 必須の言語と検討中を分ける |
| 会社・商品資料 | 原稿の根拠をそろえる | 不足する仕様や写真を一覧にする |
| 現在のURLと課題 | 残すものと直すものを判断する | 分かる範囲の画面や困りごとを伝える |
| 公開したい時期 | 逆算して順番を決める | 必須の締切と希望日を分ける |
| 社内の担当者 | 確認待ちを減らす | 原稿・翻訳・承認を決める日を置く |
資料に個人情報や未公開の取引情報が含まれる場合は、そのまま共有せず、制作に必要な範囲へ絞ります。公開してよい写真と、社内確認用の写真も分けてください。資料を多く渡すことより、掲載してよい内容が分かることが大切です。
すべての言語を同時に始める必要はある?
営業上必要な言語と、将来使うかもしれない言語を分けます。最初から増やすほど、原稿確認や修正の対象も増えます。確認担当がいない言語を加える場合は、誰へ確認を頼むか、費用と日程を含めて相談します。
また、言語と国は同じではありません。英語で世界共通の説明をするのか、国ごとに商品や条件が異なるのかで、必要なページが変わります。Googleも多言語と多地域を区別して案内しています。導入相談では、翻訳する言語だけでなく、提供する地域と条件を伝えてください。Google公式「多地域、多言語のサイトの管理」
相談と要件整理では何を決める?

制作した概念図。実製品の画面・顧客実績ではありません。
図の要点:相談と要件整理では何を決める?
- 要件を整理
- 担当を決める
- 範囲を合意
要望を「必要な動作」へ置き換える
「見やすくしたい」「海外向けにしたい」という要望は、そのままでは完成の判定に使えません。どの場面で誰が困っているかを整理し、実際の動作へ変えます。料金表を見つけられないなら、料金を確認する導線を作る。問い合わせが日本語だけなら、対象言語で入力と案内を読めるようにする、といった形です。
要件は、公開時に必要なもの、公開後に検討するもの、今回は含めないものに分けます。将来の可能性を否定するためではなく、今回の完成範囲を決めるためです。追加したい機能が出たときにも、元の合意と何が変わったかを確認できます。
表は横にスクロールして比較できます。
| あいまいな要望 | 具体化した要件の例 | 確認方法の例 |
|---|---|---|
| 海外から相談してほしい | 対象言語の説明から問い合わせへ進める | 詳細ページから送信まで通す |
| 更新を楽にしたい | 社内担当が営業時間を変更できる | 操作して全言語の反映を確認する |
| 商品を分かりやすくしたい | 用途・条件・仕様をそろえて載せる | 初見の確認者に必要情報を探してもらう |
| 担当交代に備えたい | 原稿、権限、更新手順を引き継げる | 別担当が資料から作業できるか確認する |
これらは編集上の例で、特定サービスの標準仕様ではありません。実際には、使う仕組みや契約で対応できる範囲を確認します。会議で口頭確認したことも、後から見返せる一覧に残します。
役割を決めてから日程を引く
制作会社の作業が始まっても、原稿や翻訳の承認者がいなければ進められません。社内窓口、内容の責任者、言語の確認者、公開を判断する人を決めます。同じ人が兼ねても構いませんが、役割が空欄のままにしないことが重要です。
窓口担当が、すべての内容を一人で決める必要はありません。商品条件は営業や事業責任者、採用情報は採用担当など、必要な人に確認してから一つの回答にまとめます。複数の担当者が制作側へ別々の指示を送ると、どれを反映すべきか分からなくなります。
日程には制作作業だけでなく、社内確認、翻訳確認、素材の準備も入れます。「確認はすぐ終わるはず」として省くと、公開直前にしわ寄せが来ます。誰がいつ回答するかを決め、休業日や不在の期間も共有してください。
確認期限までに結論が出ない場合は、何が未確定なのかを分けます。写真の選定なら仮配置で進められるかもしれませんが、提供する商品そのものが変わるなら原稿と翻訳に影響します。どの工程へ戻るか、公開範囲を絞れるかを相談してください。
工程表には「完了予定」だけでなく、次の担当へ渡す条件も書きます。翻訳へ渡す条件なら日本語の内容承認、公開検査へ渡す条件なら確定版の反映といった形です。終了日が並んだだけの予定表より、遅れの影響と進められる作業を判断しやすくなります。
見積もりの対象と変更条件をそろえる
見積もりでは、ページ、言語、原稿作成、翻訳、フォーム、画像、保守の範囲を確認します。同じページ数でも、会社案内の複製と、国別に条件が違う商品ページでは必要な作業が異なります。料金の比較には前提の一致が必要です。
途中でページや言語を追加した場合、誰が追加作業を見積もり、公開日をどう調整するかも決めます。修正の回数だけでなく、「確定後の原稿変更」「新機能の追加」「当初の仕様どおり動かない不具合」を区別しておくと、相談しやすくなります。
導入方法自体が未定なら、先に制作会社・テンプレート型・自作のどれを軸にするか整理します。既存の多言語サイト制作会社の比較表は、依頼先の提案範囲を比べる材料として使えます。金額だけで工程の不足を見落とさないようにしましょう。
構成・原稿・デザインはどの順に固める?

制作した概念図。実製品の画面・顧客実績ではありません。
図の要点:構成・原稿・デザインはどの順に固める?
- 構成を作る
- 原稿を確定
- 表示を確認
ページ一覧で公開範囲を見えるようにする
いきなりトップページのデザインから始めると、後から必要な情報が増え、構成を組み直すことがあります。先にページ一覧を作り、それぞれの目的と必要な内容を整理します。トップ、会社案内、サービス詳細、問い合わせなどの名前だけでなく、読者が何を判断するページかを書きます。
ページ一覧には言語別の対応も持たせます。すべてのページを同じ範囲で翻訳するのか、一部だけを外国語で用意するのか。翻訳しないページへ移るときに、利用者が混乱しない案内も考えます。未作成の言語版があるのに、切替ボタンだけが表示される状態を避けます。
構成を考える材料は、多言語ホームページの構成例でも確認できます。ページを増やす前に、問い合わせの判断に必要な情報が揃っているかを見てください。
原稿は、翻訳前に事実と条件を確定する
日本語が未確定のまま全言語の制作を進めると、変更が出るたびに訳文と画面を直す必要があります。商品名、提供範囲、受付方法、対象外の条件など、意味が変わる部分を先に確定します。細かな言い回しと事業上の条件を同じ優先度で扱わないことがコツです。
原稿の確認では、文章の上手さだけを見ません。「誰が利用できるか」「どこまで対応するか」「問い合わせ後に何が起こるか」が説明されているかを確認します。実績や数字を載せるなら、その根拠と掲載許可も必要です。裏付けのない成果を、分かりやすさのために足してはいけません。
表は横にスクロールして比較できます。
| 原稿の状態 | 次に進める作業 | 先に解決すること |
|---|---|---|
| 内容と条件が確定 | 翻訳、レイアウトへの反映 | 固定する用語を共有する |
| 表現だけ調整中 | 仮組みで表示を確認 | 変更の締切と対象を決める |
| 仕様や提供範囲が未確定 | 構成の相談まで | 事業上の判断者へ確認する |
| 根拠や掲載許可が不明 | 該当箇所を保留 | 証拠を確認するか掲載を外す |
この区分を共有すると、制作側は待つべき部分と進められる部分を判断できます。原稿が一部止まっていても、画像整理や別の確定ページまで止める必要はありません。
デザインは代表ページと長い訳文で確認する
見本を確認する際は、色や写真の印象に加えて、見出し、説明、ボタンがどの順で読まれるかを見ます。会社案内と商品詳細では情報の密度が異なるため、代表的なページを選んで確認してください。
スマホでは、説明が長くなったときに必要な情報へ進めるか、表が切れないか、問い合わせボタンが押しやすいかが重要です。日本語の短い仮文だけで決めず、実際に使う訳文や、それに近い長さの内容を入れて確認します。
デザインの承認後に商品情報を大きく増やすと、見本のままでは収まらないことがあります。情報量の変更と装飾の修正は分けて伝え、必要なら構成へ戻って調整します。最初に決めた見た目を守るために、必要な説明を削る判断は避けましょう。
修正指示は、場所・理由・確定文をまとめる
「もっと分かりやすく」の一言では、どこをどう変えるかが伝わりません。ページ名、対象箇所、困っている理由、修正したい内容をまとめます。訳文の変更なら、元の文章と確定した訳文を対応させて渡します。
意見が分かれる場合は、読者と目的に戻ります。経営者が好きな写真かではなく、提供内容が伝わるか。文章が短いかではなく、申込条件を理解できるか。判断の理由が共有できれば、好みだけの修正を減らせます。
翻訳と多言語実装をどう進める?

制作した概念図。実製品の画面・顧客実績ではありません。
図の要点:翻訳と多言語実装をどう進める?
- 文脈を渡す
- 訳文を確認
- 言語別に実装
翻訳の依頼には文脈も渡す
翻訳担当には日本語だけを渡すのではなく、対象読者、ページの役割、商品の説明、用語表を添えます。同じ単語でも、業界や利用場面で適切な表現が異なることがあります。日本語の意図を質問できる窓口も決めておきます。
自動翻訳を下訳に使う場合も、専門用語、契約や申込みの条件、問い合わせ案内は確認対象を明確にします。確認者が事業条件を理解していないなら、言語の確認と内容の承認を別の担当へ分けます。自然な文章に見えることと、自社が提供できる内容であることは同じではありません。
用語表には、商品名、役職名、固定する訳、避けたい表現などを残します。すべての文章をルール化する必要はありませんが、毎回迷う語が揃えば、ページ間の不一致を減らせます。原稿更新後に使うためにも、確定版を共有場所へ残してください。
対象は本文だけでなくフォームや資料にも広がる
本文が翻訳されても、入力エラーが日本語のままなら、外国語の利用者が送信できないことがあります。問い合わせの案内、完了画面、必要な返信、ダウンロード資料など、行動の途中に出る情報を一覧にします。
表は横にスクロールして比較できます。
| 確認する場所 | 見落としやすい内容 | 確認する担当 |
|---|---|---|
| ナビゲーション | メニュー名、言語名、戻る導線 | サイト担当と言語確認者 |
| フォーム | 項目名、必須表示、エラー、完了案内 | 動作担当と言語確認者 |
| 画像と資料 | 画像内の文字、PDF、図の説明 | 原稿担当と素材担当 |
| 検索向け情報 | 言語別タイトルや説明 | 制作担当と内容承認者 |
| 連絡の案内 | 対応時間、返信言語、次の手順 | 問い合わせ担当 |
画像内に文字を入れる場合は、別言語への差し替えが必要かを考えます。可能な箇所は画面上の文字として扱うと、更新や表示の調整をしやすくなります。元画像と編集できる素材があるかも、導入時に整理します。
言語ごとのURLと切替先を対応させる
Googleは各言語版に異なるURLを使うことを推奨しています。導入では、管理画面の設定名だけを確認するのではなく、言語別の公開URLを一覧にし、直接開けることを確かめます。別言語への切替で、すべてトップへ戻ってしまわないかも確認対象です。Google公式資料
既存サイトを更新する場合、旧URLを変えるかどうかは別の判断です。見た目の変更に合わせて、必要もなくURLを作り直さないようにします。変更が必要なら、旧ページと新ページの対応、転送、内部リンクを確認する工程を入れてください。
技術的な確認の詳細は、多言語SEOの公開URL確認手順へ分けて進められます。導入を依頼する際は、これらの設定と検査が契約のどの範囲に含まれるかを確認します。
翻訳が遅れた場合の扱いを先に決める
公開日が近づいてから、未確認の訳文をそのまま載せる判断は避けます。公開範囲を絞る、対象言語を段階的に追加する、公開日を調整するなど、何を優先するかを相談します。申込条件の不明なページを公開するより、確定した範囲を明確にする方が判断しやすくなります。
ただし、一部の言語を外すなら、メニュー、広告、営業資料の案内も整合させます。公開していないページへリンクを張ったままにしないことが必要です。翻訳の完了とサイトの公開範囲を、一つの一覧で管理すると漏れを見つけやすくなります。
完成確認から公開までに何を検査する?

制作した概念図。実製品の画面・顧客実績ではありません。
図の要点:完成確認から公開までに何を検査する?
- 内容を検査
- 送受信を検査
- 公開後に確認
完成の条件は、公開前に共有する
完成画面を一度見て「問題なさそう」と判断するだけでは、問い合わせや言語切替の不具合を見落とします。見た目、内容、動作、検索向けの設定に分け、担当者と確認した範囲を残します。全部を一人で見ようとするより、役割ごとに検査を分ける方が実務的です。
たとえば内容承認者は提供条件、言語確認者は意味と表現、サイト担当は表示とリンク、問い合わせ担当は受信と返信の流れを見ます。誰かが見たはずという状態をなくし、未確認は未確認として残してください。
表は横にスクロールして比較できます。
| 検査の区分 | 確認すること | 残す記録 |
|---|---|---|
| 内容 | 会社情報、条件、連絡先が確定版と一致 | 対象ページ、確認者、確認日 |
| 表示 | PCとスマホで欠けや横はみ出しがない | 端末・画面幅、問題箇所 |
| 導線 | 言語切替、主要リンク、問い合わせへ進める | 操作順と到達先 |
| 送受信 | 安全なテストで通知と必要な返信を確認 | テスト日時と確認した受信先 |
| 設定 | 公開対象、タイトル、正規URLなどが意図どおり | 公開URLと検査結果 |
テストは、実際の利用者の順番で行う
トップページを開き、対象のサービスを探し、条件を読み、問い合わせへ進む。この流れを対象言語ごとに試します。詳細ページに直接来る利用者もいるため、そこから会社情報や問い合わせへ進めるかも見ます。
フォームでは、正しい入力だけでなく、必須項目が空の場合や入力形式が違う場合の案内を確認します。送信後に完了が分かるか、担当者が通知を受け取れるか、必要な自動返信が想定どおりかを分けて確認します。実在顧客の情報は使わず、許可されたテスト先を使います。
詳しい確認項目は、多言語フォームの公開テストも参考になります。完了画面の成功だけで、担当者への通知まで成功したと扱わないことがポイントです。
公開作業と公開後確認を一組にする
テスト環境で正しくても、本番のURLや送信先で同じ動作になるかは、公開後に確認が必要です。公開作業の担当と、公開後に見る担当を決め、営業や広告で案内する前に主要ページを確認します。
既存サイトの切替では、元の原稿や設定、必要なバックアップを保全し、戻す条件を決めます。WordPressの公式資料は、ファイルとデータベースの双方をバックアップ対象として説明しています。バックアップが存在するだけでなく、誰が復元するかも含めて相談してください。WordPress公式バックアップ資料
公開日が決まっていても、問い合わせが送れない、提供条件が間違っているといった問題は優先して修正します。公開を急ぐために検査結果を成功扱いにしないことが重要です。軽微な調整を公開後へ回すなら、担当と対応予定を残します。
架空例:展示会前の公開を目指す場合
以下は進め方を示す架空例で、実際の案件の記録ではありません。ある事業者が展示会で英語ページを案内するとします。商品一覧、代表商品の説明、問い合わせが必要ですが、ほかの商品資料は翻訳中です。
この場合は、展示会で案内する範囲を先に決め、代表商品の条件と問い合わせを優先して確認します。翻訳中の資料は未公開とし、リンクを出さない判断ができます。会期に間に合わせるために、未確認の全文を公開する必要はありません。
また、会場で配る資料のURLやQRコードが最終ページへつながるかを確認します。公開日そのものより、訪問者が情報を読み、問い合わせを送れる状態が締切の実質的な条件になります。
公開後に何を引き継ぎ、どう改善する?

制作した概念図。実製品の画面・顧客実績ではありません。
図の要点:公開後に何を引き継ぎ、どう改善する?
- 資料を引継ぐ
- 更新を試す
- 改善を続ける
納品物は画面と管理画面だけではない
公開したサイトを運用するには、言語別原稿、画像原本、URL一覧、更新手順、権限の管理方法が必要です。何を受け取れるか、どの資料を自社で保管するかを確認します。制作会社との契約が続く場合も、社内担当が現状を把握できる資料を持っておきます。
引継ぎで確認したいのは、「誰がどの画面を操作できるか」「困ったときどこへ連絡するか」「原稿変更をどう依頼するか」です。アカウントの秘密情報は、一般の資料に貼り付けず、適切な管理方法で扱います。担当交代の際には権限を見直す手順も決めてください。
サイト作成サービスを使う場合、原稿や画像の権利と、サイトを別の環境へ移せる範囲は別です。引継ぎ先でも同じように動くとは想定せず、取り出せる情報と再構築が必要な部分を確認します。
最初の更新を一緒に試す
操作説明を聞いただけでは、実際に自分で変更できるか分かりません。営業時間や担当窓口など、影響を限定した更新を一件選び、作業の流れを試します。元に戻せる材料を残し、確定原稿を使って入力と表示確認を行います。
多言語サイトでは、日本語だけを変えて終わりにしないことが重要です。変更対象の言語を特定し、翻訳確認、画面反映、公開後の確認まで通します。途中で止まる工程があれば、手順や分担を直してから本格運用へ進めます。
引継ぎの確認は、担当者の能力を試すためではありません。資料に不足がないか、操作権限が適切か、相談先が明確かを確かめるためです。分からない操作をその場で記録すれば、後から同じ疑問を調べ直す負担を減らせます。
公開と集客成果を混同しない
公開が完了しても、検索への登録、順位、問い合わせの増加が同時に確定するわけではありません。まずは、必要なページが開ける、主要導線が動く、問い合わせを受けられるという土台を確認します。その後に、どこから訪問され、何を読まれ、どこで止まるかを見ます。
確認する情報は、目的に合わせて絞ります。資料請求が目的なら、閲覧数だけでなく問い合わせまで進んだか、対象外の問い合わせが増えていないかも判断材料になります。件数が少ない段階で、細かな変動だけから成功や失敗を断定しないようにします。
改善するときは、変更箇所と理由を記録します。原稿、ボタン、導線を同時に大きく変えると、何が影響したか分かりにくくなります。問題のある箇所を特定し、小さく修正して動作を確認する方が、少人数の運用には取り入れやすい方法です。
導入を始めるための相談内容をまとめる
相談前に決めきれないことがあっても構いません。「目的と対象言語」「今ある資料」「必要な問い合わせ方法」「希望する時期」「社内で担当できる作業」が分かれば、次に必要な準備を整理できます。
タゲンゴへ導入の流れを詳しく聞く場合も、完成した企画書より、現在のサイトと困っている場面を共有するところから始められます。翻訳だけを頼みたいのか、構成から相談したいのか、公開後も更新を頼みたいのかを添えると、相談範囲を合わせやすくなります。
多言語サイトの導入を前へ進めるのは、「すべておまかせ」という言葉よりも、次の工程へ渡せる確定情報です。最初の一歩は、誰に何を伝えるサイトかを一文にし、必要な代表ページを選ぶことです。
よくある質問
原稿や写真が揃っていなくても相談できますか?
相談時点で全部が揃っている必要はありません。あるものと未準備のものを分け、原稿作成や写真準備を誰が担うか相談します。ただし、提供条件や掲載許可が不明な情報は、確定した内容として制作を進めないようにします。
多言語サイトはどのくらいの期間で導入できますか?
対象ページ、言語、原稿の準備、機能、社内確認の速さで変わります。相談日から一律の週数で考えず、各工程の作業と確認に必要な日程を見積もってください。公開したい理由と必須の締切を伝えると、優先する範囲を相談しやすくなります。
翻訳とデザインは同時に進められますか?
確定した構成や原稿を使って並行できる部分はあります。ただし、商品条件が変われば訳文や画面も直す必要があります。内容を先に固め、長い訳文を入れた表示確認を残すなど、工程ごとの前提をそろえることが大切です。
公開後の修正も制作費に含まれますか?
契約内容によります。不具合の修正、原稿変更、新機能追加、定期保守を分けて、対象と依頼方法を確認してください。公開前に担当窓口と引継ぎ資料をそろえると、運用開始後に相談する際も状況を伝えやすくなります。
関連記事
- 多言語ホームページの構成例:最初に用意するページを決めるために。
- 多言語フォームの公開テスト:問い合わせの検査を具体化するために。
- 多言語サイト公開後の運用ルール:引継ぎ後の担当と更新方法を決めるために。
運営者・確認日・公式出典
執筆・編集:タゲンゴ。公式資料確認日:2026年10月27日。工程表、分担例、架空例は本記事の編集提案で、特定プランの納期や顧客成果を示していません。実際の作業範囲と日程は個別に確認してください。


