開発

LINE予約システムを自作する：LIFFとMessaging APIの構成・コード・料金【2026年10月】

AIチャットボット開発の応用分野

LINE予約システムを自作するときは、予約画面をLIFFで作り、予約の完了通知と前日のリマインドをMessaging APIのプッシュメッセージで送る構成が基本形です。この記事では、2026年10月時点のLINE Developersの公式ドキュメントにもとづき、チャネルの作り方、IDトークンで予約者を確かめるコード、二重予約を止めるテーブル設計、Webhookでのキャンセル受付、リッチメニューの導線、月の予約件数から逆算する料金プランまでを手順で示します。既製の予約システムで足りる場面と、自作に進むべき条件も最後に言い切ります。

まとめ：LINE予約システムを自作するときの構成と採否の判断基準

自作の構成は、LINEログインチャネルに登録したLIFFアプリ（予約画面）、Messaging APIチャネル（通知とWebhook）、自社のAPIサーバーと予約データベースの4つです。2つのチャネルは必ず同じプロバイダーに置きます。プロバイダーが違うとユーザーIDが一致せず、予約者に通知を送れません。

実装で外せないのは、IDトークンをサーバーで検証してから予約を作ること、空き枠の取り合いをデータベースの制約で止めること、プッシュにリトライキーを付けることの3点です。費用は、予約1件につき完了通知と前日リマインドの2通を送るなら、月100件まではLINE公式アカウントの無料プランに収まります。既存の顧客台帳や業務システムと予約をつなぎたい場合は自作が見合い、単店舗で月数十件なら既製ツールの無料プランを選びます。

LINE予約システムの作り方の選択肢：既製ツール連携と自作で変わる範囲

「LINE予約システム」と呼ばれる仕組みの多くは、既製の予約システムがLINE公式アカウントと連携したものです。自作するかどうかは、この連携で届かない要件があるかで決まります。

既製予約システムのLINE連携で足りる範囲と自作に進む4つの要件

既製の予約システムは、リッチメニューから予約ページへ送客し、予約完了やリマインドをLINEで通知する機能を、月額のオプションとして提供していることが多くあります。予約枠の管理画面も最初から付いてくるので、メニューと時間枠が決まった店舗ならこれで対応可能です。方式ごとの違いと通知の費用は予約管理システムのLINE連携｜4つの実装方式と通知コストで決める選び方で比べています。

自作に進むのは、次のどれかに当てはまる場合です。

  • 予約データを自社の顧客台帳・会員ID・基幹システムと同じIDで持ちたい
  • 枠の決め方が独自で、既製品の設定項目では表せない（設備と担当者の組み合わせ、移動時間を挟む訪問予約など）
  • 予約数が多く、既製品の従量課金が自前のサーバー費を上回る
  • 通知の文面・送るタイミング・送る相手を、業務の状態に合わせて細かく変えたい

上の項目ほど、既製品のカスタマイズでは解決しにくい要件です。1つ目に当てはまるなら、ほかの3つを待たずに自作を検討してよいでしょう。

自作構成の全体像：LIFF・Messaging API・予約DB・Webhookの役割

部品ごとの役割は次のとおりです。LINEの機能を使うのは画面と通知だけで、予約の正しさは自社のサーバーとデータベースが受け持ちます。

部品 置き場所 役割
LIFFアプリ LINEログインチャネル 予約フォームの表示とIDトークンの取得
APIサーバー 自社のクラウド IDトークンの検証と予約の登録
予約データベース 自社のクラウド 空き枠と予約の保存と二重予約の防止
Messaging API Messaging APIチャネル 完了通知とリマインドの送信
Webhook 自社のAPIサーバー キャンセルボタンの受信

予約画面をLINEの外のWebページにすると、予約者のLINEユーザーIDを確実に受け取れません。LIFFを使う理由はこの1点にあります。

検証環境の準備：同じプロバイダーにLINEログインとMessaging APIを置く手順

コードを書く前に、LINE Developersコンソールで2つのチャネルを用意します。ここで配置を誤ると、後から作り直しになります。

Messaging APIチャネルの作成とユーザーIDを揃えるプロバイダー配置

Messaging APIの始め方を説明した公式ドキュメントによると、2024年9月4日以降、Messaging APIチャネルはLINE Developersコンソールから直接作れません。先にLINE公式アカウントを作り、LINE Official Account ManagerでMessaging APIを有効にすると、チャネルが作られます。有効にするときに選ぶプロバイダーが、この後の設計を左右します。

