古民家 宿 集客の改善実務｜魅力・不便・予約条件を伝える7ステップ【2026年】

結論：営業中の古民家宿が集客を改善する第一歩は、建物の古さを美しい言葉で飾ることではありません。梁や建具の魅力と、段差・音・寒暖・水回り・交通などの制約を実測し、写真・寸法・利用条件・更新日をそろえて、旅行者が「自分の滞在に合うか」を予約前に判断できる情報へ変えることです。

この記事の対象 - すでに営業している古民家宿、古民家民宿、古民家の一棟貸し - 予約ページはあるが、問い合わせで同じ確認を何度も受ける施設 - 写真の反応はあるのに、予約完了や宿泊後の満足へつながっているか分からない施設 - 日本語と外国語、公式サイトとOTAで条件がずれ、更新に不安がある施設

読了後に作れるもの 現況・制約証拠台帳、宿泊条件マトリクス、写真撮影票、交通手段別アクセス案内、媒体整合監査票、指標定義書、90日検証票の7点です。本文にはそのまま複製できる10本のテンプレートを掲載します。

「古民家ならではの風情」「非日常を味わえる」「日本の原風景に泊まる」。この表現だけでは、予約を検討する人が知りたいことは決まりません。写真で見えた階段は寝室へ行く唯一の経路なのか。浴室とトイレは専用か共用か。冬の寝室で使える暖房は何か。最寄りの停留所から荷物を持って歩ける道か。夜に到着しても入口を見つけられるか。こうした条件が分からなければ、魅力を感じた人ほど予約直前で確認のために止まります。

逆に、不便を全部小さく隠せば予約が増えるとも限りません。予約後に条件が判明すると、取消、到着時の混乱、現場の追加対応、期待とのずれにつながります。古民家の制約は、欠点一覧として並べるのではなく、どこに・どの程度あり・どんな滞在へ影響し・代わりに何を用意できるかまで示します。旅行者が条件を理解したうえで選べる状態が、本稿で扱う「集客改善」です。

本稿は開業、旅館業許可、建築改修費の解説ではありません。一般的なSNS運用、MEO、LINE、OTA手数料削減を一通り説明する記事でもありません。それらは既存記事へ分担し、ここでは営業中の一つの古民家宿について、同じ現況を予約判断に使える証拠へ変える実務に絞ります。古民家という名称だけを根拠に、人気、文化的価値、耐震性、断熱性、静けさ、予約増加を断定しません。

本文の公的資料と各サービスの仕様は2026年9月12日に確認しました。施設の安全性、バリアフリー対応、道路状況、交通、設備、キャンセル条件は施設ごとに異なり、更新も必要です。建築・消防・旅館業等の適合判断は記事で代替せず、所管行政、建築士等の専門家、契約中の予約サービスへ確認してください。

まず結論：古民家宿の集客を改善する7ステップ

七つの手順は、発信媒体を増やす順番ではなく、一つの事実を確認し、予約ページへ載せ、実際の宿泊まで検証する順番です。

最初の公開物は、新しい広告や動画でなくても構いません。たとえば「2階寝室へは階段のみ」「一段目から最上段までの写真」「手すりの位置」「1階で利用できる設備」「予約前に相談できる窓口」を一つの情報ブロックにするだけで、質問すべき条件が明確になります。バリアフリーを名乗れるかどうかを自己判断するのではなく、確認できる事実を示します。

観光庁の宿泊施設におけるバリアフリー情報発信のためのマニュアルも、設備の有無だけで終わらず、写真や寸法等を使って利用者が判断できる情報を発信する考え方を示しています。対象は段差だけではありません。古民家宿では、入口、廊下、寝室、浴室、トイレ、食事場所、駐車場所までの移動を一本の経路として確認すると、予約者の質問へ具体的に答えられます。

七つの手順は、開業直後の一回限りの制作ではありません。家具を動かした、寝具を替えた、送迎をやめた、停留所名が変わった、予約システムを移した、といった変更があれば、台帳の事実から関係媒体を更新します。この更新経路まで作って初めて、情報が資産になります。

集客の前に指標を固定する｜閲覧・予約・宿泊を同じ成果にしない

「古民家の写真が3万回見られた」「予約ボタンが100回押された」「問い合わせが20件来た」。どれも宿泊完了を意味しません。集客改善を判定する前に、表示から宿泊までの段階を分けます。

Google Search Consoleの検索パフォーマンス レポートでは、クリック、表示回数、CTR、平均掲載順位を確認できます。ただし、検索結果での表示と予約は別の出来事です。平均掲載順位だけを集客成果にせず、対象ページへ来た後の予約行動と宿の予約台帳をつなぎます。Search Consoleではプライバシー保護等によりすべての検索語が表へ出るわけではないため、表に見える検索語の合計を全需要と扱わないでください。

Google Analytics 4では、自宿にとって重要な操作をイベントとして実装し、キーイベントに設定できます。外部ドメインの予約エンジンへ移動する場合は、同じ利用者の経路を正しく扱うためのクロスドメイン測定が必要になることがあります。予約システムが計測タグやURLパラメータを受け付けるかは事業者ごとに違うため、設定後は実際のテスト予約で確認します。

改善前に固定する九つの指標

1. 販売可能室泊：対象期間に実際に販売できた部屋数×泊数。休館・工事・自家利用を理由つきで除く
2. 確定予約室泊：予約が確定した室泊。予約受付だけを含めない
3. 宿泊完了室泊：取消・不泊を除き、実際に提供した室泊
4. 取消室泊：確定後に取り消された室泊。予約件数と混ぜない
5. 条件確認問い合わせ：階段、寝具、入浴、食事、到着など、予約適合に関する質問を重複除外して数える
6. 情報不一致件数：公開情報と現況、または媒体間の食い違いが原因になった照会・変更・苦情
7. 追加対応時間：通常運用を超えて説明、移動補助、部屋変更等に使った実時間
8. 経路別宿泊売上：宿泊完了した予約を経路別に集計した金額。予約時の表示額と精算額を分ける
9. 追加限界利益：改善後に増えたと確認できる宿泊売上から、その宿泊に伴う販売費・決済費・清掃・リネン・食材等の変動費を引いた額

稼働率を使う場合は、分母を固定します。

自宿の稼働率 ＝ 宿泊完了室泊 ÷ 販売可能室泊 × 100

予約完了率 ＝ 同じ対象群の予約確定件数 ÷ 同じ対象群の予約開始件数 × 100

取消率 ＝ 対象宿泊期間に確定した予約の取消件数 ÷ 同じ対象宿泊期間に確定した予約件数 × 100

情報不一致率 ＝ 情報不一致が確認された宿泊または照会件数 ÷ 判定対象件数 × 100

※そのままコピーして使えます

予約件数、人数、室泊を式の中で混ぜないことが重要です。一棟貸し一件5人2泊を、予約件数では1件、人数では5人、室泊では2棟泊として扱います。どれを採用したか指標定義書に残します。

