ホテル・旅館の直販での再宿泊を増やすLINE公式アカウントとLINEミニアプリの活用方法
こんにちは。リテールアプリ共創部@大阪のmorimorikochanです。
宿泊事業者様との商談では、「OTA(宿泊予約サイト)の手数料負担が大きい」「2回目以降の予約もOTA経由になってしまう」「メルマガやDMを送ってもなかなか反応が得られない」といったお悩みをよく耳にします。
国内の宿泊予約におけるOTA経由の比率は約半分と言われており、一度泊まっていただいたお客様がリピート時にもOTAを利用されると、その都度手数料が発生し続けることになります。
前回の記事ホテル・旅館滞在中の顧客体験を向上させるLINE公式アカウントとLINEミニアプリの活用方法では、チェックインからチェックアウトまでの滞在中の接点について検証しました。
今回はその続編として、OTAの手数料負担を下げることを目的として、チェックアウト後のお客様との接点をLINE公式アカウント(Messaging API)とLINEミニアプリで構築し、2回目以降の宿泊を直販(公式サイトや自社予約システム経由)へ誘導する検証・整理してみましたのでご紹介します。
なお、本記事は前回と同様に、滞在中にお客様がLINE公式アカウントを友だち追加し、自社会員アカウントとLINEユーザーIDの紐付けが完了していることを前提としています。
OTA経由で宿泊されたお客様であっても、滞在中にこの紐付けさえ完了していれば、チェックアウト後は同様の仕組みに乗せることが可能です。
検証した顧客体験
チェックアウト直後のお礼メッセージ、アンケート、領収書ダウンロード
チェックアウト直後は、お客様の滞在の記憶が最も鮮明なタイミングです。
単にお礼メッセージを送るだけではもったいないため、1通のメッセージの中に「満足度アンケート」と「領収書発行」の導線をまとめた体験を設計してみました。
チェックアウトが完了すると、お客様のLINEにお礼のメッセージ(画像やボタンを組み合わせたカード型のFlexメッセージ)が届きます。
用意したアクションボタンは「アンケートに答える」と「領収書を表示」の2つです。
「アンケートに答える」をタップするとLINEミニアプリのアンケート画面が開き、3問ほどの設問に回答すると、お礼メッセージとともにGoogleマップ等の口コミ投稿へのリンクが表示されます。
なお、アンケートの評価が低かった場合には、口コミ導線の手前にお詫びのメッセージを添える構成にしています。
以下のデモ動画では、お礼メッセージの受信からアンケート回答、口コミ導線の表示までの一連の流れを確認できます。

