第8回 データ標準化分科会 活動レポート

会合の概要

第8回データ標準化分科会は、標準フォーマット V1.0 の中身を、実データの裏づけとともにご報告した回となりました。V1.0で何を出すのか、どこまでをスコープに入れ、何を今回は外したのか。そして、その線引きが何を根拠に決まったのかを、実測の数字とともにご説明しています。

実データ検証では、ターミナル系POSの全検算に合格し、券売機系についても変換の骨格が成立していることを確認しました。あわせて、前回公開版から標準に追記された事項が現時点で28項目に達していることをご報告しています。いずれも仕様書の読み解きではなく、実データの突合から出てきたものです。

スケジュールについては、これまで前倒し基調としてご報告してきましたが、実データを入れるたびに仕様書だけでは分からない差分が出てくるため、その吸収に想定より時間がかかっている旨を率直にお伝えしました。早く出すことよりも、実データに合うことを優先します。そのうえで、9月中の仕様確定、秋のV1.0正式公開という期限は維持します。

本レポートに登場するデータは、すべて企業名・店舗名・POSメーカー名を伏せた形で扱っています。商品名の例はすべて架空のものに置き換えています。

1. V1.0で何を出すのか

1-1. 標準が置かれる場所

POSの生データは、メーカーごと・機種ごとに形がバラバラです。これをどのPOSでも同じ形になる明細に変換し、会計・BI・本部システム、そしてAIや分析といった「使う側のシステム」へ渡す。標準が置かれるのは、この中間の位置です。

仕様は公開しますので、POSメーカー側で標準に沿った出力を実装いただくことも歓迎です。いずれの方式も選べます。

1-2. 標準は「集計」ではなく「ログ」を定義します

各社のPOSは、それぞれ独自のルールで日計を出しています。そのルールは公開されておらず、会社によって「客数」の数え方も「値引後」の意味も違います。その集計値をそのまま流通させても、企業をまたいで比べられません。

一方、1回の会計で何が何個いくらで売れたかという明細は、どのPOSも必ず持っています。ここを揃えれば、集計はあとから何通りにでも作れます。V1.0が最初に扱う領域は、売上管理と会計連携です。もっとも困りごとの大きい領域から着手しています。

なお、日計・時間帯集計も標準の出力に含めますが、これは上流の集計値をそのまま流すのではなく、標準明細から算出したものです。上流の日計は「突合の相手」として使います。

1-3. 1回の会計が、どう分解されるか

4名で来店し、生ビール2杯・から揚げ1皿・雑炊1つ。支払は現金2,000円とクレジット1,900円。この1会計は、標準では次のように分解されます。

出力先	行数	中身
伝票明細	1行	店舗・営業日・端末番号・伝票番号／客数4／着席18:12・初回オーダー18:15・会計19:41／合計3,900円／店内飲食
商品明細	3行	生ビール ×2 単価600 税率10%／から揚げ ×1 単価780 税率10%／雑炊 ×1 単価1,320 税率10%　── 各行に商品コード・部門・税率の出所を持つ
支払明細	2行	現金 2,000円／クレジット 1,900円（ブランドはコードで保持）
入出金明細	随時	ドロアの現金増減、釣銭の補充・回収、金種ごとの枚数
運用イベント	随時	点検・精算・開局閉局・訓練モードなど、会計以外のレジ操作
日計／時間帯集計	日次	上の明細から算出。15分・30分・1時間などの粒度は利用企業が選択

この形になっていれば、POSを入れ替えても、出てくるデータの形は変わりません。

1-4. V1.0で出力するデータ

データ	対応する国際標準の概念	内容
伝票明細	RetailTransaction	1会計単位のまとまり
商品明細	LineItem	何が、いくつ、いくらで売れたか
支払明細	Tender	現金・カード・各種決済の内訳
入出金明細	—	レジ現金の動き・残高・金種内訳
運用イベント	Control Event	点検・精算・開閉局など会計以外の操作
日計集計	—	1日単位の集計（標準明細から算出）
時間帯別 伝票／商品／支払 集計	—	15分・30分・1時間などの粒度を利用企業が選択

