多言語サイトは自分で作れる？DIYの進め方と外注へ切り替える判断基準

日本語サイトを作った経験があれば、外国語ページも追加できそうに見えます。一方で、翻訳の品質、言語を切り替える仕組み、問い合わせ対応まで考えると、自分でどこまで担当すべきか迷うのではないでしょうか。

多言語サイトは、自社で扱えるページ数と更新範囲を決めればDIYで構築できます。ただし、画面を作れることと、各言語の情報を正しく保ち続けられることは別です。最初に対象読者と相談の流れを絞り、原稿、言語別URL、対応ページへの切替、問い合わせ、更新担当を一つの小さな構成でそろえると、必要な作業を判断しやすくなります。

この記事で分かるのは、DIYに向く条件、構築方式の違い、原稿の整理方法、言語切替の設計、公開後の更新、制作担当へ引き継ぐ資料です。公開直前の点検項目を並べる記事ではなく、作り始める前から担当範囲を決めるための実務ガイドです。特定のツールを使えば集客できるという保証や、未確認の制作費・成功事例は提示しません。

私が参拝していた「サムハラ神社」は、カタカナの名前が印象に残る神社です。固有名詞の正式な表記をどう扱うかは、多言語化でも確かめておきたい点です。

DIYで作る範囲をどう決めるか

作れる画面ではなく、届けたい情報から始める

最初に決めるのは色やレイアウトではありません。誰が何語で、何を確認し、最後にどの行動へ進むかです。例えば「ベトナム語を読む購買担当者が、取扱製品の対応範囲を確認して相談する」という一文を作ります。これは架空の検討例であり、実在顧客の行動を観測した結果ではありません。

この一文があると、最初のサイトに必要な情報を絞れます。会社の長い沿革より、扱うもの、相談できる条件、対応する地域、連絡方法が先に必要かもしれません。すべての日本語ページを同時に翻訳するのではなく、読者が相談を判断するためのページを一つのまとまりにします。

DIYの範囲を小さくすることは、重要な説明を省くことではありません。対応しない商品や地域があるなら、その条件を分かるように書きます。説明できていない部分を外国語の雰囲気で補うのではなく、自社が正式に案内できる範囲を先に決めることが、作り直しを減らす土台になります。

自社が持つ三つの役割を確認する

必要なのは、事業内容を確定する役割、言語の意味を確認する役割、サイトを保存・更新する役割です。同じ人が複数を担当しても構いませんが、誰も担当しない役割を残さないようにします。操作が得意な人だけに、専門用語や提供条件の判断まで任せる必要はありません。

表は横にスクロールして比較できます。

「自分で作るか、全部外注するか」の二択にする必要はありません。内容の原本を自社で作り、言語確認と特定の設定だけ依頼する方法もあります。逆に制作を外注しても、正式なサービス条件や更新の連絡先は自社が用意する必要があります。外注によって事業情報の責任がすべてなくなるわけではありません。

先に外部の確認を入れたい条件を見分ける

複数の担当者が頻繁に更新する、商品ごとに販売条件が違う、予約や決済に連動する、といった場合は、ページを追加する作業以外の設計が増えます。DIYが不可能と決めつける必要はありませんが、完成までに何を確かめるかを具体化し、設定や連携を理解できないまま進めないことが大切です。

例えば、読む言語は英語でも、対応地域を複数国へ一律に広げる必要はありません。言語と対象市場を別に決めれば、説明と運用の範囲を絞れます。相談を受け付けるだけのサイトと、その場で注文を確定するサイトでは必要な確認が違います。初期段階では、どの行動まで提供するかを明記してください。

DIYを続ける条件は、作業が無料で済むかだけでは判断できません。原稿の確認、修正、担当交代に使う時間や、分からない設定を放置する負担も含めて考えます。具体的な費用はサービスや契約で変わるため、本記事では一律の価格帯を示しません。自社で管理する範囲と、依頼する範囲の違いを先に整理しましょう。

多言語化の構築方式をどう選ぶか

言語別ページと、その場の翻訳を分けて考える

多言語化には、言語ごとにページを持つ方法と、閲覧時に表示を変える方法があります。利用者にはどちらも翻訳に見えますが、原稿の保存先、言語ごとのURL、検索向けの設定、更新差分の管理が異なります。翻訳ボタンが表示されたことだけで、別言語ページの公開が完了したと考えないようにします。

