BLOG

ブログ

TOP

>

BLOG

>

【実例】小規模ホテルのサイトを、Studio×多言語×宿泊予約(CHILLNN)×Cookie同意で作ってみた(無料ツール中心)

すべてStudio
Studio初心者ガイド
Studioテンプレート
Studioはじめてみた
Shopify
ネットショップ
デザイン
MA/CRM
初心者EC
世界一周

2026/10/14

[ 初回公開日:

2026/7/17

]

【実例】小規模ホテルのサイトを、Studio×多言語×宿泊予約(CHILLNN)×Cookie同意で作ってみた(無料ツール中心)

インバウンド向けの小規模な宿のWebサイト----「多言語対応したい」「サイトから直接予約を取りたい」「海外からのアクセスにCookie同意はどこまで必要?」。よく相談を受けるテーマを、ノーコード+無料ツール中心でどこまで実現できるか、実際にサンプルサイトを作って検証しました。

作ったのはこちらです(架空のホテルのサンプル)。

IT+HOTEL|明治神宮前 — https://sample-hotel.itplus.co.jp

2026年10月に、Cookie同意の組み方を「GTM経由」から「ページに直接置く形」へ作り直しました。理由と、作り直したあとの実測結果も載せています。

使ったもの(すべて既製・無料中心)

役割

使ったもの

補足

サイト本体

Studio純正の無料テンプレート「リバーサイドホテル&ホステル」

ノーコードで土台が完成

多言語(英語)

固定ページを複製して手動制作

数ページ・更新頻度低なら手動で十分

宿泊予約

CHILLNN

Studioサイト内で予約が完結(外部遷移なし)

Cookie同意バナー

CookieYes(無料版)
*Cookiebotなど他にもあります

サイト全体のカスタムコード(head)に直接設置。無料版は全ページにバナーが出る。月5,000PV・スキャンは1回100ページまで

アクセス解析

GA4 + Search Console

GA4はGTM経由

独自ドメイン

サブドメイン(sample-hotel.itplus.co.jp)

自社ドメインで見せられる

ポイントは、予約までStudioサイトの中で完結すること。宿泊予約(CHILLNN)を埋め込めるので、「サイトを見る→そのまま予約」が外部サイトに飛ばずに繋がります。

※「無料中心」はツール利用料の話です。実運用では、宿泊予約の手数料や独自ドメインの取得・維持費など、別途費用がかかります。また、Studioで独自ドメインを使って公開するには、Studioの有料プランが必要です。

多言語は「固定ページの複製+手動翻訳」で十分なケースが多い

今回のようにページ数が少なく・更新頻度が低いサイトは、日本語ページを複製して英語ページを作り、翻訳を流し込む「手動の多言語」で十分です(URLは頭に /en を付与)。ページ数が多い・更新が頻繁・言語数が多いサイトになると、翻訳を自動管理するツール(Weglot・WOVN等)が向いてきます。

英語ページを作ったら、Studioのページ設定で「言語設定」を英語にしておきます(サイト全体の設定とは別に、ページ単位で指定できます)。これを忘れると、英語のページが「日本語のページ」として宣言されたまま公開され、ブラウザの翻訳やスクリーンリーダーの言語判定が正しく働かないことがあります。この設定は「このページは何語か」の宣言で、hreflang(言語版どうしの対応づけ)とは別のものです。今回のサンプルサイトも、公開時にこれを入れ忘れていて後から直しました。

あわせて、hreflang(「このページの英語版・日本語版はこれ」と検索エンジンに伝える宣言)を入れておくと、英語で検索した人には英語ページ、日本語で検索した人には日本語ページが正しく表示されやすくなります。今回はページごとに手で書くのではなく、1つのスクリプトで全ページ分を自動生成する形にしました(ページを増やしても追記不要)。


Cookie同意バナー:全ページで同意まで止め、予約はボタンで開く