観光庁の宿泊旅行統計調査は全国や都道府県等の市場動向を確認する資料です。自宿の販売可能室泊、予約経路、古民家を選んだ理由、情報不一致は自宿の記録でしか分かりません。地域の延べ宿泊者数が増えたことを、自宿の施策成果へ置き換えないでください。

テンプレート1：指標定義書

【古民家宿・集客指標定義書】版：　集計開始日：　責任者：

対象施設／客室／販売経路：
対象宿泊期間：
比較期間と、曜日・休館・工事・料金の違い：

指標名：
何を1件と数えるか：
分子：　分母：
予約日基準／宿泊日基準／精算日基準：
除外条件：取消／不泊／テスト／社員利用／自家利用／重複：
取得元：Search Console／GA4／予約システム／OTA／電話台帳／現場記録
取得担当と頻度：
欠損時の表示：0にせず「未取得」

表示→訪問→予約開始→予約確定→宿泊完了→精算完了の件数：
条件確認問い合わせ：
情報不一致件数と内容：
追加対応時間：
判断日：　続行／修正／停止：　理由：

※そのままコピーして使えます

ゼロと未取得は分けます。予約画面から数字を取得できなかった週を0件とすると、改善が失敗したようにも成功したようにも見せられます。欠損理由と復旧日を残し、取得できた範囲だけで判断します。

ステップ1：古民家の現況を「魅力・制約・証拠」に分ける

古民家の紹介文を書く前に、現場を歩いて事実を集めます。担当者の記憶だけで台帳を埋めず、写真、実測、取扱説明書、契約書、行政や交通事業者の公開情報など、確認元をひも付けます。

現況調査は、予約者の動線で一周する

調査する順序は、建物の部屋番号順より、旅行者が到着してから退出するまでの順が分かりやすくなります。

1. 公道または停留所から敷地入口まで
2. 駐車・降車場所から玄関まで
3. 玄関の段差、鍵、照明、雨天時の動線
4. 玄関から居間、寝室、浴室、トイレ、食事場所まで
5. 夜間に使う照明、空調、連絡手段
6. ゴミ、喫煙、火気、調理、音に関する利用条件
7. 退出時の施錠、鍵返却、交通手段までの移動

各地点で「魅力」「制約」「宿泊条件」を分けます。たとえば土間は、素材や広がりが魅力である一方、寝室までに高低差があれば移動条件です。木製建具は意匠の魅力になり得ますが、遮音の状態は別に確認します。囲炉裏が写っていても、宿泊者が使える設備とは限りません。展示物、使用可能、スタッフ対応時のみ、使用禁止を分けます。

「ある・ない」だけでなく、単位と範囲を残す

「階段あり」だけでは判断材料が足りません。どの部屋へ行く階段か、ほかの経路はあるか、幅や段数、手すりの位置、途中の曲がり、夜の照明を記録します。「駐車場あり」も、台数、車両サイズの制約、入口の幅、敷地内で転回できるか、宿泊棟までの距離を分けます。

寸法は、測った場所と方法を残します。同じ玄関でも最も狭い有効幅と建具枠の幅は違います。写真には撮影方向を記載し、広角補正で実際より広く見える可能性がある場合は寸法を添えます。Wi-Fiは「高速」と形容せず、宿泊者が使う場所ごとの測定日時、使用回線、測定値、同時接続時の保証をしない旨を必要に応じて示します。

季節で変わる現況には有効期間を付けます。冬の暖房器具、梅雨期の湿気、山間部の虫、積雪や凍結、台風期の交通は、通年で同じではありません。経験談を「必ず発生する」「発生しない」と断定せず、確認できた時期、対策、旅行者が準備するもの、最新情報の確認先を記録します。

テンプレート2：現況・制約証拠台帳

【現況・制約証拠台帳】施設名：　版：　最終現地確認日：

管理ID：
場所：敷地入口／駐車／玄関／居間／寝室／浴室／トイレ／台所／庭／その他
確認する対象：

魅力として伝える確認済み事実：
制約として伝える確認済み事実：
宿泊への影響：移動／睡眠／入浴／食事／仕事／子ども／荷物／その他
利用条件・代替手段：

数値：　単位：　測定位置：　測定方法：
写真ファイル名：　撮影方向：　撮影日：
根拠資料名・URL・版：
確認者：　再確認期限：

掲載する媒体：公式／予約画面／OTA／Google／SNS／到着案内／館内案内
現在の掲載文：
差し替える掲載文：
不明点：推測で埋めず「要確認」
変更のきっかけ：設備交換／配置変更／季節／交通改正／規約変更／その他
変更責任者と期限：

※そのままコピーして使えます

台帳に「不明」を残すことは欠陥ではありません。分からないのに「問題なし」と公開することが問題です。予約前に個別確認が必要な条件は、問い合わせ窓口、返答期限、予約枠を保持するかどうかまで決めます。

ステップ2：宿泊条件マトリクスで「合う・要確認・合わない」を示す

現況台帳は施設側の資料です。そのまま公開すると情報量が多く、旅行者が自分に関係する条件を探せません。次に、旅行中の行動ごとに情報を束ね、適合、要確認、不適合を旅行者自身が判断できる宿泊条件マトリクスへ変えます。

ここでいう適合は、人を属性で選別することではありません。「1階だけで就寝・入浴・トイレを完結したい」「公共交通で日没後に到着したい」「オンライン会議を確実に行いたい」など、希望する滞在条件と、施設が実際に提供できる条件を照合することです。施設が判断できない健康・身体条件を推測したり、「高齢者には無理」「子どもなら安全」と一括したりしません。

マトリクスは設備名でなく、滞在中の目的から作る

表示文は、旅行者へ結論を押し付けるのではなく、条件を渡します。「階段が苦手な方はご遠慮ください」より、「2階寝室へは写真の階段16段のみ。片側手すりで、1階に寝室はありません。予約前の設備確認はこの窓口へ」と書くほうが、判断材料が具体的です。実際の段数や設備へ置き換え、例文をそのまま事実として使わないでください。

制約には「影響」と「代替」を隣接させる

不便の書き方が抽象的だと、必要以上に不安を与えます。「古い建物のためご不便があります」では、何が起こるか分かりません。次の四点を一組にします。

1. 現況：どこに何があるか
2. 影響：どの行動に関係するか
3. 代替または支援範囲：施設が実際に用意できるもの
4. 予約前の判断：確認方法と期限

書き換え前：古民家なので冬は寒い場合があります。

書き換え後の構造：
現況＝［客室名］は［暖房設備名］を設置しています。
影響＝廊下・洗面・トイレは客室と同じ空調範囲ではありません。
用意できるもの＝［確認済みの貸出品・利用可能設備］。
判断材料＝設備写真、部屋ごとの位置、確認日［年月日］。
予約前の窓口＝寒さや設備について確認したい場合は［窓口・回答時間］へ。

※そのままコピーして使えます