言語ごとに原稿を持つ方法は、表現を個別に確認しやすい一方、元の内容が変わったときに各言語へ反映する作業が必要です。その場の翻訳では始めやすい場合があっても、何が保存され、どこまで編集でき、どの画面に反映されるかを使うサービスの公式説明で確認します。未確認の機能を前提に、設計を進めないでください。

表は横にスクロールして比較できます。

この比較は、特定の商品やプランの機能比較ではありません。実際に選ぶ際は、公式資料と利用する契約の範囲で確認してください。同じサービス名でもプランや設定によって使える範囲が変わる可能性があるため、古い紹介記事の説明だけで決めないことが重要です。

ページを増やす前に一つの構成を試す

構築方式を判断するため、サービス説明、対応条件、問い合わせ入口を含む小さな構成を作ります。トップページだけでは、長い本文、表、フォーム、言語切替などの作業量を見積もれません。実際に掲載する原稿の一部を使い、更新したときにどこへ反映されるかまで確認します。

試す際は、見た目だけでなく、編集する場所が分かるか、間違えたときに戻せるか、ほかの担当へ説明できるかを見ます。作成した本人しか修正できない仕組みでは、担当交代や急な変更で困ることがあります。編集画面の操作手順と、ページの関係を簡単にメモしておくと引き継ぎやすくなります。

仮のサイトを公開環境へそのまま置く必要はありません。確認用の場所と公開する場所を分け、公開前の原稿や連絡先を不用意に一般公開しないようにします。公開制限や検索設定について理解できていない場合は、制作担当に範囲を確かめます。テスト環境があることと、公開環境へ安全に反映できることも別の確認です。

「自動」の対象範囲を文章で確認する

自動翻訳、自動切替、自動更新という言葉は、何を対象にするかを確認して使います。本文を翻訳できても、画像の文字、添付資料、入力エラー、自動返信は別の扱いかもしれません。自動切替も、利用者が読む言語を選び直せるか、同じサービスへ戻れるかが重要です。

導入前の確認表には「変更する場所」「反映される場所」「自分で直せる場所」を並べると整理できます。例えば日本語の説明を更新したときに、外国語版が自動更新されるのか、未反映として残るのか、再確認が必要になるのかを確かめます。意味の変更を、人の確認なしで確定する設計にしないことが基本です。

ツールが多機能であるほどDIYに向くとは限りません。必要な機能だけを使い、その機能の動きを説明できることが大切です。初期段階で使わない決済や会員機能まで追加すると、更新や権限の管理が増えます。読者の次の行動に必要かという基準で、最初の構成を決めてください。

編集する人と確認する人を一つの原稿で試す

DIYの試作では、原稿を一か所変えたときの動きを具体的に試せるようにします。例えば架空のサービス説明にある「相談時に仕様を確認する」を変更する場合、誰が原文を確定し、どの外国語原稿が再確認の対象になり、どこへ反映するかを一行で記録します。実施済みのテスト結果ではなく、試作時の確認方法の例です。

この流れを説明できなければ、ページを増やす前に管理方法を整理します。原稿がメール、文書、編集画面へばらばらに残っているなら、正式な原本の置き場所を一つ決めます。翻訳の担当者へ渡す版と、実際に反映する版が一致することを確かめるだけでも、どこで確認が必要か見えてきます。

また、外部の担当者へ編集を依頼する場合は、すべての管理権限を最初から渡す必要があるかを検討します。原稿の修正と、サイト全体の設定変更では必要な権限が違います。利用する仕組みの権限機能を確認し、依頼する作業に合った範囲を選びます。試作段階でこの区別をしておくと、公開後も同じ説明を引き継ぎ資料へ使えます。

翻訳前の原稿とページ構成をどう作るか

日本語の原稿を短く分かる形にする

日本語が曖昧なままでは、翻訳後に意味を確認しにくくなります。「柔軟に対応」「高品質なサービス」だけで済ませず、何を相談でき、何は個別確認が必要かを書きます。主語や対象が省略されている文は補い、一文に複数の条件を詰め込みすぎないようにします。