命名は米国標準規格 POSLog に準拠しています。日本語名称は電子レシート標準で定義済みの名称を引用しました。独自ルールを新設せず、国際標準との整合を優先しています。

2. V1.0のスコープ

2-1. 入れたもの

• 内税の按分 — 伝票単位で付与された内税を、商品明細へ配分する処理に対応します。
• 3つの価格を保持 — カタログ価格・税込販売価格・税抜販売価格をそれぞれ持ちます。
• 端数処理は企業ごとに選択 — 総合計に合わせるか、明細単位で整えるかを利用企業が選べます。
• 対象業種 — 外食・中食を主軸としつつ、小売もミニマムで対応します。お預かりした実データに物販が含まれていたためです。税を商品単位で持つ仕様と、伝票単位で持つ仕様の両方を吸収します。

今回あらたにスコープへ加えたものは、次の4点です。

• 運用イベント — 点検・精算・訓練モードなど、会計以外のレジ操作を独立したデータとして定義しました。
• 現金の金種内訳 — ドロア・コインディスペンサ別に、金種ごとの枚数と金額を持ちます。
• 客層セグメント — 軸・コード・名称の縦持ちで受けます。
• 整合性検証用のメタデータ — 上流が申告する取引件数と合計金額を受け取り、突合します。

2-2. 今回は外したもの

外したもの	理由
商品明細への割引の紐付け	伝票単位の値引は扱います。「どの商品にどの割引が効いたか」までは今回見送りました。ご要望があれば検討します
顧客コード・会員情報	会員基盤はPOSごとに構造が大きく異なり、標準化の負荷が高いため
カード番号・交通系IC番号・承認番号	個人を特定しうる値は、業界標準として流通させるデータに持ちません。決済ブランドは持ちます
調理完了・料理提供の時刻	現時点で実装しているPOSが確認できていません。出せるPOSが現れた段階で追加します
商品マスタへの書き込みを伴う連携	権限設計の難易度が大きく上がるため、読み取り側から着手します
EC領域	将来のスコープとして認識を共有済み。実店舗とECの統合は課題として上がっています
ベンダー固有の項目	特定メーカーにしか存在しない項目は標準に入れません

「やらない」ではなく「V1.0には入れない」です。標準は公開して終わりにせず、維持・更新を続けます。

3. 公開する文書 ── 12本

• 辞書は、語彙・命名規則・値域を横断的に定義するものです。定義書はすべてこの辞書に従います。
• 運用規約集は、カラム定義では表現しきれない取り扱いのルールをまとめたものです。
• 設定ダッシュボード仕様書は、端数処理や集計粒度など、利用企業が選べる設定を定義したものです。

現在は仕様確定に向けた最終整備の段階です。対外公開は V1.0 が最初になります。

4. 実データ検証の結果

4-1. 検算の考え方

POSの生データを標準明細へ変換し、その明細から自力で集計した日計と、POS自身が出した日計とを突き合わせます。これを「検算」と呼んでいます。数字が合わなければ、変換が間違っているということです。

• 部門別・商品別・商品別×売上種別・担当者別・総合計・支払種別別 ── すべてを突合します。
• 一致率98%は不正解。100%以外は採用しない、を基準にしています。
• 1項目でも合わなければ、そこが標準の穴です。穴を記録して標準側に反映します。

4-2. ターミナル系POS ── 全検算に合格

4店舗・約1か月分について、110の店舗日すべてで全項目が一致しました。部門別／商品別／商品別×売上種別／担当者別／総合計／支払種別別のすべてです。

検証は、生データ起点と標準明細起点の2段階で再現しています。標準フォーマットに変換した時点で情報が落ちていないことの証明になります。

この4店舗には外食2店舗と小売2店舗が含まれていました。同一メーカー・同一フォーマットの配信の中に業態が混在しており、しかもデータ側に業態を示す項目がありませんでした。これが、小売をV1.0のスコープに入れる直接のきっかけになっています。

4-3. 券売機系 ── 検証中、骨格は成立

