---
title: "順番待ちシステムとは？機能・費用相場と選び方、LINE呼び出しの実装と開発判断を解説"
url: "https://www.issoh.co.jp/column/details/15370/"
published: 2026-07-19
updated: 2026-09-26
categories: ["Webシステム"]
publisher: "株式会社一創"
---

# 順番待ちシステムとは？機能・費用相場と選び方、LINE呼び出しの実装と開発判断を解説

店頭の記帳台に名前を書き、席や診察の順番を店内でひたすら待つ――この当日の待ち行列を、発券・待ち状況表示・呼び出し通知で置き換えるのが順番待ちシステムです。本記事では、受付から呼び出しまでの基本機能、マルチ機能型やLINEミニアプリ対応型など4タイプの分類、月額4,800円〜9,800円帯が中心となる費用相場までを扱う構成です。あわせて、発券機の要否や呼び出し方法といった比較の観点を、クリニック・飲食店など業種別の運用要件から解説します。自前で組む場合に必要な受付番号の採番とLINE呼び出しの実装例も示したうえで、既製のクラウドサービスで足りる条件と、電子カルテやPOSとの連携のために個別開発へ踏み込むべき条件を、発注側の視点で言い切ります。

## まとめ：順番待ちシステムは既製で始め、連携要件が出たら開発を検討

順番待ちシステムは「当日来た人の行列を管理する」仕組みであり、事前に日時を押さえる予約システムとは役割が別です。単独店舗で、受付と呼び出しの省力化だけが目的なら、月額1万円前後の既製クラウドサービスで足ります。選定時に比較すべきは、発券機・モニターの要否、SMS・LINEなど呼び出し方法の対応範囲、来店前のオンライン受付の有無の3つに絞られます。

費用は製品の月額だけでは決まりません。LINE呼び出しは上位プランに限られる製品が多く、LINE公式アカウントの通数やSMSの従量課金が別に積み上がるため、呼び出し件数から逆算した総額で比べてください。

一方、電子カルテ・POSレジ・自社会員基盤と待ち行列データをつなぎたい場合、既製サービスのプラン内では実現できないことが多く、API連携を含む個別開発が検討対象に入ります。判断の分岐条件は本文の判断章で具体的に示します。

## 順番待ちシステムの定義と基本機能、予約システムとの役割の違い