ユーザーIDの取得方法を説明した公式ドキュメントには、ユーザーIDはプロバイダーごとに異なる値が発行され、同じプロバイダーならチャネルの種類にかかわらず同じ値になると書かれています。LIFFで受け取ったIDにプッシュを送るには、LINEログインチャネルをMessaging APIチャネルと同じプロバイダーに作る必要があります。別のプロバイダーに作ると、APIは受け付けても予約者に通知が届きません。

LIFFアプリの登録：スコープ・サイズ・友だち追加オプションの設定値

LIFFアプリの追加手順を示した公式ドキュメントに沿って、LINEログインチャネルにLIFFアプリを追加します。予約で使う設定値は次のとおりです。

  1. サイズはFullを選ぶ（日付と時間枠を一覧で見せるため）
  2. エンドポイントURLに予約画面のURLを入れる（httpsのみ、URLフラグメントは不可）
  3. スコープはopenidとprofileを選ぶ（IDトークンの取得と友だち状態の確認に使う）
  4. 友だち追加オプションはOn (aggressive)にする（同意画面の後に友だち追加の確認を出す）

登録するとhttps://liff.line.me/から始まるLIFF URLが発行され、これがリッチメニューやメッセージに置く予約画面の入口になります。友だち追加を強めに促すのは、後で説明するとおり、友だちでない予約者にはプッシュが届かないからです。

LIFFで予約フォームを作る：IDトークンを送り、サーバーで本人確認するコード

予約画面は通常のWebアプリとして作り、LIFF SDKで予約者を特定する処理だけを足します。2026年10月時点のnpmの最新版は@line/liff 2.31.2です。

liff.initとgetIDTokenで予約内容とIDトークンを送るフロント実装

LIFF APIリファレンスによると、LINEの中で開いた場合はliff.init()の時点でログインが済み、外部ブラウザで開いた場合だけliff.login()が必要になります。

npm install @line/liff@2
import liff from '@line/liff';

const LIFF_ID = '1234567890-AbcdEfgh'; // 登録時に発行されたLIFFアプリID

async function setup() {
  await liff.init({ liffId: LIFF_ID });
  if (!liff.isLoggedIn()) {
    liff.login(); // 外部ブラウザで開いたときだけ通る
    return;
  }
  // 友だちでなければ通知が届かないので、予約前に知らせる
  const { friendFlag } = await liff.getFriendship();
  document.querySelector('#friend-warning').hidden = friendFlag;
}

async function submitReservation(slotId, partySize) {
  const idToken = liff.getIDToken(); // openid スコープが必要
  const res = await fetch('/api/reservations', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      Authorization: `Bearer ${idToken}`,
    },
    body: JSON.stringify({ slotId, partySize }),
  });
  if (res.status === 409) {
    alert('この枠は埋まりました。別の時間を選んでください。');
    return;
  }
  if (!res.ok) throw new Error(`予約に失敗しました: ${res.status}`);
  if (liff.isInClient()) liff.closeWindow(); // LINEの中ならトーク画面へ戻す
}

setup();

送るのは枠のIDと人数とIDトークンだけです。ユーザーIDや名前をフロントから送らない理由は、次のh3で説明します。liff.closeWindow()は外部ブラウザでの動作が保証されていないため、LIFFブラウザの中に限って呼んでいます。

IDトークン検証APIでsubを取り出すサーバー側の本人確認の実装

LIFFでユーザー情報を扱う方法を示した公式ドキュメントは、liff.getProfile()などで得たプロフィールをサーバーに送らないよう求めています。フロントから届くユーザーIDは、書き換えれば他人になりすませるからです。サーバーはIDトークンを受け取り、LINEの検証APIに問い合わせて、返ってきたsubをユーザーIDとして使います。

// Node.js 20以降（fetch は標準で使える）
async function verifyIdToken(idToken) {
  const res = await fetch('https://api.line.me/oauth2/v2.1/verify', {
    method: 'POST',
    headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
    body: new URLSearchParams({
      id_token: idToken,
      client_id: process.env.LINE_LOGIN_CHANNEL_ID, // LINEログインのチャネルID
    }),
  });
  if (!res.ok) return null; // 期限切れ・改ざん・別チャネルのトークン
  const payload = await res.json();
  return payload.sub; // LINEユーザーID（U から始まる文字列）
}

IDトークンの検証方法を示した公式ドキュメントのとおり、client_idにはMessaging APIではなくLINEログインのチャネルIDを入れます。検証に失敗したら401を返し、予約は作りません。