デモ動画
| 1.お礼メッセージと アンケート届く |
2.1タップで アンケート回答 |
3.ミニアプリで 詳細アンケート回答 |
4.GoogleMapの口コミ にも誘導可能 |
|---|---|---|---|
![]() |
![]() |
![]() |
![]() |
また、"領収書を表示"をタップすると、今回の宿泊分の領収書がLINEミニアプリ上で表示されます。
出張利用のお客様にとっては、後日フロントへ電話して領収書の再発行を依頼する手間が省けるため、実用的なメリットを感じていただける機能だと考えています。
| 1.「領収書を表示」をタップ | 2.LINEミニアプリ 領収書が表示される |
3.PDFのダウンロードも可能 | 4.過去の履歴も残る |
|---|---|---|---|
![]() |
![]() |
![]() |
![]() |
仕組み
お礼メッセージは、PMS(宿泊管理システム)からのチェックアウトイベントをトリガーに、Messaging APIのプッシュメッセージで送信しています。
前回の記事の「どうやって滞在中と判定するか」で紹介した構成図において、3番目で呼び出すAPIをプッシュメッセージに差し替えたシンプルな構成です。
アンケートの回答データは、回答日時とともにLINEユーザーIDと紐付けてデータベースに保存します。
ここで得られたデータは、後述するセグメント配信(満足度の高かったお客様に限定したプラン案内など)の抽出条件として活用できます。
領収書機能は、PMSの精算データをもとにPDFを生成してAmazon S3へ保存し、ミニアプリから該当ユーザーの宿泊分のみを表示させる構成としました。
すでに会員アカウントとLINEユーザーIDが紐付いているため、ミニアプリを開いた時点で適切な領収書を特定して表示できます。
ただし、領収書には適格請求書(インボイス)としての記載要件が定められているため、PMS側に標準のWeb領収書発行機能がある場合は、そちらと連携して表示する方が安全です。
また、GoogleMapへの口コミ導線の設計には注意が必要です。
Googleのポリシーでは、事業者が「否定的なクチコミを抑制する、または肯定的なクチコミを選択的に募集する」行為や、特典と引き換えにクチコミを促す行為が明確に禁止されています。
そのため、口コミ導線自体は評価の高低にかかわらず全員へ均一に表示し、低評価だったお客様に対してはお詫びの文面を添える形にとどめています。
GoogleMap以外の他社口コミサイトにも同様のガイドラインが存在するため、外部の口コミ導線を設ける際は事前のポリシー確認が必要です。
物販ECサイトへの誘導
滞在中に利用したアメニティや食事メニューが気に入り、「自宅用にも購入したい」と感じた経験をお持ちの方も多いのではないでしょうか。
チェックアウト後もLINE公式アカウントをブロックされずに維持していただくためには、単なる割引クーポンよりも「日常的に利用する動機」があることが望ましいと考え、物販ECサイトへの導線を用意しました。
前回の記事では、チェックアウト後にリッチメニュー(トーク画面下部に固定表示されるメニュー)を「館内モード」から「通常モード」へ切り替える運用を紹介しました。今回はその通常モードのリッチメニューの1枠に「物販ストア」を配置し、既存のECサイトへ遷移できるようにしています。
さらに、お礼メッセージの送信から数日後に、「滞在中にお召し上がりいただいた料理はこちら」といった形で、宿泊履歴(利用プランやディナーのコース)に合わせたおすすめ商品の案内メッセージを配信する導線も構築しました。

チェックアウト数日後に届く商品案内メッセージから購入する流れ
| 1.ECサイトに リッチメニュー/メッセージから アクセス |
2.ECサイトでショッピング |
|---|---|
![]() |
![]() |
仕組み
ECサイトへの導線は、既存サイトへの外部リンクを設定するだけで対応可能です。
URLに計測用のパラメータ(UTMパラメータなど)を付与しておけば、LINE経由のアクセス数や売上への貢献度を正確に測定できます。
また、宿泊履歴に応じて商品の案内を出し分ける処理には、次に解説するオーディエンス抽出の仕組みをそのまま流用しています。
再宿泊の動機に合わせたプラン案内
次回の宿泊を検討する動機やタイミングは、お客様ごとに異なります。
記念日で宿泊されたご夫婦であれば翌年の記念日前、夏休みに利用されたファミリー層なら翌年の夏休みの計画時期、ビジネス出張であれば次回の出張予定に合わせてアプローチするのが自然です。
予約をOTAで探し始める前のタイミングで、それぞれのニーズに合わせた「直販限定プラン」を提案できれば、自社予約への誘導につながると考え、今回は次の3つの配信シナリオを設計しました。
- 記念日利用のご夫婦:翌年の記念日の1か月前に、記念日向け特別プランを案内
- 夏休み利用のご家族:翌年の夏休み予約が開始される時期に、ファミリー向けプランを案内
- 出張利用のビジネス客:チェックアウトから一定期間予約がない場合に、平日限定のビジネスプランを案内
以下の図は、チェックアウトから各案内を送信するまでのタイムラインを比較したものです。