まず言葉の範囲を確定させます。「受付システム」「整理券アプリ」「呼び出しシステム」と呼ばれるものは、いずれもここで扱う順番待ちシステムの一部です。オフィスの来訪者取次や入館記録を自動化する仕組みは[受付システムの機能・料金相場と選び方](https://www.issoh.co.jp/column/details/15386/)で扱っており、当日行列の管理を担う本記事とは対象が分かれます。

### 店頭受付から整理券発行・呼び出しまでを自動化する仕組みの全体像

順番待ちシステムは、来店者の受付、待ち組数・待ち時間の表示、整理券（受付番号）の発行、順番が来たときの呼び出しという4つの工程を一続きで処理するソフトウェアです。来店者は店頭のタブレットや発券機、あるいは自分のスマートフォンから受付し、受付番号を受け取ります。店側は管理画面で待ち行列を一覧し、ボタン操作で次の番号を呼び出す流れになります。

紙の整理券と違い、受付データがそのまま記録として残る点が構造上の違いです。時間帯別の受付数や平均待ち時間が数値で取れるため、後述するシフト調整や混雑予測にもつながります。

### 日時指定の予約システムと当日ウェイティング管理との違い・併用の型

予約システムが「来店前に日時を確定させる」仕組みであるのに対し、順番待ちシステムは「当日来た人を先着順にさばく」仕組みです。管理する対象が予約枠か待ち行列かという点で、データ構造も画面も別物になります。両者の位置づけは[予約システムの主な機能・種類と開発判断の解説](https://www.issoh.co.jp/column/details/12829/)で整理しているとおり、置き換えではなく併用の関係です。

実際の店舗運用では「予約客と当日客の合流」が最初の設計課題になります。予約客を優先しつつ当日客の待ち時間を案内する、昼のピークだけ順番待ち受付に切り替える、といった併用パターンを先に決めてから製品を選ばないと、2つのシステムの案内が食い違い、店頭での説明コストがかえって増えます。

### 紙の記帳台や手書きリスト運用から置き換えたときの効果と残る限界

記帳台運用からの置き換えで消えるのは、名前の読み間違い・呼び忘れ・記帳順の割り込みトラブルです。来店者が店の外で待てるようになるため、店頭の滞留も減ります。スタッフ側は「今何組待ちか」を口頭で答える業務がなくなり、受付対応の中断が減る点が実務上は大きい効果です。

残る限界も明確にあります。呼び出しに応答しない来店者の扱い（何分で不在キャンセルにするか）、スマートフォンを持たない高齢層への案内は、システムを入れても運用ルールとして決める必要が残ります。高齢層が多い診療所では、紙の整理券印刷を併用できる製品を選ぶ判断が現実的です。

## 店舗・クリニックで使われる主要機能と呼び出し通知手段の対応範囲

製品パンフレットには多数の機能が並びますが、実務で差が付くのは受付方式・呼び出し通知・データ記録の3領域です。

### 発券機・タブレット・Webの3方式に分かれる受付と発券の方法

受付方式は大きく3つです。専用発券機を置く方式、汎用タブレットを受付端末にする方式、来店者のスマートフォンからWebやLINEで受け付ける方式で、多くの製品はこれらの組み合わせに対応します。

- 専用発券機：紙の整理券を印刷できる。高齢層比率が高い医療機関に向く一方、本体・保守のハード費用が別途かかる
- タブレット受付：市販のiPad等で済むため初期費用を抑えられる。紙発券にはプリンタ増設が必要
- Web・LINE受付：来店前に列に並べる「オンライン順番受付」に対応。機器不要だが、店頭に来た人向けの導線は別に要る

どの方式でも、受付時に人数・利用目的（診療科目やメニュー）を選ばせて振り分けられるかを確認しておくと、窓口が複数ある施設でも1台で運用できます。

### SMS・LINE・番号表示モニターによる呼び出し通知の使い分け

呼び出し手段は、店内モニターへの番号表示、SMS送信、LINE通知、Webページの自動更新表示が主流です。屋外や車内で待つ来店者にはSMSかLINEが届きやすく、店内待ちが中心ならモニター表示で足ります。SMSは送信ごとの従量費用が発生する製品があるため、月間の呼び出し件数が多い施設では通知単価まで見積もりに入れて比較する必要があります。

LINE通知はアプリのインストールが不要なミニアプリ形式が広がっており、友だち追加を入口にすることで再来店の案内にも接続できます。逆に、ビジネス街のランチ営業のように客がLINEを開かない場面もあるため、通知手段は客層で決めるのが正解です。

### 待ち時間データの記録と来店傾向分析への展開で得られる副次効果

受付ログには、曜日・時間帯別の受付数、平均待ち時間、呼び出しへの不応答率が残ります。このデータを使うと、混雑する時間帯に合わせたシフト配置や、待ち時間が伸びた日の原因特定が数値ベースで可能です。たとえば「土曜11時台だけ平均待ちが40分を超える」と分かれば、席数やスタッフ数ではなく受付の締め切り時刻を調整する、という具体的な打ち手につながります。

分析画面の粒度は製品ごとの差が大きい領域です。CSV出力だけの製品と、ダッシュボードまで備える製品が同じ価格帯に混在しているため、データを誰がどの頻度で見るかを決めてから比較すると選びやすくなります。

## 4つのタイプ分類と費用相場から見る順番待ちシステムの検討手順

比較サイトに掲載される製品は30本を超えますが、タイプで分ければ検討対象は数本に絞れます。

### マルチ機能・LINEミニアプリ・業種特化・Web完結の4タイプ比較

市場の製品は次の4タイプに大別できます。自店の客層と設備方針を先に決めれば、タイプの時点で候補が絞られます。

| タイプ         | 向く場面       | 特徴            |
| ----------- | ---------- | ------------- |
| マルチ機能タイプ    | 複数窓口・大規模施設 | 発券機・モニター連携に強い |
| LINEミニアプリ対応 | 若年層中心の店舗   | アプリ不要で通知まで完結  |
| 業種特化タイプ     | クリニック・調剤薬局 | 電子カルテ等と連携しやすい |
| Web完結タイプ    | 小規模・低予算の店舗 | ブラウザのみで導入が速い  |

迷ったらマルチ機能タイプ、と考えるのは早計です。窓口が1つの店舗にとって複数窓口対応は使わない機能であり、その分の月額を払い続けることになります。機能の多さではなく、自店で使う工程を過不足なく満たす最小のタイプを選ぶ方が運用は安定します。

### 月額料金と初期費用・発券機ハードの費用相場と見積もり時の注意点

クラウド型の公開料金は、主要比較サイト掲載製品で月額4,800円〜9,800円の帯が中心です（2026年7月時点の公開プラン。上位プランや要問い合わせの製品を除く）。初期費用は無料〜数万円の設定が多く、専用発券機やサーマルプリンタを置く場合はハード費用が別枠で加わります。

プランの刻み方は、製品ごとに異なる料金体系です。具体例として[Airウェイトの料金ページ](https://airregi.jp/wait/)では、2026年9月時点で簡易的な順番待ち管理ができる無料プラン、LINE呼出に対応するベーシック（月額11,000円・税込）、窓口ごとの呼出や外部モニターでの自動音声呼出に対応するスタンダード（月額22,000円・税込）の3段階が示され、初期費用0円・契約期間の縛りなしとされています。比較の決め手になるLINE呼び出しや複数窓口ほど上位プランに寄っているため、最安プランの月額ではなく、必要な機能を満たすプランの月額で比べると実態に合います。

見積もりで見落としやすいのは3点です。SMS通知の従量課金、店舗追加ごとの課金単位、そして契約期間の縛りです。特に多店舗展開を予定している場合、1店舗あたりの月額×店舗数で総額が既製サービスの想定を超えていくため、この時点で後述する個別開発との損益分岐を一度計算しておくと判断を誤りません。

## 導入前に確認する3つの比較観点と業種ごとに分かれる要件の違い

製品比較の軸は多く見えて、実際に決め手になる観点は限られています。

### 発券機とモニターの要否・呼び出し方法・オンライン受付の3観点

複数の比較サイトが共通して挙げる決め手は、発券機や外部モニターの有無、呼び出し方法の対応範囲、来店前オンライン受付への対応の3つです。この3観点は「どの客層が・どこで待ち・どう呼ばれるか」という運用そのものなので、ここが合わない製品は他の機能が良くても使い物になりません。

1. 客層を確認する：高齢層が多いなら紙発券とモニター表示は必須と考える
2. 待つ場所を決める：店外・車内待ちを許すならSMSかLINE通知が要る
3. 来店前受付の要否を決める：行列自体を減らしたいならオンライン受付対応が前提になる

この順で確認すると、カタログ上の機能一覧を全部読み込まなくても候補を2〜3本まで落とせます。無料トライアルはこの絞り込みの後に、実店舗のピーク時間帯で試すのが効率的です。

### クリニック・飲食店・調剤薬局で異なる当日運用の要件と選定の勘所

業種によって、順番待ちの中身は別物です。クリニックでは診察券番号との突き合わせや、検査後に列へ戻す「呼び戻し」ができるかが決め手になります。予約診療と当日受付が混在する運用の設計は[クリニック予約システムの予約方式・費用相場と機能の選び方](https://www.issoh.co.jp/column/details/15271/)で扱っているとおり、予約側の仕組みとセットで考える必要があります。

飲食店では席種（カウンター・テーブル）ごとの案内順制御と、グルメサイトの順番受付との二重管理をどう避けるかが論点です。この2点を含む飲食店固有の機能範囲・費用・連携の判断は[飲食店の順番待ちシステムの行列受付・LINE呼び出しと費用の選び方](https://www.issoh.co.jp/column/details/16093/)で個別に扱っている内容です。[飲食店予約システムのグルメサイト連携から見る自社開発の判断基準](https://www.issoh.co.jp/column/details/15275/)と同じく、既存の集客チャネルとの接続可否が製品選定を左右します。調剤薬局では処方箋の受付順と調剤完了のタイミングが一致しないため、「受付順＝呼び出し順」を前提にした製品では運用が崩れます。完了時に個別呼び出しできるかを必ず確認してください。

## 呼び出し通知を自前で組む場合の実装例、受付番号の採番とLINE送信の手順

既製サービスの管理画面の裏側で動いているのは、受付番号の採番・待ち組数の計算・通知送信という小さな処理の組み合わせです。連携開発を検討する段階では、この3つを自社側で持つと何が必要になるかを知っておくと、ベンダーの見積もりや提案の妥当性を判断しやすくなります。ここではPostgreSQLとLINE Messaging APIを例に、最小構成を示します。

### 受付番号の採番と待ち組数の算出をPostgreSQLで書く最小のテーブル設計

待ち行列は「店舗×営業日×受付番号」で一意になる1テーブルで表せます。状態を待機中・呼び出し済み・案内済み・不在の4つに絞ると、不在キャンセルの扱いも同じ列で管理できます。

```
-- 受付1件＝1行。店舗・営業日・番号の組で一意にする
CREATE TABLE queue_ticket (
  id            bigserial PRIMARY KEY,
  store_id      integer NOT NULL,
  business_date date    NOT NULL DEFAULT current_date,
  ticket_no     integer NOT NULL,
  party_size    integer NOT NULL,
  line_user_id  text,
  status        text    NOT NULL DEFAULT 'waiting'
                CHECK (status IN ('waiting', 'called', 'seated', 'no_show')),
  created_at    timestamptz NOT NULL DEFAULT now(),
  called_at     timestamptz,
  UNIQUE (store_id, business_date, ticket_no)
);

-- 発券：当日の最大番号＋1を払い出す（例は店舗1・2名）
INSERT INTO queue_ticket (store_id, ticket_no, party_size)
SELECT 1, COALESCE(MAX(ticket_no), 0) + 1, 2
FROM queue_ticket
WHERE store_id = 1 AND business_date = current_date
RETURNING ticket_no;

-- 受付番号12番の前に何組待っているか
SELECT count(*) FROM queue_ticket
WHERE store_id = 1 AND business_date = current_date
  AND status = 'waiting' AND ticket_no < 12;

-- 当日の平均待ち時間（呼び出し済みの受付だけで算出）
SELECT avg(called_at - created_at) FROM queue_ticket
WHERE store_id = 1 AND business_date = current_date
  AND called_at IS NOT NULL;
```

発券は2台の端末から同時に来ることがあり、同じ番号を払い出すとUNIQUE制約違反で片方が失敗します。失敗時にアプリ側で再実行するか、発券処理を店舗単位のロックで直列化する設計が要ります。既製サービスが当たり前にこなしているこの排他処理が、自前開発では最初の品質課題です。平均待ち時間の結果は、前述の来店傾向分析や「あと何分」の案内表示の元データになります。

### LINE Messaging APIのプッシュ送信で呼び出し通知を送るリクエスト例

呼び出し時にLINEへ通知する処理は、[LINE Messaging APIリファレンス](https://developers.line.biz/ja/reference/messaging-api/)に載っているプッシュメッセージのエンドポイント（`POST /v2/bot/message/push`）へリクエストを1回送る形で書けます。送信先には、受付時に取得して上のテーブルの line\_user\_id 列へ保存したユーザーIDを指定します。

```
curl -X POST https://api.line.me/v2/bot/message/push \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $LINE_CHANNEL_ACCESS_TOKEN" \
  -d '{
    "to": "受付時に保存したユーザーID",
    "messages": [
      {"type": "text", "text": "受付番号12番の方、まもなくご案内します。5分以内に店頭へお越しください。"}
    ]
  }'
```

見落としやすいのは費用の数え方です。プッシュ送信はLINE公式アカウントのメッセージ通数を消費します。[LINE公式アカウントの料金プラン](https://www.lycbiz.com/jp/service/line-official-account/plan/)では、2026年9月時点で無料のコミュニケーションプランが月200通、月額5,000円（税別）のライトプランが月5,000通までとされ、上限を超えて追加送信できるのは月額15,000円（税別）のスタンダードプランだけです（追加メッセージ料金は2026年10月1日に改定予定と告知）。1日40組を呼び出す店舗なら月1,200通前後になり、無料プランには収まりません。呼び出し1回を1通と数え、再呼び出しの分を上乗せして試算すると外れにくくなります。

### Web PushとLINEミニアプリで異なる通知の送信条件とiOS側の制約

友だち追加を求めずに通知したい場合の選択肢は2つあります。1つは[LINEミニアプリのサービスメッセージ](https://developers.line.biz/ja/docs/line-mini-app/develop/service-messages/)で、ユーザーの操作に対する確認・応答として、1回の操作につき最大5通まで送信が可能です。ただし認証済ミニアプリでしか使えず、テンプレートにはLINEヤフーの審査が入り、値下げやクーポンなど広告的な内容は禁止されています。順番待ちの「受付完了」「まもなく順番」は用途に合いますが、審査の期間を導入スケジュールに織り込む必要があります。

もう1つはブラウザの[Push API](https://developer.mozilla.org/ja/docs/Web/API/Push%5FAPI)を使うWeb Pushです。iPhoneは[iOS・iPadOS 16.4でWeb Pushに対応](https://webkit.org/blog/13878/web-push-for-web-apps-on-ios-and-ipados/)しましたが、対象はホーム画面に追加したWebアプリに限られます。店頭でQRコードを読んだだけの来店者にホーム画面への追加まで頼むのは無理があります。iPhone比率が高い客層では、Web Pushを呼び出しの主手段にしない判断が妥当です。受付ページの自動更新表示とSMSで補う構成の方が、呼び出しの取りこぼしは少なくなります。

## 既製の順番待ちシステムで足りる場面と受託開発に踏み込む場面の判断

ここからが本記事の結論部です。既製サービスと個別開発の分岐条件を、費用と連携要件の両面から言い切ります。

### 月額1万円前後の既製サービスで十分に賄える店舗運用の条件整理

次の条件がすべて当てはまるなら、個別開発は過剰投資です。既製のクラウドサービスを選んでください。単独または数店舗の運営で、待ち行列の管理と呼び出しの省力化が目的の中心であり、他システムとのデータ連携が「あれば便利」の水準に留まる場合です。この条件下では、月額4,800円〜9,800円帯の既製サービスが初期投資ゼロに近い形で立ち上がり、開発では到達できない速度と価格で運用に乗ります。前章の排他処理や通知の審査対応を自社で抱える必要もありません。

既製で始めて、受付ログが1年分たまってから連携や独自機能の要否を再判断する、という段階的な進め方も成立します。待ち行列データはあとから移行しにくい資産ではないため、この領域では「まず既製で小さく始める」判断のリスクが小さいのです。

### 電子カルテ・POS・会員基盤との連携が要るときの開発という選択

分岐点は連携要件です。電子カルテの患者IDと受付番号を突き合わせたい、POSレジの会計完了を呼び出しトリガーにしたい、自社アプリの会員情報と待ち履歴を統合したい――こうした要件は既製サービスの標準プランでは実現できないか、できても連携先が特定製品に限定されます。複数拠点の待ち状況を本部で一元管理し、独自の優先順位ルール（会員ランク別の案内順など）を組み込む要件も同様です。

この段階では、順番待ち機能を単体で買うのではなく、予約・受付・顧客管理を含む業務システムの一部として設計する方が総コストを抑えられます。当社の[予約管理システム開発](https://www.issoh.co.jp/service/system/reservation/)は、予約枠管理と当日ウェイティング、外部システム連携を一体で設計する受託開発のサービスです。既製サービスの月額×店舗数×利用年数が開発費を上回る規模なら、個別開発が数年単位で安く付く計算になるため、5店舗超・3年以上の利用を見込む時点で一度試算する価値があります。

### 導入後に形骸化しやすい失敗パターンと避けるための要件定義の順序

導入したのに使われなくなる典型は2つあります。1つ目は、呼び出し不応答の扱いを決めずに導入し、不在客の再呼び出しで現場が混乱して紙運用に戻るパターンです。2つ目は、予約システムと順番待ちシステムを別々に入れ、店頭で「予約の方はこちら、当日の方はあちら」と案内が複線化して受付が詰まるパターンです。

避ける手順は明快で、製品選定の前に運用ルールを文書化することです。不在時の扱い（例：3回呼び出し後にキャンセル）、予約客と当日客の優先順、ピーク時の受付締め切り条件の3項目を先に決め、それを実現できる製品だけを比較します。機能一覧から入ると「できることが多い製品」に流れ、運用に合わない機能を持て余す結果になりがちです。

## よくある質問

順番待ちシステムの検討時に、実際の検索で多い疑問へ答えます。

### 順番待ちシステムは無料のアプリだけで運用できますか？

無料プランや無料アプリは存在しますが、受付件数の上限、通知手段の制限（SMS不可など）、広告表示といった制約が付きます。Airウェイトのように無料プランを持つ製品でも、LINE呼出やオンライン順番受付は有料プランの機能です。1日の受付が数十件を超える店舗や、呼び出し通知を確実に届けたい医療機関では、無料枠では運用が持たないケースが大半を占めます。トライアルとして無料版で受付フローを検証し、本運用は有料プランへ移行する使い方が現実的です。

### LINEだけで受付から呼び出しまで完結できますか？

LINEミニアプリ対応型の製品なら、友だち追加なし・アプリインストールなしで受付から呼び出し通知まで完結します。ただし店頭に来た人がその場で並ぶ導線には、QRコード掲示か受付端末が別途必要です。また高齢層などLINEを使わない客層には紙の整理券やモニター表示の併用が要るため、「LINEのみ」で全客層を覆える店舗は限られます。

### 予約システムとの併用はできますか？

併用が標準的な構成です。予約枠で来店の大半を確定させ、予約外の当日客を順番待ちで受けるのが典型的な分担になります。その際は予約客と当日客の優先ルールを先に決めてください。同一ベンダーで予約と順番待ちの両機能を持つ製品を選ぶか、開発でデータを統合すると、店頭案内が一本化できます。

### 発券機は必ず必要ですか？

必須ではありません。タブレット受付＋スマートフォン通知だけで運用する店舗も多くあります。判断基準は客層で、高齢層比率が高い施設では紙の整理券がないと受付が成立しにくいため、発券機かプリンタ連携のある製品が候補です。若年層中心なら発券機なしで初期費用を抑える構成が成り立ちます。

### 導入までの期間はどのくらいかかりますか？

Web完結型・タブレット型の既製サービスなら、申し込みから数日〜2週間程度で運用開始できる製品が中心です。専用発券機を設置する場合は機器手配と設置で1〜2か月を見ます。電子カルテやPOSとの連携を含む個別開発では、要件定義から数か月単位の期間になるため、繁忙期から逆算した計画が必要です。LINEミニアプリで通知する構成なら、認証とテンプレート審査の期間も加えてください。

## 関連記事

- [予約システムとは？機能・種類・費用と既製サービスで足りない場合の開発判断](https://www.issoh.co.jp/column/details/12829/)：事前予約側の仕組みと開発判断を整理したハブ記事です
- [クリニック予約システムとは？予約方式・費用相場と選び方、開発判断を解説](https://www.issoh.co.jp/column/details/15271/)：診療予約と当日受付の併用設計を扱っています
- [飲食店予約システムとは？機能・料金の選び方とグルメサイト連携から見る自社開発の判断基準](https://www.issoh.co.jp/column/details/15275/)：飲食店の予約・ウェイティング両面の選定軸です
- [歯科医院予約システムとは？機能・費用とリコール・開発判断を解説](https://www.issoh.co.jp/column/details/15285/)：歯科特有の予約・受付運用を解説しています
- [美容室予約システムとは？機能・料金の選び方と既製サービスで足りない場合の開発判断](https://www.issoh.co.jp/column/details/15205/)：サロン業態の予約管理の選び方です

---

出典: [順番待ちシステムとは？機能・費用相場と選び方、LINE呼び出しの実装と開発判断を解説](<https://www.issoh.co.jp/column/details/15370/>)（株式会社一創）