駅構内事業者よりご提供いただいた実機データ、3店舗・159営業日分（2026年3月〜8月）を検証しました。

• 売上金額・販売枚数・来店客数・現金の入出金は完全一致。機器が出力する日計値と、明細から積み上げた値が一致しており、変換の骨格は成立しています。
• 機器の設定・運用に起因して取得できない項目を10件、照会中です。設定変更のお願い3件／追加ファイル3件／仕様の確認4件。

券売機のデータは1行に多数の項目が横に並ぶ構造、標準は1件を1行として縦に積む構造です。この読み替えが最大の論点でした。

4-4. 仕様書だけでは分からないこと

券売機データの検証で実際に出てきた例です。いずれも仕様書には書かれていません。

仕様書に書かれていること	実データ
取引区分は 01〜2x の範囲で定義	定義にない 30 と 32 が出現。3店舗で件数が完全に一致し、日計側の「ポイント利用件数」とも一致（合計509件）。利用時の「要求」と「応答」と推定して照会中
メニューマスター番号は、設定が有効なら出力される	46,801行すべて空欄。メニュー側にコードが登録されていないと見られ、商品マスタと結び付かず、商品別集計が作れません
領収書発行枚数を出力する	明細では1,751件発行されているのに、日計は159ファイルすべて0。設定オプションが無効だったためです
払戻を記録する	払戻142件のうち130件で、元の販売を特定できない。紐付ける項目が仕様上ありません
メニュー名称	ある店舗では、全メニュー共通で名称の末尾に9桁の数字が入力されていました（例：かけそば123456789）

※ 商品名は架空の例に置き換えています。

5. 標準に積み上がったもの ── 実データが書き換えた28項目

前回公開版から、実データ検証を経て標準に追記した事項は現在28項目です。すべて実測が根拠です。ここでは主なものをご紹介します。

5-1. 取引を一意に識別する鍵

レシート番号だけでは、取引を特定できませんでした。

• 31営業日のうち28日で、レシート番号の重複が発生。6端末を運用する1店舗に集中しており、単一端末の3店舗では80営業日中0件でした。
• 取引1,410件に対し、レシート番号の異なりは983件。同じ番号が別の取引に振られており、区別できたのは端末番号だけでした。

営業日	端末	レジ番号	レシート番号	会計時刻	金額
2026-05-12	01	1	0342	12:04	1,180
2026-05-12	03	1	0342	18:47	4,620
2026-05-12	05	1	0342	20:15	2,950

レジ番号は全取引で同じ値、ヘッダの店舗内POS番号も全取引で同じ値。区別できるのは端末番号だけでした。

何が起きるか。「レシート番号0342を取り消す」という記録が来たとき、レシート番号だけで元取引を探すと、昼の1,180円の取引まで巻き込んで無効化します。

標準への反映。一意キーを（店舗・営業日・端末番号・レジ番号・レシート番号）の複合とし、取消元の参照も同じ複合キーで解決します。単一端末の店舗では絶対に顕在化しません。端末を増やした日に、静かに壊れます。

5-2. 取消は、種別ごとに扱いが逆になる

どちらも売上は差し引き0円です。しかし日計に残る形が違います。AとBを同じ「無効フラグ」で一律に除外すると、Bの負の行と突き合わなくなります。実際に、税区分が変わる訂正で内税が11円ずれ、担当者別集計で件数が1件ずれ、日計側に実在した「件数 −1／金額 −334」という負の行がこちらの集計には現れませんでした。

標準への反映。明細に符号（+1／−1）を持たせ、取消の種別を列挙値で必ず保持します（取引取消・レジマイナス・取消復旧・売上区分変更・返品）。符号だけでは、元取引を残すか外すかが決まりません。

5-3. 支払は、取引と独立に符号を持つ

取消53件のうち16件で、支払種別が元取引と違う種別に付け替わっていました。16件すべてがレジマイナス種別で、方向も全件「非現金 → 現金」。取引取消では1件も発生していません。

お客様はカードで支払い、返金はレジの現金から出しているためです。カード会社への請求は取り消されず、ドロアから現金が出ていきます。

