ERP

セルフオーダーシステムとは?卓上端末型とQR型の違いとPOS連携・多言語対応の要件

AI画像認識ソフトウェアの応用範囲

セルフオーダーシステムは、客が自分の手で注文を確定させ、その注文がテーブル番号ごとの伝票として厨房とPOSへ流れる仕組みです。導入相談で先に詰まるのは機種選びではありません。会計を最後にまとめるのか注文ごとに払うのか、商品マスタをPOSと注文側のどちらで持つのか、という設計の判断です。この記事では、卓上端末型とQR型の構造の違い、POS・キッチンプリンターとつなぐときの連携の粒度、アレルゲン・酒類・軽減税率を画面にどう組み込むかを一次情報つきで整理します。小売や宿泊での使い方と、既製品で足りる店・個別開発に進む店の線引きまで書きます。

まとめ:セルフオーダーシステムは端末より会計方式とPOS連携の粒度で決める

卓上端末型かQR型かは、客層と席数でほぼ決まります。端末を店が持つか、客のスマホを借りるかの違いです。迷うべきなのはその先にある2つの設計で、ここを決めないまま製品を選ぶと、導入後に運用でつじつまを合わせることになります。

1つ目は会計方式です。食べ終わってからまとめて払う後会計なら、注文はテーブル伝票に積み上がりPOSで締めます。注文ごとに払う都度決済なら、注文側が決済まで受け持ち、POSは売上を受け取るだけになります。2つ目はPOS連携の粒度で、商品マスタ・売り切れ・オプションをどちらが正とするかを1つに決めることです。

画面には法令と表示の要件も入ります。2026年4月に9品目となった特定原材料の情報、酒類注文時の年齢確認、店内飲食と持ち帰りの税率を分ける意思確認の3点は、既製品の設定項目にあるかを契約前に確かめてください。既製品の標準機能でこれらが満たせ、POSも対応機種なら個別開発は不要です。業態固有の注文工程があるとき、あるいは小売や宿泊のように飲食店の前提が合わないときに限り、開発を検討します。

セルフオーダーシステムの定義とハンディやモバイルオーダーとの守備範囲の境目

客が自分で注文を確定させてテーブル番号で伝票へひもづける流れ

セルフオーダーの中核は、注文の確定ボタンを店員ではなく客が押すことです。押された注文には席を特定する情報が付き、その席の伝票へ追記されます。同時にキッチンプリンターやキッチンモニターへ調理指示が出て、ドリンクと料理で出力先を分ける設定もここで効きます。

店員が端末で注文を取るハンディは、確定ボタンを押すのが店員という一点で別物です。ハンディは聞き取りの手間が残るかわりに、おすすめの声かけや提供順の調整ができます。飲食店の注文方式4つを費用込みで比べる話は飲食店のオーダーシステムの種類と料金比較に譲り、本記事では客が確定させる方式の設計に絞ります。

店外から事前に注文するモバイルオーダーと店内セルフオーダーの線引き

言葉が混ざりやすいのがモバイルオーダーです。客のスマホを使う点はQR型のセルフオーダーと同じでも、来店前に注文と決済を済ませ、店では受け取るだけという使い方を指すことが多いです。席がまだ決まっていないので、伝票は席でなく注文番号にひもづきます。

線引きの基準は「注文時点で席が決まっているか」です。決まっていればセルフオーダー、決まっていなければ事前注文型のモバイルオーダー。同じ製品が両方を受け持つことも多いものの、伝票のひもづけ先と会計のタイミングが違うため、要件定義では別の機能として扱ってください。

卓上端末型とQR型で変わる端末管理と会計方式・いたずら注文への備え

店が端末を持つ卓上端末型で発生する充電・破損・更新の運用負担

卓上端末型は、各テーブルに店のタブレットを置く方式です。操作に迷う客が少なく、写真を大きく見せられるので追加注文が出やすい。代わりに、端末の管理が毎日の作業として店に残ります。

