［ 初回公開日：
2026/6/18
］
Studioで多言語サイトはつくれる？ ― 対応方法と選び方、公開後の注意点
シリーズ（全5本）
Studioで多言語サイト × Cookie同意
↓ 決めた範囲に合わせて、2つの実例から選ぶ
「サイトを英語や中国語にも対応させたい」。インバウンドや海外との取引が身近になり、こうしたご相談が増えています。すでにStudioでサイトを持っている方、これからStudioで作ろうとしている方から、よく聞かれるのが「Studioで多言語ってできるの？」という素朴な疑問です。
結論から言うと、できます。ただし、やり方が何通りかあって、規模やこだわりで向き不向きが変わります。フラットに整理します。
そもそも、Studioは多言語に対応してる？
正直にお伝えすると、Studioには「ボタンひとつで多言語に切り替わる」ような標準の多言語機能は、今のところありません（2026年9月時点）。
とはいえ「Studioだと多言語は無理」ということではなく、ページ構成や外部ツールを組み合わせて実現する、というのが実際のところです。Studioの公式ヘルプにも「Studioで多言語サイトを作成したい」（2026年5月更新）という記事があり、専用機能は無いと明言したうえで、4つの作り方が"事例"として紹介されています。
ひとつのプロジェクト内に言語ごとのページを作る（
example.com/en/）言語ごとにプロジェクトを分けてサブドメインで公開する（
en.example.com）言語ごとにプロジェクトを分け、カスタムプロキシでサブディレクトリにつなぐ（Business Plus以上）
外部の翻訳サービスを使う
本記事の「①手動」は上の1、「②〜④ツール」は4にあたります。
2と3は、Studioの機能だけで多言語にする方法です。言語ごとにプロジェクトを分けるため、言語の数だけ有料プランの契約が要り、デザインの変更や記事の追加もプロジェクトごとに手でやり直すことになります。国ごとに中身の違うサイトを持つなら向いていますが、同じサイトを訳して見せたいなら、1かツールを使うほうが現実的です。
後半の「URLの形」で比べるサブドメイン型・サブディレクトリ型も、主にツールで作る場合の話です。URLの形は2・3と同じでも、Studioのプロジェクトは1つのまま。日本語を直せば、機械翻訳の部分は各言語にも自動で反映されます。なお Studio は特定のツールの推奨や連携の保証はしておらず、個別の相談に応じるのは Enterprise の一部プランのみです。
多言語にする "やり方" と、翻訳の品質
まず大きな分かれ道は「手動で作るか、ツールを使うか」。そしてツールを使うなら、翻訳の品質をどこまで上げるかを選べます。②〜④は、手間をかけない順です。
① 手動で1ページずつ作る（ツールなし）
言語ごとにページを複製して、翻訳を入れていく方法です。ページ数が少なく（数ページ）、言語も1つくらいなら、これで十分。ただし「ページ数 × 言語数」だけ手間が増え、日本語を直すたびに各言語も手で直すことになるので、規模が出てくると現実的ではなくなります。
手動で作るときに1つだけ忘れやすいのが、英語ページの「言語設定」です。Studioはサイト全体の言語とは別に、ページ単位で言語を指定できます（公式ヘルプ「公開サイトの言語設定」・2026年3月更新）。これを入れないと、英語のページなのに「日本語のページです」と宣言したまま公開される形になり、ブラウザの翻訳機能やスクリーンリーダーの言語判定が正しく働かないことがあります。英語ページを作ったら、ページ設定の[言語設定]で英語を選んでください。この設定は「このページは何語か」の宣言で、hreflang（言語版どうしの対応づけ）とは別のものです。
①を選ぶなら、下訳を生成AIに作らせる手はあります。訳文を自分で用意してページに流し込む方式なので、原稿の作り方は自由です。プロ翻訳より安く、機械翻訳より文脈に合わせやすい。
②〜④のようにツールへ任せる場合、生成AIの使い方は2つあります。ツール内蔵のAI翻訳を使う方法（Weglot は OpenAI や Google の大規模言語モデルを翻訳の改善に使っています）と、外部で作って人が確認した訳文を、ツールの管理画面で反映する方法です。
② ツール＋機械翻訳（自動・手軽）
多言語ツールを連携すると、自動で全ページが翻訳されます。日本語（元サイト）を更新すれば、機械翻訳の部分は各言語にも自動で追従します。まず多言語サイトを立ち上げる、という段階では、これが手軽です。
（Studioでの具体的な導入手順は、別記事「STUDIOでの多言語対応！Weglotを使った手順とポイント」に。）
③ ツール＋用語集で、精度を上げる
同じ "自動翻訳" でも、仕上がりの質は一律ではありません。順番としては2段階で考えると分かりやすいです。
まず、ツール自体が持つ翻訳エンジンや辞書の性能で、自動翻訳の "素の精度" が決まります。とくに日本語や自分の業界の言葉にどれだけ強いツールかで、最初に出てくる訳の質がかなり変わります。
そのうえで、自社ならではの専門用語・会社名・商品名・型番などを "用語集" に登録すると、表記がブレず、さらに精度が上がります。ツールを選ぶときの、地味だけれど大事なポイントです。
④ ツール＋プロ翻訳で、仕上げる
会社の顔になるページや、商品をしっかり説明したいページなど、こだわりたい部分は人の翻訳を組み合わせます。いちばん手はかかりますが、品質は最高です。ただし、日本語の元の文を変えると、手直しした訳ではなく新しい自動翻訳に切り替わるツールもあります（Weglot など）。元の文を直したときは、その箇所の訳も見直してください。
②〜④は、同じ「ツールを使う」中での品質の違いです（①だけがツールなし）。①→④へ必ず進むものではなく、自社に合う一点を選べばOK。ページごとに「自動でいい所」「手をかける所」を分けることもできます。
どれを選べばいい？
①手動が向くケース：固定ページが少ない／必要なページだけ各言語があればOK／ブログなどCMSの多言語は不要、という場合。弊社サイトにも、説明用に手動でつくった英語ページがあります（itplus.co.jp/eng）。
②ツールで自動化が向くケース：ページや言語が増える、更新が多い。運用が一気に楽になります。
③④で品質を上げるべきケース：ブランド・商談・ECなど、訳の質が成果に直結するとき。用語集で精度を上げ、こだわるページはプロ翻訳を組み合わせます。
ツールをざっくり例示すると、こんな分かれ方になります。
英語中心・ページ少なめ・費用を抑えたい → 月額が手頃で、自分で設定・運用できるツール（例：Weglot）
ページ数が多い・導入から運用まで相談しながら進めたい → 国内で実績があり、日本語でサポートを受けられるツール（費用は規模により個別見積もり）
迷ったら「どのページに、どこまで質を求めるか」をページ単位で考えると、すっきり決まります。全部を同じ品質でやる必要はありません。
費用の輪郭（ざっくり）：手動はツール代こそ不要ですが、その分の手間（人件費）がかかります。ツールは月額制（文字数やPVで段階課金）が一般的。さらに、サブディレクトリ型にするなら、Studio側も上位プランが必要になることがあります（後述）。「初期費用」だけでなく「更新し続ける運用コスト」で見るのがコツです。
始める前に、知っておくと損しないこと
迷ったときの相談先を、最初に見つけておく。多言語化は外部のツールを組み合わせて行うので、導入や運用で頼れる先（制作会社・SEO会社・翻訳ツールの会社など）があると安心です。Studioの公式ヘルプも、Studio Expert による構築支援をすすめています。
画像の中の文字は、自動では訳されないことが多い。バナー・図版・PDFなどは言語別に作り直し（差し替え）が必要です（ツールによっては画像まで自動で翻訳して表示できるものも出てきています）。
言語によって文字数が変わり、デザインが崩れることがある。日本語に合わせて作ったボタンや見出しが、英語やドイツ語だと長くなってはみ出す、など。多言語を前提に余白を見ておくと安心ですが、全てに対応するのは難しいためこのあたりもツールによっては自動で調整してくれるものも出てきています。
全部訳すか、絞るか。海外に読者がいるページは訳す。一方で、国内限定の告知などは、無理に全部訳さなくても構いません。
「翻訳ページがどのドメインで配信されるか」も見る。自動翻訳サービスの中には、翻訳したページを自社ドメインではなく翻訳事業者側のドメインで配信するタイプがあります。導入は手軽ですが、検索での評価がその事業者のドメインに積み上がり、自社サイトの資産になりにくくなります。Cookie同意（CMP）やアクセス解析もドメイン単位で設定するので、翻訳側のドメインでも設定し直すことになります（例えばCookiebotはサブドメインですら別ドメインとして数えます）。そもそも「英語で読める」ことと「英語で検索して見つかる」ことは同じではありません。インバウンド向けに"検索から来てもらう"つもりなら、翻訳ページが自社ドメイン（
en.◯◯や◯◯/en/）に載る方式を選んでください。（補足：Google自身にも、検索結果のタイトルと説明文を利用者の言語に機械翻訳して見せ、クリックすると機械翻訳したページを表示する機能があります。ただしGoogleが翻訳版のサイトを別途ホストする仕組みではないので、これは「自社の英語ページがある」ことの代わりにはなりません。）
URLの形は最初に決める。後から変えにくいからです。サブドメイン型（
en.◯◯）とサブディレクトリ型（◯◯/en）で変わるのは、管理のしやすさと運用です。Google 公式はどちらが検索順位で有利とは言っていません。一方、SEO の実務では「サブディレクトリの方がサイト全体の評価をまとめやすい」という見方が今も一般的です（公式の根拠ではなく、事例にもとづく見立てです）。アクセス解析（GA4）は、どちらの方式でも1つのプロパティで計測できます（言語版をまたぐ計測の注意はWeglot記事の第7章）。
サブディレクトリ型をStudioで実現するには
方法は3つで、必要なプランが違います。
同じプロジェクトの中に
/en/のページを作る（手動）：追加費用は要りませんが、ページ数は今のプランの上限までです。公式ヘルプが「最もコストを抑えて実現できる方法」としているのはこれです。IT+が検証用に用意した小規模ホテルのサンプルサイトも、この方式です（実例記事）。言語ごとに別プロジェクトを立て、カスタムプロキシでつなぐ：Business Plus 以上のプランを言語の数だけ契約し、カスタムプロキシのアドオンも付けるのが前提です。設定にはサーバーやネットワークの知識が求められる、と公式も注意しています。
外部の自動翻訳ツールでサブディレクトリにする：ツール側のプロキシやCDNを、サイトの前段に置くやり方です。Studioのサポート対象外で、相談できるのは Enterprise の一部プランです。できるかどうかは、ツールの仕様とStudio側の契約条件の両方で決まります。
なお、カスタムプロキシで差し込んだ区画には、親サイトに入れているタグ（Cookie同意バナーや計測タグ）が自動では載りません。その区画側にも同じ設定を入れる必要があります（IT+が他社サイトの実装を調べていて気づいた点です）。
ツールを入れた "後" が、実は大事 ― 自社で検証して分かったこと
ここはIT+の実体験から、少し踏み込んでお伝えします。私たちは自社サイトも多言語化していて（Weglotを使っています）、ときどきサイト監査ツールで健全性をチェックしています。
多言語ツールは、検索エンジン向けの hreflang（「このページには各言語・地域向けの版があり、ユーザーに合った版を出してください」と検索エンジンに伝える記述）を自動で入れてくれます。ただし、ツールやサイトの構成によっては、サイト監査ツールが「不足している」と指摘を出すことがあります（下層ページでURLが相対指定になる、x-default が入らない、など）。このうち、URLの相対指定や、言語版どうしの参照の抜けは、Google に正しく読まれないので直す必要があります。x-default は推奨の設定で、必須ではありません。実際、私たちも自社サイトを監査して、headに記述を補う対応をして整えました。
詳しくは別記事「STUDIOでの多言語対応！Weglotを使った手順とポイント」に実際のスクリプトの例と合わせて掲載しています。
あわせて、自社で運用して分かったことを3つ。
IT+のサイトでは、Cookie同意を得るまでJSを読み込まなくても、訳は崩れませんでした。サブドメイン方式では、ページは翻訳ツールのサーバー側で訳されてから届きます。サイトに貼るJavaScriptが担うのは、言語切替ボタンの表示、表示を速くするためのキャッシュ（ブラウザ内の保存）、ページ表示後に生成される要素の翻訳です（Weglot公式）。JSを外したときと動かしたときで比べても、日本語のまま残る部分は増えませんでした（2026年9月）。
そのキャッシュは、Cookie同意（CMP）の対象になり得ます。多言語ツールがブラウザに置く保存データは、CMPのスキャンに項目として出ます。Weglot公式はこのキャッシュを「必須（Necessary）」に分類していますが、IT+では、確認した表示範囲ではJSなしでも翻訳が出ることを踏まえ、運用方針として「機能性（Preferences）」に置き、同意を得てからJSを読み込んでいます（JSはGTMに移して制御。詳しくは後編の第7章）。
「多言語対応した」＝「EU向けに対応が要る」ではありません。EU域内に拠点を持たない日本の事業者の場合、GDPRが及ぶかどうかは「EU域内にいる人に商品・サービスを提供しているか（＝狙っているか）、またはその人の行動を監視しているか」で見ます。どの言語を並べたかは判断材料の1つで、対象市場や価格の通貨、配送の範囲などと合わせて総合的に見られます。言語の数だけで決まるわけではありませんが、EU圏の言語を足すときは、Cookie同意の費用と一緒に考えてください（前編の第2章）。
もうひとつ。多言語サイトの状態は、日本語版やトップページだけ見ても分かりません。日本語版はソース言語として手が入っていて健全なことが多く、それを基準にすると他言語版の不具合が見えなくなりがちだからです。英語版・中国語版……とすべての言語版を、しかもトップだけでなく下層ページまで横断してチェックする必要があります。さらに、各版が単体で正常に見えても、版どうしの連携（どの言語版を誰に出すか）の設定ミスで、検索結果に適切な言語版が出ないこともあります。こうした問題（ページが表示されない・タイトルが抜けている・検索に載らない、など）は埋もれたまま、「問題なし」と誤解されやすいのです。
つまり多言語サイトは、「ツールを入れて終わり」ではなく、公開した後に全言語版を確認して仕上げて、はじめて完成します。ここは見落とされやすいところ。制作会社・SEO会社・翻訳ツールの会社と連携して詰めて行く必要があります。
まとめ
Studioでも、多言語サイトは十分につくれます。大事なのは「規模とこだわりに合ったやり方を選ぶこと」、そして「公開後の確認まで含めて考えること」。手動で十分なケースもあれば、ツールで自動化したほうがいいケースもあります。
もし「うちの場合はどの方法がいいんだろう」と整理したい段階でしたら、気軽にご相談ください。弊社は翻訳の専門会社ではありませんが、実際に手を動かして検証してきた経験から、まず前段の整理（どのやり方・どんな構成が合うか）をさせていただいたうえで、Studio Enterpriseのご担当者さんや日本国内で実績のある翻訳ツールの会社さんへおつなぎします。
※制作を弊社にご依頼いただかなくても全然構いませんw
【補足】多言語化対応に必要となるCookie同意バナーについての関連記事
※Studioの仕様・公式ヘルプの記述・ツール名は2026年9月時点の情報です。仕様は変わるため、最新は各サービスの公式情報をご確認ください。
この記事を書いた人
