会合の概要
第9回データ標準化分科会は、標準フォーマット V1.0 を、小売のデータまで反映してからリリースするという方針の変更をご報告した回となりました。小売大手1社から実データのご提供にご協力いただけることになり、外食・中食に加えて、小売の単品(SKU)まで V1.0 で扱います。
あわせて、9つのPOS系統の実データを1つの標準へまとめるにあたり、どういう考え方で、どんなルールを決めたのかをご説明しました。後半では、標準データから出力できる電子レシートによって、ポイントの付与・利用や、さまざまなアプリとの連携がどう実現できるのかを、仕組みの面からご説明しています。
質疑では、電子レシート国際標準との対応、税や日付の持ち方、小売と外食の読み分け、取消・返品の考え方など、仕様の細部に踏み込んだご質問を多くいただきました。口頭では説明しきれなかった点が多かったため、標準データの解説資料を、本レポートとは別にサイトで公開していきます(本レポート 5 章)。
本レポートに登場するデータは、すべて企業名・店舗名・POSメーカー名を伏せた形で扱っています。商品名・金額の例は説明のためのものです。
1. ご報告
1-1. V1.0 は、小売のデータを反映してからリリースします
これまで、小売への対応は「ミニマム」としてきました。今回、小売大手1社から実データのご提供にご協力いただけることになり、方針を変えました。V1.0 では、飲食だけでなく、小売の単品(SKU)まで対応します。
商品分類の階層、メニューの親子(サブメニューやオプション)、SKU の持ち方は、小売の実データで確かめないと決めきれません。そのため、ご提供いただくデータを取り込み、標準に反映したうえでリリースします。外食部分の仕様は、ほぼ完成しています。
V1.0 の完成の基準 ── 接続しているすべてのPOSの実データを、1列も余らせずに標準へ割り当てられること。
1-2. 駅構内事業者との取り組み
駅構内事業者よりご提供いただいている実データについて、POSと券売機の2つの系統のデータを、標準の形に変換し、出力するところまで、ひととおり完了しました。 今後は、実データの受け渡しの方法と、標準データからどのような形で出力するかといった、詳細のつなぎ方を個別に詰めていきます。
1-3. 商業施設のテナント売上報告
商業施設に出店するテナント企業から施設側への売上報告は、長年、施設ごとに異なる形式で、手作業を含めて行われてきました。これを完全に自動化・オンライン化するための取り組みの第一弾として、PoC を開始しています。標準データの使い方の1つの方向性として、ご紹介しました。
2. 標準データの作り込み ── POSごとの違いを、1つの標準にどうまとめたか
2-1. まとめ方の5つの原則
V1.0 は、9つのPOS系統の実データを実際に標準の形へ変換し、件数・金額・税額が元のデータと合うことを確かめながら作り直しています。その過程で、同じ「売上」でもPOSによって持ち方が大きく違う箇所が次々に見つかりました。個々の判断は、すべて次の5つの原則から導いています。
| 原則 | 内容 |
|---|---|
| 全部受け取る | POSが出している値には必ず受け皿を用意する。受け皿が無ければ、標準の側を直す |
| 作らない | POSが出していない値を、推測や既定値で埋めない。それらしい値は誰にも見分けられない |
| 原本のまま、意味は設定で | コードと名称は出された形のまま持つ。何を意味するかは企業ごとの設定で読み替える |
| 国際標準の語に揃える | ARTS POSLog と電子レシート標準の定義に合わせる。独自に作るのは両者に無いところだけ |
| 数が合うことで確かめる | 変換の前後で数が合うことを実データで確かめる。検算が効いていることも確かめる |
2-2. 明細で持ち、POS自身の日計と突き合わせる
標準は、POSのデータを明細の単位で持ちます。そのうえで、標準の明細からPOSの集計を再現し、POS自身が出した日計と突き合わせることで、データの正確さを担保します。合わなければ、変換か標準のどちらかを直して、もう一度流します。この繰り返しで、文書の上では見えなかった標準の穴が多数見つかりました。
取消と打ち消しの区別、「値が無い」と「0」の区別、分割会計の二重計上は、いずれも実データでなければ見つかりませんでした。
2-3. 商品の持ち方
| 項目 | POSごとの違い | 標準での持ち方 |
|---|---|---|
| 商品分類 | 外食は2〜3段、小売は4〜5段が普通。自社の分類と業界共通の分類を併せ持つPOSもある | 段の数を決めた列ではなく、1つの商品に「分類の札」を何枚でも付けられる子表で持つ。札は電子レシート標準の17種類から選び、何段目かは別に持つ。これまでの3段の列は、子表から取り出した便利な列として残す |
| メニューの親子(サブ・オプション・セット) | トッピング、調理の指示、セットの中身の記録の仕方が4通りに散らばっていた | すべてを商品明細の行にし、親の行と関係の種類を書く。関係の種類は国際標準どおり3つ(調理指示/関連する行/セットの構成品)。セットは親の金額だけを売上に数え、二重にしない |
| SKU(色違い・サイズ違い) | 親の商品を持つ場所がなかった | SKU は階層ではなく「札」として、分類と同じ子表に Style(親の商品)と SKU(単品)を付ける。色・サイズ・容量・味などの属性は、国際標準に無いため OFSC の拡張として持つ |
2-4. 金額の持ち方
| 項目 | POSごとの違い | 標準での持ち方 |
|---|---|---|
| 商品の価格の段階 | 定価・通常の売価・実際の売価のどれを出すかがPOSごとに違う | 3つを別々の値として持ち、その間の値引は「価格変更の記録」として国際標準の方式で残す。季節やランチ・ディナーの価格の違いは値引ではなく、価格帯として持つ |
| 伝票全体への値引の按分 | 按分して明細に書くPOSと、伝票の合計から引くだけのPOSがある。端数の寄せ方もばらばら | 伝票全体の値引は伝票の側で正として持ち、商品ごとへの按分はPOSが出した値を持つ。按分の端数処理は設定として持つ |
| 支払の種別 | 同じPOSの同じコードが、企業によって「掛け」「クレジット」「コード決済」と別の決済を指していた | コードは原本のまま持ち、意味は企業ごとの読み替えの設定で決める。標準は3段の分類(種類・サブ種類・ブランド)で受ける。ブランドを出さないPOSのために「ブランド未提供」を用意し、特定のブランドを代わりに入れない |
| 税 | 内税・外税・非課税の表し方だけで3通り以上。1枚の伝票に店内飲食と持ち帰りが混ざる | 税率を列の名前に埋め込まず、伝票に税率ごとの枠を5組持つ。税率が増えても変わっても、標準の形は変わらない |
2-5. 取引の持ち方
| 項目 | POSごとの違い | 標準での持ち方 |
|---|---|---|
| 取消・返品・打ち消し | 数量をマイナスにした行で打ち消すPOS、取り消した行に印を付けるPOS、最終結果しか出さないPOSの3通り | 会計の前に取りやめた「キャンセル」、会計の後の「取消」、売った後に戻された「返品」、別の行を打ち消す「打ち消し」を、別の状態として分ける。数量は常に正で持ち、向きは状態で表す |
| 分割会計 | 親の伝票と子の伝票の両方に同じ金額を載せるPOSがあった(ある企業で売上の約6.5%が二重) | 伝票どうしの親子関係で表し、同じ金額を持つ場合は親だけを数える |
| 「値が無い」と「0」 | 出さない項目を0・空白・印の値で埋めるPOSがある | 「出していない」「区別していない」「全部まとめた」「本当に0」の4つを別の表し方にする。既定値で埋めない |
| 営業日と時刻 | 時と分だけを出し、日付も秒も持たないPOSがある。深夜営業では暦の日付と営業日がずれる | 営業日の境目を店舗ごとの設定として持ち、日付をまたぐ時刻を正しく解く。秒を出さないPOSの秒は作らない |
例えば、ラーメンを3杯注文し、あとから2杯を1杯ずつ取り消した場合、打ち消しの行を「取消」として扱うと、取消の行は集計に含めないため、売上は3杯のまま残ります。「打ち消し」という状態を設けて相手の行から引くことで、売上は 3 − 1 − 1 = 1杯となり、POS自身の日計と一致することを確認しています。
2-6. 国際標準に無いところは、OFSC の拡張として明記します
標準の構造と英語の物理名は ARTS POSLog から、日本語の名称は電子レシート標準から取っています。両者に無い概念(色・サイズなどの属性、企業が自由に決める区分など)は、OFSC の拡張であることを明記して持ちます。
色・サイズなどは本来、商品マスターの側で持つべき情報です。商品マスターの扱いは小売側での議論を踏まえて見直す可能性がありますが、V1.0 では出力データの使いやすさを優先し、拡張として標準の側でも受けられるようにしました。
3. 電子レシートでできるようになること
3-1. 標準データから、電子レシートがそのまま出る
標準データと電子レシート標準は、同じ国際標準(ARTS POSLog)を土台にしています。データの出どころが同じなので、標準データが固まれば、そこから電子レシートの標準データをそのまま出力できます。 標準データは管理会計・財務会計のデータを揃えるだけでなく、業界のデータ活用を進める入口にもなります。
3-2. どのPOSの店でも、ポイントを貯めて使える仕組み
以下は、標準の電子レシートがあれば技術的にこう実現できる、という仕組みの説明です。特定のポイント事業者や運用方式を評価・推奨するものではありません。
共通ポイントがすべての店に広がらない理由は、ポイントの仕組みそのものではなく、店のPOSと1社ずつ個別につなぐ導入方式にあります。接続の費用が合わない中小の飲食店などでは、「貯まるだけ」「使えない」店が残ります。
標準の電子レシートは、会計の瞬間にPOSからポイント事業者へ通信せず、POSの取引記録を日次で集める仕組みです。それでも、次のようにすれば「貯める」と「使う」の両方を、特定のPOSに限らず成立させられます。
| 流れ | ポイント | |
|---|---|---|
| 貯める(付与) | 会計時にPOSで会員コードを読む → 伝票に会員IDが残る → 翌日、電子レシートとしてポイント事業者に渡り、事業者が自社のルールで付与を確定する | 付与は翌日の確定でも客が損をしない。明細が届くので、商品ごとの倍率も事業者の側で計算できる |
| 使う(利用) | 客がアプリで使う額を先に確定する → ポイント事業者のサーバで残高を減らす → 1回限りの割引券コードを発行する → POSはそれを割引として処理する | 残高を持つのはサーバ1か所なので、二重利用は起きない。POSへの書き込みは要らない |
| 突き合わせ | 翌日、電子レシートに残った割引券コードと、発行した割引券を1件ずつ照合する | 使われなかった券は残高に戻し、発行していない券は精算しない |
ポイント事業者は、標準の電子レシートを受け取る口を1つ作れば、POSメーカーごとの個別接続なしに、標準に対応したすべてのPOSの店に届きます。これは既存の加盟店の運用を置き換えるものではなく、いま経済的に届いていない店に届くための道です。必要な項目(会員の口座、付与、利用、後からの付与)は、国際標準の POSLog にすでに定義されています。
3-3. 電子レシートをハブに、アプリがつながる
1つの店だけのアプリが広がりにくいのは、年に数回しか行かない店のためにアプリを1つ増やしても、使い道がその店に行ったときだけに限られるからです。
標準の電子レシートを通して、家計簿、食事の記録、経費精算、福利厚生、保証書の管理、共通ポイントなど、消費者がふだん使っているアプリとつながれば、使い道が増えます。消費者が自分でアプリどうしの連携をオンにする形は、銀行の口座と家計簿アプリをつなぐ仕組みに近い考え方です。
データを渡す先は、①審査を通ったアプリ・事業者であること、②店舗(企業)の方針で許可されていること、③消費者本人が同意していること、の3つを前提とします。アプリが何を提供するかは各社の競争領域です。
広がる順序としては、まず標準データができ、次に電子レシートの出力ができ、最初のアプリが用途ごとに展開していく、という段階を踏みます。
4. 当日の主な議論
当日は、説明の途中でも随時ご発言をいただく形で進めました。以下、主なやり取りをご紹介します。
4-1. 電子レシート国際標準との対応 ── これから正式に対応表を作ります
電子レシートの国際標準とのマッピングはできているのか、今の仕様に合わせれば電子レシートの国際標準も同時に実装できるのか、というご質問をいただきました。
標準の構造と英語の物理名は ARTS POSLog から、日本語の名称は電子レシート標準から取っており、電子レシート標準の日本語名称も POSLog を訳したものです。そのため基本的には対応がとれている認識で、新しく作らざるを得なかった概念を除けば、おおむね対応しています。正式な対応表(マッピング)は、これから作成します。
4-2. ポイント連携は、各社にとって実現できるのか
参加者から、既存のポイントの仕組みはそれぞれのネットワーク内での運用を前提に作られているものが多く、外部とつなぐには相当のハードルがあるだろう、とのご指摘をいただきました。共通ポイント各社についても、1つずつ標準の電子レシートとつなぐにはハードルがありそうだ、とのご意見がありました。
分科会長からは、本日の説明はあくまで理屈の上で実現できる仕組みの説明であり、実際につなぐところのハードルの高さはご指摘のとおりである、とお答えしました。
4-3. 決済・ポイント・クーポンには、踏み込みすぎない
決済・ポイント・クーポンは、いわゆる経済圏の取り合いが起きている、とてもセンシティブな領域であり、標準化団体の場で「こうした方がよい」とまで踏み込まない方が、組織の位置づけとしてよいのではないか、とのご意見をいただきました。本日の説明が仕組みの説明に留まっていたことは良かった、というご評価もいただいています。
あわせて、決済の分野には他の業界団体や標準化団体もあるため、それらとの棲み分けや位置づけを意識した運営が必要だ、とのご指摘もいただきました。分科会としても、この点を踏まえて進めます。
4-4. 日付の持ち方と、全体の接続構成
日付はどのような形で持つのか(年月日と時刻に分けるのか、UNIX時間のような整数にするのか)、というご質問をいただきました。標準は伝票ごとに日時を持ち、店舗ごとに営業日の境目(日付変更時刻)を設定できるので、深夜営業や早朝営業、24時間営業の店でも、営業日を正しく扱えます。日時の具体的な表し方は、解説資料でお答えします。
また、全体の接続の構成(API がどのような形になるのか)が1枚の図で分かるとよい、とのご要望もいただきました。これに対し、個々の変換の仕組み(ゲートウェイ)の設計は各社が自由に作る競争領域であり、本分科会は標準データの仕様書を策定する場として、そこに集中する、と整理しました。
4-5. 仕様の開示時期と、小売・外食の読み分け
自社でPOSを開発中のため、仕様をできるだけ早く開示してほしい、とのご要望をいただきました。外食部分の仕様はほぼできあがっており、小売のデータを反映する際に一部の入れ替えが生じる見込みである、とお答えしました。
あわせて、小売と外食のデータを入口で分けずに一緒に読ませると、かなりの誤解が生じることが分かってきた、という点を共有しました。この店舗は外食、この店舗は小売、というように業態を設定したうえで読み分ける仕様とし、その前提条件を仕様書と説明書に明記します。
4-6. 税の扱い
内税・外税、店内飲食・持ち帰り、明細への税額の配分と端数処理について、参加者の間でご意見が分かれました。小売でも内税・外税は設定できるので気にしていない、というご意見や、免税品を扱う店はみな同じ考え方ではないか、というご意見、今後の税制改正で食料品の税率だけが変われば外税が主流になるのではないか、というご意見をいただきました。
分科会長からは、標準は日本の現行制度だけに合わせるのではなく、今後税率が変わっても増えても使えるように作っていること、そのうえで、小売のPOSと外食のPOSでは税の持ち方が実際に違っており、業態を渡さずに読ませると混乱したことをお伝えしました。口頭では十分に整理しきれなかったため、例を付けた資料で改めてご説明します。
4-7. 小売にとって、POSデータの標準は必要か
小売のPOSに携わる方から、「POSデータの標準化は、小売では誰も困っていないのではないか」という声が寄せられていることが紹介されました。
分科会長からは、次のようにお答えしました。小売の大手では、全店舗でPOSを統一し、基幹システムも統一するのが当たり前です。一方、外食では、大手でも1つの企業の中に複数のメーカーのPOSが混在しているのが普通で、日計の出し方も、支払種別の運用もばらばらです。そのため、POSごとに出力したデータを手作業で合わせて会計に入れている実態があり、外食のほうが解決を急ぐ必要があります。小売でも、POSを入れ替えるたびにデータを作り直す負担は存在しています。また、小売は流通の出口、外食は各店がメーカーという違いがあり、小売にとっては商品マスターの標準化の優先度が高い、という声も聞いています。
これに関連して、小売は商品マスターが中心であり、今後は2次元のバーコードによる商品マスターの扱い(いわゆる Sunrise 2027)も出てくるため、飲食とは大きく違う、とのご指摘もいただきました。
4-8. 小売と外食を1つの標準にするハードル
小売のデータを取り込むことは大きな進展だとしたうえで、外食と小売は相反するとまで言えるかもしれず、同じ標準にするハードルは非常に高いだろう、とのご意見をいただきました。
分科会長からは、小売に合わせることで外食の使い勝手が悪くなるおそれは正直あるとお答えしました。ご提供いただく小売大手1社のデータは、多くの業態と幅広い商品を扱いながら、社内で完全に標準化されています。これを手本として標準とぶつけて差分を見て、次に外食との差分を見たうえで、どこをどう詰めるかを決めていきます。
4-9. 物販の併売と、決済まで完結するモバイルオーダー
POSベンダーのサポートに携わる方から、飲食店でもお土産などの物販を扱う企業があること、また、客が自分のスマートフォンで注文して決済まで済ませるモバイルオーダーには、そもそもPOSが入っていないことがあり、こうしたケースはどうなるのか、とのご質問をいただきました。
決済まで完結するモバイルオーダーについては、1社のデータを見ていますが、現時点では仕様への取り込みを保留しています。オーダーの入力として扱えば標準と合わせられますが、決済まで含めると足りないロジックがあるためです。今後、標準データの仕様書ができることで、「経理や監査のために最低限これが必要」という基準を、開発する側にお渡しできるようになると考えています。
また、企業ごとの運用によって、支払種別や掛売りなどが誤って入力されているデータも多く見つかっており、これをどう統合するかは残っている課題です。
4-10. 取消・返品の考え方と、時間軸の違い
飲食と小売では、値引・返品・取消の考え方が違う、とのご指摘をいただきました。飲食では、3杯頼んだうちの1杯を取り消すような注文ごとの取消や、一度取り消して入れ直す運用があり、小売では返品が中心になります。
小売は商品を登録してすぐに会計になるのに対し、後払いの飲食では注文が積み重なり、数時間後に会計になります。券売機のように先に会計するものもあります。こうした時間軸の違いを、はっきりと書き出しておかないと混乱が起きるため、説明書で明文化します。
4-11. 小売の検討の進め方
小売のデータを取り込むことには前向きに取り組むべきだが、小売のメンバーにも最初から入ってもらい、一緒に検討を始めるべきであり、後から結果だけを共有するのは良くない、とのご意見をいただきました。これを受けて、小売のメンバーと関係者への参加の呼びかけを行うことになりました。
また、1社のデータだけでなく、業界で広く使われている小売POSのデータがあると説得力が増すこと、小売POSのシステムベンダーにも「こういうことを始めます」と知らせておくべきこと、とのご意見もいただきました。仕様書のフォーマットが分かれば足りるのではないか、というご意見に対しては、本番のデータは仕様書だけでは見えないことが非常に多く、サンプルのデータとも振れ幅が大きく違うため、本番データでの検証が欠かせないことをお伝えしました。
5. 今後の進め方
当日の議論を受けて、次の点を確認しました。
| # | 内容 |
|---|---|
| 1 | 小売大手1社のデータを取り込み、外食との差分を確かめたうえで、V1.0 の仕様を調整してリリースする |
| 2 | 小売のメンバーと関係者へ、検討への参加を呼びかける。業界で広く使われている小売POSのデータの提供にも協力を募る |
| 3 | 電子レシート国際標準との正式な対応表を作成する |
| 4 | 仕様が正しいことを示す検算の資料を作成する |
| 5 | 仕様書と現時点までの検討資料を、分科会の参加者へ順次共有する |
| 6 | 標準データの解説資料を、サイトで新たに公開していく |
6 の解説資料は、本日「口頭では説明しきれない」とお伝えした点を、表と図で丁寧にご説明するものです。V1.0 を「どういう考え方で、どんなルールで定義したか」を中心に、業態の識別と前提条件、税の扱い、支払種別、日付と営業日、取消・返品と時間軸、電子レシートとの対応などを、具体例とともに取り上げます。標準データを取り込んで集計や基幹のシステムを作る方にも、仕様の前提が分かる内容を目指します。解説資料は本レポートとは別のページとして、準備が整ったものから順次公開します。
分かりにくい点や、可視化してほしい内容がございましたら、下記のお問い合わせフォームから、または分科会長まで個別にお寄せください。順次資料に反映します。
次回開催
| 日時 | 2026年10月26日(月)14:00〜15:30 |
|---|---|
| 形式 | WeWork 神田スクエア 11F(対面)+ オンライン(Zoom)ハイブリッド |
| 予定議題 | 1. 小売データの反映状況と V1.0 リリースに向けた確認 2. 標準データ解説資料のご説明 3. 電子レシート標準との対応 |
本レポートに関するお問い合わせ、分科会への参加ご希望はデータ標準化分科会ページのお問い合わせフォームよりご連絡ください。アンケートのみの参加、ロゴ掲載のみのご賛同も歓迎しております。中食・小売企業からのご参加・ご賛同も歓迎しております。