予約データの設計：空き枠の二重予約をデータベースの制約で止めるテーブル

LINEから来る予約は、通知を見た複数の人が同時に同じ枠を押す形になりがちです。空き確認と登録を別々のSQLで行うと、最後の1枠に2件入ります。

PostgreSQLで書く予約枠と予約のテーブル定義と部分ユニーク制約

枠のテーブルに定員と予約済み数を持たせ、予約済み数が定員を超えない制約をデータベースに書きます。同じ人が同じ枠を二重に押した場合は、有効な予約だけを対象にした部分ユニークインデックスで弾きます。

CREATE TABLE slots (
  id         BIGSERIAL PRIMARY KEY,
  starts_at  TIMESTAMPTZ NOT NULL,
  capacity   INT NOT NULL CHECK (capacity > 0),
  reserved   INT NOT NULL DEFAULT 0,
  CHECK (reserved BETWEEN 0 AND capacity)
);

CREATE TABLE reservations (
  id            BIGSERIAL PRIMARY KEY,
  slot_id       BIGINT NOT NULL REFERENCES slots(id),
  line_user_id  TEXT NOT NULL,          -- IDトークン検証で得た sub
  party_size    INT NOT NULL DEFAULT 1 CHECK (party_size > 0),
  status        TEXT NOT NULL DEFAULT 'confirmed',  -- confirmed / canceled
  remind_key    UUID NOT NULL DEFAULT gen_random_uuid(),  -- リマインドのリトライキー
  reminded_at   TIMESTAMPTZ,
  created_at    TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- 同じ人が同じ枠に有効な予約を2件持てないようにする
CREATE UNIQUE INDEX uq_active_reservation
  ON reservations (slot_id, line_user_id) WHERE status = 'confirmed';

gen_random_uuid()はPostgreSQL 13以降で拡張なしに使えます。remind_keyを予約ごとに保存しておく理由は、通知の章で扱います。

同時に押された最後の1枠を条件付きUPDATEで取り合わせない実装

空きの確認と予約済み数の加算を、1本の条件付きUPDATEで済ませます。条件に合わなければ更新は0行になり、その時点で満席と判断できます。

BEGIN;
-- 定員を超えない場合だけ加算する。0行なら満席として 409 を返す
UPDATE slots
   SET reserved = reserved + $2
 WHERE id = $1 AND reserved + $2 <= capacity
RETURNING id;

INSERT INTO reservations (slot_id, line_user_id, party_size)
VALUES ($1, $3, $2)
RETURNING id, remind_key;
COMMIT;

UPDATEが行ロックを取るため、同じ枠への後続の更新は先の処理が確定するまで待ち、確定後の値で条件を判定し直します。INSERTが部分ユニークインデックスに当たった場合はロールバックし、「すでに予約済み」と返してください。営業時間・休業日・キャンセル規定など、LINEに依存しない予約の設計は予約システム開発の進め方｜自作の設計・技術選定・必須機能と費用を解説で扱っています。

Messaging APIで予約完了と前日リマインドを送るプッシュ通知の実装

予約者への通知は、Messaging APIのプッシュメッセージで送ります。予約はLIFFの画面で完結し、トークでの返信を伴わないため、応答メッセージは使えません。

プッシュメッセージAPIとX-Line-Retry-Keyで二重送信を防ぐ送信関数

Messaging APIリファレンスのプッシュメッセージの項では、エンドポイントはPOST https://api.line.me/v2/bot/message/pushで、1回に送れるメッセージは5件までです。タイムアウトで再送したときに同じリマインドが2回届かないよう、X-Line-Retry-Keyを付けます。

// retryKey には予約ごとに保存した remind_key などを渡し、再試行でも同じ値を使う
async function pushMessage(to, messages, retryKey) {
  const res = await fetch('https://api.line.me/v2/bot/message/push', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      Authorization: `Bearer ${process.env.LINE_CHANNEL_ACCESS_TOKEN}`,
      'X-Line-Retry-Key': retryKey,
    },
    body: JSON.stringify({ to, messages }),
  });
  if (res.status === 409) return 'accepted-before'; // 同じキーで受理済み＝送信済み扱い
  if (res.status === 429) throw new Error('上限超過またはレート制限');
  if (!res.ok) throw new Error(`push failed: ${res.status} ${await res.text()}`);
  return 'sent';
}

