メインコンテンツへスキップ

POSレジ・POSシステムの選び方|種類の違いと、在庫・会員・ECとつなぐ設計

2026.10.09

POSレジ・POSシステムを入れ替えるとき、最初に決めるべきなのは機種ではありません。そのPOSで発生したデータを、店舗の他のどの仕組みに渡すかです。ここを決めずに端末だけを選ぶと、在庫・会員・ネット通販・会計・決済のそれぞれで同じ数字を人が手で作り直す運用が残ります。

結論を先に書くと、多くの店舗にとっての現実解は**「POS本体は既製品を使い、つなぎ込みとデータの使い方を開発する」**です。会計・レシート・決済といった本体の機能は業界共通で自社開発しても差がつかず、差になるのは在庫や会員とのつなぎ方だからです。

POSレジ・POSシステムとは?レジと何が違うのか#

POS(販売時点情報管理)とは、商品が売れたその時点で、何が・いくつ・いつ・いくらで・どの決済手段で売れたかを記録する仕組みです。金額を打って現金を預かるだけの旧来のレジ(レジスター)との違いは、記録が残るかどうかにあります。

POSレジとPOSシステムは何が違うのか#

実務ではほぼ同じ意味で使われますが、指している範囲が違います。

  • POSレジ: 店頭の端末と周辺機器(レシートプリンタ・バーコードリーダー・キャッシュドロア・決済端末)を指すことが多い
  • POSシステム: 上記に加えて、商品マスタ・売上の集計・在庫の増減・会員の購買履歴まで含めた全体を指す

選定で問題になるのはほぼ後者です。端末は数年で入れ替えられますが、商品マスタと売上データの持ち方は後から変えにくく、他システムとの連携もここに依存します。

なぜ「店舗データの発生源」として見る必要があるのか#

店舗には発注・棚卸・勤怠・会員登録など多くの業務がありますが、店頭の販売で商品・数量・時刻・会員・決済手段が同時に確定するのは、POSを通る瞬間だけです。この地点でデータを取りこぼすと、後工程のどこでも復元できません。

決済手段の多様化もこの地点に集まります。経済産業省によると、2025年のキャッシュレス決済比率は58.0%(162.7兆円)で、政府は2030年までに65%とする中間目標を置いています(出典:キャッシュレス|経済産業省)。売上の多くが現金以外で動くということは、POSが記録した売上と決済事業者からの入金を、決済手段ごとに突き合わせる作業が毎日発生するということです。この照合は選定時に見落とされやすく、運用開始後に負担として表面化します。

POSレジにはどんな種類があるのか?#

「POSの種類」として並べられる5つの呼び名には、3つの異なる軸が混ざっています。カタログを横に並べても比較にならないのは、このためです。

3つの軸に分けて考える#

  • 端末の形: ターミナル型(据置の専用端末)か、タブレット型(市販のタブレットと周辺機器の組み合わせ)か
  • データの置き場所: クラウド型(データをインターネット上で保持)か、店舗内のサーバーで持つか
  • 誰が操作するか: 従業員が登録と精算を行うか、セルフレジ(登録だけ従業員が行うセミセルフと、登録から客が行うフルセルフ)にするか、無人レジとして入退店から決済まで自動化するか

自店が決めるべきは3軸それぞれです。たとえば「タブレット型でクラウド型のセルフレジ」は矛盾なく両立します。一方で、1軸だけを見て「クラウドPOSにする」と決めても、端末の形と操作者が未決のままなので要件は埋まりません。

5つの呼び名を4つの観点で比べる#

市場で実際に使われている呼び名を、端末と初期構成・拡張性・他システムとの連携・向く業態の4観点で整理します。表に出てくるAPIとは、外部のシステムとデータを受け渡すための接続口のことです。

横スクロールできます
種類端末と初期構成拡張性他システムとの連携向く業態
ターミナル型据置の専用端末メーカー対応に依存個別開発が必要大規模チェーン
タブレット型タブレット+機器機器とアプリで追加APIや書き出し小〜中規模の店
クラウド型クラウドで保持契約プランで変更API連携が前提多店舗・本部集計
セルフレジ登録と精算を分けるレーン単位で増やす既存POSに追加レジ待ちが課題の店
無人レジ入退店から決済まで設置工事を伴う入退店・決済と一体省人化優先の小型店
ターミナル型・タブレット型・クラウド型・セルフレジ・無人レジの5種類を、端末と初期構成/拡張性/他システムとの連携/向く業態の4観点で比べたマトリクス
ターミナル型・タブレット型・クラウド型・セルフレジ・無人レジの5種類を、端末と初期構成/拡張性/他システムとの連携/向く業態の4観点で比べたマトリクス