営業後の充電、落下や飲み物による破損、OSとアプリの更新、置き忘れや持ち去りへの備えがそれです。30卓の店なら30台を毎晩充電台に戻し、翌朝すべてが起動するかを確かめることになります。端末を固定するスタンドやケーブル盗難防止具の費用も見込んでください。客のスマホを使えない高齢の客が多い店や、写真で選ぶメニューが中心の店では、この負担を払ってでも卓上端末型を選ぶ価値があります。

客のスマホで注文するQR型の固定QRと来店ごとに発行するQRの差

QR型は、テーブルのQRコードを客が読み取り、ブラウザやLINEミニアプリで注文する方式です。端末費がかからない一方、QRコードの発行方式で安全性が大きく変わります。

テーブルに印刷した固定QRは、写真を撮れば店外からでも同じ画面を開けます。退店後や来店前に注文が入る、いわゆるいたずら注文の入口になるのはここです。対策は、来店時に受付やPOSで席ごとのQRを発行し、会計と同時にそのQRを失効させる方式です。固定QRを使うなら、初回注文をスタッフが承認してから厨房へ流す設定を入れるか、注文できる時間を着席中に限る仕組みが必要になります。製品比較では、QRを来店ごとに発行できるかを最初に確かめてください。

後会計と都度決済の2つの会計方式で変わるテーブル伝票とPOSの役割

後会計は、注文を伝票に積み上げ、退店時にレジやテーブルでまとめて払う方式です。POSが伝票を締めるので、既存のレジ運用をほぼそのまま残せます。客がQR画面で会計まで済ませる「セルフ会計」を足すと、レジ待ちも減ります。小売店のように会計そのものを客に任せる方式はセルフレジのフルセルフとセミセルフの違いで整理しています。

都度決済は、注文ごとに客がスマホで支払う方式です。食い逃げや会計漏れが原理的に起きず、レジ要員も不要になります。ただし注文側が決済サービスとつながるため、POSは売上と決済結果を受け取る側に回ります。返金や注文取り消しをどちらのシステムで処理するかを決めておかないと、締め作業で売上と入金が合わなくなるので、処理先は導入前に決めておくこと。追加注文が多い居酒屋は後会計、1回の注文で完結するカフェやフードコートは都度決済が合います。

卓上端末型とQR型を端末費・運用・客層・会計で並べた比較の一覧

ここまでの違いを、導入判断で比べる5つの観点で並べます。費用の実額は製品と台数で大きく変わるため、相場は店舗管理システム・POSレジの費用相場で確認してください。

観点 卓上端末型 QR型
端末の費用 席数分のタブレットが必要 客のスマホを使い店側はほぼ不要
日々の運用 充電・破損対応・更新が毎日発生 QRの発行と失効の管理が中心
向く客層 高齢層・家族連れ・写真で選ぶ客 スマホ操作に慣れた若年層・訪日客
会計方式 後会計が中心 後会計と都度決済の両方に対応しやすい
いたずら注文 端末が店内にあるため起きにくい 固定QRでは店外から注文される余地あり

QR型が安く見えるのは端末費だけを見たときです。来店ごとのQR発行を受付で回す人手と、スマホの電池切れや通信不良で注文できない客への代替手段を含めて比べてください。

POS・キッチンプリンター・決済とつなぐときに要件定義で決める連携の粒度

POS側のAPIで注文を受ける方式とスマレジのWaiter APIの守備範囲

セルフオーダーとPOSの連携には、同じ会社の製品どうしでつなぐ方式と、POS側が公開するAPIで別会社の注文システムをつなぐ方式があります。前者は設定だけで動くかわりに組み合わせが固定され、後者は選択肢が広がるかわりに連携の範囲を自分で確かめる必要があります。

