電子レシートとPOSログは別物だ
── 飲食業データ構造の本質に迫る

はじめに

前回のコラム「標準は何度も作られた。それでも普及しなかった ── 飲食業POSデータ標準化の25年史」では、25年にわたる飲食業POSデータ標準化の系譜を辿りました。その中で「電子レシートとPOSログは補完関係であって代替関係ではない」と述べましたが、これは業界の議論で繰り返し混同される、極めて重要な区別です。

今回はこの「補完関係」の中身を、データ構造の側から解きほぐします。両者は同じ「取引」を扱っているように見えながら、まったく違う問題を解こうとしている ── これを理解することが、標準化議論を前に進めるための最初の一歩です。

1. 「データ」とひとくくりに語ってきた弊害

業界で「POSデータの標準化」が語られるとき、しばしば電子レシートとPOSログが混同されます。「電子レシートが世界標準になったのなら、POSデータの標準化は完成したのではないか」── そう問われることがあります。

結論から言えば、違います。電子レシートが標準化されても、POSログの標準化は別問題として残ります。両者は別の対象を、別の目的で標準化しているからです。

「データ」とひとくくりに語ってきたことが、業界全体の議論を曖昧にしてきました。25年の標準化失敗の系譜にも、この混同が影を落としていたと言えます。本稿では両者を切り分けて整理し、それぞれが解こうとしている問題と、それぞれが必要とする構造の違いを明らかにします。

2. 電子レシートとは何か ── 取引証跡として

電子レシートは、店舗が消費者に対して発行する会計の証拠です。紙のレシートをデジタル化したもの、と言うと単純すぎますが、本質はそこから大きく外れません。

主な構成要素

• ヘッダ情報：発行日時、店舗識別、レジ番号、取引番号
• 明細：商品ごとの名称、数量、単価、税区分
• 決済方法：現金、クレジットカード、QRコード等の内訳
• 合計：税抜・税込・支払額・釣銭

構造はほぼフラットです。レシートヘッダがあり、その下に明細行が並ぶ。会計が確定した瞬間のスナップショットを、消費者と店舗の双方に渡せる形式に固めたもの ── これが電子レシートです。

主な目的

電子レシートが解決しようとしているのは、消費者側のエコシステムの問題です。

• 家計簿・経費精算アプリでの自動取り込み
• 税務関連（特にインボイス制度対応）
• ペーパーレス化と環境対応
• 不正レシート発行の防止
• 消費者側でのレシート長期保存と検索性

これらの便益を業界横断で享受するには、各店舗・各POSが共通のフォーマットで電子レシートを発行できなければなりません。だからこそ、国際標準化が必要でした。

国際標準化の現状

2025年4月、OMG Digital Receipt API v1.0（DRAPI／formal/25-04-01）が世界標準として承認されました。OFSC代表理事の古幡整がOMG Retail Domain Task ForceのChairとして、この標準化プロセスを主導した経緯は前回も触れた通りです。日本国内では、経産省／NEDO事業が2018年に「標準電子レシートフォーマット仕様書」を公開し、町田市での実証実験（27店舗）でその有効性が示されています。

電子レシートは、すでに「標準が世界規模で存在し、実装も進みつつある」段階に入っています。

3. POSログとは何か ── オペレーション・ストリームとして

一方、POSログは別物です。POSログは、店舗運営における全イベントの時系列記録です。

「会計時のレシートをデジタル化したもの」ではなく、「店舗が稼働している間に発生する全ての操作・処理を、時系列で記録し続けたストリーム」と表現するのが近いでしょう。

主な構成要素

• 注文受付イベント（誰がオーダーを取ったか、何時何分に）
• キッチン投入イベント（オーダーが厨房に流れた瞬間）
• 提供イベント（料理が客に出された瞬間）
• 精算イベント（会計時の操作詳細）
• 訂正・取消イベント（押し間違い、空打ち、商品差し替え、卓移動）
• シフト境界イベント（オープン、クローズ、レジ精算、人員交代）
• 卓・組管理（テーブル番号、人数、滞在時間）
• 従業員イベント（誰がどの操作を実行したか）
• 日計集計（一日分の合計、業態別、時間帯別、商品別）

これらが時系列で連続的に記録されていく ── これがPOSログです。

構造の違い

電子レシートが「ほぼフラット」だったのに対し、POSログは階層的な構造を持ちます。

• 日（営業日）
  • 精算（シフト単位、レジ単位）
    • 取引（1卓1組、1会計）
      • 注文（オーダー単位、追加オーダーは別注文として）
        • 明細（商品単位）
          • 修飾子（トッピング、サイズ変更、無料サービス）

この階層構造の中で、注文時刻、キッチン投入時刻、提供時刻、精算時刻といった複数の時刻情報が記録されます。さらに訂正・取消・卓移動などの運用イベントが、時系列のどこに発生したかも記録されます。

主な目的

POSログが解決しようとしているのは、経営側のエコシステムの問題です。

• 売上分析（時間帯別、業態別、商品別、店舗別）
• ABC分析、メニュー戦略の見直し
• 人時生産性・人時売上・労働時間連動
• ロス管理、廃棄分析、原価管理
• 多店舗ベンチマーク、フランチャイズ統制
• M&A後の業態統合、本部の意思決定速度
• AIエージェントを用いた経営判断補助

国際標準化の現状