翻訳前の原稿には、固有名詞、型番、正式なサービス条件、更新日などを整理します。文章として読みやすくする前に、変えてはいけない値を決めるためです。例えば製品の型番はそのまま残し、その役割や用途を対象言語で説明するなど、翻訳する部分と固定する部分を分けます。

運営者の体験：コロナ禍に香港から日本へ一時的に戻っていた3年間、私はほぼ毎朝、神社に参拝し、その後、合気道の早朝稽古に通っていました。その生活の中で印象に残ったのが、「サムハラ神社」というカタカナの名前です。

大阪府神社庁は「サムハラ神社（さむはらじんじゃ）」と読みを添えて掲載し、神社の公式サイトもカタカナ表記で案内しています。名前の由来や文字の意味を想像で翻訳せず、まず公式表記と読みを確かめる。企業名や商品名でも、用語集と各言語版でその基準をそろえておくことが大切です。

架空の部品相談ページなら、「幅広い製品へ対応」より「相談時に型番と使用条件を確認する」という説明のほうが、読者が準備する情報を判断できます。ただし、実際にその対応を行っていることが前提です。自社が実施していない確認やサポートを、分かりやすい説明として付け足さないようにしてください。

ページごとに一つの主な疑問を置く

会社紹介、サービス説明、取引条件、問い合わせを一枚へ詰め込む方法もありますが、読者が探す順番を考えます。まず何を提供するか、次に自分が対象か、最後にどう相談するかという流れです。ページを分ける場合も、一つの説明を読むために何度も行き来しなくてよいようにします。

表は横にスクロールして比較できます。

日本語と外国語でページ数が完全に同じである必要はありません。ただし、対応がないページへ切り替えたときの案内は必要です。外国語版にサービス説明があるのに、条件だけ日本語ページへ飛ぶ構成では、読者が判断できない可能性があります。最初に公開する範囲を、一つの経路としてそろえることを優先します。

翻訳依頼に原稿以外の情報を添える

翻訳を依頼する資料には、対象読者、文章の用途、用語集、固定する名称、相談できる範囲を添えます。原稿だけを渡すと、営業的な表現へ強めるべきか、仕様を厳密に保つべきか判断しづらくなります。重要な条件は、自然さのために省略しないことも伝えておきます。

確認の際は、原文と訳文を段落ごとに対応させます。どの日本語を更新するとどこが変わるか追える形にすれば、公開後の修正にも使えます。翻訳の版と元原稿の版を記録し、古い原稿に対する訳文を新しいページへ混ぜないようにします。

専門用語に複数の表記がある場合は、検索で使われる名称と正式な名称を区別して説明する方法があります。ただし、実際に使われているか未確認の言い回しを「現地では一般的」と断定しないでください。必要なときは対象言語を確認できる担当へ相談し、用語の根拠を残す形にします。

言語別URLと切替をどう実装するか

一つの言語版へ直接アクセスできるようにする

Googleの多地域・多言語サイトの案内では、言語ごとに異なるURLを使う設計が示されています。DIYでも、誰かに外国語版のURLを渡したとき、そのページへ直接進めるかを確認します。トップページでボタンを押した人だけが外国語表示になる状態では、共有や確認の方法を考える必要があります。

URLの形式は複数ありますが、見た目だけで選ぶのではなく、今のサイト構成と管理方法に合わせます。既存のURLを持つサイトでは、言語を追加するために過去のURLを無条件に変えないようにします。変更が必要なら、旧新の対応と転送、内部リンクを別に確認します。この記事は既存URLを変更する操作の手順ではありません。

確認用の対応表には、ページの役割と各言語のURLを一行で並べます。作成中、確認待ち、公開中といった状態も加えると、切替先を登録してよいか判断しやすくなります。公開していないページのURLを、見た目を整えるためだけに切替ボタンへ入れないことが大切です。

切替ボタンは同じ内容の対応先へつなぐ

サービス詳細で言語を切り替えたとき、別言語の同じサービスへ進めると、読者は読み直す範囲を減らせます。外国語版のトップへ戻すだけでは、目的の情報をもう一度探すことになります。完全な対応ページがない場合は、存在しないリンクを作らず、案内先の違いを分かるようにします。