POS側のAPIの例として、スマレジは開発者向けにスマレジ Developersを設け、POS API・在庫管理API・受注管理APIと並んで、オーダーエントリーシステム連携用のWaiter APIを公開しています。仕様はスマレジ・プラットフォームAPIリファレンスで個別に確認できます。他社のセルフオーダーを入れる場合は、使っているPOSがこうしたAPIを持つか、注文・取消・テーブル移動・割り勘のどこまでがAPIで受けられるかを、製品資料ではなくリファレンスで確かめてください。POS本体の種類と役割はPOSシステムの仕組みと種類で整理しています。

商品マスタの持ち主を1つに決めて売り切れとオプションをそろえる条件

連携の不具合で最も多いのは、商品マスタが2か所にある状態です。POSで価格を変えたのに注文画面が古い値段のまま、厨房で売り切れにしたのにQR画面では注文できる、といったずれが起きます。

決めることは1つで、商品・価格・売り切れ・オプションの正をどちらのシステムに置くかです。POSを正にして注文側は読み取るだけにするのが基本形ですが、写真・説明文・多言語名・アレルゲン情報はPOSの商品マスタに項目が無いことが多く、注文側で持つことになります。この場合は商品コードを共通の鍵にして、価格と在庫はPOS、表示情報は注文側という分担を文書に残してください。飲食業態ごとにPOSへ求める機能は飲食店のPOSレジの業態別の必須機能にまとめています。

通信断や停電でも注文を止めないためのオフライン時の動作の取り決め

セルフオーダーは、店内のWi-Fiとクラウドの両方が動いて初めて注文が厨房に届きます。ピーク時間に回線が止まると、客は注文できず、店員は何が注文済みかを把握できません。

要件定義で決めるのは3点です。1つ目は、通信断の間に客の画面へ何を出すか。2つ目は、店内のサーバーや端末に注文を一時保存して、回線復旧後に送り直すかどうか。3つ目は、紙の伝票とハンディに切り替える手順を誰が判断するか。QR型は客のスマホ回線で注文が届くため店内Wi-Fiの停止には強い一方、クラウド側の障害には弱いという性質も踏まえてください。既製品なら障害時の動作を仕様書で確認し、個別開発なら一時保存と再送の設計を最初から入れておきます。

多言語・アレルゲン・酒類・軽減税率で注文画面に組み込む表示と法令の要件

多言語メニューと2026年4月に9品目となった特定原材料の持たせ方

多言語対応は翻訳の質より更新の運用で破綻します。新メニューを足すたびに英語・中国語・韓国語の名前と説明を誰が書くかが決まっていないと、日本語だけが新しい画面になります。言語ごとの名前を商品マスタの項目として持ち、未翻訳の商品は公開できない設定にしておくのが確実です。言語とURLの設計の考え方は多言語サイト制作の言語・URL設計と共通しています。

アレルゲン情報も同じ扱いです。食品表示法のアレルギー表示義務は容器包装された加工食品が対象で、店内で提供する料理は表示義務の外にあります。それでも消費者庁の外食・中食向けの取組は情報提供を進める方向で教材を出しています。消費者庁の食物アレルギー表示の情報によれば、2026年4月1日にカシューナッツが特定原材料に加わり、えび・かに・くるみ・小麦・そば・卵・乳・落花生と合わせて9品目になりました。品目を固定の列で持つと追加のたびに改修が要るため、品目を別表にして商品とひもづける作りにしておくと、次の追加にも設定だけで対応できます。

酒類の注文画面に入れる年齢確認と二十歳未満の飲酒を防ぐ提供時の措置

店員が注文を取るなら、酒類の注文時に客の様子を見て年齢を確かめられます。セルフオーダーでは、注文の時点で店員が客を見る場面そのものがありません。二十歳未満ノ者ノ飲酒ノ禁止ニ関スル法律は第1条第4項で、酒類を販売・供与する営業者に年齢の確認その他の必要な措置を講ずるよう定めています。

画面での実装は、酒類の初回注文時に「20歳以上ですか」の確認を出し、提供時に店員が目で確かめる二段構えが一般的です。確認ボタンだけで済ませず、酒類の注文が入った席をキッチンモニターや配膳担当の画面で目立たせ、提供する人が気づける作りにしてください。ファミリー層の多い店では、子どもが端末を触って酒類を注文する場面も想定しておきます。