失敗したAPIリクエストの再試行を説明した公式ドキュメントによると、リトライキーは最初のリクエストから24時間有効で、受理済みのキーで再送すると409が返ります。再送のたびに新しいUUIDを作ると重複を防げないので、キーは予約の行に保存したものを使い回します。

友だちでない予約者に200が返っても届かない仕様と代替の連絡手段

同じリファレンスには、LINE公式アカウントを友だち追加していないユーザーやブロックしているユーザーにプッシュを送ると、ステータスコード200が返るのに実際には送信されないと書かれています。APIの応答だけを見て「通知済み」と記録すると、届いていないリマインドを送ったことになります。

LIFFはLINEログインで動くため、友だちでなくても予約画面は開けます。対策は2段です。LIFFの登録で友だち追加オプションをOn (aggressive)にし、予約の前にliff.getFriendship()で状態を確かめます。友だちでない予約者からはメールアドレスか電話番号を受け取り、リマインドをメールやSMSで送る経路を残してください。

前日リマインドの送信バッチと予約件数から逆算する料金プランの通数

リマインドは1時間ごとなどの定期実行で、翌日の有効な予約のうち未送信のものを取り出して送ります。

SELECT r.id, r.line_user_id, r.remind_key, s.starts_at
  FROM reservations r
  JOIN slots s ON s.id = r.slot_id
 WHERE r.status = 'confirmed'
   AND r.reminded_at IS NULL
   AND s.starts_at >= (current_date + 1) AND s.starts_at < (current_date + 2)
 ORDER BY s.starts_at
 LIMIT 500;
-- 送信後: UPDATE reservations SET reminded_at = now() WHERE id = $1;

Messaging APIの料金を説明した公式ドキュメントでは、プッシュは通数に数えられ、応答メッセージは数えられません。上限を超えるとエラーが返り、メッセージは送信されません。予約1件につき完了通知とリマインドの2通を送る場合の目安は次のとおりです（金額は税別）。

プラン 月額 無料の通数 2通送る場合の予約件数
コミュニケーション 0円 200通 月100件まで
ライト 5,000円 5,000通 月2,500件まで
スタンダード 15,000円 30,000通 月15,000件まで

無料の通数は、同じアカウントから送るキャンペーン配信と共有です。予約が月100件を超える見込みなら、最初からライトプランで見積もります。LINEヤフー for Businessの料金プランのページによると、追加メッセージを送れるのはスタンダードプランだけで、2026年10月1日に追加メッセージ料金が改定されました。通数の数え方の全体はMessaging APIとは？LINEでできること・料金の通数カウントと実装手順を解説にまとめています。

Webhookでキャンセルを受け付ける：署名検証とポストバックの処理手順

リマインドに「キャンセルする」ボタンを付けると、無断キャンセルを事前の連絡に変えられます。ボタンが押されると、LINEプラットフォームから自社のWebhookにポストバックイベントが届きます。

x-line-signatureの照合とポストバックで本人の予約を取り消す処理

リマインドには、ボタンテンプレートでポストバックアクションを入れておきます。dataは最大300文字なので、予約IDだけを入れます。

{
  "type": "template",
  "altText": "明日のご予約のお知らせ",
  "template": {
    "type": "buttons",
    "text": "明日 10:00 のご予約があります。",
    "actions": [
      { "type": "uri", "label": "日時を変更する", "uri": "https://liff.line.me/1234567890-AbcdEfgh?r=123" },
      { "type": "postback", "label": "キャンセルする", "data": "action=cancel&reservationId=123", "displayText": "キャンセルします" }
    ]
  }
}

受信側では、処理の前に必ず署名を照合します。Webhookの署名検証を説明した公式ドキュメントの手順は、チャネルシークレットを鍵にしてリクエストボディのHMAC-SHA256を計算し、Base64にした値をx-line-signatureヘッダーと比べるというものです。ボディをJSONに変換してから計算すると一致しないので、生のバイト列のまま扱います。

import crypto from 'node:crypto';
import express from 'express';

const app = express();

app.post('/webhook', express.raw({ type: 'application/json' }), async (req, res) => {
  const signature = Buffer.from(req.get('x-line-signature') ?? '');
  const expected = Buffer.from(
    crypto.createHmac('sha256', process.env.LINE_CHANNEL_SECRET).update(req.body).digest('base64')
  );
  if (signature.length !== expected.length || !crypto.timingSafeEqual(signature, expected)) {
    return res.sendStatus(401);
  }
  res.sendStatus(200); // 先に200を返し、処理はその後に行う

  const { events } = JSON.parse(req.body.toString('utf8'));
  for (const ev of events) {
    if (ev.type !== 'postback') continue;
    const params = new URLSearchParams(ev.postback.data);
    if (params.get('action') === 'cancel') {
      // 予約IDと送信者のユーザーIDが一致する予約だけを取り消す
      await cancelReservation(params.get('reservationId'), ev.source.userId);
    }
  }
});