代替がない場合も、あるように見せません。「スタッフが補助します」と書くなら、対応できる時間、人員、行為、事前連絡の期限を決めます。善意の口約束を標準サービスにすると、別の担当者や繁忙日に提供できません。

テンプレート3：宿泊条件マトリクス

【宿泊条件マトリクス】客室・棟名：　対象期間：　更新日：

判断テーマ：移動／睡眠／入浴／食事／調理／子ども／仕事／交通／天候／その他
旅行者がしたいこと：
必要になる条件：

自宿の確認済み現況：
数値・単位・範囲：
写真・動画・図面へのリンク：
利用できる設備・対応：
利用できない設備・対応：

判定：
［ ］公開情報だけで判断できる
［ ］予約前に個別確認が必要
［ ］この客室・プランでは条件に合わない
［ ］別客室・別プランを案内できる

個別確認の質問：
回答担当：　回答可能時間：　予約枠の扱い：
公開文へ反映する内容：
次回の現況確認日：

※そのままコピーして使えます

テンプレート4：予約前セルフチェック

ご予約前に、次の条件をご確認ください。

□ 寝室の階と、寝室までの移動経路を写真・寸法で確認した
□ 浴室・トイレが専用か共用か、利用時間を確認した
□ 寝具の種類・数と、部屋の仕切り方を確認した
□ 冷暖房のある場所と、空調範囲外の場所を確認した
□ 調理・食事・食材対応の範囲を確認した
□ 駐車または最寄り交通から玄関までの経路を確認した
□ 夜間、雨天、季節によって変わる条件を確認した
□ 合計料金、支払時期、変更・取消条件を確認した

確認したい項目がある場合：［連絡方法］
通常の回答時間：［曜日・時間］
この連絡だけでは予約確定・部屋確保になりません／なる場合の条件：［事実］

※そのままコピーして使えます

セルフチェックを必須同意にするか、任意の案内にするかは予約システムと運用に合わせます。チェックを置いただけで説明責任や安全確認が完了するとは限りません。重要条件は予約完了前の画面にも本文で表示し、リンク先へ隠さないようにします。

ステップ3：予約ページを「雰囲気」から「証拠の束」へ変える

予約ページでは、魅力写真と条件説明を別世界にしません。梁、縁側、庭、かまど、ふすま、囲炉裏などを見せる写真の近くに、使える範囲、寝具、段差、火気、利用時間等を置きます。写真に写ることと、宿泊者が自由に使えることは同じではないからです。

最初の一画面で五つの判断材料を出す

スマートフォンで予約ページを開いた最初の範囲には、少なくとも次を置きます。

• 施設単位：一棟貸し、客室単位、共用部分の有無
• 定員と寝具：大人・子どもの扱いを含む実際の設定
• 主要な移動条件：寝室の階、階段、浴室・トイレの位置
• 合計料金へ進む入口：対象日、人数、税・追加料金の確認方法
• 重要な制約ページへのリンク：到着、音、火気、ペット、食事等

「最大8名」と大きく書いても、寝室2室、布団8組、食卓6席、浴室1か所という現況なら、8名での使い方を説明する必要があります。定員は許可やシステムの上限だけでなく、寝具配置、食事、入浴、荷物、駐車を含めた実運用と整合させます。本稿だけで定員を変更せず、必要に応じて許認可と運営条件を確認してください。

料金は「一棟○円〜」だけで止めません。対象日と人数を入力した後の合計額、別払い、現地払い、清掃・食事・税等の扱い、決済時期、返金条件へ到達できるようにします。観光庁の旅行予約サイト利用時の確認事項は、サイト運営者の情報、問い合わせ体制、契約当事者、支払代金と内訳、支払方法、キャンセル条件、利用規約等を確認項目として示しています。宿側も、旅行者がこれらを予約前に確認できる配置を点検します。

国民生活センターも、旅行予約サイトのチェックポイントで、同じ宿泊施設でもプランごとに取消可能期間や返金条件が異なる場合があること、予約内容を確認できる画面や確認メール等を保存することを案内しています。古民家宿側では、予約ボタンの直前と確定後の両方で、選ばれたプランの条件が同じかをテストします。

写真は「一番広く見える一枚」ではなく、経路を撮る

古民家宿の撮影では、美しい引き写真だけを並べると、部屋同士の関係が伝わりません。次の五種類を一組にします。

1. 全景：部屋全体と出入口の位置
2. 接続：玄関から居間、居間から寝室など前後の関係
3. 寸法：段差、最狭部、寝具間隔等を測る位置
4. 使用状態：寝具を敷いた状態、荷物を置いた状態、夜の照明
5. 制約：階段、低い梁、共用動線、屋外通路など判断に必要な箇所

写真は撮影日と現況の版に結びます。広角レンズを使う場合は、壁や家具が不自然に伸びていないか確認します。画像生成や強い修整で、ひび、段差、隣家、電線、設備、窓外の眺めを消した画像を現況写真として使いません。季節の庭や雪景色を載せる場合は、撮影時期と通年の保証ではないことが分かる説明を添えます。

テンプレート5：証拠写真の撮影票

【古民家宿・証拠写真撮影票】撮影日：　現況台帳の版：　確認者：

管理ID：　場所：　予約者が判断すること：
撮る向き：入口側→室内／室内→入口／左右／上から／夜間
一緒に写す基準：メジャー／寝具／荷物／人物を使わない寸法物
全景：　接続：　寸法位置：　使用状態：　制約：

写真で確認できる事実：
写真だけでは確認できない事実：
キャプションに書く数値・利用条件：
季節・時間帯：
加工内容：明るさ・色・切抜き等。現況を変える修整はしない
人・私物・住所・鍵・防犯設備・車両番号等の公開確認：

掲載先：公式／OTA名／Google／SNS／到着案内
元データ保存先：　ファイル名：
差替えのきっかけ：家具移動／工事／設備交換／季節／破損／その他

※そのままコピーして使えます

一つの主張を、写真・数値・条件で三点支持する

次の例は架空の施設を想定した編集例です。特定の古民家宿の実績ではありません。

抽象表現：昔ながらの階段も古民家の風情です。

予約判断に使える表現：
2階の寝室へは、この写真の階段だけを使います。
階段は［実測段数］段、最も狭い箇所は［実測値］cm、手すりは［左右・区間］です。
1階には［就寝可能／就寝不可］の［部屋名］があり、浴室・トイレは［位置］です。
昇降に不安がある場合は、予約前に［連絡先］へお問い合わせください。

※そのままコピーして使えます

抽象表現：自然に囲まれた静かな宿です。

予約判断に使える表現：
宿は［確認済みの周辺環境］にあります。
［季節・時間］には［農作業音／川音／虫や鳥の音／近隣交通等、確認済みの内容］があります。
客室はふすま・木製建具で仕切られ、ホテル同等の遮音を保証するものではありません。
夜間の屋外利用時間は［時刻］までです。

※そのままコピーして使えます

