標準は何度も作られた。それでも普及しなかった
── 飲食業POSデータ標準化の25年史

はじめに

「標準が無いから、飲食業界のPOSデータは横並びで比較できない」── 業界の関係者と話していると、しばしばこう言われます。しかし、これは事実ではありません。標準は、何度も作られてきたのです。

1999年に米国NRF/ARTSが策定した「POSLog」、2018年に経済産業省／NEDOがまとめた「標準電子レシートフォーマット仕様書」、そして2025年4月に世界標準として承認された「OMG Digital Receipt API v1.0（DRAPI）」── これらは、いずれも飲食業界のPOSデータを扱える設計を含んでいます。それでも、日本の飲食店のPOSデータは、業態を超えて、企業を超えて、ベンダーを超えて、未だ流通していません。

なぜでしょうか。問うべきは「なぜ標準が無いのか」ではなく、「標準があってなお、なぜ普及しないのか」です。本稿では、25年にわたる飲食業POSデータ標準化の系譜を辿り、普及を阻んできた構造的な要因を整理し、そしてOFSC（一般社団法人オープン・フードサービス・システム・コンソーシアム）が今、何を、どう変えようとしているのかを記します。

1. 25年の標準化の系譜

POSデータの標準化は、決して新しいテーマではありません。世界的にも、日本国内でも、繰り返し試みられてきました。主な節目を時系列で振り返ります。

1999年：ARTS POSLog v1の登場

ARTS（Association for Retail Technology Standards、後にNRF傘下に統合）は、1999年にPOSLog v1を発表しました。それ以前から事実上の業界標準として存在していた「TLog（Transaction Log）」をXML化したものです。POSLogは、小売業の取引データを業界横断で表現するための共通言語として設計されました。

2014年：ARTS POSLog v6 ── 飲食バリアントを含む大規模拡張

15年の歳月をかけて改訂されたPOSLog v6は、2014年に承認、2015年に正式公開されました。策定メンバーには、東芝テック、Epson、NCR、Bizerba、JDA、Microsoft、Yum! Brands、H&M、ノルウェーのNorgesGruppen等、世界の主要なPOSベンダーと小売・外食事業者が名を連ねています。

重要なのは、このv6においてFoodservice variant（飲食業向け派生仕様）が明示的に組み込まれたことです。レストランの顧客ファイル、テーブル単位の取引、注文時刻と提供時刻の分離など、飲食業特有の概念を扱えるよう仕様が拡張されました。

2017〜2018年：経済産業省／NEDOの電子レシート標準化プロジェクト

国内では、経済産業省がNEDO事業の一環として、電子レシートの標準仕様策定に着手しました。委託先は東芝テック株式会社。OFSCのデジタルレシート分科会も協力団体として参画しています。2018年5月には「標準電子レシートフォーマット仕様書」と「電子レシートAPI仕様書」が完成・公開され、東京都町田市での実証実験（27店舗）でも、複数業種・複数ベンダーのPOSから標準仕様の電子レシートを発行することに成功しました。

2025年4月：OMG Digital Receipt API v1.0が世界標準に

日本で策定された電子レシート標準仕様書は、その後、国際標準化団体OMG（Object Management Group）に提出されました。OMGからAPI仕様書の策定も求められ、当初のSOAP-XMLベースの仕様をJSON-RESTに全面変換する作業を経て、2025年4月、「Digital Receipt API v1.0（DRAPI／formal/25-04-01）」として世界標準に承認されました。日本発の仕様が世界標準になった、極めて重要なマイルストーンです。

OFSC代表理事の古幡整がOMG Retail Domain Task ForceのChairとして、この標準化プロセスを主導しました。

このように、POSデータをめぐる標準化の取り組みは、四半世紀にわたって繰り返されてきました。仕様書は完成し、世界標準にもなった。にもかかわらず、日本の飲食店の現場では、各POSベンダーが独自のCSVフォーマットでデータを吐き出し続けています。標準は存在する。実装が分断されているのです。

なぜそうなったのでしょうか。次節で、構造的な3つの理由を見ていきます。

2. 普及しなかった3つの構造的な理由

OFSC代表理事の古幡整は、OPOS（OLE for POS）から電子レシートまで、30年にわたり業界標準化の最前線に立ち続けてきました。その経験から繰り返し語られるのが、「仕様だけでは普及しない」という指摘です。なぜ仕様だけでは普及しないのか。3つの構造的な要因に整理できます。

