会合の概要
第7回データ標準化分科会は、「標準化」と「実装」の役割をはっきり分けた回となりました。分科会の議論が具体化するにつれ、「その仕様を誰がいつ実装するのか」という話題が自然と入り込むようになっていました。これを分科会の議題として扱ってよいかを運営規程に照らして確認した結果、実装と事業はOFSCの枠の外で進め、本分科会は標準化そのものに専念することとしました。
あわせて、標準フォーマット V1.0 が実装の最終段階に入ったことを報告しました。駅構内事業者よりご提供いただいた多業態・多メーカーの実機生データの読み解きが進み、ターミナル系・モバイルPOS系ともに主要な系統を一巡しています。AI活用により、1メーカー分のデータを解析して標準へ取り込むまでの所要が大幅に短縮されており、ロードマップは前倒し基調を維持しています。
1. 標準化と実装の切り分け
本分科会は、標準の中身を議論する場です。「どこがいくらで実装するのか」を決める場ではないことは、第1回から申し上げてきました。一方で議論が具体化するほど、実装や事業スキームの話題が入り込みやすくなります。これは参加各社の関心が具体化した証でもありますが、扱う場を誤ると標準そのものの成立条件を損ないます。
そこで運営規程および知的財産権合意書との整合をあらためて確認し、実装と事業はOFSCの枠の外で進めることといたしました。
この分科会で扱うこと
- 標準フォーマットの仕様策定
- 語彙・命名規則の定義
- データ階層とスコープの決定
- 適合の考え方の整理
- 仕様の公開・維持・更新
この分科会の外で扱うこと
- 個社ごとの実装・接続構成
- 費用・契約・事業スキーム
- 導入時期・体制の調整
- 個別の運用サポート
右側を「やらない」という意味ではありません。「この場では扱わない」という意味です。右側は別の場で進みます。
1-1. なぜ分けたのか
分けた理由は、標準そのものを守るためです。OFSCの運営規程および関連文書には、次の定めがあります。
- 運営規程 第27条 — 分科会長が単独で仕様を決定できないよう制限しています。
- 運営規程 第13条 — 利益相反の防止を定めています。
- 知的財産権合意書 — 特定企業の特許権が標準仕様に影響しないことを担保しています。
これらはいずれも同じことを示しています。標準は、特定の誰かの都合が入らないからこそ標準として成立します。実装の議論を同じ場に置いたままにすると、「特定の実装者に都合のよい仕様になっているのではないか」という疑義が生じ得ます。そう見えた時点で、仕様の出来にかかわらず標準としての価値は失われます。
なお、分科会長は実装にも関わる立場にあるため、仕様の最終決定には関与しません。分科会は方向性を整理して提案をまとめ、決定は理事会が行います。
2. OFSCが担い続けること
実装を外に出したことをもって、OFSCが関与から退くわけではありません。むしろ規程上の制約の中で実装を止めないための整理です。本分科会として担い続けるものは、次の4点です。
- ① 仕様を維持・更新し続ける — 公開して終わりにはしません。
- ② 適合の考え方を示し続ける — 何をもって「標準に沿っている」と言えるのかを示します。
- ③ この分科会を継続する — 仕様の公開をもって解散はしません。
- ④ 実装が前へ進むよう調整する — 必要な調整を続けます。
実装を外に出したのは、OFSCが手を引いたからではありません。実装を止めないために分けました。
この分科会は、実装が業界のインフラとして機能しはじめるまで閉じません。
3. 標準フォーマット V1.0 の現在地
駅構内事業者よりご提供いただいた実機生データの読み解きが進み、V1.0の実装は最終段階に入りました。並行して、各POSメーカーの出力データを1社ずつ解析し、標準への変換を追加しています。
- 対応系統 — ターミナル系の主要メーカーは一巡しました。モバイルPOS系についても取り込みを進めています。
- 開発速度 — AI活用により、1メーカー分の生データを解析して標準実装へ持ち込むまでの所要が、従来の数ヶ月規模から大幅に短縮されました。
- 取り込みのご相談 — 対応をご希望のPOSメーカー・利用企業がございましたら、分科会までお申し付けください。
3-1. 仕様書だけでは分からないこと ── 生データが不可欠な理由
実データの読み込みを通じて、カラム名と実際に格納されている値が一致しない事例が数多く見つかりました。たとえば「入店時刻」に相当する名称のカラムであっても、実データを確認すると、実態はファーストオーダーの時刻であることがあります。
これを「客が入店した時刻」として記録すべきか、実態に即して「ファーストオーダー時刻」として扱うべきかは、解釈を伴う判断です。仕様書だけを読んでいては判断できず、実データを見て初めて分かります。各社に実データのご提供をお願いしているのは、この理由によります。
4. V1.0 で扱うデータ
V1.0は集計データではなくログデータを基本概念としています。まずは売上管理と会計連携という、最も困りごとの大きい領域から扱います。
| データ種別 | 対応する概念 | 内容 |
|---|---|---|
| 商品販売明細 | LineItem | 何が、いくつ、いくらで売れたか |
| 伝票明細 | RetailTransaction | 1会計単位のまとまり |
| 支払種別明細 | Tender | 現金・カード・各種決済の内訳 |
| 時間帯集計 | — | 15分・30分・1時間などの単位を利用企業が選択 |
| 日計集計 | — | 1日単位の集計 |
| 現金入出金・現金在高 | — | レジ現金の動きと残高 |
命名は米国標準規格 POSLog に準拠しています。日本語名称については、電子レシート標準で定義済みの名称を引用しています。独自ルールを新設するのではなく、国際標準との整合を優先しています。
4-1. 税・価格の取り扱い
- 内税の按分をスコープに含めます。伝票単位で付与された内税を商品明細へ按分する処理に対応します。
- カタログ価格・税込販売価格・税抜販売価格をそれぞれ保持します。
- 端数処理（丸め）方式は企業ごとに選択できます。総合計に合わせるか、明細単位で整えるかを利用企業が選べる設計です。
- 商品明細への割引の紐付けは、現時点ではスコープ外としています。ご要望があれば検討します。
4-2. 対象業種
外食・中食を主軸としつつ、小売についてもミニマムで対応します。今回お預かりした実データに物販が含まれていたため、これを除外すると検証が片手落ちになるという判断です。税を商品単位で持つ仕様か伝票単位で持つ仕様かといった違いを吸収する形で進めています。
5. 設計の考え方 ── POSメーカーに開発負担をかけない
POSメーカー側
- 既存のFTP／API出力を、そのまま出すだけ
- 新規の開発は不要
- 仕様変更への追随も不要
標準フォーマット側
- 出力フォーマットを1社ずつ解析し、標準へ変換
- 各社の日計集計と変換後の集計値を必ず突合し、精度を担保
数字が合わなければ変換が誤っているということですので、突合を精度担保の要としています。また、POSメーカー側で標準仕様に沿った出力を実装いただくことも歓迎です。仕様は公開しますので、いずれの方式も選択できます。
データを利用する側のベンダーは、標準フォーマットの取り込み口を一度だけ開発すれば、業界のどのPOSにも対応できるようになります。
6. 外食・中食・小売企業にとって何が変わるか
- POSを選び直せるようになります。POSを変えても出力されるデータの形は変わらないため、システムの選択がデータの都合に縛られなくなります。
- つなぎ込みが一度で済みます。会計システム、BI、本部システムへの個別開発から解放されます。
- 規模を問わなくなります。これまで大手企業しか手の届かなかったデータ活用に、中小・個人店も同じ基盤で乗れるようになります。
7. AI Ready なデータとは何か
標準化の価値は、社内のバラバラなPOSデータを一つに揃えられることに留まりません。当日は、AI活用の前提としての標準化について整理を共有しました。
- 生データをそのままAIに投入すると、処理はできてもコストが膨大になります。整理・集計された標準データを渡して初めて、費用対効果の見合う使い方ができます。
- カラム名称の揺らぎは、AIに黙って誤解させます。同じ意味のデータに各社が異なる名称を付けてきた結果、AIは読み違えたまま処理を続けます。出力を検算して初めて、最初のカラム解釈が誤っていたと判明する、ということが実際に起こります。数十・数百のカラムでこれが生じれば、正しい集計は成り立ちません。
- 外食には標準タグ付けが必要です。外食では各店舗が独自の商品名を付けるため、同種の商品をAIが同じカテゴリとして認識できません。「これはラーメンである」といった業界標準のタグ付けを実装することで、横断的な分析が可能になります。
8. 当日の主な議論
8-1. 未対応系統のPOSをどう取り込むか
百貨店業界の参加者より、現在未対応の系統のPOSについて取り込みの可否をご質問いただきました。POSメーカーの窓口からではなく、そのPOSを使用しているユーザー企業から許諾を得て実データをお預かりする流れが、最もスムーズである旨をご説明しました。ユーザー企業のご紹介についてもご協力の意向をいただいています。
8-2. 接続標準とネットワーク運用
店舗で発生するトラブルの多くがネットワーク由来である実態が、あらためて共有されました。ターミナルPOSの時代はベンダーがネットワークの敷設から運用まで担っていましたが、現在のタブレット系POSではネットワークが利用企業側の管理に委ねられています。結果として、家庭用ルーターや旧式のアクセスポイントが使われ続け、ハンディオーダーやキッチンプリンターのトラブルが頻発しています。
これはPOSの問題ではなく、「正しいインフラとは何か」を誰も示していないことに起因します。POS周辺の接続標準（決済端末・自動釣銭機・プリンター・ネットワーク設定等）については関連分科会で議論が始まっており、連携して進めます。
また、一部のPOSではデータ収集に集配信の仕組みが別途必要であり、店舗ごとの設定差異（表記の揺れ、割引番号の不一致など）がそのまま集計の混乱につながる実態も共有されました。標準実装においては、この接続部分がボトルネックになりやすいという認識を共有しています。
8-3. ID-POSデータと電子レシート
AI分科会長より、ポイントシステムと購買データが紐づいていないため、「いくら使ったか」は分かっても「何を買ったか」が分からないという課題が提起されました。決済端末経由でポイントが付与される構成では、ID-POSデータ化が進みません。
これに対し、電子レシートの標準実装をハブとする方向性を共有しました。標準化された電子レシートを各社が実装すれば、企業アプリ間・ポイント間の連携を利用者自身が自分の端末上で自由に組めるようになります。連携は事業者が行うのではなく利用者が行うため、利便性が動機となってアプリの利用が広がり、結果として各社が取得できるIDデータが大きく増える、という構図です。中小・個人店でも大手のポイントサービスを運用できる市場が生まれます。
8-4. EC領域との接合
実店舗とECを併せ持つ事業に取り組む参加者より、在庫・売上・決済の3点を統合する必要があり、決済は共通基盤の利用で実店舗との差を埋められる一方、売上については仕様の標準化への期待が大きいとのご意見をいただきました。ベンダーが領域ごとに異なるため個別見積が積み上がる一方、実現したいことは統合されている、という実態も共有されました。EC領域も将来のスコープとして認識を共有しています。
8-5. 商品マスター標準化 ── 小売と外食の合流点
小売業界では、アレルゲン情報をはじめとする商品情報の拡充に伴い、商品マスターの持ち方・参照の仕方を見直す必要が生じています。小売の切迫した課題がデータの入口（商品マスター）にあるのに対し、外食は店舗が製造現場であるため出口（販売時のデータ）の標準化が先という違いがあります。
ただし外食でも、事業統合に伴う商品マスターの統合は現に課題となっており、いずれ両者は合流します。関連部会と情報交換を継続します。なお、マスターへの書き込みを伴う連携は権限設計の面で難易度が上がるため、スコープの範囲は慎重に検討すべきという認識も共有されました。
8-6. 協調領域と競争領域
参加者より、標準として持つ範囲と各社が競争する範囲の境界を分かりやすく示してほしい、とのご要望をいただきました。
分析ツールやダッシュボードは、あるべき論ではなく各社の好みと事情によって選ばれるものであり、選択肢が一つしかない状態はむしろ不健全です。一方で、データを正しく取得する部分は全社が同じことをしており、ここに共通項がないために各ベンダーがゼロから接続開発を繰り返しています。ここは競争すべき領域ではなく、共通の仕組みを用意して皆で使えばよい領域です。
接続の工数が不要になることで、ベンダー各社は本来の開発に集中でき、かつ市場が自由化されることであらゆる企業にアプローチできるようになります。ベンダーロックインの解消は、利用企業とベンダー双方にとっての利益であるという認識を共有しました。
9. 電子レシート標準化
本標準は、約20年前に策定されたPOSログの世界標準を全面的に参照して構築しています。同じ親を持つため、データ標準が固まれば電子レシート標準はほぼ自動的に完成します。仕様書はすでに存在し、日本語名称の定義も整っています。年内のスタートを目指します。
10. 団体名称の変更について
2026年6月10日、OFSCとSRF（スマーター・リテイリング・フォーラム）の統合に伴い、一般社団法人OFSC に名称を変更しました。飲食と小売を横断する情報システム標準化団体として位置づけを改めています。ウェブサイトの内容も全面的に刷新しました。小売のSKU対応についても、できるだけ早期にスコープへ組み込む方針です。
11. 実データ提供・ロゴ掲載のお願い
11-1. 実データのご提供
V1.0に御社のデータが取り込まれていない状態では、御社にとってこの標準が使えるものかどうかを検証していただくこと自体ができません。実データをお預かりできれば、標準と突き合わせて足りない項目・形の合わない項目を洗い出し、必要なものは標準側に取り込みます。そのうえで、御社のデータが標準データとして扱える状態にしてから検証していただけます。
「使えると分かってから提供する」という順序では、双方とも先に進めません。まずは実データのご提供からお願いいたします。複数業態・複数店舗・一定期間分のサンプルと、あわせて仕様書をご提供いただけますと幸いです。ご検討段階でのご参加で問題ありません。
11-2. 賛同ロゴのご提供
標準は、仕様の出来だけでは決まりません。一社の取り組みに見えているうちは、標準になりません。賛同企業として社名・ロゴが並ぶことが、業界に対する最も強いメッセージになります。
ロゴ掲載は本活動の方向性へのご賛同を示すものであり、特定製品の採用を約束するものではありません。無料・自動更新の条件で、広く受け付けています。中食・小売企業からのご賛同・ご参加も歓迎しております。
次回開催
| 日時 | 2026年8月31日（月）16:00〜17:30 |
|---|---|
| 形式 | WeWork 神田スクエア 11F（対面）＋ オンライン（Zoom）ハイブリッド |
| 予定議題 | 1. 標準フォーマット V1.0 の仕様確定に向けた確認 2. 実データ検証の結果報告 3. 今後の進め方 |
本レポートに関するお問い合わせ、分科会への参加ご希望はデータ標準化分科会ページのお問い合わせフォームよりご連絡ください。アンケートのみの参加、ロゴ掲載のみのご賛同も歓迎しております。