「静か」「快適」「広い」「すぐ」「歩ける」は、人によって基準が違います。形容詞を禁止する必要はありませんが、直後に測定値、位置関係、写真、時間、利用条件のいずれかを置きます。

予約ページの完成テンプレート

【古民家宿・予約判断ページ】情報更新日：

1．この宿の単位
一棟貸し／客室貸し：　共用する場所：　定員：　寝具：

2．この建物で残しているもの
梁・建具・庭等の確認済み現況：
宿泊者が利用できる範囲：　展示・利用禁止の範囲：

3．移動
駐車・降車→玄関→居間→寝室→浴室→トイレの順に、写真と寸法を掲載

4．睡眠・寒暖・音
部屋の仕切り：　冷暖房範囲：　季節差：　近隣・館内音：

5．入浴・トイレ
専用／共用：　利用時間：　位置：　段差・幅：

6．食事・調理
提供するもの：　持込：　調理設備：　個別対応できる範囲と要相談期限：

7．到着
車／公共交通／徒歩自転車の分岐：　夜間・雨天：　最新情報の確認先：

8．料金と契約
日付・人数別の合計額：　別料金：　支払時期：　契約当事者：
変更・取消条件：　問い合わせ体制：

9．予約前の確認
セルフチェック：　個別確認窓口：　通常回答時間：

10．予約
空室と合計金額を確認するボタン：

※そのままコピーして使えます

予約ページづくりの一般手順や小規模宿全体の集客施策は、民宿・ペンション・小さな宿の集客方法完全ガイドへ分担しています。本稿では、その前段にある「何を事実として掲載するか」を完成させます。

ステップ4：アクセスを車・公共交通・徒歩自転車に分岐する

古民家宿は、住所と地図のピンだけで到着条件を説明し切れない場合があります。集落内の細い道、同名の地名、建物から離れた駐車場所、停留所からの坂、街灯の少ない区間など、最後の移動を交通手段別に確かめます。すべての古民家宿に当てはまると決めず、自宿の経路を実走・実歩して記録してください。

車は「所要時間」より、分岐と車両条件を先に示す

車向け案内では、出発地からの最短時間を広告文にするより、最後に迷いやすい分岐を明確にします。

• 地図ピンは玄関、敷地入口、駐車場所のどこを指すか
• 最後に使う主要道路と、案内開始地点
• 入口の目印を、昼・夜・反対方向からどう見えるか
• 道路と敷地の最狭部、急な曲がり、勾配、未舗装区間
• 駐車可能台数と、車種・全長・全幅等の制約を確認する方法
• 敷地内で転回できるか、後退が必要か
• 通行を避けるべき私道・生活道路があるか
• 工事、通行止め、積雪・凍結等の最新確認先

所要時間は、出発時刻、渋滞、休憩、天候で変わります。「駅から20分」と固定する場合は交通手段と算出方法を示し、到着保証にしません。カーナビが狭い道を案内するなら、推奨経路の地図と「ナビの案内にかかわらず、この交差点から進む」という説明を用意します。宿泊者へ運転を指示する内容は、道路管理者・警察・現地の標識等に反しないよう確認します。

公共交通は、停留所から玄関までを商品情報に含める

最寄り駅や停留所の名前だけでは、予約者は到着可否を判断できません。次を一組にします。

• 利用する交通事業者と公式時刻表へのリンク
• 下車する駅・停留所の正式名称
• 停留所から宿までの実測距離と、実際に歩いた日
• 高低差、路面、階段、横断、歩道、街灯、屋根の有無
• 荷物を持った移動で確認すべき点
• 最終便を逃した場合に宿が提供できること・できないこと
• 送迎がある場合の対象、定員、予約期限、時間、荷物、変更条件

時刻表や停留所は変わり得ます。時刻そのものを各ページへ複製する場合は更新責任者と確認日を付け、交通事業者の公式ページも併記します。「送迎あり」とだけ書かず、毎日定時、前日までの予約制、特定便のみ、繁忙日は不可など、実際の運用範囲を示します。

JNTOの外国人旅行者向け公式ガイドHow to travel by train and bus in Japanも、地方部では運行本数が限られることがあり、より計画が必要だと案内しています。これは個別路線の運行証明ではありません。自宿ページでは、JNTOの一般案内だけに頼らず、利用する交通事業者の公式時刻表と、停留所から玄関までの現地確認を優先します。

徒歩・自転車は、距離に加えて路面・明るさ・保管を示す

徒歩旅行や自転車旅行を受け入れる場合、地図上の距離だけで「徒歩圏」「自転車歓迎」と断定しません。歩道の有無、未舗装、坂、トンネル、夜間照明、雨宿り、荷物、携帯電波、給水、自転車保管、充電、工具、洗濯等について、自宿で確認できた範囲を載せます。提供しない設備は、近隣で確実に利用できると確認できない限り補いません。

熊野古道沿線など歩く旅の条件設計と情報発信は、熊野古道のインバウンド集客｜沿線事業者の実務ガイドで詳しく扱っています。古民家宿側では、ルート全体を代わりに保証するのではなく、宿へ入る分岐、到着締切、食事、翌朝の出発、荷物等、自宿が担当する区間を明確にします。

天候・災害情報は、宿の予想で上書きしない

雨、台風、地震、津波、土砂災害、積雪等で経路や営業を変更する基準は、平時に決めます。気象庁の台風や大雨に関する最新の防災気象情報など、地域の公的情報、自治体、道路・交通事業者の公式情報を確認先にします。SNSの投稿だけで「道路は大丈夫」「予定どおり来られます」と断定しません。

観光庁の観光危機管理計画等作成の手引きは、減災、危機への備え、対応、復興の段階で、事業者が旅行者への情報提供や安全確保を準備する資料を公開しています。集客用アクセスページと緊急対応は目的が違いますが、連絡責任者、情報元、更新時刻を共通化すると、古い案内を残しにくくなります。

テンプレート6：アクセス分岐カード

【交通手段を選んでください】現地確認日：　情報更新日：

■車
地図ピンの場所：　推奨する最後の分岐：
入口の昼／夜写真：
最狭部・曲がり・勾配・路面：
駐車台数・車両条件・転回：
通行止め等の公式確認先：

■公共交通
事業者・路線・正式な下車場所：
公式時刻表URL：
下車場所→玄関の距離・高低差・路面・街灯：
送迎の有無と、対象便・期限・定員・料金：
最終便を逃した場合に提供できないこと：

■徒歩・自転車
推奨入口までの経路：
歩道・未舗装・坂・暗い区間：
荷物・自転車の保管、充電等の提供範囲：

■天候・災害・運休
確認する公的情報：
宿が営業・送迎・到着時刻を変更する判断者：
宿から連絡する経路：
旅行者からの連絡先と受付時間：
変更・取消条件へのリンク：

※そのままコピーして使えます

ステップ5：同じ現況を日本語・外国語・写真へ翻訳する