標準への反映。支払明細を取引から独立した明細として持ち、支払明細レコード単位で符号を表現できる構造としました。

加えて、現金を支払明細に出さないPOSがあります（取引ヘッダの現金売上欄にしかない）。標準側で現金の行を1行生成し、「支払明細の合計＝取引金額」が必ず成立するようにしました。これがないと、支払種別の検算が原理的にできません。

5-4. 税率は、業務区分から導いてはいけない

ある物販店の1営業日、1,379明細。仕向はすべて「持ち帰り」でした。それでも税率は8%と10%に割れています。持ち帰りでも酒類・雑貨は標準税率だからです。

商品	仕向	税率	理由
焼き菓子詰合せ	持ち帰り	8%	飲食料品
おにぎり弁当	持ち帰り	8%	飲食料品
地ビール6本セット	持ち帰り	10%	酒類
保冷バッグ	持ち帰り	10%	雑貨

※ 商品名は架空の例です。

外食では「イートインか、テイクアウトか」で税率が決まります。小売ではその前提が成り立ちません。外食の常識をそのまま持ち込むと、金額としては妥当な値のまま、静かに誤ります。

税額から逆算する方法も使えません。税込105円・内税8円なら逆算値は8.25%、税込298円・内税22円なら7.97%。端数処理のため、同じ8%の商品でも逆算値が散ります。丸めて8%に寄せる実装は、軽減税率の境界で必ず破綻します。

標準への反映。仕向・売上種別からの税率導出と、税額からの逆算をいずれも禁止しました。税率は明細に実値で持ち（1/100%単位。10.00%は 01000、8.00%は 00800）、あわせて税率の出所を併記します。出所を残すことで、監査のときに「この税率はどこから来たのか」に答えられます。

5-5. 「客数」は、ひとつではない

同じ日・同じ店舗で、総合計ファイルの客数は76人、時間帯別ファイルの客数は62人でした。どちらも列名は「客数」です。差が出るのは卓番を持つ業態だけで、カウンター・物販では完全に一致します。

もう一方の定義を10通り、総当たりで検証しました（会計分割、グループ内の最大値／先頭値／最終値／最小値、グループ数など）。いずれも全営業日一致には至りませんでした。さらに、金額20,028円・取引1件に対して客数が0の行も実在し、客単価の分母として使えないことが分かりました。

標準への反映。明細から一意に再構成でき、POS自身が総合計で使っている定義を採用します。上流がもう一方しか出さない場合は、別名で保持し、定義不明であることをメタデータに明記します。

5-6. 固定列をやめて、縦に持つ

対象	実測でわかったこと
総合計の枠	112列の固定レイアウトのうち、同じ列位置が店舗ごとに別の意味を持っていた。ある店舗では商品券の金額、別の店舗では客数、別の店舗ではゼロ
支払手段	同一チェーン4店舗で登録数が 17／19／29／36 種類。交通系IC・コード決済・商品券・地域クーポン・デリバリー各社など、立地と運用で構成が変わる
客層セグメント	軸の意味自体がベンダー・店舗で異なる。あるベンダーは軸1=客層／軸2=年代／軸3=職業、別のベンダーの店舗では軸1=顧客区分14種／軸2=利用シーン8種
現金の金種	ドロア・コインディスペンサ別に、金種ごとの枚数と金額が日次で出力されていた（1万円札12枚＝120,000円、500円玉27枚＝13,500円 など）

標準への反映。いずれも固定列をやめ、コードと名称を伴う縦持ちで受けます。客層は「軸番号・コード・名称」に加えて軸の名称そのものもデータとして持つことにしました。軸番号だけでは意味が分からず、企業間で比較できないためです。

マスタがあるから使われている、とは限りません。客層マスタが配信されている3店舗すべてで、取引側の客層コードは全件未設定でした。

5-7. 商品名には、価格や仕入先が混ざっている

商品マスタには名称が2列あります。レジの操作画面に出る名称と、レシートに印字される名称です。