今回のサンプルは、こう組んでいます。

  • 日本語ページにも英語ページにも、Cookie同意バナーを表示します

  • 同意(Accept)を押すまで、アクセス解析(GA4)は何も送らず、Googleマップも読み込みません

  • 宿泊予約は、同意しなくても使えるように、ボタンを押したときに読み込む形にしました

CookieYesの無料版は、バナーを出すページを管理画面で選べません(特定のページでバナーを止める機能は Pro プラン以上)。そのため今回は全ページに設置していて、日本語ページにもバナーが出ます。ここが無料版の限界です。

GA4も、全ページで同意まで送らない設定(同意モードの基本モード)にしました。言語や地域で出し分けたい場合は、後述の「どこまでやるか」を参照してください。

あわせて、「利用者情報の外部送信について」の公表ページも置いています(義務の対象になるかは、提供している役務の内容によります。自社の宿の案内と予約だけのサイトは、総務省のFAQで対象外の例に挙げられています。必要な公表内容は前編を参照)。

なぜGTMではなく、ページに直接置いたのか

最初(2026年7月)は、CookieYesをGTM経由で入れ、英語ページだけにバナーを出していました。このとき同意と連動していたのは、GTMから出しているGA4だけです。

予約(CHILLNN)は、StudioのApps連携でStudio自身がページに入れています。Googleマップの埋め込みも、GTMとは関係なくページに入ります。今回のGTM経由の設定では、この2つを止められませんでした。

実際に、GTM経由の形で英語トップを同意前に開くと、次のものが動いていました。

  1. CHILLNNの空室データの取得

  2. CHILLNNが組み込んでいる監視サービス(New Relic)への送信

  3. その監視サービスの値の、ブラウザへの保存

そこで、CookieYesのタグをStudioのサイト全体のカスタムコード(head)に直接置きました。CookieYesもCookiebotも、ほかのスクリプトを自動で止める機能は、CMPのタグを先に読み込ませる前提で案内しています。

Studioのカスタムコードはheadの末尾に入り、一番先頭には置けません。ただ、GTMとCHILLNNのタグはbodyの最後に出力されるので、headの末尾でもそれより先に動けます(公開したページのHTMLで並びを確認しました)。

コードは、CookieYesの公式手順(GTMのテンプレートを使わない方法)に沿ったものです。

<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){ dataLayer.push(arguments); }
  gtag("consent", "default", {
    ad_storage: "denied", ad_user_data: "denied", ad_personalization: "denied",
    analytics_storage: "denied", functionality_storage: "denied",
    personalization_storage: "denied", security_storage: "granted",
    wait_for_update: 2000
  });
  gtag("set", "ads_data_redaction", true);
  gtag("set", "url_passthrough", false);
</script>
<!-- YOUR_ID は CookieYes の管理画面に出る ID -->
<script id="cookieyes" type="text/javascript" src="https://cdn-cookieyes.com/client_data/YOUR_ID/script.js"></script>

設定したのは次の5つです。

  1. 上のコードを、Studioのサイト設定のカスタムコード(headの末尾)に追加

  2. CookieYesの管理画面の[Advanced Settings]→[Google consent mode (GCM)]で、「Support GCM」をオン、「Allow Google tags to fire before consent」をオフにする。オンにすると、同意前もGoogleのタグが動きます

  3. CookieYesの管理画面で、Googleマップ(google.com/maps)を「Functional」のスクリプトとして登録

  4. 予約部品を、ボタンで開く形だけにする(ページに直接置く空室カレンダーの部品を外す)

  5. GTMで入れていたCookieYesのタグを停止(二重に読み込まないため)

なお、Studioの公式ヘルプはCookiebotをGTMのテンプレートで入れる手順を紹介しています。GA4のようにGTMで管理しているタグだけなら、その手順で足ります。

予約まで止めると、同意しない人は予約できない