案内までのインターバルはそれぞれ異なりますが、後述のとおり配信のロジック自体は共通であり、抽出条件と送信タイミングのパラメータを切り替えているだけです。
プラン案内はFlexメッセージ形式で配信され、タップするとLINEミニアプリ内のプラン詳細画面が立ち上がり、そのまま予約フローへと進めます。
以下の画像では、属性の異なる3名のお客様それぞれにパーソナライズされたプランが届いてることがわかると思います。
| 記念日利用のご夫婦向け | 夏休み利用のご家族向け | 出張利用のビジネス客向け |
|---|---|---|
![]() |
![]() |
![]() |
仕組み
配信対象の抽出は、「宿泊履歴」「アンケート回答」「ミニアプリ上で取得した興味・関心」の3つの要素をもとに、自前のデータベースからLINEユーザーIDのリストを生成しています。
このリストをMessaging APIのオーディエンス(配信先ユーザーIDのグループ)として登録し、ナローキャスト配信(オーディエンスや属性を指定した絞り込み配信)で送信するアーキテクチャを採用しました。
配信タイミングの制御は、「前回の宿泊日から○日前」「チェックアウトから○日後」といった条件で日次判定を行うステップ配信の形式をとり、該当したユーザー群をオーディエンス化して配信を実行します。
前回の記事では、滞在中の少人数を対象にしたマルチキャスト配信(複数ユーザーへの一括送信)を用いましたが、今回は特定の条件を満たすセグメントへ定期的にアプローチするため、グループを保持・管理できるナローキャスト配信のほうが運用に適していると判断しました。
Messaging API経由で登録したオーディエンスは「LINE Official Account Manager」の管理画面上にも反映されるため、現場のスタッフが使い慣れたWeb画面から手動で配信を行うことも可能です。
ただし、オーディエンスの仕様に関して留意すべき点はいくつかあります。
まず、オーディエンスは作成後すぐには利用できません。作成直後は"準備中"ステータスとなり、配信可能になるまでに最低でも5分程度のラグが発生します。
準備中のオーディエンスを指定して送信APIをコールするとエラーが返るため、配信処理の直前に作成するのではなく、前日などのバッチ処理であらかじめオーディエンスを生成しておく設計が安全です。
また、ナローキャスト配信は非同期で実行されるため、送信完了の確認には進行状況取得APIを用いる必要があります。今回の検証時は受付からおよそ30秒で送信が完了しました。
また、公式ドキュメントには「配信対象が一定数未満の場合、ナローキャスト配信を実行できない場合がある」旨の記述がありますが、ユーザーIDを直接指定するタイプのオーディエンスでは制約は除外されているため、結果的に少人数への配信になっていたとしても問題ありませんでした。
また、実運用に向けては以下の2点を事前に設計しておく必要があります。
- 直販限定のインセンティブを設定する必要があります。アーリーチェックインやウェルカムドリンクの提供、直販限定価格など、自社経由で予約する明確なメリットを用意すること。OTAと同等の条件では、ポイント付与や決済の利便性からOTAへ流れてしまうため、自社サイトへ戻っていただく動機づけが不可欠です。
- 配信頻度に上限を設ける必要があります。チェックアウト後は、お礼、EC案内、次回プランの案内とメッセージ数が重なりがちです。配信が過度になるとブロックにつながるため、「月に1〜2通まで」といった上限を設定することをお勧めします。
なお、直販限定インセンティブの設計や配信頻度のルール策定は、システム開発というよりも運用設計の領域です。
筆者の所属するリテールアプリ共創部では、配信シナリオの設計や案内文面の検討も含めたご相談を承っています(クラスメソッドのLINE活用支援)。
リッチメニューからの直感的な次回予約
パーソナライズされたプラン案内が届いたとしても、その場でスムーズに予約を完結できなければ離脱を招いてしまいます。
また、プッシュ通知が届いていないタイミングでも、お客様がLINEを開いた際にいつでも手軽に予約できる導線を用意しておくべきです。そこで、通常モードのリッチメニューから数ステップで次回予約を完了できる導線も検証しました。
リッチメニューの「次回のご予約」をタップするとLINEミニアプリが起動し、希望の日程と人数を選択するだけで利用可能な会員限定プランが表示されます。
プランを選択して予約を確定すると、トーク画面へ自動的に予約完了通知が届きます。
すでに会員情報とLINEアカウントが紐付いているため、氏名や電話番号といった基本情報は入力済みの状態となり、ユーザーが操作するのは実質的に「日程と人数の選択」のみで済みます。
OTAが支持される大きな要因である「決済情報が保存されている」「入力の手間が少ない」という強みに対し、同等以上の手軽さを提供できるアプローチだと考えています。
以下のデモ動画では、リッチメニューから予約完了までの操作フローをご確認いただけます。