古民家宿のインバウンド対応は、日本文化を説明する文章を増やすだけでは完成しません。畳、布団、障子、縁側、土間、かまど等の名称と同時に、旅行者がそこで何をできるか、どんな扱いが必要か、どの設備がないかを伝えます。

先に一つの日本語「事実原稿」を作る

翻訳元は、公開中の日本語ページをその都度コピーするのではなく、現況台帳から作った一つの事実原稿にします。各行へ管理IDを付ければ、設備が変わったときに日本語・英語・OTAを追跡できます。

管理ID：BED-02
確認済み日本語：2階寝室に布団を4組敷きます。ベッドはありません。
補足する現況：寝室へは階段のみ。1階に就寝室なし。
数値：布団4組／階段［実測段数］段
禁止・注意：布団を1階へ移動するサービスは提供していません。
写真：BED-02-a、STAIR-01-a
確認日：［年月日］
翻訳版：英語v3／その他言語v1
媒体：公式、OTA-A、OTA-B、到着案内

※そのままコピーして使えます

「futon」「tatami」をローマ字へ置き換えるだけでは、ベッドの有無、床に寝ること、寝具の数、履物の扱いは伝わりません。名称、実際の使い方、予約判断に必要な条件を短文で分けます。文化の説明と、契約・設備条件を一文に詰め込まないほうが、数字や否定語の確認が容易です。

翻訳で最優先するのは、数字・否定・期限・主体

翻訳確認では、表現の美しさより先に次を突き合わせます。

• 人数、寝具数、段数、幅、距離、時刻、金額、税、泊数
• 「できる」「できない」「要相談」「予約制」の違い
• 宿が提供するもの、外部事業者が提供するもの、旅行者が用意するもの
• 問い合わせ期限、チェックイン締切、食事申込期限、取消期限
• 専用・共用、屋内・屋外、1階・2階、敷地内・敷地外
• 予約受付と予約確定、無料と現地有料、返金可と返金不可

機械翻訳や生成AIは下書きに使えますが、入力していない送迎、アレルギー対応、返金、荷物配送、スタッフ常駐を補うことがあります。原稿にないサービスが増えていないかを、人が行単位で確認します。個人の予約情報、健康情報、決済情報を外部サービスへ入力する場合は、自社の利用ルールとサービスの取扱いを確認します。

観光庁の2023年11月〜2024年2月の訪日外国人旅行者の受入環境整備に関する調査は、空港で4,012件を調査し、旅行中に困ったこととして「施設等のスタッフとのコミュニケーション」を22.5％が挙げたと公表しています。この結果は自宿の外国語問い合わせ率ではありません。自宿では、どの言語の、どの条件の質問があり、回答後に予約・宿泊へ進んだかを別に記録します。

同調査では「ごみ箱の少なさ」も30.1％でした。古民家一棟貸しでゴミ分別や退出時の扱いを案内する際は、この全国調査を自宿の苦情件数へ置き換えず、自宿の保管場所、分別、回収、屋外へ放置しない理由、質問窓口を写真付きで説明します。

テンプレート7：事実を増やさない翻訳依頼票

あなたは宿泊施設の情報を翻訳する担当者です。
次の「確認済み事実」だけを使い、［対象言語］の予約案内を作成してください。

【確認済み事実】
管理IDつき日本語原稿：［貼付］
写真ID：［貼付］
用語集：［宿名、地名、部屋名、交通名、畳・布団等の表記］

【厳守】
1．送迎、設備、返金、食事、支援、営業時間を追加しない
2．不明点を推測せず、原文の管理IDつきで「要確認」にする
3．数字、単位、否定、期限、専用・共用、階を太字で検算一覧にする
4．予約受付と予約確定を区別する
5．文化語は名称だけでなく、利用者が行うことを平易に説明する
6．翻訳文の後に、日本語へ戻した確認文を管理IDごとに出す

出力：翻訳文／数字・条件の照合表／要確認事項／逆翻訳確認文

※そのままコピーして使えます

外国語ページも同じ予約画面へ接続する

外国語の紹介ページを作っても、予約画面で言語、通貨、合計料金、変更条件が理解できなければ、完了までの経路は切れます。外部予約システムへ遷移するときは、選択した日付・人数・プランが引き継がれるか、言語が戻らないか、スマートフォンで実操作します。

Googleのバケーションレンタル掲載は、価格、空室、予約リンク等を含む仕組みですが、すべての施設が自動で掲載されるわけではありません。Googleのバケーションレンタル掲載の概要と接続事業者の要件を確認し、掲載や順位を保証する表現は避けます。無料予約リンクの公式説明では、ランディングページ体験や価格の正確性等が表示順位を決めるシグナルに含まれると案内されています。予約システムを使っている場合は、接続可否と価格・在庫更新の責任分界を事業者へ確認します。

古民家宿の外国語ページを作る前後の地域連携や問い合わせ対応は、熊野古道のインバウンド集客実務と重なる部分があります。本稿の成果物は、翻訳対象になる自宿の事実原稿です。

ステップ6：公式・OTA・Google・SNSの条件を同じ版へそろえる

媒体ごとに文章の長さや役割は違います。全文を同じにする必要はありません。しかし、定員、寝具、階、浴室、料金、食事、到着、送迎、変更・取消、連絡先といった予約判断の事実は一致させます。

正本は「一番詳しいページ」ではなく、証拠台帳にする

公式サイトを正本にしても、更新担当が直接文章を書き換えると、変更理由と証拠が消えます。現況・制約証拠台帳を正本にし、そこから媒体別の短文を作ります。

GoogleビジネスプロフィールやSNSは、予約条件の全文を保存する台帳ではありません。投稿で設備変更を告知したら、現況台帳、公式ページ、該当するOTA、予約後案内を同じ変更票で直します。投稿が流れた後も、常設情報が最新である状態を保ちます。

SNSの一般的な企画・投稿頻度・事例設計は旅館のSNS集客事例の読み方と設計へ分担します。古民家宿では、SNSを雰囲気の入口として使う場合も、予約判断の詳細は検証可能なページへつなぎ、SNSだけで条件を完結させない運用が安全です。

重大項目は画面を見ながら照合する

管理画面へ入力したことと、旅行者の画面へ反映したことは別です。ログアウト状態、スマートフォン、言語切替、人数変更、複数日程で表示を確認します。

監査する予約例A：大人2人・1泊・車1台
監査する予約例B：大人4人・子ども2人・2泊・食事あり
監査する予約例C：外国語表示・公共交通・到着締切付近

確認項目：
□ 同じ客室・棟・プランを見ている
□ 定員と寝具数が一致する
□ 合計料金と内訳へ到達できる
□ 食事・清掃・税・追加料金の扱いが一致する
□ 寝室の階、浴室・トイレ、共用範囲が一致する
□ 到着締切、送迎、連絡先が一致する
□ 変更・取消条件と契約相手を確認できる
□ 予約完了後の確認メールに同じ条件が残る

※そのままコピーして使えます