CHILLNNの予約部品には、ページに空室カレンダーを直接表示する方式と、ボタンを押すと予約画面が開く方式があります。

ページに直接表示する空室カレンダーの例
ページに直接表示する空室カレンダーの例(サンプルサイトでは使っていません)

カレンダーを直接表示する方式は、ページを開いた時点で予約システムと通信します。そこで、同意前の通信・保存を避けるため、予約部品全体を同意まで止める方法も試しました。

形

開いた時点で外へ出るもの

同意しない人の予約

空室カレンダー

カレンダーを直接表示し、予約部品を同意まで止める

予約部品のファイルの取得だけ

できない(同意した直後の同じページでも動かない)

同意して、次のページから

ボタンで開く形だけにする(採用)

予約部品と決済(PAY.JP)のファイルの取得だけ。保存なし

できる

ボタン → 日付を選ぶと表示

予約は宿の売上そのものなので、同意しない人が予約できない形は採りませんでした。

EUのルール(ePrivacy指令5条3項)は、利用者がはっきり求めたサービスを提供するのに欠かせない保存・読み取りを、同意の例外にしています。予約ボタンを押す前から予約部品が通信し、ブラウザに保存する形は、この例外に当てはめにくいので、押したときに読み込む形にしました。

代わりに、空室カレンダーはトップに直接は出ません。ボタンを押してから日付を選ぶ、ひと手間が増えます。サンプルサイトのトップには、直接表示するカレンダーの見本を画像で載せています。

Studioの「非表示」では止まらない

最初は、空室カレンダーを「非表示」にして済ませようとしました。ところが、Studioは非表示にした要素もHTMLに出力します(画面上で隠すだけ)。CHILLNNのカレンダーは、非表示の中でも読み込まれて通信していました。

止めたいときは、非表示ではなく部品そのものを外します。

作り直したあとの実測(2026年10月)

新しいブラウザで日本語と英語のトップを開き、ページを下まで見て、通信とブラウザへの保存を数えました。日本語も英語も同じ結果でした。

状態

GA4

Googleマップ

予約(CHILLNN)

ブラウザへの保存

開いた時点(同意前・拒否後とも)

計測の送信なし(GTM本体のファイルは読み込む)

読み込まない

予約部品と決済(PAY.JP)のファイルの取得だけ

なし(Studio内蔵解析の分と、同意の記録を除く)

予約ボタンを押した

―

―

空室データの取得・New Relicへの送信。予約画面が開く

New Relicの値など

同意した

送信を始める(Cookieあり)

同じページで読み込む

変化なし

GA4のCookie

Studio内蔵のアクセス解析は、どの状態でも送信していました(止める設定がありません)。

「どこまでやるか」はサイトのターゲットと規模で変わる

Cookie同意の対応は、唯一の正解があるわけではなく、狙う顧客と企業規模で実務的な選択肢がいくつかあります。

  • もっと簡易:バナーは通知のみ(「情報を送信しています」と知らせるだけ)。外部送信規律では通知・公表/同意/オプトアウト措置のいずれかが求められるので、その「通知」で対応する形。→ 後編の表の A(公表だけ)に近い形です。

  • 今回(中間):全ページにバナー+同意までGA4と地図を止め、予約はボタンで開く(無料・設置は1か所)。→ 後編の表の B(英語ページに無料で)と同じく無料ですが、バナーは日本語ページにも出て、止める相手も訪問者全員です。

  • より本格的(地域最適化):EU圏からのアクセスだけバナー+同意まで停止し、それ以外の地域はまず計測する----という「地域で出し分け」。国内の計測やUXを守りながらEUにだけ厳格対応する形で、地域判定の機能が必要になります(今回使ったCookieYesでは Pro プラン以上、Cookiebotでは Premium Lite(月€7〜)以上の機能です・2026年10月時点)。CookieYesでは、日本語ページなど特定のページだけバナーを止める機能も Pro 以上です。→ 後編の表の C(バナーもEU圏だけに)です。