オペレータ向け名称	レシート名称	混ざっているもの
×炊込ごはん150	炊込ごはん	販売価格と操作記号
◆アイスティーＳ	アイスティーＳ	操作記号
幕の内弁当・山田屋	幕の内弁当	仕入先名
（白）ワイン	グラスワイン(白)	逆に、正式名称が欠けている

※ 商品名はすべて架空の例に置き換えています。

2つの名称の相違率は、あるベンダーの4店舗で 10.9%／50.2%／56.2%／81.9%。別のベンダーではほぼ0%でした。「常に同じ」も「常に違う」も前提にできません。また、価格が名称に埋まっているため、価格改定のたびに名称が変わり、同一商品が別商品として集計されます。

標準への反映。顧客向け表示名とオペレータ向け操作名を分けて持ち、分析・名寄せの既定は顧客向け名称とします。

5-8. 標準は、表記を「直さない」

同一商品コードで、期間中に名称が変わった例です。「緑茶ペット350」→「緑茶ペット３５０」（半角→全角）、「ミルクティ５００Ｐ」→「ミルク・ティー５００Ｐ」（中点の追加）、空欄→「純米吟醸」（登録の遅れ）。改定は稀で、1店舗あたり1か月に0〜4件程度です。

※ 商品名はすべて架空の例に置き換えています。

寄せれば「同じ」に見えます。それでも、標準側では寄せません。POSの名称は、店舗が現場で入力したものです。入力された値そのものが事実であり、標準は受け取った値をそのまま保持します。表記を直すのはPOS側の責務であり、標準側で寄せてしまうと「POSに何が登録されているのか」が追えなくなります。

名寄せの鍵は商品コード、名称は表示用と割り切る。これは標準化団体としての立ち位置そのものだと考えています。

5-9. 受け取る側が、壊れたデータに気づけること

• 日計は取引1,613件と申告、配信された明細は1,063件。550件の欠損です。ファイル自体は完結しており、途中で切れた痕跡はありません。突合して初めて分かりました。
• 同一内容のバッチが2組配信された日が実在しました（実測2日）。連番だけが違い、内容はバイト単位で同一。両方取り込むと全項目が正確に2倍になります。
• 同じコードが「013」と「␣13」の二通りで出力される。同じPOS・同じ営業日の中で混在しており、正規化を怠ると担当者別集計が全営業日で不一致になりました。

標準への反映。上流が申告する取引件数と合計金額を、整合性検証用のメタデータとして必ず受け取ります。取込時に突合し、合わなければ取り込まずアラートを上げることを受入要件としました。

金額が「きれいに倍」になる異常は、異常値検知をすり抜けます。発見が遅れると、原因不明の売上増減として調査に時間を溶かします。

5-10. 小売への対応で、何を変えたか

変えたこと	実測でわかったこと
業態区分をデータ自体に持たせる	同一ベンダー・同一フォーマットの配信に外食と小売が混在していたにもかかわらず、店舗マスタにも配信データにも業態を示す項目がなかった。店舗マスタ側だけに持つ設計にすると、過去データを再解釈できません
自社商品コードとJANの併存	小売では同一伝票に混在する。1店舗で商品コードの先頭が15種類に割れました
桁数でJANを判別しない	外食のある店舗は13桁の自社コードを使っており、形式ではJANと区別がつきませんでした
商品階層の格上げ	SubClass・SKU・UPC/EPC を「将来対応」から「V1.0対応」へ
カード会社コード	POSの社内マスタは1桁、実際の明細に入る値は決済端末が返す3桁の別体系。対応表なしには突き合わせられないため、生の値をそのまま保持します

前回、小売のSKU対応をできるだけ早期にスコープへ組み込む方針をご報告しましたが、今回、商品階層をV1.0対応へ格上げしました。

6. 標準文書そのものの中立性

• 標準文書からベンダー名・企業名・店舗名を全数走査で排除しました。
• ベンダー固有の変換情報は、標準文書の外へ物理的に分離しています。
• 本レポートでご紹介した28項目も、すべて「あるPOS」「あるベンダー」の表記で記述しています。

分科会長は実装にも関わる立場にあるため、仕様の最終決定には関与しません。分科会は方向性を整理して提案をまとめ、決定は理事会が行います。