ARTS POSLog v6（2014年承認、2015年公開）が存在し、東芝テック、Epson、NCR等の主要POSベンダーが策定に参画しました。Foodservice variant（飲食業向け派生仕様）も明示的に組み込まれています。しかし、前回1-Aで述べた通り、仕様は存在するものの、業界実装は分断したままです。各POSベンダーが独自のCSV出力を進化させ続け、業界横断の経営・オペレーション分析を阻んでいます。

4. 同じ「1取引」を見ても、見えているものが違う

ここまでの抽象論を、具体的な情景で考えてみましょう。

ある夜、6人のグループがレストランに来店します。最初は1卓に着きましたが、途中で「4人と2人」に卓分けで会計したいと申し出ました。店員は卓を分け、追加オーダーを4人卓のみで受けます。最終的に、4人卓は法人カードで支払い、2人卓は片方が現金、もう片方がQR決済で割り勘します。途中、店員が一度商品を押し間違えて取消が入り、別の料理が改めて入力されました。

この1グループの来店から、データはどう生成されるでしょうか。

電子レシートの場合

最終的に発行されるレシートは2枚です。

• 4人卓のレシート（法人カード決済、商品リスト、税込合計）
• 2人卓のレシート（現金／QR分割、商品リスト、税込合計）

それぞれのレシートには「何を、いくらで、誰に、どう支払われたか」が記録されます。消費者側エコシステム（家計簿、経費精算、税務）にとっては、これで十分です。

POSログの場合

同じグループから、以下のイベント連鎖がすべて記録されます。

• 来店時刻、初期人数（6人）、テーブルアサイン
• 最初のオーダー（複数明細、それぞれ注文時刻）
• 商品の押し間違いと取消の操作ログ
• 訂正後の再入力
• キッチン投入時刻、提供時刻
• 卓分けの操作ログ（人数変更、卓追加）
• 追加オーダー（4人卓のみ）
• それぞれの会計操作（誰がレジを打ったか、何時に）
• 決済方法の内訳（4人卓：法人カード、2人卓：現金＋QR）
• グループの総滞在時間
• 卓ごとの客単価、グループとしての客単価

これが、両者を別の問題として扱わなければならない最大の理由です。

5. 飲食業がデータ構造的に難しい3つの理由

POSログの設計が難しいのは、飲食業の業務構造そのものが複雑だからです。3つの構造的な難しさがあります。

(1) 時系列イベントが多層的

小売業の取引は「商品をスキャン→決済」とほぼ単一の瞬間で完結します。一方、飲食業では「注文受付→キッチン投入→提供→精算」が時系列で分かれます。注文時刻と提供時刻のギャップは厨房の効率を示し、提供時刻と精算時刻のギャップは客の滞在時間を示します。これらの時刻情報を捨てると、飲食業の経営に必要な分析の半分が消えます。

(2) 取引境界が複雑

「1卓1組」「1会計」「1注文」── これらは別々の単位です。1卓に複数組が混在する場合、卓分け会計、卓移動、追加オーダー、シフト跨ぎなど、取引の境界をどう定義するかが業務ロジックに直結します。小売業では「1取引＝1決済」で済むのに対し、飲食業ではネストした概念を扱う必要があります。

(3) 運用イベントが豊富

押し間違い、空打ち、商品差し替え、注文キャンセル、卓移動、人数変動、奉仕料の手動付与、デリバリープラットフォーム経由のオーダー受付、テイクアウトとイートインの振替 ── これらは全て、現場で日常的に発生する運用イベントです。これらを記録しないと、現場の実態と経営数字が乖離します。

これらの3要因が、飲食業のPOSログを小売業のそれより遥かに複雑にしています。電子レシートだけでは捉えきれない情報が、ここに集まっているのです。だからこそARTS POSLog v6でもFoodservice variantが必要とされ、独自の派生仕様として組み込まれました。

6. それぞれが解く問題 ── 一覧で整理する

両者を整理すると、解こうとしている問題そのものが違うことが見えてきます。

両者は対立しません。同じ取引データを、異なる目的のために、異なる構造で表現したものです。どちらか一方では完結しない ── ここが、両者を分けて考えるべき最大の理由です。

7. なぜOFSCはPOSログ標準化に取り組むのか

電子レシートは、すでにOMGの世界標準が整いつつあり、消費者側のエコシステムが形成されはじめています。日本発の仕様が国際標準になった ── これは大きな成果です。

一方で、POSログ層は25年の系譜にもかかわらず、実装が分断したままです。仕様（ARTS POSLog v6）は存在しても、ベンダーごとに独自のCSV出力が進化し続け、業界横断の経営・オペレーション分析を阻んでいます。

OFSCのデータ標準化分科会は、ここに焦点を当てます。「データ」とひとくくりに語るのではなく、電子レシート層は世界標準（DRAPI）に整合させ、POSログ層に集中して業界実装を進める ── これがOFSCの役割分担の発想です。

技術的には、OFSC Gatewayは両層の橋渡しも視野に入れて設計されています。消費者側に対しては電子レシート世界標準（DRAPI）に整合し、経営側に対してはPOSログ標準データを業界横断で提供する ── このアーキテクチャが、業界全体の標準化に必要だと考えています。

おわりに

電子レシートとPOSログは、似て非なるものです。両者を別の問題として整理することで、業界の議論が一段クリアになります。

「データ」をひとくくりにしないこと ── それが、標準化議論を前に進めるための最初の一歩です。