直予約とOTAの役割、費用、精算を比較する場合はOTA手数料一覧と実質負担の計算式、南紀の宿で直予約の受入条件を作る場合は南紀の宿が直予約を増やす方法を参照してください。本稿では経路をどれか一つへ誘導する前に、どの経路でも現況と契約条件が食い違わない状態を作ります。

テンプレート8：媒体整合監査票

【媒体整合監査票】監査日：　正本の版：　監査者：

事実ID：
項目：定員／寝具／階／浴室／トイレ／食事／料金／到着／送迎／取消／連絡
正本の確認済み事実：
根拠写真・寸法・資料：

公式サイト：掲載URL／表示文／更新日／一致・不一致・未掲載
予約画面：URL／表示文／更新日／一致・不一致・未掲載
OTA-A：URL／表示文／更新日／一致・不一致・未掲載
OTA-B：URL／表示文／更新日／一致・不一致・未掲載
Google：URL／表示文／更新日／一致・不一致・未掲載
SNS固定情報：URL／表示文／更新日／一致・不一致・未掲載
予約後案内：版／表示文／更新日／一致・不一致・未掲載

重大度：予約停止／当日までに修正／次回更新
修正担当：　修正期限：
管理画面で保存した日時：
旅行者画面で反映を確認した日時：
未反映時の代替案内：

※そのままコピーして使えます

不一致を見つけたら、最も新しそうな文章へ自動統一しません。どの現況が正しいかを証拠台帳で再確認します。料金や取消条件は予約日、宿泊日、プランによって異なるため、「旧条件の予約へ新条件を上書きするか」も契約・運用に沿って判断します。

ステップ7：表示から宿泊完了までを90日で検証する

90日検証の目的は、三か月で必ず予約を増やすことではありません。情報を変えた前後で、どの旅行者行動が変わり、予約・取消・宿泊・現場負荷へどうつながったかを、次の判断に使える形で残すことです。宿泊日の予約リードタイムが長い施設では、90日内に宿泊が完了しない予約を未完了として追跡します。

観光庁の宿泊業の高付加価値化のための経営ガイドラインは、宿泊事業者の取組を経営状況、人事・労務環境、IT活用状況の分野で整理しています。本稿の90日票は登録申請やガイドライン適合を判定するものではありませんが、予約数だけでなく、収支、担当者の負荷、計測・予約システムを同時に見る理由を確認できます。

0日目：比較できる基準値を凍結する

公開前に、直近の同条件期間から基準値を作ります。三か月前と比べるだけでは、曜日、連休、料金、販売停止、工事、天候が違うかもしれません。次を注記します。

• 対象宿泊日と、予約を観察した日
• 曜日、連休、催し、季節
• 販売可能室泊と、停止した理由
• 客室・プラン・料金・最低泊数
• 予約経路と、各経路の在庫設定
• 改修、家具配置、食事、送迎、スタッフ体制の変更
• 比較期間で異なる条件と、比較できない項目

すでに計測がなければ、過去を推測で埋めません。予約台帳と問い合わせ履歴から確認できる範囲だけを基準にし、検索表示やページ行動は0日目から新たに測ります。

1〜14日：一棟・一客室・一つの重要条件に絞る

最初から全ページを改稿すると、どの変更が効いたか分かりません。問い合わせが多い、当日対応が多い、写真と現況がずれている、といった証拠から一つの対象を選びます。

例として、2階寝室への階段質問が多い場合は、次を一つの変更単位にします。

1. 現況台帳で階段、寝室、1階設備を再確認
2. 全景・接続・寸法・夜間の写真を撮る
3. 宿泊条件マトリクスで「公開だけで判断」「要確認」を決める
4. 公式ページと主要OTAの同じ位置へ反映
5. 問い合わせ分類に「階段・寝室」を追加

この例は施策設計であり、予約改善の実績ではありません。自宿の問い合わせや不一致が別の項目に集中しているなら、浴室、食事、駐車、夜間到着などを優先します。

15〜30日：公開状態と計測を実機で確認する

公開後は、制作担当の画面だけで合格にしません。スマートフォンで、検索結果、公式ページ、予約画面、確認メールまで進みます。テスト予約は本番在庫や決済へ影響しない方法を予約システム事業者へ確認し、テスト用データを実予約から除外できる印を付けます。

確認する順序は次の通りです。

検索表示
→ 対象の古民家宿ページ
→ 条件説明と証拠写真
→ 日付・人数の入力
→ 合計料金・変更条件
→ 予約確定直前または安全なテスト環境
→ 確認画面・確認メール
→ 台帳と計測画面

※そのままコピーして使えます

外部予約ドメインへ移る場合、GA4の参照元やセッションが意図どおりつながるかを確認します。クロスドメイン設定は保存しただけで終えず、Googleの手順に沿ってリンク先URLのパラメータ、ページ表示、計測をテストします。予約エンジン側で対応できない場合は、少なくとも遷移クリックと予約システムの予約番号を別々に記録し、完全に追跡できない範囲を明記します。

31〜60日：問い合わせの減少だけで成功と決めない

条件を詳しく書くと、同じ質問が減ることがあります。しかし、ページ訪問そのものが減った場合も問い合わせは減ります。次を一緒に見ます。

• 対象ページの検索表示とクリック
• 対象ページの閲覧と予約画面遷移
• 条件確認問い合わせの件数と分類
• 問い合わせ後の予約確定・未確定・理由不明
• 予約確定した室泊と宿泊予定日
• 取消と変更、その理由を確認できた範囲

「階段についての質問が10件から3件へ減った」という結果だけでは、説明が十分になったのか、候補者がページを見なくなったのか、条件を見て問い合わせ前に別の宿を選んだのかは分かりません。予約確定、情報不一致、現場負荷まで見て、目的に合った変化かを判断します。

旅行者が条件を見て予約しないことも、無意味とは限りません。自宿では提供できない条件が予約前に伝わり、当日の重大な食い違いを防げた可能性があります。ただし、その可能性を成果として数値化するには、理由が確認できる記録が必要です。推測で「ミスマッチを防止できた件数」を作りません。

61〜90日：予約を宿泊・精算・現場負荷まで閉じる

予約確定は途中経過です。宿泊完了後、次を予約番号単位で閉じます。

• 宿泊完了、取消、不泊、日程変更
• 宿泊者が見た予約経路と、予約前に確認した主な条件
• 現況との食い違いがあったか
• 追加説明、部屋変更、送迎等に要した時間
• 宿泊売上、販売・決済費、追加の変動費、返金
• 公開情報へ反映すべき質問・指摘

個人の健康状態や家族事情を不要に記録しません。改善に必要な条件を「階段情報が不足」「寝具数を誤認」「送迎期限が不明」のように匿名化し、予約番号と必要最小限の関係だけを持たせます。

続行・修正・停止の基準を先に決める

判定条件は公開前に置きます。都合のよい指標へ後から変えないためです。