このAPIの有無が、後の選択肢を大きく左右します。APIも明細の書き出しも持たないPOSを選ぶと、在庫や会員とつなぐ方法は、画面の目視と手入力しか残りません。

この5つのうち無人レジだけは、他の4つと検討の仕方が違います。入退店の認証・商品の認識・決済が一体で設計されるため、既存のPOSに後から足す形が取りにくく、店舗のレイアウトと設置工事が前提になります。既存店への導入より、新規の小型店で最初から組むほうが現実的です。

セルフ化・省人化を検討する業態では、人員の確保そのものが前提条件になります。民間の信用調査会社である株式会社帝国データバンクの調査では、非正社員の人手不足を感じている企業の割合は「飲食店」で57.7%でした。前年同月比ではマイナス4.1ポイントで改善が続いているものの、なお6割近い水準です(出典:人手不足に対する企業の動向調査(2026年7月)|株式会社帝国データバンク。2026年7月17日〜7月31日のインターネット調査、有効回答1万518社)。ただしセルフレジは登録や精算を客に移すもので、品出し・接客・締め作業は残ります。どの作業が誰に移るのかを工程単位で確認せずに導入すると、期待した省人化になりません。

POSは店舗の何とつながるべきか?#

POSの選定で最も効くのは、つなぐ先を5系統に分けて、それぞれ「POSから何を渡すか」と「つながないと何が起きるか」を先に決めることです。表に出てくるCRMは顧客関係管理、ECはネット通販、OMSは複数の販売経路の注文と在庫の引き当てをまとめて扱う受注管理システムを指します。製品を見る前にこの表を自店向けに埋めると、必要な連携と不要な連携が分かれます。

横スクロールできます
つなぐ先POSが渡す主なデータつながないと起きること
在庫・棚卸商品別の販売数と時刻理論在庫を作れない
会員・CRM会員IDごとの購買履歴誰が買ったかが残らない
EC・OMS店舗在庫と店舗の売上店舗受取を組めない
会計・請求税率ごとの売上と消費税額税率集計を手で作り直す
決済請求金額と決済手段の別入金との照合が手作業
在庫・棚卸/会員・CRM/EC・OMS/会計・請求/決済の5系統について、POSが渡す主なデータと、つながないと起きることを並べたマトリクス
在庫・棚卸/会員・CRM/EC・OMS/会計・請求/決済の5系統について、POSが渡す主なデータと、つながないと起きることを並べたマトリクス

この5系統に加えて、勤怠・シフトとつなぐ選択肢もあります。POSが時間帯別の売上と客数を渡せれば、必要人数を決める根拠になります。ただし優先度は上の5系統より低く、勤怠側の仕組みが整っていることが前提です。進め方はシフト管理システムの選び方|無料ツールで足りなくなる条件と、勤怠・POSとつなぐ設計で解説しています。

在庫・棚卸との連携の効果は「差異が消えること」ではない#

POSが販売数を渡せば理論在庫を持てますが、**実地棚卸との差異が消えるわけではありません。**差異は廃棄・誤登録・入荷時の検品漏れ・紛失など複数の原因から生まれ、POSが記録するのは販売側だけです。POS連携の効果は「差異が消えること」ではなく、差異の金額と発生箇所が分かるようになることです。差異の要因と棚卸の進め方そのものは棚卸システムの導入|実地棚卸の負担と在庫差異を減らすで扱っています。

会員・CRMとの連携で決めるのは「何をキーにするか」#

POSの購買履歴とCRM側の会員情報をつなぐには、両者を結ぶキーが必要です。会員証の番号・電話番号・アプリのIDのどれを正とするかを決めないまま運用を始めると、同一人物が複数の会員として積み上がります。ID統合の進め方は店舗とECの会員・ポイント・顧客データ統合|ID統合とCRM/CDPで解説しています。

EC・OMSとの連携は在庫の持ち方から決まる#

店舗在庫をEC側からも引き当てるなら、在庫を1か所にまとめる設計が先に必要です。POSが店舗在庫と店舗の売上を渡せないと、店舗受取や取り置きのように「ECで注文して店舗で受け取る」流れが組めません。逆に言えば、店舗受取を当面やらないなら、この連携の優先度は下げられます。在庫を一元化する仕組みの選び方は店舗在庫とECの在庫一元管理|OMS・API連携の仕組みと選び方にまとめています。

