2026.09.12 ERP

飲食店のPOSレジは何が違う？業態別の必須機能と自社開発の判断基準

飲食店向けのPOSレジを調べると、製品名と機能一覧が並ぶ比較記事にたどり着きます。ところが実際に現場で困るのは、製品の優劣ではなく「自分の店の業態では、どの機能が無いと回らないのか」が分からないことです。居酒屋で会計分割ができないレジは閉店間際に行列を作り、カフェで持ち帰りと店内飲食の税率を切り替えられないレジはレシートを作り直させます。この記事では、飲食という業態がPOSレジに課している固有の要件を、業態ごとの差と税制の規定から分解する構成です。そのうえで、既製品で足りる店と、既存の予約・会員・基幹システムとの統合のために受託開発へ振るべき店の分岐を、条件付きで示します。

まとめ：飲食店のPOSレジで先に決める3点と業態別の分かれ目

飲食店のPOSレジを選ぶ順序は、製品比較から入ると必ず迷います。先に決めるのは3点です。第1に注文をどこで受けるか（口頭とハンディか、テーブルのセルフオーダーか、入口の券売機か）。第2に会計までの間、誰が何を頼んだかをどの単位で持つか（テーブル単位か、客単位か、伝票単位か）。第3にレシートへ何を出すか（適用税率、登録番号、持ち帰りと店内の区分）。この3つが決まると候補は数製品まで絞れます。

業態ごとの分かれ目もはっきりしています。居酒屋とパブは、滞在時間が長く会計が複雑なため、テーブル管理・会計分割・伝票の付け替えが最初に確認する足切り条件です。カフェと喫茶は、持ち帰りと店内飲食で税率が変わるため、注文時点で区分を確定させる操作設計が要ります。ラーメン店やファーストフードは券売機との併用が前提になりやすく、注文データを誰が持つかで構成が変わります。POSシステムの仕組みと種類の整理を押さえたうえで、業態の要件を重ねる順序にしてください。

市場側の数字も選び方に影響します。日本フードサービス協会が公表した令和7年（2025年）の年間結果報告では、会員社の全店データで売上が前年比107.3％、客数が102.9％、客単価が104.3％でした。売上の伸びは客数ではなく客単価が押し上げています。客数で稼ぐ構造から客単価で稼ぐ構造へ寄っている以上、POSレジに求める分析は「何個売れたか」よりも「誰がいくら使ったか、どの時間帯に単価が落ちたか」に移ります。商品別売上だけを見る設計では足りません。

飲食店のPOSレジが小売のレジと違う理由と、業態別に割れる要件

小売と飲食でレジに求めるものが違うのは、取引が完了するまでの時間の長さが違うからです。この差を理解しないまま小売向けの製品を入れると、機能は足りているのに現場の手が増えます。

小売のレジが売る瞬間だけを見るのに対し飲食店が管理する時間の幅

小売のレジは、商品をスキャンして代金を受け取る数十秒を記録する装置です。取引の開始と終了がほぼ同時なので、レジが持つ状態は「いま会計中かどうか」だけで足ります。飲食店では、管理する状態が小売とは別です。入店から退店までの数十分から数時間、店は「まだ会計していない注文」を抱え続けます。追加注文が入れば金額は増え、席を移動すれば持ち主が変わり、途中で人数が増えれば分割の条件も変わります。

この抱えている状態を管理できるかどうかが、飲食店向けを名乗るPOSレジと汎用レジの最大の差です。汎用レジでも売上は記録できますが、未会計の伝票がテーブルに紐づいていないと、注文を取った人と会計する人が別になった瞬間に口頭の申し送りが発生します。閉店前の混雑時間帯で申し送りが増えると、会計ミスと待ち時間の両方が同時に悪化します。

注文から会計までが時間的に分離する飲食店特有のデータの持ち方