サンプルが数件しかない場合、割合の上下は一件で大きく変わります。割合だけで結論を出さず、分子と分母の実数も並べます。季節や曜日が違う比較は、因果関係を断定せず「次に確認する仮説」として残します。

テンプレート9：90日検証票

【古民家宿・90日検証票】施策ID：　責任者：

改善する一項目：
根拠：問い合わせ／不一致／現場負荷／検索語／その他
対象ページ・客室・プラン・販売経路：
変更前の証拠と画面保存：
変更内容：文章／写真／寸法／条件／予約画面／計測

基準期間：　施策期間：
曜日・季節・料金・販売可能室泊の差：
比較できない項目：

0日目：表示／訪問／予約開始／確定予約／取消／宿泊完了／精算／不一致／追加対応
14日目：現況台帳と証拠が完成したか
30日目：全媒体へ反映し、実機計測を確認したか
60日目：質問分類、予約確定、未確定理由
90日目：宿泊完了、取消、売上、変動費、追加対応時間

未完了予約：予約番号／宿泊予定日／再確認日
欠損データ：　欠損理由：
判定：続行／一項目修正／停止／継続観察
判断根拠：
次に変更する一項目：

※そのままコピーして使えます

広告、SNS、MEO、価格変更を同じ90日に一斉実施すると、この情報改善だけの影響を分けにくくなります。必要な施策を止めるのではなく、施策ID、開始日、対象、費用を別行で残します。SNS運用を試す場合は、投稿表示だけでなく予約台帳までつなぐ設計を旅館のSNS集客実務で確認できます。

現況を更新し続ける｜担当・期限・反映確認を一つにする

集客情報は、公開時点で正しくても劣化します。古民家宿では、建具や設備の修繕、家具の配置、季節設備、庭や進入路、公共交通、食事提供、人員体制などが変わります。更新作業を「気づいた人がSNSで告知」に任せず、変更票を起点にします。

更新を開始する十二のきっかけ

1. 工事、修繕、破損、設備交換
2. 寝具・家具の数や配置変更
3. 客室、共用範囲、利用時間の変更
4. 定員、子ども、ペット等の受入条件変更
5. 食事、調理、アレルギー確認範囲の変更
6. 駐車、進入路、周辺工事、通行条件の変更
7. 路線、停留所、時刻表、送迎の変更
8. チェックイン、夜間連絡、スタッフ体制の変更
9. 料金、税、追加費用、決済、取消条件の変更
10. 予約システム、ドメイン、計測タグの変更
11. 季節設備、災害対応、営業停止・再開
12. 宿泊者から現況との不一致を指摘されたとき

変更を受け付けたら、まず予約済みの旅行者への影響を確認します。公開ページの更新だけでは、変更前の条件で予約した人に届きません。対象宿泊日、対象予約、連絡内容、到達確認、同意や取消の扱いを、契約条件と事実に沿って記録します。

LINEで再来訪案内を行う場合の同意、配信、予約台帳の設計は旅館のLINE公式アカウント活用へ分担します。設備変更や緊急案内は販促配信と同じ目的ではないため、予約者への必要連絡、希望者への案内、一般公開を分けて運用します。

テンプレート10：現況変更・全媒体更新票

【現況変更・全媒体更新票】変更ID：　受付日時：　受付者：

変わった現況：
変更前：　変更後：
変更日・有効期間：
根拠：現地写真／工事記録／取扱説明／交通事業者／規約／その他
安全・契約・料金・予約在庫への影響：

影響する事実ID：
影響する宿泊日：
予約済み対象：あり／なし／調査中
予約者への連絡文・手段・期限：
送信・到達・返信・変更・取消を別に記録：

現況証拠台帳：担当／期限／完了時刻
日本語事実原稿：担当／期限／完了時刻
翻訳：担当／期限／確認者／完了時刻
公式サイト：担当／保存時刻／公開画面確認時刻
予約画面：担当／保存時刻／公開画面確認時刻
OTA：媒体別の担当／反映確認時刻
Google：担当／反映確認時刻
SNS固定情報：担当／反映確認時刻
到着・館内案内：担当／差替確認時刻

反映待ちの媒体と代替案内：
旧画像・旧PDF・検索キャッシュ等の確認：
最終確認者：　完了条件：旅行者画面で全重大項目を再確認

※そのままコピーして使えます

毎月30分の監査会議で見る画面を固定する

会議では報告資料を新しく作るより、次の実画面を同じ順で開きます。

1. 現況・制約証拠台帳の期限超過
2. 公式予約ページのスマートフォン表示
3. 主要OTAの旅行者向け画面
4. Google上の住所、連絡先、営業時間、予約リンク
5. 予約確認メールと到着案内
6. 条件確認問い合わせと情報不一致一覧
7. 未宿泊の確定予約と、宿泊後に閉じていない記録

担当者の説明で済ませず、旅行者が見る画面と現地の両方を確認します。媒体側の審査・反映待ちで直せない場合は、状態を「未反映」とし、公式ページや予約者への直接案内で補える範囲を決めます。反映していないのに完了扱いにはしません。

よくある質問

Q. 古民家らしい不便まで書くと、予約が減りませんか？

条件に合わない人が予約前に見送る可能性はあります。一方、曖昧なまま予約を受けると、取消や当日の追加対応、期待とのずれが生じる可能性もあります。公開前後で、閲覧、問い合わせ、予約確定、取消、宿泊完了、情報不一致、追加対応時間を同時に見てください。「問い合わせが減った」だけで良否を決めず、自宿に合う予約と運営負荷まで確認します。

Q. 古民家宿の魅力は、どのように言葉にすればよいですか？

「風情」「非日常」だけで終えず、残している部材、場所、宿泊者が体験できる行動、利用できる時間を具体化します。たとえば「縁側があります」から、「居間に接する南向きの縁側を、7時から21時まで座って利用できます。雨天時は建具を閉めます」のように、現況と条件を添えます。方角や時間は例なので、自宿の事実へ置き換えてください。

Q. 写真はプロへ頼まないと集客できませんか？

プロ撮影が必要かは、目的、予算、自社の技術で判断します。予約適合の証拠写真は、華やかさより、入口、接続、寸法、寝具を敷いた状態、夜間等が正確に分かることが重要です。撮影を外注する場合も、証拠台帳と撮影票を渡し、美観写真だけで終わらないよう成果物、使用権、元データ、差替条件を確認します。

Q. 段差や階段の寸法は、どこまで載せればよいですか？

旅行者が経路を判断するために必要な箇所を優先します。玄関だけ測っても、寝室や浴室までに別の狭い箇所があれば判断できません。最狭部、段差、手すり、別経路、写真の撮影方向を一組にします。バリアフリー適合の法的・専門的判断を自己宣言するためではなく、現況情報として提示します。測定箇所と方法も残してください。

Q. 「子連れ歓迎」「高齢者歓迎」と書けば対象が明確になりますか？