リッチメニュー → 日程と人数を選択 → プランを選択 → 予約完了 → 予約確認のメッセージ
| 1.リッチメニューからタップ | 2.会員情報の入力は不要 | 3.予約確認メッセージ届く |
|---|---|---|
![]() |
![]() |
![]() |
仕組み
空室状況・料金のリアルタイム取得、および予約確定のトランザクションは、直販用の予約エンジン(またはPMS)が提供するAPIを呼び出すアーキテクチャを想定しています(今回の検証ではダミーの予約エンジンを用意して検証しました)。
予約データにはLINE経由であることを示す識別コードを付与し、直販予約全体の中でLINEがどの程度寄与しているかを後から追跡・分析できるようにしています。
※利用中の予約エンジンにAPIが備わっていない場合の代替案は、セクション"直販予約システムとの連携パターン" をご参照ください。
予約完了時の確認メッセージには、LINEミニアプリの「サービスメッセージ」(ミニアプリ上のユーザー操作に対する応答として、無償で自動配信できる通知機能)を利用することも可能です。仕様や制約については前回の記事で触れていますので、併せてご参照ください。
再宿泊を促す対象者をどのように抽出するか
ここまで紹介した施策は、いずれも"システムがチェックアウトを検知できること"と"宿泊実績や顧客属性がLINEユーザーIDと紐付いた形でDBに格納されていること"の2点を前提として成立しています。
前回の記事で解説した"会員IDとLINEユーザーIDの対応テーブル"および"チェックイン検知の仕組み"を、チェックアウト後のフェーズへ拡張した設計です。
例として、チェックアウトからプラン案内が配信されるまでのデータフローを下図に整理しました。

- チェックアウト完了時に、PMSから連携サーバーへ宿泊履歴・精算データ・会員IDを送信します(PMSにAPIが存在しない場合は、日次バッチによるCSV取り込みでも運用可能)。
- 連携サーバーは宿泊履歴をデータベースへ蓄積します。アンケートの回答結果やミニアプリ内で収集した興味関心データも同一のデータベースに集約されます。
- 「最終宿泊日から○日経過」「ファミリー利用」「満足度スコア4以上」などの条件をもとにLINEユーザーIDを抽出し、Messaging API経由でオーディエンスとして登録します。
- Messaging APIのナローキャスト配信を用いて、登録したオーディエンスへパーソナライズメッセージを送信します。
- ユーザーがミニアプリ上で予約手続きを完了すると、予約エンジンのAPIを通じて予約データが確定します。
オーディエンス作成の管理画面
ユーザー抽出のたびにエンジニアがSQLを記述するのは現実的ではないため、現場のマーケティング担当者が画面上で条件を組み合わせて配信リストを作成できる管理画面をデモとして構築しました。
以下はオーディエンス作成画面のサンプルです。
「前回の宿泊から90日以上経過」「ファミリー利用」「宿泊満足度4以上」といった複数の条件をAND/ORで組み合わせ、名前を付けて保存できます。条件を変更すると、該当する対象ユーザー数がリアルタイムに画面上へ算出・表示されます。

条件を組み合わせることで対象人数をリアルタイムに把握可能
設定可能な条件のうち、宿泊回数、累計決済額、過去の予約経路、会員ランク、記念日といった詳細データは、PMSや自社CRMとのシステム連携が必要不可欠です。
裏を返せば、これら基幹システムとの連携が強固であるほど、より精度の高いセグメンテーションと訴求が可能になります。
また、各システムが提供するAPIやファイルのインタフェース・仕様はバラバラであり、これらシステム連携には深い技術力と各システムベンダーとのコミュニケーション力や要件調整力が求められます。
クラスメソッドでは、こうしたPMSや会員基盤、CRMといった既存システムとLINEをつなぐ開発を数多く手がけています。
東急株式会社様の会員基盤とLINEミニアプリの連携をはじめ、自社会員データベースや基幹システムとの連携を前提としたLINEミニアプリの開発実績があり、システムベンダーとのAPI仕様の調整やファイル連携の設計といった、ベンダー間の橋渡しも含めてご支援しています。
今回のデモのような管理画面やステップ配信の仕組みも、フルスクラッチで要件に合わせて構築できます。
LINEヤフーパートナープログラムの認定パートナーとして、LINE側の仕様や審査の相談にも対応していますので、「うちのPMSと連携できるのか」といった段階からお気軽にご相談ください。
メッセージ配信の管理画面
配信画面では、あらかじめ保存したオーディエンスを選択し、Flexメッセージのビジュアル、見出し、テキスト、ボタンを画面上でプレビューしながら直感的に組み立てて送信できます。