運営規程 第27条（分科会長が単独で仕様を決定できない）／第13条（利益相反の防止）／知的財産権合意書（特定企業の特許権が標準仕様に影響しないことの担保）

7. 電子レシート標準化

本標準は、約20年前に策定されたPOSログの世界標準を全面的に参照して構築しています。同じ親を持つため、データ標準が固まれば電子レシート標準はほぼ自動的に完成します。仕様書はすでに存在し、日本語名称の定義も整っています。年内のスタートを目指します。

標準化された電子レシートを各社が実装すれば、企業アプリ間・ポイント間の連携を、事業者ではなく利用者自身が自分の端末上で組めるようになります。利便性が動機となって利用が広がり、結果として各社が取得できるIDデータが大きく増える ── という構図です。中小・個人店でも大手のポイントサービスを運用できる市場が生まれます。

8. スケジュール ── 率直なところ

これまで前倒し基調としてご報告してきましたが、実データを入れるたびに、仕様書だけでは分からない差分が出てきます。その吸収に、想定より時間がかかっています。本レポートでご紹介した28項目が、まさにその中身です。

早く出すことよりも、実データに合うことを優先しています。そのうえで、期限は切ります。

時期	内容
9月中	標準フォーマット V1.0 の仕様確定
秋	V1.0 正式公開（文書12本）
年内	電子レシート標準のスタート

開発の速度そのものは上がっています。AI活用により、1メーカー分の生データを解析して標準へ取り込むまでの所要が、従来の数か月規模から大幅に短縮されました。対応をご希望のPOSメーカー・利用企業がございましたら、分科会までお申し付けください。

9. 当日の主な議論

当日は、進行の途中でも随時ご発言をいただく形で進めました。以下、主なやり取りをご紹介します。

9-1. 内税と外税が同じ出力に混ざるとき ── 標準は「設定を伴う標準」です

外食の店舗で土産物や菓子を扱っている場合、同じ出力の中に内税と外税が混在します。これをどう表現するのか、というご質問をいただきました。

外食では、店内飲食か持ち帰りかを会計時に確定させるため、POS上での判定はまず問題なく行えます。ところが、小売の店舗と外食の店舗で、税の判定を同じトリガーの基準で作ると、そこで誤認が発生します。しかもこの差は、データだけを眺めていても見えません。

そこで標準では、店舗ごとの初期設定を先に与える方式を採ることにしました。この店舗は物販店なのか、店内飲食と持ち帰りの両方がある店なのか、券売機の店なのか、オーダーエントリーのある店なのか ── これを設定ダッシュボードで最初に登録します。設定を与えずに読ませたときには解釈できなかったものが、与えたとたんにきれいに読めるようになりました。免税の扱いも同じ枠組みで吸収します。

端数処理の丸め方についても、あわせてご質問をいただきました。総合計に合わせるのか、明細単位で整えるのか。明細単位で揃えると総合計は多少ずれますし、総合計に合わせると明細側がぶれます。実務では「8%が何品、10%が何品」という明細単位の見方をされることが多く、どちらを許容するかは業務の見方によって変わります。企業ごとに選んでいただく設定項目としました。

将来の税率改定にV1.0のまま対応できるか、というご確認もいただきました。税率を固定値で埋め込まず、複数の税率枠を持ち、それぞれに実値を設定できる構造にしてあります。改定があっても、また国外で運用する場合でも、仕様の作り直しは不要です。

9-2. 商品コードの桁数 ── まだ結論を出せていません

本標準で唯一、分科会長として最初期から挙げていながら、いまだに結論を出せていない論点です。この場でご意見を募りました。

商品コードの桁数はメーカーによって、また同じメーカーでも世代によって異なります。あるメーカーの旧い機種は4桁、近年の機種は8桁、別のメーカーは当初から13桁です。やっかいなのは、短い桁のコードが、桁の位置そのものに意味を持たせていることでした。1桁目が大分類、次の桁が中分類、残りがメニュー ── という構造です。13桁に揃えるために先頭へゼロを詰めると、この構造が崩れます。