言語名は、利用者が読める形で表示します。国旗だけでは、どの言語へ切り替わるのか、どの市場を対象にするのかが分かりにくいことがあります。言語と国を別に考え、自動的に表示を切り替える場合も、利用者が選び直す方法を残してください。

表は横にスクロールして比較できます。

本文の言語と検索向けの対応情報をそろえる

W3CのHTML言語宣言の説明は、ページの主要な言語を示すためのlang属性などを扱っています。これは読み上げなどの処理が言語を判断する手掛かりになります。一方、Googleはページの言語をコンテンツから判断すると説明しています。属性を付けただけで本文が翻訳済みになる、検索順位が上がる、という意味ではありません。

言語別ページの対応を示すhreflangについても、使っている構築方法でどこから設定するかを確認します。Googleのローカライズ版の案内には、自分自身を含む言語版や相互の対応について説明があります。DIYで設定する場合は、記号だけをコピーせず、実在するページの対応表と照合してください。

ここで必要なのは、専門用語を暗記することではありません。公開する本文の言語、直接開けるURL、切替先、検索向けの対応情報が同じ構成を示しているかを確認できることです。設定場所が分からない場合は、この対応表を渡して、その部分だけ外部担当へ確認を依頼できます。

問い合わせと更新をどう続けるか

問い合わせを受け付ける範囲を先に決める

外国語ページを公開するときは、何語でどこまで返答できるかを決めます。ページを英語にしたから、すべての取引を英語で即時に進められるとは限りません。必要なときに翻訳確認を挟むなら、その流れと担当を決め、実際に守れる案内だけを掲載します。

フォームの項目は、最初の返答に必要な情報から考えます。相談内容、返信先、希望する言語、対象地域などが候補ですが、すべての事業に同じ欄が必要なわけではありません。詳しい個人情報や取引情報を初回から集めすぎず、後から確認できる内容と分けます。

送信ボタンを置いたら、入力後の完了表示、自動返信、担当者通知を一つの経路として設計します。受付しただけなのに、予約や契約が確定したように見せないことが大切です。送信テストは、許可された宛先とダミーデータを使い、通知や外部連携へどこまで流れるかを事前に確認して行います。

更新する原本と各言語の差分を管理する

サイトの情報は公開後も変わります。対応製品、担当窓口、営業時間、問い合わせ先などが変わったとき、どの言語へ反映するかを追えるようにします。日本語だけを更新して終わらないために、原本の変更と各言語の反映状況を一覧にします。

表は横にスクロールして比較できます。

頻度を決めるだけでなく、変更が起きたときの入口を決めます。社内の担当が変わったら誰がサイト担当へ知らせるのか、商品条件の修正はどの原稿へ記録するのか、といった連絡の起点です。小さなサイトでも、ここが曖昧だと情報が古いまま残ることがあります。

自分以外の人が管理を引き継げるようにする

DIYで作ったサイトのアカウントやデータを、個人だけが持つ状態にしないようにします。誰が管理し、権限をどう渡し、担当交代時に何を確認するかを決めます。パスワードを原稿や作業メモへ平文で貼るのではなく、許可された安全な共有方法を使います。

バックアップがある場合も、何を戻せるのか確認します。文章の保存履歴だけなのか、設定や画像を含むのかで、復旧の範囲が違います。料金プランやサービスによって条件が変わる部分は、利用している契約の公式資料で確認してください。本記事は特定サービスの復元機能を保証していません。

管理を引き継ぐ資料には、言語ごとのURL、原稿の原本、用語集、更新手順、問い合わせの受信先、外部担当へ依頼した範囲を含めます。これらがまとまっていれば、将来別の構築方法へ変える場合も、見た目以外の条件を守りやすくなります。古い担当者の記憶だけに頼らない形を目指してください。

小さく作って外注へ引き継ぐには

最初の一経路を完成させる

最初から全言語・全ページを用意するより、対象を決めた一経路で実際の原稿を作ります。サービスの説明から条件を読み、問い合わせへ進み、返答の担当が分かるところまでです。ここを通して作ると、文章だけでなく、設定、翻訳、操作、運用の不足が見えてきます。

架空の小規模なB2Bサイトなら、まず日本語と一つの対象言語で、同じサービス説明と相談入口をそろえる構成が考えられます。対象国を増やす、商品を追加する、注文を受け付ける、といった拡張は、その小さな構成を維持できるかを見てから検討します。これは最適な言語数を一律に決める提案ではありません。