レシートは適格簡易請求書の要件を満たせるか#

小売業など不特定かつ多数の者に販売する事業では、適格請求書に代えて記載事項を簡易にした適格簡易請求書を交付できます。国税庁が示す記載事項は次の5つです。

  1. 1適格請求書発行事業者の氏名又は名称及び登録番号
  2. 2課税資産の譲渡等を行った年月日
  3. 3課税資産の譲渡等に係る資産又は役務の内容(課税資産の譲渡等が軽減対象課税資産の譲渡等である場合には、資産の内容及び軽減対象課税資産の譲渡等である旨)
  4. 4課税資産の譲渡等の税抜価額又は税込価額を税率ごとに区分して合計した金額
  5. 5税率ごとに区分した消費税額等又は適用税率

適格請求書と違い、交付を受ける相手方の氏名・名称は不要で、5つ目は消費税額等か適用税率のどちらか一方で足ります(出典:問58 適格簡易請求書の記載事項|国税庁)。POS側で確認すべきは、登録番号を印字できるか、軽減対象品目に印が付くか、税率ごとに金額を区分して集計できるかの3点です。請求書側のデータ項目まで含めた対応は適格請求書(インボイス)にシステムで対応する|記載事項・データ項目と経過措置の見直しで扱っています。

税率が変わるときに設定を切り替えられるか#

2026年9月15日、飲食料品に係る消費税率を2027年4月から2年間に限って臨時的に引き下げる内容を定めた大綱が閣議決定されました。国税庁が公表したQ&Aでは、引下げ後の税率を1%、適用期間を令和9年4月1日から令和11年3月31日まで(2027年4月1日から2029年3月31日まで)としています。ただし同Q&Aは、法案が国会に提出され可決・成立した場合のものであると明記しています(出典:飲食料品に係る2年間の消費税率引下げに関するQ&A(令和8年9月)|国税庁 軽減税率・インボイス制度対応室)。

制度としての確定は国会での可決・成立を待つことになりますが、POSの選定では「税率と商品の区分を期間指定で切り替えられるか」「切り替え前後をまたぐ集計ができるか」を確認項目に入れておくのが安全です。期間を指定して予約設定できないPOSでは、仮に切替日が確定した場合に、その日に全店で手作業が発生します。

改修の費用には支援制度があります。中小企業庁は、2026年9月15日以降に先に改修へ着手して事後に補助金を申請できる「事前着手制度」を措置しました。デジタル化・AI導入補助金のPOSレジ類型では、補助対象経費に「POSレジ・受発注・請求書管理等のシステム改修費」が含まれます。対象期間は2026年9月15日から2027年3月、申請受付期間は2027年1月から2027年3月(いずれも調整中)とされ、詳細は後日公募要領で公表される予定です(出典:変化の時代に対応できるスマートレジの導入支援(事前着手制度)|中小企業庁、変化の時代に対応できるスマートレジの導入を支援します(デジタル化・AI導入補助金)|中小企業庁)。

決済との連携は「売上と入金が合うか」で見る#

決済端末との連携は、金額が正しく通ることだけでなく、決済手段ごとの売上がPOSに残り、後から入金と突き合わせられるかで評価してください。商業施設に入居している店舗では、施設側の精算額とPOS売上が合わないという形で問題が出ます。その原因と照合の自動化はPOS売上と商業施設の精算額が合わない|差異の原因と照合を自動化する進め方で詳しく扱っています。

POSを選ぶ基準は?#

前提として先に固めておくのは業態と売り方(取扱点数・単品管理の要否・予約の有無)と店舗数と本部機能(全店実績を本部で集約するか、商品マスタを一括で配るか)の2つです。これは製品を比べる前に自店で決めることであり、候補ごとに答えが変わる項目ではありません。

そのうえで、製品を比べる段階では次の5項目を同じ質問として全候補にぶつけてください。カタログの機能一覧ではなく、自店の業務が成立するかどうかで判定するための項目です。

横スクロールできます
確認すること見るポイント
データの出し方APIの有無とCSVで明細まで出せるか
通信が切れたとき単独で会計を続け、復旧後に送れるか
レシートの記載事項適格簡易請求書の記載事項5つを満たせるか
税率変更への対応税率区分を期間指定で切り替えられるか
費用の構造初期・月額・端末・連携開発・保守の範囲
データの出し方・通信が切れたとき・レシートの記載事項・税率変更への対応・費用の構造の5項目について、候補ごとに見るポイントを並べたチェックリスト
データの出し方・通信が切れたとき・レシートの記載事項・税率変更への対応・費用の構造の5項目について、候補ごとに見るポイントを並べたチェックリスト