13桁に統一すべきか、桁はそのまま保持すべきか。各社でどのように解決されているか、ご知見をお持ちの方がいらっしゃいましたら、ぜひ共有いただけますと助かります。

関連して、企業コードが全店舗で同一値になっているケースもありました。1台ごとに独立して販売されてきた世代の設計で、企業をまたいだ運用が想定されていません。こうした前提は標準側で吸収し、企業の区別を持たせる必要があります。

9-3. 割引・クーポンの商品明細への紐付け ── ご意見を受けて再検討します

割引やクーポンをどう扱うのか、というご質問をいただきました。商品ごとの値引も、伝票単位の値引・割引も標準に入ります。割引率まで含めて明細として保持します。

今回スコープから外していたのは、伝票単位の値引を商品明細へ按分して戻す処理のほうです。税の按分だけでも設定が複雑になるため、いったん見送っていました。

これに対し、小売を対象に含めるのであれば既定で持っておいたほうがよい、というご意見をいただきました。惣菜や弁当のように時間の経過とともに値下げしていく販売では、どの商品にどれだけの値引が効いたかが分析の要になるためです。カラムを一つ加えれば対応できる見通しが立っていますので、V1.0での対応を再検討します。

9-4. 支払手段の併用、ポイント、返品

クレジットとポイントと現金を組み合わせて支払った場合でも、商品明細まで揃うのか。揃います。支払明細を1行ごと独立して持ち、伝票単位ではなく支払単位で情報を保持する構造にしているためです（本レポート 5-3 でご説明した設計です）。

ポイントは、付与・利用のいずれにも対応済みです。企業独自のハウスポイントと共通ポイントの併用も扱えます。商品ごとにポイントの倍率が異なる運用があるとのご指摘もいただきました。小売では珍しくない設定です。

返品についても、取消の種別ごとに一つずつ定義しています。この領域はメーカーごとに名称も扱いも大きく異なり、仕様書だけでは判断がつきませんでした。生データにあたることで、ようやく整理できた部分です。

9-5. 時間帯別と総合計で客数が違うのは、なぜか

本レポート 5-5 でご報告した「同じ列名なのに値が違う客数」について、なぜずれるのか、というご質問をいただきました。

集計している測定ポイントが違うからです。会計時の人数なのか、注文時の人数なのか。居酒屋業態のように、途中で人数が変わる運用では、どこで数えたかによって値が変わります。あるメーカーでは、予約時・着席時・お通し提供時・オーダー時・会計時など、1つの取引に対して複数の地点で客数を測定していました。

標準では、上流が曖昧に持っている値をそのまま流すのではなく、どの地点で測った人数なのかを明示したうえで受け取ります。そうしておけば、複数のPOSが混在していても比較できるデータになります。

9-6. 標準への準拠を、どう示すのか ── 認証の考え方

「標準に準拠しました」というお墨付きは、どういう形で出るのか。実務的に重要なご質問をいただきました。

考え方としては、ベンダーが自社の変換で標準データを出力できるようになった段階で、その出力をOFSC側で突合・検証し、問題がなければ準拠の認証を発行するという形です。検証に用いるテストツールも、あわせて用意します。

認証の運用条件については、理事会で審議のうえ決定されます。

9-7. 実データのご提供 ── 上流の運用まで含めた確認が必要になること

券売機データをご提供いただいている駅構内事業者より、実務上の制約についてご説明をいただきました。

券売機側が持っていない項目があり、基幹システム側で変換をかけて数字を出している部分があるとのことです。過去に複数メーカーの券売機を併用してきた経緯があり、その変換マスタがないと商品が特定できません。この変換マスタを提供できるかどうかを、あらためて確認いただくことになりました。

また、なぜその設定になっているのかは、経緯を遡らないと分からないものがあり、変更できるもの・できないものの切り分けもあわせて確認いただきます。分科会としては、標準データは上流の値を「あるがまま」に受け取ることを原則としつつ、検証を先に進めるために上流で変換済みのデータをお預かりする、という選択肢も併せて検討します。