cancelReservationでは、予約IDだけで取り消さず、line_user_idが送信者と一致する行に限ってstatusをcanceledにし、同じトランザクションで枠のreservedを戻します。Webhookの受信を説明した公式ドキュメントによると再送は既定で無効なので、取りこぼしが困る場合はコンソールで再送を有効にし、同じイベントが2回届いても結果が変わらない処理にしておきます。

リッチメニューから予約画面を開く導線：URIアクションとLIFF URLの設定

友だちになった人が次に予約するときの入口は、トーク画面の下に常に出るリッチメニューです。

リッチメニューAPIで予約・予約確認の2領域を作成するリクエスト

リッチメニューの使い方を説明した公式ドキュメントの手順は、メニューの作成、画像のアップロード、デフォルトへの設定の3段です。左右2つの領域に、予約画面と予約確認画面のLIFF URLを割り当てる例を示します。

curl -X POST https://api.line.me/v2/bot/richmenu \
  -H "Authorization: Bearer ${LINE_CHANNEL_ACCESS_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "size": { "width": 2500, "height": 843 },
    "selected": true,
    "name": "reservation-menu",
    "chatBarText": "予約する",
    "areas": [
      { "bounds": { "x": 0, "y": 0, "width": 1250, "height": 843 },
        "action": { "type": "uri", "uri": "https://liff.line.me/1234567890-AbcdEfgh" } },
      { "bounds": { "x": 1250, "y": 0, "width": 1250, "height": 843 },
        "action": { "type": "uri", "uri": "https://liff.line.me/1234567890-AbcdEfgh/mine" } }
    ]
  }'
# 返ってきた richMenuId に画像を付け、全員のデフォルトにする
curl -X POST "https://api-data.line.me/v2/bot/richmenu/${RICH_MENU_ID}/content" \
  -H "Authorization: Bearer ${LINE_CHANNEL_ACCESS_TOKEN}" -H "Content-Type: image/png" -T menu.png
curl -X POST "https://api.line.me/v2/bot/user/all/richmenu/${RICH_MENU_ID}" \
  -H "Authorization: Bearer ${LINE_CHANNEL_ACCESS_TOKEN}"

Messaging APIリファレンスが定める画像の条件は、JPEGかPNG、幅800〜2500ピクセル、高さ250ピクセル以上、アスペクト比1.45以上、1MBまでです。一度設定した画像は差し替えられず、メニューを作り直すことになります。季節ごとに画像を変える運用なら、作成から切り替えまでをスクリプトにしておきます。

受託開発の視点で見るLINE予約システム自作の採用条件と見送る場面

ここからは、予約システムの開発を受ける立場からの判断です。自作の費用は画面とAPIの開発だけでなく、枠の管理画面、障害時の連絡、LINEの仕様変更への追従まで含みます。

自作を採用する条件：既存の顧客台帳や業務システムと予約をつなぐ場合

自作が見合うのは、予約を受けた後の処理が自社の業務に深く入り込むケースです。会員IDとLINEのユーザーIDを結び付けて来店履歴を出す、予約の確定で在庫や担当者のシフトを押さえる、来店後に請求や問診のデータへ引き継ぐ、といった要件は既製品の連携オプションでは届きません。複数店舗を同じ基盤で回す場合も、店舗を増やすたびの月額が積み上がらない分、自作の回収が早まります。

既存の業務システムとつなぐ予約基盤の設計から、LIFFの画面、通知、管理画面までをまとめて任せたい場合は、予約管理システム開発でご相談をお受けしています。

自作を見送る場面：月数十件の単店舗と既製ツールの無料プランで足りる要件

1店舗で月数十件、メニューと時間枠が固定の予約なら、自作はやめておくべきです。通数はLINEの無料プランに収まっても、サーバーの保守、チャネルアクセストークンの管理、リッチメニューの更新といった運用は誰かが持ち続けることになります。既製の予約システムの無料プランか、Googleのツールで組む方法で始め、乗り換えの検討は件数が増えてからで十分です。Googleで組む場合の構成と限界は予約システムを無料でGoogleだけで作る方法｜予約スケジュール・フォーム・Apps Scriptの3構成と限界で解説しています。

