整理券発行システムの発注は、受付業務を整理し、方式を比べ、RFPで条件を示し、試験導入を経て本番へ進めると、現場に合う運用につながります。発注形態や費用、委託先の選び方も、この流れの中で決めていきます。
▼全体ガイドの記事
・整理券発行システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
整理券発行システムの発注・外注で決める内容
発注では、発券機だけを購入するか、受付から呼出・分析までを備えた業務システムを導入するかを、まず決めます。
費用や期間は、来訪者数だけでなく、ピーク受付数や窓口数、通知方法によって変わります。
個人情報の有無や既存システムとの連携範囲も、費用と期間に関わります。
整理券発行システムの範囲の定義
整理券発行システムは、受付順や予約順に番号を付け、順番を管理して呼出状況を伝える仕組みです。
- スタンドアロン型：紙の番号札と音声呼出による運用
- クラウド型：タブレットとプリンターを使う運用
- SaaS：WebやLINEからの受付
- 個別開発型：予約・抽選・決済・顧客管理まで組み込んだ構成
「整理券を出したい」とだけ伝えると、ベンダーごとに見積もりの前提が食い違います。そのため、発券や窓口別の呼出、待ち時間表示、再呼出を業務でどう使うかを先に決めます。保留・キャンセル・集計、権限管理・外部連携についても、業務に沿って範囲を決めます。
発注先に最初に伝える判断材料
見積もりの前提をそろえるには、受付規模や現場条件を先に整理しておく必要があります。最低限、1日あたりの平均受付数とピーク受付数は、発注先に示せるようにしておきます。
- 受付規模：平均・ピーク受付数、営業日、営業時間
- 窓口・待機場所：窓口や診療科の数、利用者が待つ場所
- 利用者と通知：スマートフォンを使わない人の割合、通知手段
- 例外と代替運用：再呼出、二重発券、順番変更、通信断、停電、用紙切れへの対応
医療や自治体で氏名・電話番号・予約情報を扱うなら、個人情報の扱いも発注条件に含めます。保存する情報と期間、閲覧担当者、操作ログを具体的に決め、委託先・再委託先も条件に入れます。
番号と時刻だけで運用する場合は、費用とセキュリティリスクを抑えられます。
整理券発行システムの発注形態の選び方
発注形態は、既製SaaSから機器・クラウド、機能追加を経てフルスクラッチへ進むほど、自由度と責任が広がります。つまり、自由度が高いほど、発注側が引き受ける責任も大きくなります。そこで、譲れない条件を満たす方式から候補を絞り、導入期間と運用負担を比べます。
既製SaaS・発券機を選ぶケース
1店舗・1窓口で、発券と待ち組数の表示、番号呼出、簡単な集計ができれば足りる場合は、既製サービスが候補になります。
- Airウェイト：無料プランと機能別の有料プラン
- CQ-S257系：単体発券とクラウド運用のどちらも選べる
- 総額確認：周辺機器や設置・保守費も含めて見積もる
Airウェイトの有料プランは、ベーシックが月額11,000円（税込）、スタンダードが月額22,000円（税込）です。
オンライン受付、外部ディスプレイ、窓口別呼出は段階的に追加されます（出典: 株式会社リクルート「Airウェイト 有料プランについて」、2026年8月確認）。
シチズン・システムズのCQ-S257系には、ネットワークなしで発券する構成と、スマートフォンやモニターで順番を確認するクラウド構成があります。
公式仕様では、月額使用料が無料の機種と、月額3,300円（税込）のクラウド機種が示されています。
シチズン・システムズでは、検討者向けに2週間の無料デモ機の貸出も案内されています（出典: シチズン・システムズ株式会社「整理券システム」、2026年8月確認）。
ただし、端末本体やプリンター、モニターは別途見積もる必要があります。設置、通信、保守の費用も確認の対象です。
Web・LINE受付型を選ぶケース
店外での受付や待ち時間の活用、通知による離脱の低減を狙う場合は、Web・LINE型を候補にします。
- 店外受付：WebやLINEで受付できる導線の用意
- 利用者対応：紙・電話・スタッフ受付との組み合わせ
matocaはLINEミニアプリです。
店頭タブレット、スタッフ発券、QRコードからの店外発券に対応します。
公式サイトには、導入企業380社超、導入店舗2,200店突破と掲載されています（出典: 株式会社ブレイブテクノロジー「matoca」、2026年8月確認）。
高齢者や外国人、端末を持たない人も受付できるように、利用者層に応じて受付の導線を複数用意します。
個別開発・フルスクラッチを選ぶケース
既製サービスで業務要件を満たせない場合は、個別開発を検討します。
- 連携：既存システムとの接続が必要な場合
- 独自業務：標準機能で扱えない呼出順や受付の実現
- 開発範囲：既製品にない連携や業務機能への絞り込み
対象となる既存システムは、電子カルテや予約、POSなどです。会計や施設サイネージ、会員基盤も含まれます。
診療科ごとの呼出順や、整理券と時間予約を同じ窓口で扱う要件も、追加開発の対象になりやすいです。
イベントでのランダム発番や抽選も、追加開発に回りやすい要件です。
独自機能を増やすほど、発注者側の負担が大きくなります。要件定義やテストに加え、障害対応や将来の改修も、発注者側で見込んでおく必要があります。
競争優位に直結しない機能は作り込まず、既製品で実現できる部分を残すハイブリッド方式も有効です。
整理券発行システムの発注・外注の進め方
発注先に任せきりにせず、業務目的と受入基準を自社で決めておくと、納品後に使われない事態を防ぎやすくなります。
- 発注先へ相談する
- 現場を調査する
- RFPを提示する
- 提案と見積もりを比較する
- 契約する
- 要件定義を行う
- 設計・設定、テスト、教育を進める
- 本番導入する
- 運用を改善する
現場観察と目的設定の先行
現場観察では、混雑する曜日・時間帯と、来訪からキャンセルまでの流れを記録します。
- 業務の記録：受付、発券、待機、呼出、対応完了を追う
- 課題の把握：紙の記録、口頭の例外、利用者の問い合わせ
- 効果測定：処理時間、不在率、待合人数、電話件数の確認
現場観察をすると、機能一覧だけでは見えない要件が分かります。
目的は、「行列をなくす」といった言い方のままでは測れないため、待ち時間の可視化や問い合わせ削減など、測れる言葉で決めます。
導入後は、ピーク時の受付処理時間と待合場所の人数で効果を確認します。
呼出後の不在率や電話問い合わせ件数も、あわせて見ておきます。
小規模PoCと受入基準の設定
全拠点へ一括で導入する前に、まず1窓口・1店舗で試します。通常日と繁忙日の両方で、運用を確かめます。
- 利用者の操作：自分で発券し、番号呼出を聞き取れるか
- スタッフの操作：用紙補充や再発券に迷わないか
- 障害時の運用：通信断の際に紙運用へ戻せるか
受入基準は、画面表示だけでなく業務の結果で定めます。たとえば、ピーク時の同時接続数や一定時間後の保留状況、担当者・時刻のログを基準にできます。未処理番号の手作業での復元も、基準に含められます。
教育・本番移行・改善を含む発注範囲
スタッフが必要な操作を使えないと、現場が紙運用へ戻る可能性があります。
- 操作教育：呼出、保留、取消、再発券の研修
- 本番移行：マニュアル、問い合わせ窓口、繁忙日の立ち会いの決定
- 運用改善：変更依頼の受付、回答期限、見積承認の取り決め
旧運用との並行期間と障害時の連絡先は、契約前に確かめておきます。
本番後の改善では、初期契約の保守範囲と追加開発の扱いを分けて考えます。
通知文や窓口設定の変更と、データ構造・外部連携の変更では工数が異なります。そのため、変更範囲を分けておくと運用が安定します。
RFPと要件整理に書く内容
RFPは、発注先に示す依頼書です。
書く内容は、課題、対象業務、利用者から始めます。
そのうえで、機能・非機能要件と連携を示します。導入条件と、提案・見積の回答形式も書きます。画面仕様は先に固定せず、現状と目標を示して、複数の方式を比べられる余地を残します。
業務フローと例外処理の記載
RFPには、受付場所と入力内容、待機場所を記載します。また、呼出の時期と手段も書きます。受付順と予約順の優先順位、複数窓口への振り分け、再呼出回数は、具体的なシナリオで示します。
遅刻や不在、キャンセルの扱いを決めます。重複発券の扱いも含め、通常時以外の条件も整理しておく必要があります。
- 機器・回線：用紙切れ、タブレット故障、インターネット断、電源断を想定
- 受付・人員：想定を超える来訪やスタッフの交代
- 復旧方法：自動復旧、管理者の手動復旧、紙運用からの記録復元を発注先に提案してもらう
優先度を付けた機能要件の分類
機能要件は、必須のMUST、できれば欲しいSHOULD、将来検討のCOULDに分けます。
- MUST：発券や番号管理、呼出、保留・取消、現地発券
- 追加機能：Web受付、LINE通知、予約、抽選、決済、会員連携、詳細分析の優先順位を、業種と目的で決める
- 仕様記述：担当者、時点、入力、処理、記録内容を明記
たとえば、受付担当が診療科を選び、受付番号と時刻を保存して、患者には番号だけを表示します。この形にすると、画面とデータ、権限、プライバシーを一緒に検討できます。
非機能要件・連携・運用条件の明記
RFPには、性能と稼働、保守を明記します。連携と個人情報の扱いも書き添えます。
- 性能・稼働：同時受付数、応答時間、稼働時間、バックアップ、復旧目標
- 保守・対応：受付時間、対応言語、アクセシビリティ
- 連携・情報管理：データ連携仕様と個人情報の管理条件
イベントでは、販売開始や開場直後の最大負荷を前提にします。
API連携では、システム名とデータ項目を定めます。連携方向と頻度、再送方法、認証方式も示します。
個人情報を扱う場合は、利用目的や保存期間、権限を確認します。そのうえで、操作ログや委託先・再委託先を決めます。国外保管と削除手順も、条件に入れます。
安全管理措置の参照には、個人情報保護委員会の通則編ガイドラインが役立ちます。個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」を2026年8月に確認しました。
発注条件と照らし合わせ、内容を契約と運用に反映します。
請負と準委任の契約形態の選び方
請負は成果物と完成条件を定め、準委任は作業時間や専門知識の提供を重視します。
どちらかが正解とは限りません。そこで、要件が固まった部分と検証する部分を分けて契約します。
請負契約の成果物と検収の明確化
請負契約では成果物を定め、発注者の検収を経て対価を支払います。
- 成果物：要件定義書、画面、プログラム、試験結果、操作マニュアル
- 検収条件：受入試験、性能、権限、ログ、バックアップ、復旧
- 契約後の対応：不具合修正、瑕疵対応、外部サービス障害の責任の確認
既製サービスの初期設定や、仕様が確定した発券・呼出機能に向く契約です。ただし、要件変更が頻発すると、追加費用や納期変更が生じやすくなります。
検収の時点でスタッフ研修の完了も確認しておくと、納品後の運用準備を確かめられます。
準委任契約が向く検証と伴走
準委任契約では、一定期間の専門作業を、発注者と外注先が協力して進めます。
- 対象作業：要件整理、設計、技術調査、進行管理、運用改善
- 向く場面：複数現場の調査、連携可否の検証、PoC後の本開発判断
- 契約条件：作業範囲、担当者、時間、会議、報告、評価方法
準委任契約は、成果物の完成を無条件に保証する契約ではありません。また、現場を見ながら最適な発券方法を探す段階にも向いています。
発注者側にも、意思決定者と現場代表を置きます。確認を先送りしないことが、期間超過のリスクを抑えます。
要件定義と開発を分けた契約の組み合わせ
要件定義・PoCは準委任、仕様が固まった開発は請負、運用保守は別契約にする方法が現実的です。
- 成果物の引継ぎ：要件定義の内容を次工程へ渡す方法
- 責任と権利：責任分界、データ・ソースコードの権利
- 費用内訳：作業別に固定費、従量費、追加変更費の確認
運用保守を別契約にする場合は、契約終了時の引き渡し方法も明記します。
「一式」とだけ書かれた見積もりでは、契約形態や内訳が分かりません。そのため、要件定義や設計、開発・設定、機器の項目ごとに内訳を見ます。
連携や試験、移行の項目も、分けて見ます。研修と保守の内訳も見ます。
整理券発行システムの費用相場の目安
費用は簡易発券なら初期数万円から数十万円、クラウド型は月額数千円から数万円です。
連携や個別開発では数百万円から数千万円です。この数字は、公開料金と類似業務システムから整理した目安で、整理券専用開発の確定価格ではありません。
小規模な既製導入の総額での見積もり
小規模導入では、使う機器や通知方法を含めて、初期費用と月額を見積もります。
- 既存タブレット：1窓口の発券・呼出なら初期0万〜20万円程度
- 機器追加：発券機やモニターを加えると初期20万〜100万円程度
- 運用費：月額、通信、通知、保守を含めた年間額の確認
初期0万〜20万円程度には、設定やプリンター、用紙が含まれます。掲示物も、この額に入ります。月額の目安は0円〜2.2万円程度です。
機器追加の金額には、設置やネットワークを含めて比べます。ただし、無料プランでも関連費用は別になる場合があります。
タブレットやプリンター、モニターの費用を確認します。通信回線と用紙、設置の費用も見ます。故障交換や電話サポートも、見積もりに入れます。
SMSや電話通知は従量課金になることがあります。そのため、月間受付数と通知数を掛け合わせ、年間総額を確認します。
連携・カスタマイズの費用の目安（100万〜800万円程度）
小〜中規模の連携は、対象システム数や拠点、試験・移行の範囲で費用が変わります。
- 小〜中規模連携：100万〜800万円程度の推定
- 複数施設・機能追加：300万〜1,500万円程度を見込む
- 見積確認：仕様確認、エラー処理、権限、総合試験を含める
POSや予約、CRMとの連携を想定します。電子カルテや自治体窓口管理との連携も想定します。
この数字は、整理券側のAPI開発、個人情報、複数拠点を含む試算です。テストと移行も含めて見ています。公開統計ではなく、NotebookLMで確認した類似業務システムの相場と、連携・運用工数を基にしています。
複数施設・複数部門で予約枠や抽選、決済を作り、会員連携や分析ダッシュボードまで加える場合の目安です。
連携先が増えるほど、費用も増えます。相手側の仕様確認やエラー処理が、その分必要になります。権限や総合テストの費用も、連携先の数に応じて増えるためです。
スクラッチ開発の800万〜5,000万円以上の想定
スクラッチ開発の費用と期間は、規模や連携・負荷要件によって幅があります。
- 小規模な専用受付：800万〜2,000万円の推定
- 複数拠点など：外部連携や高負荷イベント対応を含め、2,000万〜5,000万円以上の推定
- 要件の分類：既製、設定、追加開発、新規開発に分ける
開発期間は4〜18か月程度です。
整理券専用の相場ではなく、類似業務システムやPOSの規模を基にした試算です。
費用レンジは予算を決める断定値ではなく、既製品で置き換えられない要件を抜き出す材料として使います。分類ごとに、初期費用と月額を分けて見積もってもらいます。保守費と将来変更費も、別に示してもらいます。
委託先の選定と見積比較の観点
委託先は、会社名や機能数だけで決めません。類似業種や受付規模の経験、障害時の支援で評価します。連携実績や提案の透明性も見ます。
候補には、開発会社や機器メーカーのほか、SaaS事業者、導入支援会社があります。また、自社と外部委託の範囲も確認します。
導入実績と現場支援の質の確認
導入実績では、社数だけでなく、自社の業務規模や例外処理への適合を確かめます。
- 現場規模：ピーク受付数、窓口数、複数部門、外部連携を尋ねる
- 業種別の対応：その業種特有の運用例
- 支援体制：訪問、電話、休日対応、代替機の条件
紙とスマートフォンを併用するケースや、障害時の運用も確認します。
EPARKの法人情報では、店頭発券後の待ち状況の確認や、不在者の保留・再呼出が紹介されています（出典: 株式会社EPARK「順番待ちシステム」、2026年8月確認）。
必要な例外処理が実際に運用されているか、画面デモと導入事例の両方で確かめます。
医療では番号案内、自治体では窓口・言語・申請種類、イベントでは集中アクセスや抽選を確認します。
同じ条件での見積書の比較
候補を2〜3社に絞り、同じRFPで提案を依頼します。受付数や窓口数、通知条件も、そろえて伝えます。
- 見積内訳：初期、月額、従量、機器、移行、連携、試験、教育を分ける
- 追加費用：保守、変更、通知、繁忙期対応の条件
- 総額比較：初年度と3年間を、価格・適合性・継続性の観点で比べる
解約時のデータ返却も、比較項目に含めます。
「導入費一式」「保守一式」と書かれた場合は、作業内容と数量を尋ねます。
安い見積もりには、要件抜け、連携の別料金、繁忙期の性能増強費が含まれないことがあります。また、SMS・電話通知の従量費も確認します。
問い合わせ受付時間や障害時の代替運用も、見積もりに含まれるか確認します。
初年度総額と3年間の総保有コストを並べ、価格・適合性・継続性の3つの観点で評価します。
評価項目と失注・失敗リスクの点数化
必須要件への適合を最優先にし、候補を複数の観点で評価します。
- 適合性：必須要件と現場の使いやすさ
- 導入・費用：連携、セキュリティ、期間、初期・運用費の比較
- リスク対応：障害、個人情報、データ移行の対策
価格を重視しすぎると、使いにくさから紙で二重管理するリスクを見落とします。
候補会社には、スマートフォンを使わない人への対応や、通信障害への対応を尋ねます。番号重複や呼出不在への対応も確認します。
個人情報漏えい、データ返却、ベンダー変更時の移行も確認します。
回答が契約書やSLAに反映されるかも見ます。
発注後の失敗を防ぐための備え
発注後は、要件や現場教育の不足、通知手段の偏りが失敗につながります。例外処理が決まっていないことや、保守範囲の誤解も、失敗の原因になります。
行列の解消には、システム導入に加えて、受付ルールや人員配置を整える必要があります。案内表示や利用者への説明も、準備しておきます。
通信断・停電・機器故障への備え
クラウド型でも、オンラインに頼りきると、通信障害が数十分続くだけで業務停止につながります。
- 代替記録：紙の番号札、手書きの呼出記録、復旧後の再入力方法
- 利用者案内：障害時の案内文と掲示方法
- 予備品と訓練：予備プリンターや用紙の保管場所、年に数回の訓練
端末故障時の代替機手配担当、復旧目標時間、復元データを確認します。
バックアップ頻度・保存期間と復元テストの実施有無を聞きます。
口頭の約束はSLAや保守契約に記載します。
番号運用と個人情報の扱いの現場への浸透
番号呼出では、表示・音声案内の情報と本人確認の手順をそろえます。
- 表示の統一：券面、モニター、通知、窓口画面をそろえる
- 情報管理：権限共有や私物端末への転送を避け、不要な保存をしない
- 定期確認：ログと権限の見直し、異動・委託終了時のアカウント停止
氏名を表示・音声案内しない番号呼出は、プライバシーに配慮できます。
番号を誤ると、別の利用者を案内する事故になります。そのため、本人確認が必要な場面と、番号だけで進める場面を分けます。
スタッフには、問い合わせ時の本人確認を研修します。
整理券発行システムの発注・外注に関するよくある質問
発注前によくある疑問に、費用、開発方法、運用の観点から答えます。金額と仕様は、2026年8月に確認した情報とリサーチノートに基づく目安です。最新の金額は、候補先の見積もりで確かめてください。
整理券発行システムは無料で導入できますか？
無料プランや月額無料の発券機でも、端末やプリンター、用紙は別料金の場合があります。通信や設置、通知、保守も、別料金になることがあります。
小規模なら、無料または月額数千円から始められる場合があります。3年間の機器・運用費を合算して判断します。
整理券発行システムはスクラッチ開発すべきですか？
既製品で業務ルールや複数連携を満たせず、独自性や高負荷イベントへの対応も必要な場合は、スクラッチ開発を検討します。
発券・呼出・通知だけなら既製品を使い、連携部分だけ追加開発すると、初期費用と保守負担を抑えやすくなります。
高齢者やスマートフォンを使わない人にも対応できますか？
対応できます。店頭発券機と紙の番号札を残し、スタッフによる代行発券にも対応します。番号表示や音声案内も用意します。
WebやLINEを主導線にする場合も、受付方法を選べるようにします。文字サイズ、言語、案内文は、実際の利用者に試してもらいます。
既存の予約・POS・電子カルテと連携できますか？
相手システムの仕様と契約条件が合えば、APIやファイル連携で接続できます。
RFPには、データ項目と連携方向・頻度を示します。認証やエラー時の再送、個人情報の扱いも書きます。
候補先には、標準機能と設定、追加開発、連携不可を分けて回答してもらいます。そのため、見積もりの差の理由が分かります。
整理券発行システムの発注・外注方法のまとめ
外注では、誰の待ち時間を、どの業務で、どの指標により改善するかを決めます。
既製SaaSや発券機、Web・LINE型、個別開発を比べ、MUST要件を満たす方式から選びます。
RFPと見積比較による発注条件の統一
RFPには、業務フローと例外処理、ピーク受付数、窓口数を記載します。通知方法や個人情報の扱いも書き、連携と障害時の代替運用まで含めます。
受入基準も明記し、候補先に同じ条件で提案を依頼します。初期費用だけでなく、月額や従量課金も比べます。
機器や保守、追加開発、解約時のデータ返却まで比べると、導入後の費用も見通せます。
導入後の運用と契約の確認による決定
導入後の運用リスクと契約範囲を確認し、発注先を決めます。
- 契約：確定要件は請負、検証・伴走は準委任の検討
- 運用体制：障害、用紙切れ、呼出不在、権限、保守窓口の確認
- 見積比較：初年度・3年間の総額、適合、支援、責任範囲の比較
受付業務と将来の拡張方針を整理し、同一条件の見積もりを2〜3社から取ります。
運用条件の確認は、本番前に終えておきます。
▼全体ガイドの記事
・整理券発行システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。