注文と会計が分離すると、POSレジは3つのデータを別々に持つ必要が出ます。1つ目はテーブル（席）の状態で、空席・着席・会計待ちの区別。2つ目は伝票で、そのテーブルに紐づく明細の集合。3つ目は客数と滞在時間で、客単価と回転率を出すための分母です。3つ目を取らない製品は珍しくありませんが、客単価の分析ができないと、前述の客単価主導の売上構造に対して打ち手が作れません。

導入前に確認するなら、カタログの機能名ではなく操作の回数で見るのが確実です。「4人組が来店して2人が先に帰り、残りが追加注文して最後に3枚に分けて会計する」という一連の流れを、実機の試用で何タップで完了できるか数えます。飲食店向けを名乗る製品でも、席移動と部分会計の組み合わせでレジ締めの数字が合わなくなるものがあります。試用時に必ず通す経路として決めておいてください。

居酒屋・カフェ・ラーメン店で変わるPOSレジの必須機能の差分

業態別の要件は、好みの問題ではなく回らなくなる条件です。ここでは前述の年間結果報告の業態別データと突き合わせながら、どの機能が足切りになるかを分けます。

居酒屋とパブのレジに先に要るテーブル管理と会計分割まわりの機能

パブ／居酒屋の2025年の全店データは売上104.0％で、居酒屋に絞ると客単価は102.4％、店舗数は99.8％でした。他業態と比べて客単価の伸びが鈍く、店舗数も横ばいから微減です。値上げで吸収しきれない以上、回転と人時で稼ぐしかありません。ここでレジが握るのは会計にかかる時間です。

足切り条件は4つあります。テーブル単位の伝票管理、1伝票を複数人へ分ける会計分割、席移動と伝票の付け替え、コースや飲み放題の時間管理です。とくに飲み放題は、開始時刻をレジ側で持たないと延長の判定が口頭になり、ラストオーダーの声かけが漏れます。時間制の管理をオーダー端末側だけに置く構成もありますが、その場合は会計時に延長料金がレジへ自動で乗るかを必ず試用で確認します。

カフェと喫茶で問題になる店内と持ち帰りの税率区分と単価の取り方

喫茶の2025年は売上109.8％、客単価108.6％と全業態で最も客単価が伸びました。一方で客数は101.1％にとどまります。単価の高い商品を売る構成へ寄っているため、レジには商品別の単価分析と、セット・トッピングの組み合わせを崩さず記録する能力が要ります。

それ以上に効くのが税率の区分です。国税庁の消費税の軽減税率制度の説明では、標準税率が10％（消費税7.8％と地方消費税2.2％）、軽減税率が8％（6.24％と1.76％）と定められています。外食は「飲食店業等の事業を営む者が飲食に用いられる設備がある場所において行う食事の提供」と定義され、軽減税率の対象に含まれません。持ち帰りは軽減税率の対象です。同じコーヒーでも、店内なら10％、持ち帰りなら8％になります。

厄介なのは判定の時点です。同じ説明で、適用税率の判定は「飲食料品を提供する時点」で行うとされています。会計時にまとめて切り替えるのではなく、注文を受けた瞬間に区分が決まる建て付けです。したがってレジ側には、商品ごとに税率を持てること、注文入力の画面で店内と持ち帰りをワンタップで切り替えられること、切り替えを伝票単位でなく明細単位でできることが要ります。明細単位で持てない製品だと、店内飲食と持ち帰りが混ざった注文で伝票を分ける運用になり、レシートが2枚に割れます。

券売機を使うラーメン店やファーストフードでの注文データの流れ

ファーストフードの持ち帰り米飯／回転寿司は、2025年の客数が96.0％と前年を下回り、客単価は107.2％でした。客数が減っているのに売上が伸びる構造では、レジの目的は会計処理よりも「単価を上げた施策が効いたか」の検証に寄ります。ところが券売機を先に入れている店では、注文データが券売機の中で完結し、POS側には合計金額しか渡っていないことがあります。