歓迎という意思だけでは、階段、柵、寝具、浴室、暖房器具、夜間対応等の条件は分かりません。年齢や家族構成から適合を決めつけず、設備と提供範囲を示します。利用者が個別確認を希望する場合の窓口と回答時間も載せます。医療・介助等を提供しない場合は、できるように読める表現を避けます。

Q. 古民家宿のインバウンド集客は、まず英語ページを作ればよいですか？

先に日本語の確認済み事実原稿を作り、数字、否定、期限、専用・共用、階、料金、取消条件を固定します。その後に翻訳し、予約画面、確認メール、到着案内まで同じ言語経路をテストします。英語の紹介だけがあり、予約途中で日本語へ戻る状態は、予約完了の検証が必要です。必要な言語は自宿の検索・問い合わせ・予約実績で決めます。

Q. 公式サイトとOTAは、文章を完全に同じにすべきですか？

媒体の文字数や画面構造が違うため、全文一致は不要です。ただし、定員、寝具、階、浴室・トイレ、料金、食事、到着、送迎、取消、連絡先などの重大事実は一致させます。省略した場合も、予約完了前に詳細へ到達できるか確認します。正本は一媒体の文章ではなく、根拠付きの現況台帳です。

Q. GoogleやSNSの閲覧数が伸びれば、集客成功ですか？

閲覧は入口の指標です。予約画面遷移、問い合わせ、予約確定、取消、宿泊完了、精算まで別に記録します。検索表示や動画再生を宿泊数へ換算しません。Googleや各SNSの数字と予約番号を直接結べない場合は、取得できる範囲を明記し、予約時の経路質問も参考として使います。自己申告経路は記憶違いがあり得るため、計測値と同一視しません。

Q. 90日で予約が増えなければ、情報改善は失敗ですか？

予約リードタイム、販売可能室泊、季節、曜日、料金、他施策によって判断は変わります。90日内に宿泊日が来ない確定予約は、宿泊完了へ繰り上げません。表示は増えたが予約開始がない、予約はあるが取消が多い、情報不一致は減ったが新規需要がない、というように段階を分けて次の一項目を決めます。件数が少ない場合は観察期間を延ばします。

Q. 予約を増やすため、古民家の歴史や築年数は強く打ち出すべきですか？

建築年代、由来、文化財等の表現は、根拠資料と権利者・関係者の確認がある範囲で使います。「築100年」と伝承だけで断定したり、地域を代表する建築、文化財、著名人ゆかり等を裏付けなく付けたりしません。確認できない場合は「所有者から聞いているが資料未確認」のように公開の可否を検討し、予約条件とは分けます。歴史の長さが安全性や快適性を保証するものでもありません。

Q. 直予約へ誘導すれば、古民家宿の利益は増えますか？

手数料だけでは判断できません。予約システム、決済、広告、問い合わせ対応、取消・返金、在庫同期、特典、社内工数を含めます。既存のOTA予約が直予約へ移った場合と、新しい宿泊が増えた場合も分けます。実施済み宿泊の売上から経路別費用と追加変動費を引き、同じサービス条件で比較してください。

Q. Tipへ相談すると、何から始まりますか？

まず、営業中の施設について、公開ページ、予約経路、現況写真、繰り返し受ける質問、媒体間の不一致を確認し、どの一項目を90日で検証するか整理します。支援範囲や成果を先に断定せず、施設側が確認できる事実、更新できる体制、計測できる範囲に合わせて相談内容を決めます。

まとめ｜古民家宿の集客は、選べる情報を増やすところから始める

古民家宿の魅力は、抽象的な形容詞を増やすより、現況の証拠と一緒に示すほど、予約者が具体的な滞在を想像できます。段差、音、寒暖、水回り、交通などの制約も、隠すか強調するかの二択ではありません。場所、程度、影響、代替、確認方法をそろえれば、旅行者が自分の希望と照合できます。

着手順は次の通りです。

1. 一番質問が多い客室・条件を一つ選ぶ
2. 予約者の動線で現況を測り、写真・寸法・確認日を台帳へ入れる
3. 宿泊条件マトリクスで、公開だけで判断できることと要確認を分ける
4. 公式ページ、予約画面、OTAへ同じ事実を反映する
5. 車・公共交通・徒歩自転車の最後の移動を分ける
6. 日本語事実原稿から翻訳し、数字・否定・期限を検算する
7. 90日間、表示、予約、取消、宿泊、精算、現場負荷を追う

本日できる最小の作業は、予約者から直近で繰り返し聞かれた質問を一つ選び、その答えに必要な現地写真と数値を取り直すことです。いきなり全ページを作り直さず、一つの証拠ブロックを完成させ、旅行者画面と実際の宿泊まで確かめます。

株式会社Tipでは、古民家宿・一棟貸し・小さな宿の公開情報、予約導線、SNS等を、施設の現況と運営体制に合わせて整理する相談を受けています。「予約を増やせる」と先に約束する相談ではなく、現在のページと質問履歴を見ながら、確認できる事実、優先する一項目、90日の測定方法を決めます。

参照した一次資料・公式仕様

• 観光庁「宿泊旅行統計調査」（全国・都道府県等の宿泊動向と用語、2026年9月12日確認）
• 観光庁「宿泊施設におけるバリアフリー情報発信のためのマニュアル」（写真・寸法等を用いた施設情報の伝え方、2026年9月12日確認）
• 観光庁「旅行予約サイト利用時の確認事項」（事業者、問い合わせ、契約、支払、取消等の確認事項、2026年9月12日確認）
• 国民生活センター「便利な旅行予約サイトでトラブルに！？チェックポイント」（プラン別の取消・返金条件と予約記録の確認、2026年9月12日確認）
• 観光庁「訪日外国人旅行者の受入環境に関する調査」（令和5年度調査、回答4,012件、2026年9月12日確認）
• JNTO「How to travel by train and bus in Japan」（地方部を含む鉄道・バス利用の公式案内、2026年9月12日確認）
• 観光庁「災害時の対応力強化に関する取組」（観光危機管理の手引き・ワークシート、2026年9月12日確認）
• 気象庁「台風や大雨に関する最新の防災気象情報」（公的な気象・防災情報への入口、2026年9月12日確認）
• 観光庁「宿泊業の高付加価値化のための経営ガイドライン」（経営状況、人事・労務環境、IT活用状況の取組分野、2026年9月12日確認）
• Google Search Console「検索パフォーマンス レポート」（クリック、表示回数、CTR、掲載順位等の定義、2026年9月12日確認）
• Google Analytics「イベントをキーイベントとしてマークする」（重要行動の計測設定、2026年9月12日確認）
• Google Analytics「クロスドメイン測定を設定する」（異なるドメイン間の利用者行動の測定、2026年9月12日確認）
• Google Hotel Center「Googleのバケーションレンタルについて」（掲載情報と予約リンクの概要、2026年9月12日確認）
• Google Hotel Center「無料予約リンクについて」（表示順位のシグナルと料金・ランディングページの正確性、2026年9月12日確認）