店内飲食と持ち帰りの税率を注文時点の意思確認で分ける画面の流れ

テイクアウトも受ける店では、同じ商品でも税率が変わります。国税庁の区分経理と申告書作成の資料は、税込価格を同一にしている場合でも店内飲食は10%、持ち帰りは8%と適用税率が異なり、販売時点で顧客に意思確認を行うなどして区分経理する必要があると示しています。

店員がいない以上、意思確認は画面が受け持ちます。注文の最初に「店内で食べる」「持ち帰る」を選ばせ、その選択を注文データに残してPOSへ渡す流れです。後から持ち帰りに変える客のために、会計前に区分を変更できる操作も用意してください。区分のデータがPOSに届かない連携だと、税率の内訳が締めで合わなくなります。

飲食店以外の小売・宿泊・施設でセルフオーダーを使う場面と要件の違い

小売店の店頭注文で在庫の引当と受け取り場所を決める倉庫型の売り方

小売でのセルフオーダーは、売場に見本だけを置き、客が端末やQRで注文した商品をバックヤードから出す売り方です。家電・タイヤ・建材のように陳列できる量が限られる商材や、盗難が多い商品で使われます。

飲食店との違いは、注文の時点で在庫を確保する引当が必要になることです。注文が入ったのに在庫が無い、という状態は飲食の売り切れより客の不満が大きく、在庫システムとの連携が前提になります。受け取りがレジか専用カウンターか、配送かも注文データに含める項目です。POSと在庫の連携の考え方はPOSレジの在庫管理の連携の仕組みで、売場とバックヤードを含む店舗運営全体は店舗管理システムの機能の範囲で扱っています。

宿泊施設のルームサービスや施設の座席注文で精算時に必要になる連携先

宿泊施設では、客室のQRやテレビからルームサービスを注文し、代金を部屋付けにしてチェックアウト時にまとめて払う使い方が中心です。ここでは注文データの行き先がPOSではなく宿泊管理システム(PMS)になり、部屋番号と宿泊者を照合する連携が要ります。PMSの役割と連携の考え方はホテル管理システム(PMS)の機能と連携の判断基準を参照してください。

病院の売店や社員食堂、スタジアムや映画館の座席注文も同じ型です。席の代わりに座席番号・病室・社員番号で注文をひもづけ、提供場所へ届けるか受け取りに来てもらうかを決めます。社員食堂なら給与天引き、病院なら食事制限との照合が加わるなど、業種ごとの連携先が飲食店の既製品に用意されていないことが多く、個別開発の相談が多い領域です。

既製のセルフオーダーで足りる店と個別開発に進む店を分ける判断の条件

既製品で要件を満たせるかを確かめる5つの質問とQR型を見送る場面

既製品を選ぶ前に、次の5つを製品資料と担当者への質問で確かめてください。重要度の高い順に並べています。

  1. 今のPOSと連携でき、注文・取消・テーブル移動・割り勘がPOS側に正しく反映されるか
  2. QRを来店ごとに発行し、会計と同時に失効させられるか
  3. 店内飲食と持ち帰りの区分を注文データとしてPOSへ渡せるか
  4. アレルゲン品目と多言語名を商品ごとに持ち、未入力の商品を公開しない設定があるか
  5. 通信断のときに注文を一時保存するか、紙運用へ切り替える手順が示されているか

1と2のどちらかが満たせないなら、その製品は候補から外します。QR型そのものを見送るべき店もあります。客の多くが70代以上の店、1卓あたりの注文が1〜2回で終わる定食店、席数が10席未満で店員が全席を見渡せる店です。こうした店では注文を取る手間がもともと小さく、QRの発行と失効の管理が新しい仕事を増やすだけになります。

個別開発に進むときにPOS・厨房・決済の仕様を先に固める手順