この構成だと、商品別の売れ筋も時間帯別の単価も分析できません。券売機とPOSをつなぐ場合は、券売機が販売明細をPOSへ送るのか、POSのマスタを券売機が読むだけなのかを、導入前に接続仕様の単位で確認します。メニュー改定のたびに券売機とPOSへ二重登録が必要になる構成も残っており、月に何度も価格を変える店では運用負荷が無視できません。注文を受ける端末の選び方そのものは飲食店のオーダーシステムの種類と費用の整理にまとめてあります。

軽減税率とインボイス制度が飲食店のPOSレジに課す会計要件の線引き

飲食店のレジは、売上を記録する装置であると同時に、税法上の書類を発行する装置です。ここを製品選定の後半に回すと、レシートの様式で作り直しが起きます。

レシートに出す項目と、飲食店業に認められている記載の省略範囲

国税庁の適格請求書等の記載事項の説明によると、取引の相手方へ交付する請求書等には、書類作成者の氏名または名称および登録番号、取引年月日、取引内容（軽減税率の対象品目である旨）、税率ごとに区分して合計した対価の額および適用税率、税率ごとに区分した消費税額等、書類の交付を受ける事業者の氏名または名称の6項目が要ります。

飲食店には省略が認められています。同じ説明の注記で、小売業・飲食店業・タクシー等を営む事業者が交付する書類については、適用税率と消費税額等のいずれかの記載で差し支えないとされ、この場合に相手方の氏名または名称の記載は不要になります。不特定多数の客に一枚ずつ宛名を書かせない趣旨です。ただし登録番号は省略できません。レジのレシート様式に登録番号を差し込む設定があるか、店舗ごとに異なる番号を持てるか（同一法人で複数店舗なら通常は同一番号）を確認します。

保存期間も契約前に確認する項目です。同じ説明では、帳簿および請求書等は閉鎖または受領した日の属する課税期間の末日の翌日から2か月を経過した日から7年間の保存が必要で、6年目と7年目はいずれか一方の保存でよいとされています。クラウドPOSの売上データ保持期間が契約プランによって1年や3年に制限されている場合、この7年と衝突します。契約前に保持期間と、解約後のデータ取り出し可否を確認してください。

一体資産と物販併設で起きる税率判定の例外と商品マスタ設定の勘所

物販を併設するカフェやベーカリーでは、一体資産の扱いが効きます。軽減税率制度の説明では、食品と食品以外があらかじめ一体となっていて一体の価格だけが提示されている資産について、税抜価額が1万円以下で、かつ食品の価額が占める割合が3分の2以上の場合に限り、その全体が軽減税率の対象になるとされています。それ以外は全体が標準税率です。

菓子とマグカップを組んだギフトセット、コーヒー豆とドリッパーのセットなどが該当します。レジ側では、セット商品を単一の商品コードとして税率を固定で持たせるのか、明細を分解して都度判定するのかが、設計上の分かれ目です。季節ごとにセット構成を変える店なら、商品マスタで税率を商品単位に持てる製品を選ばないと、毎回の登録作業で誤りが混ざります。税率を部門（カテゴリ）単位でしか持てない古い構成の製品は、この時点で候補から外れます。

券売機・セルフオーダー・決済端末とPOSレジをつなぐ連携の設計

飲食店のPOSレジは単体では完結しません。注文側と決済側の両方に別の機器がぶら下がり、その接続の質が現場の手数を決めます。

決済端末との接続方式と、キャッシュレス比率から見た必要な手数

経済産業省が2026年3月31日に公表した2025年のキャッシュレス決済比率は58.0％（162.7兆円）でした。内訳はクレジットカードが82.7％（134.6兆円）、デビットカードが3.4％（5.5兆円）、電子マネーが3.7％（6.0兆円）、コード決済が10.2％（16.6兆円）です。中間目標として2030年までに国内指標で65％が置かれています。会計の6割近くが現金以外で、コード決済だけで16.6兆円が動いている以上、レジと決済端末が別々に金額入力を求める構成は現場の負担が大きくなります。

