結論: 民宿のホームページは自作できます。ただし、自作しやすいのは施設案内、客室・食事・アクセスの説明、問い合わせへの入口までです。空室を販売し、予約を即時確定し、カードで事前決済する場合は、対応する予約エンジン、在庫連携、決済事業者を使う構成が現実的です。最初に「フォームを受け付けた状態」と「部屋を確保して予約が成立した状態」を分け、OTA・電話・自社予約が参照する在庫の正本を一つ決めてください。
この記事の要点 対象読者: 小規模な民宿・ペンション・ゲストハウスを運営し、自分で公式サイトを作るか、制作や予約機能を外注するか判断したい方 読了後にできること: 3つの構成から自館に合う方式を選び、最小ページ、予約導線、在庫、決済、表示事項、公開テスト、月次KPIを一枚の要件表へまとめられる
「民宿のホームページを無料で作りたい」という相談では、ページを公開する作業と、宿泊契約を安全に成立させる作業が混ざりがちです。写真と文章を載せたページは無料または低い固定費でも試せます。一方、空室の自動判定、複数OTAとの在庫同期、プランごとのキャンセル条件、本人認証を伴うカード決済、返金は別の仕組みです。無料のフォームを付けても、自動で部屋が確保されるわけではありません。
この記事では、特定の制作サービスを一律に推すのではなく、2026年9月11日時点の公式情報を基に、民宿の公式サイトをどこまで自作し、どこから専用サービスへ渡すかを整理します。サービスの料金、無料枠、接続先、決済手数料は変更され得るため、契約時には各社の料金表・利用規約・対応表を再確認してください。検索順位、予約増加、無事故、無料での継続を保証する内容ではありません。
民宿の集客全体、口コミ、SNS、リピーター施策を先に整理したい場合は、民宿・ペンションの集客方法に分けて解説しています。本稿は、公式サイトの自作範囲と、予約を成立させる仕組みに集中します。
目次
まず決める｜問い合わせ受付と予約確定は同じではない
ホームページを作り始める前に、ボタンを押した後の状態を決めます。表現が「予約する」なのに、実際は担当者が後で空室を確認するだけなら、利用者は部屋が取れたと誤解する可能性があります。反対に、単なる問い合わせフォームへ空室保証まで求めると、返信前にOTAや電話で同じ部屋が売れたときに二重予約が起きます。
| 受付方式 | 送信直後の状態 | 在庫の確保 | 利用者へ必ず伝えること | 向く運用 |
|---|---|---|---|---|
| 問い合わせ | 質問を受け取っただけ | しない | 予約ではない、回答予定、緊急連絡先 | 空室以外の質問、団体・長期滞在の事前相談 |
| 予約リクエスト | 希望条件を受け取った状態 | 担当者確認まで未確保 | 未確定、回答期限、確定通知の方法 | 予約件数が少なく、営業時間内に人が照合できる宿 |
| 即時予約 | システム上の条件を満たせば成立 | 送信処理と連動して確保 | 総額、日程、人数、条件、確定番号 | 在庫・料金・決済を予約エンジンで管理できる宿 |
「送信完了」は通信処理の完了であり、常に宿泊予約の成立を意味するわけではありません。予約リクエスト方式では、入力画面、送信ボタン、完了画面、自動返信のすべてに「この時点では予約未確定」と表示します。担当者が在庫を確認した後、予約番号、宿泊日、人数、部屋、食事、総額、支払条件、キャンセル条件を含む確定通知を送り、その時点を自館の約款と運用に合わせます。
即時予約方式では、最終確認画面で条件を見せ、申込操作の意味を明確にします。観光庁のモデル宿泊約款では、宿泊契約は宿泊施設が申込みを承諾したときに成立する構成です。ただしモデル約款はひな型であり、そのまま載せれば自館の契約条件が完成するわけではありません。実際の予約画面、確定通知、自館の宿泊約款で成立時点を矛盾させないことが重要です。
コピー用テンプレ1: 予約リクエストの自動返信
件名: ご宿泊希望を受け付けました（この時点では予約未確定です）
［宿名］へご連絡いただき、ありがとうございます。
次の希望内容を受け付けました。
宿泊希望日: ［到着日］〜［出発日］
人数・室数: ［大人・子ども・室数］
希望プラン: ［プラン名］
現在、空室と受入条件を確認しています。このメールだけでは予約は確定していません。
［回答する期限または営業時間］までに、確定可否と総額をご連絡します。
予約確定の通知には、予約番号、宿泊条件、支払方法、キャンセル条件を記載します。
当日予約や期限を過ぎても返信がない場合: ［実際に対応できる連絡先・時間］
※そのままコピーして使えます
民宿ホームページを自作する3つの構成
自作方法は、使うサービス名よりも「誰が空室を確保し、誰が予約を確定し、どの画面で支払うか」で選びます。次の3構成は優劣ではなく、予約件数、販売チャネル、担当時間、必要な機能に応じた選択肢です。
構成A｜案内ページ＋問い合わせフォーム
施設案内を自作し、空室の質問や予約希望をフォームで受け、担当者が在庫の正本を確認して返信します。フォームは希望の受付までで、部屋を自動確保しません。月の問い合わせが少なく、電話・OTAを含む予約を一人の担当者が決めた時間内に照合できる場合に限って運用しやすい構成です。
初期のページ制作費を抑えやすい一方、返信前の売り違い、休館日の受付、担当者不在、転記漏れが弱点です。「24時間予約」と表示せず、「24時間リクエスト受付、予約確定は担当者の返信後」のように実態を書きます。Googleフォームなど汎用フォームを使う場合も、カード番号やセキュリティコードは入力させません。
構成B｜自作サイト＋外部予約エンジン＋ホスト型決済
客室、食事、アクセス、よくある質問は自作サイトで説明し、空室検索以降を外部の予約エンジンへ渡します。複数OTAを使う場合は、予約エンジンとOTAの在庫・料金・予約データを接続できるサイトコントローラーやPMSを検討します。カード決済はPCI DSS準拠状況を確認した決済事業者のホスト型画面で行い、自作サイトのフォーム、メール、LINEではカード情報を受け取りません。
小規模な宿が「説明は自分で更新したいが、即時予約とカード処理は専用サービスへ任せたい」と考えるときの基準になります。ただし、外部サービスを使えば自動的にすべてのOTAが同期するわけではありません。予約エンジン、サイトコントローラー、PMS、決済の組み合わせごとに対応先と責任分担を確認します。
構成C｜サイト・予約・決済の一体型サービス
ページ制作、プラン登録、予約、決済を同じ管理画面で扱えるサービスを使います。画面や窓口を減らせる一方、独自ドメイン、ページ数、デザイン、外国語、料金プラン、データ出力、OTA接続、決済、解約時の移行に制限があり得ます。導入時の手軽さだけでなく、電話予約の入力、部屋タイプ別在庫、食事・子ども料金、キャンセル、返金、権限管理まで実際の業務で試してください。
| 判断項目 | 構成A | 構成B | 構成C |
|---|---|---|---|
| ページの自作 | する | する | サービス内で行う |
| 空室判定 | 人が正本を確認 | 予約エンジン | 一体型の予約機能 |
| 複数OTAとの同期 | 別途必要 | 対応サービスを接続 | 対応範囲を確認 |
| カード決済 | 決済リンク等を別途検討 | ホスト型決済へ移動 | サービスの対応方式を確認 |
| 主な弱点 | 返信・転記・売り違い | 接続設定と複数契約 | 機能制限と移行条件 |
| 選択の目安 | 少数の相談受付 | 複数経路を運用 | 対応機能が要件に合う |
コピー用テンプレ2: 3構成を選ぶ要件票
【民宿ホームページ・構成選択票】
販売する部屋タイプと室数:
現在の予約経路: 電話 / OTA名 / 紹介 / 自社 / その他
月の予約・問い合わせ件数:
予約担当者と対応できる曜日・時間:
即時予約: 必要 / 予約リクエストで可 / 未定
事前カード決済: 必要 / 不要 / 現地決済のみ
在庫の正本にするシステム:
接続が必要なOTA・予約エンジン・PMS:
電話予約を正本へ入れる担当と期限:
外国語・子ども料金・食事選択・連泊制御の必要:
選ぶ構成: A / B / C
選んだ理由と、専用サービスへ任せる範囲:
※そのままコピーして使えます
現在の受付方法と必要機能を一緒に整理したい場合は、使っているOTA、予約台帳、客室・食事の販売ルールを用意すると、制作範囲を切り分けやすくなります。
Google・OTA・公式サイト・予約システムの役割を分ける
公式サイトを作れば、OTAもGoogleも自動的に同じ空室を販売してくれるわけではありません。それぞれの役割を分け、予約データがどこへ戻るかを決めます。
| 仕組み | 主な役割 | 正本にしない情報 | 接続前に確認すること |
|---|---|---|---|
| Google検索・Googleマップ | 施設を見つけ、公式情報や予約先へ進む入口 | 自作ページだけではリアルタイム在庫にならない | 施設情報、リンク先、料金表示の接続方法 |
| OTA | 認知、比較、OTA上での販売・予約管理 | 他OTAや電話の在庫を必ず自動取得するとは限らない | 契約条件、在庫連携、変更・取消、メッセージ利用 |
| 公式サイト | 施設固有の情報、写真、条件、約款、公式予約への導線 | 予約機能がなければ部屋は確保しない | 更新担当、表示内容、予約先、計測 |
| 予約エンジン | 日付・人数・プラン選択、空室・料金確認、予約確定 | 未接続のOTA・電話予約 | 在庫の更新方向、確定通知、決済、返金 |
| サイトコントローラー | OTA・直販間の在庫、料金、予約データの連携 | 対応外チャネルや手入力前の電話予約 | 接続先、遅延・障害時の運用、料金・在庫の正本 |
| PMS | 予約・顧客情報、部屋割り、チェックイン、会計、館内業務 | 連携していない外部台帳 | 予約エンジン・サイトコントローラーとの対応 |
| 決済事業者 | カード情報の入力、本人認証、売上・返金処理 | 宿の空室や提供可否 | 3-Dセキュア、返金、PCI責任分担、管理権限 |
在庫の正本は一つに決める
在庫の正本とは、「この部屋をこの日に販売できるか」を最終判断する基準です。小規模な宿では紙台帳、予約エンジン、サイトコントローラー、PMSのどれかが候補になります。複数OTAと即時予約を行うなら、各画面へ同じ数字を人が別々に入力する設計ではなく、対応する連携を確認します。
電話予約や紹介予約は、自動連携の外から入ります。受話器を置いてから入力するのか、通話中に入力するのか、仮押さえの期限をどうするのかを決めます。「後で誰かが入力する」では、担当交代や繁忙時に抜けます。障害で同期が止まった場合は販売を止めるのか、安全在庫を減らすのか、連絡先と判断者まで決めてください。
コピー用テンプレ3: 在庫と予約データの流れ図
【在庫の正本】システム・台帳名:
最終的に残室を判断する担当:
予約経路ごとの入力先と反映期限
OTA 1: ［自動連携 / 手動］ 反映先: 遅延時:
OTA 2: ［自動連携 / 手動］ 反映先: 遅延時:
自社予約: ［自動連携 / 手動］ 反映先: 遅延時:
電話・紹介: 入力担当: 反映期限:
仮押さえ: 有効時間: 期限後の処理:
同期エラーの通知先:
障害時に販売を止める経路:
再開を判断する人:
毎日照合する数字: 到着 / 出発 / 部屋タイプ / 残室 / 未処理予約
※そのままコピーして使えます
Googleの無料予約リンクは予約ページとの接続が必要
Googleの無料予約リンクは、Google検索・Googleマップの宿泊料金表示から、宿の予約ページへ進む入口です。クリック自体にGoogleへの料金はかかりませんが、予約エンジンや接続パートナーの利用料が別に発生する場合があります。リンク順位は購入できず、設定後の表示や順位も保証されません。
Googleは宿泊料金の手入力機能を2025年7月30日で終了し、現在はCRS、インターネット予約エンジンなどの接続パートナーを使うよう案内しています。ビジネスプロフィールへ公式サイトURLを登録するだけで、空室と料金が自動表示されるわけではありません。料金、日付、人数、税・必須料金、返金条件は、Google側と予約ページ側で一致させます。無料予約リンクの遷移先には、SNSやOTAのページではなく、宿が直接予約を受けられる公式の予約ページが必要です。
OTA手数料、直販比率、OTA経由客への案内は契約条件を含む別テーマです。詳しい計算はOTA手数料と旅館・民宿の直販比率で確認してください。
最小構成は7ページ｜写真だけでなく予約条件を文章にする
民宿のサイトは、豪華な演出よりも「自分の条件で泊まれるか」を短時間で判断できることが先です。一枚だけのサイトでも公開できますが、更新担当と検索者が情報を見つけやすいよう、次の役割を持つページまたは明確な区画を用意します。
| ページ | 最低限書く内容 | よくある不足 |
|---|---|---|
| 1. トップ | 宿の特徴、所在地、主な客室、予約ボタン、重要なお知らせ | 誰に向く宿か、予約先が分からない |
| 2. 客室・設備 | 部屋タイプ、定員、寝具、風呂・トイレ、Wi-Fi、禁煙、段差 | 写真だけで設備名や共用範囲がない |
| 3. 料金・宿泊プラン | 税込総額の考え方、食事、子ども、追加料金、販売期間 | 「○円〜」の条件や必須料金がない |
| 4. 食事・館内案内 | 提供時間、場所、アレルギー相談の期限、持込・門限 | 要望すれば必ず対応できるように見える |
| 5. アクセス | 住所、地図、駐車条件、公共交通、最終区間、遅着連絡 | 地図だけで入口や夜間到着が分からない |
| 6. 予約・変更・取消 | 受付と確定、支払、変更、キャンセル料、返金、連絡先 | 条件が予約ボタンの後まで見えない |
| 7. 事業者・規約・個人情報 | 運営者、住所、電話、必要な取引表示、宿泊約款、プライバシー | 名称だけで問い合わせ先や利用目的がない |
客室写真には、撮影日、部屋タイプ、定員、設備の現在の状態を照合します。広角写真で実際より広く見える場合は面積や寝具構成を文章で示し、別タイプの客室写真を混ぜません。共用風呂、共用トイレ、階段、門限、送迎、ペット、食事は、予約判断に影響する条件です。提供できる場合だけ、対象、料金、期限、例外を書きます。
検索対策では、施設名、地域名、客室・食事・アクセス・条件を画像の中だけでなく本文にも書きます。Googleはモバイル版を主にクロール・インデックスへ使用し、レスポンシブデザインを推奨しています。Googlebotを遮断しない、HTTP 200で応答する、インデックス可能な本文があることは基本条件ですが、満たしても掲載や順位は保証されません。サイトマップ送信や構造化データも発見・理解を助ける手段であり、上位表示の確約ではありません。
コピー用テンプレ4: 最小ページの原稿台帳
【ページ名】
このページで答える質問:
対象の客室・プラン・期間:
確定済みの事実:
写真ファイル名・撮影日・部屋タイプ:
料金: 税込 / 税別 / 必須料金 / 変動条件:
予約前に伝える制限:
予約ボタンの遷移先:
情報の責任者:
公開前確認者:
最終確認日:
次回見直し日:
変更時に同時更新する場所: 公式サイト / 予約エンジン / OTA / Google / 館内案内
※そのままコピーして使えます
公開後に検索や予約が伸びない原因の切り分けは、ホームページから集客できない中小企業の原因診断へ分けています。まずは正確な施設情報と壊れていない予約導線を公開し、開始前の数字を残してください。
民宿ホームページを自作する7ステップ
ステップ1｜宿泊契約と販売ルールを一枚にする
最初に、客室タイプ、定員、販売単位、食事、子ども料金、税・必須料金、支払時期、チェックイン、キャンセル、返金を一覧にします。サイトの文章を書く前に予約担当、調理担当、会計担当で確認し、OTAと自社サイトで条件が異なる場合は経路ごとに分けます。
「夕食付き」と書きながら到着時刻によって提供できない、子ども料金が年齢ではなく寝具・食事で変わる、入湯税や宿泊税を現地で別に受け取るといった条件は、総額と受入可否に影響します。予約の最終画面まで隠さず、プラン説明と確認画面の両方で分かるようにします。
コピー用テンプレ5: 宿泊プランの正本
プラン名:
販売期間 / 宿泊対象日:
部屋タイプ / 販売室数 / 定員:
大人料金の計算方法:
子ども・乳幼児: 年齢 / 寝具 / 食事 / 料金:
含まれるもの: 宿泊 / 食事 / 体験 / 税・料金:
別途必要な税・必須料金:
食事時間・最終到着時刻:
予約締切 / 最少・最大泊数:
支払時期・方法:
変更・キャンセル・不泊の条件:
返金方法と目安: 決済事業者・カード会社により変わる旨を含む
在庫の正本 / 更新責任者 / 最終更新日:
掲載先: 公式 / 予約エンジン / OTA名:
※そのままコピーして使えます
ステップ2｜在庫の正本と接続可否を決める
次に、OTA、自社予約、電話の予約がどこへ集まるかを図にします。現在の予約管理が紙や表計算でも、予約リクエスト方式なら運用できます。ただし、即時予約を複数経路で受ける場合は、手作業での在庫更新が間に合うかを過去の受付時刻と件数で判断します。
予約エンジンを選ぶときは、サイトへ埋め込めるかより先に、利用中のOTA、サイトコントローラー、PMS、決済事業者と接続できるかを確認します。観光庁は2026年の調査でも、PMSなど宿泊施設システム間のデータ連携仕様が標準化されていないことを課題として示しています。名称が同じ「連携対応」でも、在庫だけか、料金・予約・顧客情報までかは確認が必要です。
ステップ3｜ドメイン・アカウント・権限を宿側で管理する
独自ドメイン、サイト、予約エンジン、Google、アクセス解析、決済の契約名義と管理者を一覧にします。制作を知人や外注先へ頼む場合も、宿の代表メールを所有者にし、作業者には必要な権限だけを付けます。退職・契約終了時の削除手順、復旧用連絡先、多要素認証、請求先も確認します。
無料サービスのサブドメインで試作しても、公開版の独自ドメインを誰が更新するかは別に決めます。ドメインの期限切れは、サイトだけでなくメールや予約リンクの停止につながる場合があります。個人の私用アカウント一つに全権限を集めず、宿の資産として引き継げる台帳にします。
ステップ4｜7ページの文章・写真・予約ボタンを作る
先に原稿台帳を埋め、確定していない情報は公開しません。トップページの予約ボタンは、日付と人数を選べる正しい予約ページへ送ります。予約リクエストならボタンを「空室を問い合わせる」とし、即時予約なら「空室と料金を確認する」など、次の画面で起きることと合わせます。
スマートフォンで、電話番号が押せるか、地図が開くか、重要条件が横スクロールで隠れないか、予約ボタンが画面を覆わないかを確認します。写真には短い代替テキストを付け、部屋名や設備を周辺本文でも説明します。キーワードを不自然に繰り返すのではなく、実際の宿泊判断に必要な固有情報を増やします。
ステップ5｜予約エンジンとホスト型決済を接続する
予約エンジンには、プランの正本から料金、在庫、定員、締切、食事、キャンセル条件を登録します。予約確認メールの送信元、返信先、迷惑メール時の案内、管理画面への反映、OTAとの同期をテストします。利用者が予約ページへ移動した後も、宿名、日程、人数、通貨、総額が突然変わらないようにします。
カード決済は、PCI DSS準拠状況を確認した決済事業者のホスト型ページや、対応する予約エンジン上で入力してもらいます。自作フォームにカード番号欄を作らず、メール、SMS、LINE、チャットで番号やセキュリティコードを送るよう案内しません。外部委託しても加盟店側の責任は残ります。契約時と契約後の定期確認で、対象サービスの準拠状況、加盟店との責任分担、管理画面の保護、変更通知の受け方を確認してください。
ステップ6｜表示・約款・個人情報・セキュリティを確認する
インターネットで宿泊予約の申込みを受ける場合は、実際の取引設計に応じて特定商取引法の通信販売規制を確認します。消費者庁の案内では、価格と追加負担、支払時期・方法、役務提供時期、撤回・解除、事業者名・住所・電話番号などに加え、申込みの期間を定める場合はその内容が主な表示事項です。申込みになる最終確認画面では、宿泊日、泊数、人数・室数、総額、支払条件、提供時期、キャンセル・解除条件を一覧で確認し、誤りを修正できる流れにします。「申込みの期間（定める場合のみ）」と、自館が設ける「予約受付締切（運用条件）」は分けて記録してください。
通信販売だから宿泊予約に一律8日間のクーリングオフがある、とは書けません。キャンセル料も全国一律の法定表ではありません。自館が採用する宿泊約款とプラン条件を整え、予約前と確定通知で示します。観光庁のモデル宿泊約款は検討用のひな型であり、自館の設備、受付、決済、自治体ルール、実際の運用へ合わせて確認してください。
旅館・ホテル営業や簡易宿所営業は原則として自治体の許可が必要です。一方、国の資料だけから「許可番号を全国すべての民宿が公式サイトへ必ず表示する」とは断定できません。所在地の条例、許可条件、保健所の案内を確認します。また、屋号としての「民宿」と住宅宿泊事業法上の民泊は同じ制度とは限らないため、自館の許認可区分を正確に書きます。
個人情報は、予約に必要な範囲へ絞り、利用目的、保管先、閲覧者、保存期間、削除、問い合わせ先を決めます。サイトをHTTPSにするだけで安全が完成するわけではありません。CMS・拡張機能の更新、強い固有パスワード、多要素認証、バックアップ、権限削除、脆弱性情報の確認、事故時の連絡手順を運用に入れます。
コピー用テンプレ6: 最終確認画面と確定通知の確認表
【予約直前に見せる内容】
宿名 / プラン / 部屋タイプ:
到着日 / 出発日 / 泊数:
大人・子ども・室数:
税込総額 / 現地で必須の追加負担:
支払時期・方法:
食事・チェックイン等の重要条件:
変更・キャンセル・不泊・返金条件:
申込みの期間（定める場合のみ）:
予約受付締切（運用条件）:
入力内容を戻って修正できる: はい / いいえ
ボタン文言が申込みだと分かる: はい / いいえ
【確定通知に入れる内容】
予約番号 / 確定日時 / 上記条件の再掲 / 宿の連絡先
カード情報そのものは記載・収集しない
※そのままコピーして使えます
コピー用テンプレ7: 個人情報と権限の管理台帳
取得項目: 氏名 / 連絡先 / 住所 / 宿泊者情報 / 要望 / その他
項目ごとの利用目的:
取得しない情報: カード番号 / セキュリティコード / 不要な本人確認情報
保存先と管理責任者:
閲覧できる役割:
外部委託先と取り扱う範囲:
保存期間・削除方法:
本人からの問い合わせ窓口:
管理者アカウント / 多要素認証 / 復旧先:
退職・委託終了時の権限削除期限:
バックアップと復元確認日:
事故を検知したときの連絡順:
※そのままコピーして使えます
ステップ7｜予約を端から端まで試して公開する
公開前テストは、ページが見えるかだけでは足りません。スマートフォンで検索・地図・公式サイトから入り、日付、人数、プランを選び、最終確認し、テスト予約を確定し、在庫が減り、宿側へ通知され、利用者へ確認メールが届き、変更・取消・返金まで進めるかを確認します。テスト予約は本番売上や実績へ混ぜず、終了後に在庫と決済を戻します。
満室、子ども同伴、連泊、販売締切後、カード認証失敗、メール未着、同時操作、キャンセル料発生日、同期停止も試します。すべての事故を防げるとは保証できませんが、通常経路だけを一度見るより、どこで人の判断へ切り替えるかが明確になります。
コピー用テンプレ8: 公開前の端から端テスト
テスト日時 / 端末 / ブラウザ / 担当者:
入口: Google検索 / Googleマップ / 公式URL / OTAからの確認
日付・人数・部屋・プランが正しい:
総額・税・必須料金が一致:
キャンセル・返金条件を申込前に確認できる:
ボタン後の状態: 問い合わせ / リクエスト / 即時確定
予約番号と確定メールが届く:
在庫の正本が1室減る:
接続OTAへ残室が反映する:
電話予約を手入力して各経路へ反映する:
変更 / 取消 / 返金を処理できる:
カード情報が自館フォーム・メール・ログへ残らない:
失敗した項目 / 暫定対応 / 修正担当 / 再試験日:
※そのままコピーして使えます
無料ツールでできる範囲と、見落としやすい費用
無料プランや既存アカウントを使えば、施設案内の試作、写真・文章の整理、問い合わせフォーム、アクセス解析の入口まで作れる場合があります。ただし「無料ホームページ」と「無料で直販予約の運用が完結する」は別です。独自ドメイン、広告非表示、ページ数、容量、フォーム件数、共同編集、バックアップ、データ出力、外国語、サポート、予約、在庫同期、決済はサービスごとに範囲が違います。
2026年9月11日時点の仕様確認では、固定の無料期間や料金をこの記事で保証しません。契約直前に公式料金ページと規約を保存し、税込・税別、月額・年額、予約ごとの費用、決済手数料、返金時の扱い、初期設定、最低契約期間、解約後のデータ出力を同じ表で比較してください。
| 費用区分 | 無料・低価格で試しやすい範囲 | 別途発生し得るもの | 確認する単位 |
|---|---|---|---|
| ページ制作 | テンプレートでの案内ページ試作 | 独自ドメイン、広告非表示、追加ページ、移行 | 月額・年額・更新時間 |
| ドメイン・メール | サービスの共用URL | 独自ドメイン、宿名メール、更新料 | 初年度・更新年 |
| 問い合わせ | 汎用フォーム | 通知、容量、自動返信、権限、保存期間 | 件数・利用者数 |
| 予約エンジン | 試用・限定プランがある場合 | 初期、月額、予約従量、オプション | 予約件数・売上・室数 |
| 在庫連携 | 手動台帳 | OTA接続、サイトコントローラー、PMS | 接続先・施設・月 |
| カード決済 | 初期費用なしの契約がある場合 | 決済、返金、チャージバック、端末等 | 決済額・件数 |
| 保守・安全 | 自分での更新 | 監視、バックアップ、復旧、専門作業 | 月額・作業時間 |
| 写真・文章 | 自館で制作 | 撮影、翻訳、校正、権利処理 | ページ・点数・言語 |
WordPressのソフトウェア自体はオープンソースですが、ドメイン、サーバー、テーマ・拡張機能、更新、バックアップ、安全管理は別に必要です。ページ作成サービスの無料枠を使う場合も、予約在庫や決済まで同じサービスに含まれるとは限りません。汎用フォームは質問の受付に使えても、在庫の確保、予約番号発行、OTA同期、カード処理を自動で行う予約エンジンの代わりにはなりません。
費用は現金だけでなく、自分の作業時間も含めます。月額0円でも、空室照合、返信、各OTAの残室変更、更新、バックアップに毎月10時間かかるなら、その時間を宿泊運営から移す判断になります。自作と外注を比べるときは、初期費用だけでなく3年間の支払額と担当時間、障害時の復旧範囲を同じ条件で見ます。
コピー用テンプレ9: 3年間の費用比較
【候補名・構成A/B/C】
初期費用:
ドメイン・サーバー・メールの3年分:
サイト機能の月額×36か月:
予約エンジンの固定費×36か月:
予約・決済の従量費: 想定売上と件数を明記
OTA・サイトコントローラー・PMSの追加費用:
撮影・原稿・翻訳・初期登録:
保守・バックアップ・復旧:
自館作業: 月＿＿時間×36か月×社内時間単価:
解約・移行・データ出力:
3年総額:
含まれない機能と追加条件:
料金・仕様の確認日と公式URL:
※そのままコピーして使えます
制作会社へ依頼する場合の費用項目や見積の比べ方は、和歌山のホームページ制作費用と見積書の読み方で詳しく整理しています。掲載金額をそのまま民宿の予算へ当てはめず、予約・在庫・決済・多言語・保守の要件を追加して見積もります。
自作か外注かは、ページ数より予約事故の影響で判断する
自作に向くのは、販売する部屋・プランが少ない、担当者が毎日更新できる、問い合わせ方式でよい、写真と原稿を自館で管理できる、カード情報を扱わない構成です。一方、複数OTAと即時予約を同時に動かす、料金が日別に変わる、子ども・食事・連泊条件が複雑、事前カード決済を行う、複数言語を更新する、障害時も販売を止められない場合は、予約システム提供会社や制作・保守の専門家を交えて設計する方が現実的です。
外注は全部を丸投げする意味ではありません。宿側は、客室在庫、料金、食事、受付、キャンセル、現場で提供できる内容の正本を持ちます。外注先には、サイト実装、接続設定、表示確認、セキュリティ更新、計測、引継ぎなど、専門作業の成果物と責任範囲を依頼します。予約数や検索順位だけを成果条件にせず、在庫反映、テスト合格、更新時間、障害時の復旧といった検収可能な項目を置きます。
段階的に始める方法もあります。第1段階で7ページと問い合わせを公開し、第2段階で予約エンジンを接続し、第3段階でOTA連携と事前決済を追加します。ただし、途中の問い合わせボタンを即時予約のように見せないこと、各段階で在庫の正本を変える場合は切替日時と未処理予約を照合することが条件です。
| 判断質問 | 自作を続けやすい | 専門支援を検討する合図 |
|---|---|---|
| 予約の成立 | 人が確認して返信できる | 24時間即時確定が必要 |
| 販売経路 | 少数で手動照合できる | 複数OTA・直販を同時販売 |
| 料金・プラン | 少数で変更が少ない | 日別料金、派生条件が多い |
| 決済 | 現地または外部リンク | 事前決済、取消、返金が多い |
| 更新 | 責任者が毎月時間を取れる | 担当不在、更新が止まる |
| 障害 | 一時的に受付停止できる | 停止の影響が大きい |
| 引継ぎ | 宿が全アカウントを所有 | 個人・外注先だけが権限を持つ |
コピー用テンプレ10: 外注の依頼・検収表
目的: 民宿の公式情報公開 / 問い合わせ / 予約リクエスト / 即時予約
自館が管理する正本: 客室 / 料金 / 食事 / 在庫 / 約款 / 顧客対応
依頼範囲: 設計 / 原稿 / 写真 / 実装 / 予約接続 / 決済 / 保守 / 計測
必要な接続先: OTA / 予約エンジン / サイトコントローラー / PMS / 決済
納品物: サイト / 原稿 / 画像原本 / 設定表 / 操作手順 / テスト記録
アカウント所有者: 自館名義。外注先の権限と終了時削除日を明記
検収条件: スマホ表示 / 総額一致 / 在庫反映 / 確定通知 / 変更取消 / 計測
安全確認: 更新 / バックアップ / 多要素認証 / 障害連絡 / 復元試験
保証しない事項: 検索順位 / 予約件数 / 売上 / 無事故
保守の対応時間・対象外・追加料金:
解約時のデータ、ドメイン、素材、設定の引渡し:
※そのままコピーして使えます
自館で作る範囲と、予約・在庫・決済を任せる範囲を具体化したうえで相談すると、制作ページ数だけの見積ではなく、運用開始後まで含む比較ができます。
公開後は月次KPIで「閲覧・受付・確定・宿泊」を分ける
ホームページの評価をアクセス数や予約数一つだけで決めると、どこを直すか分かりません。入口から宿泊実施まで段階を分けます。
| 段階 | KPI例 | 数え方の注意 |
|---|---|---|
| 発見 | 検索表示、自然検索クリック、Google経由クリック | 同じ人の複数回行動を人数と決めつけない |
| 閲覧 | 主要ページ閲覧、予約ボタンクリック | ボタン押下は予約ではない |
| 受付 | 問い合わせ、予約リクエスト、予約開始 | 同じ予約の複数連絡を一件にまとめる |
| 確定 | 確定予約、確定室泊、予約売上 | 未確定リクエストを含めない |
| 実施 | 実際の宿泊室泊、宿泊売上 | 未来の予約と分ける |
| 取消 | 取消件数、取消室泊、返金待ち | 客都合・宿都合・決済失敗を分ける |
| 採算 | 売上、変動費、決済・予約費、広告、作業時間 | OTAから直販への経路変更を新規需要と断定しない |
| 運用 | 返信時間、更新時間、同期エラー、二重予約 | エラー0を安全保証と表現しない |
直販比率は、自社経路の実施室泊を全経路の実施室泊で割るなど、自館で分母を決めます。問い合わせから確定への率は、対象月に受けた問い合わせを追跡し、同じ予約を電話・メールで重複計上しません。予約から宿泊まで月をまたぐため、「今月受けた確定予約」と「今月実施した宿泊」を別の列にします。
毎月の改善は一つに絞ります。閲覧が少ないなら検索結果・地図・既存顧客への案内、閲覧はあるが予約開始が少ないならページの条件とボタン、予約開始後の離脱が多いなら総額・入力・決済、リクエストから確定しないなら在庫・回答時間・条件を見ます。原因を推測だけで決めず、質問内容、エラー記録、予約台帳で確認してください。
月次記録には、対象月、販売可能室泊、休館・販売停止室泊、入口別クリック、主要ページ閲覧、予約ボタン、問い合わせ、予約リクエスト、予約開始、確定予約・室泊、実施予約・室泊、取消・返金、売上、決済・システム・広告費、自館作業時間、返信時間、同期エラーを並べます。最後に、確認できた事実と、来月直す箇所・担当・期限・判定指標を一つずつ残してください。数字が取れない項目はゼロにせず「未計測」とし、計測開始日を記録します。
よくある質問
Q. 民宿のホームページは本当に無料で自作できますか？
施設情報を載せた試作ページや問い合わせ窓口まで、無料枠で始められるサービスはあります。ただし独自ドメイン、広告非表示、予約エンジン、OTA在庫連携、カード決済、保守まで無料で続くとは限りません。公式料金表と利用規約を契約日に確認し、自館の作業時間も費用に含めてください。
Q. Googleフォームだけで宿泊予約を受けてもよいですか？
予約希望の受付には使えますが、フォーム送信だけで部屋が自動確保される仕組みではありません。予約未確定と明示し、在庫確認、確定通知、台帳反映の担当と期限を決めます。カード番号・セキュリティコードは汎用フォームで取得しないでください。
Q. 問い合わせ受付と予約確定の違いは何ですか？
問い合わせ受付は、質問や希望条件を受け取った状態です。予約確定は、宿が空室と条件を確認し、予約番号、宿泊日、人数、部屋、総額、支払、キャンセル条件を示して成立を通知した状態です。自館の約款と画面の流れに合わせ、成立時点を一貫させます。
Q. OTAと自社サイトの二重予約を防ぐにはどうしますか？
残室を最終判断する在庫の正本を一つ決め、対応する予約エンジン、サイトコントローラー、PMSとの接続範囲を確認します。電話・紹介など自動連携しない予約は、担当者が決めた期限内に正本へ入力します。同期障害時の販売停止や安全在庫のルールも必要です。
Q. Googleビジネスプロフィールへ料金を手入力できますか？
Googleは宿泊料金の手入力機能を2025年7月30日で終了しています。Google検索・マップに料金や空室を表示するには、対応するCRS、予約エンジンなどの接続パートナーを確認します。公式サイトのURL登録だけで料金表示や上位表示が保証されるわけではありません。
Q. カード番号をメールやLINEで受け取り、後から決済できますか？
その運用は採用しません。カード情報は、自作フォーム、メール、SMS、LINE、チャットで送らせず、PCI DSS準拠状況を確認した決済事業者のホスト型画面や予約エンジンで入力してもらいます。外部委託後も加盟店側の確認責任は残るため、契約時と定期的に対象サービスの準拠状況、契約先との責任分担、変更の有無を確認してください。
Q. 宿泊予約には8日間のクーリングオフがありますか？
宿泊サービスに一律の8日間キャンセル権があるとは説明できません。自館の宿泊約款と予約プランの変更・キャンセル・不泊・返金条件を整え、予約前の最終確認画面と確定通知に示します。モデル宿泊約款の違約金表も固定の法定料金ではありません。
Q. 民宿の営業許可番号はホームページに必ず載せますか？
今回確認した国の資料だけでは、すべての旅館・ホテル営業・簡易宿所営業に全国一律で許可番号のサイト表示を義務付ける規定までは確認できませんでした。不要とも決めつけず、所在地の条例、許可条件、保健所の案内を確認します。運営者名、住所、電話番号など、取引設計に応じた表示事項は別に確認が必要です。
Q. WordPressとホームページ作成サービスのどちらが民宿向きですか？
更新担当、必要ページ、予約エンジンとの接続、保守、データ移行で選びます。WordPressは拡張しやすい一方、サーバー、更新、安全管理が必要です。一体型サービスは管理をまとめやすい一方、機能や移行に制限があり得ます。予約・在庫・決済の要件を先に決め、実機テストで比較してください。
Q. 自作サイトを公開すれば、OTAをやめられますか？
公式サイトの公開と、OTAを停止しても同じ認知・予約を得られるかは別です。OTA、自社、電話の経路別に、確定ではなく実施済み室泊、売上、費用、取消、担当時間を測ります。契約条件を確認し、利用者が選べる公式予約の受け皿を整えてから判断してください。
公式一次情報と確認先
以下は2026年9月11日に確認した一次情報です。サービス仕様、料金、ガイドライン、法令、自治体運用は変更されるため、実装・契約・公開時に最新版を再確認してください。
- Google Hotel Center「宿泊料金の手入力終了」：2025年7月30日の手入力終了と、CRS・予約エンジン等の接続パートナー要件
- Google Hotel Center「無料予約リンク」：無料予約リンクの表示場所、クリック課金、予約ページへの遷移
- Google Hotel Center「予約ページのポリシー」：公式予約ページの遷移、日付・人数等の一貫性
- Google Hotel Center「価格の正確性ポリシー」：Google表示と予約ページの価格・空室の整合
- Google検索「SEOスターターガイド」：分かりやすい本文、タイトル、画像、検索の基本
- Google検索「技術要件」：Googlebot、HTTPステータス、インデックス可能な内容
- Google検索「モバイルファーストインデックス」：モバイル版を基にしたクロール・インデックスとレスポンシブデザインの案内
- 消費者庁「通信販売」：通信販売の規制、広告表示、申込み段階の考え方
- 消費者庁「通信販売広告の表示事項」：価格、支払、提供、解除、事業者情報等の表示
- 消費者庁「通信販売の申込み段階における表示ガイドライン」PDF：最終確認画面での分量、総額、支払、提供時期、解除条件等
- 観光庁「モデル宿泊約款」掲載ページ：宿泊契約成立、解除、違約金等を検討するひな型
- 観光庁「オンライン旅行取引の表示等に関するガイドライン」PDF：OTAを含むオンライン旅行取引の表示と契約主体の確認
- 厚生労働省「民泊サービスと旅館業法に関するQ&A」：旅館業の許可と住宅宿泊事業との制度区分
- 観光庁「宿泊施設のIT活用事例集」PDF：OTA、直販、サイトコントローラー、PMSの役割と連携例
- 観光庁「宿泊施設のデータ連携仕様標準化に向けた調査」：宿泊システム間の連携仕様に関する2026年の調査
- PCI SSC「決済を外部委託した加盟店の責任」：外部委託後も残るPCI DSS上の確認
- PCI SSC「メール・SMS・チャットでのカード番号送信」：保護されないチャネルでカード番号を受ける場合の要件
- 経済産業省「クレジットカード・セキュリティガイドライン6.0版」：EC加盟店の脆弱性対策、EMV 3-Dセキュア等
- WordPress.org「Requirements」：運用環境の公式要件
まとめ｜民宿サイトは「受付・在庫・決済」の境界から作る
民宿のホームページを自作するときは、最初に問い合わせ受付と予約確定を分けます。次に在庫の正本を一つ決め、OTA、自社予約、電話をそこへ戻します。カード情報は自作フォーム、メール、LINEで受け取らず、予約・決済事業者の画面へ渡します。この3点が決まれば、構成A・B・C、最小7ページ、必要な外注範囲を具体的に選べます。
今日やることは、現在の予約経路と在庫の正本を書くことです。今週は一つの宿泊プランについて料金・食事・支払・キャンセル条件をそろえ、7ページの原稿台帳を埋めます。今月はスマートフォンから変更・取消まで端から端で試し、公開前の数字を残してください。公開後は閲覧、受付、確定、実施、取消を分け、毎月一つだけ改善します。