個別開発に進むのは、業態固有の注文工程が既製品で表現できないとき、または宿泊・小売・社員食堂のように連携先が飲食店向けの既製品に無いときです。費用と月額の比べ方は飲食店のオーダーシステムの自作判断で計算手順を示しています。

開発に入る前に固める順番は、POS・厨房・決済の順です。まずPOSのAPIで受けられる操作の範囲を確定し、次にキッチンプリンターやキッチンモニターへの出力先の分け方、最後に後会計か都度決済かと返金の処理先を決めます。この3つが決まれば、画面はそれらの仕様に沿って設計すればよい段階です。一創では店舗アプリ開発として、セルフオーダーやモバイルオーダーをPOS・在庫・PMSとつなぐ開発をお受けしています。既製品で足りるかの見極めから相談いただけます。

よくある質問

セルフオーダーシステムの導入を検討するときに寄せられることの多い質問をまとめました。

セルフオーダーシステムとモバイルオーダーは何が違いますか?

注文時点で席が決まっているかどうかが違いです。セルフオーダーは店内の席で注文し、注文はテーブル番号で伝票にひもづきます。モバイルオーダーは来店前に注文と決済を済ませ、店では受け取るだけという使い方を指すことが多く、伝票は注文番号にひもづきます。同じ製品が両方を扱う場合でも、伝票のひもづけ先と会計のタイミングが違うため、要件は分けて決めてください。

QR型のセルフオーダーでいたずら注文を防ぐにはどうすればよいですか?

QRを来店ごとに発行し、会計と同時に失効させる方式を選ぶのが確実です。テーブルに印刷した固定QRは、写真を撮れば店外からでも注文画面を開けてしまいます。固定QRを使い続ける場合は、各席の初回注文をスタッフが承認してから厨房へ流す設定や、着席中の時間帯だけ注文を受け付ける設定を組み合わせてください。

今使っているPOSレジのままセルフオーダーだけ導入できますか?

POSが外部の注文システムとの連携に対応していれば可能です。POS会社が公開しているAPIや連携先一覧で、注文の登録だけでなく取消・テーブル移動・割り勘まで反映できるかを確認してください。連携先に入っていないPOSでは、注文データを手で打ち直すことになり、二重入力でかえって手間が増えます。この場合はPOSの入れ替えを含めて検討します。

セルフオーダーの画面にアレルギー表示は必要ですか?

食品表示法のアレルギー表示義務は容器包装された加工食品が対象で、店内で提供する料理は義務の外にあります。ただし店員に尋ねる機会が減るセルフオーダーでは、画面で提供する情報が客にとっての判断材料です。2026年4月にカシューナッツが加わって9品目となった特定原材料を商品ごとに持たせ、品目の追加にも設定で対応できる作りにしておくと運用が安定します。

飲食店以外でもセルフオーダーシステムは使えますか?

飲食店以外でも利用は可能です。小売店では見本を置いて注文を受け、バックヤードから商品を出す売り方に、宿泊施設ではルームサービスを部屋付けで精算する使い方に、社員食堂やスタジアムでは座席や社員番号で注文をひもづける使い方に向きます。いずれも連携先がPOSではなく在庫システムやPMS、給与システムになることが多く、飲食店向けの既製品では足りない場合に個別開発を検討します。

関連記事

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

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

資料請求

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

  1. 2026.10.06 テックブログ 大和証券の不正アクセスと約11万人分の口座番号:問い合わせ管理の委託先に残さない設計
  2. 2026.10.06 テックブログ 焼肉きんぐの不正アクセスと1,078万件の会員情報|全件規模の流出を防ぐAPIとログの点検
  3. 2026.10.06 テックブログ 原子力研究開発機構の不正アクセスと身分証画像の漏えい|研究支援サイトのファイル保管を点検する手順
  4. 2026.10.06 テックブログ アフラックの情報漏洩440万人|大量照会を止められなかった原因と照会量制御の実装
  5. 2026.03.31 コラム 配偶者特別控除の早見表【2026年・令和8年分】満額38万円は年収169万円まで

RELATED POSTS 関連記事

目次