確認すべきは連動の方式です。POSから決済端末へ金額を自動で送る連動型なら、打ち間違いによる差異が起きません。金額を手で打ち直す非連動型は、端末の導入費は安いものの、締め作業でレジ売上と決済端末の入金明細を突き合わせる手間が毎日発生します。1日の決済件数が100件を超える店では、連動型を選ばない理由はほぼ無い状況です。決済手段ごとの手数料と入金サイクルは飲食店の決済システムの種類と手数料の整理で確認できます。

在庫・原価・多店舗の一元管理へ売上データを流すときの接続点と条件

POSの売上データは、レジの中で完結させず後工程へ流してはじめて元が取れます。代表的な流し先は3つです。1つ目は在庫と発注で、レシピ（原材料構成）を持たせれば販売実績から理論消費量を出せます。2つ目は原価と人時で、売上に対する原価率とシフトの人件費を日次で突き合わせる用途。3つ目は本部で、複数店舗の売上を同じ粒度で集約する用途です。

接続の現実的な難所はマスタです。店舗ごとにメニュー名の表記が揺れていると、本部で集計した瞬間に別商品として並びます。多店舗化の予定があるなら、商品コードの採番規則を最初の1店舗の時点で決めておく。連携の仕組みそのものはPOSレジと在庫管理の連携と自動発注の整理、多店舗の集約は飲食店の店舗管理システムの機能と導入判断に分けて書いてあります。

パッケージで足りる飲食店と、受託開発に振るべき飲食店の分岐条件

既製のクラウドPOSは安くなり、機能も広がりました。それでも受託開発に振ったほうが総額で安くなる店は残ります。分岐は店の規模ではなく、つなぎたい先の数と独自性で決まります。

既製品で足りる店の条件と、無理に作らないほうがよい規模の目安

次の条件をすべて満たすなら、既製品の範囲で収まります。第1に業態が標準的で、テーブル管理と会計分割、税率区分が製品の標準機能で足りること。第2に外部へつなぐ相手が、会計ソフトと決済端末、せいぜい勤怠の3つまでで、いずれも製品側が公式に対応していること。第3に店舗数が数店以内で、本部の集計を製品の管理画面で見て済むこと。この範囲なら、月額課金の製品を選び、浮いた予算を店舗の運用設計に回すほうが回収が早くなります。

製品タイプごとの選定基準はPOSレジの比較で外さない判断軸の整理にまとめました。ここで言い切っておくと、単店から3店舗規模で、既存システムとの連携要件が無い店が受託開発でPOSを作るのは、費用回収の見込みが立ちません。開発費に加えて、税制改正のたびの改修費を自社で負い続けることになるためです。制度改正はレシート様式と税率区分に直接効くので、保守を持てない規模では既製品の追随に乗るほうが安全です。

飲食店が受託開発に振る条件と、既製品との併存で費用を抑える組み方

受託開発を検討する条件は4つです。第1に自社の予約システムや会員基盤があり、来店客の識別をPOSと共通化したい場合。第2に独自の原価計算や歩留まり管理があり、標準的なレシピ管理では表現できない場合。第3に本部の基幹システムへ日次で明細を渡す必要があり、既製品の出力形式では変換の手間が常態化している場合。第4に複数ブランドを運営し、ブランドごとに異なるメニュー体系と価格体系を同じ集計軸へ揃えたい場合です。

ただし、この場合でもレジ端末そのものを作る必要はほとんどありません。現実的なのは、レジと決済は既製品に任せ、その売上データを受け取って自社の要件で処理する層を作る組み方です。レジ側は制度改正への追随を製品ベンダーに任せ、独自性が要る部分だけを自社で持つと、改修の範囲が限定されます。どこまでを既製品に任せ、どこから自社で持つかの線引きは店ごとに違うので、流通システム開発の受託では既存のレジと基幹の構成を確認したうえで設計します。

飲食店のPOSレジ導入で失敗する原因と、稼働前に潰す確認項目

導入の失敗は機能不足よりも、運用条件の見落としで起きます。稼働前に確認すれば潰せるものがほとんどです。