理由(1)：仕様完成と業界実装は別問題 ── 実装責任を引き受ける主体の不在

標準仕様書を完成させることと、その仕様が業界で実装されることは、まったく別の問題です。仕様書は、設計図に過ぎません。設計図があれば家が建つわけではない、というのと同じです。

ARTS POSLog v6が完成しても、POSベンダーがそれを自製品に実装するインセンティブはありませんでした。経産省の電子レシート仕様書が完成しても、実装したPOSベンダーは限定的でした。OMG DRAPIが世界標準になった現在も、日本の飲食業POSにそれを実装した例はほぼ皆無です。

仕様策定の場には事業者、ベンダー、業界団体が集まります。しかし、仕様完成後に「では、これを業界全体に実装していく責任は誰が持つのか」という問いに、明確な答えが用意されてこなかったのです。

理由(2)：ベンダー側のロックイン解除インセンティブの不在

POSベンダーにとって、業界共通の標準データフォーマットへの対応は、短期的にはコストでしかありません。長期的にも、競合との差別化が薄まり、ユーザー企業のスイッチング（他社POSへの乗り換え）が容易になることを意味します。つまり、自社のシェア維持・拡大という観点からは、標準化への積極投資は合理的選択になりにくいのです。

結果として、各POSベンダーは独自のCSVフォーマットを進化させてきました。たとえばある国産POSベンダーのCSV仕様では、集計項目だけで256項目を超える独自定義がなされています。各ベンダーが独自のレシピで「データ料理」を出し続けてきた結果、ユーザー企業はそれぞれの皿を別々に消費するしかない状況が続いてきました。

理由(3)：顧客側の集合組織の不在 ── 個別最適から業界横断へ

標準化を本気で要求する顧客側の声が、業界横断で集合化されてこなかったことも大きな要因です。各飲食チェーンは、自社のPOSベンダーに個別にカスタマイズを要望し、自社最適のデータ環境を整えてきました。しかしそれは、業界全体の標準化を要求する集合的な圧力にはなりませんでした。

2026年4月16日にMicrosoft品川オフィスで開催された「スマーターリテーリングフォーラム2026」（SRF2026）において、トライアルホールディングス／Retail AI Inc.の西川晋二氏は、印象的な指摘をしています。「リテール業界の生産性は、20年にわたる政府主導の施策にもかかわらず、国際平均の半分のままだ」と。この事実は、標準化を含むDX施策が、業界全体の実装に至っていないことの傍証と読むことができます。

これら3つの要因 ── 実装責任主体の不在、ベンダー側のインセンティブ不整合、顧客側の集合組織の不在 ── が複合的に作用し、飲食業POSデータの標準化は「仕様はあるが現場には届かない」状態に置かれ続けてきました。

3. 電子レシートとPOSログ ── 標準化レイヤーの違い

ここで、しばしば混同される2つの概念を整理しておきます。電子レシートとPOSログは、似て非なるものです。両者の違いを理解しないと、標準化の議論はすぐに錯綜します。

電子レシート ── 消費者〜決済間レイヤー

電子レシートが扱うのは、店舗が消費者に対して発行する「会計の証拠」です。レシートの発行、消費者側での受信、保存、参照、家計簿アプリ等での二次利用までを含むレイヤーです。OMG Digital Receipt API v1.0（DRAPI）として2025年に世界標準化されたのは、まさにこのレイヤーです。

POSログ ── 経営〜オペレーション間レイヤー

一方、POSログが扱うのは、店舗運営における「取引明細・集計・分析」の情報です。商品ごとの売上、客数、客単価、決済種別の内訳、時間帯別の動き、テイクアウトと店内飲食の区別、注文時刻と提供時刻、テーブル別の取引、奉仕料の有無 ── こうした、経営判断とオペレーション改善のために用いられるデータ群です。

両者は補完関係、代替関係ではない

電子レシートとPOSログは、どちらか一方で代替できるものではありません。両者は補完関係にあります。電子レシートが標準化されたからといって、POSログの標準化が不要になるわけではない ── これは古幡が繰り返し業界に対して指摘してきた論点です。

OFSCがいま取り組んでいるのは、後者、すなわちPOSログ（経営〜オペレーション間レイヤー）の標準化です。OMGの世界標準（DRAPI）を土台に置きつつ、その先にある経営・オペレーションのレイヤーに橋を架けようとしています。

