JetBookingとJetEngineで宿泊予約サイトを作る前に考えること

宿泊予約サイトをElementorで作ろうとすると、最初に迷いやすいのは「カレンダーを置くこと」ではありません。先に決めるべきなのは、部屋、料金、定員、設備、予約期間、予約後の確認を、WordPress内のどのデータとして持たせるかです。

静的なElementorページなら、部屋紹介を1ページずつきれいに作れば十分です。ただ、部屋数が増えたり、季節料金、空き状況、チェックイン日、チェックアウト日、予約者情報まで扱い始めると、手入力のページ運用ではすぐに苦しくなります。ここでJetEngineを使って部屋データを管理できる形に分けると、JetBookingの予約カレンダーとつなげやすくなります。

この記事では、10室前後の小さな宿泊施設を例に、JetEngineで「部屋データの箱」を作り、Elementorで部屋詳細を表示し、JetBookingで予約カレンダーと予約フォームを接続する前に考えることを整理します。いきなり大規模なホテル予約システムを作る話ではなく、まずWordPress制作の延長で現実的に設計するための下準備です。

JetBooking公式ページを見てみる

この記事で作る予約サイトの形

• 部屋ごとの詳細ページをJetEngineのデータから表示する
• 料金、定員、設備、写真、予約対象かどうかを入力項目として分ける
• Elementor側では部屋カードと部屋詳細テンプレートを作る
• JetBooking側では宿泊日、予約済み日、料金ルールを扱う
• 予約後の確認、通知、在庫調整を運用フローとして考える

まず何を作るのか

今回の例では、旅館や小規模ホテルの「部屋一覧」と「部屋詳細」から予約へ進む構成を作ります。サイト訪問者は部屋一覧で写真、定員、料金目安、設備を見て、部屋詳細でカレンダーを確認し、宿泊日を選んで予約フォームに進む流れです。

静的なElementorページだけでも、部屋A、部屋B、部屋Cの紹介ページは作れます。しかし、料金改定、設備変更、写真差し替え、予約停止などがあるたびに、複数ページを開いて手作業で直すことになります。特に「今は予約できる部屋だけ出したい」「2名向けの部屋だけ一覧に出したい」「朝食ありの部屋を絞り込みたい」となった瞬間に、見た目だけのページ制作では限界が出ます。

そこで、JetEngineでは部屋を1件ずつ登録するためのデータの箱（CPT）を用意します。名前は分かりやすく、たとえば次のようにします。

ここで大事なのは、予約システムを先に触り始めることではなく、予約対象になる部屋をデータとして安定させることです。部屋情報が曖昧なまま予約カレンダーを置いても、あとで料金、定員、オプション、休業日、複数室の扱いで詰まりやすくなります。

JetEngineで持たせる部屋データ

JetEngineでは、部屋CPTに入力項目（Custom Field）を追加していきます。初心者がやりがちな失敗は、部屋説明の本文に「料金は18,000円、定員2名、Wi-Fiあり、朝食あり」とまとめて書いてしまうことです。人間には読めますが、一覧表示、絞り込み、並び替え、予約対象判定には使いにくくなります。

今回なら、入力項目は次のように分けると扱いやすいです。

料金をNumberにしておくと、Elementor側で「18,000円〜」のように整形して出せます。定員もNumberにしておけば、2名向け、4名向けの一覧を分けやすくなります。設備はCheckboxやSelectにしておくと、タグのように並べたり、将来的に絞り込み検索を足したりできます。

予約対象かどうかを `booking_enabled` のような真偽値で持たせるのも実務では便利です。改装中の部屋、冬季だけ止める部屋、まだ写真準備中の部屋を、データ側で「表示する・しない」に分けられます。ただし、これだけで予約の重複防止ができるわけではありません。予約済み日や空室判定はJetBooking側の責任範囲として考えます。

Elementor側ではどう表示するのか

Elementor側では、まず部屋1件分の一覧テンプレート（Listing Item）を作ります。カードには部屋写真、部屋名、料金、定員、設備タグ、詳細リンクを置きます。これをListing Gridで並べると、部屋を追加するたびに一覧が自動で増える構成になります。

部屋詳細ページでは、JetThemeCoreなどでSingleテンプレートを作り、部屋CPTに対して表示条件を設定します。テンプレート内ではDynamic FieldやDynamic Imageを使い、JetEngineの入力項目をElementorの見た目に流し込みます。たとえば、料金は `room_base_price` を読み取り、前後に「1泊」「円〜」の文字を足します。設備は繰り返し表示やタグ風の見せ方にできます。