通信断とプリンタ振り分けで止まる現場と、稼働前に確かめる運用条件

クラウドPOSで最初に効くのは回線です。店舗の回線が落ちたとき、レジが会計を継続できるか、できるとしてどこまでの機能が使えるかは製品によって大きく違います。会計だけは端末内で継続し復旧後に同期する設計と、完全に停止する設計の両方があるため、製品ごとの確認が必要です。停止する設計なら、モバイル回線のバックアップを用意するか、手書き伝票での運用手順を決めておく必要があります。

もう一つがプリンタの振り分けです。注文がキッチンとドリンクカウンターへ正しく振り分かるか、厨房が複数ある店で商品カテゴリごとに出し分けられるかを、実際の商品マスタで試します。この設定を製品側の担当者に任せきりにすると、開店初日に全伝票が1台へ集中して調理が詰まります。カテゴリ数と厨房の数を紙に書き出し、対応表を作ってから設定に入ってください。

既存レジからの移行で消えるデータと、補助金を使う場合の発注順序

入れ替えで消えやすいのは、過去の売上明細と顧客の来店履歴です。旧レジのデータを新レジへ取り込めるとは限らず、取り込めても粒度が落ちます。移行前に、日次の売上集計だけは表計算形式で全期間を書き出しておく。商品マスタは名称と価格だけでなく、税率区分と部門の対応表まで書き出すと、新レジでの登録漏れが減ります。

補助金を使う場合は順序に注意します。交付決定の前に発注すると対象外になる制度が通例で、開店日や改装日から逆算すると間に合わないことがあります。制度ごとの対象費目と締切はPOSレジで使える補助金の対象費目の整理にまとめてあるので、見積書を取る前に確認してください。制度を使う前提なら、交付決定の見込み時期を先に押さえ、そこから設置工事と研修の日程を引く順序になります。

よくある質問

飲食店のPOSレジと小売向けのPOSレジは何が違いますか？

注文と会計が時間的に分離するかどうかが、両者の違いです。飲食店は入店から退店まで未会計の伝票を抱え続けるため、テーブル単位の伝票管理、会計分割、席移動時の伝票の付け替えが必要になります。小売向けの製品はこの状態管理を持たないものが多く、注文を取った人と会計する人が別になった時点で口頭の申し送りが発生します。

居酒屋でPOSレジを選ぶとき最初に見る機能はどれですか？

会計分割と伝票の付け替えです。1つのテーブルを複数人で割る、途中で帰る客の分だけ先に精算する、席を移動した客の伝票を移す、という操作が閉店前の混雑時間帯に集中します。試用時には「4人来店して2人が先に帰り、残りが追加注文して最後に3枚へ分ける」という経路を実機で通し、レジ締めの数字が合うかまで確認してください。

持ち帰りと店内飲食で税率を切り替える設定はどうしますか？

国税庁の説明では適用税率の判定は飲食料品を提供する時点で行うため、会計時ではなく注文入力の時点で区分を確定させる設計にします。レジ側の条件は、商品ごとに税率を持てること、明細単位で店内と持ち帰りを切り替えられることの2点です。部門単位でしか税率を持てない製品だと、混在した注文で伝票が分かれます。

券売機を使っている店でもPOSレジを入れる意味はありますか？

売上分析を行うなら意味があります。券売機の中で注文データが完結していると、POS側に渡るのが合計金額だけになり、商品別や時間帯別の分析ができません。券売機が販売明細をPOSへ送る構成か、メニュー改定時に両方へ二重登録が必要かを、導入前に接続仕様の単位で確認してください。

飲食店のPOSレジを自社開発する判断はどこで分かれますか？

つなぎたい先の数と独自性で分かれます。自社の予約・会員基盤と来店客を共通化したい、独自の原価計算がある、本部の基幹へ日次で明細を渡す、複数ブランドを同じ集計軸へ揃える、のいずれかに当たる場合です。その場合もレジ端末自体は既製品に任せ、売上データを受け取って処理する層だけを自社で持つ組み方が費用を抑えられます。