もう1つの失敗パターンは、LINEの友だちだけを予約の前提にする設計です。友だちでない人やブロックした人には通知が届かないため、メールか電話の連絡先を持たない予約基盤は、リマインドの到達率をLINEの友だち状態に預けることになります。

LIFFアプリとLINEミニアプリのどちらで作るか：統合予定を踏まえた選択

LIFFアプリの追加手順を示した公式ドキュメントには、LIFFとLINEミニアプリはブランド統合を予定しており、LIFFアプリを新規に作るときはLINEミニアプリとして作成することを推奨すると書かれています（2025年2月12日のニュースを参照する注記）。これから新しく作る予約画面は、LINEミニアプリのチャネルで始めるほうが統合後の作り直しを避けられます。

中のコードは本記事のLIFF SDKの書き方をそのまま使うことが可能です。認証済みミニアプリの審査を通れば、予約完了や前日リマインドをサービスメッセージとして送る選択肢も加わります。審査の要否と未認証・認証済みの機能差はLINEミニアプリとは？未認証と認証済みの違い・LIFFとの使い分け・審査と開発費用【2026年版】で比べています。

LINE予約システムのよくある質問：無料で作れる範囲と通知の扱い

LINE予約システムの自作について、2026年10月時点の公式ドキュメントをもとによくある質問に答えます。

LINE予約システムは無料で自作できますか？

LINEの部分は無料で始められます。LINE公式アカウントのコミュニケーションプランは月額0円で、プッシュメッセージを月200通まで送れます。LIFFの利用にも料金はかかりません。費用が出るのはサーバーとデータベース、開発と保守の工数です。予約1件で2通送るなら無料の範囲は月100件までなので、それを超えると月額5,000円のライトプランが必要になります。

LINE公式アカウントの友だちでない人も予約できますか？

予約画面には入れます。LIFFはLINEログインで動くため、友だち追加していなくても開けて、IDトークンも取れます。ただし友だちでない人やブロックした人にはプッシュメッセージが届かず、APIは200を返すので気付きにくい点に注意してください。LIFFの友だち追加オプションとliff.getFriendship()で状態を確かめ、メールなどの連絡先も受け取っておきます。

予約完了の通知はメッセージの通数に数えられますか？

プッシュメッセージで送る限り、数えられます。通数の対象はプッシュ・マルチキャスト・ブロードキャスト・ナローキャストで、対象外は応答メッセージだけです。予約者がトークに送ったメッセージへの返信として送れば対象外になりますが、LIFFの画面で予約を受ける構成では使えません。

LIFFで作った予約画面は外部ブラウザでも動きますか？

外部ブラウザでも動作可能です。LIFF URLをパソコンなどの外部ブラウザで開くと、liff.login()でLINEログインを経て同じ画面を使えます。liff.init()にwithLoginOnExternalBrowser: trueを渡すと、ログインを自動で始められます。画面を閉じるliff.closeWindow()は外部ブラウザでの動作が保証されていないため、完了画面を別に用意してください。

既存の予約システムにLINE通知だけを足すことはできますか？

できます。予約の登録や変更のタイミングで、既存のシステムからMessaging APIのプッシュを呼べば足ります。課題は、予約者とLINEのユーザーIDを結び付けることです。予約完了画面からLINEログインかLIFFを開いてもらい、IDトークンの検証で得たユーザーIDを予約者の行に保存します。会員IDとの紐付け方は、前出のLINE連携の記事で詳しく扱っています。

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

この記事に関連するサービス

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.10.07　テックブログ ファインズの不正アクセスと153万件の予約者情報｜予約システムを使う店舗の報告と通知の手順
  2. 2026.10.19　テックブログ コミックシーモア不正アクセスで会員情報流出：再開時期・パスワード再設定と運営側のログ点検
  3. 2026.10.16　テックブログ バーガーキング情報漏洩どうしたらいい？約1,118万件の対象確認・補償・退会とメールの真偽
  4. 2026.10.15　テックブログ 銀のさら不正アクセス：最大650万件の対象確認と窓口、パスワード変更・退会の手順
  5. 2026.10.15　テックブログ リゾートトラスト不正アクセス：会員2.6万件・カハラ横浜3.6万件の対象確認と窓口

RELATED POSTS 関連記事

一覧へ戻る

目次