ここで考えるべきなのは、部屋詳細を作り込みすぎないことです。最初から凝ったアニメーションや複雑なタブを入れるより、部屋名、写真、料金、定員、設備、予約カレンダー、フォームの位置を先に安定させた方が運用しやすくなります。宿泊予約ページは見た目だけでなく、ユーザーが日付を選び、内容を確認し、必要な情報を入力する導線が大事です。

表示条件（Dynamic Visibility）も便利ですが、使いすぎると管理者自身がどこで何を隠しているのか分からなくなります。今回なら、`booking_enabled` がオンのときだけ「空室を見る」ボタンを出し、オフなら「現在受付停止中」と表示する程度から始めるのが安全です。

JetBookingで扱う予約カレンダーとフォーム

JetBookingは、宿泊やレンタルのように日付範囲で予約する用途に向いたCrocoblockプラグインです。公式ドキュメントでは、Elementor、ブロックエディター、Bricksでの利用が案内されており、予約フォームはJetFormBuilderやJetEngine Forms（レガシー）と組み合わせる説明があります。これから作るなら、申し込みフォームはJetFormBuilderを前提に考える方が自然です。

JetBooking側で意識するのは、部屋CPTを「予約対象」として選ぶこと、予約情報を保存する注文用のデータを用意すること、チェックイン・チェックアウト日をフォームで受け取ることです。小規模な例なら、次のような設計が考えられます。

予約カレンダーは、ユーザーが宿泊日を選ぶUIとして分かりやすい一方、実装では「予約済み日をどう扱うか」「最低泊数を設けるか」「週末料金や季節料金をどうするか」「同じ部屋を複数在庫として扱うか」を決める必要があります。公式ヘルプにも、季節料金、週末料金、複数ユニット、WooCommerce連携、Google Calendar同期などの項目がありますが、最初から全部を入れると設計が重くなります。

最初は、1部屋1予約、通常料金、シンプルな通知までに絞るのが分かりやすいです。支払いをWooCommerceに渡す、追加サービスを計算する、Google Calendarと同期する、といった話は、基本の予約導線が壊れずに動いてから検討した方が安全です。

管理画面での登録順を先に決める

予約サイトは、公開後よりも公開前の登録順でつまずくことがあります。おすすめは、最初に部屋データを1件だけ作り、次に部屋詳細テンプレートを作り、それから予約フォームとカレンダーをつなぐ順番です。部屋データが複数ある状態でフォーム設定を始めると、どの部屋IDをフォームが受け取っているのか分かりにくくなります。

たとえば、最初の検証用に「room_demo」という部屋を1件だけ作ります。料金は18000、定員は2、設備はWi-Fiと朝食、予約対象はオン。写真は仮で1枚だけでも構いません。この状態で、部屋詳細テンプレートに料金、定員、設備、予約カレンダー、予約フォームが正しく出るかを見ます。ここで表示が安定してから、本番用の部屋を増やします。

次に、予約テスト用のフォーム送信を行います。管理者通知が届くか、予約者向けの自動返信が届くか、予約済み日がカレンダー上で選べなくなるか、予約記録に部屋IDと日付が残るかを確認します。特に、宿泊日を日付範囲で受け取る場合は、チェックイン日とチェックアウト日の扱いを間違えると、1泊のつもりが2日分として保存されたり、最終日まで塞いでしまったりします。

この検証では、実在するお客様の情報を使わないでください。名前はテスト用、メールは自分で受け取れる確認用にします。電話番号や住所など、まだ必要性が決まっていない個人情報はフォームに入れない方が安全です。公開前の段階では、予約が作られることより、予約を取り消せることも確認します。誤予約が入ったときに管理者がどこで削除し、どこへ連絡し、どの履歴を残すのかを決めておくと、運用開始後に慌てにくくなります。

最後に、管理者以外の担当者が更新する場合を想定します。部屋情報だけを更新する人、予約一覧を見る人、フォーム設定まで触る人を分けたいなら、WordPressの権限や運用ルールを先に整理します。JetEngineやJetBookingの設定画面を誰でも触れる状態にすると、意図せずフィールド名や予約ルールが変わる可能性があります。初心者向けのサイトでも、公開後に触る範囲を小さくすることは大切です。

運用すると何が楽になるのか

JetEngineで部屋データを分けておくと、運用者はElementorのデザイン画面を毎回開かなくても、WordPress管理画面で部屋情報を更新できます。料金変更は `room_base_price`、設備変更は `room_facilities`、予約停止は `booking_enabled` を直すだけで済みます。