実データのご提供にあたっては、こうした「なぜこの値なのか」という運用側の事情まで含めて確認させていただくことになります。お手数をおかけしますが、できる範囲でご協力いただけますと幸いです。

9-8. 電子レシート標準の現在地

いまの電子レシート標準は、実際に使われているのか。率直なご質問をいただきました。

規格そのものが固まったのは2024年、国際的な標準化団体の承認を得たのが2025年です。それ以前から電子レシートを実装してきた事業者のフォーマットは、似てはいるものの、完全には一致しません。結果として現時点では、国際標準に完全準拠した電子レシートの実装は確認されていない、というのが実情です。

本標準は同じ親（POSログ）を参照して構築しており、日本語名称も電子レシート標準で定義済みのものを引用しています。標準データが固まれば、電子レシートへの接続はそのまま行えます。この点を、あらためて共有しました。

9-9. 商業施設分野からの期待

商業施設分野からご参加の方より、次のようなご発言をいただきました。

商業施設では、出店されているテナントから施設側へ、日次で売上と客数の報告が行われています。この報告の標準化・システム化を進めたいと考えており、本標準に相乗りさせてもらいたい、というご要望です。テナント側は前向きである一方、施設側では費用対効果の見極めで足踏みしている状況とのことでした。

また、2019年に施設のアプリへ電子レシートを組み込んだものの、出店テナント側に使う意味を感じてもらえず、実装後まもなく終了した経緯もご紹介いただきました。施設が各店舗の販売データを集めてマーケティングに活かすことには大きな意義があり、次のステップとして期待しているとのお話です。

中食・小売・商業施設の各分野からのご参加・ご賛同も歓迎しております。

10. 実データのご提供・賛同ロゴのお願い

10-1. 実データのご提供

Gatewayの実装・運営は、本分科会の外で進めることになりました。したがって、この場で「使うか、使わないか」をご判断いただく必要はありません。実データをお預かりする目的は、御社のデータ構造が漏れなく入った標準フォーマットを作ることです。

そこまで到達できれば、実装は御社ご自身で行っていただくこともできますし、御社が現在お使いの基幹システムや中継システムのベンダーに行っていただくこともできます。標準に沿って作られる限り、どこが実装しても同じものが出てきます。逆に、御社の形が入っていない標準のまま各社が実装を進めれば、結局は個社ごとの実装に戻ります。

お願いしたいのは、複数業態・複数店舗・3か月程度のサンプルデータと、あわせて出力仕様書です。

V1.0の網羅性は、中堅・大手企業の多業態データをお預かりして初めて上がります。本レポートでご紹介した差分は、いずれも単一業態・単一店舗のデータでは顕在化しないものばかりでした。レシート番号の重複は複数端末の店舗でしか出ませんし、客数の2種類は卓番を持つ業態でしか差が出ません。仕向と税率のずれは小売でしか出ません。

取り込みの速度そのものは大きく上がっています。「このPOSも対応してほしい」というご要望があれば、優先順位のご相談ではなく、そのままお申し付けください。順次進めます。

10-2. 賛同ロゴのご提供

一社の取り組みに見えているうちは、標準になりません。ロゴ掲載は本活動の方向性へのご賛同を示すものであり、特定製品の採用を約束するものではありません。無料・自動更新の条件で、広く受け付けています。中食・小売企業からのご賛同・ご参加も歓迎しております。

次回開催

日時	2026年9月29日（火）15:00〜16:30
形式	WeWork 神田スクエア 11F（対面）＋ オンライン（Zoom）ハイブリッド
予定議題	1. 標準フォーマット V1.0 の仕様確定報告 2. V1.0 正式公開に向けた文書12本の確認 3. 電子レシート標準化の進め方

同日17:00より企業システム分科会が連続開催されます。分科会間の交流の場として、あわせてのご参加も歓迎しております。

本レポートに関するお問い合わせ、分科会への参加ご希望はデータ標準化分科会ページのお問い合わせフォームよりご連絡ください。アンケートのみの参加、ロゴ掲載のみのご賛同も歓迎しております。