--- title: "予約管理システムのLINE連携｜4つの実装方式と通知コストで決める選び方" url: "https://www.issoh.co.jp/column/details/16971/" published: 2026-08-26 updated: 2026-08-26 categories: ["Webシステム"] publisher: "株式会社一創" --- # 予約管理システムのLINE連携｜4つの実装方式と通知コストで決める選び方 LINE連携という言葉は、2つの別の話をひとまとめにしています。予約を受ける場所をLINEの中に置く話と、予約後の連絡をLINEで送る話。必要な仕組みも費用の出方も違い、片方だけで足りる事業者が実際には多くあります。この記事では、LINE公式アカウントからの送客、既製システムの連携オプション、LINEミニアプリ、Messaging APIによる自社実装の4方式を、導線と通知の2レイヤに分けて比較しました。友だちと予約者を結ぶ紐付けの設計、プッシュ通数の課金対象、リマインドを送ってもノーショーが減らない条件までを、2026年8月時点の公式ドキュメントの記載で整理しています。製品ごとの機能差は[予約管理システムを3タイプに分けて比較した記事](https://www.issoh.co.jp/column/details/16964/)で扱っています。 ## まとめ｜LINE連携を導線と通知に分けたときの選び方と費用の見積もり方 先に結論を書きます。LINE連携の検討は、予約を受ける場所をどこに置くかから始めてください。LINE公式アカウントのリッチメニューから既存の予約ページへ送るだけでも、利用者から見た体験は「LINEで予約できる」に変わります。ミニアプリや自社実装が必要になるのは、その先の要件が出てきたときだけです。 費用が読みにくいのは通知の側です。予約完了と前日リマインドと当日案内で1件あたり3通。月200件の予約なら600通で、無料枠200通のコミュニケーションプランでは足りません。しかも上限を超えた送信はエラーが返って届かないため、月末にリマインドが止まります。通知を業務の前提に組み込むなら、通数の監視と別手段への切り替えまで含めて設計してください。 自社でミニアプリを持つ判断は、認証審査とサービスメッセージの制約を受け入れられるかで決まります。1つの予約操作に対して送れるのは最大5回、内容も操作への応答に限られ、販促は送れません。予約が月数十件の運用なら、この投資は回収できません。 ## 予約管理システムのLINE連携で変わること｜予約導線と通知の2レイヤ 同じ「LINE連携対応」と書かれた製品でも、対応している範囲は2つに分かれます。混ぜて検討すると、必要のない機能に月額を払うことになります。 ### 予約を受ける場所としてのLINE｜アプリ内で完結する導線と外部送客の差 1つ目のレイヤは、予約フォームをどこで開かせるかです。LINE公式アカウントのリッチメニューに予約ボタンを置き、タップで既存の予約ページを開かせる形が最も軽い構成になります。この場合、開くのはブラウザなので、予約システム側の改修は不要です。 もう一段進めた形がLINEミニアプリです。LINE Developersの記載では、LINEミニアプリはLIFF（LINE Front-end Framework）上で実行されるウェブアプリで、利用者はアプリをインストールせずにサービスを使えます。リッチメニューやリッチメッセージから開くリンクを設置でき、LINEの外部からはパーマネントリンクでも到達可能。基盤側の解説は[LINEミニアプリの仕組みとLIFFとの違いを整理した記事](https://www.issoh.co.jp/column/details/15161/)にまとめています。 差が出るのは離脱です。ブラウザで開く方式では、予約のたびに氏名や電話番号の入力が発生します。ミニアプリならLINEのプロフィール情報を取得できるため、初回以降の入力を減らせる。ただしこの差が売上に効くのは、同じ利用者が繰り返し予約する業態に限られます。 ### 通知チャネルとしてのLINE｜到達が友だち関係に依存する構造と不達の扱い 2つ目のレイヤが通知です。メールやSMSと決定的に違うのは、送信できる相手が友だちに限られる点にあります。友だち登録がなければ、予約完了の連絡すら送れません。 ブロックされた場合も同じです。LINE Developersの「Messaging APIの料金」には、ブロック中のユーザーIDや存在しないユーザーIDなど実際には届かない宛先へ送信した場合、メッセージ通数にはカウントされないと明記されています。課金はされませんが、届いてもいません。送信ログが成功で埋まっていても来店に結びついていない状態が起こりえます。 この構造から、予約の連絡をLINEだけに寄せる設計は避けてください。予約時に取得したメールアドレスか電話番号を必ず台帳に残し、LINEが不達の相手には別手段が動くようにしておく。[予約台帳の役割と店舗のデジタル化の判断基準](https://www.issoh.co.jp/column/details/15908/)を整理した記事で触れたとおり、連絡手段の冗長化は台帳側の設計事項です。 ## LINE連携の4方式｜送客・連携オプション・ミニアプリ・API実装の比較 導線と通知の組み合わせで、実装は4つの型に整理できます。下にいくほど自由度が上がり、同時に審査と運用の負担も増えます。 ### 方式1｜リッチメニューから予約ページへ送客する最小構成と適する規模 LINE公式アカウントを開設し、リッチメニューに予約ページのURLを設定するだけの構成です。予約システム側は既存のまま、開発は発生しません。月額はLINE公式アカウントの料金プランのみで、無料のコミュニケーションプランでも運用できます。 この方式で足りるのは、予約が月100件程度までで、通知を一斉配信に頼らない事業者です。予約完了メールは予約システムの標準機能で送り、LINEは入口としてだけ使う。導入にかかるのはリッチメニューの画像作成と設定に限られます。 ### 方式2｜既製システムの連携オプション｜月4,400円という課金単位の意味 予約システム側がLINE連携を有償オプションとして提供している場合、これを契約する型です。STORES 予約のLINEミニアプリ連携は月4,400円（税込）でスモールプラン以上という提供形態を取っています。連携1本ごとに課金される構造で、同社ではかんざし連携5,500円、RemoteLOCK連携4,400円と、外部サービスごとに料金が積み上がります。 読み違えやすいのは、この4,400円が開発費の代替ではない点です。連携で実現するのは、その製品が用意した範囲の予約フローと通知に限られます。予約枠の持ち方や通知の文面を自社仕様にしたいなら、オプションでは届きません。どの製品がどの連携を持つかは[製品タイプ別の比較記事](https://www.issoh.co.jp/column/details/16964/)に、月額の総額への効き方は[費用を4項目に分解した記事](https://www.issoh.co.jp/column/details/16967/)に整理しています。 ### 方式3｜自社でLINEミニアプリを持つ構成と、認証審査が分ける機能差 自社の予約画面をLIFF上のウェブアプリとして作り、LINEミニアプリとして公開する型です。LINE Developersの記載では、ミニアプリは認証審査の通過有無で未認証ミニアプリと認証済ミニアプリに分かれます。未認証でも作成はできますが、機能に制限がかかります。 認証済になると、ホーム画面へのショートカット追加、Custom Path、チャネル同意の簡略化が使えます。LINEのホームタブのサービス欄に最近利用したミニアプリが最大8件表示される導線と、LINEの検索機能からのアクセスも認証済のみです。後述するサービスメッセージも認証済ミニアプリ限定で、ここが実質的な分岐点になります。 ### 方式4｜Messaging APIで自社の予約基盤に通知を実装する構成と前提 予約基盤は自社のシステムに置いたまま、通知だけをMessaging APIで送る型です。予約の作成・変更・キャンセルのイベントに合わせて、サーバーからプッシュメッセージを送ります。[Messaging APIでできることと通数カウントの基本](https://www.issoh.co.jp/column/details/3302/)は別記事にまとめているので、ここでは予約業務に効く条件だけを見ます。 前提になるのは、予約者のLINEユーザーIDを自社側で持てていることです。友だち追加のタイミングで発行されるIDを、予約台帳のどのレコードに結びつけるか。ここを決めずに実装を始めると、通知を送る相手が特定できず作り直しになります。設計は次章で扱います。 | 方式 | 予約を受ける場所 | 通知の手段 | 初期の負担 | 向く規模 | | --------- | ---------- | ---------- | -------- | ----------- | | 1 送客 | 既存の予約ページ | 予約システムのメール | 設定のみ | 月100件まで | | 2 連携オプション | 製品のミニアプリ | 製品の標準通知 | 月4,400円級 | 月100〜1,000件 | | 3 自社ミニアプリ | 自社のLIFFアプリ | サービスメッセージ | 開発＋認証審査 | 複数店舗・再来型 | | 4 API実装 | 自社の予約画面 | プッシュメッセージ | 開発＋通数課金 | 基幹連携が必要 | 実務では方式1から始めて、予約件数が伸びてから2へ移る順路が安全です。3と4は、既存の予約フローで壊れる要件がはっきりしてから検討してください。 ## 友だちと予約者を結ぶ紐付け設計｜ユーザーIDの単位と台帳の顧客キー LINE連携の失敗は、通知が届かない形で表面化します。原因のほとんどは、送信の実装ではなく紐付けの設計にあります。 ### ユーザーIDと自社会員IDを結ぶ手順｜アカウント連携で押さえる流れ LINEのユーザーIDは、LINE公式アカウントのチャネル単位で発行される識別子です。自社の会員番号や予約番号とは無関係な値なので、両者を結ぶ工程が要ります。LINE Developersは、プロバイダーが提供するサービスのユーザーと、LINE公式アカウントと友だちになっているLINEアカウントを安全に連携する仕組みとして、アカウント連携を案内しています。 1. 予約者が友だち追加した時点で、WebhookイベントからユーザーIDを受け取る 2. 会員登録済みか未登録かで分岐し、未登録なら本人確認を挟んで会員レコードを作る 3. 会員IDとユーザーIDの対応表を、予約台帳とは別のテーブルとして持つ 4. 通知の送信時は会員IDから対応表を引き、有効な連携があるときだけプッシュを実行する 対応表を独立させるのは、1人の会員が機種変更や再登録でIDを持ち直す場面があるためです。予約レコードにユーザーIDを直接持たせると、履歴と通知先が同時に壊れます。 ### 紐付けが崩れる3つの場面｜代理予約・ブロック・複数店舗での取り違え 設計時に想定から漏れやすいのは、1つのLINEアカウントが複数の予約者を代理するケースです。家族分をまとめて予約する歯科や、子どもの習い事の枠を保護者が押さえる形が該当します。通知先は1つでも、予約者は複数。台帳の顧客キーをLINEユーザーIDにしてしまうと、この時点で破綻します。 - 代理予約：通知先と予約者が1対多になり、顧客キーをLINEユーザーIDに置けない - ブロック：送信は成功扱いでも届かず、通数にもカウントされないため検知が遅れる - 複数店舗：LINE公式アカウントを店舗ごとに分けるとユーザーIDも店舗ごとに別値になる 3つ目は多店舗展開で必ず当たります。ブランドで1つの公式アカウントにまとめるか、店舗ごとに分けるかは、集客の設計ではなくデータの設計として先に決めてください。後から統合する場合、ユーザーIDは引き継げず、友だちの再取得からやり直しになります。 ## リマインド配信の費用構造｜通数のカウント対象と2026年10月の料金改定 LINE連携の月額は、予約システム側のオプション料金よりも、通知の通数で決まります。ここは公式の料金ページに数字が出ているので、自社の予約件数から逆算できます。 ### カウントされる送信とされない送信｜応答メッセージが無料である仕組み LINE Developersの「Messaging APIの料金」では、料金プランのメッセージ通数としてカウントされる送信方法を、プッシュメッセージ・マルチキャストメッセージ・ブロードキャストメッセージ・ナローキャストメッセージの4つと定めています。カウントされないのは応答メッセージです。 予約業務に置き換えると、システム側から一方的に送る予約完了通知やリマインドはすべて課金対象になります。一方、利用者が「予約確認」と送ってきたのに対して返す形にすれば、応答メッセージとして通数を消費しません。通数を抑えたい場合の設計余地はここにあります。 通数は送信対象となった人数でカウントされる点も押さえてください。1回のリクエストでメッセージオブジェクトを4件指定しても、宛先が5人なら5通です。文面を分割して送ると、その分だけ人数×回数で増えます。 ### 予約件数から必要プランを逆算する試算｜1件3通で見た月間の上限 予約1件あたりの通知を、予約完了・前日リマインド・当日案内の3通と置きます。日本のLINE公式アカウントの料金プランは、公式ドキュメントの例で次のとおりです。 | プラン | 月額固定費 | 無料メッセージ | 追加メッセージ | 1件3通での月間予約 | | --------- | ------- | ------- | ------- | ---------- | | コミュニケーション | 0円 | 200通 | 不可 | 約66件 | | ライト | 5,000円 | 5,000通 | 不可 | 約1,666件 | | スタンダード | 15,000円 | 30,000通 | 〜3円通 | 約1万件 | 金額はいずれも税別です。この表で読み取ってほしいのは、月200件の予約でも無料枠を3倍超過するという事実になります。無料で始められるという説明は、通知を使わない場合の話です。 ### 2026年10月1日の追加メッセージ料金改定｜影響が出る配信規模の見極め LINEヤフー for Businessの料金プランページには、2026年10月1日に追加メッセージ料金の改定を行うとの告知が掲載されています（2026年8月時点の記載）。改定後は段階的な単価から2段階へ整理され、月20万通までが1通3円、超過分が1通2.5円になると各社が案内しています。 予約リマインドの規模では、この改定の影響はほぼありません。追加メッセージが使えるのはスタンダードプランのみで、無料枠30,000通を超えて初めて発生する費用だからです。1件3通の設計なら、月1万件の予約を超えたところが入口になります。改定への対応が要るのは、予約通知ではなく販促配信を大量に回しているアカウントです。 ## ノーショー削減が成立する条件｜リマインドを送っても減らない予約の型 LINE連携の効果として最も語られるのが無断キャンセルの減少ですが、通知を送るだけで減るわけではありません。効く条件と、効かない場面を分けます。 ### 到達と行動の2条件｜変更導線のないリマインドが空振りする理由 リマインドがノーショーを減らすのは、受け取った人がその場で予定を確定または変更できるときだけです。「明日15時にご予約です」とだけ送り、変更の連絡先が電話番号の記載しかない場合、都合が悪くなった利用者は連絡を諦めます。結果は無断キャンセルのままです。 設計として必要なのは、リマインド本文に予約詳細画面へのリンクを載せ、そこで変更とキャンセルを完結させることです。ミニアプリ方式ならタップ2回で予約画面に着きます。キャンセルされた枠が空きとして戻れば、当日の埋め直しにも回せます。ノーショーを減らすという言い方は正確ではなく、無断を有断に変えるのが実際の効果です。 ### 上限超過で配信が止まる事故｜エラーレスポンスが返る仕様への備え 見落とされやすい失敗がこれです。LINE Developersの記載では、当月に送信できるメッセージ通数の上限を超えてメッセージを送信しようとした場合、エラーレスポンスが返りメッセージは送信されません。予約が集中した月ほど、リマインドが止まる確率が上がります。 公式には、当月に送信できるメッセージ数の上限目安を取得するエンドポイントと、当月のメッセージ利用状況を取得するエンドポイントが用意されています。通知を業務の前提にするなら、この2つを日次で監視し、残通数が閾値を割ったらメールかSMSへ切り替える分岐を必ず入れてください。監視なしでLINEだけに寄せる構成は採用しないでください。月末に無言で止まり、止まった事実にも気づけません。 ### LINE連携を見送ってよい場面｜月数十件・当日予約中心の運用での判断 逆に、投資が見合わない条件も明確です。月間予約が数十件で、その多くが当日または前日の飛び込みという運用では、リマインドを送る時間差がそもそも生まれません。通知が届く前に来店が終わります。 もう1つは、予約者の大半が一見客で再来がない業態です。友だち追加は予約の摩擦になるため、追加を必須にすると予約数自体が落ちます。この場合はLINE連携を入れず、予約ページのフォーム改善と、メールまたはSMSでのリマインドに絞るほうが結果が出ます。LINEは再来を前提とした関係の上でしか働きません。 ## 自社ミニアプリと受託開発の分岐｜サービスメッセージの制約と見合う規模 方式3と4に進むかどうかは、既製オプションで壊れる要件があるかで決まります。判断材料になるのは、サービスメッセージの仕様です。 ### サービスメッセージの制約｜1操作5回・テンプレート20個・販促の禁止 LINE Developersの記載では、サービスメッセージは認証済ミニアプリでのみ利用できる機能で、ミニアプリ上のユーザー操作に対する確認や応答としてのみ送信できます。レストランや宿泊施設の予約を例に、1つの操作に対して予約完了や前日のリマインドといったメッセージを最大5回まで送信できると説明されています。 制約は3つあります。値下げ・特典・新商品・クーポン・プロモーションを含む広告やイベントの通知は禁止されていること。テンプレートは公式が用意したカテゴリ別のものを使い、チャネルごとに20個まで追加できること。そしてAPIで利用するにはLINEヤフー株式会社の審査を通過する必要があることです。 裏を返すと、予約の確認とリマインドという用途はテンプレートの想定内に収まります。販促を同じ経路で送りたいなら、LINE公式アカウントのプッシュメッセージが別途要り、そちらは通数課金の対象になります。 ### 受託開発に踏み出す条件｜既製オプションで届かない要件の見極め方 自社ミニアプリや自社実装を選ぶ理由になるのは、次のいずれかが該当する場合です。予約枠のロジックが製品の想定と合わない（設備と人員を同時に押さえる、施術内容で所要時間が変わるなど）。基幹システムと予約データを双方向で同期する必要がある。複数ブランドを1つのアカウントで運用したい。 逆に、これらに当てはまらないのに開発を選ぶと費用が回収できません。月4,400円のオプションは年52,800円で、開発費の下限にも届かない金額です。要件が既製品の内側にあるうちは、乗り換えのほうが速く安く済みます。判断の全体像は[予約システムの機能と種類、開発判断を整理した記事](https://www.issoh.co.jp/column/details/12829/)にまとめています。 要件が外側にあると分かった段階で、実装方式の選定に入ります。当社では[LINEミニアプリ開発](https://www.issoh.co.jp/service/apps/line/)として、予約フローの設計から認証審査の申請、既存の予約基盤との接続までを請けました。既存システムを残したまま通知だけをMessaging APIへ寄せる構成も選択肢です。 ## よくある質問 予約管理システムのLINE連携について、検討段階で問い合わせの多い5点をまとめました。 ### LINE公式アカウントだけで予約を受け付けられますか？ トーク上のやり取りで受けることはできますが、予約台帳としては機能しません。枠の重複を防ぐ仕組みがなく、担当者が手作業で空きを確認することになるためです。リッチメニューから予約システムのページへ送る構成にすれば、公式アカウントは入口として使いつつ、枠の管理はシステム側に任せられます。 ### LINEミニアプリとLIFFは、どちらを選べばよいですか？ 選択の関係ではありません。LINEミニアプリはLIFF上で動くウェブアプリで、LIFFはその土台です。LINEミニアプリチャネルとして公開すると認証審査やサービスメッセージが関わり、LIFFアプリ単体で使う場合はそれらの対象外になります。仕組みの違いはLINEミニアプリの解説記事、実装手順はLIFFの技術記事に分けて整理しています。 ### リマインドは何通まで無料で送れますか？ LINE公式アカウントの料金プランによります。公式ドキュメントの例では、コミュニケーションプランが月200通、ライトプランが5,000通、スタンダードプランが30,000通の無料メッセージを含みます。予約1件につき完了・前日・当日の3通を送る設計なら、それぞれ月66件・1,666件・1万件程度が目安です。上限を超えた送信はエラーになり届かないため、件数が読めない月は監視を入れてください。 ### 友だち追加していない人にも予約の通知は届きますか？ 届きません。Messaging APIで送信できる相手は、そのLINE公式アカウントと友だちになっているユーザーに限られます。ブロック中のユーザーIDへ送信した場合もメッセージは届かず、通数にもカウントされません。予約時にメールアドレスか電話番号を必ず取得し、LINEが使えない相手には別の手段で連絡が飛ぶようにしておくのが前提になります。 ### 既存の予約システムをLINE対応にする場合、どこから着手すべきですか？ まず、使っている製品がLINE連携オプションを持つかを確認してください。持っている場合は月額の追加で済みます。持っていない場合は、リッチメニューから予約ページへ送る構成で先に効果を測り、入力の手間や通知の要件で不足が出た段階でミニアプリ化を検討する順路が無駄になりません。 ## 関連記事 - [予約システムとは？主な機能・種類と、既製サービスで足りない場合の開発判断を解説](https://www.issoh.co.jp/column/details/12829/)：予約システム全体の機能と種類、開発に切り替える判断基準 - [予約管理システムの比較｜3タイプ別の選び方と既製品で足りなくなる境界線](https://www.issoh.co.jp/column/details/16964/)：製品タイプ別の比較と選定の順番 - [LINEミニアプリとは？仕組み・LIFFとの違い・開発費用から導入判断まで解説](https://www.issoh.co.jp/column/details/15161/)：ミニアプリの仕組みと開発費用の目安 - [LIFFとは？LINEアプリ内で動くWebアプリの仕組みと開発手順を実装目線で解説](https://www.issoh.co.jp/tech/details/3396/)：土台となるLIFFの実装手順を技術者向けに解説 - [飲食店の順番待ちシステムとは？行列受付・LINE呼び出しの機能と費用・連携の選び方](https://www.issoh.co.jp/column/details/16093/)：当日の行列をLINEで呼び出す場合の設計 --- 出典: [予約管理システムのLINE連携｜4つの実装方式と通知コストで決める選び方]()（株式会社一創）