とくに見落とされる2項目#

通信が切れたときの動作は、クラウド型なら必ず確認してください。「オフラインでも使える」の中身は製品によって差があり、会計そのものが止まるもの、会計は続くが会員照会ができないもの、復旧後に自動送信するものに分かれます。自店の立地で通信が落ちる頻度と、落ちたときに何分で会計を再開できるかを質問項目に入れておくのが確実です。

費用の構造は、金額の大小ではなく内訳で見てください。初期費用・月額利用料・端末費用・連携開発費・保守の範囲のうち、どれが含まれどれが別見積もりかは製品ごとに違います。とくに連携開発費と保守窓口の範囲は見積もりに現れにくく、運用開始後に差が出ます。障害が起きたときの一次窓口をPOSのメーカーが持つのか自社が持つのか、決済端末のメーカーが変わったときの改修費用をどちらが負担するのかを、契約前に確認しておいてください。

メーカー・サービスを見るときの観点#

規模の大きい事業者を選べば安心、という判断は成り立ちません。見るべきは自店の業態での導入実績、APIとデータ出力の仕様が公開されているか、保守の窓口と対応時間が契約に書かれているかです。開発を担う立場から言えば、仕様が公開されているかどうかが、後から連携を足せるかを決めます。

既製POSか、連携開発か、自社開発か?#

冒頭で書いた「本体は既製品、つなぎ込みを開発」が現実解になりやすい理由は、差がつく場所が本体の外にあることです。選択肢は3つあり、向く条件が分かれます。

横スクロールできます
選択肢向く条件初期の負担変えたいときの自由度
既製POSをそのまま使う標準機能で業務が収まる小さい低い(提供機能の範囲内)
既製POS+連携開発本体は標準、つなぎ先に固有の事情がある中くらいつなぎ目は変えられる
自社開発売り方そのものが商品で、標準品に乗らない大きい高い(保守も自前)

3つの選択肢はどこで分かれるか#

既製POSをそのまま使うのは、1〜数店舗で取扱点数が多くなく、在庫も会員も標準機能で足りる場合です。無理に開発を挟まないほうが早く、保守の負担もありません。

既製POS+連携開発が向くのは、POS本体は標準品で足りるが、つなぐ先に固有の事情がある場合です。たとえば自社の基幹システムに独自の商品コード体系があり、POSの商品マスタとの対応表が必要になるケース、あるいは本部の集計で店舗ごとに異なる締め時刻を扱うケースです。開発するのはデータを受け渡す部分と、受け取った後の見せ方に限られます。

自社開発が成立するのは、売り方そのものが事業の商品で標準品に乗らない場合に限られます。会計・レシート・決済・税率対応を自前で持つと、制度改正のたびに自社で改修する責任を負います。前述の消費税率引下げのような制度改正も、成立すれば既製品は提供側が対応しますが、自社開発では自社の開発計画に入ります。この負担を引き受ける理由があるかを先に確認してください。

弊社が担うのはどの部分か#

弊社(株式会社TryWith)が小売・店舗ビジネスのお客様の案件で担うことが多いのは、2つ目の「既製POS+連携開発」の部分です。POS本体の選定はお客様の業務要件で決めていただき、在庫・会員・ネット通販・会計・決済とのつなぎ込み、本部向けの集計、既存の基幹システムとの対応付けを設計・開発します(システム開発ソリューション|Web・モバイル・LINE受託開発)。

POS導入はどう進めるのか?#

要件を決めずに製品の比較から始めると、デモで見た機能に要件が引きずられます。次の5工程の順で進めてください。

  1. 1要件を整理する: 現在のレジ業務と、つなぐ先のシステムを洗い出す
  2. 2種類を決める: 端末の形・データの置き場所・誰が操作するかを選ぶ
  3. 3連携を設計する: 渡すデータの項目・粒度・頻度と、失敗時の扱いを決める
  4. 4移行して試す: 商品マスタ・在庫の初期値・会員データを移し、1店舗で試す
  5. 5運用に乗せる: 締め作業・マスタ更新・問い合わせ窓口の担当を決める
要件を整理する、種類を決める、連携を設計する、移行して試す、運用に乗せるの5工程を順に並べたフロー図
要件を整理する、種類を決める、連携を設計する、移行して試す、運用に乗せるの5工程を順に並べたフロー図