Elementor側のテンプレートは1つなので、カードの見た目を変えたいときも、部屋ごとのページを10枚直す必要がありません。これは小規模サイトでも地味に大きいです。予約サイトでは、写真差し替えや注意文の変更が何度も発生します。そこで情報は管理画面、見た目はElementorと役割を分けておくと、更新作業が落ち着きます。

予約後の運用も同じです。予約データがWordPress内に残る形にしておけば、管理者は予約一覧、通知メール、フォーム記録、必要ならWooCommerce注文を確認できます。ただし、ここで「全部WordPressに入れておけば安心」と考えるのは危険です。予約者名、メールアドレス、電話番号、宿泊日などは個人情報です。アクセス権限、バックアップ、不要になった情報の扱い、プライバシーポリシーの整備は別途きちんと考える必要があります。

標準設定に少し足す任意のPHP例

標準設定だけでも部屋詳細は作れます。もし、部屋ごとに短い注意書きを本文の決まった位置へ出したい場合は、JetEngineのTextフィールド `room_notice` を作り、ショートコードで表示する方法もあります。これは予約機能そのものを変えるものではなく、表示の補助です。

設置場所は、Code Snippetsプラグイン、または子テーマの `functions.php` です。ライブサイトではなく、必ずテスト環境で動作確認してから使ってください。

add_shortcode( 'room_booking_note', function () {
    if ( ! is_singular( 'room' ) ) {
        return '';
    }

    $note = get_post_meta( get_the_ID(), 'room_notice', true );

    if ( '' === trim( (string) $note ) ) {
        return '';
    }

    return '<div class="room-booking-note">' . esc_html( $note ) . '</div>';
} );

Elementor側では、部屋詳細テンプレートの任意の位置に `[room_booking_note]` を置きます。`esc_html()` で出力をエスケープしているため、入力した文字列をそのままHTMLとして実行しない作りです。逆に、管理者以外が入力する欄にHTMLやスクリプトを許可する設計は避けてください。

どこから複雑になりすぎるのか

宿泊予約は、見た目よりも業務ルールで複雑になります。たとえば、部屋タイプごとに複数在庫がある、連泊割引がある、繁忙期料金がある、キャンセル料が日数で変わる、現地決済とオンライン決済を分ける、外部予約サイトと在庫を同期する、といった要件です。

JetBookingには予約や料金に関する便利な機能がありますが、すべての業務ルールをプラグイン設定だけで無理なく表現できるとは限りません。特に決済、キャンセル、本人確認、外部サービス同期、会計処理まで絡む場合は、WordPress制作だけで抱え込まず、運用担当者、決済サービス、必要なら開発者と設計を分けて考えた方が安全です。

また、予約一覧や空き状況の表示は、データが増えると重くなることがあります。複雑な条件で大量の部屋や予約履歴を読み込む場合は、キャッシュ、検索条件、表示件数、サーバー性能も確認してください。JetEngineやCrocoblockは動的サイト制作を助けますが、パフォーマンス設計やセキュリティ設計を不要にするものではありません。

この構成が向いている人、向いていない人

この構成が向いているのは、Elementorでサイト制作ができ、部屋情報をWordPress管理画面で更新したい人です。小規模宿泊施設、レンタルスペース、貸別荘、日付範囲で予約するサービスなら、部屋データと予約カレンダーの関係を理解しやすいはずです。

一方で、大規模ホテルチェーン、複雑な在庫連携、外部OTAとの高度な同期、会員ランク別料金、細かいキャンセル規定をすべて自動化したい場合は、最初から専用予約システムや個別開発も比較対象に入れた方がいいです。WordPressで作る範囲を広げすぎると、更新しやすいサイトではなく、壊すのが怖い管理画面になってしまいます。

まとめ

JetBookingとJetEngineで宿泊予約サイトを考えるときは、まず予約カレンダーを置くのではなく、部屋データをどう持たせるかから始めるのが現実的です。部屋CPTに料金、定員、設備、写真、予約対象フラグを分けておけば、Elementor側では部屋カードと詳細ページをテンプレート化できます。

そのうえで、JetBookingの予約カレンダー、予約フォーム、予約記録、通知を接続します。最初はシンプルな予約導線から始め、季節料金、複数ユニット、WooCommerce決済、外部カレンダー同期は、運用が固まってから足す方が安全です。

静的なElementorページから一歩進めて、予約対象のデータと予約導線を分けて設計したいなら、JetBookingは検討しやすい選択肢です。まずは小さな部屋一覧と1つの予約フォームで、どこまで運用できるかを確認してみてください。

JetBooking公式ページを見てみる