オーディエンスを選択し、プレビューを確認しながらメッセージを作成
ステップ配信の設定画面では、配信のトリガー(チェックアウト当日、チェックアウトから○日後、次回記念日の○日前など)に対して、待機日数、適用条件、配信コンテンツを時系列でセットします。前述した3つのプラン案内も、この画面上で条件とタイミングを個別に設定して運用する形をとっています。

トリガーとステップごとの配信条件を視覚的に管理
直販予約システムとの連携パターン
直販予約システムとの連携については、導入している予約エンジン側のAPI提供状況によって採用できるアーキテクチャが異なります。
今回の検証では、現実的なアプローチとして以下の3つの方式を想定しました。
| 連携方式 | 概要 | メリット | 留意点・デメリット |
|---|---|---|---|
| API連携 | 予約エンジンのAPIをミニアプリから直接コールし、空室照会から予約確定までを完結 | ・即時に予約が完了する ・予約データにLINE経由の属性を確実に保持できる ・完了通知メッセージをシームレスに自動送信可能 |
・予約エンジン側のAPI提供が必須要件 ・API利用オプション費用や開発コストが発生する |
| URL遷移 | ミニアプリから予約エンジンのWeb予約ページ(プランコード付きURL)へリダイレクト | ・開発工数を最小限に抑えられる ・API非対応の予約エンジンでもスピーディーに開始可能 |
・遷移先で会員情報の再入力が発生する場合がある ・LINE経由のコンバージョン計測がURLパラメータ依存となる ・予約完了イベントをLINE側で直接検知できない |
| CSV連携 | 予約エンジンやPMSから、予約・宿泊データを日次バッチ(CSV)で取り込む | ・既存システムに大規模な改修を加えずにスモールスタートできる ・過去の宿泊履歴の蓄積には十分 |
・リアルタイム性に欠ける(チェックアウト当日の即時配信は不可、翌日以降の対応となる) ・定期的なファイル授受の運用・管理設計が必要 |
完全なAPI連携が最もUXとしては優れていますが、まずはCSV連携を用いて宿泊実績を蓄積・セグメント配信を行い、予約自体はURL遷移で既存エンジンへ委ねるといった、フェーズを分けた段階的な導入も十分に現実的です。
どの方式から始めるべきかは、導入している予約エンジンのAPI提供状況や、蓄積したいデータの範囲によって異なります。
弊社では、ご利用中の予約エンジンやPMSの仕様を確認したうえで、「どの方式から着手すべきか」を整理する段階からご支援しています。
まとめ
- お礼とアンケート、領収書発行、物販ECへの誘導、再宿泊の動機に合わせたプラン案内、リッチメニューからの即時予約といった一連の導線は、LINE公式アカウントとLINEミニアプリを組み合わせることで柔軟に実装可能であることがわかりました。
- 実装時の留意点も多く、口コミ導線はプラットフォームの規約上、全員へ公平に提示する必要がある点や、オーディエンス作成から配信可能になるまでの待機時間、ブロック防止のための配信頻度制限、案内が届くのは予約者本人に限られる点など、設計段階で把握しておくべき制約もいくつか存在します。
- 一連の施策を成立させるためには、チェックアウトイベントの確実な検知と、宿泊実績・顧客属性をLINEユーザーIDに紐付けて管理するデータ基盤が土台となります。前回の記事でご紹介した「滞在中の仕組み」をそのまま拡張できるため、チェックインからチェックアウト後のフォローまでを一貫したアーキテクチャで設計するのが最も効果的です。
前回の滞在中の取り組みと今回の内容を組み合わせることで、チェックインから2回目以降のリピート予約に至るまでのカスタマージャーニーを、LINEを軸にシームレスにつなぐ全体像をイメージしていただけたのではないでしょうか。
クラスメソッドでは、LINEミニアプリの企画・UI設計からシステム開発、既存PMSや予約エンジンとの連携支援まで幅広く対応しています。
「どの施策から着手すべきか」「現在利用している予約システムとどのように連携できるか」など、気になる点がございましたらぜひお気軽にお問い合わせください。
※本記事の内容は2026年9月時点の情報にもとづいています。記事中で紹介した各種サービスの仕様、料金、APIの制約等は今後変更される可能性があるため、最新情報は各サービスの公式サイトをご確認ください。





