移行で実際につまずく3箇所#

  • 商品マスタ: 旧POSの商品コード・名称・税区分・売価の履歴が、そのまま移せないことが多い。廃番商品や同一商品の重複登録を先に整理しないと、移行後の集計が旧データとつながらない
  • 在庫の初期値: 移行日の在庫数をどう確定するかを決めておく。実地棚卸を挟まずに理論在庫を引き継ぐと、以後の差異が移行前の誤差を含んだままになる
  • 会員データ: 会員番号の体系が変わる場合、旧番号との対応表を残す。ポイント残高の移行日時と、移行中の取引をどう扱うかを事前に決める

連携の失敗時をどう扱うか決めておく#

設計で抜けやすいのは、連携が失敗したときの扱いです。在庫への反映が失敗したら自動で再送するのか、担当者に通知して手で直すのかを決めておきます。再送するなら、同じ売上が二重に反映されない仕組みが必要です。ここを決めずに運用を始めると、月末に原因不明の在庫差異として現れます。

まとめ#

POSレジ・POSシステムの選定は、機種選びではなくデータの受け渡し先を決める作業です。

  • POSは、店頭の販売で商品・数量・時刻・会員・決済手段が同時に確定する地点である
  • 「種類」は端末の形・データの置き場所・誰が操作するかの3軸に分けて決める
  • つなぐ先は在庫・棚卸/会員・CRM/EC・OMS/会計・請求/決済の5系統。「渡すデータ」と「つながないと起きること」を先に埋める(勤怠・シフトは後から足す)
  • 業態と売り方、店舗数と本部機能は先に自社で決め、製品比較では5項目の同じ質問を全候補にぶつける
  • 現実解は「既製POS+連携開発」。標準機能で足りるなら既製品のまま、売り方自体が商品なら自社開発を検討する
  • 移行でつまずくのは商品マスタ・在庫の初期値・会員データの3箇所

店舗業務全体でのPOSの位置づけは店舗DX・モバイル活用ガイド|人手不足を仕組みで解決するも参考にしてください。

よくある質問(FAQ)#

Q. POSを入れれば在庫が合うようになりますか?

A. 合うようにはなりません。POSが記録するのは販売側だけで、在庫差異は廃棄・誤登録・検品漏れ・紛失などからも生まれます。POS連携で変わるのは、差異の金額と発生箇所が見えるようになることです。

Q. クラウドPOSはインターネットが切れたら使えなくなりますか?

A. 製品によって動作が分かれます。「オフライン対応」という表記だけで判断せず、落ちたときに何ができて何ができないかを製品ごとに確認してください。

Q. POSのレシートは適格簡易請求書になりますか?

A. 小売業など不特定かつ多数の者に販売する事業では、記載事項を満たせば適格簡易請求書として交付できます。POS側では、登録番号の印字、軽減対象品目である旨の表示、税率ごとに区分した金額の集計ができるかを確認します。詳しい記載事項は問58 適格簡易請求書の記載事項|国税庁をご確認ください。

Q. すでに使っている会員アプリや基幹システムとつなげられますか?

A. POS側にAPIか明細レベルのデータ出力があれば可能です。実際の作業は、両者を結ぶキー(会員番号・商品コード)の対応付けと、渡すデータの粒度・頻度、失敗したときの扱いを決めることが中心になります。

Q. セルフレジを入れれば人は減らせますか?

A. 減るのは登録と精算の工程だけで、品出し・接客・締め作業・トラブル対応は残ります。レジ台数を増やして待ち時間を短くする効果と、人員を減らす効果は別のものとして見積もってください。

Q. POSを自社開発してくれる会社はありますか?

A. あります。ただし前述のとおり、POS本体の自社開発が必要なのは売り方そのものが事業の商品で標準品に乗らない場合に限られます。多くのご相談では、本体は既製品を使い、在庫・会員・ネット通販・会計・決済とのつなぎ込みと本部向けの集計を開発する形が現実的です。

POSと在庫・会員・ECのつなぎ方をご相談ください#

POSの選定でつまずくのは、たいてい端末の性能ではなく、つなぐ先の設計とデータの粒度です。弊社(株式会社TryWith)は小売・店舗ビジネス向けのシステム開発を手がけており、既製POSと在庫・会員・ネット通販・会計・決済をどうつなぐか、どこまでを開発し、どこを標準機能に任せるかの整理からお手伝いしています。

現在お使いのレジ業務とつなぎ先のシステムを伺えれば、30分のオンライン相談で論点を整理できます。検討の初期段階でも構いません。

お問い合わせはこちら

タグ

#POSレジ#POSシステム#在庫管理#店舗DX#キャッシュレス#システム連携