そもそも、GDPR(EUの規制)が自分のサイトに適用されるかどうかは、EU域内に拠点を持たない日本の宿の場合、「EU域内にいる人に商品・サービスを提供しているか(=狙っているか)、その人の行動を監視しているか」で決まります。英語ページがあっても、EU向け言語やユーロ建て決済がなく、特にEU市場を狙っていなければ、適用は薄いと考えられます。ただし宿泊業は注意が要ります。EUのガイドラインは、場合によっては、観光のように活動そのものが国際的なこと自体が判断材料になり得る、と例示しています。とくにフランス語・ドイツ語・スペイン語などEU圏の言語のページを足すと、「EUの人向けに作っている」と見られる材料が増えます(決め手は1つではなく、対象市場や通貨などと合わせた総合判断です)。言語を増やすときは、Cookie対応の形も一緒に見直してください(判断材料の一覧は前編の第2章に)。だからこそ「どこの客を狙うか」に応じて、対応を過不足なく選ぶのが現実的です。

なお、英国は2026年2月の改正で、サイト改善のための統計目的の解析に限り、目的の説明と簡単な拒否手段があれば同意なしでも使える形になりました(国別の違いは前編の表を参照)。

👉 Cookie同意の考え方・実装の詳しい選び方は、こちらの記事で解説しています。 Studio×多言語×Cookie同意の判断・実装記事へ


これは何のサンプルか(正直に)

このサイトは「こういう見せ方ができます」というサンプル(デモ)です。実在の宿泊予約やデータ収集を目的としたものではありません。

そのうえで、作り直したあとも残っている点を書いておきます。

  1. Studio内蔵のアクセス解析は、同意に関係なく送信されます。Studioに止める設定がないためです

  2. 予約ボタンを押したあと、CHILLNNは監視サービス(New Relic)へ送信し、ブラウザに値を保存します。予約に欠かせないものとまでは言い切れませんが、サイト側では止められません

止めていない送信先は、サンプルの公表ページ(利用者情報の外部送信について)に載せました。ただし、公表すれば同意が要らなくなる、という意味ではありません。


まとめ

  • Studio純正の無料テンプレ+CHILLNN(予約)+CookieYes(同意)+手動の多言語で、インバウンド向け小規模ホテルのサイトは無料ツール中心で作れる

  • 予約までサイト内で完結、多言語・hreflang・アクセス解析・独自ドメインまで込み

  • CookieYesの無料版は、サイト全体に1か所置くだけで使える。ただし全ページにバナーが出る。言語や地域で出し分けるなら有料版

  • 予約はボタンで開く形にすると、同意しない人も予約できる

  • 同意前に何が動いているかは、実際に数えて確かめる

「多言語にしたい」「サイトから予約を取りたい」「Cookie同意はどうすれば」----このあたりをまとめて相談したい方は、多言語サイト制作サービスをご覧ください。宿泊業向けの予約連携プランもあります。

(本記事のサンプルは、IT+が制作の実例として公開しているものです)

関連記事

※掲載のツール名・料金・仕様は2026年10月時点の情報です。仕様は変わるため、最新は各サービスの公式情報をご確認ください。

※本記事は法的助言ではありません。具体的な対応は弁護士等の専門家にご相談ください。

この記事を書いた人

一覧に戻る

おすすめ記事

CONTACT

お問い合わせ・ご相談はこちら

IT+

株式会社アイティプラス

〒150-0001 東京都渋谷区神宮前3-25-18
THE SHARE 2F

チャネルトーク

チャネルトーク認定パートナー

Shopify Partners

shopify認定パートナー

Studio Templates

「Studio Store」にて、テンプレート販売中

STUDIOテンプレート 和食STUDIOテンプレート 病院STUDIOテンプレート 和食

©2014  ITPLUS, Inc.