4. 転機 ── なぜ「今」なのか

25年にわたり何度も試みられ、何度も普及せずに来た飲食業POSデータの標準化。それを今、改めて取り組む意味はどこにあるのでしょうか。4つの外部環境の変化が、決定的に状況を変えつつあります。

(1) 中堅チェーンのデータ活用ニーズの顕在化

これまで、データ活用は大手チェーンの特権でした。しかし近年、中堅チェーン（10〜50店舗規模）でも、本部システムやBIツールを使って店舗別の収益管理を行うのが当たり前になりつつあります。複数のPOSを併用するチェーンも増えました（M&Aによる業態統合、業態別のベンダー使い分け等）。「複数ベンダーのPOSデータを統合できないと経営できない」という状況が、現場の問題として浮上してきました。

(2) AIエージェント時代の到来

生成AIとAIエージェントの実用化が進む中、標準化されていないデータはAIに食わせられないという新しい制約が見えてきました。AIに在庫予測をさせる、AIにメニュー戦略を提案させる、AIに営業日報を書かせる ── どれも、入力データの構造が揃っていることが前提です。バラバラのCSVのままでは、AIネイティブな経営に進めません。

(3) サプライチェーン側との接続要請

POSデータだけでは経営判断は完結しません。仕入データ、勤怠データ、シフトデータ、天気データなど、店舗運営を構成する周辺データとの接続が必須です。標準データフォーマットがないと、これらの接続は毎回個別実装になり、コストが下がりません。

(4) 「標準が無いコスト」の経営課題化

これら3つの変化が重なった結果、「標準が無いことのコスト」が、初めて経営課題として可視化されるようになりました。それまでは「POSベンダーごとに違うのは仕方ない」と諦められていたコストが、今や「データ統合に毎月数十時間使っている」「AIに食わせるためのデータクレンジングが終わらない」「複数POSの数字を本部レポートに合わせるのに毎月格闘している」という具体的な経営課題として表面化しています。

つまり、これまで「あったら便利」だった標準化が、いま「無いと経営できない」段階に移行しつつあるのです。これが、何度も失敗してきた業界標準化を、改めて今取り組む合理性です。

5. OFSCのアプローチ ── 25年の教訓から学んだこと

25年の標準化の系譜から、OFSCが学んだ最大の教訓は1つです。「仕様を作るだけでは、業界実装は起きない」。

この教訓に基づいて、OFSCのデータ標準化分科会は、以下の3つの原則でアプローチを設計しています。

原則(1)：OMG世界標準を土台にする

ゼロから新しい標準を作るのではなく、すでに世界標準となっているOMG Digital Receipt API v1.0（DRAPI）を土台に据えます。DRAPIは小売・飲食を含むPOS取引データの構造を定義する世界標準であり、これを無視して別の標準を立ち上げることは、業界全体にとって合理的ではありません。OFSCが扱うのは、DRAPIを基盤としつつ、その上位にあたる経営〜オペレーション集計レイヤーです。

原則(2)：「合意可能な最小集合」から始める

すべての業態、すべてのチェーン、すべてのベンダーを満足させる完璧な仕様を最初から定義しようとすると、合意は永遠にまとまりません。OFSCは、まず「合意可能な最小集合」に絞り、それを業界共通仕様として確定させます。範囲設計の思想を共有することから始めることが、25年の失敗から学んだ最大の方法論的転換です。

原則(3)：実装責任を引き受ける主体を伴走させる

これが、過去25年と最も異なる点です。OFSCは仕様策定だけを行うのではなく、その仕様を業界全体に実装するためのインフラ層（OFSC Gateway）を併走させます。各POSベンダーの独自フォーマットから標準データへの変換、API／FTP／CSVでの提供、ユーザー企業側からのアクセス、これらすべてを業界横断のインフラとして提供する設計です。

仕様を作るだけでは、仕様書は本棚にしまわれます。実装責任を引き受ける主体があってはじめて、業界に届きます。25年の系譜は、その当たり前のことを、当たり前に教えてくれました。

おわりに

「標準が無いから飲食業のデータは流通しない」という言説は、事実ではありません。標準は何度も作られ、世界標準にもなりました。問題は標準の不在ではなく、実装の分断です。

OFSCはこの構造に挑みます。仕様策定、ベンダー側の参画、ユーザー企業側の集合化、そして実装インフラの伴走 ── すべてを業界横断で進めていきます。