制作中に判断が止まったら、画面が作れないのか、原稿が決まらないのか、言語の意味が確認できないのかを分けます。原因が違うのに新しいツールへ乗り換えても、同じところで止まる可能性があります。分からない部分だけを言葉にすると、外部へ依頼する範囲も小さくできます。

外注の相談資料には完成イメージより判断材料を入れる

制作担当へ渡す資料は、好みのデザインだけでは足りません。対象読者、言語、ページの役割、相談までの流れ、更新の担当をまとめます。すでにDIYの試作があるなら、どこが使いやすく、どの操作や設定で困ったかを添えます。試作をそのまま採用するか、別の構成にするかを判断する材料になります。

表は横にスクロールして比較できます。

見積もりを比較するときは、翻訳、設定、画像、公開後の修正、保守など、何が含まれるかを分けて見ます。総額だけでは、同じ作業を比べているか分かりません。自社が担当する作業が残る場合は、その内容と期限も確認しておくと、納品直前の行き違いを減らしやすくなります。

DIYを止める判断と、全部作り直す判断を分ける

外部へ相談したからといって、作ったものをすべて捨てる必要はありません。確定した原稿、翻訳用の用語集、ページ対応表、読者の経路は、別の構築方法でも活用できる場合があります。残す情報と、技術的に作り直す範囲を分けて検討します。

ただし、既存のURLや公開中の内容を変更する場合は、以前のリンクから来る人への対応が必要です。見た目を一新する作業とURLの移行を同じものとして扱わず、旧新の対応、転送、通常URLでの表示を別に確認します。移行の検証をせず、外国語版だけ先に別の場所へ移すことも避けてください。

自社で判断を進めるなら、まず対象読者と言語、必要なページ、更新する人を一枚にまとめてみましょう。作業を説明できる部分はDIYで進め、意味や設定の判断が止まる部分を相談する形にすると、必要な支援が見えやすくなります。自分で作る範囲と依頼する範囲を相談する際は、未公開の顧客情報や認証情報を送らず、構成と困っている操作から共有してください。

よくある質問

日本語サイトがあれば外国語版も自分で作れますか？

原稿とページを追加する操作ができる場合でも、言語ごとのURL、対応ページへの切替、翻訳の意味、問い合わせ、更新方法を別に整える必要があります。まず一つのサービスと対象言語で小さな構成を作り、作業と確認の範囲を把握すると判断しやすくなります。

無料の翻訳機能を付ければ多言語化は完成ですか？

機能の対象範囲によります。本文の表示が変わっても、画像、資料、エラー、自動返信、直接開けるURLなどが別の扱いかもしれません。利用するサービスの公式説明で、保存・編集・反映の範囲を確認してください。翻訳が表示されたことだけで、意味や導線まで確認済みにはなりません。

外国語を話せないとDIYはできませんか？

サイトの構築作業と、言語の意味確認を分ける方法があります。正式な条件を自社で整理し、対象言語を確認できる人へ訳文の確認を依頼できます。専門用語や取引条件の意味を確認できないまま、翻訳ツールの出力だけで確定しないことが大切です。

どこまで作ったら外注へ相談すればよいですか？

完成してからでなくても構いません。対象読者、言語、必要なページ、問い合わせの流れを決め、判断が止まる部分を示せれば相談材料になります。原稿の整理、言語確認、設定、運用のどこを依頼するか分けると、全部作り直す必要があるかも検討できます。

出典・確認日・運営者

既存SEO技術資料の確認日：2026年11月5日。サムハラ神社の表記資料確認日：2026年11月7日。執筆・編集：タゲンゴ編集担当。掲載した構成やB2Bサービスは架空の検討例です。顧客の体験、制作成果、実施済み試験として示したものではありません。参拝と稽古の部分は、運営者本人が提供した体験を整えたものです。

• Google検索セントラル：多地域、多言語のサイトの管理
• Google検索セントラル：ローカライズされたページ
• W3C：HTMLにおける言語の宣言
• サムハラ神社公式サイト
• 大阪府神社庁：サムハラ神社（さむはらじんじゃ）